Re: [PATCH v3 08/13] gpu: nova-core: Add bindings and accessors for GspSystemInfo

["Benno Lossin" <lossin@kernel.org>]

On Fri Oct 3, 2025 at 7:25 PM CEST, Janne Grunau wrote:
> On Fri, Oct 03, 2025 at 06:34:12PM +0200, Benno Lossin wrote:
>> On Thu Oct 2, 2025 at 3:49 PM CEST, Alexandre Courbot wrote:
>> > Hi Alistair, (+Benno as this concerns the `init!` macros)
>> >
>> > On Tue Sep 30, 2025 at 10:16 PM JST, Alistair Popple wrote:
>> >> Adds bindings and an in-place initialiser for the GspSystemInfo struct.
>> >>
>> >> Signed-off-by: Alistair Popple <apopple@nvidia.com>
>> >>
>> >> ---
>> >>
>> >> It would be good to move to using the `init!` macros at some point, but
>> >> I couldn't figure out how to make that work to initialise an enum rather
>> >> than a struct as is required for the transparent representation.

Oh by the way, enums are not supported due to a language limitation,
see:

    https://github.com/Rust-for-Linux/pin-init/issues/59

>> > Indeed we have to jump through a few (minor) hoops.
>> >
>> > First the `init!` macros do not seem to support tuple structs. They
>> > match a `{` after the type name, which is not present in
>> > `GspSystemInfo`. By turning it into a regular struct with a single
>> > field, we can overcome this, and it doesn't affect the layout the
>> > `#[repr(transparent)]` can still be used.
>> 
>> Yeah that's the correct workaround at the moment. I'm tracking support
>> for tuple structs in [1]. Essentially the problem is that it requires
>> lots of effort to parse tuple structs using declarative macros. We will
>> get `syn` this cycle, which will enable me to support several things,
>> including tuple structs.
>> 
>> [1]: https://github.com/Rust-for-Linux/pin-init/issues/85
>> 
>> > Then, due to a limitation with declarative macros, `init!` interprets
>> > `::` as a separator for generic arguments, so `bindings::GspSystemInfo`
>> > also doesn't parse. Here the trick is to use a local type alias.
>> 
>> This one will also be solved when we switch to syn.
>
> I was planning to submit
> https://github.com/AsahiLinux/linux/commit/2d95fd3b6c359634a0976f27f7a3c667826256da
> https://github.com/AsahiLinux/linux/commit/515638cb47cf0ebdac378686fcbbdc6a8364096a
> from the asahi downstream tree after 6.18-rc1. Does that still make
> sense timing wise?

Probably not, since I'll depend on the syn patches this cycle which will
mean that pin-init supports tuples in 6.19.

> Types with type paths are used extensively in the asahi driver but I can
> initially work around that.

Yeah they should be supported simply by moving to syn, hope it doesn't
introduce too much pain in the next cycle.

---
Cheers,
Benno