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.

This series addresses the usage of adap->dev in device printk() helpers
(dev_err() et al). It introduces a set of i2c-specific helpers and
starts using them across bus drivers. For now just 12 patches but I'll
keep on doing it if these get accepted. Once these get upstream for
v6.20/7.0, we'll be able to also start converting i2c drivers outside of
drivers/i2c/.

[1] https://lore.kernel.org/all/20251106152330.11733-1-tzungbi@kernel.org/

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
Bartosz Golaszewski (12):
      i2c: add i2c_adapter-specific printk helpers
      i2c: sun6i-p2wi: use i2c_adapter-specific printk helpers
      i2c: mlxbf: use i2c_adapter-specific printk helpers
      i2c: isch: use i2c_adapter-specific printk helpers
      i2c: ali1535: use i2c_adapter-specific printk helpers
      i2c: scmi: use i2c_adapter-specific printk helpers
      i2c: ali15x3: use i2c_adapter-specific printk helpers
      i2c: powermac: use i2c_adapter-specific printk helpers
      i2c: owl: use i2c_adapter-specific printk helpers
      i2c: nforce2: use i2c_adapter-specific printk helpers
      i2c: amd756: use i2c_adapter-specific printk helpers
      i2c: piix4: use i2c_adapter-specific printk helpers

 drivers/i2c/busses/i2c-ali1535.c    | 20 ++++++++++----------
 drivers/i2c/busses/i2c-ali15x3.c    | 20 ++++++++++----------
 drivers/i2c/busses/i2c-amd756.c     | 24 ++++++++++++------------
 drivers/i2c/busses/i2c-isch.c       | 32 ++++++++++++++++----------------
 drivers/i2c/busses/i2c-mlxbf.c      | 19 +++++++++----------
 drivers/i2c/busses/i2c-nforce2.c    | 14 +++++++-------
 drivers/i2c/busses/i2c-owl.c        |  4 ++--
 drivers/i2c/busses/i2c-piix4.c      |  8 ++++----
 drivers/i2c/busses/i2c-powermac.c   | 26 +++++++++++++-------------
 drivers/i2c/busses/i2c-scmi.c       |  6 +++---
 drivers/i2c/busses/i2c-sun6i-p2wi.c |  8 ++++----
 include/linux/i2c.h                 |  6 ++++++
 12 files changed, 96 insertions(+), 91 deletions(-)
---
base-commit: cc3aa43b44bdb43dfbac0fcb51c56594a11338a8
change-id: 20251222-i2c-printk-helpers-a69f4403ca70

Best regards,
-- 
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

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.

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.

> This series addresses the usage of adap->dev in device printk() helpers
> (dev_err() et al). It introduces a set of i2c-specific helpers and
> starts using them across bus drivers. For now just 12 patches but I'll
> keep on doing it if these get accepted. Once these get upstream for
> v6.20/7.0, we'll be able to also start converting i2c drivers outside of
> drivers/i2c/.

Same comment applies to the other two series you posted today.

Johan

On Tue, Dec 23, 2025 at 3:24 PM Johan Hovold <johan@kernel.org> 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

On Tue, Dec 23, 2025 at 04:11:08PM +0100, Bartosz Golaszewski wrote:
> On Tue, Dec 23, 2025 at 3:24 PM Johan Hovold <johan@kernel.org> 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.

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

> 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.

Johan

On Mon, Jan 19, 2026 at 12:03 PM Johan Hovold <johan@kernel.org> wrote:
>
> On Tue, Dec 23, 2025 at 04:11:08PM +0100, Bartosz Golaszewski wrote:
> > On Tue, Dec 23, 2025 at 3:24 PM Johan Hovold <johan@kernel.org> 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.
>
> Revocable, as presented in plumbers, is not going upstream.
>

Oh really? :)

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

> > 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

On Mon, Jan 19, 2026 at 12:17:49PM +0100, Bartosz Golaszewski wrote:
> On Mon, Jan 19, 2026 at 12:03 PM Johan Hovold <johan@kernel.org> wrote:
> >
> > On Tue, Dec 23, 2025 at 04:11:08PM +0100, Bartosz Golaszewski wrote:
> > > On Tue, Dec 23, 2025 at 3:24 PM Johan Hovold <johan@kernel.org> 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.
> >
> > Revocable, as presented in plumbers, is not going upstream.
> >
> 
> Oh really? :)
> 
> https://lore.kernel.org/all/2026011607-canister-catalyst-9fdd@gregkh/

Looks like a bad call as Laurent immediately pointed out:

	https://lore.kernel.org/all/20260116160454.GN30544@pendragon.ideasonboard.com/#t

Let's see where that goes.

> > > 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.

Of course it is, but you still don't have to rewrite world to post an
RFC where the problem can be discussed. A single driver is more than
enough.

> 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.

Magic helpers that hide what's really going on hurts readability. So
introducing them when they are not really needed should be avoided.

(But yeah, we have a problem with developers introducing esoteric
helpers while seemingly thinking all that matters is LOC count, and too
few people raising their voice against bad ideas.)

Johan

Johan, (and all future readers I have pointed to this mail)

> 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.

In general, this is correct. It does not apply here, though. I will
describe it in detail, so I can also point other people to this mail who
wonder about quite some intrusive changes to I2C core this year.

> We should not be making driver code less readable just to address some
> really niche corner cases like hot pluggable i2c controllers.

It is not a niche-case for hot-plugging. Hot-plugging (which still
should be avoided for I2C) just makes a subsystem-inherent lifecycle
problem more obvious. All of Bart's patch series basically prepare to
tackle this comment from the I2C core:

1805         /* wait until all references to the device are gone
1806          *
1807          * FIXME: This is old code and should ideally be replaced by an
1808          * alternative which results in decoupling the lifetime of the struct
1809          * device from the i2c_adapter, like spi or netdev do. Any solution
1810          * should be thoroughly tested with DEBUG_KOBJECT_RELEASE enabled!
1811          */
1812         init_completion(&adap->dev_released);
1813         device_unregister(&adap->dev);
1814         wait_for_completion(&adap->dev_released);

This has been in the I2C core since switching to the driver model and
the underlying problem applies to *all* i2c adapters. Simply unbind an
I2C controller while you still have a reference to its i2c-dev
counterpart and you are right in the problem space.

The problem is known for decades(!) and nobody dared to touch it, so
far. Even worse, the above pattern is not only present in I2C but also
other subsystems. Bart and I have been talking about potential solutions
for three years now. Bart brought in SRCU as a generic solution and at a
Plumbers 2024 session with many experienced maintainers present, it was
decided that this path is worth exploring. Greg suggested to try SRCU
with GPIO and I2C subsystems, and if this works well, we can try to
abstract it into something useful for other canidates as well. Now,
recently, the 'revocable' patch series was introduced which might be
helpful in our case. I am *extremly* thankful that Bartosz took the
initiative to prepare the I2C core for the SRCU approach so we can
research 'revocable'. I currently have zero time for implementing any of
this. At least, from now on, I can reserve time for discussing, testing,
reviewing patches.

It is also perfectly okay to work incrementally here, in my book. It is
such an intrusive change that we need to touch a lot of drivers in any
case. Yet, with the I2C core being a moving target, all the I2C drivers,
the 'revocable' patch series, and Linux in general, I think requesting a
fully complete patch series now is neither efficient nor maintainable.

Bartosz and I do have a plan. We are happy to discuss it with other
interested people, of course. Still, despite all our efforts it might be
a bumpy ride. Because it is such a crucial and deep-inside change to the
subsystem core. This is part of development, though. If something
breaks, we will fix or revert. The alternative is stagnation which I
don't want. The above code was fine back in the days but now we have
better mechanisms to handle lifecycle issues. And I really do not want
Linux to have lifecycle issues. Especially not ones we *know of*.

And who knows, maybe it is not a bumpy ride after all...

> But in any case, don't get ahead of things by posting changes that we
> most likely don't want in the end anyway.

We want helpers accessing that specific 'struct device', so we have
central place to implement access to a protected version of it.

Happy hacking,

   Wolfram

On Tue, Jan 13, 2026 at 11:03:16AM +0100, Wolfram Sang wrote:
> Johan, (and all future readers I have pointed to this mail)
> 
> > 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.
> 
> In general, this is correct. It does not apply here, though. I will
> describe it in detail, so I can also point other people to this mail who
> wonder about quite some intrusive changes to I2C core this year.
> 
> > We should not be making driver code less readable just to address some
> > really niche corner cases like hot pluggable i2c controllers.
> 
> It is not a niche-case for hot-plugging. Hot-plugging (which still
> should be avoided for I2C) just makes a subsystem-inherent lifecycle
> problem more obvious. All of Bart's patch series basically prepare to
> tackle this comment from the I2C core:
> 
> 1805         /* wait until all references to the device are gone
> 1806          *
> 1807          * FIXME: This is old code and should ideally be replaced by an
> 1808          * alternative which results in decoupling the lifetime of the struct
> 1809          * device from the i2c_adapter, like spi or netdev do. Any solution
> 1810          * should be thoroughly tested with DEBUG_KOBJECT_RELEASE enabled!
> 1811          */
> 1812         init_completion(&adap->dev_released);
> 1813         device_unregister(&adap->dev);
> 1814         wait_for_completion(&adap->dev_released);
> 
> This has been in the I2C core since switching to the driver model and
> the underlying problem applies to *all* i2c adapters. Simply unbind an
> I2C controller while you still have a reference to its i2c-dev
> counterpart and you are right in the problem space.

Unbinding drivers is even more of a corner case than hot-plugging i2c
controllers is since only root can do that.

Unloading modules is really just a development (debugging) tool so there
is a perfectly simple solution for any issues stemming from root
unbinding a driver while it's in use: don't do that then.

Furthermore, we even have mechanisms for preventing root from shooting
themselves in the foot with module refcounting and suppression of bind
attributes (which sometimes makes sense).

Issues stemming from unbinding drivers are not in themselves a
sufficient reason for making code harder to read and maintain or for
adding overhead to normal operation.

> The problem is known for decades(!) and nobody dared to touch it, so
> far. Even worse, the above pattern is not only present in I2C but also
> other subsystems. Bart and I have been talking about potential solutions
> for three years now. Bart brought in SRCU as a generic solution and at a
> Plumbers 2024 session with many experienced maintainers present, it was
> decided that this path is worth exploring. Greg suggested to try SRCU
> with GPIO and I2C subsystems, and if this works well, we can try to
> abstract it into something useful for other canidates as well. Now,
> recently, the 'revocable' patch series was introduced which might be
> helpful in our case.

Revocable is definitely not something we want for the very reasons I
outlined above (wrapping every access in code that's generally simply
not needed).

> It is also perfectly okay to work incrementally here, in my book. It is
> such an intrusive change that we need to touch a lot of drivers in any
> case. Yet, with the I2C core being a moving target, all the I2C drivers,
> the 'revocable' patch series, and Linux in general, I think requesting a
> fully complete patch series now is neither efficient nor maintainable.

Again, if the end result is undesirable, that's what we should be
focusing on and not "chipping away" in a direction were we most likely
do not want to go.

It doesn't have to be a complete series, an RFC reworking one driver is
more than enough to be able to judge the end result. And of course a
proper description of the problem you're trying to solve.

> Bartosz and I do have a plan. We are happy to discuss it with other
> interested people, of course. Still, despite all our efforts it might be
> a bumpy ride. Because it is such a crucial and deep-inside change to the
> subsystem core. This is part of development, though. If something
> breaks, we will fix or revert. The alternative is stagnation which I
> don't want. The above code was fine back in the days but now we have
> better mechanisms to handle lifecycle issues. And I really do not want
> Linux to have lifecycle issues. Especially not ones we *know of*.

There are lifetime issues in some subsystems related to user space
interfaces and hotplugging, but driver unbind is really not something
you need to worry about.

> > But in any case, don't get ahead of things by posting changes that we
> > most likely don't want in the end anyway.
> 
> We want helpers accessing that specific 'struct device', so we have
> central place to implement access to a protected version of it.

I really don't think we do. USB has been dealing with hotplugging since
forever without any of this. You need to keep some state around and
prevent new accesses until the last user is gone. That's about it.

Johan

Hi Bart,

> can be *revoked*. To that end we need to hide all dereferences of
> adap->dev in drivers.

I haven't actually tested the code yet (but will do so this week). But I
already want to feed back that I approve of the general concept of
abstracting away drivers access to the struct device by something we can
then convert to SRCU in a central place.

This mail is to discuss the timeline of these series. My preferred
solution is to aim for inclusion right after 7.0-rc1 is released. That
gives me enough time to test and you some more time to address review
comments. Bold wish, but maybe we can even get dependencies into 6.19
before (like the i2c_dbg rename for the saa7134 driver. Is there a patch
for it already?).

Does that work for you?

Happy hacking and thanks again for doing all this!

   Wolfram

On Tue, Jan 13, 2026 at 11:45 AM Wolfram Sang
<wsa+renesas@sang-engineering.com> wrote:
>
> Hi Bart,
>
> > can be *revoked*. To that end we need to hide all dereferences of
> > adap->dev in drivers.
>
> I haven't actually tested the code yet (but will do so this week). But I
> already want to feed back that I approve of the general concept of
> abstracting away drivers access to the struct device by something we can
> then convert to SRCU in a central place.
>
> This mail is to discuss the timeline of these series. My preferred
> solution is to aim for inclusion right after 7.0-rc1 is released. That
> gives me enough time to test and you some more time to address review
> comments. Bold wish, but maybe we can even get dependencies into 6.19
> before (like the i2c_dbg rename for the saa7134 driver. Is there a patch
> for it already?).
>

FYI: I think the road-map will look something like this: v7.1 will get
new interfaces and most controllers under drivers/i2c/ converted as
this can be done within your tree exclusively. For v7.2 (with the new
interfaces upstream) we can think about converting all i2c controller
drivers treewide to the new helpers. Once v7.2-rc1 is tagged, I would
try to remove struct device from struct i2c_adapter locally and send
it to autobuilders for testing. If that goes well, we could create
struct i2c_adapter_private or something like this and store its
address in struct i2c_adapter. This new struct would be controlled by
i2c core and contain struct device. With that out of the way, for v7.4
we could think about adding SRCU into the mix (possibly using the
then-available revocable).

If all goes well, we should be done in early 2027. :)

Bartosz

> FYI: I think the road-map will look something like this: v7.1 will get
> new interfaces and most controllers under drivers/i2c/ converted as
> this can be done within your tree exclusively. For v7.2 (with the new
> interfaces upstream) we can think about converting all i2c controller
> drivers treewide to the new helpers. Once v7.2-rc1 is tagged, I would
> try to remove struct device from struct i2c_adapter locally and send
> it to autobuilders for testing. If that goes well, we could create
> struct i2c_adapter_private or something like this and store its
> address in struct i2c_adapter. This new struct would be controlled by
> i2c core and contain struct device. With that out of the way, for v7.4
> we could think about adding SRCU into the mix (possibly using the
> then-available revocable).
> 
> If all goes well, we should be done in early 2027. :)

With this plan, what could possibly go wrong? :)

On Tue, Jan 13, 2026 at 11:45 AM Wolfram Sang
<wsa+renesas@sang-engineering.com> wrote:
>
> Hi Bart,
>
> > can be *revoked*. To that end we need to hide all dereferences of
> > adap->dev in drivers.
>
> I haven't actually tested the code yet (but will do so this week). But I
> already want to feed back that I approve of the general concept of
> abstracting away drivers access to the struct device by something we can
> then convert to SRCU in a central place.
>
> This mail is to discuss the timeline of these series. My preferred
> solution is to aim for inclusion right after 7.0-rc1 is released. That
> gives me enough time to test and you some more time to address review
> comments. Bold wish, but maybe we can even get dependencies into 6.19
> before (like the i2c_dbg rename for the saa7134 driver. Is there a patch
> for it already?).
>
> Does that work for you?

Yes, I agree it's too late to queue it for v7.0. I actually wanted to
rename my macro to i2c_debug() to avoid a conflict with saa7134 but
you're right, I may submit a patch for that instead for v7.0.

Bart

> Yes, I agree it's too late to queue it for v7.0. I actually wanted to
> rename my macro to i2c_debug() to avoid a conflict with saa7134 but
> you're right, I may submit a patch for that instead for v7.0.

Your choice. I think keeping 'i2c_dbg' is more consistent but the
dependency on media might not be worth it.

I set your patches to 'Deferred' in patchwork. Meaning that they will be
handled as agreed above.