[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c8195f04-3492-4cf9-b2b0-6f3a1198ffa2@roeck-us.net>
Date: Tue, 16 Dec 2025 01:45:59 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: Jeff Lin <jefflin994697@...il.com>
Cc: grantpeltier93@...il.com, karanja99erick@...il.com,
chiang.brian@...entec.com, krzk@...nel.org, william@...nnington.com,
tzungbi@...nel.org, thorsten.blum@...ux.dev, ninad@...ux.ibm.com,
linux-hwmon@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] hwmon: (pmbus) Add support for multiple-function pin
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
Powered by blists - more mailing lists