[PATCH v2 0/4] i2c: provide and use i2c_adapter_dev()

[PATCH v2 0/4] i2c: provide and use i2c_adapter_dev()

[Bartosz Golaszewski]

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.

Other series address more generic problems - like printk helpers and
parent/of_node setting - but there are still some more specific
use-cases of drivers dereferencing the internal struct device of
i2c_adapters. We need to hide the fact that the device is embedded in
i2c_adapter before we can move it out so provide a helper that provides
the address of struct device without showing how it's stored and use it
in some drivers.

Link: [1] https://lore.kernel.org/all/20251106152330.11733-1-tzungbi@kernel.org/
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
Changes in v2:
- drop two patches that can be addressed in a different series
- rebase on top of v7.0-rc1
- collect tags
- Link to v1: https://lore.kernel.org/r/20251223-i2c-adapter-dev-wrapper-v1-0-bcf960a48fa9@oss.qualcomm.com

---
Bartosz Golaszewski (4):
      i2c: provide i2c_adapter_dev()
      i2c: piix4: use i2c_adapter_dev()
      i2c: amd-asf-plat: use i2c_adapter_dev()
      i2c: mv64xxx: use i2c_adapter_dev()

 drivers/i2c/busses/i2c-amd-asf-plat.c | 4 ++--
 drivers/i2c/busses/i2c-mv64xxx.c      | 4 ++--
 drivers/i2c/busses/i2c-piix4.c        | 6 +++---
 include/linux/i2c.h                   | 5 +++++
 4 files changed, 12 insertions(+), 7 deletions(-)
---
base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f
change-id: 20251222-i2c-adapter-dev-wrapper-c882660190a2

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

[PATCH v2 1/4] i2c: provide i2c_adapter_dev()

[Bartosz Golaszewski]

Provide a wrapper around the dereferencing of i2c_adapter::dev. Once we
convert i2c drivers to using it, it will be possible to finally move the
embedded struct device into a separate, revocable structure protected by
SRCU.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
 include/linux/i2c.h | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index 20fd41b51d5c85ee1665395c07345faafd8e2fca..b5f4db9417aca2e058c8be19d57d693339b6f9b9 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -768,6 +768,11 @@ struct i2c_adapter {
 };
 #define to_i2c_adapter(d) container_of(d, struct i2c_adapter, dev)
 
+static inline struct device *i2c_adapter_dev(struct i2c_adapter *adap)
+{
+	return &adap->dev;
+}
+
 static inline void *i2c_get_adapdata(const struct i2c_adapter *adap)
 {
 	return dev_get_drvdata(&adap->dev);

-- 
2.47.3

[PATCH v2 2/4] i2c: piix4: use i2c_adapter_dev()

[Bartosz Golaszewski]

Use i2c_adapter_dev() where applicable in order to avoid direct
dereferencing of struct device embedded within struct i2c_adapter.

Acked-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
 drivers/i2c/busses/i2c-piix4.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/busses/i2c-piix4.c b/drivers/i2c/busses/i2c-piix4.c
index 7b6a4e201be4a211c3b84e57fb7d8e0adc9895b7..2e36883f630ac50e4f4bb901bcca70b5230b984b 100644
--- a/drivers/i2c/busses/i2c-piix4.c
+++ b/drivers/i2c/busses/i2c-piix4.c
@@ -788,7 +788,7 @@ static s32 piix4_access_sb800(struct i2c_adapter *adap, u16 addr,
 	u8 prev_port;
 	int retval;
 
-	retval = piix4_sb800_region_request(&adap->dev, &adapdata->mmio_cfg);
+	retval = piix4_sb800_region_request(i2c_adapter_dev(adap), &adapdata->mmio_cfg);
 	if (retval)
 		return retval;
 
@@ -859,7 +859,7 @@ static s32 piix4_access_sb800(struct i2c_adapter *adap, u16 addr,
 		piix4_imc_wakeup();
 
 release:
-	piix4_sb800_region_release(&adap->dev, &adapdata->mmio_cfg);
+	piix4_sb800_region_release(i2c_adapter_dev(adap), &adapdata->mmio_cfg);
 	return retval;
 }
 
@@ -947,7 +947,7 @@ static int piix4_add_adapter(struct pci_dev *dev, unsigned short smba,
 	adap->dev.parent = &dev->dev;
 
 	if (has_acpi_companion(&dev->dev)) {
-		acpi_preset_companion(&adap->dev,
+		acpi_preset_companion(i2c_adapter_dev(adap),
 				      ACPI_COMPANION(&dev->dev),
 				      hw_port_nr);
 	}

-- 
2.47.3

[PATCH v2 3/4] i2c: amd-asf-plat: use i2c_adapter_dev()

[Bartosz Golaszewski]

Use i2c_adapter_dev() where applicable in order to avoid direct
dereferencing of struct device embedded within struct i2c_adapter.

Acked-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
 drivers/i2c/busses/i2c-amd-asf-plat.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-amd-asf-plat.c b/drivers/i2c/busses/i2c-amd-asf-plat.c
index ca45f0f233210a3b03a16c4a240012bd524fefb0..271b1b24417d06cc87733268c3191aea16fa1d83 100644
--- a/drivers/i2c/busses/i2c-amd-asf-plat.c
+++ b/drivers/i2c/busses/i2c-amd-asf-plat.c
@@ -209,7 +209,7 @@ static int amd_asf_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
 	asf_data[0] = dev_msgs->len;
 	memcpy(asf_data + 1, dev_msgs[0].buf, dev_msgs->len);
 
-	ret = piix4_sb800_region_request(&adap->dev, &dev->mmio_cfg);
+	ret = piix4_sb800_region_request(i2c_adapter_dev(adap), &dev->mmio_cfg);
 	if (ret)
 		return ret;
 
@@ -224,7 +224,7 @@ static int amd_asf_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
 	ret = amd_asf_access(adap, msgs->addr, msgs[0].buf[0], asf_data);
 	piix4_sb800_port_sel(prev_port, &dev->mmio_cfg);
 	amd_asf_setup_target(dev);
-	piix4_sb800_region_release(&adap->dev, &dev->mmio_cfg);
+	piix4_sb800_region_release(i2c_adapter_dev(adap), &dev->mmio_cfg);
 	return ret;
 }
 

-- 
2.47.3

[PATCH v2 4/4] i2c: mv64xxx: use i2c_adapter_dev()

[Bartosz Golaszewski]

Use i2c_adapter_dev() where applicable in order to avoid direct
dereferencing of struct device embedded within struct i2c_adapter.

Reviewed-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
 drivers/i2c/busses/i2c-mv64xxx.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
index 1acba628e16c3bd1dbf82c777162870cbe3815ef..7892793d2a1cabf3376efcec1d031c3d764f7731 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++ b/drivers/i2c/busses/i2c-mv64xxx.c
@@ -747,7 +747,7 @@ mv64xxx_i2c_xfer_core(struct i2c_adapter *adap, struct i2c_msg msgs[], int num)
 	struct mv64xxx_i2c_data *drv_data = i2c_get_adapdata(adap);
 	int rc, ret = num;
 
-	rc = pm_runtime_resume_and_get(&adap->dev);
+	rc = pm_runtime_resume_and_get(i2c_adapter_dev(adap));
 	if (rc)
 		return rc;
 
@@ -766,7 +766,7 @@ mv64xxx_i2c_xfer_core(struct i2c_adapter *adap, struct i2c_msg msgs[], int num)
 	drv_data->num_msgs = 0;
 	drv_data->msgs = NULL;
 
-	pm_runtime_put_autosuspend(&adap->dev);
+	pm_runtime_put_autosuspend(i2c_adapter_dev(adap));
 
 	return ret;
 }

-- 
2.47.3

Re: [PATCH v2 4/4] i2c: mv64xxx: use i2c_adapter_dev()

[Andy Shevchenko]

On Mon, Feb 23, 2026 at 10:02:52AM +0100, Bartosz Golaszewski wrote:
> Use i2c_adapter_dev() where applicable in order to avoid direct
> dereferencing of struct device embedded within struct i2c_adapter.

...

> mv64xxx_i2c_xfer_core(struct i2c_adapter *adap, struct i2c_msg msgs[], int num)

>  	struct mv64xxx_i2c_data *drv_data = i2c_get_adapdata(adap);
>  	int rc, ret = num;
>  
> -	rc = pm_runtime_resume_and_get(&adap->dev);
> +	rc = pm_runtime_resume_and_get(i2c_adapter_dev(adap));
>  	if (rc)
>  		return rc;

...

>  	drv_data->num_msgs = 0;
>  	drv_data->msgs = NULL;
>  
> -	pm_runtime_put_autosuspend(&adap->dev);
> +	pm_runtime_put_autosuspend(i2c_adapter_dev(adap));
>  
>  	return ret;

These two changes are in the same function, perhaps temporary variable
would be better?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 4/4] i2c: mv64xxx: use i2c_adapter_dev()

[Bartosz Golaszewski]

On Mon, Feb 23, 2026 at 10:14 AM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Mon, Feb 23, 2026 at 10:02:52AM +0100, Bartosz Golaszewski wrote:
> > Use i2c_adapter_dev() where applicable in order to avoid direct
> > dereferencing of struct device embedded within struct i2c_adapter.
>
> ...
>
> > mv64xxx_i2c_xfer_core(struct i2c_adapter *adap, struct i2c_msg msgs[], int num)
>
> >       struct mv64xxx_i2c_data *drv_data = i2c_get_adapdata(adap);
> >       int rc, ret = num;
> >
> > -     rc = pm_runtime_resume_and_get(&adap->dev);
> > +     rc = pm_runtime_resume_and_get(i2c_adapter_dev(adap));
> >       if (rc)
> >               return rc;
>
> ...
>
> >       drv_data->num_msgs = 0;
> >       drv_data->msgs = NULL;
> >
> > -     pm_runtime_put_autosuspend(&adap->dev);
> > +     pm_runtime_put_autosuspend(i2c_adapter_dev(adap));
> >
> >       return ret;
>
> These two changes are in the same function, perhaps temporary variable
> would be better?
>

If all else is fine, maybe let's do it in a follow-up?

Bart

Re: [PATCH v2 4/4] i2c: mv64xxx: use i2c_adapter_dev()

[Andy Shevchenko]

On Mon, Feb 23, 2026 at 10:23:40AM +0100, Bartosz Golaszewski wrote:
> On Mon, Feb 23, 2026 at 10:14 AM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Mon, Feb 23, 2026 at 10:02:52AM +0100, Bartosz Golaszewski wrote:

...

> > > mv64xxx_i2c_xfer_core(struct i2c_adapter *adap, struct i2c_msg msgs[], int num)
> >
> > >       struct mv64xxx_i2c_data *drv_data = i2c_get_adapdata(adap);
> > >       int rc, ret = num;
> > >
> > > -     rc = pm_runtime_resume_and_get(&adap->dev);
> > > +     rc = pm_runtime_resume_and_get(i2c_adapter_dev(adap));
> > >       if (rc)
> > >               return rc;

...

> > >       drv_data->num_msgs = 0;
> > >       drv_data->msgs = NULL;
> > >
> > > -     pm_runtime_put_autosuspend(&adap->dev);
> > > +     pm_runtime_put_autosuspend(i2c_adapter_dev(adap));
> > >
> > >       return ret;
> >
> > These two changes are in the same function, perhaps temporary variable
> > would be better?
> 
> If all else is fine, maybe let's do it in a follow-up?

I gave already a tag, this is just a nit-pick / side note, it doesn't need
to be addressed on its own.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 0/4] i2c: provide and use i2c_adapter_dev()

[Andy Shevchenko]

On Mon, Feb 23, 2026 at 10:02:48AM +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.
> 
> Other series address more generic problems - like printk helpers and
> parent/of_node setting - but there are still some more specific
> use-cases of drivers dereferencing the internal struct device of
> i2c_adapters. We need to hide the fact that the device is embedded in
> i2c_adapter before we can move it out so provide a helper that provides
> the address of struct device without showing how it's stored and use it
> in some drivers.

LGTM, and I follow the evolution of these two series for a while,
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
for this one.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 0/4] i2c: provide and use i2c_adapter_dev()

[Wolfram Sang]

On Mon, Feb 23, 2026 at 10:02:48AM +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.
> 
> Other series address more generic problems - like printk helpers and
> parent/of_node setting - but there are still some more specific
> use-cases of drivers dereferencing the internal struct device of
> i2c_adapters. We need to hide the fact that the device is embedded in
> i2c_adapter before we can move it out so provide a helper that provides
> the address of struct device without showing how it's stored and use it
> in some drivers.
> 
> Link: [1] https://lore.kernel.org/all/20251106152330.11733-1-tzungbi@kernel.org/
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

Also applied to for-current and squashed everything into one patch...

> ---
> Changes in v2:
> - drop two patches that can be addressed in a different series
> - rebase on top of v7.0-rc1

... but why didn't you rebase on top of rc1 + plus your previous series?
The merge conflict was easy to solve but kinda unnecessary in my
book...?