Re: [PATCH 4/8] rust: io: register: use path fragment in relative internal rules

"Alexandre Courbot" <[email protected]>
Newsgroups org.kernel.vger.rust-for-linux,dev.linux.lists.driver-core,dev.linux.lists.nova-gpu,org.freedesktop.lists.dri-devel,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
On Tue Jul 21, 2026 at 4:00 AM PDT, Alexandre Courbot wrote:
> The base of a relative register is a type, but its current fragment is
> `ident`. This prevents referencing bases that are e.g. declared in
> another module.
>
> The `path` fragment is more accurate to represent relative register
> bases, but bases are currently followed by `+`, which is forbidden right
> after `path` fragments.
>
> `:` is another separator that can carry the desired semantics, and is
> legal to follow a `path` fragment. Thus, replace the `+` separator with
> `:` in the internal rules so we can change the fragment for relative
> register bases to `path`.
>
> The public rule still uses the `+` notation and an `ident` fragment, so
> there is no user-facing change yet; only a minor replumbing of the
> internals to better support the new syntax introduced in the next patch.
>
> Signed-off-by: Alexandre Courbot <[email protected]>
> ---
>  rust/kernel/io/register.rs | 23 ++++++++++++-----------
>  1 file changed, 12 insertions(+), 11 deletions(-)
>
> diff --git a/rust/kernel/io/register.rs b/rust/kernel/io/register.rs
> index 1e0e23e4233f..62208f52752a 100644
> --- a/rust/kernel/io/register.rs
> +++ b/rust/kernel/io/register.rs
> @@ -816,8 +816,8 @@ macro_rules! register {
>          $(
>          $crate::register!(
>              @reg $(#[$attr])* $vis $name ($storage) $([$size $(, stride = $stride)?])?
> -                $(@ $($base +)? $offset)?
> -                $(=> $alias $(+ $alias_offset)? $([$alias_idx])? )?
> +                $(@ $($base :)? $offset)?
> +                $(=> $alias $(: $alias_offset)? $([$alias_idx])? )?
>              { $($fields)* }
>          );
>          )*
> @@ -850,7 +850,7 @@ macro_rules! register {
>  
>      // Creates a register at a relative offset from a base address provider.
>      (
> -        @reg $(#[$attr:meta])* $vis:vis $name:ident ($storage:ty) @ $base:ident + $offset:literal
> +        @reg $(#[$attr:meta])* $vis:vis $name:ident ($storage:ty) @ $base:path : $offset:literal
>              { $($fields:tt)* }
>      ) => {
>          $crate::register!(@bitfield $(#[$attr])* $vis struct $name($storage) { $($fields)* });
> @@ -860,7 +860,7 @@ macro_rules! register {
>  
>      // Creates an alias register of relative offset register `alias` with its own fields.
>      (
> -        @reg $(#[$attr:meta])* $vis:vis $name:ident ($storage:ty) => $base:ident + $alias:path
> +        @reg $(#[$attr:meta])* $vis:vis $name:ident ($storage:ty) => $base:path : $alias:path
>              { $($fields:tt)* }
>      ) => {
>          $crate::register!(@bitfield $(#[$attr])* $vis struct $name($storage) { $($fields)* });
> @@ -916,7 +916,7 @@ macro_rules! register {
>      (
>          @reg $(#[$attr:meta])* $vis:vis $name:ident ($storage:ty)
>              [ $size:expr, stride = $stride:expr ]
> -            @ $base:ident + $offset:literal { $($fields:tt)* }
> +            @ $base:path : $offset:literal { $($fields:tt)* }
>      ) => {
>          $crate::build_assert::static_assert!(::core::mem::size_of::<$storage>() <= $stride);
>  
> @@ -928,11 +928,12 @@ macro_rules! register {
>      // Shortcut for contiguous array of relative registers (stride == size of element).
>      (
>          @reg $(#[$attr:meta])* $vis:vis $name:ident ($storage:ty) [ $size:expr ]
> -            @ $base:ident + $offset:literal { $($fields:tt)* }
> +            @ $base:path : $offset:literal { $($fields:tt)* }
>      ) => {
>          $crate::register!(
> -            $(#[$attr])* $vis $name($storage) [ $size, stride = ::core::mem::size_of::<$storage>() ]
> -                @ $base + $offset { $($fields)* }
> +            @reg $(#[$attr])* $vis $name($storage)

Mmm looks like this `@reg` should also have been added by the first patch.
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.