gpu: nova-core: arm32 build errors

[Danilo Krummrich]

On Thu Aug 28, 2025 at 9:58 PM CEST, Danilo Krummrich wrote:
> On Thu Aug 28, 2025 at 9:36 PM CEST, Miguel Ojeda wrote:
>> On Thu, Aug 28, 2025 at 9:31 PM Miguel Ojeda
>> <miguel.ojeda.sandonis at gmail.com> wrote:
>>>
>>> and a `DmaAddress`
>>> newtype, not just a typedef, could perhaps be nice anyway?
>>
>> The one from your linked patch is not a newtype though, so I guess
>> there is a reason for that.
>
> No specific reason, I didn't see a lot of value in a newtype in the first
> place, depending on you answer in the other thread, may we just found some
> value. :)

To expand a bit, the typdef is also for simplicity. Eventually, drivers will do
some arithmetic on the DMA address, etc.

So, if we have a new type, we'd probably want to provide methods for doing the
most common arithmetic operations, because we don't want to convert to/from the
corresponding primitive type all the time.

At the same time we could take this further and also provide a DmaRange type,
which also considers the size for those operations.

DmaRange is actually something that I had in mind to implement subsequently,
because I'm not too happy with CoherentAllocation::dma_handle_with_offset(),
it's just too specific and insufficient.

Given that, I thought there's not that much value in making DmaAddress a new
type. (Mybe saying "no specific reason" was a slight understatement. :)

So, if the idea was to have from/to helpers, we can also do them on DmaRange.

However, given that also the above only helps in a limited way for the cases
discussed in the other thread, I feel like the best option might still be to
depend on 64-bit for Nova.