[PATCH 0/2] hwmon: Add support for Analog Devices MAX20912 and MAX20916

[PATCH 0/2] hwmon: Add support for Analog Devices MAX20912 and MAX20916

[Fred Chen]

Add PMBus hardware monitoring support for the Analog Devices MAX20912
and MAX20916 dual-output multiphase voltage regulators.

Both devices expose two independently regulated output voltage rails,
Rail A and Rail B, using the VR12 VID interface. Each rail reports input
current, output current, temperature, input power, and output power.
Input voltage is reported on Rail A only.

Fred Chen (2):
  dt-bindings: trivial-devices: Add adi max20912 and max20916
  hwmon: (pmbus) Add driver for Analog Devices MAX20912 and MAX20916

 .../devicetree/bindings/trivial-devices.yaml  |   4 +
 Documentation/hwmon/index.rst                 |   1 +
 Documentation/hwmon/max20912.rst              | 156 ++++++++++++++++++
 MAINTAINERS                                   |   7 +
 drivers/hwmon/pmbus/Kconfig                   |   9 +
 drivers/hwmon/pmbus/Makefile                  |   1 +
 drivers/hwmon/pmbus/max20912.c                |  70 ++++++++
 7 files changed, 248 insertions(+)
 create mode 100644 Documentation/hwmon/max20912.rst
 create mode 100644 drivers/hwmon/pmbus/max20912.c

-- 
2.52.0

[PATCH 1/2] dt-bindings: trivial-devices: Add adi max20912 and max20916

[Fred Chen]

Add device tree bindings for Analog Devices MAX20912 and MAX20916
Dual-Output Voltage Regulator.

Signed-off-by: Fred Chen <fredchen.openbmc@gmail.com>
---
 Documentation/devicetree/bindings/trivial-devices.yaml | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml
index 435c4baab436..5e7fb4edb82a 100644
--- a/Documentation/devicetree/bindings/trivial-devices.yaml
+++ b/Documentation/devicetree/bindings/trivial-devices.yaml
@@ -57,6 +57,10 @@ properties:
           - adi,adt7468
             # Analog Devices LT7182S Dual Channel 6A, 20V PolyPhase Step-Down Silent Switcher
           - adi,lt7182s
+            # Analog Devices MAX20912 Dual-Output Voltage Regulator
+          - adi,max20912
+            # Analog Devices MAX20916 Dual-Output Voltage Regulator
+          - adi,max20916
             # AMS iAQ-Core VOC Sensor
           - ams,iaq-core
             # Aosong temperature & humidity sensors with I2C interface
-- 
2.52.0

[PATCH 2/2] hwmon: (pmbus) Add driver for Analog Devices MAX20912 and MAX20916

[Fred Chen]

Add support for the Analog Devices MAX20912 and MAX20916 dual-output
multiphase voltage regulators with PMBus interfaces.

Signed-off-by: Fred Chen <fredchen.openbmc@gmail.com>
---
 Documentation/hwmon/index.rst    |   1 +
 Documentation/hwmon/max20912.rst | 156 +++++++++++++++++++++++++++++++
 MAINTAINERS                      |   7 ++
 drivers/hwmon/pmbus/Kconfig      |   9 ++
 drivers/hwmon/pmbus/Makefile     |   1 +
 drivers/hwmon/pmbus/max20912.c   |  70 ++++++++++++++
 6 files changed, 244 insertions(+)
 create mode 100644 Documentation/hwmon/max20912.rst
 create mode 100644 drivers/hwmon/pmbus/max20912.c

diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
index 29130df44d12..4fadb7e961b2 100644
--- a/Documentation/hwmon/index.rst
+++ b/Documentation/hwmon/index.rst
@@ -166,6 +166,7 @@ Hardware Monitoring Kernel Drivers
    max20751
    max20830
    max20860a
+   max20912
    max31722
    max31730
    max31760
diff --git a/Documentation/hwmon/max20912.rst b/Documentation/hwmon/max20912.rst
new file mode 100644
index 000000000000..da1430751e93
--- /dev/null
+++ b/Documentation/hwmon/max20912.rst
@@ -0,0 +1,156 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+Kernel driver max20912
+======================
+
+Supported chips:
+
+  * Analog Devices MAX20912
+
+    Prefix: 'max20912'
+
+    Datasheet: Not publicly available
+
+  * Analog Devices MAX20916
+
+    Prefix: 'max20916'
+
+    Datasheet: Not publicly available
+
+Author:
+
+	Fred Chen <fredchen.openbmc@gmail.com>
+
+Description
+-----------
+
+This driver implements support for the Analog Devices MAX20912 and MAX20916
+high-density, flexible, and scalable dual-output multiphase voltage regulators.
+
+The MAX20912 supports up to 12 phases in total, configurable from 12+0 to
+6+6 phases between Rail A and Rail B.
+
+The MAX20916 supports up to 16 phases in total, configurable from 16+0 to
+8+8 phases between Rail A and Rail B.
+
+Device compliant with:
+
+- PMBus rev 1.3 interface.
+
+Both devices expose two independently regulated output voltage rails,
+Rail A and Rail B, using the VR12 VID interface. Each rail reports input
+current, output current, temperature, input power, and output power.
+Input voltage is reported on Rail A only.
+
+The driver exports the following attributes via the 'sysfs' files
+for input voltage:
+
+**in1_input**
+
+**in1_label**
+
+**in1_alarm**
+
+The driver provides the following attributes for output voltage:
+
+**in2_input**
+
+**in2_label**
+
+**in2_alarm**
+
+**in3_input**
+
+**in3_label**
+
+**in3_alarm**
+
+The driver provides the following attributes for input current:
+
+**curr1_input**
+
+**curr1_label**
+
+**curr1_max**
+
+**curr1_max_alarm**
+
+**curr2_input**
+
+**curr2_label**
+
+**curr2_max**
+
+**curr2_max_alarm**
+
+The driver provides the following attributes for output current:
+
+**curr3_input**
+
+**curr3_label**
+
+**curr3_max**
+
+**curr3_max_alarm**
+
+**curr3_crit**
+
+**curr3_crit_alarm**
+
+**curr4_input**
+
+**curr4_label**
+
+**curr4_max**
+
+**curr4_max_alarm**
+
+**curr4_crit**
+
+**curr4_crit_alarm**
+
+The driver provides the following attributes for temperature:
+
+**temp1_input**
+
+**temp1_max**
+
+**temp1_max_alarm**
+
+**temp1_crit**
+
+**temp1_crit_alarm**
+
+**temp2_input**
+
+**temp2_max**
+
+**temp2_max_alarm**
+
+**temp2_crit**
+
+**temp2_crit_alarm**
+
+The driver provides the following attributes for input power:
+
+**power1_input**
+
+**power1_label**
+
+**power1_alarm**
+
+**power2_input**
+
+**power2_label**
+
+**power2_alarm**
+
+The driver provides the following attributes for output power:
+
+**power3_input**
+
+**power3_label**
+
+**power4_input**
+
+**power4_label**
diff --git a/MAINTAINERS b/MAINTAINERS
index 4a8b0fd665ce..a301af7ff6fd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15851,6 +15851,13 @@ F:	Documentation/devicetree/bindings/hwmon/pmbus/adi,max20860a.yaml
 F:	Documentation/hwmon/max20860a.rst
 F:	drivers/hwmon/pmbus/max20860a.c
 
+MAX20912 HARDWARE MONITOR DRIVER
+M:	Fred Chen <fredchen.openbmc@gmail.com>
+L:	linux-hwmon@vger.kernel.org
+S:	Maintained
+F:	Documentation/hwmon/max20912.rst
+F:	drivers/hwmon/pmbus/max20912.c
+
 MAX2175 SDR TUNER DRIVER
 M:	Ramesh Shanmugasundaram <rashanmu@gmail.com>
 L:	linux-media@vger.kernel.org
diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
index c8cda160b5f8..442c3538bf7c 100644
--- a/drivers/hwmon/pmbus/Kconfig
+++ b/drivers/hwmon/pmbus/Kconfig
@@ -421,6 +421,15 @@ config SENSORS_MAX20860A_REGULATOR
 	  This enables the MAX20860A to be used as a regulator device,
 	  providing voltage control through the regulator framework.
 
+config SENSORS_MAX20912
+	tristate "Analog Devices MAX20912 and MAX20916"
+	help
+	  If you say yes here you get hardware monitoring support for Analog
+	  Devices MAX20912 and MAX20916 dual-output voltage regulators.
+
+	  This driver can also be built as a module. If so, the module will
+	  be called max20912.
+
 config SENSORS_MAX31785
 	tristate "Maxim MAX31785 and compatibles"
 	help
diff --git a/drivers/hwmon/pmbus/Makefile b/drivers/hwmon/pmbus/Makefile
index ffc05f493213..2fa74f0caf18 100644
--- a/drivers/hwmon/pmbus/Makefile
+++ b/drivers/hwmon/pmbus/Makefile
@@ -40,6 +40,7 @@ obj-$(CONFIG_SENSORS_MAX20730)	+= max20730.o
 obj-$(CONFIG_SENSORS_MAX20751)	+= max20751.o
 obj-$(CONFIG_SENSORS_MAX20830)	+= max20830.o
 obj-$(CONFIG_SENSORS_MAX20860A)	+= max20860a.o
+obj-$(CONFIG_SENSORS_MAX20912)	+= max20912.o
 obj-$(CONFIG_SENSORS_MAX31785)	+= max31785.o
 obj-$(CONFIG_SENSORS_MAX34440)	+= max34440.o
 obj-$(CONFIG_SENSORS_MAX8688)	+= max8688.o
diff --git a/drivers/hwmon/pmbus/max20912.c b/drivers/hwmon/pmbus/max20912.c
new file mode 100644
index 000000000000..3d028a619678
--- /dev/null
+++ b/drivers/hwmon/pmbus/max20912.c
@@ -0,0 +1,70 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Hardware monitoring driver for Analog Devices MAX20912 and MAX20916
+ * Dual-Output Voltage Regulator
+ *
+ * Copyright (c) 2026 Quanta Computer Inc.
+ */
+
+#include <linux/module.h>
+#include <linux/i2c.h>
+#include <linux/of.h>
+#include "pmbus.h"
+
+static struct pmbus_driver_info max20912_info = {
+	.pages = 2,
+	.format[PSC_VOLTAGE_IN] = linear,
+	.format[PSC_VOLTAGE_OUT] = vid,
+	.vrm_version[0] = vr12,
+	.vrm_version[1] = vr12,
+	.format[PSC_TEMPERATURE] = linear,
+	.format[PSC_CURRENT_IN] = linear,
+	.format[PSC_CURRENT_OUT] = linear,
+	.format[PSC_POWER] = linear,
+	.func[0] = PMBUS_HAVE_VIN | PMBUS_HAVE_IIN | PMBUS_HAVE_STATUS_INPUT |
+		PMBUS_HAVE_VOUT | PMBUS_HAVE_STATUS_VOUT |
+		PMBUS_HAVE_IOUT | PMBUS_HAVE_STATUS_IOUT |
+		PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP |
+		PMBUS_HAVE_PIN | PMBUS_HAVE_POUT,
+	.func[1] = PMBUS_HAVE_IIN | PMBUS_HAVE_STATUS_INPUT |
+		PMBUS_HAVE_VOUT | PMBUS_HAVE_STATUS_VOUT |
+		PMBUS_HAVE_IOUT | PMBUS_HAVE_STATUS_IOUT |
+		PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP |
+		PMBUS_HAVE_PIN | PMBUS_HAVE_POUT,
+};
+
+static int max20912_probe(struct i2c_client *client)
+{
+	return pmbus_do_probe(client, &max20912_info);
+}
+
+static const struct of_device_id max20912_of_match[] = {
+	{ .compatible = "adi,max20912" },
+	{ .compatible = "adi,max20916" },
+	{}
+};
+MODULE_DEVICE_TABLE(of, max20912_of_match);
+
+static const struct i2c_device_id max20912_id[] = {
+	{"max20912"},
+	{"max20916"},
+	{}
+};
+
+MODULE_DEVICE_TABLE(i2c, max20912_id);
+
+static struct i2c_driver max20912_driver = {
+	.driver = {
+		.name = "max20912",
+		.of_match_table = max20912_of_match,
+	},
+	.probe = max20912_probe,
+	.id_table = max20912_id,
+};
+
+module_i2c_driver(max20912_driver);
+
+MODULE_AUTHOR("Fred Chen <fredchen.openbmc@gmail.com>");
+MODULE_DESCRIPTION("PMBus driver for Analog Devices MAX20912 and MAX20916");
+MODULE_LICENSE("GPL");
+MODULE_IMPORT_NS("PMBUS");
-- 
2.52.0

Re: [PATCH 2/2] hwmon: (pmbus) Add driver for Analog Devices MAX20912 and MAX20916

[Krzysztof Kozlowski]

On 07/07/2026 14:26, Fred Chen wrote:
> +
> +static const struct of_device_id max20912_of_match[] = {
> +	{ .compatible = "adi,max20912" },
> +	{ .compatible = "adi,max20916" },
> +	{}
> +};
> +MODULE_DEVICE_TABLE(of, max20912_of_match);
> +
> +static const struct i2c_device_id max20912_id[] = {
> +	{"max20912"},
> +	{"max20916"},

Please use named initializers (see recent code).

Best regards,
Krzysztof

Re: [PATCH 2/2] hwmon: (pmbus) Add driver for Analog Devices MAX20912 and MAX20916

[Guenter Roeck]

On 7/7/26 05:26, Fred Chen wrote:
> Add support for the Analog Devices MAX20912 and MAX20916 dual-output
> multiphase voltage regulators with PMBus interfaces.
> 
> Signed-off-by: Fred Chen <fredchen.openbmc@gmail.com>

Please provide evidence that those chips actually exist.
Internet search comes up blank. I'll need confirmation
from someone at Analog.

Thanks,
Guenter

Re: [PATCH 2/2] hwmon: (pmbus) Add driver for Analog Devices MAX20912 and MAX20916

[Nuno Sá]

On Tue, Jul 07, 2026 at 06:52:48AM -0700, Guenter Roeck wrote:
> On 7/7/26 05:26, Fred Chen wrote:
> > Add support for the Analog Devices MAX20912 and MAX20916 dual-output
> > multiphase voltage regulators with PMBus interfaces.
> > 
> > Signed-off-by: Fred Chen <fredchen.openbmc@gmail.com>
> 
> Please provide evidence that those chips actually exist.
> Internet search comes up blank. I'll need confirmation
> from someone at Analog.

Hi Guenter,

Well, in fact I'm in the middle of preparing a series that adds support
for:

"max20826"
"max20855b"
"max20908"
"max20912"
"max20916"

All the above parts have the datasheet under NDA. But before we had a
one page "datasheet" in analog.com but I guess that is gone! For context
I mainly did the base (core) driver for max20826 and then Alexis added
the other ones.

Not sure how to proceed... I can wait and then work on top of what Fred
has but this patch is very minimal when compared with what we have.
Like:

* No regulator support;
* No direct mode. The chip has two ways to access registers (paging and
* direct mode).
* No way to count how many phases we have or if RAIL_B (func[1]) is being used at
all.


Some other things more intriguing is that these chips, as far as I'm
aware (at least for max20826), always have bit 2 set in ON_OFF_CONFIG so
a gpio vout. Also we needed some special handling to read phase current
which I'm not seeing in the driver. So I would like to understand how
the chip was tested?

Anyways, if Fred is ok with it I can just finish what I'm doing and send
the patches. It would make sense to have something more complete on
submission but I don't want to just "steal" the work already done.

- Nuno Sá

> 
> Thanks,
> Guenter
> 

Re: [PATCH 2/2] hwmon: (pmbus) Add driver for Analog Devices MAX20912 and MAX20916

[Krzysztof Kozlowski]

On Wed, Jul 08, 2026 at 10:19:56AM +0100, Nuno Sá wrote:
> On Tue, Jul 07, 2026 at 06:52:48AM -0700, Guenter Roeck wrote:
> > On 7/7/26 05:26, Fred Chen wrote:
> > > Add support for the Analog Devices MAX20912 and MAX20916 dual-output
> > > multiphase voltage regulators with PMBus interfaces.
> > > 
> > > Signed-off-by: Fred Chen <fredchen.openbmc@gmail.com>
> > 
> > Please provide evidence that those chips actually exist.
> > Internet search comes up blank. I'll need confirmation
> > from someone at Analog.
> 
> Hi Guenter,
> 
> Well, in fact I'm in the middle of preparing a series that adds support
> for:
> 
> "max20826"
> "max20855b"
> "max20908"
> "max20912"
> "max20916"
> 
> All the above parts have the datasheet under NDA. But before we had a
> one page "datasheet" in analog.com but I guess that is gone! For context
> I mainly did the base (core) driver for max20826 and then Alexis added
> the other ones.
> 
> Not sure how to proceed... I can wait and then work on top of what Fred
> has but this patch is very minimal when compared with what we have.
> Like:
> 
> * No regulator support;
> * No direct mode. The chip has two ways to access registers (paging and
> * direct mode).
> * No way to count how many phases we have or if RAIL_B (func[1]) is being used at
> all.
> 
> 
> Some other things more intriguing is that these chips, as far as I'm
> aware (at least for max20826), always have bit 2 set in ON_OFF_CONFIG so
> a gpio vout. Also we needed some special handling to read phase current
> which I'm not seeing in the driver. So I would like to understand how
> the chip was tested?
> 
> Anyways, if Fred is ok with it I can just finish what I'm doing and send
> the patches. It would make sense to have something more complete on
> submission but I don't want to just "steal" the work already done.

Binding should be in such case posted complete, so probably not a
trivial device.

Best regards,
Krzysztof

Re: [PATCH 2/2] hwmon: (pmbus) Add driver for Analog Devices MAX20912 and MAX20916

[Nuno Sá]

On Wed, Jul 08, 2026 at 12:50:25PM +0200, Krzysztof Kozlowski wrote:
> On Wed, Jul 08, 2026 at 10:19:56AM +0100, Nuno Sá wrote:
> > On Tue, Jul 07, 2026 at 06:52:48AM -0700, Guenter Roeck wrote:
> > > On 7/7/26 05:26, Fred Chen wrote:
> > > > Add support for the Analog Devices MAX20912 and MAX20916 dual-output
> > > > multiphase voltage regulators with PMBus interfaces.
> > > > 
> > > > Signed-off-by: Fred Chen <fredchen.openbmc@gmail.com>
> > > 
> > > Please provide evidence that those chips actually exist.
> > > Internet search comes up blank. I'll need confirmation
> > > from someone at Analog.
> > 
> > Hi Guenter,
> > 
> > Well, in fact I'm in the middle of preparing a series that adds support
> > for:
> > 
> > "max20826"
> > "max20855b"
> > "max20908"
> > "max20912"
> > "max20916"
> > 
> > All the above parts have the datasheet under NDA. But before we had a
> > one page "datasheet" in analog.com but I guess that is gone! For context
> > I mainly did the base (core) driver for max20826 and then Alexis added
> > the other ones.
> > 
> > Not sure how to proceed... I can wait and then work on top of what Fred
> > has but this patch is very minimal when compared with what we have.
> > Like:
> > 
> > * No regulator support;
> > * No direct mode. The chip has two ways to access registers (paging and
> > * direct mode).
> > * No way to count how many phases we have or if RAIL_B (func[1]) is being used at
> > all.
> > 
> > 
> > Some other things more intriguing is that these chips, as far as I'm
> > aware (at least for max20826), always have bit 2 set in ON_OFF_CONFIG so
> > a gpio vout. Also we needed some special handling to read phase current
> > which I'm not seeing in the driver. So I would like to understand how
> > the chip was tested?
> > 
> > Anyways, if Fred is ok with it I can just finish what I'm doing and send
> > the patches. It would make sense to have something more complete on
> > submission but I don't want to just "steal" the work already done.
> 
> Binding should be in such case posted complete, so probably not a
> trivial device.

Yes, in my series bindings are not in trivial as we support the enable
gpios.

- Nuno Sá

Re: [PATCH 2/2] hwmon: (pmbus) Add driver for Analog Devices MAX20912 and MAX20916

[Guenter Roeck]

On 7/8/26 04:32, Nuno Sá wrote:
> On Wed, Jul 08, 2026 at 12:50:25PM +0200, Krzysztof Kozlowski wrote:
>> On Wed, Jul 08, 2026 at 10:19:56AM +0100, Nuno Sá wrote:
>>> On Tue, Jul 07, 2026 at 06:52:48AM -0700, Guenter Roeck wrote:
>>>> On 7/7/26 05:26, Fred Chen wrote:
>>>>> Add support for the Analog Devices MAX20912 and MAX20916 dual-output
>>>>> multiphase voltage regulators with PMBus interfaces.
>>>>>
>>>>> Signed-off-by: Fred Chen <fredchen.openbmc@gmail.com>
>>>>
>>>> Please provide evidence that those chips actually exist.
>>>> Internet search comes up blank. I'll need confirmation
>>>> from someone at Analog.
>>>
>>> Hi Guenter,
>>>
>>> Well, in fact I'm in the middle of preparing a series that adds support
>>> for:
>>>
>>> "max20826"
>>> "max20855b"
>>> "max20908"
>>> "max20912"
>>> "max20916"
>>>
>>> All the above parts have the datasheet under NDA. But before we had a
>>> one page "datasheet" in analog.com but I guess that is gone! For context
>>> I mainly did the base (core) driver for max20826 and then Alexis added
>>> the other ones.
>>>
>>> Not sure how to proceed... I can wait and then work on top of what Fred
>>> has but this patch is very minimal when compared with what we have.
>>> Like:
>>>
>>> * No regulator support;
>>> * No direct mode. The chip has two ways to access registers (paging and
>>> * direct mode).
>>> * No way to count how many phases we have or if RAIL_B (func[1]) is being used at
>>> all.
>>>
>>>
>>> Some other things more intriguing is that these chips, as far as I'm
>>> aware (at least for max20826), always have bit 2 set in ON_OFF_CONFIG so
>>> a gpio vout. Also we needed some special handling to read phase current
>>> which I'm not seeing in the driver. So I would like to understand how
>>> the chip was tested?
>>>
>>> Anyways, if Fred is ok with it I can just finish what I'm doing and send
>>> the patches. It would make sense to have something more complete on
>>> submission but I don't want to just "steal" the work already done.
>>
>> Binding should be in such case posted complete, so probably not a
>> trivial device.
> 
> Yes, in my series bindings are not in trivial as we support the enable
> gpios.
> 

Same question I asked before: What is your use case ?

Thanks,
Guenter

RE: [PATCH 2/2] hwmon: (pmbus) Add driver for Analog Devices MAX20912 and MAX20916

[Torreno, Alexis Czezar]

> On 7/8/26 04:32, Nuno Sá wrote:
> > On Wed, Jul 08, 2026 at 12:50:25PM +0200, Krzysztof Kozlowski wrote:
> >> On Wed, Jul 08, 2026 at 10:19:56AM +0100, Nuno Sá wrote:
> >>> On Tue, Jul 07, 2026 at 06:52:48AM -0700, Guenter Roeck wrote:
> >>>> On 7/7/26 05:26, Fred Chen wrote:
> >>>>> Add support for the Analog Devices MAX20912 and MAX20916
> >>>>> dual-output multiphase voltage regulators with PMBus interfaces.
> >>>>>
> >>>>> Signed-off-by: Fred Chen <fredchen.openbmc@gmail.com>
> >>>>
> >>>> Please provide evidence that those chips actually exist.
> >>>> Internet search comes up blank. I'll need confirmation from someone
> >>>> at Analog.
> >>>
> >>> Hi Guenter,
> >>>
> >>> Well, in fact I'm in the middle of preparing a series that adds
> >>> support
> >>> for:
> >>>
> >>> "max20826"
> >>> "max20855b"
> >>> "max20908"
> >>> "max20912"
> >>> "max20916"
> >>>
> >>> All the above parts have the datasheet under NDA. But before we had
> >>> a one page "datasheet" in analog.com but I guess that is gone! For
> >>> context I mainly did the base (core) driver for max20826 and then
> >>> Alexis added the other ones.
> >>>
> >>> Not sure how to proceed... I can wait and then work on top of what
> >>> Fred has but this patch is very minimal when compared with what we have.
> >>> Like:
> >>>
> >>> * No regulator support;
> >>> * No direct mode. The chip has two ways to access registers (paging
> >>> and
> >>> * direct mode).
> >>> * No way to count how many phases we have or if RAIL_B (func[1]) is
> >>> being used at all.
> >>>
> >>>
> >>> Some other things more intriguing is that these chips, as far as I'm
> >>> aware (at least for max20826), always have bit 2 set in
> >>> ON_OFF_CONFIG so a gpio vout. Also we needed some special handling
> >>> to read phase current which I'm not seeing in the driver. So I would
> >>> like to understand how the chip was tested?
> >>>
> >>> Anyways, if Fred is ok with it I can just finish what I'm doing and
> >>> send the patches. It would make sense to have something more
> >>> complete on submission but I don't want to just "steal" the work already
> done.
> >>
> >> Binding should be in such case posted complete, so probably not a
> >> trivial device.
> >
> > Yes, in my series bindings are not in trivial as we support the enable
> > gpios.
> >
> 
> Same question I asked before: What is your use case ?
> 

Hi Guenter,

Unlike my MAX20830 patches, for some reason these chips (not only Nuno's max20826)
hardwired the bit 2 in ON_OFF_CONFIG to '1'. This makes the use of gpio to enable the
device a requirement.  (as of the latest info given to us)

Regards,
Alexis

Re: [PATCH 2/2] hwmon: (pmbus) Add driver for Analog Devices MAX20912 and MAX20916

[Fred Chen]

Torreno, Alexis Czezar <AlexisCzezar.Torreno@analog.com> 於 2026年7月9日週四 上午8:59寫道：
>
> > On 7/8/26 04:32, Nuno Sá wrote:
> > > On Wed, Jul 08, 2026 at 12:50:25PM +0200, Krzysztof Kozlowski wrote:
> > >> On Wed, Jul 08, 2026 at 10:19:56AM +0100, Nuno Sá wrote:
> > >>> On Tue, Jul 07, 2026 at 06:52:48AM -0700, Guenter Roeck wrote:
> > >>>> On 7/7/26 05:26, Fred Chen wrote:
> > >>>>> Add support for the Analog Devices MAX20912 and MAX20916
> > >>>>> dual-output multiphase voltage regulators with PMBus interfaces.
> > >>>>>
> > >>>>> Signed-off-by: Fred Chen <fredchen.openbmc@gmail.com>
> > >>>>
> > >>>> Please provide evidence that those chips actually exist.
> > >>>> Internet search comes up blank. I'll need confirmation from someone
> > >>>> at Analog.
> > >>>
> > >>> Hi Guenter,
> > >>>
> > >>> Well, in fact I'm in the middle of preparing a series that adds
> > >>> support
> > >>> for:
> > >>>
> > >>> "max20826"
> > >>> "max20855b"
> > >>> "max20908"
> > >>> "max20912"
> > >>> "max20916"
> > >>>
> > >>> All the above parts have the datasheet under NDA. But before we had
> > >>> a one page "datasheet" in analog.com but I guess that is gone! For
> > >>> context I mainly did the base (core) driver for max20826 and then
> > >>> Alexis added the other ones.
> > >>>
> > >>> Not sure how to proceed... I can wait and then work on top of what
> > >>> Fred has but this patch is very minimal when compared with what we have.
> > >>> Like:
> > >>>
> > >>> * No regulator support;
> > >>> * No direct mode. The chip has two ways to access registers (paging
> > >>> and
> > >>> * direct mode).
> > >>> * No way to count how many phases we have or if RAIL_B (func[1]) is
> > >>> being used at all.
> > >>>
> > >>>
> > >>> Some other things more intriguing is that these chips, as far as I'm
> > >>> aware (at least for max20826), always have bit 2 set in
> > >>> ON_OFF_CONFIG so a gpio vout. Also we needed some special handling
> > >>> to read phase current which I'm not seeing in the driver. So I would
> > >>> like to understand how the chip was tested?
> > >>>
> > >>> Anyways, if Fred is ok with it I can just finish what I'm doing and
> > >>> send the patches. It would make sense to have something more
> > >>> complete on submission but I don't want to just "steal" the work already
> > done.
> > >>
> > >> Binding should be in such case posted complete, so probably not a
> > >> trivial device.
> > >
> > > Yes, in my series bindings are not in trivial as we support the enable
> > > gpios.
> > >
> >
> > Same question I asked before: What is your use case ?
> >
>
> Hi Guenter,
>
> Unlike my MAX20830 patches, for some reason these chips (not only Nuno's max20826)
> hardwired the bit 2 in ON_OFF_CONFIG to '1'. This makes the use of gpio to enable the
> device a requirement.  (as of the latest info given to us)
>
> Regards,
> Alexis

Hi Nuno,

Based on the MAX20912/16 specs on my hand, these chips do not support
PMBUS_PHASE (0x04). Furthermore, the spec only indicates support for VID mode
and does not provide m/b/r. Therefore, some of the features you mentioned might
be specific to the MAX20826 series.

Regarding enabling VOUT via GPIO, our platform handles this via the CPLD as
part of the hardware power sequencing. Managing this pin through the driver is
not a requirement for our system.

As for the testing, I have verified that the telemetry readings for both Rail A
and Rail B behave as expected. The driver reports valid data after system
power-on, and the readings drop to 0 properly after power-off.

It's possible my specs are outdated or that I'm missing some use cases. If
you plan to submit your more complete driver covering the MAX20912/16
soon, I'm more than willing to hold off on sending v2 patch.

Regards,
Fred

Re: [PATCH 2/2] hwmon: (pmbus) Add driver for Analog Devices MAX20912 and MAX20916

[Nuno Sá]

On Thu, Jul 09, 2026 at 03:23:55PM +0800, Fred Chen wrote:
> Torreno, Alexis Czezar <AlexisCzezar.Torreno@analog.com> 於 2026年7月9日週四 上午8:59寫道：
> >
> > > On 7/8/26 04:32, Nuno Sá wrote:
> > > > On Wed, Jul 08, 2026 at 12:50:25PM +0200, Krzysztof Kozlowski wrote:
> > > >> On Wed, Jul 08, 2026 at 10:19:56AM +0100, Nuno Sá wrote:
> > > >>> On Tue, Jul 07, 2026 at 06:52:48AM -0700, Guenter Roeck wrote:
> > > >>>> On 7/7/26 05:26, Fred Chen wrote:
> > > >>>>> Add support for the Analog Devices MAX20912 and MAX20916
> > > >>>>> dual-output multiphase voltage regulators with PMBus interfaces.
> > > >>>>>
> > > >>>>> Signed-off-by: Fred Chen <fredchen.openbmc@gmail.com>
> > > >>>>
> > > >>>> Please provide evidence that those chips actually exist.
> > > >>>> Internet search comes up blank. I'll need confirmation from someone
> > > >>>> at Analog.
> > > >>>
> > > >>> Hi Guenter,
> > > >>>
> > > >>> Well, in fact I'm in the middle of preparing a series that adds
> > > >>> support
> > > >>> for:
> > > >>>
> > > >>> "max20826"
> > > >>> "max20855b"
> > > >>> "max20908"
> > > >>> "max20912"
> > > >>> "max20916"
> > > >>>
> > > >>> All the above parts have the datasheet under NDA. But before we had
> > > >>> a one page "datasheet" in analog.com but I guess that is gone! For
> > > >>> context I mainly did the base (core) driver for max20826 and then
> > > >>> Alexis added the other ones.
> > > >>>
> > > >>> Not sure how to proceed... I can wait and then work on top of what
> > > >>> Fred has but this patch is very minimal when compared with what we have.
> > > >>> Like:
> > > >>>
> > > >>> * No regulator support;
> > > >>> * No direct mode. The chip has two ways to access registers (paging
> > > >>> and
> > > >>> * direct mode).
> > > >>> * No way to count how many phases we have or if RAIL_B (func[1]) is
> > > >>> being used at all.
> > > >>>
> > > >>>
> > > >>> Some other things more intriguing is that these chips, as far as I'm
> > > >>> aware (at least for max20826), always have bit 2 set in
> > > >>> ON_OFF_CONFIG so a gpio vout. Also we needed some special handling
> > > >>> to read phase current which I'm not seeing in the driver. So I would
> > > >>> like to understand how the chip was tested?
> > > >>>
> > > >>> Anyways, if Fred is ok with it I can just finish what I'm doing and
> > > >>> send the patches. It would make sense to have something more
> > > >>> complete on submission but I don't want to just "steal" the work already
> > > done.
> > > >>
> > > >> Binding should be in such case posted complete, so probably not a
> > > >> trivial device.
> > > >
> > > > Yes, in my series bindings are not in trivial as we support the enable
> > > > gpios.
> > > >
> > >
> > > Same question I asked before: What is your use case ?
> > >
> >
> > Hi Guenter,
> >
> > Unlike my MAX20830 patches, for some reason these chips (not only Nuno's max20826)
> > hardwired the bit 2 in ON_OFF_CONFIG to '1'. This makes the use of gpio to enable the
> > device a requirement.  (as of the latest info given to us)
> >
> > Regards,
> > Alexis
> 
> Hi Nuno,
> 
> Based on the MAX20912/16 specs on my hand, these chips do not support
> PMBUS_PHASE (0x04). Furthermore, the spec only indicates support for VID mode
> and does not provide m/b/r. Therefore, some of the features you mentioned might
> be specific to the MAX20826 series.

I see, phases are not supported using standard PMBUS.

> 
> Regarding enabling VOUT via GPIO, our platform handles this via the CPLD as
> part of the hardware power sequencing. Managing this pin through the driver is
> not a requirement for our system.

But we cannot assume all systems will behave like the above. But now i
do wonder about controlling the GPIOs in the driver. In your system you
clearly did not need to do it. In mine (testing with a rpi) I had to
use a GPIO (well I could have used hogs or pinctrl). But if you control the pin
you do gain the ability to turn off the regulator. If you don't it's always on
(which might be indeed the bulk of the real usecases for these systems).

> 
> As for the testing, I have verified that the telemetry readings for both Rail A
> and Rail B behave as expected. The driver reports valid data after system
> power-on, and the readings drop to 0 properly after power-off.
> 
> It's possible my specs are outdated or that I'm missing some use cases. If
> you plan to submit your more complete driver covering the MAX20912/16
> soon, I'm more than willing to hold off on sending v2 patch.
>

Sure, soon enough :)

- Nuno Sá

Re: [PATCH 2/2] hwmon: (pmbus) Add driver for Analog Devices MAX20912 and MAX20916

[Guenter Roeck]

On Thu, Jul 09, 2026 at 12:58:58AM +0000, Torreno, Alexis Czezar wrote:
> > >
> > > Yes, in my series bindings are not in trivial as we support the enable
> > > gpios.
> > >
> > 
> > Same question I asked before: What is your use case ?
> > 
> 
> Hi Guenter,
> 
> Unlike my MAX20830 patches, for some reason these chips (not only Nuno's max20826)
> hardwired the bit 2 in ON_OFF_CONFIG to '1'. This makes the use of gpio to enable the
> device a requirement.  (as of the latest info given to us)
> 

Outch, that hurts. Ok. I excpect that to be explained in the driver.

Thanks,
Guenter

Re: [PATCH 2/2] hwmon: (pmbus) Add driver for Analog Devices MAX20912 and MAX20916

[Guenter Roeck]

On Thu, Jul 09, 2026 at 03:23:55PM +0800, Fred Chen wrote:
> 
> Based on the MAX20912/16 specs on my hand, these chips do not support
> PMBUS_PHASE (0x04). Furthermore, the spec only indicates support for VID mode
> and does not provide m/b/r. Therefore, some of the features you mentioned might
> be specific to the MAX20826 series.

FWIW, phase support can be implemented in the chip driver. Other chips
such as MAX16601 don't support the standard phase command either.

> 
> Regarding enabling VOUT via GPIO, our platform handles this via the CPLD as
> part of the hardware power sequencing. Managing this pin through the driver is
> not a requirement for our system.

That would normally be the case, but if the chip mandates the use of the EN pin
the driver should support (but not mandate) it. I would not expect you to implement
it, though, if you can not test it. This functionality is critical enough that
it should be implemented and tested by someone with access to hardware using it.

Thanks,
Guenter

Re: [PATCH 2/2] hwmon: (pmbus) Add driver for Analog Devices MAX20912 and MAX20916

[Guenter Roeck]

On Thu, Jul 09, 2026 at 09:54:22AM +0100, Nuno Sá wrote:
> > 
> > Based on the MAX20912/16 specs on my hand, these chips do not support
> > PMBUS_PHASE (0x04). Furthermore, the spec only indicates support for VID mode
> > and does not provide m/b/r. Therefore, some of the features you mentioned might
> > be specific to the MAX20826 series.
> 
> I see, phases are not supported using standard PMBUS.
> 

As mentioned in my other e-mail, it can still be supported by the driver.
That is what the chip drivers are for, after all.

> > 
> > Regarding enabling VOUT via GPIO, our platform handles this via the CPLD as
> > part of the hardware power sequencing. Managing this pin through the driver is
> > not a requirement for our system.
> 
> But we cannot assume all systems will behave like the above. But now i
> do wonder about controlling the GPIOs in the driver. In your system you
> clearly did not need to do it. In mine (testing with a rpi) I had to
> use a GPIO (well I could have used hogs or pinctrl). But if you control the pin
> you do gain the ability to turn off the regulator. If you don't it's always on
> (which might be indeed the bulk of the real usecases for these systems).
> 
Agreed. I don't really like it, but if the chip and some specific hardware
mandate it, it should be supported. However, that code also needs to be
tested - an untested implementation would be worse than no implementation.

Note to anyone from Analog listening: It is really unfortunate that I,
as subsystem maintainer, do not have access to datasheets. That means I have
to rely on assumptions and can not really provide actionable feedback other
than guesswork based on the PMBus standard. That feedback may and likely
will miss essential details.

Thanks,
Guenter

Re: [PATCH 2/2] hwmon: (pmbus) Add driver for Analog Devices MAX20912 and MAX20916

[Nuno Sá]

On Thu, Jul 09, 2026 at 08:54:09AM -0700, Guenter Roeck wrote:
> On Thu, Jul 09, 2026 at 09:54:22AM +0100, Nuno Sá wrote:
> > > 
> > > Based on the MAX20912/16 specs on my hand, these chips do not support
> > > PMBUS_PHASE (0x04). Furthermore, the spec only indicates support for VID mode
> > > and does not provide m/b/r. Therefore, some of the features you mentioned might
> > > be specific to the MAX20826 series.
> > 
> > I see, phases are not supported using standard PMBUS.
> > 
> 
> As mentioned in my other e-mail, it can still be supported by the driver.
> That is what the chip drivers are for, after all.
> 
> > > 
> > > Regarding enabling VOUT via GPIO, our platform handles this via the CPLD as
> > > part of the hardware power sequencing. Managing this pin through the driver is
> > > not a requirement for our system.
> > 
> > But we cannot assume all systems will behave like the above. But now i
> > do wonder about controlling the GPIOs in the driver. In your system you
> > clearly did not need to do it. In mine (testing with a rpi) I had to
> > use a GPIO (well I could have used hogs or pinctrl). But if you control the pin
> > you do gain the ability to turn off the regulator. If you don't it's always on
> > (which might be indeed the bulk of the real usecases for these systems).
> > 
> Agreed. I don't really like it, but if the chip and some specific hardware
> mandate it, it should be supported. However, that code also needs to be
> tested - an untested implementation would be worse than no implementation.

That's how I tested it :). So from what I understand the preferred way
is to support these pins as optional? If they are not there we just
assume the pins are always enabled by some other means? In contrast to
what I have today which makes these pins mandatory!

> 
> Note to anyone from Analog listening: It is really unfortunate that I,
> as subsystem maintainer, do not have access to datasheets. That means I have
> to rely on assumptions and can not really provide actionable feedback other
> than guesswork based on the PMBus standard. That feedback may and likely
> will miss essential details.

I cannot make any promises but can at least raise this internally.

- Nuno Sá

Re: [PATCH 2/2] hwmon: (pmbus) Add driver for Analog Devices MAX20912 and MAX20916

[Nuno Sá]

On Thu, Jul 09, 2026 at 08:54:09AM -0700, Guenter Roeck wrote:
> On Thu, Jul 09, 2026 at 09:54:22AM +0100, Nuno Sá wrote:
> > > 
> > > Based on the MAX20912/16 specs on my hand, these chips do not support
> > > PMBUS_PHASE (0x04). Furthermore, the spec only indicates support for VID mode
> > > and does not provide m/b/r. Therefore, some of the features you mentioned might
> > > be specific to the MAX20826 series.
> > 
> > I see, phases are not supported using standard PMBUS.
> > 
> 
> As mentioned in my other e-mail, it can still be supported by the driver.
> That is what the chip drivers are for, after all.

Ah and if it was not clear... The driver I have in hands do support
reading phases. In fact we need a patch in the pmbus header to increase
the max number of phases as, at least, max20826 supports up to 16 phases just in
one rail (or 8 + 8)

- Nuno Sá
> 
> > > 
> > > Regarding enabling VOUT via GPIO, our platform handles this via the CPLD as
> > > part of the hardware power sequencing. Managing this pin through the driver is
> > > not a requirement for our system.
> > 
> > But we cannot assume all systems will behave like the above. But now i
> > do wonder about controlling the GPIOs in the driver. In your system you
> > clearly did not need to do it. In mine (testing with a rpi) I had to
> > use a GPIO (well I could have used hogs or pinctrl). But if you control the pin
> > you do gain the ability to turn off the regulator. If you don't it's always on
> > (which might be indeed the bulk of the real usecases for these systems).
> > 
> Agreed. I don't really like it, but if the chip and some specific hardware
> mandate it, it should be supported. However, that code also needs to be
> tested - an untested implementation would be worse than no implementation.
> 
> Note to anyone from Analog listening: It is really unfortunate that I,
> as subsystem maintainer, do not have access to datasheets. That means I have
> to rely on assumptions and can not really provide actionable feedback other
> than guesswork based on the PMBus standard. That feedback may and likely
> will miss essential details.
> 
> Thanks,
> Guenter

Re: [PATCH 2/2] hwmon: (pmbus) Add driver for Analog Devices MAX20912 and MAX20916

[Guenter Roeck]

On 7/9/26 09:09, Nuno Sá wrote:
> On Thu, Jul 09, 2026 at 08:54:09AM -0700, Guenter Roeck wrote:
>> On Thu, Jul 09, 2026 at 09:54:22AM +0100, Nuno Sá wrote:
>>>>
>>>> Based on the MAX20912/16 specs on my hand, these chips do not support
>>>> PMBUS_PHASE (0x04). Furthermore, the spec only indicates support for VID mode
>>>> and does not provide m/b/r. Therefore, some of the features you mentioned might
>>>> be specific to the MAX20826 series.
>>>
>>> I see, phases are not supported using standard PMBUS.
>>>
>>
>> As mentioned in my other e-mail, it can still be supported by the driver.
>> That is what the chip drivers are for, after all.
>>
>>>>
>>>> Regarding enabling VOUT via GPIO, our platform handles this via the CPLD as
>>>> part of the hardware power sequencing. Managing this pin through the driver is
>>>> not a requirement for our system.
>>>
>>> But we cannot assume all systems will behave like the above. But now i
>>> do wonder about controlling the GPIOs in the driver. In your system you
>>> clearly did not need to do it. In mine (testing with a rpi) I had to
>>> use a GPIO (well I could have used hogs or pinctrl). But if you control the pin
>>> you do gain the ability to turn off the regulator. If you don't it's always on
>>> (which might be indeed the bulk of the real usecases for these systems).
>>>
>> Agreed. I don't really like it, but if the chip and some specific hardware
>> mandate it, it should be supported. However, that code also needs to be
>> tested - an untested implementation would be worse than no implementation.
> 
> That's how I tested it :). So from what I understand the preferred way
> is to support these pins as optional? If they are not there we just
> assume the pins are always enabled by some other means? In contrast to
> what I have today which makes these pins mandatory!
> 

I had to go back a bit in mental history .... actually, the regulator code
in the PMBus core doesn't touch the ON_OFF_CONFIG register. It uses the
OPERATION command to enable/disable outputs. The reason is that the enable
pin and ON_OFF_CONFIG typically affect the entire chip, while the OPERATION
command only affects a single channel.

So far PMBus drivers typically don't touch ON_OFF_CONFIG. The ibm-cffps
driver supports writing it, but only through a debugfs file. The tda38640
driver supports writing it, but only because it does not (or not correctly)
support the OPERATION command. ON_OFF_CONFIG (if it is modified at all)
is normally set by the firmware or even in production (if the chip supports
non-volatile configuration). It is one of the "hairy" PMBus commands
which should be left alone if at all possible.

You can not make the property mandatory since most systems will neither
support nor need it since it is handled by hardware/firmware.
In many if not almost all cases there won't even _be_ a GPIO pin that
can be set by software.

Guenter