Re: [PATCH v10 8/9] platform/chrome: Protect cros_ec_device lifecycle with revocable

[Tzung-Bi Shih]

On Fri, May 08, 2026 at 08:53:09AM -0300, Jason Gunthorpe wrote:
> On Fri, May 08, 2026 at 06:54:47PM +0800, Tzung-Bi Shih wrote:
> >  struct cros_ec_device *cros_ec_device_alloc(struct device *dev)
> > @@ -47,6 +49,15 @@ struct cros_ec_device *cros_ec_device_alloc(struct device *dev)
> >  	if (!ec_dev)
> >  		return NULL;
> >  
> > +	ec_dev->its_rev = revocable_alloc(ec_dev);
> > +	if (!ec_dev->its_rev)
> > +		return NULL;
> > +	/*
> > +	 * Drop the extra reference for the caller as the caller is the
> > +	 * resource provider.
> > +	 */
> > +	revocable_put(ec_dev->its_rev);
> > +
> >  	ec_dev->din_size = sizeof(struct ec_host_response) +
> >  			   sizeof(struct ec_response_get_protocol_info) +
> >  			   EC_MAX_RESPONSE_OVERHEAD;
> 
> FWIW I am still very much against seeing any revokable concept used
> *between two drivers*. That will turn the kernel's lifetime model into
> spaghetti code.
> 
> Your other series where you only have to change
> drivers/platform/chrome/cros_ec_chardev.c just confirms how wrong this
> approach is.
> 
> Given you say this is such a bug I think you really should be sending
> a series that is patches 5 through 7 from the other series and a
> simple rwsem instead of misc_deregister_sync() to deal with this bug
> ASAP. No need to complicate a simple bug fix in a driver with all
> these core changes.

Apologies for missing this suggestion.

For "patches 5 through 7 from the other series" I guess you're referring:
- https://lore.kernel.org/all/20260427134659.95181-6-tzungbi@xxxxxxxxxx
- https://lore.kernel.org/all/20260427134659.95181-7-tzungbi@xxxxxxxxxx
- https://lore.kernel.org/all/20260427134659.95181-8-tzungbi@xxxxxxxxxx

Could you provide a bit more detail on the rwsem approach?  I'm not
entirely clear on what data or operations the rwsem would be protecting.