[PATCH] hwmon: (pmbus/xdpe1a2g7b) Add regulator support

[PATCH] hwmon: (pmbus/xdpe1a2g7b) Add regulator support

[Abdurrahman Hussain]

Register both dual-loop output channels with the regulator framework by
populating regulator_desc[] and num_regulators in pmbus_driver_info.
This exposes the standard PMBus OPERATION-based on/off control and
status reporting to consumer drivers.

Signed-off-by: Abdurrahman Hussain <abdurrahman@nexthop.ai>
---
The new SENSORS_XDPE1A2G7B_REGULATOR Kconfig and the ifdef-guarded
regulator_desc array mirror the opt-in pattern already used by the
XDPE122 driver (SENSORS_XDPE122_REGULATOR), so the REGULATOR dependency
stays optional for users that only need hwmon monitoring.
---
 drivers/hwmon/pmbus/Kconfig      | 10 ++++++++++
 drivers/hwmon/pmbus/xdpe1a2g7b.c | 11 +++++++++++
 2 files changed, 21 insertions(+)

diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
index c8cda160b5f8..78146f27585a 100644
--- a/drivers/hwmon/pmbus/Kconfig
+++ b/drivers/hwmon/pmbus/Kconfig
@@ -803,6 +803,16 @@ config SENSORS_XDPE1A2G7B
 	  This driver can also be built as a module. If so, the module will
 	  be called xdpe1a2g7b.
 
+config SENSORS_XDPE1A2G7B_REGULATOR
+	bool "Regulator support for XDPE1A2G7B and compatibles"
+	depends on SENSORS_XDPE1A2G7B && REGULATOR
+	help
+	  If you say yes here you get regulator support for Infineon
+	  XDPE1A2G5B and XDPE1A2G7B multi-phase digital controllers.
+
+	  This enables the controllers to be used as regulator devices,
+	  providing voltage control through the regulator framework.
+
 config SENSORS_XDPE122
 	tristate "Infineon XDPE122 family"
 	help
diff --git a/drivers/hwmon/pmbus/xdpe1a2g7b.c b/drivers/hwmon/pmbus/xdpe1a2g7b.c
index 971e7b73752e..9455ef443b2b 100644
--- a/drivers/hwmon/pmbus/xdpe1a2g7b.c
+++ b/drivers/hwmon/pmbus/xdpe1a2g7b.c
@@ -57,6 +57,13 @@ static int xdpe1a2g7b_identify(struct i2c_client *client,
 	return 0;
 }
 
+#if IS_ENABLED(CONFIG_SENSORS_XDPE1A2G7B_REGULATOR)
+static const struct regulator_desc xdpe1a2g7b_reg_desc[] = {
+	PMBUS_REGULATOR("vout", 0),
+	PMBUS_REGULATOR("vout", 1),
+};
+#endif
+
 static struct pmbus_driver_info xdpe1a2g7b_info = {
 	.pages = XDPE1A2G7B_PAGE_NUM,
 	.identify = xdpe1a2g7b_identify,
@@ -72,6 +79,10 @@ static struct pmbus_driver_info xdpe1a2g7b_info = {
 	.func[1] = PMBUS_HAVE_VIN | PMBUS_HAVE_VOUT | PMBUS_HAVE_STATUS_VOUT |
 		   PMBUS_HAVE_IIN | PMBUS_HAVE_IOUT | PMBUS_HAVE_STATUS_IOUT |
 		   PMBUS_HAVE_PIN | PMBUS_HAVE_POUT | PMBUS_HAVE_STATUS_INPUT,
+#if IS_ENABLED(CONFIG_SENSORS_XDPE1A2G7B_REGULATOR)
+	.num_regulators = XDPE1A2G7B_PAGE_NUM,
+	.reg_desc = xdpe1a2g7b_reg_desc,
+#endif
 };
 
 static int xdpe1a2g7b_probe(struct i2c_client *client)

---
base-commit: 9ecfb2f7287a967b418ba69f10d45ead0d360593
change-id: 20260619-xdpe1a2g7b-a3365760fb20

Best regards,
--  
Abdurrahman Hussain <abdurrahman@nexthop.ai>

Re: [PATCH] hwmon: (pmbus/xdpe1a2g7b) Add regulator support

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Critical] This problem wasn't introduced by this patch, but the PMBus core function `pmbus_data2reg_vid()` hardcodes the VR11 VID calculation formula and completely ignores the `vrm_version` parameter configured by the driver. When the `xdpe1a2g7b` driver operates in `nvidia195mv` VID mode, calls to `regulator_set_voltage()` will convert the target voltage to a completely incorrect VR11 VID code. For example, a request for 200mV is incorrectly clamped to 500mV and converted to a VR11 VID of 0xB2, which the hardware interprets in `nvidia195mv` mode as 1.08V. This applies unexpected and potentially destructive voltages to attached components.
--

commit 970e2131ac4cd9e077822790586db122a481d9fb
Author: Abdurrahman Hussain <abdurrahman@nexthop.ai>

hwmon: (pmbus/xdpe1a2g7b) Add regulator support

Register both dual-loop output channels with the regulator framework by
populating regulator_desc[] and num_regulators in pmbus_driver_info.
This exposes the standard PMBus OPERATION-based on/off control and
status reporting to consumer drivers.

> diff --git a/drivers/hwmon/pmbus/xdpe1a2g7b.c b/drivers/hwmon/pmbus/xdpe1a2g7b.c
> index 971e7b73752ea..9455ef443b2b3 100644
> --- a/drivers/hwmon/pmbus/xdpe1a2g7b.c
> +++ b/drivers/hwmon/pmbus/xdpe1a2g7b.c
[ ... ]
> @@ -72,6 +79,10 @@ static struct pmbus_driver_info xdpe1a2g7b_info = {
>  	.func[1] = PMBUS_HAVE_VIN | PMBUS_HAVE_VOUT | PMBUS_HAVE_STATUS_VOUT |
>  		   PMBUS_HAVE_IIN | PMBUS_HAVE_IOUT | PMBUS_HAVE_STATUS_IOUT |
>  		   PMBUS_HAVE_PIN | PMBUS_HAVE_POUT | PMBUS_HAVE_STATUS_INPUT,
> +#if IS_ENABLED(CONFIG_SENSORS_XDPE1A2G7B_REGULATOR)
> +	.num_regulators = XDPE1A2G7B_PAGE_NUM,
> +	.reg_desc = xdpe1a2g7b_reg_desc,

[Severity: Critical]
This is a pre-existing issue, but does enabling regulator support here expose
attached hardware to destructive voltages when operating in nvidia195mv VID
mode?

The core PMBus framework translates microvolts into raw register encodings via
pmbus_data2reg_vid(), but it currently hardcodes the VR11 VID calculation
formula and completely ignores the vrm_version parameter configured by the
driver.

For example, if regulator_set_voltage() requests 200mV, the core does:

drivers/hwmon/pmbus/pmbus_core.c:pmbus_data2reg_vid() {
	val = clamp_val(val, 500, 1600);
	return 2 + DIV_ROUND_CLOSEST_ULL((1600LL - val) * 100LL, 625);
}

This incorrectly clamps the request to 500mV and converts it to a VR11 VID of
0xB2. The hardware interprets 0xB2 in nvidia195mv mode as 1.08V.

Writing these values into the PMBUS_VOUT_COMMAND register of an nvidia195mv
compliant device translates low-voltage requests into dangerously high physical
voltage output.

Could pmbus_data2reg_vid() be updated to branch on vrm_version before exposing
this regulator interface?

> +#endif
>  };

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260619-xdpe1a2g7b-v1-1-428c3847be0d@nexthop.ai?part=1

Re: [PATCH] hwmon: (pmbus/xdpe1a2g7b) Add regulator support

[Abdurrahman Hussain]

On Sat, 20 Jun 2026 06:53:57 +0000, sashiko-bot@kernel.org wrote:
> [Severity: Critical]
> This is a pre-existing issue, but does enabling regulator support here expose
> attached hardware to destructive voltages when operating in nvidia195mv VID
> mode?
>
> The core PMBus framework translates microvolts into raw register encodings via
> pmbus_data2reg_vid(), but it currently hardcodes the VR11 VID calculation
> formula and completely ignores the vrm_version parameter configured by the
> driver.

Good catch! Confirmed: pmbus_data2reg_vid() ignores vrm_version while its
read counterpart pmbus_reg2data_vid() already switches on it, so a non-VR11
driver that exposes a regulator -- or any hwmon vout_command setter -- will
write VR11-encoded values into the chip. For an nvidia195mv part this turns
a 200 mV request into VID 0xB2, which the chip interprets as 1080 mV.

I'll send the core fix as a separate prerequisite patch (mirroring
pmbus_reg2data_vid() so writes round-trip with reads) and respin this
series on top of it.

Thanks,
Abdurrahman