Re: [PATCH 1/3] lib: Add ref_proxy module

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

On Thu, Aug 14, 2025 at 12:03:11PM +0200, Greg KH wrote:
> On Thu, Aug 14, 2025 at 09:10:18AM +0000, Tzung-Bi Shih wrote:
> > +/**
> > + * devm_ref_proxy_provider_alloc() - Dev-managed ref_proxy_provider_alloc().
> > + * @dev: The device.
> > + * @ref: The pointer of resource.
> > + *
> > + * This holds an initial refcount to the struct.
> > + *
> > + * Return: The pointer of struct ref_proxy_provider.  NULL on errors.
> > + */
> > +struct ref_proxy_provider *devm_ref_proxy_provider_alloc(struct device *dev,
> > +							 void *ref)
> > +{
> > +	struct ref_proxy_provider *rpp;
> > +
> > +	rpp = ref_proxy_provider_alloc(ref);
> > +	if (rpp)
> > +		if (devm_add_action_or_reset(dev, devm_ref_proxy_provider_free,
> > +					     rpp))
> > +			return NULL;
> > +
> > +	return rpp;
> > +}
> > +EXPORT_SYMBOL(devm_ref_proxy_provider_alloc);
> 
> Do we really need a devm version?  That feels odd as this should be
> doing almost the same thing that devm does, right?  How do they interact
> properly?

ref_proxy is similar to devm.  The key difference is their lifetime: a
devm resource is freed when the device detaches, whereas a
ref_proxy_provider persists as long as it has references from ref_proxy.

Since the resource in my use case is provided by the device, it's more
intuitive to tie the resource's lifetime to the device's.

This devm helper further simplifies the provider code.  Otherwise, the
provider needs to call ref_proxy_provider_free() at its error handling
paths or device .remove() callback.

> And do you have a selftest for this thing anywhere?

Will address all review comments and add tests using kselftest and/or KUnit
in the next version.