The BCM59054 is another chip from the BCM590xx line of PMUs, commonly
used on devices with the BCM21664/BCM23550 chipsets.

Prepare the BCM590xx driver for supporting other devices by adding the
PMUID register values for supported chip types and store them in the
MFD data struct as "pmu_id". (These will be checked against the actual
PMUID register values in a later commit.)

Then, add a DT compatible for the BCM59054, and provide the PMU ID as
OF match data.

Signed-off-by: Artur Weber <aweber.kernel@gmail.com>
---
Changes in v6:
- Move PMUID value to MFD header
- Use PMUID value as OF data/device type value
- Add bcm59054 to I2C ID table

Changes in v4:
- Rewrite commit message description
- Rename "device_type" member to "dev_type"
- Drop awkward line break to fit function call
- Add PMU ID/revision parsing function

Changes in v3:
- Fix compilation warning about device_type pointer cast type
- Name the device types enum and use it as the type in the MFD struct
---
 drivers/mfd/bcm590xx.c       | 12 +++++++++++-
 include/linux/mfd/bcm590xx.h |  7 +++++++
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/bcm590xx.c b/drivers/mfd/bcm590xx.c
index 8b56786d85d0182acf91da203b5f943556c08422..4620eed0066fbf1dd691a2e392e967747b4d125b 100644
--- a/drivers/mfd/bcm590xx.c
+++ b/drivers/mfd/bcm590xx.c
@@ -50,6 +50,8 @@ static int bcm590xx_i2c_probe(struct i2c_client *i2c_pri)
 	bcm590xx->dev = &i2c_pri->dev;
 	bcm590xx->i2c_pri = i2c_pri;
 
+	bcm590xx->pmu_id = (uintptr_t) of_device_get_match_data(bcm590xx->dev);
+
 	bcm590xx->regmap_pri = devm_regmap_init_i2c(i2c_pri,
 						 &bcm590xx_regmap_config_pri);
 	if (IS_ERR(bcm590xx->regmap_pri)) {
@@ -91,12 +93,20 @@ static int bcm590xx_i2c_probe(struct i2c_client *i2c_pri)
 }
 
 static const struct of_device_id bcm590xx_of_match[] = {
-	{ .compatible = "brcm,bcm59056" },
+	{
+		.compatible = "brcm,bcm59054",
+		.data = (void *)BCM590XX_PMUID_BCM59054,
+	},
+	{
+		.compatible = "brcm,bcm59056",
+		.data = (void *)BCM590XX_PMUID_BCM59056,
+	},
 	{ }
 };
 MODULE_DEVICE_TABLE(of, bcm590xx_of_match);
 
 static const struct i2c_device_id bcm590xx_i2c_id[] = {
+	{ "bcm59054" },
 	{ "bcm59056" },
 	{ }
 };
diff --git a/include/linux/mfd/bcm590xx.h b/include/linux/mfd/bcm590xx.h
index c614d1b1d8a217ac2f212908a4c19ae71fa56f63..8d146e3b102a7dbce6f4dbab9f8ae5a9c4e68c0e 100644
--- a/include/linux/mfd/bcm590xx.h
+++ b/include/linux/mfd/bcm590xx.h
@@ -13,6 +13,10 @@
 #include <linux/i2c.h>
 #include <linux/regmap.h>
 
+/* PMU ID register values; also used as device type */
+#define BCM590XX_PMUID_BCM59054		0x54
+#define BCM590XX_PMUID_BCM59056		0x56
+
 /* max register address */
 #define BCM590XX_MAX_REGISTER_PRI	0xe7
 #define BCM590XX_MAX_REGISTER_SEC	0xf0
@@ -23,6 +27,9 @@ struct bcm590xx {
 	struct i2c_client *i2c_sec;
 	struct regmap *regmap_pri;
 	struct regmap *regmap_sec;
+
+	/* PMU ID value; also used as device type */
+	u8 pmu_id;
 };
 
 #endif /*  __LINUX_MFD_BCM590XX_H */

-- 
2.49.0

On Wed, 30 Apr 2025, Artur Weber wrote:

> The BCM59054 is another chip from the BCM590xx line of PMUs, commonly
> used on devices with the BCM21664/BCM23550 chipsets.
> 
> Prepare the BCM590xx driver for supporting other devices by adding the
> PMUID register values for supported chip types and store them in the
> MFD data struct as "pmu_id". (These will be checked against the actual
> PMUID register values in a later commit.)
> 
> Then, add a DT compatible for the BCM59054, and provide the PMU ID as
> OF match data.
> 
> Signed-off-by: Artur Weber <aweber.kernel@gmail.com>
> ---
> Changes in v6:
> - Move PMUID value to MFD header
> - Use PMUID value as OF data/device type value
> - Add bcm59054 to I2C ID table
> 
> Changes in v4:
> - Rewrite commit message description
> - Rename "device_type" member to "dev_type"
> - Drop awkward line break to fit function call
> - Add PMU ID/revision parsing function
> 
> Changes in v3:
> - Fix compilation warning about device_type pointer cast type
> - Name the device types enum and use it as the type in the MFD struct
> ---
>  drivers/mfd/bcm590xx.c       | 12 +++++++++++-
>  include/linux/mfd/bcm590xx.h |  7 +++++++
>  2 files changed, 18 insertions(+), 1 deletion(-)

I can't merge this until Mark has provided the Regulator Acks.

-- 
Lee Jones [李琼斯]

On Fri, May 09, 2025 at 03:09:57PM +0100, Lee Jones wrote:
> On Wed, 30 Apr 2025, Artur Weber wrote:

> > ---
> >  drivers/mfd/bcm590xx.c       | 12 +++++++++++-
> >  include/linux/mfd/bcm590xx.h |  7 +++++++
> >  2 files changed, 18 insertions(+), 1 deletion(-)

> I can't merge this until Mark has provided the Regulator Acks.

Could you be more explicit what you're looking for here, the diffstat is
entirely MFD?

On Wed, 14 May 2025, Mark Brown wrote:

> On Fri, May 09, 2025 at 03:09:57PM +0100, Lee Jones wrote:
> > On Wed, 30 Apr 2025, Artur Weber wrote:
> 
> > > ---
> > >  drivers/mfd/bcm590xx.c       | 12 +++++++++++-
> > >  include/linux/mfd/bcm590xx.h |  7 +++++++
> > >  2 files changed, 18 insertions(+), 1 deletion(-)
> 
> > I can't merge this until Mark has provided the Regulator Acks.
> 
> Could you be more explicit what you're looking for here, the diffstat is
> entirely MFD?

Okay, more explicitly, I can merge this and MFD will have no issue.
However, the Regulator commits make use of 'pmu_id' introduced in this
change and would therefore cause a compile break.  So we could:

  1. Apply this now and merge the dependents next cycle
  2. Apply this now and provide an IB
  3. Wait for all Acks and apply as a unified set

We usually choose 3, hence my assumptions above.

-- 
Lee Jones [李琼斯]

On Thu, May 15, 2025 at 08:13:57AM +0100, Lee Jones wrote:
> On Wed, 14 May 2025, Mark Brown wrote:

> > Could you be more explicit what you're looking for here, the diffstat is
> > entirely MFD?

> Okay, more explicitly, I can merge this and MFD will have no issue.
> However, the Regulator commits make use of 'pmu_id' introduced in this
> change and would therefore cause a compile break.  So we could:

>   1. Apply this now and merge the dependents next cycle
>   2. Apply this now and provide an IB
>   3. Wait for all Acks and apply as a unified set

> We usually choose 3, hence my assumptions above.

Well, you choose 3 - I do think it'd be a lot easier to go with option
2, or with applying the rest to your tree as acks come in.  There seemed
to still be a reasonable amount of discussion on the MFD bits (eg,
there's some formatting comments still) so I was expecting this series
to churn some more and was waiting for a resend.

On Thu, 15 May 2025, Mark Brown wrote:

> On Thu, May 15, 2025 at 08:13:57AM +0100, Lee Jones wrote:
> > On Wed, 14 May 2025, Mark Brown wrote:
> 
> > > Could you be more explicit what you're looking for here, the diffstat is
> > > entirely MFD?
> 
> > Okay, more explicitly, I can merge this and MFD will have no issue.
> > However, the Regulator commits make use of 'pmu_id' introduced in this
> > change and would therefore cause a compile break.  So we could:
> 
> >   1. Apply this now and merge the dependents next cycle
> >   2. Apply this now and provide an IB
> >   3. Wait for all Acks and apply as a unified set
> 
> > We usually choose 3, hence my assumptions above.
> 
> Well, you choose 3 - I do think it'd be a lot easier to go with option
> 2, or with applying the rest to your tree as acks come in.  There seemed
> to still be a reasonable amount of discussion on the MFD bits (eg,
> there's some formatting comments still) so I was expecting this series
> to churn some more and was waiting for a resend.

Yes, I expected to apply v9 with your Ack.

I can go with 2 in this case.  Applying in dribs-and-drabs as Acks come
in would be sub-optimal and would likely end up in a mess.

-- 
Lee Jones [李琼斯]

On Thu, May 15, 2025 at 10:20:00AM +0100, Lee Jones wrote:
> On Thu, 15 May 2025, Mark Brown wrote:

> > Well, you choose 3 - I do think it'd be a lot easier to go with option
> > 2, or with applying the rest to your tree as acks come in.  There seemed
> > to still be a reasonable amount of discussion on the MFD bits (eg,
> > there's some formatting comments still) so I was expecting this series
> > to churn some more and was waiting for a resend.

> Yes, I expected to apply v9 with your Ack.

OK, that's about where I was expecting - at least one more respin before
the MFD bits are stable.

> I can go with 2 in this case.  Applying in dribs-and-drabs as Acks come
> in would be sub-optimal and would likely end up in a mess.

Well, then just going a head and applying them on a branch with a tag
seems easier than delaying then.

On 5/15/25 11:33, Mark Brown wrote:
> On Thu, May 15, 2025 at 10:20:00AM +0100, Lee Jones wrote:
>> On Thu, 15 May 2025, Mark Brown wrote:
> 
>>> Well, you choose 3 - I do think it'd be a lot easier to go with option
>>> 2, or with applying the rest to your tree as acks come in.  There seemed
>>> to still be a reasonable amount of discussion on the MFD bits (eg,
>>> there's some formatting comments still) so I was expecting this series
>>> to churn some more and was waiting for a resend.
> 
>> Yes, I expected to apply v9 with your Ack.
> 
> OK, that's about where I was expecting - at least one more respin before
> the MFD bits are stable.
> 
>> I can go with 2 in this case.  Applying in dribs-and-drabs as Acks come
>> in would be sub-optimal and would likely end up in a mess.
> 
> Well, then just going a head and applying them on a branch with a tag
> seems easier than delaying then.

I can split the patchset into two parts (one for MFD, one for regulator)
if it helps.

Best regards
Artur

On Thu, May 15, 2025 at 01:28:15PM +0200, Artur Weber wrote:
> On 5/15/25 11:33, Mark Brown wrote:
> > On Thu, May 15, 2025 at 10:20:00AM +0100, Lee Jones wrote:

> > > I can go with 2 in this case.  Applying in dribs-and-drabs as Acks come
> > > in would be sub-optimal and would likely end up in a mess.

> > Well, then just going a head and applying them on a branch with a tag
> > seems easier than delaying then.

> I can split the patchset into two parts (one for MFD, one for regulator)
> if it helps.

There's still a dependency on the MFD bits whatever happens.

On Thu, 15 May 2025, Mark Brown wrote:

> On Thu, May 15, 2025 at 01:28:15PM +0200, Artur Weber wrote:
> > On 5/15/25 11:33, Mark Brown wrote:
> > > On Thu, May 15, 2025 at 10:20:00AM +0100, Lee Jones wrote:
> 
> > > > I can go with 2 in this case.  Applying in dribs-and-drabs as Acks come
> > > > in would be sub-optimal and would likely end up in a mess.
> 
> > > Well, then just going a head and applying them on a branch with a tag
> > > seems easier than delaying then.
> 
> > I can split the patchset into two parts (one for MFD, one for regulator)
> > if it helps.
> 
> There's still a dependency on the MFD bits whatever happens.

Right.  That won't help since you need to describe the deps.  Submitting
them as a set was the correct thing to do.

-- 
Lee Jones [李琼斯]

On 5/15/25 15:13, Lee Jones wrote:
> On Thu, 15 May 2025, Mark Brown wrote:
> 
>> On Thu, May 15, 2025 at 01:28:15PM +0200, Artur Weber wrote:
>>> On 5/15/25 11:33, Mark Brown wrote:
>>>> On Thu, May 15, 2025 at 10:20:00AM +0100, Lee Jones wrote:
>>
>>>>> I can go with 2 in this case.  Applying in dribs-and-drabs as Acks come
>>>>> in would be sub-optimal and would likely end up in a mess.
>>
>>>> Well, then just going a head and applying them on a branch with a tag
>>>> seems easier than delaying then.
>>
>>> I can split the patchset into two parts (one for MFD, one for regulator)
>>> if it helps.
>>
>> There's still a dependency on the MFD bits whatever happens.
> 
> Right.  That won't help since you need to describe the deps.  Submitting
> them as a set was the correct thing to do.
> 

OK then. I submitted a new version, v9, with the style nitpick
addressed:

https://lore.kernel.org/lkml/20250515-bcm59054-v9-0-14ba0ea2ea5b@gmail.com/

Best regards
Artur