linux-kernel - Re: gpu: nova-core: arm32 build errors

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <DCEDOBPT4VLP.R2K3EWY871F1@kernel.org>
Date: Thu, 28 Aug 2025 23:27:51 +0200
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Miguel Ojeda" <miguel.ojeda.sandonis@...il.com>
Cc: "Miguel Ojeda" <ojeda@...nel.org>, "Alexandre Courbot"
 <acourbot@...dia.com>, "David Airlie" <airlied@...il.com>, "Simona Vetter"
 <simona@...ll.ch>, <nouveau@...ts.freedesktop.org>,
 <dri-devel@...ts.freedesktop.org>, <rust-for-linux@...r.kernel.org>,
 <linux-kernel@...r.kernel.org>
Subject: Re: gpu: nova-core: arm32 build errors

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@...il.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.