This series contains a few fixups for the recently merged GSP
command-queue code, by order of importance:

- Some explicit padding required to safely implement `AsBytes` was
  missing in the bindings,
- A bug in the received message length calculation results in the
  message handler being given more data than it should, 
- `MaybeZeroable` is now derived by the kernel's bindgen, but the Nova
  bindings have not been updated for that,
- Some items in the bindings were referred to using the version module
  directly, instead of the alias we defined to limit the diff when we
  upgrade firmware versions.

All of them address "bugs" (with the first two fixing actual correctness
issues), but since Nova does not do much anyway, they are also not
absolutely critical and can wait -rc1 if we prefer to do so.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
---
Changes in v2:
- Add missing "Fixes:" tags.
- Link to v1: https://lore.kernel.org/r/20251122-nova-fixes-v1-0-a91eafeed7b5@nvidia.com

---
Alexandre Courbot (4):
      gpu: nova-core: bindings: Add missing explicit padding
      gpu: nova-core: gsp: Fix length of received messages
      gpu: nova-core: bindings: Derive `MaybeZeroable`
      gpu: nova-core: gsp: Replace firmware version with "bindings" alias

 drivers/gpu/nova-core/gsp/cmdq.rs                 |  11 ++-
 drivers/gpu/nova-core/gsp/fw.rs                   |  67 +++++++-------
 drivers/gpu/nova-core/gsp/fw/r570_144.rs          |  11 ++-
 drivers/gpu/nova-core/gsp/fw/r570_144/bindings.rs | 105 ++++++++++++----------
 4 files changed, 103 insertions(+), 91 deletions(-)
---
base-commit: 57dc2ea0b7bdb828c5d966d9135c28fe854933a4
change-id: 20251121-nova-fixes-dc9b4f17b90e

Best regards,
-- 
Alexandre Courbot <acourbot@nvidia.com>

On Sun Nov 23, 2025 at 2:12 PM JST, Alexandre Courbot wrote:
> This series contains a few fixups for the recently merged GSP
> command-queue code, by order of importance:
>
> - Some explicit padding required to safely implement `AsBytes` was
>   missing in the bindings,
> - A bug in the received message length calculation results in the
>   message handler being given more data than it should, 
> - `MaybeZeroable` is now derived by the kernel's bindgen, but the Nova
>   bindings have not been updated for that,
> - Some items in the bindings were referred to using the version module
>   directly, instead of the alias we defined to limit the diff when we
>   upgrade firmware versions.
>
> All of them address "bugs" (with the first two fixing actual correctness
> issues), but since Nova does not do much anyway, they are also not
> absolutely critical and can wait -rc1 if we prefer to do so.

Alice, Danilo, how would you like to proceed with this series? We could
either:

* Merge this into `drm-rust-next` if you are planning on sending another
  before -rc1,
* Wait until -rc1 gets released and send it via `drm-rust-fixes` for
  -rc2,
* ... or just take it for 6.20, as it is not absolutely critical.

I am not very familiar with how to do things after the merge window has
opened, so appreciate your guidance here.

On 2025-12-08 18:06, Alexandre Courbot wrote:
> On Sun Nov 23, 2025 at 2:12 PM JST, Alexandre Courbot wrote:
>> This series contains a few fixups for the recently merged GSP
>> command-queue code, by order of importance:
>> 
>> - Some explicit padding required to safely implement `AsBytes` was
>>   missing in the bindings,
>> - A bug in the received message length calculation results in the
>>   message handler being given more data than it should,
>> - `MaybeZeroable` is now derived by the kernel's bindgen, but the Nova
>>   bindings have not been updated for that,
>> - Some items in the bindings were referred to using the version module
>>   directly, instead of the alias we defined to limit the diff when we
>>   upgrade firmware versions.
>> 
>> All of them address "bugs" (with the first two fixing actual 
>> correctness
>> issues), but since Nova does not do much anyway, they are also not
>> absolutely critical and can wait -rc1 if we prefer to do so.
> 
> Alice, Danilo, how would you like to proceed with this series? We could
> either:
> 
> * Merge this into `drm-rust-next` if you are planning on sending 
> another
>   before -rc1,
> * Wait until -rc1 gets released and send it via `drm-rust-fixes` for
>   -rc2,
> * ... or just take it for 6.20, as it is not absolutely critical.
> 
> I am not very familiar with how to do things after the merge window has
> opened, so appreciate your guidance here.

Let’s wait for -rc1 and subsequently queue them up in drm-rust-fixes.

Currently we are not running a -next-fixes scheme, so -next is closed 
until -rc1 is released.