Re: [PATCH 0/3] Revert "revocable: Revocable resource management"

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

On Thu, Jan 29, 2026 at 10:28:36AM -0400, Jason Gunthorpe wrote:
> On Thu, Jan 29, 2026 at 08:50:30AM -0500, Bartosz Golaszewski wrote:
> 
> > and the ownership of that data belongs to the driver. There's no way we could
> > address it now so the next best thing is to work towards moving the ownership
> 
> Think positive!
> 
> If this is common:
> 
>  struct my_i2c_drv_data *data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> 
> Then change it into
> 
>  struct my_i2c_drv_data *data = devm_i2c_adaptor_alloc(struct my_i2c_drv_data, adap);
> 
> With Coccinelle or sed.
> 
> Audit all the drivers to catch the stragglers.
> 
> Now you have a refcount. Look at how fwctl_alloc_device() works to
> understand the pattern.
> 
> Kernel community has done far harder transformations than this :)
> 
> Sure it is 200 drivers, I would ask Coccinelle team for help.

We rewrote the device model between v2.4 and v2.6 (and by "we" I mostly
mean kudos to Greg for that work, as well as to all the people who
worked with him who I don't know about). That impacted *all* the
drivers. We can do this if we want to.

> Here is how I would approach it.
> 
> First, grep to find all the candidates:
> 
> $ git grep -E '^\s+struct i2c_adapter[^*]*;'
> 
> Get a kernel built with all those compiling and get a clangd database
> going. Make a list of all possible candidate files with grep.
> 
> AI tells me (and AI is never right about Coccinelle sadly) that you
> could use this:
> 
> // C1: Find any struct that has a member of type "struct i2c_adapter"
> @ has_i2c_adapter_struct @
> type S;
> @@
> struct S {
>   ...
>   struct i2c_adapter;
>   ...
> };
> 
> // C2: Replace sizeof(...) with fixme_sizeof(...)
> @ sizeof_i2c_adapter_struct depends on has_i2c_adapter_struct @
> type has_i2c_adapter_struct.S;
> @@
> - sizeof(struct S)
> + fixme_sizeof(struct S)
> 
> The idea being the only reason to do sizeof(S) is for an allocation
> and we want to find every allocation of a wrapper struct to fix it.
> 
> Now you have an index of all lines that need touching.
> 
> Look for common patterns, use Coccinelle or sed to make bulk
> replacements. Group patches of all similar transformations. Sweep
> through with grep to clean anything not caught. Probably there will be
> a couple drivers doing something utterly insane, meditate on them and
> clean them up by hand (this is what clangd is helpful for)
> 
> Betcha you can get through it in a few hours!
> 
> Jason

-- 
Regards,

Laurent Pinchart