Re: [PATCH 00/12] i2c: add and start using i2c_adapter-specific printk helpers

On Mon, Jan 19, 2026 at 12:03 PM Johan Hovold [off-list ref] wrote:

On Tue, Dec 23, 2025 at 04:11:08PM +0100, Bartosz Golaszewski wrote:

quoted

On Tue, Dec 23, 2025 at 3:24 PM Johan Hovold [off-list ref] wrote:

quoted

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.

Revocable, as presented in plumbers, is not going upstream.

Oh really? :)

https://lore.kernel.org/all/2026011607-canister-catalyst-9fdd@gregkh/ (local)

quoted

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.

You can post an RFC converting one driver with a proper description of
the problem you're trying to solve.

It's not a one-driver problem. It's a subsystem-wide problem requiring
a subsystem-wide solution. Wolfram explained it really well in his
summary, I'm not going to repeat it here.

I also don't agree that i2c-specific helpers make code harder to read.
Is device_set_node() harder to read than

dev->fwnode = fwnode;
dev->of_node = to_of_node(fwnode);

?

Even if you answer yes - it at least helps hide the implementation
details of the OF layer where fwnode-level is preferred. We do it all
the time in the kernel. This kind of helpers allows easier transitions
when some implementation detail needs to change - as is the case here.

Bartosz