Some pmbus chip support the additional multiple-function pin, which can
detect and provide the connected device's current reading. The data
format of the multiple-function ping must be confirmed with the chip
vendor, as it may vary between different chips. However, it is
problematic if the data format differs from the original 'iin' and 'iout'
and we want to show both the current from multiple-function pin and the
original 'iin' and 'iout'.

To solve the problem, add support for additional virtual current input
and virtual current output, call it 'viin' and 'viout', respectively.

Signed-off-by: Jeff Lin <jefflin994697@gmail.com>
---
 drivers/hwmon/pmbus/pmbus.h      | 12 ++++++++++++
 drivers/hwmon/pmbus/pmbus_core.c | 18 ++++++++++++++++++
 2 files changed, 30 insertions(+)

diff --git a/drivers/hwmon/pmbus/pmbus.h b/drivers/hwmon/pmbus/pmbus.h
index d2e9bfb5320f..8a1c3a7a4f32 100644
--- a/drivers/hwmon/pmbus/pmbus.h
+++ b/drivers/hwmon/pmbus/pmbus.h
@@ -236,6 +236,14 @@ enum pmbus_regs {
 	PMBUS_VIRT_CURR_SAMPLES,
 	PMBUS_VIRT_POWER_SAMPLES,
 	PMBUS_VIRT_TEMP_SAMPLES,
+
+	/* Multiple function pin
+	 *
+	 * Drivers wanting to expose the value from multiple function pin
+	 * should implement support in read_word_data callback.
+	 */
+	PMBUS_VIRT_READ_IIN,
+	PMBUS_VIRT_READ_IOUT,
 };
 
 /*
@@ -381,6 +389,8 @@ enum pmbus_sensor_classes {
 	PSC_TEMPERATURE,
 	PSC_FAN,
 	PSC_PWM,
+	PSC_VIRT_CURRENT_IN,
+	PSC_VIRT_CURRENT_OUT,
 	PSC_NUM_CLASSES		/* Number of power sensor classes */
 };
 
@@ -411,6 +421,8 @@ enum pmbus_sensor_classes {
 #define PMBUS_HAVE_PWM12	BIT(20)
 #define PMBUS_HAVE_PWM34	BIT(21)
 #define PMBUS_HAVE_SAMPLES	BIT(22)
+#define PMBUS_HAVE_VIRT_IIN	BIT(23)
+#define PMBUS_HAVE_VIRT_IOUT	BIT(24)
 
 #define PMBUS_PHASE_VIRTUAL	BIT(30)	/* Phases on this page are virtual */
 #define PMBUS_PAGE_VIRTUAL	BIT(31)	/* Page is virtual */
diff --git a/drivers/hwmon/pmbus/pmbus_core.c b/drivers/hwmon/pmbus/pmbus_core.c
index be6d05def115..9a8eec5d3945 100644
--- a/drivers/hwmon/pmbus/pmbus_core.c
+++ b/drivers/hwmon/pmbus/pmbus_core.c
@@ -1929,6 +1929,16 @@ static const struct pmbus_sensor_attr current_attributes[] = {
 		.gbit = PB_STATUS_IOUT_OC,
 		.limit = iout_limit_attrs,
 		.nlimit = ARRAY_SIZE(iout_limit_attrs),
+	}, {
+		.reg = PMBUS_VIRT_READ_IIN,
+		.class = PSC_VIRT_CURRENT_IN,
+		.label = "viin",
+		.func = PMBUS_HAVE_VIRT_IIN
+	}, {
+		.reg = PMBUS_VIRT_READ_IOUT,
+		.class = PSC_VIRT_CURRENT_OUT,
+		.label = "viout",
+		.func = PMBUS_HAVE_VIRT_IOUT
 	}
 };
 
@@ -2501,6 +2511,14 @@ static const struct pmbus_class_attr_map class_attr_map[] = {
 		.class = PSC_TEMPERATURE,
 		.attr = temp_attributes,
 		.nattr = ARRAY_SIZE(temp_attributes),
+	}, {
+		.class = PSC_VIRT_CURRENT_IN,
+		.attr = current_attributes,
+		.nattr = ARRAY_SIZE(current_attributes),
+	}, {
+		.class = PSC_VIRT_CURRENT_OUT,
+		.attr = current_attributes,
+		.nattr = ARRAY_SIZE(current_attributes),
 	}
 };
 
-- 
2.34.1

On 12/16/25 01:16, Jeff Lin wrote:
> Some pmbus chip support the additional multiple-function pin, which can
> detect and provide the connected device's current reading. The data
> format of the multiple-function ping must be confirmed with the chip
> vendor, as it may vary between different chips. However, it is
> problematic if the data format differs from the original 'iin' and 'iout'
> and we want to show both the current from multiple-function pin and the
> original 'iin' and 'iout'.
> 
> To solve the problem, add support for additional virtual current input
> and virtual current output, call it 'viin' and 'viout', respectively.
> 

Those are just additional current input and output values. That does not
require additional sensor classes. Just use the chip driver to map the
readings from the chip format to the format used by the existing iin and
iout (there is no 'viin" or "viout").

Also, please point to the standard regarding "multiple function pin".
The term must only be used in the common code or definitions if it has
a reference in the standard. Otherwise it is just a manufacturer specific
extension which has no place in common code. The second patch of the series,
which accesses some very vendor specific functions, strongly suggests that
this is the case.

Guenter