Re: [PATCH 00/12] i2c: add and start using i2c_adapter-specific printk helpers
From: Bartosz Golaszewski <brgl@kernel.org>
Date: 2025-12-23 15:11:22
Also in:
linux-arm-kernel, linux-i2c, linux-sunxi, lkml
On Tue, Dec 23, 2025 at 3:24 PM Johan Hovold [off-list ref] wrote:
On Tue, Dec 23, 2025 at 11:02:22AM +0100, Bartosz Golaszewski wrote:quoted
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