On Tue, Dec 23, 2025 at 3:24 PM Johan Hovold <[email protected]> wrote: > > On Tue, Dec 23, 2025 at 11:02:22AM +0100, Bartosz Golaszewski wrote: > > It's been another year of discussing the object life-time problems at > > conferences. I2C is one of the offenders and its problems are more > > complex than those of some other subsystems. It seems the revocable[1] > > API may make its way into the kernel this year but even with it in > > place, I2C won't be able to use it as there's currently nothing to > > *revoke*. The struct device is embedded within the i2c_adapter struct > > whose lifetime is tied to the provider device being bound to its driver. > > > > Fixing this won't be fast and easy but nothing's going to happen if we > > don't start chipping away at it. The ultimate goal in order to be able > > to use an SRCU-based solution (revocable or otherwise) is to convert the > > embedded struct device in struct i2c_adapter into an __rcu pointer that > > can be *revoked*. To that end we need to hide all dereferences of > > adap->dev in drivers. > > No, this is not the way to do it. You start with designing and showing > what the end result will look like *before* you start rewriting world > like you are doing here. >
The paragraph you're commenting under explains exactly what I propose to do: move struct device out of struct i2c_adapter and protect the pointer storing its address with SRCU. This is a well-known design that's being generalized to a common "revocable" API which will possibly be available upstream by the time we're ready to use it. You know I can't possibly *show* the end result in a single series because - as the paragraph before explains - we need to first hide all direct dereferences of struct device in struct i2c_adapter behind dedicated interfaces so that we when do the conversion, it'll affect only a limited number of places. It can't realistically be done at once. > We should not be making driver code less readable just to address some > really niche corner cases like hot pluggable i2c controllers. > > But in any case, don't get ahead of things by posting changes that we > most likely don't want in the end anyway. > The changes I sent are the result of another discussion with Wolfram at LPC so I'll definitely wait for his take on it before dropping anything. Bartosz
