[PATCH v2 1/2] hwmon:(pmbus/tda38740a) TDA38740A Voltage Regulator Driver

[PATCH v2 1/2] hwmon:(pmbus/tda38740a) TDA38740A Voltage Regulator Driver

[ASHISH YADAV]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 7872 bytes --]

Add the pmbus driver for the Infineon TDA38740A/TDA38725A
DC-DC voltage regulator.

Signed-off-by: ASHISH YADAV <Ashish.Yadav@infineon.com>
---
Changes in v2:
 - Review comments address.
 - Another Patch for Devicetree binding submitted for Driver
   Documentation.
---
 drivers/hwmon/pmbus/Kconfig     |  16 +++
 drivers/hwmon/pmbus/Makefile    |   1 +
 drivers/hwmon/pmbus/tda38740a.c | 203 ++++++++++++++++++++++++++++++++
 3 files changed, 220 insertions(+)
 create mode 100644 drivers/hwmon/pmbus/tda38740a.c

diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
index f3fb94cebf1a..e7d7ff1b57df 100644
--- a/drivers/hwmon/pmbus/Kconfig
+++ b/drivers/hwmon/pmbus/Kconfig
@@ -602,6 +602,22 @@ config SENSORS_TDA38640_REGULATOR
 	  If you say yes here you get regulator support for Infineon
 	  TDA38640 as regulator.
 
+config SENSORS_TDA38740A
+	tristate "Infineon TDA38740A"
+	help
+	  If you say yes here you get hardware monitoring support for Infineon
+	  TDA38740A/25A.
+
+	  This driver can also be built as a module. If so, the module will
+	  be called tda38740a.
+
+config SENSORS_TDA38740A_REGULATOR
+	bool "Regulator support for TDA38740A and compatibles"
+	depends on SENSORS_TDA38740A && REGULATOR
+	help
+	  If you say yes here you get regulator support for Infineon
+	  TDA38740A/25A as regulator.
+
 config SENSORS_TPS25990
 	tristate "TI TPS25990"
 	help
diff --git a/drivers/hwmon/pmbus/Makefile b/drivers/hwmon/pmbus/Makefile
index 349a89b6d92e..f422c80cf3d8 100644
--- a/drivers/hwmon/pmbus/Makefile
+++ b/drivers/hwmon/pmbus/Makefile
@@ -58,6 +58,7 @@ obj-$(CONFIG_SENSORS_PXE1610)	+= pxe1610.o
 obj-$(CONFIG_SENSORS_Q54SJ108A2)	+= q54sj108a2.o
 obj-$(CONFIG_SENSORS_STPDDC60)	+= stpddc60.o
 obj-$(CONFIG_SENSORS_TDA38640)	+= tda38640.o
+obj-$(CONFIG_SENSORS_TDA38740A)  += tda38740a.o
 obj-$(CONFIG_SENSORS_TPS25990)	+= tps25990.o
 obj-$(CONFIG_SENSORS_TPS40422)	+= tps40422.o
 obj-$(CONFIG_SENSORS_TPS53679)	+= tps53679.o
diff --git a/drivers/hwmon/pmbus/tda38740a.c b/drivers/hwmon/pmbus/tda38740a.c
new file mode 100644
index 000000000000..b31e1b5c6916
--- /dev/null
+++ b/drivers/hwmon/pmbus/tda38740a.c
@@ -0,0 +1,203 @@
+// SPDX-License-Identifier: GPL-2.0+
+/**
+ * Hardware monitoring driver for Infineon Integrated-pol-voltage-regulators
+ * Driver for TDA38725A and TDA38740A
+ *
+ * Copyright (c) 2025 Infineon Technologies
+ */
+
+#include <linux/err.h>
+#include <linux/i2c.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/regulator/driver.h>
+#include "pmbus.h"
+
+#define TDA38725A_IC_DEVICE_ID "\xA9"
+#define TDA38740A_IC_DEVICE_ID "\xA8"
+
+static const struct i2c_device_id tda38740a_id[];
+
+enum chips { tda38725a, tda38740a };
+
+struct tda38740a_data {
+	enum chips id;
+	struct pmbus_driver_info info;
+	u32 vout_voltage_multiplier[2];
+};
+
+#define to_tda38740a_data(x) container_of(x, struct tda38740a_data, info)
+
+static const struct regulator_desc __maybe_unused tda38740a_reg_desc[] = {
+	PMBUS_REGULATOR("vout", 0),
+};
+
+static int tda38740a_read_word_data(struct i2c_client *client, int page,
+				    int phase, int reg)
+{
+	const struct pmbus_driver_info *info = pmbus_get_driver_info(client);
+	const struct tda38740a_data *data = to_tda38740a_data(info);
+	int ret;
+
+	/* Virtual PMBUS Command not supported */
+	if (reg >= PMBUS_VIRT_BASE)
+		return -ENXIO;
+
+	switch (reg) {
+	case PMBUS_READ_VOUT:
+		ret = pmbus_read_word_data(client, page, phase, reg);
+		if (ret < 0)
+			return ret;
+		ret = ((ret * data->vout_voltage_multiplier[0]) /
+		       data->vout_voltage_multiplier[1]);
+		break;
+	case PMBUS_VOUT_COMMAND:
+	case PMBUS_VOUT_MAX:
+	case PMBUS_VOUT_MARGIN_HIGH:
+	case PMBUS_VOUT_MARGIN_LOW:
+	case PMBUS_VOUT_TRANSITION_RATE:
+	case PMBUS_VOUT_DROOP:
+	case PMBUS_VOUT_SCALE_LOOP:
+	case PMBUS_VOUT_OV_FAULT_LIMIT:
+	case PMBUS_VOUT_UV_FAULT_LIMIT:
+	case PMBUS_IOUT_OC_FAULT_LIMIT:
+	case PMBUS_OT_FAULT_LIMIT:
+	case PMBUS_OT_WARN_LIMIT:
+	case PMBUS_VIN_OV_FAULT_LIMIT:
+	case PMBUS_STATUS_WORD:
+	case PMBUS_READ_VIN:
+	case PMBUS_READ_IIN:
+	case PMBUS_READ_IOUT:
+	case PMBUS_READ_TEMPERATURE_1:
+	case PMBUS_READ_POUT:
+	case PMBUS_READ_PIN:
+		ret = pmbus_read_word_data(client, page, phase, reg);
+		break;
+	default:
+		ret = -ENODATA;
+		break;
+	}
+	return ret;
+}
+
+static struct pmbus_driver_info tda38740a_info[] = {
+	[tda38740a] = {
+		.pages = 1,
+		.read_word_data = tda38740a_read_word_data,
+		.format[PSC_VOLTAGE_IN] = linear,
+		.format[PSC_VOLTAGE_OUT] = linear,
+		.format[PSC_CURRENT_OUT] = linear,
+		.format[PSC_CURRENT_IN] = linear,
+		.format[PSC_POWER] = linear,
+		.format[PSC_TEMPERATURE] = linear,
+
+		.func[0] = PMBUS_HAVE_VIN | PMBUS_HAVE_STATUS_INPUT
+			| PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP
+			| PMBUS_HAVE_IIN
+			| PMBUS_HAVE_VOUT | PMBUS_HAVE_STATUS_VOUT
+			| PMBUS_HAVE_IOUT | PMBUS_HAVE_STATUS_IOUT
+			| PMBUS_HAVE_POUT | PMBUS_HAVE_PIN,
+#if IS_ENABLED(CONFIG_SENSORS_TDA38740A_REGULATOR)
+		.num_regulators = 1,
+		.reg_desc = tda38740a_reg_desc,
+#endif
+	},
+};
+
+static int tda38740a_get_device_id(struct i2c_client *client)
+{
+	u8 device_id[I2C_SMBUS_BLOCK_MAX + 1];
+	enum chips id;
+	int status;
+
+	status = i2c_smbus_read_block_data(client, PMBUS_IC_DEVICE_ID,
+					   device_id);
+	if (status < 0 || status > 1) {
+		dev_err(&client->dev,
+			"Failed to read Device ID or unexpected/unsupported Device\n");
+		return -ENODEV;
+	}
+
+	if (!memcmp(TDA38725A_IC_DEVICE_ID, device_id, 1)) {
+		id = tda38725a;
+	} else if (!memcmp(TDA38740A_IC_DEVICE_ID, device_id, 1)) {
+		id = tda38740a;
+	} else {
+		dev_err(&client->dev, "Unsupported device with ID:%s\n",
+			device_id);
+		return -ENODEV;
+	}
+
+	return id;
+}
+
+static int tda38740a_probe(struct i2c_client *client)
+{
+	struct device *dev = &client->dev;
+	struct tda38740a_data *data;
+	int chip_id;
+
+	if (!i2c_check_functionality(client->adapter,
+				     I2C_FUNC_SMBUS_BYTE |
+					     I2C_FUNC_SMBUS_BYTE_DATA |
+					     I2C_FUNC_SMBUS_WORD_DATA |
+					     I2C_FUNC_SMBUS_BLOCK_DATA))
+		return -ENODEV;
+
+	chip_id = tda38740a_get_device_id(client);
+	if (chip_id < 0)
+		return chip_id;
+
+	data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+	data->id = chip_id;
+	memcpy(&data->info, &tda38740a_info[chip_id], sizeof(data->info));
+
+	if (!of_property_read_u32_array(client->dev.of_node, "infineon,vout-voltage-multiplier",
+					data->vout_voltage_multiplier,
+		    ARRAY_SIZE(data->vout_voltage_multiplier))) {
+		dev_info(&client->dev,
+			 "vout-voltage-multiplier from Device Tree:%d %d\n",
+			 data->vout_voltage_multiplier[0],
+			 data->vout_voltage_multiplier[1]);
+	} else {
+		dev_info(&client->dev,
+			 "vout-voltage-multiplier not available from Device Tree,using default values");
+		data->vout_voltage_multiplier[0] = 0x01;
+		data->vout_voltage_multiplier[1] = 0x01;
+	}
+
+	return pmbus_do_probe(client, &data->info);
+}
+
+static const struct i2c_device_id tda38740a_id[] = { { "tda38725a", tda38725a },
+						     { "tda38740a", tda38740a },
+						     {} };
+
+MODULE_DEVICE_TABLE(i2c, tda38740a_id);
+
+static const struct of_device_id __maybe_unused tda38740a_of_match[] = {
+	{ .compatible = "infineon,tda38725a", .data = (void *)tda38725a },
+	{ .compatible = "infineon,tda38740a", .data = (void *)tda38740a },
+	{}
+};
+
+MODULE_DEVICE_TABLE(of, tda38740a_of_match);
+
+static struct i2c_driver tda38740a_driver = {
+	.driver = {
+		.name = "tda38740a",
+		.of_match_table = of_match_ptr(tda38740a_of_match),
+	},
+	.probe = tda38740a_probe,
+	.id_table = tda38740a_id,
+};
+
+module_i2c_driver(tda38740a_driver);
+
+MODULE_AUTHOR("Ashish Yadav <Ashish.Yadav@infineon.com>");
+MODULE_DESCRIPTION("PMBus driver for Infineon TDA38725A/40A IPOL");
+MODULE_LICENSE("GPL");
+MODULE_IMPORT_NS("PMBUS");
-- 
2.39.5

[PATCH v2 2/2] dt-bindings: hwmon/pmbus: Add Infineon TDA38740A

[ASHISH YADAV]

Document the TDA38740A/25A device tree binding.

Signed-off-by: ASHISH YADAV <Ashish.Yadav@infineon.com>

---
Changes in v2:
 - Review comments address:
https://lore.kernel.org/all/2ee75453-0869-4348-ad92-f7ff71aca75d@kernel.org/

Driver code in review process:
https://www.spinics.net/lists/kernel/msg5985470.html
---
 .../hwmon/pmbus/infineon,tda38740a.yaml       | 81 +++++++++++++++++++
 1 file changed, 81 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/pmbus/infineon,tda38740a.yaml

diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/infineon,tda38740a.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/infineon,tda38740a.yaml
new file mode 100644
index 000000000000..cd4102350a15
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/pmbus/infineon,tda38740a.yaml
@@ -0,0 +1,81 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+
+$id: http://devicetree.org/schemas/hwmon/pmbus/infineon,tda38740a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Infineon TDA38740A and TDA38725A Synchronous Buck Regulator with I2C
+
+maintainers:
+  - ASHISH YADAV <Ashish.Yadav@infineon.com>
+
+description: |
+  The Infineon TDA38740A/TDA38725A is a 40A/25A Single-voltage Synchronous
+  Buck Regulator with I2C designed for Industrial use.
+
+  Datasheet:
+  https://www.infineon.com/assets/row/public/documents/24/49/infineon-tda38740a-tda38725a-datasheet-en.pdf
+
+properties:
+  compatible:
+    enum:
+      - infineon,tda38725a
+      - infineon,tda38740a
+
+  reg:
+    maxItems: 1
+
+  infineon,vout-voltage-multiplier:
+    description: |
+      TDA38740/25 pin strap parts are available in two flavors of 1:1 & 1:2
+      vout scale loop.
+      For the 1:1 vout_scale_loop version, there is no need for any resistor
+      divider as output voltage sense pins are directly connected to
+      the output.
+
+      For a 1:2 scale loop version, it is recommended to use 499 ohms each for
+      top and bottom across the feedback path.
+      However, in some applications customers tend to use an intentional
+      resistor divider across the output with a different divider ratio other
+      than 1:1 or 1:2 to alter the actual output voltage.
+
+      For example, if pin strap part is set to Vboot of 0.7V,they use a
+      resistor divider to generate 0.75V using the equation provided in
+      Section 13.3 of the datasheet.In this case, as there are only two
+      vout_scale_loop options of 1:1 and 1:2 that the IC can identify,
+      Read_Vout would still read as 0.7V in the telemetry and the baseboard
+      management controllers would use this telemetry data to monitor the
+      rail parameters leading to false tripping of the system.
+      This multiplier is used to offset the telemetry output voltage Read_Vout
+      so that the telemetry data is reported correctly to the monitoring
+      controller,in this example the multiplier would be 0.75/0.7 = 1.071.
+
+      This multiplier is required only for any external monitoring of the rail
+      output voltage. All the other Vout related parameters are used
+      internally by the IC and there is only a slight impact on the fault
+      thresholds.The impact can be calculated using equations in Section 13.3
+      of the datasheet.
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+    minItems: 2
+    maxItems: 2
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/irq.h>
+    i2c {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        hwmon@40 {
+            compatible = "infineon,tda38740a";
+            reg = <0x40>;
+            infineon,vout-voltage-multiplier = <75 70>;
+        };
+    };
-- 
2.39.5

Re: [PATCH v2 2/2] dt-bindings: hwmon/pmbus: Add Infineon TDA38740A

[Krzysztof Kozlowski]

On 07/01/2026 15:45, ASHISH YADAV wrote:
> Document the TDA38740A/25A device tree binding.
> 
> Signed-off-by: ASHISH YADAV <Ashish.Yadav@infineon.com>
> 
> ---
> Changes in v2:
>  - Review comments address:

You need to write here what you exactly changed.


> https://lore.kernel.org/all/2ee75453-0869-4348-ad92-f7ff71aca75d@kernel.org/
> 
> Driver code in review process:
> https://www.spinics.net/lists/kernel/msg5985470.html
> ---
>  .../hwmon/pmbus/infineon,tda38740a.yaml       | 81 +++++++++++++++++++
>  1 file changed, 81 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/hwmon/pmbus/infineon,tda38740a.yaml
> 
> diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/infineon,tda38740a.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/infineon,tda38740a.yaml
> new file mode 100644
> index 000000000000..cd4102350a15
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/pmbus/infineon,tda38740a.yaml
> @@ -0,0 +1,81 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +
> +$id: http://devicetree.org/schemas/hwmon/pmbus/infineon,tda38740a.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Infineon TDA38740A and TDA38725A Synchronous Buck Regulator with I2C
> +
> +maintainers:
> +  - ASHISH YADAV <Ashish.Yadav@infineon.com>
> +
> +description: |
> +  The Infineon TDA38740A/TDA38725A is a 40A/25A Single-voltage Synchronous
> +  Buck Regulator with I2C designed for Industrial use.
> +
> +  Datasheet:
> +  https://www.infineon.com/assets/row/public/documents/24/49/infineon-tda38740a-tda38725a-datasheet-en.pdf
> +
> +properties:
> +  compatible:
> +    enum:
> +      - infineon,tda38725a
> +      - infineon,tda38740a
> +
> +  reg:
> +    maxItems: 1
> +
> +  infineon,vout-voltage-multiplier:

vout of what? Of input supply? But there is no input supply... Maybe you
just want to set output regulator supply?


> +    description: |
> +      TDA38740/25 pin strap parts are available in two flavors of 1:1 & 1:2
> +      vout scale loop.
> +      For the 1:1 vout_scale_loop version, there is no need for any resistor
> +      divider as output voltage sense pins are directly connected to
> +      the output.
> +
> +      For a 1:2 scale loop version, it is recommended to use 499 ohms each for
> +      top and bottom across the feedback path.
> +      However, in some applications customers tend to use an intentional
> +      resistor divider across the output with a different divider ratio other
> +      than 1:1 or 1:2 to alter the actual output voltage.
> +
> +      For example, if pin strap part is set to Vboot of 0.7V,they use a
> +      resistor divider to generate 0.75V using the equation provided in
> +      Section 13.3 of the datasheet.In this case, as there are only two
> +      vout_scale_loop options of 1:1 and 1:2 that the IC can identify,
> +      Read_Vout would still read as 0.7V in the telemetry and the baseboard
> +      management controllers would use this telemetry data to monitor the
> +      rail parameters leading to false tripping of the system.
> +      This multiplier is used to offset the telemetry output voltage Read_Vout
> +      so that the telemetry data is reported correctly to the monitoring
> +      controller,in this example the multiplier would be 0.75/0.7 = 1.071.
> +
> +      This multiplier is required only for any external monitoring of the rail
> +      output voltage. All the other Vout related parameters are used
> +      internally by the IC and there is only a slight impact on the fault
> +      thresholds.The impact can be calculated using equations in Section 13.3
> +      of the datasheet.
> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> +    minItems: 2
> +    maxItems: 2
> +


So this was a regulator before, now it is not. Confusing... Parts of the
description are saying this is regulator, so you miss regulator.yaml
reference in top-level. Anyway, I am not doing full review with such
incomplete changelog.


Best regards,
Krzysztof

Re: [PATCH v2 2/2] dt-bindings: hwmon/pmbus: Add Infineon TDA38740A

[Krzysztof Kozlowski]

On Wed, Jan 07, 2026 at 08:15:07PM +0530, ASHISH YADAV wrote:
> Document the TDA38740A/25A device tree binding.
> 
> Signed-off-by: ASHISH YADAV <Ashish.Yadav@infineon.com>

Also, fails checkpatch on SoB difference.

Please organize the patch documenting the compatible (DT bindings)
before the patch using that compatible.
See also: https://elixir.bootlin.com/linux/v6.14-rc6/source/Documentation/devicetree/bindings/submitting-patches.rst#L46

Best regards,
Krzysztof

Re: [PATCH v2 2/2] dt-bindings: hwmon/pmbus: Add Infineon TDA38740A

[ashish yadav]

Hi Krzysztof,

Thanks for reviewing the patch and providing the valuable feedback.
I will generate the next set of patches (v3) with the review comments address.

I try to address the review comments with current patch which were received in :
https://lore.kernel.org/all/2ee75453-0869-4348-ad92-f7ff71aca75d@kernel.org/

The Driver code also submitted with this patch:
https://lore.kernel.org/all/20260107144507.46491-1-Ashish.Yadav@infineon.com/

With Best Regards
   Ashish Yadav

On Thu, Jan 8, 2026 at 2:24 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On Wed, Jan 07, 2026 at 08:15:07PM +0530, ASHISH YADAV wrote:
> > Document the TDA38740A/25A device tree binding.
> >
> > Signed-off-by: ASHISH YADAV <Ashish.Yadav@infineon.com>
>
> Also, fails checkpatch on SoB difference.
>
> Please organize the patch documenting the compatible (DT bindings)
> before the patch using that compatible.
> See also: https://elixir.bootlin.com/linux/v6.14-rc6/source/Documentation/devicetree/bindings/submitting-patches.rst#L46
>
> Best regards,
> Krzysztof
>

Re: [PATCH v2 2/2] dt-bindings: hwmon/pmbus: Add Infineon TDA38740A

[ashish yadav]

Hi Krzysztof,

Please find my response inline.

Thanks a lot for your time and feedback.

With Best Regards
  Ashish Yadav

On Wed, Jan 7, 2026 at 9:44 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 07/01/2026 15:45, ASHISH YADAV wrote:
> > Document the TDA38740A/25A device tree binding.
> >
> > Signed-off-by: ASHISH YADAV <Ashish.Yadav@infineon.com>
> >
> > ---
> > Changes in v2:
> >  - Review comments address:
>
> You need to write here what you exactly changed.
Sure,I will take care this in v3 version.
>
> > https://lore.kernel.org/all/2ee75453-0869-4348-ad92-f7ff71aca75d@kernel.org/
> >
> > Driver code in review process:
> > https://www.spinics.net/lists/kernel/msg5985470.html
> > ---
> >  .../hwmon/pmbus/infineon,tda38740a.yaml       | 81 +++++++++++++++++++
> >  1 file changed, 81 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/hwmon/pmbus/infineon,tda38740a.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/infineon,tda38740a.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/infineon,tda38740a.yaml
> > new file mode 100644
> > index 000000000000..cd4102350a15
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/hwmon/pmbus/infineon,tda38740a.yaml
> > @@ -0,0 +1,81 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +
> > +$id: http://devicetree.org/schemas/hwmon/pmbus/infineon,tda38740a.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Infineon TDA38740A and TDA38725A Synchronous Buck Regulator with I2C
> > +
> > +maintainers:
> > +  - ASHISH YADAV <Ashish.Yadav@infineon.com>
> > +
> > +description: |
> > +  The Infineon TDA38740A/TDA38725A is a 40A/25A Single-voltage Synchronous
> > +  Buck Regulator with I2C designed for Industrial use.
> > +
> > +  Datasheet:
> > +  https://www.infineon.com/assets/row/public/documents/24/49/infineon-tda38740a-tda38725a-datasheet-en.pdf
> > +
> > +properties:
> > +  compatible:
> > +    enum:
> > +      - infineon,tda38725a
> > +      - infineon,tda38740a
> > +
> > +  reg:
> > +    maxItems: 1
> > +
> > +  infineon,vout-voltage-multiplier:
>
> vout of what? Of input supply? But there is no input supply... Maybe you
> just want to set output regulator supply?

 Yes, output of regulator supply.
>
> > +    description: |
> > +      TDA38740/25 pin strap parts are available in two flavors of 1:1 & 1:2
> > +      vout scale loop.
> > +      For the 1:1 vout_scale_loop version, there is no need for any resistor
> > +      divider as output voltage sense pins are directly connected to
> > +      the output.
> > +
> > +      For a 1:2 scale loop version, it is recommended to use 499 ohms each for
> > +      top and bottom across the feedback path.
> > +      However, in some applications customers tend to use an intentional
> > +      resistor divider across the output with a different divider ratio other
> > +      than 1:1 or 1:2 to alter the actual output voltage.
> > +
> > +      For example, if pin strap part is set to Vboot of 0.7V,they use a
> > +      resistor divider to generate 0.75V using the equation provided in
> > +      Section 13.3 of the datasheet.In this case, as there are only two
> > +      vout_scale_loop options of 1:1 and 1:2 that the IC can identify,
> > +      Read_Vout would still read as 0.7V in the telemetry and the baseboard
> > +      management controllers would use this telemetry data to monitor the
> > +      rail parameters leading to false tripping of the system.
> > +      This multiplier is used to offset the telemetry output voltage Read_Vout
> > +      so that the telemetry data is reported correctly to the monitoring
> > +      controller,in this example the multiplier would be 0.75/0.7 = 1.071.
> > +
> > +      This multiplier is required only for any external monitoring of the rail
> > +      output voltage. All the other Vout related parameters are used
> > +      internally by the IC and there is only a slight impact on the fault
> > +      thresholds.The impact can be calculated using equations in Section 13.3
> > +      of the datasheet.
> > +    $ref: /schemas/types.yaml#/definitions/uint32-array
> > +    minItems: 2
> > +    maxItems: 2
> > +
>
>
> So this was a regulator before, now it is not. Confusing... Parts of the
> description are saying this is regulator, so you miss regulator.yaml
> reference in top-level. Anyway, I am not doing full review with such
> incomplete changelog.
>
Sorry for the inconvenience.
Regulator part is taken out as per review comments from:
https://lore.kernel.org/all/2ee75453-0869-4348-ad92-f7ff71aca75d@kernel.org/


>
> Best regards,
> Krzysztof

Re: [PATCH v2 1/2] hwmon:(pmbus/tda38740a) TDA38740A Voltage Regulator Driver

[ashish yadav]

Hi Guenter,

Could you please review the current patch.
Thanks for your time and valuable feedback in the previous patch.

You can find documentation (dt-bindings) of this driver here:
https://lkml.org/lkml/2026/1/7/1122

With Best Regards
   Ashish Yadav

  Ashish Yadav

On Wed, Jan 7, 2026 at 8:15 PM ASHISH YADAV <ashishyadav78@gmail.com> wrote:
>
> Add the pmbus driver for the Infineon TDA38740A/TDA38725A
> DC-DC voltage regulator.
>
> Signed-off-by: ASHISH YADAV <Ashish.Yadav@infineon.com>
> ---
> Changes in v2:
>  - Review comments address.
>  - Another Patch for Devicetree binding submitted for Driver
>    Documentation.
> ---
>  drivers/hwmon/pmbus/Kconfig     |  16 +++
>  drivers/hwmon/pmbus/Makefile    |   1 +
>  drivers/hwmon/pmbus/tda38740a.c | 203 ++++++++++++++++++++++++++++++++
>  3 files changed, 220 insertions(+)
>  create mode 100644 drivers/hwmon/pmbus/tda38740a.c
>
> diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
> index f3fb94cebf1a..e7d7ff1b57df 100644
> --- a/drivers/hwmon/pmbus/Kconfig
> +++ b/drivers/hwmon/pmbus/Kconfig
> @@ -602,6 +602,22 @@ config SENSORS_TDA38640_REGULATOR
>           If you say yes here you get regulator support for Infineon
>           TDA38640 as regulator.
>
> +config SENSORS_TDA38740A
> +       tristate "Infineon TDA38740A"
> +       help
> +         If you say yes here you get hardware monitoring support for Infineon
> +         TDA38740A/25A.
> +
> +         This driver can also be built as a module. If so, the module will
> +         be called tda38740a.
> +
> +config SENSORS_TDA38740A_REGULATOR
> +       bool "Regulator support for TDA38740A and compatibles"
> +       depends on SENSORS_TDA38740A && REGULATOR
> +       help
> +         If you say yes here you get regulator support for Infineon
> +         TDA38740A/25A as regulator.
> +
>  config SENSORS_TPS25990
>         tristate "TI TPS25990"
>         help
> diff --git a/drivers/hwmon/pmbus/Makefile b/drivers/hwmon/pmbus/Makefile
> index 349a89b6d92e..f422c80cf3d8 100644
> --- a/drivers/hwmon/pmbus/Makefile
> +++ b/drivers/hwmon/pmbus/Makefile
> @@ -58,6 +58,7 @@ obj-$(CONFIG_SENSORS_PXE1610) += pxe1610.o
>  obj-$(CONFIG_SENSORS_Q54SJ108A2)       += q54sj108a2.o
>  obj-$(CONFIG_SENSORS_STPDDC60) += stpddc60.o
>  obj-$(CONFIG_SENSORS_TDA38640) += tda38640.o
> +obj-$(CONFIG_SENSORS_TDA38740A)  += tda38740a.o
>  obj-$(CONFIG_SENSORS_TPS25990) += tps25990.o
>  obj-$(CONFIG_SENSORS_TPS40422) += tps40422.o
>  obj-$(CONFIG_SENSORS_TPS53679) += tps53679.o
> diff --git a/drivers/hwmon/pmbus/tda38740a.c b/drivers/hwmon/pmbus/tda38740a.c
> new file mode 100644
> index 000000000000..b31e1b5c6916
> --- /dev/null
> +++ b/drivers/hwmon/pmbus/tda38740a.c
> @@ -0,0 +1,203 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/**
> + * Hardware monitoring driver for Infineon Integrated-pol-voltage-regulators
> + * Driver for TDA38725A and TDA38740A
> + *
> + * Copyright (c) 2025 Infineon Technologies
> + */
> +
> +#include <linux/err.h>
> +#include <linux/i2c.h>
> +#include <linux/init.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/regulator/driver.h>
> +#include "pmbus.h"
> +
> +#define TDA38725A_IC_DEVICE_ID "\xA9"
> +#define TDA38740A_IC_DEVICE_ID "\xA8"
> +
> +static const struct i2c_device_id tda38740a_id[];
> +
> +enum chips { tda38725a, tda38740a };
> +
> +struct tda38740a_data {
> +       enum chips id;
> +       struct pmbus_driver_info info;
> +       u32 vout_voltage_multiplier[2];
> +};
> +
> +#define to_tda38740a_data(x) container_of(x, struct tda38740a_data, info)
> +
> +static const struct regulator_desc __maybe_unused tda38740a_reg_desc[] = {
> +       PMBUS_REGULATOR("vout", 0),
> +};
> +
> +static int tda38740a_read_word_data(struct i2c_client *client, int page,
> +                                   int phase, int reg)
> +{
> +       const struct pmbus_driver_info *info = pmbus_get_driver_info(client);
> +       const struct tda38740a_data *data = to_tda38740a_data(info);
> +       int ret;
> +
> +       /* Virtual PMBUS Command not supported */
> +       if (reg >= PMBUS_VIRT_BASE)
> +               return -ENXIO;
> +
> +       switch (reg) {
> +       case PMBUS_READ_VOUT:
> +               ret = pmbus_read_word_data(client, page, phase, reg);
> +               if (ret < 0)
> +                       return ret;
> +               ret = ((ret * data->vout_voltage_multiplier[0]) /
> +                      data->vout_voltage_multiplier[1]);
> +               break;
> +       case PMBUS_VOUT_COMMAND:
> +       case PMBUS_VOUT_MAX:
> +       case PMBUS_VOUT_MARGIN_HIGH:
> +       case PMBUS_VOUT_MARGIN_LOW:
> +       case PMBUS_VOUT_TRANSITION_RATE:
> +       case PMBUS_VOUT_DROOP:
> +       case PMBUS_VOUT_SCALE_LOOP:
> +       case PMBUS_VOUT_OV_FAULT_LIMIT:
> +       case PMBUS_VOUT_UV_FAULT_LIMIT:
> +       case PMBUS_IOUT_OC_FAULT_LIMIT:
> +       case PMBUS_OT_FAULT_LIMIT:
> +       case PMBUS_OT_WARN_LIMIT:
> +       case PMBUS_VIN_OV_FAULT_LIMIT:
> +       case PMBUS_STATUS_WORD:
> +       case PMBUS_READ_VIN:
> +       case PMBUS_READ_IIN:
> +       case PMBUS_READ_IOUT:
> +       case PMBUS_READ_TEMPERATURE_1:
> +       case PMBUS_READ_POUT:
> +       case PMBUS_READ_PIN:
> +               ret = pmbus_read_word_data(client, page, phase, reg);
> +               break;
> +       default:
> +               ret = -ENODATA;
> +               break;
> +       }
> +       return ret;
> +}
> +
> +static struct pmbus_driver_info tda38740a_info[] = {
> +       [tda38740a] = {
> +               .pages = 1,
> +               .read_word_data = tda38740a_read_word_data,
> +               .format[PSC_VOLTAGE_IN] = linear,
> +               .format[PSC_VOLTAGE_OUT] = linear,
> +               .format[PSC_CURRENT_OUT] = linear,
> +               .format[PSC_CURRENT_IN] = linear,
> +               .format[PSC_POWER] = linear,
> +               .format[PSC_TEMPERATURE] = linear,
> +
> +               .func[0] = PMBUS_HAVE_VIN | PMBUS_HAVE_STATUS_INPUT
> +                       | PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP
> +                       | PMBUS_HAVE_IIN
> +                       | PMBUS_HAVE_VOUT | PMBUS_HAVE_STATUS_VOUT
> +                       | PMBUS_HAVE_IOUT | PMBUS_HAVE_STATUS_IOUT
> +                       | PMBUS_HAVE_POUT | PMBUS_HAVE_PIN,
> +#if IS_ENABLED(CONFIG_SENSORS_TDA38740A_REGULATOR)
> +               .num_regulators = 1,
> +               .reg_desc = tda38740a_reg_desc,
> +#endif
> +       },
> +};
> +
> +static int tda38740a_get_device_id(struct i2c_client *client)
> +{
> +       u8 device_id[I2C_SMBUS_BLOCK_MAX + 1];
> +       enum chips id;
> +       int status;
> +
> +       status = i2c_smbus_read_block_data(client, PMBUS_IC_DEVICE_ID,
> +                                          device_id);
> +       if (status < 0 || status > 1) {
> +               dev_err(&client->dev,
> +                       "Failed to read Device ID or unexpected/unsupported Device\n");
> +               return -ENODEV;
> +       }
> +
> +       if (!memcmp(TDA38725A_IC_DEVICE_ID, device_id, 1)) {
> +               id = tda38725a;
> +       } else if (!memcmp(TDA38740A_IC_DEVICE_ID, device_id, 1)) {
> +               id = tda38740a;
> +       } else {
> +               dev_err(&client->dev, "Unsupported device with ID:%s\n",
> +                       device_id);
> +               return -ENODEV;
> +       }
> +
> +       return id;
> +}
> +
> +static int tda38740a_probe(struct i2c_client *client)
> +{
> +       struct device *dev = &client->dev;
> +       struct tda38740a_data *data;
> +       int chip_id;
> +
> +       if (!i2c_check_functionality(client->adapter,
> +                                    I2C_FUNC_SMBUS_BYTE |
> +                                            I2C_FUNC_SMBUS_BYTE_DATA |
> +                                            I2C_FUNC_SMBUS_WORD_DATA |
> +                                            I2C_FUNC_SMBUS_BLOCK_DATA))
> +               return -ENODEV;
> +
> +       chip_id = tda38740a_get_device_id(client);
> +       if (chip_id < 0)
> +               return chip_id;
> +
> +       data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> +       if (!data)
> +               return -ENOMEM;
> +       data->id = chip_id;
> +       memcpy(&data->info, &tda38740a_info[chip_id], sizeof(data->info));
> +
> +       if (!of_property_read_u32_array(client->dev.of_node, "infineon,vout-voltage-multiplier",
> +                                       data->vout_voltage_multiplier,
> +                   ARRAY_SIZE(data->vout_voltage_multiplier))) {
> +               dev_info(&client->dev,
> +                        "vout-voltage-multiplier from Device Tree:%d %d\n",
> +                        data->vout_voltage_multiplier[0],
> +                        data->vout_voltage_multiplier[1]);
> +       } else {
> +               dev_info(&client->dev,
> +                        "vout-voltage-multiplier not available from Device Tree,using default values");
> +               data->vout_voltage_multiplier[0] = 0x01;
> +               data->vout_voltage_multiplier[1] = 0x01;
> +       }
> +
> +       return pmbus_do_probe(client, &data->info);
> +}
> +
> +static const struct i2c_device_id tda38740a_id[] = { { "tda38725a", tda38725a },
> +                                                    { "tda38740a", tda38740a },
> +                                                    {} };
> +
> +MODULE_DEVICE_TABLE(i2c, tda38740a_id);
> +
> +static const struct of_device_id __maybe_unused tda38740a_of_match[] = {
> +       { .compatible = "infineon,tda38725a", .data = (void *)tda38725a },
> +       { .compatible = "infineon,tda38740a", .data = (void *)tda38740a },
> +       {}
> +};
> +
> +MODULE_DEVICE_TABLE(of, tda38740a_of_match);
> +
> +static struct i2c_driver tda38740a_driver = {
> +       .driver = {
> +               .name = "tda38740a",
> +               .of_match_table = of_match_ptr(tda38740a_of_match),
> +       },
> +       .probe = tda38740a_probe,
> +       .id_table = tda38740a_id,
> +};
> +
> +module_i2c_driver(tda38740a_driver);
> +
> +MODULE_AUTHOR("Ashish Yadav <Ashish.Yadav@infineon.com>");
> +MODULE_DESCRIPTION("PMBus driver for Infineon TDA38725A/40A IPOL");
> +MODULE_LICENSE("GPL");
> +MODULE_IMPORT_NS("PMBUS");
> --
> 2.39.5
>

Re: [PATCH v2 2/2] dt-bindings: hwmon/pmbus: Add Infineon TDA38740A

[Guenter Roeck]

On 1/7/26 06:45, ASHISH YADAV wrote:
> Document the TDA38740A/25A device tree binding.
> 
> Signed-off-by: ASHISH YADAV <Ashish.Yadav@infineon.com>
> 
> ---
> Changes in v2:
>   - Review comments address:
> https://lore.kernel.org/all/2ee75453-0869-4348-ad92-f7ff71aca75d@kernel.org/
> 

That is not a change log.

Guenter

> Driver code in review process:
> https://www.spinics.net/lists/kernel/msg5985470.html
> ---
>   .../hwmon/pmbus/infineon,tda38740a.yaml       | 81 +++++++++++++++++++
>   1 file changed, 81 insertions(+)
>   create mode 100644 Documentation/devicetree/bindings/hwmon/pmbus/infineon,tda38740a.yaml
> 
> diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/infineon,tda38740a.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/infineon,tda38740a.yaml
> new file mode 100644
> index 000000000000..cd4102350a15
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/pmbus/infineon,tda38740a.yaml
> @@ -0,0 +1,81 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +
> +$id: http://devicetree.org/schemas/hwmon/pmbus/infineon,tda38740a.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Infineon TDA38740A and TDA38725A Synchronous Buck Regulator with I2C
> +
> +maintainers:
> +  - ASHISH YADAV <Ashish.Yadav@infineon.com>
> +
> +description: |
> +  The Infineon TDA38740A/TDA38725A is a 40A/25A Single-voltage Synchronous
> +  Buck Regulator with I2C designed for Industrial use.
> +
> +  Datasheet:
> +  https://www.infineon.com/assets/row/public/documents/24/49/infineon-tda38740a-tda38725a-datasheet-en.pdf
> +
> +properties:
> +  compatible:
> +    enum:
> +      - infineon,tda38725a
> +      - infineon,tda38740a
> +
> +  reg:
> +    maxItems: 1
> +
> +  infineon,vout-voltage-multiplier:
> +    description: |
> +      TDA38740/25 pin strap parts are available in two flavors of 1:1 & 1:2
> +      vout scale loop.
> +      For the 1:1 vout_scale_loop version, there is no need for any resistor
> +      divider as output voltage sense pins are directly connected to
> +      the output.
> +
> +      For a 1:2 scale loop version, it is recommended to use 499 ohms each for
> +      top and bottom across the feedback path.
> +      However, in some applications customers tend to use an intentional
> +      resistor divider across the output with a different divider ratio other
> +      than 1:1 or 1:2 to alter the actual output voltage.
> +
> +      For example, if pin strap part is set to Vboot of 0.7V,they use a
> +      resistor divider to generate 0.75V using the equation provided in
> +      Section 13.3 of the datasheet.In this case, as there are only two
> +      vout_scale_loop options of 1:1 and 1:2 that the IC can identify,
> +      Read_Vout would still read as 0.7V in the telemetry and the baseboard
> +      management controllers would use this telemetry data to monitor the
> +      rail parameters leading to false tripping of the system.
> +      This multiplier is used to offset the telemetry output voltage Read_Vout
> +      so that the telemetry data is reported correctly to the monitoring
> +      controller,in this example the multiplier would be 0.75/0.7 = 1.071.
> +
> +      This multiplier is required only for any external monitoring of the rail
> +      output voltage. All the other Vout related parameters are used
> +      internally by the IC and there is only a slight impact on the fault
> +      thresholds.The impact can be calculated using equations in Section 13.3
> +      of the datasheet.
> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> +    minItems: 2
> +    maxItems: 2
> +
> +required:
> +  - compatible
> +  - reg
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/interrupt-controller/irq.h>
> +    i2c {
> +        #address-cells = <1>;
> +        #size-cells = <0>;
> +
> +        hwmon@40 {
> +            compatible = "infineon,tda38740a";
> +            reg = <0x40>;
> +            infineon,vout-voltage-multiplier = <75 70>;
> +        };
> +    };

Re: [PATCH v2 1/2] hwmon:(pmbus/tda38740a) TDA38740A Voltage Regulator Driver

[Guenter Roeck]

On 1/7/26 06:45, ASHISH YADAV wrote:
> Add the pmbus driver for the Infineon TDA38740A/TDA38725A
> DC-DC voltage regulator.
> 
> Signed-off-by: ASHISH YADAV <Ashish.Yadav@infineon.com>
> ---
> Changes in v2:
>   - Review comments address.

That is not a change log.

>   - Another Patch for Devicetree binding submitted for Driver
>     Documentation.
> ---
>   drivers/hwmon/pmbus/Kconfig     |  16 +++
>   drivers/hwmon/pmbus/Makefile    |   1 +
>   drivers/hwmon/pmbus/tda38740a.c | 203 ++++++++++++++++++++++++++++++++

Documentation is missing.

>   3 files changed, 220 insertions(+)
>   create mode 100644 drivers/hwmon/pmbus/tda38740a.c
> 
> diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
> index f3fb94cebf1a..e7d7ff1b57df 100644
> --- a/drivers/hwmon/pmbus/Kconfig
> +++ b/drivers/hwmon/pmbus/Kconfig
> @@ -602,6 +602,22 @@ config SENSORS_TDA38640_REGULATOR
>   	  If you say yes here you get regulator support for Infineon
>   	  TDA38640 as regulator.
>   
> +config SENSORS_TDA38740A
> +	tristate "Infineon TDA38740A"
> +	help
> +	  If you say yes here you get hardware monitoring support for Infineon
> +	  TDA38740A/25A.
> +
> +	  This driver can also be built as a module. If so, the module will
> +	  be called tda38740a.
> +
> +config SENSORS_TDA38740A_REGULATOR
> +	bool "Regulator support for TDA38740A and compatibles"
> +	depends on SENSORS_TDA38740A && REGULATOR
> +	help
> +	  If you say yes here you get regulator support for Infineon
> +	  TDA38740A/25A as regulator.
> +
>   config SENSORS_TPS25990
>   	tristate "TI TPS25990"
>   	help
> diff --git a/drivers/hwmon/pmbus/Makefile b/drivers/hwmon/pmbus/Makefile
> index 349a89b6d92e..f422c80cf3d8 100644
> --- a/drivers/hwmon/pmbus/Makefile
> +++ b/drivers/hwmon/pmbus/Makefile
> @@ -58,6 +58,7 @@ obj-$(CONFIG_SENSORS_PXE1610)	+= pxe1610.o
>   obj-$(CONFIG_SENSORS_Q54SJ108A2)	+= q54sj108a2.o
>   obj-$(CONFIG_SENSORS_STPDDC60)	+= stpddc60.o
>   obj-$(CONFIG_SENSORS_TDA38640)	+= tda38640.o
> +obj-$(CONFIG_SENSORS_TDA38740A)  += tda38740a.o
>   obj-$(CONFIG_SENSORS_TPS25990)	+= tps25990.o
>   obj-$(CONFIG_SENSORS_TPS40422)	+= tps40422.o
>   obj-$(CONFIG_SENSORS_TPS53679)	+= tps53679.o
> diff --git a/drivers/hwmon/pmbus/tda38740a.c b/drivers/hwmon/pmbus/tda38740a.c
> new file mode 100644
> index 000000000000..b31e1b5c6916
> --- /dev/null
> +++ b/drivers/hwmon/pmbus/tda38740a.c
> @@ -0,0 +1,203 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/**
> + * Hardware monitoring driver for Infineon Integrated-pol-voltage-regulators
> + * Driver for TDA38725A and TDA38740A
> + *
> + * Copyright (c) 2025 Infineon Technologies
> + */
> +
> +#include <linux/err.h>
> +#include <linux/i2c.h>
> +#include <linux/init.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/regulator/driver.h>
> +#include "pmbus.h"
> +
> +#define TDA38725A_IC_DEVICE_ID "\xA9"
> +#define TDA38740A_IC_DEVICE_ID "\xA8"
> +
> +static const struct i2c_device_id tda38740a_id[];
> +
> +enum chips { tda38725a, tda38740a };
> +
> +struct tda38740a_data {
> +	enum chips id;
> +	struct pmbus_driver_info info;
> +	u32 vout_voltage_multiplier[2];
> +};
> +
> +#define to_tda38740a_data(x) container_of(x, struct tda38740a_data, info)
> +
> +static const struct regulator_desc __maybe_unused tda38740a_reg_desc[] = {
> +	PMBUS_REGULATOR("vout", 0),
> +};
> +
> +static int tda38740a_read_word_data(struct i2c_client *client, int page,
> +				    int phase, int reg)
> +{
> +	const struct pmbus_driver_info *info = pmbus_get_driver_info(client);
> +	const struct tda38740a_data *data = to_tda38740a_data(info);
> +	int ret;
> +
> +	/* Virtual PMBUS Command not supported */
> +	if (reg >= PMBUS_VIRT_BASE)
> +		return -ENXIO;
> +

Why is this needed (instead of just returning -ENODATA) ?

> +	switch (reg) {
> +	case PMBUS_READ_VOUT:
> +		ret = pmbus_read_word_data(client, page, phase, reg);
> +		if (ret < 0)
> +			return ret;
> +		ret = ((ret * data->vout_voltage_multiplier[0]) /
> +		       data->vout_voltage_multiplier[1]);

The need for this, especially why it would only be needed for PMBUS_READ_VOUT
but not for any other VOUT related commands, is still insufficiently explained
(and I failed to understand the rationale provided earlier).

> +		break;
> +	case PMBUS_VOUT_COMMAND:
> +	case PMBUS_VOUT_MAX:
> +	case PMBUS_VOUT_MARGIN_HIGH:
> +	case PMBUS_VOUT_MARGIN_LOW:
> +	case PMBUS_VOUT_TRANSITION_RATE:
> +	case PMBUS_VOUT_DROOP:
> +	case PMBUS_VOUT_SCALE_LOOP:
> +	case PMBUS_VOUT_OV_FAULT_LIMIT:
> +	case PMBUS_VOUT_UV_FAULT_LIMIT:
> +	case PMBUS_IOUT_OC_FAULT_LIMIT:
> +	case PMBUS_OT_FAULT_LIMIT:
> +	case PMBUS_OT_WARN_LIMIT:
> +	case PMBUS_VIN_OV_FAULT_LIMIT:
> +	case PMBUS_STATUS_WORD:
> +	case PMBUS_READ_VIN:
> +	case PMBUS_READ_IIN:
> +	case PMBUS_READ_IOUT:
> +	case PMBUS_READ_TEMPERATURE_1:
> +	case PMBUS_READ_POUT:
> +	case PMBUS_READ_PIN:
> +		ret = pmbus_read_word_data(client, page, phase, reg);

I fail to see why this would be necessary. Just return -ENODATA.

> +		break;
> +	default:
> +		ret = -ENODATA;
> +		break;
> +	}
> +	return ret;
> +}
> +
> +static struct pmbus_driver_info tda38740a_info[] = {
> +	[tda38740a] = {
> +		.pages = 1,
> +		.read_word_data = tda38740a_read_word_data,
> +		.format[PSC_VOLTAGE_IN] = linear,
> +		.format[PSC_VOLTAGE_OUT] = linear,
> +		.format[PSC_CURRENT_OUT] = linear,
> +		.format[PSC_CURRENT_IN] = linear,
> +		.format[PSC_POWER] = linear,
> +		.format[PSC_TEMPERATURE] = linear,
> +
> +		.func[0] = PMBUS_HAVE_VIN | PMBUS_HAVE_STATUS_INPUT
> +			| PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP
> +			| PMBUS_HAVE_IIN
> +			| PMBUS_HAVE_VOUT | PMBUS_HAVE_STATUS_VOUT
> +			| PMBUS_HAVE_IOUT | PMBUS_HAVE_STATUS_IOUT
> +			| PMBUS_HAVE_POUT | PMBUS_HAVE_PIN,
> +#if IS_ENABLED(CONFIG_SENSORS_TDA38740A_REGULATOR)
> +		.num_regulators = 1,
> +		.reg_desc = tda38740a_reg_desc,
> +#endif
> +	},
> +};
> +
> +static int tda38740a_get_device_id(struct i2c_client *client)
> +{
> +	u8 device_id[I2C_SMBUS_BLOCK_MAX + 1];
> +	enum chips id;
> +	int status;
> +
> +	status = i2c_smbus_read_block_data(client, PMBUS_IC_DEVICE_ID,
> +					   device_id);
> +	if (status < 0 || status > 1) {
> +		dev_err(&client->dev,
> +			"Failed to read Device ID or unexpected/unsupported Device\n");

How about printing the device ID here if it is unsupported ?
It could be printed as hex string.

> +		return -ENODEV;
> +	}
> +
> +	if (!memcmp(TDA38725A_IC_DEVICE_ID, device_id, 1)) {
> +		id = tda38725a;
> +	} else if (!memcmp(TDA38740A_IC_DEVICE_ID, device_id, 1)) {
> +		id = tda38740a;
> +	} else {
> +		dev_err(&client->dev, "Unsupported device with ID:%s\n",
> +			device_id);

device_id is not terminated, and it is not a user readable string.
It should be printed as hex string, or as hex byte (0xXX).

> +		return -ENODEV;
> +	}
> +
> +	return id;
> +}
> +
> +static int tda38740a_probe(struct i2c_client *client)
> +{
> +	struct device *dev = &client->dev;
> +	struct tda38740a_data *data;
> +	int chip_id;
> +
> +	if (!i2c_check_functionality(client->adapter,
> +				     I2C_FUNC_SMBUS_BYTE |
> +					     I2C_FUNC_SMBUS_BYTE_DATA |
> +					     I2C_FUNC_SMBUS_WORD_DATA |
> +					     I2C_FUNC_SMBUS_BLOCK_DATA))
> +		return -ENODEV;
> +
> +	chip_id = tda38740a_get_device_id(client);
> +	if (chip_id < 0)
> +		return chip_id;
> +
> +	data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> +	if (!data)
> +		return -ENOMEM;
> +	data->id = chip_id;
> +	memcpy(&data->info, &tda38740a_info[chip_id], sizeof(data->info));
> +
> +	if (!of_property_read_u32_array(client->dev.of_node, "infineon,vout-voltage-multiplier",
> +					data->vout_voltage_multiplier,
> +		    ARRAY_SIZE(data->vout_voltage_multiplier))) {
> +		dev_info(&client->dev,
> +			 "vout-voltage-multiplier from Device Tree:%d %d\n",
> +			 data->vout_voltage_multiplier[0],
> +			 data->vout_voltage_multiplier[1]);
> +	} else {
> +		dev_info(&client->dev,
> +			 "vout-voltage-multiplier not available from Device Tree,using default values");
> +		data->vout_voltage_multiplier[0] = 0x01;
> +		data->vout_voltage_multiplier[1] = 0x01;
> +	}
> +
> +	return pmbus_do_probe(client, &data->info);
> +}
> +
> +static const struct i2c_device_id tda38740a_id[] = { { "tda38725a", tda38725a },
> +						     { "tda38740a", tda38740a },
> +						     {} };
> +
> +MODULE_DEVICE_TABLE(i2c, tda38740a_id);
> +
> +static const struct of_device_id __maybe_unused tda38740a_of_match[] = {
> +	{ .compatible = "infineon,tda38725a", .data = (void *)tda38725a },
> +	{ .compatible = "infineon,tda38740a", .data = (void *)tda38740a },
> +	{}
> +};
> +
> +MODULE_DEVICE_TABLE(of, tda38740a_of_match);
> +
> +static struct i2c_driver tda38740a_driver = {
> +	.driver = {
> +		.name = "tda38740a",
> +		.of_match_table = of_match_ptr(tda38740a_of_match),
> +	},
> +	.probe = tda38740a_probe,
> +	.id_table = tda38740a_id,
> +};
> +
> +module_i2c_driver(tda38740a_driver);
> +
> +MODULE_AUTHOR("Ashish Yadav <Ashish.Yadav@infineon.com>");
> +MODULE_DESCRIPTION("PMBus driver for Infineon TDA38725A/40A IPOL");
> +MODULE_LICENSE("GPL");
> +MODULE_IMPORT_NS("PMBUS");

Re: [PATCH v2 1/2] hwmon:(pmbus/tda38740a) TDA38740A Voltage Regulator Driver

[ashish yadav]

Hi Guenter,

Thanks for your time and review comments.
Please find my answer inline.

With Regards
  Ashish

On Tue, Jan 13, 2026 at 3:21 AM Guenter Roeck <linux@roeck-us.net> wrote:
>
> On 1/7/26 06:45, ASHISH YADAV wrote:
> > Add the pmbus driver for the Infineon TDA38740A/TDA38725A
> > DC-DC voltage regulator.
> >
> > Signed-off-by: ASHISH YADAV <Ashish.Yadav@infineon.com>
> > ---
> > Changes in v2:
> >   - Review comments address.
>
> That is not a change log.

ACK, I  will  address it in the v3 release .
>
> >   - Another Patch for Devicetree binding submitted for Driver
> >     Documentation.
> > ---
> >   drivers/hwmon/pmbus/Kconfig     |  16 +++
> >   drivers/hwmon/pmbus/Makefile    |   1 +
> >   drivers/hwmon/pmbus/tda38740a.c | 203 ++++++++++++++++++++++++++++++++
>
> Documentation is missing.

ACK, I  will  address it in the v3 release .

> >   3 files changed, 220 insertions(+)
> >   create mode 100644 drivers/hwmon/pmbus/tda38740a.c
> >
> > diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
> > index f3fb94cebf1a..e7d7ff1b57df 100644
> > --- a/drivers/hwmon/pmbus/Kconfig
> > +++ b/drivers/hwmon/pmbus/Kconfig
> > @@ -602,6 +602,22 @@ config SENSORS_TDA38640_REGULATOR
> >         If you say yes here you get regulator support for Infineon
> >         TDA38640 as regulator.
> >
> > +config SENSORS_TDA38740A
> > +     tristate "Infineon TDA38740A"
> > +     help
> > +       If you say yes here you get hardware monitoring support for Infineon
> > +       TDA38740A/25A.
> > +
> > +       This driver can also be built as a module. If so, the module will
> > +       be called tda38740a.
> > +
> > +config SENSORS_TDA38740A_REGULATOR
> > +     bool "Regulator support for TDA38740A and compatibles"
> > +     depends on SENSORS_TDA38740A && REGULATOR
> > +     help
> > +       If you say yes here you get regulator support for Infineon
> > +       TDA38740A/25A as regulator.
> > +
> >   config SENSORS_TPS25990
> >       tristate "TI TPS25990"
> >       help
> > diff --git a/drivers/hwmon/pmbus/Makefile b/drivers/hwmon/pmbus/Makefile
> > index 349a89b6d92e..f422c80cf3d8 100644
> > --- a/drivers/hwmon/pmbus/Makefile
> > +++ b/drivers/hwmon/pmbus/Makefile
> > @@ -58,6 +58,7 @@ obj-$(CONFIG_SENSORS_PXE1610)       += pxe1610.o
> >   obj-$(CONFIG_SENSORS_Q54SJ108A2)    += q54sj108a2.o
> >   obj-$(CONFIG_SENSORS_STPDDC60)      += stpddc60.o
> >   obj-$(CONFIG_SENSORS_TDA38640)      += tda38640.o
> > +obj-$(CONFIG_SENSORS_TDA38740A)  += tda38740a.o
> >   obj-$(CONFIG_SENSORS_TPS25990)      += tps25990.o
> >   obj-$(CONFIG_SENSORS_TPS40422)      += tps40422.o
> >   obj-$(CONFIG_SENSORS_TPS53679)      += tps53679.o
> > diff --git a/drivers/hwmon/pmbus/tda38740a.c b/drivers/hwmon/pmbus/tda38740a.c
> > new file mode 100644
> > index 000000000000..b31e1b5c6916
> > --- /dev/null
> > +++ b/drivers/hwmon/pmbus/tda38740a.c
> > @@ -0,0 +1,203 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/**
> > + * Hardware monitoring driver for Infineon Integrated-pol-voltage-regulators
> > + * Driver for TDA38725A and TDA38740A
> > + *
> > + * Copyright (c) 2025 Infineon Technologies
> > + */
> > +
> > +#include <linux/err.h>
> > +#include <linux/i2c.h>
> > +#include <linux/init.h>
> > +#include <linux/kernel.h>
> > +#include <linux/module.h>
> > +#include <linux/regulator/driver.h>
> > +#include "pmbus.h"
> > +
> > +#define TDA38725A_IC_DEVICE_ID "\xA9"
> > +#define TDA38740A_IC_DEVICE_ID "\xA8"
> > +
> > +static const struct i2c_device_id tda38740a_id[];
> > +
> > +enum chips { tda38725a, tda38740a };
> > +
> > +struct tda38740a_data {
> > +     enum chips id;
> > +     struct pmbus_driver_info info;
> > +     u32 vout_voltage_multiplier[2];
> > +};
> > +
> > +#define to_tda38740a_data(x) container_of(x, struct tda38740a_data, info)
> > +
> > +static const struct regulator_desc __maybe_unused tda38740a_reg_desc[] = {
> > +     PMBUS_REGULATOR("vout", 0),
> > +};
> > +
> > +static int tda38740a_read_word_data(struct i2c_client *client, int page,
> > +                                 int phase, int reg)
> > +{
> > +     const struct pmbus_driver_info *info = pmbus_get_driver_info(client);
> > +     const struct tda38740a_data *data = to_tda38740a_data(info);
> > +     int ret;
> > +
> > +     /* Virtual PMBUS Command not supported */
> > +     if (reg >= PMBUS_VIRT_BASE)
> > +             return -ENXIO;
> > +
>
> Why is this needed (instead of just returning -ENODATA) ?
>
ACK, I  will  address it in the v3 release .
> > +     switch (reg) {
> > +     case PMBUS_READ_VOUT:
> > +             ret = pmbus_read_word_data(client, page, phase, reg);
> > +             if (ret < 0)
> > +                     return ret;
> > +             ret = ((ret * data->vout_voltage_multiplier[0]) /
> > +                    data->vout_voltage_multiplier[1]);
>
> The need for this, especially why it would only be needed for PMBUS_READ_VOUT
> but not for any other VOUT related commands, is still insufficiently explained
> (and I failed to understand the rationale provided earlier).
>

It is specifically needed for READ_VOUT as it is being used by
external controller to monitor the rail health.
Other Vout related parameters are used internally in the IC to for
output voltage related protections and does not impact any external
decision making.

> > +             break;
> > +     case PMBUS_VOUT_COMMAND:
> > +     case PMBUS_VOUT_MAX:
> > +     case PMBUS_VOUT_MARGIN_HIGH:
> > +     case PMBUS_VOUT_MARGIN_LOW:
> > +     case PMBUS_VOUT_TRANSITION_RATE:
> > +     case PMBUS_VOUT_DROOP:
> > +     case PMBUS_VOUT_SCALE_LOOP:
> > +     case PMBUS_VOUT_OV_FAULT_LIMIT:
> > +     case PMBUS_VOUT_UV_FAULT_LIMIT:
> > +     case PMBUS_IOUT_OC_FAULT_LIMIT:
> > +     case PMBUS_OT_FAULT_LIMIT:
> > +     case PMBUS_OT_WARN_LIMIT:
> > +     case PMBUS_VIN_OV_FAULT_LIMIT:
> > +     case PMBUS_STATUS_WORD:
> > +     case PMBUS_READ_VIN:
> > +     case PMBUS_READ_IIN:
> > +     case PMBUS_READ_IOUT:
> > +     case PMBUS_READ_TEMPERATURE_1:
> > +     case PMBUS_READ_POUT:
> > +     case PMBUS_READ_PIN:
> > +             ret = pmbus_read_word_data(client, page, phase, reg);
>
> I fail to see why this would be necessary. Just return -ENODATA.
>
ACK, I  will  address it in the v3 release .

> > +             break;
> > +     default:
> > +             ret = -ENODATA;
> > +             break;
> > +     }
> > +     return ret;
> > +}
> > +
> > +static struct pmbus_driver_info tda38740a_info[] = {
> > +     [tda38740a] = {
> > +             .pages = 1,
> > +             .read_word_data = tda38740a_read_word_data,
> > +             .format[PSC_VOLTAGE_IN] = linear,
> > +             .format[PSC_VOLTAGE_OUT] = linear,
> > +             .format[PSC_CURRENT_OUT] = linear,
> > +             .format[PSC_CURRENT_IN] = linear,
> > +             .format[PSC_POWER] = linear,
> > +             .format[PSC_TEMPERATURE] = linear,
> > +
> > +             .func[0] = PMBUS_HAVE_VIN | PMBUS_HAVE_STATUS_INPUT
> > +                     | PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP
> > +                     | PMBUS_HAVE_IIN
> > +                     | PMBUS_HAVE_VOUT | PMBUS_HAVE_STATUS_VOUT
> > +                     | PMBUS_HAVE_IOUT | PMBUS_HAVE_STATUS_IOUT
> > +                     | PMBUS_HAVE_POUT | PMBUS_HAVE_PIN,
> > +#if IS_ENABLED(CONFIG_SENSORS_TDA38740A_REGULATOR)
> > +             .num_regulators = 1,
> > +             .reg_desc = tda38740a_reg_desc,
> > +#endif
> > +     },
> > +};
> > +
> > +static int tda38740a_get_device_id(struct i2c_client *client)
> > +{
> > +     u8 device_id[I2C_SMBUS_BLOCK_MAX + 1];
> > +     enum chips id;
> > +     int status;
> > +
> > +     status = i2c_smbus_read_block_data(client, PMBUS_IC_DEVICE_ID,
> > +                                        device_id);
> > +     if (status < 0 || status > 1) {
> > +             dev_err(&client->dev,
> > +                     "Failed to read Device ID or unexpected/unsupported Device\n");
>
> How about printing the device ID here if it is unsupported ?
> It could be printed as hex string.
>
ACK, I  will  address it in the v3 release .

> > +             return -ENODEV;
> > +     }
> > +
> > +     if (!memcmp(TDA38725A_IC_DEVICE_ID, device_id, 1)) {
> > +             id = tda38725a;
> > +     } else if (!memcmp(TDA38740A_IC_DEVICE_ID, device_id, 1)) {
> > +             id = tda38740a;
> > +     } else {
> > +             dev_err(&client->dev, "Unsupported device with ID:%s\n",
> > +                     device_id);
>
> device_id is not terminated, and it is not a user readable string.
> It should be printed as hex string, or as hex byte (0xXX).
>
ACK, I  will  address it in the v3 release .

> > +             return -ENODEV;
> > +     }
> > +
> > +     return id;
> > +}
> > +
> > +static int tda38740a_probe(struct i2c_client *client)
> > +{
> > +     struct device *dev = &client->dev;
> > +     struct tda38740a_data *data;
> > +     int chip_id;
> > +
> > +     if (!i2c_check_functionality(client->adapter,
> > +                                  I2C_FUNC_SMBUS_BYTE |
> > +                                          I2C_FUNC_SMBUS_BYTE_DATA |
> > +                                          I2C_FUNC_SMBUS_WORD_DATA |
> > +                                          I2C_FUNC_SMBUS_BLOCK_DATA))
> > +             return -ENODEV;
> > +
> > +     chip_id = tda38740a_get_device_id(client);
> > +     if (chip_id < 0)
> > +             return chip_id;
> > +
> > +     data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> > +     if (!data)
> > +             return -ENOMEM;
> > +     data->id = chip_id;
> > +     memcpy(&data->info, &tda38740a_info[chip_id], sizeof(data->info));
> > +
> > +     if (!of_property_read_u32_array(client->dev.of_node, "infineon,vout-voltage-multiplier",
> > +                                     data->vout_voltage_multiplier,
> > +                 ARRAY_SIZE(data->vout_voltage_multiplier))) {
> > +             dev_info(&client->dev,
> > +                      "vout-voltage-multiplier from Device Tree:%d %d\n",
> > +                      data->vout_voltage_multiplier[0],
> > +                      data->vout_voltage_multiplier[1]);
> > +     } else {
> > +             dev_info(&client->dev,
> > +                      "vout-voltage-multiplier not available from Device Tree,using default values");
> > +             data->vout_voltage_multiplier[0] = 0x01;
> > +             data->vout_voltage_multiplier[1] = 0x01;
> > +     }
> > +
> > +     return pmbus_do_probe(client, &data->info);
> > +}
> > +
> > +static const struct i2c_device_id tda38740a_id[] = { { "tda38725a", tda38725a },
> > +                                                  { "tda38740a", tda38740a },
> > +                                                  {} };
> > +
> > +MODULE_DEVICE_TABLE(i2c, tda38740a_id);
> > +
> > +static const struct of_device_id __maybe_unused tda38740a_of_match[] = {
> > +     { .compatible = "infineon,tda38725a", .data = (void *)tda38725a },
> > +     { .compatible = "infineon,tda38740a", .data = (void *)tda38740a },
> > +     {}
> > +};
> > +
> > +MODULE_DEVICE_TABLE(of, tda38740a_of_match);
> > +
> > +static struct i2c_driver tda38740a_driver = {
> > +     .driver = {
> > +             .name = "tda38740a",
> > +             .of_match_table = of_match_ptr(tda38740a_of_match),
> > +     },
> > +     .probe = tda38740a_probe,
> > +     .id_table = tda38740a_id,
> > +};
> > +
> > +module_i2c_driver(tda38740a_driver);
> > +
> > +MODULE_AUTHOR("Ashish Yadav <Ashish.Yadav@infineon.com>");
> > +MODULE_DESCRIPTION("PMBus driver for Infineon TDA38725A/40A IPOL");
> > +MODULE_LICENSE("GPL");
> > +MODULE_IMPORT_NS("PMBUS");
>

Re: [PATCH v2 2/2] dt-bindings: hwmon/pmbus: Add Infineon TDA38740A

[ashish yadav]

Hi Guenter,

Thanks for your time and review comments.
Please find my answer inline.

With Regards
  Ashish

On Tue, Jan 13, 2026 at 3:12 AM Guenter Roeck <linux@roeck-us.net> wrote:
>
> On 1/7/26 06:45, ASHISH YADAV wrote:
> > Document the TDA38740A/25A device tree binding.
> >
> > Signed-off-by: ASHISH YADAV <Ashish.Yadav@infineon.com>
> >
> > ---
> > Changes in v2:
> >   - Review comments address:
> > https://lore.kernel.org/all/2ee75453-0869-4348-ad92-f7ff71aca75d@kernel.org/
> >
>
> That is not a change log.
>

ACK, I  will  address it in the v3 release .

> Guenter
>
> > Driver code in review process:
> > https://www.spinics.net/lists/kernel/msg5985470.html
> > ---
> >   .../hwmon/pmbus/infineon,tda38740a.yaml       | 81 +++++++++++++++++++
> >   1 file changed, 81 insertions(+)
> >   create mode 100644 Documentation/devicetree/bindings/hwmon/pmbus/infineon,tda38740a.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/infineon,tda38740a.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/infineon,tda38740a.yaml
> > new file mode 100644
> > index 000000000000..cd4102350a15
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/hwmon/pmbus/infineon,tda38740a.yaml
> > @@ -0,0 +1,81 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +
> > +$id: http://devicetree.org/schemas/hwmon/pmbus/infineon,tda38740a.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Infineon TDA38740A and TDA38725A Synchronous Buck Regulator with I2C
> > +
> > +maintainers:
> > +  - ASHISH YADAV <Ashish.Yadav@infineon.com>
> > +
> > +description: |
> > +  The Infineon TDA38740A/TDA38725A is a 40A/25A Single-voltage Synchronous
> > +  Buck Regulator with I2C designed for Industrial use.
> > +
> > +  Datasheet:
> > +  https://www.infineon.com/assets/row/public/documents/24/49/infineon-tda38740a-tda38725a-datasheet-en.pdf
> > +
> > +properties:
> > +  compatible:
> > +    enum:
> > +      - infineon,tda38725a
> > +      - infineon,tda38740a
> > +
> > +  reg:
> > +    maxItems: 1
> > +
> > +  infineon,vout-voltage-multiplier:
> > +    description: |
> > +      TDA38740/25 pin strap parts are available in two flavors of 1:1 & 1:2
> > +      vout scale loop.
> > +      For the 1:1 vout_scale_loop version, there is no need for any resistor
> > +      divider as output voltage sense pins are directly connected to
> > +      the output.
> > +
> > +      For a 1:2 scale loop version, it is recommended to use 499 ohms each for
> > +      top and bottom across the feedback path.
> > +      However, in some applications customers tend to use an intentional
> > +      resistor divider across the output with a different divider ratio other
> > +      than 1:1 or 1:2 to alter the actual output voltage.
> > +
> > +      For example, if pin strap part is set to Vboot of 0.7V,they use a
> > +      resistor divider to generate 0.75V using the equation provided in
> > +      Section 13.3 of the datasheet.In this case, as there are only two
> > +      vout_scale_loop options of 1:1 and 1:2 that the IC can identify,
> > +      Read_Vout would still read as 0.7V in the telemetry and the baseboard
> > +      management controllers would use this telemetry data to monitor the
> > +      rail parameters leading to false tripping of the system.
> > +      This multiplier is used to offset the telemetry output voltage Read_Vout
> > +      so that the telemetry data is reported correctly to the monitoring
> > +      controller,in this example the multiplier would be 0.75/0.7 = 1.071.
> > +
> > +      This multiplier is required only for any external monitoring of the rail
> > +      output voltage. All the other Vout related parameters are used
> > +      internally by the IC and there is only a slight impact on the fault
> > +      thresholds.The impact can be calculated using equations in Section 13.3
> > +      of the datasheet.
> > +    $ref: /schemas/types.yaml#/definitions/uint32-array
> > +    minItems: 2
> > +    maxItems: 2
> > +
> > +required:
> > +  - compatible
> > +  - reg
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > +  - |
> > +    #include <dt-bindings/interrupt-controller/irq.h>
> > +    i2c {
> > +        #address-cells = <1>;
> > +        #size-cells = <0>;
> > +
> > +        hwmon@40 {
> > +            compatible = "infineon,tda38740a";
> > +            reg = <0x40>;
> > +            infineon,vout-voltage-multiplier = <75 70>;
> > +        };
> > +    };
>

Re: [PATCH v2 1/2] hwmon:(pmbus/tda38740a) TDA38740A Voltage Regulator Driver

[Guenter Roeck]

On 1/12/26 23:24, ashish yadav wrote:

>> The need for this, especially why it would only be needed for PMBUS_READ_VOUT
>> but not for any other VOUT related commands, is still insufficiently explained
>> (and I failed to understand the rationale provided earlier).
>>
> 
> It is specifically needed for READ_VOUT as it is being used by
> external controller to monitor the rail health.
> Other Vout related parameters are used internally in the IC to for
> output voltage related protections and does not impact any external
> decision making.
> 

Sorry, that doesn't really make sense. How would the chip know to match
VOUT with its VOUT limits if both don't use the same scale ?

Guenter

Re: [PATCH v2 1/2] hwmon:(pmbus/tda38740a) TDA38740A Voltage Regulator Driver

[ashish yadav]

Hi Guenter,

Please find my response inline.

Thanks & Regards
   Ashish Yadav

On Tue, Jan 13, 2026 at 8:40 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> On 1/12/26 23:24, ashish yadav wrote:
>
> >> The need for this, especially why it would only be needed for PMBUS_READ_VOUT
> >> but not for any other VOUT related commands, is still insufficiently explained
> >> (and I failed to understand the rationale provided earlier).
> >>
> >
> > It is specifically needed for READ_VOUT as it is being used by
> > external controller to monitor the rail health.
> > Other Vout related parameters are used internally in the IC to for
> > output voltage related protections and does not impact any external
> > decision making.
> >
>
> Sorry, that doesn't really make sense. How would the chip know to match
> VOUT with its VOUT limits if both don't use the same scale ?
>
The chip telemetry would still show Vout as 0.7V as it does not know
about the external feedback resistors.
Hence, no need to scale internal Vout related parameters.
This scale is only for external vendor use to tweak their telemetry
output voltage reading.

> Guenter
>

Re: [PATCH v2 1/2] hwmon:(pmbus/tda38740a) TDA38740A Voltage Regulator Driver

[Guenter Roeck]

On 1/22/26 03:42, ashish yadav wrote:
> Hi Guenter,
> 
> Please find my response inline.
> 
> Thanks & Regards
>     Ashish Yadav
> 
> On Tue, Jan 13, 2026 at 8:40 PM Guenter Roeck <linux@roeck-us.net> wrote:
>>
>> On 1/12/26 23:24, ashish yadav wrote:
>>
>>>> The need for this, especially why it would only be needed for PMBUS_READ_VOUT
>>>> but not for any other VOUT related commands, is still insufficiently explained
>>>> (and I failed to understand the rationale provided earlier).
>>>>
>>>
>>> It is specifically needed for READ_VOUT as it is being used by
>>> external controller to monitor the rail health.
>>> Other Vout related parameters are used internally in the IC to for
>>> output voltage related protections and does not impact any external
>>> decision making.
>>>
>>
>> Sorry, that doesn't really make sense. How would the chip know to match
>> VOUT with its VOUT limits if both don't use the same scale ?
>>
> The chip telemetry would still show Vout as 0.7V as it does not know
> about the external feedback resistors.
> Hence, no need to scale internal Vout related parameters.
> This scale is only for external vendor use to tweak their telemetry
> output voltage reading.
> 

You fail to explain why VOUT_SCALE_LOOP - which is supposed to handle such
situations - can not be used, and why it would be acceptable for other VOUT
related attributes such as VOUT_MIN, VOUT_MAX, VOUT_MARGIN_LOW, VOUT_MARGIN_HIGH,
and the various VOUT fault limits to show the wrong values.

For reference:

VOUT_SCALE_LOOP:
"Used to account for any external attenuation network on VOUT sense
  feedback and provide correct VOUT reporting."

Guenter

Re: [PATCH v2 1/2] hwmon:(pmbus/tda38740a) TDA38740A Voltage Regulator Driver

[ashish yadav]

Hi Guenter,

I hope you are doing well.

Please find my response inline.

With Best Regards
  Ashish Yadav


On Mon, Feb 2, 2026 at 5:59 AM Guenter Roeck <linux@roeck-us.net> wrote:
>
> On 1/22/26 03:42, ashish yadav wrote:
> > Hi Guenter,
> >
> > Please find my response inline.
> >
> > Thanks & Regards
> >     Ashish Yadav
> >
> > On Tue, Jan 13, 2026 at 8:40 PM Guenter Roeck <linux@roeck-us.net> wrote:
> >>
> >> On 1/12/26 23:24, ashish yadav wrote:
> >>
> >>>> The need for this, especially why it would only be needed for PMBUS_READ_VOUT
> >>>> but not for any other VOUT related commands, is still insufficiently explained
> >>>> (and I failed to understand the rationale provided earlier).
> >>>>
> >>>
> >>> It is specifically needed for READ_VOUT as it is being used by
> >>> external controller to monitor the rail health.
> >>> Other Vout related parameters are used internally in the IC to for
> >>> output voltage related protections and does not impact any external
> >>> decision making.
> >>>
> >>
> >> Sorry, that doesn't really make sense. How would the chip know to match
> >> VOUT with its VOUT limits if both don't use the same scale ?
> >>
> > The chip telemetry would still show Vout as 0.7V as it does not know
> > about the external feedback resistors.
> > Hence, no need to scale internal Vout related parameters.
> > This scale is only for external vendor use to tweak their telemetry
> > output voltage reading.
> >
>
> You fail to explain why VOUT_SCALE_LOOP - which is supposed to handle such
> situations - can not be used, and why it would be acceptable for other VOUT
> related attributes such as VOUT_MIN, VOUT_MAX, VOUT_MARGIN_LOW, VOUT_MARGIN_HIGH,
> and the various VOUT fault limits to show the wrong values.
>
> For reference:
>
> VOUT_SCALE_LOOP:
> "Used to account for any external attenuation network on VOUT sense
>   feedback and provide correct VOUT reporting."
>

TDA38725A/TDA38740A has only two options of vout_scale_loop. These are
1 and 0.5.
If the output voltage is directly connected to the output rail, then
vout_scale_loop = 1 as there is no resistor divider in the feedback
and feedback voltage is equal to the actual output voltage.

If vout_scale_loop = 0.5, it is recommended to use a resistor divider
(top & bottom – 499ohms each) with a ratio of  0.5 in the feedback
path.
In this case, feedback voltage will be 0.5 x actual output voltage.
As the vout_scale_loop is set to 0.5, IC would use this
vout_scale_loop internally to provide the correct telemetry data.

If a customer uses a resistor divider of 2.21k (top) & 22.1k (bottom),
the divider ratio would be (2.21/22.1 + 2.21 = 0.09).
This is not an option available in the IC as it can only identify 1 and 0.5.
In this case, they configure the IC in vout_scale_loop of 1 and use a
multiplier in Linux code to correct the READ_VOUT telemetry voltage.

Why can vout_scale_loop not be used?
Using vout_scale_loop for correction will also impact all the Vout
related parameters and makes it cumbersome.
To simplify the linux code, customers prefer changing only Read_Vout
value and accept that IC would still operate based on vout_scale_loop
value configured to 1.



> Guenter
>

Re: [PATCH v2 1/2] hwmon:(pmbus/tda38740a) TDA38740A Voltage Regulator Driver

[Guenter Roeck]

On 2/8/26 21:04, ashish yadav wrote:
> Hi Guenter,
> 
> I hope you are doing well.
> 
> Please find my response inline.
> 
> With Best Regards
>    Ashish Yadav
> 
> 
> On Mon, Feb 2, 2026 at 5:59 AM Guenter Roeck <linux@roeck-us.net> wrote:
>>
>> On 1/22/26 03:42, ashish yadav wrote:
>>> Hi Guenter,
>>>
>>> Please find my response inline.
>>>
>>> Thanks & Regards
>>>      Ashish Yadav
>>>
>>> On Tue, Jan 13, 2026 at 8:40 PM Guenter Roeck <linux@roeck-us.net> wrote:
>>>>
>>>> On 1/12/26 23:24, ashish yadav wrote:
>>>>
>>>>>> The need for this, especially why it would only be needed for PMBUS_READ_VOUT
>>>>>> but not for any other VOUT related commands, is still insufficiently explained
>>>>>> (and I failed to understand the rationale provided earlier).
>>>>>>
>>>>>
>>>>> It is specifically needed for READ_VOUT as it is being used by
>>>>> external controller to monitor the rail health.
>>>>> Other Vout related parameters are used internally in the IC to for
>>>>> output voltage related protections and does not impact any external
>>>>> decision making.
>>>>>
>>>>
>>>> Sorry, that doesn't really make sense. How would the chip know to match
>>>> VOUT with its VOUT limits if both don't use the same scale ?
>>>>
>>> The chip telemetry would still show Vout as 0.7V as it does not know
>>> about the external feedback resistors.
>>> Hence, no need to scale internal Vout related parameters.
>>> This scale is only for external vendor use to tweak their telemetry
>>> output voltage reading.
>>>
>>
>> You fail to explain why VOUT_SCALE_LOOP - which is supposed to handle such
>> situations - can not be used, and why it would be acceptable for other VOUT
>> related attributes such as VOUT_MIN, VOUT_MAX, VOUT_MARGIN_LOW, VOUT_MARGIN_HIGH,
>> and the various VOUT fault limits to show the wrong values.
>>
>> For reference:
>>
>> VOUT_SCALE_LOOP:
>> "Used to account for any external attenuation network on VOUT sense
>>    feedback and provide correct VOUT reporting."
>>
> 
> TDA38725A/TDA38740A has only two options of vout_scale_loop. These are
> 1 and 0.5.
> If the output voltage is directly connected to the output rail, then
> vout_scale_loop = 1 as there is no resistor divider in the feedback
> and feedback voltage is equal to the actual output voltage.
> 
> If vout_scale_loop = 0.5, it is recommended to use a resistor divider
> (top & bottom – 499ohms each) with a ratio of  0.5 in the feedback
> path.
> In this case, feedback voltage will be 0.5 x actual output voltage.
> As the vout_scale_loop is set to 0.5, IC would use this
> vout_scale_loop internally to provide the correct telemetry data.
> 
> If a customer uses a resistor divider of 2.21k (top) & 22.1k (bottom),
> the divider ratio would be (2.21/22.1 + 2.21 = 0.09).

Is that theory or practice ?

> This is not an option available in the IC as it can only identify 1 and 0.5.
> In this case, they configure the IC in vout_scale_loop of 1 and use a
> multiplier in Linux code to correct the READ_VOUT telemetry voltage.
> 
> Why can vout_scale_loop not be used?
> Using vout_scale_loop for correction will also impact all the Vout
> related parameters and makes it cumbersome.

No, it causes the other values to be reported correctly. There is nothing
cumbersome about that. It would be not cumbersome but troubling and
potentially critical to have the chip report adjusted voltages but raw
limits.

> To simplify the linux code, customers prefer changing only Read_Vout
> value and accept that IC would still operate based on vout_scale_loop
> value configured to 1.

That explains why vout_scale_loop can not be used, assuming that the
use case is real. It does not explain why it would make sense to only
adjust READ_VOUT but not all the limits, nor does it explain if this
is an actual use case or just theory.

I am inclined to suggest that a devicetree property should only
indicate if vout_scale_loop is 1:1 or 1:2, and that all other
adjustments should be handled in the sensors configuration file.
What is completely unacceptable, customer desire or not, is to just
adjust READ_VOUT and not all other VOUT related register values.

Thanks,
Guenter