On Wed, Mar 04, 2026 at 12:07:39PM +0100, Wolfram Sang wrote: > Hi Bart, hi Johan, > > > And I agree: doing the above would be even better but you'd need - for every > > driver - to move the i2c_adapter struct out of driver data and make it a > > pointer. That's in addition to providing new APIs and using them. I2C > > drivers > > are spread treewide. There's a reason why nobody attempted it for decades. > > I'm > > proposing something a bit less complex: allow drivers to free i2c_adapter at > > unbind but make i2c core keep a private, reference-counted structure for as > > long as it's needed. > > I am still with Bart, the above paragraph sums it up extremly well IMO. > I also recall that the outcome of the Plumbers session 2024 was "go for > it!". Nobody said the approach would be "fighting" the driver model. > There were a lot of experienced developers in the room.
I don't know what was said a conference some years ago or whether there was any misunderstanding on either side. What matters is what was posted. > > I'm frustrated because I'm spending time working on an actual solution. I've > > explained what I'm doing and what the end result will look like based on > > what > > works for GPIO (struct gpio_chip's lifetime is bound to device's "bound" > > state, > > struct gpio_device is refcounted, I want to mirror it with i2c_adapter and > > whatever we eventually call its refcounted counterpart - let's say: > > i2c_bus_device). > > I am super-happy and thankful that Bart volunteers to spend all this > time on fixing this decade old problem. I know this alone is not a > reason to accept a technically bad solution. But I think it isn't. I > think it is a viable approach to keep the churn and potential > regressions lower than a theoretically ideal solution which is nobody to > do anyways because you'd need to refactor drivers from the 90s in a > quite intrusive way. We've done bigger refactoring than this, and after a looking a this a bit further today, I don't think it's going to be that intrusive at all. Bartosz seems to agree that my suggestion to decouple the driver data from the i2c_adapter would be better, and I'm willing to do the job. Johan
