On Mon, Sep 08, 2025 at 12:46:57PM +0900, Alexandre Courbot wrote:
> On Mon Sep 8, 2025 at 12:40 PM JST, 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 <joelagn...@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?).
>
> Answering my own question: it could be useful! One example is
> nova-core's `NV_PFALCON_FALCON_HWCFG2::mem_scrubbing` field. It turns
> into `0` when scrubbing is completed, which is misleading. So to paliate
> that we introduced a `mem_scrubbing_done` method that works as we want,
> but the `mem_scrubbing` accessors are still present and can be called by
> driver code. Making them private would force all callers to use
> `mem_scrubbing_done`.
Sounds reasonable. I actually ran into this myself for the inverted 'valid'
bit in page directory entries in Nova. So what I ended up doing is calling it
valid_inverted. Though, agreed privatizing it is a bit better than calling it
mem_scrubbing_inverted, but that is another option if we don't want to
compilicate the macro more.
> Another related feature would be a way to make some fields read-only or
> write-only through an optional parameter.
Agreed, that would be useful.
> I'm just mentioning these for the record; I'm not suggesting they need
> to be done for the current series. :)
Sounds good. :)
thanks,
- Joel
