All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joel Fernandes <joelagnelf@nvidia.com>
To: Alexandre Courbot <acourbot@nvidia.com>
Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	dakr@kernel.org, Alistair Popple <apopple@nvidia.com>,
	Miguel Ojeda <ojeda@kernel.org>,
	Alex Gaynor <alex.gaynor@gmail.com>,
	Boqun Feng <boqun.feng@gmail.com>, Gary Guo <gary@garyguo.net>,
	bjorn3_gh@protonmail.com, Benno Lossin <lossin@kernel.org>,
	Andreas Hindborg <a.hindborg@kernel.org>,
	Alice Ryhl <aliceryhl@google.com>,
	Trevor Gross <tmgross@umich.edu>,
	David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	John Hubbard <jhubbard@nvidia.com>, Timur Tabi <ttabi@nvidia.com>,
	joel@joelfernandes.org, Elle Rhumsaa <elle@weathered-steel.dev>,
	Daniel Almeida <daniel.almeida@collabora.com>,
	nouveau@lists.freedesktop.org, rust-for-linux@vger.kernel.org
Subject: Re: [PATCH v2 3/4] nova-core: bitstruct: Add support for custom visiblity
Date: Tue, 9 Sep 2025 14:30:37 -0400	[thread overview]
Message-ID: <20250909183037.GA4154417@joelbox2> (raw)
In-Reply-To: <DCN3UXK0EQ1Q.KWGM7NKTCS13@nvidia.com>

On Mon, Sep 08, 2025 at 12:40:17PM +0900, Alexandre Courbot wrote:
> On Thu Sep 4, 2025 at 6:54 AM JST, Joel Fernandes wrote:
> > Add support for custom visiblity to allow for users to control visibility
> > of the structure and helpers.
> >
> > Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
> > ---
> >  drivers/gpu/nova-core/bitstruct.rs   | 46 ++++++++++++++--------------
> >  drivers/gpu/nova-core/regs/macros.rs | 16 +++++-----
> >  2 files changed, 31 insertions(+), 31 deletions(-)
> >
> > diff --git a/drivers/gpu/nova-core/bitstruct.rs b/drivers/gpu/nova-core/bitstruct.rs
> > index 068334c86981..1047c5c17e2d 100644
> > --- a/drivers/gpu/nova-core/bitstruct.rs
> > +++ b/drivers/gpu/nova-core/bitstruct.rs
> > @@ -9,7 +9,7 @@
> >  ///
> >  /// ```rust
> >  /// bitstruct! {
> > -///     struct ControlReg: u32 {
> > +///     pub struct ControlReg: u32 {
> >  ///         3:0       mode        as u8 ?=> Mode;
> >  ///         7:4       state       as u8 => State;
> >  ///     }
> 
> Maybe mention in the documentation that the field accessors are given
> the same visibility as the type - otherwise one might be led into
> thinking that they can specify visibility for individual fields as well
> (I'm wondering whether we might ever want that in the future?).

Sure, good idea, done.

> > @@ -34,21 +34,21 @@
> >  ///   and returns the result. This is useful with fields for which not all values are valid.
> >  macro_rules! bitstruct {
> >      // Main entry point - defines the bitfield struct with fields
> > -    (struct $name:ident : $storage:ty $(, $comment:literal)? { $($fields:tt)* }) => {
> > -        bitstruct!(@core $name $storage $(, $comment)? { $($fields)* });
> > +    ($vis:vis struct $name:ident : $storage:ty $(, $comment:literal)? { $($fields:tt)* }) => {
> > +        bitstruct!(@core $name $vis $storage $(, $comment)? { $($fields)* });
> >      };
> >  
> >      // All rules below are helpers.
> >  
> >      // Defines the wrapper `$name` type, as well as its relevant implementations (`Debug`,
> >      // `Default`, `BitOr`, and conversion to the value type) and field accessor methods.
> > -    (@core $name:ident $storage:ty $(, $comment:literal)? { $($fields:tt)* }) => {
> > +    (@core $name:ident $vis:vis $storage:ty $(, $comment:literal)? { $($fields:tt)* }) => {
> 
> Being very nitpicky here, but for consistency why not put `$vis` before
> `$name` since it is the order they are given by the caller?

Perfect comment, changed it.

> >          $(
> >          #[doc=$comment]
> >          )?
> >          #[repr(transparent)]
> >          #[derive(Clone, Copy)]
> > -        pub(crate) struct $name($storage);
> > +        $vis struct $name($vis $storage);
> 
> `$storage` should probably be kept private - we already have accessors
> for it, and the visibility parameter is for the outer type, not its
> internals.

Already done for next revision. Thanks,

thanks,

 - Joel


  parent reply	other threads:[~2025-10-06 20:46 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-03 21:54 [PATCH v2 0/4] Improve bitfield support in Rust Joel Fernandes
2025-09-03 21:54 ` [PATCH v2 1/4] nova-core: bitstruct: Move bitfield-specific code from register! into new macro Joel Fernandes
2025-09-08  3:12   ` Alexandre Courbot
2025-09-08 17:16     ` Joel Fernandes
2025-09-09  2:37       ` Alexandre Courbot
2025-09-09 18:55         ` Joel Fernandes
2025-09-10 13:25           ` Alexandre Courbot
2025-09-10 14:19             ` Joel Fernandes
2025-09-03 21:54 ` [PATCH v2 2/4] nova-core: bitstruct: Add support for different storage widths Joel Fernandes
2025-09-05 22:21   ` Elle Rhumsaa
2025-09-08  3:26   ` Alexandre Courbot
2025-09-09 18:26     ` Joel Fernandes
2025-09-03 21:54 ` [PATCH v2 3/4] nova-core: bitstruct: Add support for custom visiblity Joel Fernandes
2025-09-05 22:22   ` Elle Rhumsaa
2025-09-05 22:23   ` Elle Rhumsaa
2025-09-08  3:40   ` Alexandre Courbot
2025-09-08  3:46     ` Alexandre Courbot
2025-09-09 19:05       ` Joel Fernandes
2025-09-09 18:30     ` Joel Fernandes [this message]
2025-09-03 21:54 ` [PATCH v2 4/4] rust: Move register and bitstruct macros out of Nova Joel Fernandes
2025-09-03 21:56   ` Daniel Almeida
2025-09-03 21:57     ` Joel Fernandes
2025-09-05 22:24   ` Elle Rhumsaa
2025-09-07 18:14   ` Miguel Ojeda
2025-09-08 17:06     ` Joel Fernandes
2025-09-08 18:39       ` Miguel Ojeda
2025-09-08 20:40         ` Joel Fernandes
2025-09-08 21:24         ` Joel Fernandes
2025-09-08  3:52   ` Alexandre Courbot
2025-09-08 20:14     ` Joel Fernandes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250909183037.GA4154417@joelbox2 \
    --to=joelagnelf@nvidia.com \
    --cc=a.hindborg@kernel.org \
    --cc=acourbot@nvidia.com \
    --cc=airlied@gmail.com \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=apopple@nvidia.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=dakr@kernel.org \
    --cc=daniel.almeida@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=elle@weathered-steel.dev \
    --cc=gary@garyguo.net \
    --cc=jhubbard@nvidia.com \
    --cc=joel@joelfernandes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=nouveau@lists.freedesktop.org \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=simona@ffwll.ch \
    --cc=tmgross@umich.edu \
    --cc=ttabi@nvidia.com \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.