[PATCH v1 0/2] i2c: designware: Clean up MODEL_* definitions

[PATCH v1 0/2] i2c: designware: Clean up MODEL_* definitions

[Andy Shevchenko]

The current way of recognizing models is not scalable and in most of the cases
just a replacement of well established device_is_compatible() approach.

For now take the low-hanging fruits and partially clean up those MODEL_*
definitions.

Andy Shevchenko (2):
  i2c: designware: Remove not-going-to-be-supported code for Baikal SoC
  i2c: designware: Use device_is_compatible() instead of custom approach

 drivers/i2c/busses/Kconfig                  |  1 -
 drivers/i2c/busses/i2c-designware-common.c  |  6 +-
 drivers/i2c/busses/i2c-designware-core.h    |  2 -
 drivers/i2c/busses/i2c-designware-platdrv.c | 70 +--------------------
 4 files changed, 2 insertions(+), 77 deletions(-)

-- 
2.50.1

[PATCH v1 1/2] i2c: designware: Remove not-going-to-be-supported code for Baikal SoC

[Andy Shevchenko]

As noticed in the discussion [1] the Baikal SoC and platforms
are not going to be finalized, hence remove stale code.

Link: https://lore.kernel.org/lkml/22b92ddf-6321-41b5-8073-f9c7064d3432@infradead.org/ [1]
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/i2c/busses/Kconfig                  |  1 -
 drivers/i2c/busses/i2c-designware-core.h    |  1 -
 drivers/i2c/busses/i2c-designware-platdrv.c | 68 ---------------------
 3 files changed, 70 deletions(-)

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 860812e224a0..e11d50750e63 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -580,7 +580,6 @@ if I2C_DESIGNWARE_CORE
 config I2C_DESIGNWARE_PLATFORM
 	tristate "Synopsys DesignWare Platform driver"
 	depends on (ACPI && COMMON_CLK) || !ACPI
-	select MFD_SYSCON if MIPS_BAIKAL_T1
 	default I2C_DESIGNWARE_CORE
 	help
 	  If you say yes to this option, support will be included for the
diff --git a/drivers/i2c/busses/i2c-designware-core.h b/drivers/i2c/busses/i2c-designware-core.h
index 2a7decc24931..cf0364079b55 100644
--- a/drivers/i2c/busses/i2c-designware-core.h
+++ b/drivers/i2c/busses/i2c-designware-core.h
@@ -314,7 +314,6 @@ struct dw_i2c_dev {
 #define ACCESS_POLLING				BIT(3)
 
 #define MODEL_MSCC_OCELOT			BIT(8)
-#define MODEL_BAIKAL_BT1			BIT(9)
 #define MODEL_AMD_NAVI_GPU			BIT(10)
 #define MODEL_WANGXUN_SP			BIT(11)
 #define MODEL_MASK				GENMASK(11, 8)
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
index 077b34535ec7..2e532f16691b 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -37,70 +37,6 @@ static u32 i2c_dw_get_clk_rate_khz(struct dw_i2c_dev *dev)
 	return clk_get_rate(dev->clk) / HZ_PER_KHZ;
 }
 
-#ifdef CONFIG_OF
-#define BT1_I2C_CTL			0x100
-#define BT1_I2C_CTL_ADDR_MASK		GENMASK(7, 0)
-#define BT1_I2C_CTL_WR			BIT(8)
-#define BT1_I2C_CTL_GO			BIT(31)
-#define BT1_I2C_DI			0x104
-#define BT1_I2C_DO			0x108
-
-static int bt1_i2c_read(void *context, unsigned int reg, unsigned int *val)
-{
-	struct dw_i2c_dev *dev = context;
-	int ret;
-
-	/*
-	 * Note these methods shouldn't ever fail because the system controller
-	 * registers are memory mapped. We check the return value just in case.
-	 */
-	ret = regmap_write(dev->sysmap, BT1_I2C_CTL,
-			   BT1_I2C_CTL_GO | (reg & BT1_I2C_CTL_ADDR_MASK));
-	if (ret)
-		return ret;
-
-	return regmap_read(dev->sysmap, BT1_I2C_DO, val);
-}
-
-static int bt1_i2c_write(void *context, unsigned int reg, unsigned int val)
-{
-	struct dw_i2c_dev *dev = context;
-	int ret;
-
-	ret = regmap_write(dev->sysmap, BT1_I2C_DI, val);
-	if (ret)
-		return ret;
-
-	return regmap_write(dev->sysmap, BT1_I2C_CTL,
-			    BT1_I2C_CTL_GO | BT1_I2C_CTL_WR | (reg & BT1_I2C_CTL_ADDR_MASK));
-}
-
-static const struct regmap_config bt1_i2c_cfg = {
-	.reg_bits = 32,
-	.val_bits = 32,
-	.reg_stride = 4,
-	.fast_io = true,
-	.reg_read = bt1_i2c_read,
-	.reg_write = bt1_i2c_write,
-	.max_register = DW_IC_COMP_TYPE,
-};
-
-static int bt1_i2c_request_regs(struct dw_i2c_dev *dev)
-{
-	dev->sysmap = syscon_node_to_regmap(dev->dev->of_node->parent);
-	if (IS_ERR(dev->sysmap))
-		return PTR_ERR(dev->sysmap);
-
-	dev->map = devm_regmap_init(dev->dev, NULL, dev, &bt1_i2c_cfg);
-	return PTR_ERR_OR_ZERO(dev->map);
-}
-#else
-static int bt1_i2c_request_regs(struct dw_i2c_dev *dev)
-{
-	return -ENODEV;
-}
-#endif
-
 static int dw_i2c_get_parent_regmap(struct dw_i2c_dev *dev)
 {
 	dev->map = dev_get_regmap(dev->dev->parent, NULL);
@@ -127,9 +63,6 @@ static int dw_i2c_plat_request_regs(struct dw_i2c_dev *dev)
 		return dw_i2c_get_parent_regmap(dev);
 
 	switch (dev->flags & MODEL_MASK) {
-	case MODEL_BAIKAL_BT1:
-		ret = bt1_i2c_request_regs(dev);
-		break;
 	case MODEL_WANGXUN_SP:
 		ret = dw_i2c_get_parent_regmap(dev);
 		break;
@@ -334,7 +267,6 @@ static void dw_i2c_plat_remove(struct platform_device *pdev)
 }
 
 static const struct of_device_id dw_i2c_of_match[] = {
-	{ .compatible = "baikal,bt1-sys-i2c", .data = (void *)MODEL_BAIKAL_BT1 },
 	{ .compatible = "mscc,ocelot-i2c", .data = (void *)MODEL_MSCC_OCELOT },
 	{ .compatible = "snps,designware-i2c" },
 	{}
-- 
2.50.1

Re: [PATCH v1 1/2] i2c: designware: Remove not-going-to-be-supported code for Baikal SoC

[Mika Westerberg]

On Wed, Jan 14, 2026 at 09:17:50AM +0100, Andy Shevchenko wrote:
> As noticed in the discussion [1] the Baikal SoC and platforms
> are not going to be finalized, hence remove stale code.
> 
> Link: https://lore.kernel.org/lkml/22b92ddf-6321-41b5-8073-f9c7064d3432@infradead.org/ [1]
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>

Re: [PATCH v1 1/2] i2c: designware: Remove not-going-to-be-supported code for Baikal SoC

[Andi Shyti]

On Wed, Jan 14, 2026 at 09:17:50AM +0100, Andy Shevchenko wrote:
> As noticed in the discussion [1] the Baikal SoC and platforms
> are not going to be finalized, hence remove stale code.
> 
> Link: https://lore.kernel.org/lkml/22b92ddf-6321-41b5-8073-f9c7064d3432@infradead.org/ [1]
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Until you guys sort things out with patch 2, I'm applying patch 1.

Thanks,
Andi

[PATCH v1 2/2] i2c: designware: Use device_is_compatible() instead of custom approach

[Andy Shevchenko]

We use MODEL_MSCC_OCELOT effectively is a flag for comparing against
"compatible" property. Use device_is_compatible() directly to make it
clear.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/i2c/busses/i2c-designware-common.c  | 6 +-----
 drivers/i2c/busses/i2c-designware-core.h    | 1 -
 drivers/i2c/busses/i2c-designware-platdrv.c | 2 +-
 3 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/i2c/busses/i2c-designware-common.c b/drivers/i2c/busses/i2c-designware-common.c
index 5b1e8f74c4ac..c766d9821975 100644
--- a/drivers/i2c/busses/i2c-designware-common.c
+++ b/drivers/i2c/busses/i2c-designware-common.c
@@ -238,14 +238,10 @@ static void i2c_dw_of_configure(struct device *device)
 	struct platform_device *pdev = to_platform_device(device);
 	struct dw_i2c_dev *dev = dev_get_drvdata(device);
 
-	switch (dev->flags & MODEL_MASK) {
-	case MODEL_MSCC_OCELOT:
+	if (device_is_compatible(dev->dev, "mscc,ocelot-i2c")) {
 		dev->ext = devm_platform_ioremap_resource(pdev, 1);
 		if (!IS_ERR(dev->ext))
 			dev->set_sda_hold_time = mscc_twi_set_sda_hold_time;
-		break;
-	default:
-		break;
 	}
 }
 
diff --git a/drivers/i2c/busses/i2c-designware-core.h b/drivers/i2c/busses/i2c-designware-core.h
index cf0364079b55..10055f0e0ec3 100644
--- a/drivers/i2c/busses/i2c-designware-core.h
+++ b/drivers/i2c/busses/i2c-designware-core.h
@@ -313,7 +313,6 @@ struct dw_i2c_dev {
 #define ARBITRATION_SEMAPHORE			BIT(2)
 #define ACCESS_POLLING				BIT(3)
 
-#define MODEL_MSCC_OCELOT			BIT(8)
 #define MODEL_AMD_NAVI_GPU			BIT(10)
 #define MODEL_WANGXUN_SP			BIT(11)
 #define MODEL_MASK				GENMASK(11, 8)
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
index 2e532f16691b..4e6fe3b55322 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -267,7 +267,7 @@ static void dw_i2c_plat_remove(struct platform_device *pdev)
 }
 
 static const struct of_device_id dw_i2c_of_match[] = {
-	{ .compatible = "mscc,ocelot-i2c", .data = (void *)MODEL_MSCC_OCELOT },
+	{ .compatible = "mscc,ocelot-i2c" },
 	{ .compatible = "snps,designware-i2c" },
 	{}
 };
-- 
2.50.1

Re: [PATCH v1 2/2] i2c: designware: Use device_is_compatible() instead of custom approach

[Mika Westerberg]

On Wed, Jan 14, 2026 at 09:17:51AM +0100, Andy Shevchenko wrote:
> We use MODEL_MSCC_OCELOT effectively is a flag for comparing against

as a flag?

> "compatible" property. Use device_is_compatible() directly to make it
> clear.

Okay but if something else ever needs this same quirk then we would need to
add new entry here and also to the IDs list.

With the flag you can have the IDs in a single place not all over the
driver.

> 
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
>  drivers/i2c/busses/i2c-designware-common.c  | 6 +-----
>  drivers/i2c/busses/i2c-designware-core.h    | 1 -
>  drivers/i2c/busses/i2c-designware-platdrv.c | 2 +-
>  3 files changed, 2 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-designware-common.c b/drivers/i2c/busses/i2c-designware-common.c
> index 5b1e8f74c4ac..c766d9821975 100644
> --- a/drivers/i2c/busses/i2c-designware-common.c
> +++ b/drivers/i2c/busses/i2c-designware-common.c
> @@ -238,14 +238,10 @@ static void i2c_dw_of_configure(struct device *device)
>  	struct platform_device *pdev = to_platform_device(device);
>  	struct dw_i2c_dev *dev = dev_get_drvdata(device);
>  
> -	switch (dev->flags & MODEL_MASK) {
> -	case MODEL_MSCC_OCELOT:
> +	if (device_is_compatible(dev->dev, "mscc,ocelot-i2c")) {
>  		dev->ext = devm_platform_ioremap_resource(pdev, 1);
>  		if (!IS_ERR(dev->ext))
>  			dev->set_sda_hold_time = mscc_twi_set_sda_hold_time;
> -		break;
> -	default:
> -		break;
>  	}
>  }
>  
> diff --git a/drivers/i2c/busses/i2c-designware-core.h b/drivers/i2c/busses/i2c-designware-core.h
> index cf0364079b55..10055f0e0ec3 100644
> --- a/drivers/i2c/busses/i2c-designware-core.h
> +++ b/drivers/i2c/busses/i2c-designware-core.h
> @@ -313,7 +313,6 @@ struct dw_i2c_dev {
>  #define ARBITRATION_SEMAPHORE			BIT(2)
>  #define ACCESS_POLLING				BIT(3)
>  
> -#define MODEL_MSCC_OCELOT			BIT(8)
>  #define MODEL_AMD_NAVI_GPU			BIT(10)
>  #define MODEL_WANGXUN_SP			BIT(11)
>  #define MODEL_MASK				GENMASK(11, 8)
> diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
> index 2e532f16691b..4e6fe3b55322 100644
> --- a/drivers/i2c/busses/i2c-designware-platdrv.c
> +++ b/drivers/i2c/busses/i2c-designware-platdrv.c
> @@ -267,7 +267,7 @@ static void dw_i2c_plat_remove(struct platform_device *pdev)
>  }
>  
>  static const struct of_device_id dw_i2c_of_match[] = {
> -	{ .compatible = "mscc,ocelot-i2c", .data = (void *)MODEL_MSCC_OCELOT },
> +	{ .compatible = "mscc,ocelot-i2c" },
>  	{ .compatible = "snps,designware-i2c" },
>  	{}
>  };
> -- 
> 2.50.1

Re: [PATCH v1 2/2] i2c: designware: Use device_is_compatible() instead of custom approach

[Andy Shevchenko]

On Wed, Jan 14, 2026 at 12:53:04PM +0100, Mika Westerberg wrote:
> On Wed, Jan 14, 2026 at 09:17:51AM +0100, Andy Shevchenko wrote:
> > We use MODEL_MSCC_OCELOT effectively is a flag for comparing against
> 
> as a flag?

Yes, sorry for the typo.

> > "compatible" property. Use device_is_compatible() directly to make it
> > clear.
> 
> Okay but if something else ever needs this same quirk then we would need to
> add new entry here and also to the IDs list.

Yes, that's how DT works and there are, of course, examples all over
the kernel, first that comes to my mind: drivers/mmc/host/sdhci-pltfm.c.

> With the flag you can have the IDs in a single place not all over the
> driver.

Makes the reality harder to read. If I know that the same quirk is used by
different platform (in terms of compatible string) I will see it immediately
from the code. Flag is meaningless.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 2/2] i2c: designware: Use device_is_compatible() instead of custom approach

[Mika Westerberg]

On Wed, Jan 14, 2026 at 06:09:09PM +0200, Andy Shevchenko wrote:
> On Wed, Jan 14, 2026 at 12:53:04PM +0100, Mika Westerberg wrote:
> > On Wed, Jan 14, 2026 at 09:17:51AM +0100, Andy Shevchenko wrote:
> > > We use MODEL_MSCC_OCELOT effectively is a flag for comparing against
> > 
> > as a flag?
> 
> Yes, sorry for the typo.
> 
> > > "compatible" property. Use device_is_compatible() directly to make it
> > > clear.
> > 
> > Okay but if something else ever needs this same quirk then we would need to
> > add new entry here and also to the IDs list.
> 
> Yes, that's how DT works and there are, of course, examples all over
> the kernel, first that comes to my mind: drivers/mmc/host/sdhci-pltfm.c.
> 
> > With the flag you can have the IDs in a single place not all over the
> > driver.
> 
> Makes the reality harder to read. If I know that the same quirk is used by
> different platform (in terms of compatible string) I will see it immediately
> from the code. Flag is meaningless.

Well with the flag you get the help from the compiler if you typo it but
with the string comparison you are on your own. Therefore I prefer the flag
and as I said it also avoid duplicating the compatible string.

Re: [PATCH v1 2/2] i2c: designware: Use device_is_compatible() instead of custom approach

[Andy Shevchenko]

On Thu, Jan 15, 2026 at 06:39:59AM +0100, Mika Westerberg wrote:
> On Wed, Jan 14, 2026 at 06:09:09PM +0200, Andy Shevchenko wrote:
> > On Wed, Jan 14, 2026 at 12:53:04PM +0100, Mika Westerberg wrote:
> > > On Wed, Jan 14, 2026 at 09:17:51AM +0100, Andy Shevchenko wrote:
> > > > We use MODEL_MSCC_OCELOT effectively is a flag for comparing against
> > > 
> > > as a flag?
> > 
> > Yes, sorry for the typo.
> > 
> > > > "compatible" property. Use device_is_compatible() directly to make it
> > > > clear.
> > > 
> > > Okay but if something else ever needs this same quirk then we would need to
> > > add new entry here and also to the IDs list.
> > 
> > Yes, that's how DT works and there are, of course, examples all over
> > the kernel, first that comes to my mind: drivers/mmc/host/sdhci-pltfm.c.
> > 
> > > With the flag you can have the IDs in a single place not all over the
> > > driver.
> > 
> > Makes the reality harder to read. If I know that the same quirk is used by
> > different platform (in terms of compatible string) I will see it immediately
> > from the code. Flag is meaningless.
> 
> Well with the flag you get the help from the compiler if you typo it but
> with the string comparison you are on your own.

It only affects the development cycle, isn't it obvious that any quirk should
be tested by the author, otherwise it won't work.

> Therefore I prefer the flag and as I said it also avoid duplicating the
> compatible string.

Duplicating compatible string is not a problem, linker nowadays combines
the same strings into one. In case you are worrying about the space, it's
not a problem.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 2/2] i2c: designware: Use device_is_compatible() instead of custom approach

[Mika Westerberg]

On Thu, Jan 15, 2026 at 09:41:26AM +0200, Andy Shevchenko wrote:
> On Thu, Jan 15, 2026 at 06:39:59AM +0100, Mika Westerberg wrote:
> > On Wed, Jan 14, 2026 at 06:09:09PM +0200, Andy Shevchenko wrote:
> > > On Wed, Jan 14, 2026 at 12:53:04PM +0100, Mika Westerberg wrote:
> > > > On Wed, Jan 14, 2026 at 09:17:51AM +0100, Andy Shevchenko wrote:
> > > > > We use MODEL_MSCC_OCELOT effectively is a flag for comparing against
> > > > 
> > > > as a flag?
> > > 
> > > Yes, sorry for the typo.
> > > 
> > > > > "compatible" property. Use device_is_compatible() directly to make it
> > > > > clear.
> > > > 
> > > > Okay but if something else ever needs this same quirk then we would need to
> > > > add new entry here and also to the IDs list.
> > > 
> > > Yes, that's how DT works and there are, of course, examples all over
> > > the kernel, first that comes to my mind: drivers/mmc/host/sdhci-pltfm.c.
> > > 
> > > > With the flag you can have the IDs in a single place not all over the
> > > > driver.
> > > 
> > > Makes the reality harder to read. If I know that the same quirk is used by
> > > different platform (in terms of compatible string) I will see it immediately
> > > from the code. Flag is meaningless.
> > 
> > Well with the flag you get the help from the compiler if you typo it but
> > with the string comparison you are on your own.
> 
> It only affects the development cycle, isn't it obvious that any quirk should
> be tested by the author, otherwise it won't work.

Of course but then are these "cleanups" that probably will not be tested
that well if at all. If it is possible to take advantage of the compiler
then I prefer that.

> > Therefore I prefer the flag and as I said it also avoid duplicating the
> > compatible string.
> 
> Duplicating compatible string is not a problem, linker nowadays combines
> the same strings into one. In case you are worrying about the space, it's
> not a problem.

I don't care about the space but just duplication.

Re: [PATCH v1 2/2] i2c: designware: Use device_is_compatible() instead of custom approach

[Andi Shyti]

Hi,

On Wed, Jan 14, 2026 at 09:17:51AM +0100, Andy Shevchenko wrote:
> We use MODEL_MSCC_OCELOT effectively is a flag for comparing against
> "compatible" property. Use device_is_compatible() directly to make it
> clear.
> 
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

I'm coming into the discussion and I personally like Andy's
approach. As a third party, I believe this patch has reached the
consensus and I'm taking it in i2c/i2c-host.

Thanks Andy,
Andi

Re: [PATCH v1 2/2] i2c: designware: Use device_is_compatible() instead of custom approach

[Andy Shevchenko]

On Thu, Jan 22, 2026 at 12:10:48PM +0100, Andi Shyti wrote:
> On Wed, Jan 14, 2026 at 09:17:51AM +0100, Andy Shevchenko wrote:
> > We use MODEL_MSCC_OCELOT effectively is a flag for comparing against
> > "compatible" property. Use device_is_compatible() directly to make it
> > clear.
> > 
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> 
> I'm coming into the discussion and I personally like Andy's
> approach. As a third party, I believe this patch has reached the
> consensus and I'm taking it in i2c/i2c-host.

Thank you!

-- 
With Best Regards,
Andy Shevchenko