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

"Gary Guo" <[email protected]>
Newsgroups org.kernel.vger.linux-pci,dev.linux.lists.driver-core,dev.linux.lists.nova-gpu,org.freedesktop.lists.dri-devel,org.kernel.vger.linux-kernel,org.kernel.vger.rust-for-linux
Message-ID <[email protected]>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.