linux.git/rust/kernel/io/register.rs, branch v7.3-rc2

rust: io: register: use path fragment for alias destination

2026-08-03T20:30:32+00:00

The destination of an alias is always another register, i.e. a `struct`
type. Replace the `ident` fragment with a `path` one in the internal
rules: `path` is more accurate, and allows referencing registers using a
qualified path instead of only identifiers visible from the current
module.

This covers all aliases, except the relative register ones which are to
be removed soon.

The public rule cannot be updated yet because a `+` can still be matched
after the alias; add a TODO item to update it after relative registers
are removed.

Signed-off-by: Alexandre Courbot 
Link: https://patch.msgid.link/20260724-registers_fix-v2-3-a0fb58b02185@nvidia.com
Signed-off-by: Danilo Krummrich

rust: io: register: remove unused rule arguments

2026-08-03T20:30:32+00:00

A few arguments passed to internal rules are never used and just add
unneeded complexity. Remove them to simplify the rules a bit.

Signed-off-by: Alexandre Courbot 
Link: https://patch.msgid.link/20260724-registers_fix-v2-2-a0fb58b02185@nvidia.com
Signed-off-by: Danilo Krummrich

rust: io: register: dispatch shortcut rules internally

2026-08-03T20:30:32+00:00

A couple of shortcut rules redispatch an already normalized declaration
through the public register! entry point. This is unneeded - the public
rule should only be invoked by users.

Dispatch directly to the appropriate internal @reg rule instead.

Signed-off-by: Alexandre Courbot 
Reviewed-by: Gary Guo 
Link: https://patch.msgid.link/20260724-registers_fix-v2-1-a0fb58b02185@nvidia.com
Signed-off-by: Danilo Krummrich

Merge patch series "rust: I/O type generalization and projection"

2026-07-13T21:50:39+00:00

Gary Guo says:

This series presents a major rework of I/O types, as a summary:

- Make I/O regions typed. The existing untyped region still exists
with a dynamically sized `Region` type.

- Create I/O view types to represent subregion of a full I/O region mapped.
A projection macro is added to allow safely create such subviews.

- Split I/O traits, make I/O views play a central role, avoid
duplicate monomorphization and less `unsafe` code.

- Add a `SysMem` backend, and make `Coherent` implement `Io`.

- Add copying methods (memcpy_{from,to}io and friends).

This series generalize `Mmio` type from just an untyped region to typed
representations (so `MmioRaw` is `__iomem *T`). This allows us to remove
the `IoKnownSize` trait; the information is sourced from just the pointer
from the `KnownSize` trait instead.

Building on top of that, `Mmio` and `ConfigSpace` have been converted to
typed views of I/O regions rather than just a big chunk of untyped I/O
memory. These changes made it possible to implement `Io` trait for
`Coherent`.

Shared system memory, `SysMem` is also added to the series, given it
similarity in implementation compared to `Coherent`. In fact, the series
use `SysMem` to implement `Coherent`'s I/O methods.

Built on these generalization, this series add `io_project!()`.
`io_project!()` performs a safe way to project a bigger view to a small
subviews, and some Nova code has been converted in this series to
demonstrate cleanups possible with this addition.

New `io_read!()`, `io_write!()` has been added that supersedes
`dma_read!()`, `dma_write!()` macro. Although, they work for primitives
only (to be exact, types that the backend is `IoCapable` of).
One feature that was lost from the old `dma_read!()` and `dma_write!()`
series was the ability to read/write a large structs. However, the
semantics was unclear to begin with, as there was no guarantee about their
atomicity even for structs that were small enough to fit in u32.

Suggested-by: Danilo Krummrich
Link: https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/Generic.20I.2FO.20backends/near/571198078
Link: https://patch.msgid.link/20260706-io_projection-v6-0-72cd5d055d54@garyguo.net
Signed-off-by: Danilo Krummrich

rust: io: implement `Mmio` as view type

2026-07-11T15:59:32+00:00

Implement `Mmio` as view type and convert `RelaxedMmio` to view type as
well. I/O implementations of `MmioOwned` are changed to delegate to the
`Mmio` view type.

All existing users of `MmioOwned` in the documentation which do not
actually reflect the owning semantics is converted.

Reviewed-by: Alexandre Courbot 
Signed-off-by: Gary Guo 
Tested-by: Daniel Almeida 
Reviewed-by: Daniel Almeida 
Link: https://patch.msgid.link/20260706-io_projection-v6-7-72cd5d055d54@garyguo.net
Signed-off-by: Danilo Krummrich

rust: io: rename `Mmio` to `MmioOwned`

2026-07-11T15:59:32+00:00

Most users would more commonly reach out to a view of `Mmio` rather than an
owned instance of `Mmio`. Only implementor of `Io` like `Bar` or `IoMem`
would need the owned version. Thus, rename `Mmio` to `MmioOwned` so that
the name `Mmio` can be used for the view type instead.

Reviewed-by: Alexandre Courbot 
Signed-off-by: Gary Guo 
Reviewed-by: Daniel Almeida 
Suggested-by: Danilo Krummrich 
Link: https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/Generic.20I.2FO.20backends/near/571198078
Link: https://patch.msgid.link/20260706-io_projection-v6-6-72cd5d055d54@garyguo.net
Signed-off-by: Danilo Krummrich

rust: io: restrict untyped IO access and `register!` to `Region`

2026-07-11T15:59:31+00:00

Currently the `Io` trait exposes a bunch of untyped IO accesses, but if the
`Io` region itself is typed, then it might be weird to have

    let io: Mmio = /* ... */;
    io.read8(1);

while not unsound, it is surely strange. Thus, restrict the untyped methods
and also the register macro to `Region` type only.

Implement it by adding a generic type to `IoLoc` indicating allowed base
types. This also paves the way to add typed register blocks in the future;
for example, we could use this mechanism to block driver A's `register!()`
generated macro from being used on driver B's MMIO. The same mechanism
could be used for relative IO registers. These are future opportunities,
and for now restrict everything to require `IoLoc, _>`.

Suggested-by: Alexandre Courbot 
Link: https://lore.kernel.org/rust-for-linux/DHLB3RO3OSF5.2R7F27U99BKLN@nvidia.com/
Reviewed-by: Alexandre Courbot 
Signed-off-by: Gary Guo 
Reviewed-by: Daniel Almeida 
Link: https://patch.msgid.link/20260706-io_projection-v6-3-72cd5d055d54@garyguo.net
Signed-off-by: Danilo Krummrich

rust: io: fix example in `register!` macro

2026-07-03T21:22:19+00:00

In this example, an u32 register is split in two u8 in big-endian order,
but the high byte is actually defined as taking nine bits instead of
eight.

This is completely inconsequential, as I expect most users will just
copy the bit ranges from their datasheets, but it doesn’t hurt to fix
that typo.

Signed-off-by: Link Mauve 
Acked-by: Alexandre Courbot 
Reviewed-by: Gary Guo 
Link: https://patch.msgid.link/20260701160357.29031-1-linkmauve@linkmauve.fr
Signed-off-by: Danilo Krummrich

rust: make `build_assert` module the home of related macros

2026-06-10T07:07:13+00:00

Given the macro scoping rules, all macros are rendered twice, in the
module and in the top-level of kernel crate.

Add `#[doc(hidden)]` to the macro definition and `#[doc(inline)]` to the
re-export inside `build_assert` module so the top-level items are hidden.

[ Sadly, because the definition is hidden, `rustdoc` decides to not list
  them as re-exports in the `prelude` page anymore, even if we refer to
  the not-actually-hidden item.

    - Miguel ]

Acked-by: Danilo Krummrich 
Reviewed-by: Alice Ryhl 
Acked-by: Alexandre Courbot 
Acked-by: FUJITA Tomonori 
Acked-by: Boqun Feng 
Signed-off-by: Gary Guo 
Link: https://patch.msgid.link/20260609142637.373347-1-gary@kernel.org
[ Kept a single declaration in the prelude, and reworded since they
  already had `no_inline`. Removed other imports from `predefine` since
  we now use the prelude. - Miguel ]
Signed-off-by: Miguel Ojeda

rust: io: use the `bitfield!` macro in `register!`

2026-06-09T02:13:16+00:00

Replace the local bitfield rules by the equivalent invocation of the
`bitfield!` macro.

No functional change should be introduced as the `bitfield!` macro has
been extracted from the rules of `register!`.

Acked-by: Yury Norov 
Acked-by: Danilo Krummrich 
Signed-off-by: Alexandre Courbot 
Reviewed-by: Yury Norov 
Link: https://patch.msgid.link/20260606-bitfield-v5-3-b92188820914@nvidia.com
Signed-off-by: Miguel Ojeda