On Thu Aug 28, 2025 at 9:31 PM CEST, Miguel Ojeda wrote:
> On Thu, Aug 28, 2025 at 9:24 PM Danilo Krummrich <d...@kernel.org> wrote:
>>
>> Maybe I spoke too soon, it's actually pretty painful to keep 32-bit
>> compatibility, even though it would be nice for testing purposes.
>>
>> I'll paste the diff to fix it below, I think that makes it obvious why I say
>> that.
>>
>> Instead, we should really just depend on CONFIG_64BIT (which implies
>> ARCH_DMA_ADDR_T_64BIT).
>
> Yeah, it isn't great.
>
> If it were just that, maybe it it is worth it (and a `DmaAddress`
> newtype, not just a typedef, could perhaps be nice anyway?)
What do you have in mind what the newtype can do?
I assume the idea is to make it provide methods {to,from}_u64, where to_u64()
has to be fallible? This would be an improvement, but not really solve the issue
entirely.
The annoying part really is
pub(super) fn read_sysmem_flush_page_ga100(bar: &Bar0) -> DmaAddress {
let addr =
u64::from(regs::NV_PFB_NISO_FLUSH_SYSMEM_ADDR::read(bar).adr_39_08())
<< FLUSH_SYSMEM_ADDR_SHIFT
|
u64::from(regs::NV_PFB_NISO_FLUSH_SYSMEM_ADDR_HI::read(bar).adr_63_40())
<< FLUSH_SYSMEM_ADDR_SHIFT_HI;
addr.try_into().unwrap_or_else(|_| {
kernel::warn_on!(true);
0
})
}
i.e. when we read a u64 from registers, but we know that what we've orignally
written there is a DmaAddress, so we can assume that a cast to DmaAddress is
fine.
But this really depends on driver specific semantics.
> but if
> you think it will become increasingly painful later, then it may be
> best to focus on what matters.
We'll have a couple more such cases for sure; I think being able to assume that
DmaAddress is always 64-bit will result in simpler and less distracting code.
But if we can come up with a good idea to deal with this with a DmaAddress type;
I'm open to that.
> It is unlikely there is going to be actual users on a 32-bit platform, right?
Yeah, I doubt that someone could think it's a great idea to run a Turing+ GPU on
some 32-bit machine.
