Message-Id: <DFTJEACENL9R.28V5QOJXXNM0S@garyguo.net>
Date: Tue, 20 Jan 2026 15:54:45 +0000
From: "Gary Guo" <gary@...yguo.net>
To: "Zhi Wang" <zhiw@...dia.com>, <rust-for-linux@...r.kernel.org>,
 <linux-pci@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Cc: <dakr@...nel.org>, <aliceryhl@...gle.com>, <bhelgaas@...gle.com>,
 <kwilczynski@...nel.org>, <ojeda@...nel.org>, <alex.gaynor@...il.com>,
 <boqun.feng@...il.com>, <gary@...yguo.net>, <bjorn3_gh@...tonmail.com>,
 <lossin@...nel.org>, <a.hindborg@...nel.org>, <tmgross@...ch.edu>,
 <markus.probst@...teo.de>, <helgaas@...nel.org>, <cjia@...dia.com>,
 <smitra@...dia.com>, <ankita@...dia.com>, <aniketa@...dia.com>,
 <kwankhede@...dia.com>, <targupta@...dia.com>, <acourbot@...dia.com>,
 <joelagnelf@...dia.com>, <jhubbard@...dia.com>, <zhiwang@...nel.org>,
 <daniel.almeida@...labora.com>
Subject: Re: [PATCH v10 2/5] rust: io: separate generic I/O helpers from
 MMIO implementation

On Mon Jan 19, 2026 at 8:22 PM GMT, Zhi Wang wrote:
> The previous Io<SIZE> type combined both the generic I/O access helpers
> and MMIO implementation details in a single struct. This coupling prevented
> reusing the I/O helpers for other backends, such as PCI configuration
> space.
>
> Establish a clean separation between the I/O interface and concrete backends
> by separating generic I/O helpers from MMIO implementation.
>
> Introduce two traits to handle different access capabilities:
> - IoCapable<T> trait provides infallible I/O operations (read/write)
>   with compile-time bounds checking.
> - IoTryCapable<T> trait provides fallible I/O operations
>   (try_read/try_write) with runtime bounds checking.
> - The Io trait defines convenience accessors (read8/write8, try_read8/
>   try_write8, etc.) that forward to the corresponding IoCapable<T> or
>   IoTryCapable<T> implementations.

Does the runtime bound checking correlate to I/O sizes at all? I think it could
be that `IoCapable<ufoo>` gives you `try_readfoo` and then `IoCapable<ufoo> +
IoKnownSize` gives you `readfoo`?

For example, is there a case where a type would have `IoTryCapable<u16>`,
`IoTryCapable<u32>`, `IoCapable<u32>`, but not `IoCapable<u16>`?

>
> This separation allows backends to selectively implement only the operations
> they support. For example, PCI configuration space can implement IoCapable<T>
> for infallible operations while MMIO regions can implement both IoCapable<T>
> and IoTryCapable<T>.

I think try_ methods could still remain available even if there's a known size?

>
> Move the MMIO-specific logic into a dedicated Mmio<SIZE> type that
> implements Io and the corresponding `IoCapable<T>` and `IoTryCapable<T>` traits.
> Rename IoRaw to MmioRaw and update consumers to use the new types.
>
> Cc: Alexandre Courbot <acourbot@...dia.com>
> Cc: Alice Ryhl <aliceryhl@...gle.com>
> Cc: Bjorn Helgaas <helgaas@...nel.org>
> Cc: Gary Guo <gary@...yguo.net>
> Cc: Danilo Krummrich <dakr@...nel.org>
> Cc: John Hubbard <jhubbard@...dia.com>
> Signed-off-by: Zhi Wang <zhiw@...dia.com>
> ---
>  drivers/gpu/drm/tyr/regs.rs            |   1 +
>  drivers/gpu/nova-core/gsp/sequencer.rs |   5 +-
>  drivers/gpu/nova-core/regs/macros.rs   |  90 +++---
>  drivers/gpu/nova-core/vbios.rs         |   1 +
>  rust/kernel/devres.rs                  |  15 +-
>  rust/kernel/io.rs                      | 396 ++++++++++++++++++++-----
>  rust/kernel/io/mem.rs                  |  16 +-
>  rust/kernel/io/poll.rs                 |  16 +-
>  rust/kernel/pci/io.rs                  |  12 +-
>  samples/rust/rust_driver_pci.rs        |   1 +
>  10 files changed, 420 insertions(+), 133 deletions(-)
>
> diff --git a/drivers/gpu/drm/tyr/regs.rs b/drivers/gpu/drm/tyr/regs.rs
> index f46933aaa221..d3a541cb37c6 100644
> --- a/drivers/gpu/drm/tyr/regs.rs
> +++ b/drivers/gpu/drm/tyr/regs.rs
> @@ -11,6 +11,7 @@
>  use kernel::device::Bound;
>  use kernel::device::Device;
>  use kernel::devres::Devres;
> +use kernel::io::Io;
>  use kernel::prelude::*;
>  
>  use crate::driver::IoMem;
> diff --git a/drivers/gpu/nova-core/gsp/sequencer.rs b/drivers/gpu/nova-core/gsp/sequencer.rs
> index 2d0369c49092..862cf7f27143 100644
> --- a/drivers/gpu/nova-core/gsp/sequencer.rs
> +++ b/drivers/gpu/nova-core/gsp/sequencer.rs
> @@ -12,7 +12,10 @@
>  
>  use kernel::{
>      device,
> -    io::poll::read_poll_timeout,
> +    io::{
> +        poll::read_poll_timeout,
> +        Io, //
> +    },
>      prelude::*,
>      time::{
>          delay::fsleep,
> diff --git a/drivers/gpu/nova-core/regs/macros.rs b/drivers/gpu/nova-core/regs/macros.rs
> index fd1a815fa57d..6909ed8743bd 100644
> --- a/drivers/gpu/nova-core/regs/macros.rs
> +++ b/drivers/gpu/nova-core/regs/macros.rs
> @@ -369,16 +369,18 @@ impl $name {
>  
>              /// Read the register from its address in `io`.
>              #[inline(always)]
> -            pub(crate) fn read<const SIZE: usize, T>(io: &T) -> Self where
> -                T: ::core::ops::Deref<Target = ::kernel::io::Io<SIZE>>,
> +            pub(crate) fn read<T, I>(io: &T) -> Self where
> +                T: ::core::ops::Deref<Target = I>,

Normally it's quite usual to see `Deref` on the bounds, as auto-deref solves the
task. However, it won't work for generics hence I suppose it's why the bound
exist here in the first place.

Would it make sense for whatever the smart pointer is here to gain a forwarding
implementation of `Io` instead?

Also, I suppose we can still have `IoCapable: Io` this is just a single bound.

Best,
Gary

> +                I: ::kernel::io::Io + ::kernel::io::IoCapable<u32>,
>              {
>                  Self(io.read32($offset))
>              }
>  
> <snip>

Powered by blists - more mailing lists