Re: [PATCH v8 1/3] revocable: Revocable resource management

[Tzung-Bi Shih]

On Mon, Feb 16, 2026 at 08:37:50AM -0800, Bartosz Golaszewski wrote:
> On Fri, 13 Feb 2026 10:23:05 +0100, Tzung-Bi Shih <tzungbi@xxxxxxxxxx> said:
> > diff --git a/include/linux/revocable.h b/include/linux/revocable.h
> > +
> 
> [snip]
> 
> > +/**
> > + * struct revocable_consumer - A handle for resource consumer.
> > + * @rp: The pointer of resource provider.
> > + * @idx: The index for the SRCU critical section.
> > + */
> > +struct revocable_consumer {
> > +	struct revocable *rp;
> > +	int idx;
> > +};
> > +
> > +void revocable_get(struct revocable *rp);
> > +void revocable_put(struct revocable *rp);
> > +struct revocable *revocable_alloc(void *res);
> 
> Is there any reason why we couldn't do:
> 
> int revocable_init(struct revocable *rp, void *res);
> 
> and then:
> 
> struct gpio_device {
> 	struct revocable rp;
> 	...
> };
> 
> revocable_init(&gdev->rp, gc);
> 
> ? It would be functionally equivalent to what we're doing now in GPIO.

In the case of struct gpio_device, it is possible to embed struct revocable
directly.  Since the lifetime of gpio_device matches the revocable object,
the reference counting mechanism in struct revocable is redundant in this
specific instance.

However, the design allows for cases where there is no persistent parent
object.  For example, a revocable handle may exist in the dev-managed
context of a kernel thread.  In such cases, consumers are required to hold
a reference to the handle.