Re: [PATCH v14 5/5] reset: Leverage revocable for accessing struct reset_controller_dev

[Tzung-Bi Shih <tzungbi@kernel.org>]

On Thu, Oct 15, 2026 at 05:49:11AM -0400, Bartosz Golaszewski wrote:
> > diff --git a/drivers/reset/core.c b/drivers/reset/core.c
> > index 38e189d04d09..788a235c3965 100644
> > --- a/drivers/reset/core.c
> > +++ b/drivers/reset/core.c
> > @@ -24,8 +24,8 @@
> >  #include <linux/property.h>
> >  #include <linux/reset.h>
> >  #include <linux/reset-controller.h>
> > +#include <linux/revocable.h>
> >  #include <linux/slab.h>
> > -#include <linux/srcu.h>
> >
> >  static DEFINE_MUTEX(reset_list_mutex);
> >  static LIST_HEAD(reset_controller_list);
> > @@ -37,9 +37,7 @@ static DEFINE_IDA(reset_gpio_ida);
> >
> >  /**
> >   * struct reset_control - a reset control
> > - * @rcdev: a pointer to the reset controller device
> > - *         this reset control belongs to
> > - * @srcu: protects the rcdev pointer from removal during consumer access
> > + * @rev: revocable handle for accessing the reset controller device
> 
> Please call it "revocable". The name "rev" does not indicate what it is at all.
> Same elsewhere if you call it the same.

Ack, I initially used "rev" to keep the lines shorter with the revocable
APIs, but "rev" alone can indeed be confusing.  On the other hand, I feel
"revocable" is a bit verbose and doesn't indicate which target object it
protects.  How about calling it "rcdev_rev"?

> Otherwise looks good to me and nicely shrinks the code! We still don't know
> what the fate of that series will be though, right?

Yes, that is also what I would like to check before sending v15.

Greg, Danilo, Rafael, Johan,

Since the revert in February, the API and lifetime model have been
redesigned, and the series now has concrete in-kernel users for both
embedded allocation (gpiolib in patch 3) and dynamic allocation (reset in
patch 5).

Do you think this series is heading in a direction that driver-core can
accept, or do you still have fundamental concerns with the approach?  I
would appreciate your thoughts on whether we should continue working on
this series.