Re: [PATCH 08/10] gpu: nova-core: use projection for PFALCON and PFALCON2 registers

From: Gary Guo

Date: Wed Jul 29 2026 - 16:04:40 EST


On Wed Jul 29, 2026 at 8:28 PM BST, Danilo Krummrich wrote:
>> The offset for `subregion` is no different to the offset for `read()`. In both
>> cases you are supposed to only supply build-time const values; and in both cases
>> you can argue they are needed there due to const generics being too limited to
>> what they do.
>
> I see where you are coming from, but I see it from a different angle:
>
> An offset given to read() can legitimately be a runtime value that happens to be
> constrained in a way that the compiler can proof that it is within bounds (with
> dead code elimination doing the rest). We have reasonable use-cases where the
> offset given to read() is not a "true" constant, and hence build_assert! is the
> correct tool.
>
> subregion() is different in this regard, as we do not have reasonable use-cases
> where the offset is not a "true" constant. (And I would guess that this also
> made you choose the implementation you picked for this patch.)

I think it's the same. Imagine instead of register arrays, you have subregion
arrays.

>
> It just happens that we hit a language limitation where const evaluation of a
> "true" constant does not work, but that does not make build time assertion the
> correct tool, it just makes it a workaround for the existing limitation.
>
> This is also in line with the documentation in rust/kernel/build_assert.rs.
>
>> We probably could even just add a method that gives you a subregion based on
>> `IoLoc` similar to other methods. This actually might be a good idea that I'd
>> pursue in next version.
>
> So, you are proposing that subregion() takes an argument of type
> L: impl IoLoc<_>?
>
> Where would this argument come from?
>
> I assume you would need to bring back
>
> impl RegisterBase<Foo> for Bar {
> const BASE: usize = 0xff;
> }
>
> impl blocks? Which seems like just adding boilerplate? Or do you have something
> else in mind?

No, I was thinking of

struct MySubRegion([u8; 4096]);

impl Register for MySubRegion {
type Storage = Self;
const OFFSET: usize = ...;
}

this can be generated with `register!` macro if you can attach a specific type
and not have it generate `bitfield!()`.

E.g.

struct MySubRegion([u8; 4096]);

register! {
pub SUBREGION: MySubRegion @ 0x1000;
}


Best,
Gary