Re: [PATCH 3/3] hwmon: (pmbus/fd5121): Add support FD5121, FD5123 and FD5125

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 10 potential issue(s) to consider:
- [High] Directly exposing PMBUS_PAGE and paged PMBus registers via custom lockless sysfs attributes bypasses PMBus core locking and page caching, causing race conditions and hardware state corruption.
- [High] Incorrect mathematical conversion of READ_VOUT to AMD 6.25mV VIDs causes voltage read failures > 1.55V and applies dangerously incorrect voltages on writes.
- [High] The `svr_go` sysfs attribute ignores its mapped register index, allowing userspace to execute arbitrary PMBus/I2C Send Byte commands.
- [High] The I2C block read fallback in `fd5121_read_block_data` corrupts the payload by reading one byte too few and shifting uninitialized memory into the result.
- [High] The I2C block write fallback in `fd5121_write_block_data` omits the required PMBus length byte, corrupting write transactions.
- [Medium] Attempting to read 164/165 bytes for OTP/RAM using standard SMBus/I2C block read functions results in silent truncation to 32 bytes.
- [Medium] `fd5121_word_store` parses user input as a signed 16-bit integer, preventing valid unsigned PMBus values from being written.
- [Medium] The custom `clear_faults` sysfs attribute sends an invalid data payload for a standard PMBus Send Byte command.
- [Medium] The driver violates the hwmon subsystem ABI by exposing over 80 standard PMBus registers as custom raw sysfs attributes.
- [Medium] `fd5121_probe` enforces an overly restrictive `I2C_FUNC_I2C` check, breaking compatibility with standard SMBus controllers.
--

commit 1e218fd27c0a9b6bb8fade016af8d29cbdb6daa5
Author: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>

hwmon: (pmbus/fd5121): Add support FD5121, FD5123 and FD5125
    
FD5121 is a dual-rail, multi-phase, digital controller that offers
full telemtry options including input/output voltage, current as
well as fault handling and identifications.
    
These controllers are compliant with PMBus specification.

> diff --git a/drivers/hwmon/pmbus/fd5121.c b/drivers/hwmon/pmbus/fd5121.c
> new file mode 100644
> index 0000000000000..e68c6d6cabbd9
> --- /dev/null
> +++ b/drivers/hwmon/pmbus/fd5121.c

[ ... ]

> +static s32 fd5121_read_block_data(const struct i2c_client *client,
> +				  u8 cmd_code, u8 len, u8 *pbuf)
> +{
> +	s32 ret = 0;
> +
> +	if (!i2c_check_functionality(client->adapter,
> +				     I2C_FUNC_SMBUS_READ_BLOCK_DATA)) {
> +
> +		/* Payload length is in the first byte. */
> +		ret = i2c_smbus_read_i2c_block_data(client, cmd_code,
> +						    len, pbuf);
> +		if (ret < 0)
> +			return ret;
> +		ret = pbuf[0];
> +		if (ret > len)
> +			ret = len;
> +		for (int idx = 0; idx < ret; idx++)
> +			pbuf[idx] = pbuf[idx + 1];
> +		return ret;

[Severity: High]
Does this fallback logic corrupt the payload by reading one byte too few?

Since the device replies with an SMBus block read format (a length byte
followed by the payload), requesting exactly len bytes retrieves the length
byte and only len - 1 data bytes.

This means the last byte of the payload is dropped, and the subsequent
left-shift copies a trailing uninitialized byte into the final payload
position. Should it request len + 1 bytes instead?

[ ... ]

> +static ssize_t fd5121_send_byte_store(struct device *dev,
> +				      struct device_attribute *da,
> +				      const char *buf, size_t count)
> +{
> +	struct i2c_client *client = to_i2c_client(dev->parent);
> +	u8 val = 0;
> +	int ret;
> +
> +	ret = kstrtou8(buf, 10, &val);
> +	if (ret < 0)
> +		return ret;
> +	ret = i2c_smbus_write_byte(client, val);

[Severity: High]
Does this allow userspace command injection?

This attribute is mapped to PMBUS_REG_MFR_SVR_GO, but it parses the
user-provided string into val and directly sends that as the SMBus command
code, completely ignoring attr->index. This allows any arbitrary command
code to be broadcast instead of SVR_GO.

[ ... ]

> +static ssize_t fd5121_byte_store(struct device *dev,
> +				 struct device_attribute *da,
> +				 const char *buf, size_t count)
> +{
> +	struct sensor_device_attribute *attr = to_sensor_dev_attr(da);
> +	struct i2c_client *client = to_i2c_client(dev->parent);
> +	u8 reg = attr->index;
> +	int ret = 0;
> +	u8 val = 0;
> +
> +	switch (reg) {
> +	case PMBUS_REG_MFR_CONFIG_ACTIVATE:
> +		ret = fd5121_config_activate(client);
> +		if (ret < 0)
> +			return ret;
> +		return count;
> +	default:
> +		ret = kstrtou8(buf, 10, &val);
> +		if (ret < 0)
> +			return ret;
> +		break;
> +	}
> +	if (reg == PMBUS_PAGE && ((val != 0 && val != 1 &&
> +	    val != GENMASK(7, 0))))
> +		return -EINVAL;
> +	ret = i2c_smbus_write_byte_data(client, reg, val);

[Severity: High]
Can writing to the PMBUS_PAGE attribute directly corrupt the PMBus core's
page tracking?

By modifying the physical hardware's page using raw i2c_smbus_write_byte_data
instead of the PMBus core accessors, the core's cached data->currpage
becomes out of sync. Subsequent accesses by the PMBus core could execute
on the wrong hardware rail.

[Severity: Medium]
Additionally, if this is used to send PMBUS_CLEAR_FAULTS, does it violate
the PMBus specification?

CLEAR_FAULTS is strictly a Send Byte command with no data payload, but
i2c_smbus_write_byte_data() transmits an extra data byte.

[ ... ]

> +static ssize_t fd5121_word_store(struct device *dev,
> +				 struct device_attribute *da,
> +				 const char *buf, size_t count)
> +{
> +	struct sensor_device_attribute *attr = to_sensor_dev_attr(da);
> +	struct i2c_client *client = to_i2c_client(dev->parent);
> +	u8 reg = attr->index;
> +	s16 val = 0;
> +	int ret = 0;
> +
> +	switch (reg) {
> +	case PMBUS_REG_MFR_PWD_PROGRAM_RAM:
> +		val = 0xC93F;
> +		break;
> +	default:
> +		ret = kstrtos16(buf, 10, &val);

[Severity: Medium]
Does using kstrtos16() prevent configuring valid unsigned PMBus word values?

PMBus word registers represent 16-bit unsigned integers, but parsing
them as a signed s16 causes any valid input between 32768 and 65535 to
be rejected with an -ERANGE error.

[ ... ]

> +static ssize_t fd5121_word_show(struct device *dev,
> +				struct device_attribute *da, char *buf)
> +{
> +	struct sensor_device_attribute *attr = to_sensor_dev_attr(da);
> +	struct i2c_client *client = to_i2c_client(dev->parent);
> +	u8 data[I2C_SMBUS_BLOCK_MAX] = { 0 };
> +	u8 reg = attr->index;
> +	s32 ret = 0;
> +
> +	if (fd5121_blk_rd_reg(reg)) {
> +		ret = fd5121_read_block_data(client, reg, 2, data);
> +		if (ret >= 0)
> +			ret = get_unaligned_le16(data);
> +	} else
> +		ret = i2c_smbus_read_word_data(client, reg);

[Severity: High]
Does this direct sysfs read lead to a race condition with the PMBus core?

Since these paged registers are read directly via i2c_smbus_read_word_data
without acquiring data->update_lock or ensuring the correct page is active,
concurrent PMBus operations could cause this to read from the wrong rail.

[ ... ]

> +static s32 fd5121_write_block_data(const struct i2c_client *client,
> +				   u8 cmd_code, u8 len, u8 *pbuf)
> +{
> +	s32 ret = 0;
> +
> +	if (!i2c_check_functionality(client->adapter,
> +				     I2C_FUNC_SMBUS_WRITE_BLOCK_DATA))
> +		ret = i2c_smbus_write_i2c_block_data(client, cmd_code,
> +						     len, pbuf);

[Severity: High]
Does this I2C block write fallback omit the mandatory PMBus length byte?

Unlike the SMBus equivalent, the I2C block write API does not prepend
a length byte on the wire. Without this length byte, the hardware will
misinterpret the first data byte (pbuf[0]) as the length, corrupting
the data payload.

[ ... ]

> +static ssize_t fd5121_block_show(struct device *dev,
> +				 struct device_attribute *da, char *buf)
> +{
> +	struct i2c_client *client = to_i2c_client(dev->parent);
> +	struct sensor_device_attribute *attr = to_sensor_dev_attr(da);
> +	u8 buffer[I2C_SMBUS_BLOCK_MAX] = { 0 };
> +	u8 reg = attr->index;
> +	int printed = 0;
> +	s32 ret = 0;
> +	u8 len = 0;
> +	int i = 0;
> +
> +	if (reg == PMBUS_REG_MFR_FAULTY_SPS) {
> +		int to_print = 0;
> +
> +		len = 7;
> +		ret = fd5121_read_block_data(client, reg, len, buffer);
> +		if (ret < 0)
> +			return ret;
> +		printed = 0;
> +		to_print = (ret < len) ? ret : len;
> +		for (i = 0; i < to_print; i++)
> +			printed += scnprintf(buf + printed,
> +					     PAGE_SIZE - printed,
> +					     "%02x", buffer[i]);
> +		printed += scnprintf(buf + printed,
> +				     PAGE_SIZE - printed, "\n");
> +		return printed;
> +	} else if (reg == PMBUS_REG_BBR_RAM ||
> +		   reg == PMBUS_REG_BBR_OTP) {
> +		u32 len = (reg == PMBUS_REG_BBR_OTP) ? 165 : 164;
> +
> +		/* Extra byte may be needed in case we need to store
> +		 * the length of the data
> +		 */
> +		u8 *tmp_in = kcalloc(len+1, sizeof(u8), GFP_KERNEL);
> +
> +		if (tmp_in == NULL)
> +			return -ENOMEM;
> +		ret = fd5121_read_block_data(client, reg, len, tmp_in);

[Severity: Medium]
Will this operation silently truncate the read to 32 bytes?

The requested lengths are 164 and 165, but the underlying I2C/SMBus
block read functions (i2c_smbus_read_block_data and its I2C fallback)
are strictly capped at I2C_SMBUS_BLOCK_MAX (32 bytes).

[ ... ]

> +static struct attribute *fd5121_paged_attrs[] = {
> +	&sensor_dev_attr_operation.dev_attr.attr,
> +	&sensor_dev_attr_vout_raw.dev_attr.attr,
> +	&sensor_dev_attr_on_off_config.dev_attr.attr,
> +	&sensor_dev_attr_clear_faults.dev_attr.attr,
> +	&sensor_dev_attr_write_protect.dev_attr.attr,
> +	&sensor_dev_attr_smbalert_mask.dev_attr.attr,
> +	&sensor_dev_attr_vout_mode.dev_attr.attr,
> +	&sensor_dev_attr_vout_command.dev_attr.attr,

[Severity: Medium]
Is it intentional to expose standard PMBus registers as raw custom sysfs
files here?

Defining over 80 standard PMBus commands (like vout_command, operation,
clear_faults) as custom attributes bypasses the standardized hwmon ABI
(e.g., in1_input). The PMBus core framework automatically translates
these standard features into the required ABI format.

[ ... ]

> +static int fd5121_read_word_data(struct i2c_client *client, int page,
> +				 int phase, int reg)
> +{
> +	int ret;
> +
> +	ret = fd5121_valid_reg(client, reg);
> +	if (ret < 0)
> +		return ret;
> +
> +	ret = pmbus_read_word_data(client, page, phase, reg);
> +	if (ret < 0)
> +		return ret;
> +
> +	/* Chip reports VOUT_MODE as vid. But gives raw value 1mV per bit.
> +	 * So, encode the READ_VOUT value so that it gets decoded and
> +	 * reported correctly.
> +	 */
> +	if (reg == PMBUS_READ_VOUT)
> +		ret = DIV_ROUND_CLOSEST(155000 - ret * 100, 625);
> +	return ret;
> +}

[Severity: High]
Does this calculation fail for voltages above 1.55V?

Since the raw VOUT is 1mV per bit, if ret is greater than 1550, the
numerator (155000 - ret * 100) evaluates to a negative number. The PMBus
core will interpret this negative value as an error code (e.g., -72),
causing sysfs reads to fail.

> +static int fd5121_write_word_data(struct i2c_client *client, int page,
> +				    int reg, u16 word)
> +{
> +	int ret;
> +
> +	ret = fd5121_valid_reg(client, reg);
> +	if (ret < 0)
> +		return ret;
> +	ret = pmbus_write_word_data(client, page, reg, word);
> +	return ret;
> +}

[Severity: High]
Is there a missing reverse translation for PMBUS_VOUT_COMMAND?

Because info->vrm_version[idx] = amd625mv is declared, the PMBus core
translates requested voltages into AMD VIDs and sends them here. Without
an inverse translation to the hardware's native 1mV/bit format, a VID
like 88 would be written directly, severely undervolting the hardware
to 88mV.

[ ... ]

> +static int fd5121_probe(struct i2c_client *client)
> +{
> +	struct pmbus_driver_info *info;
> +	struct fd5121_data *pdata;
> +	u32 id;
> +
> +	if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C))
> +		return -EOPNOTSUPP;

[Severity: Medium]
Does this unconditionally break compatibility with pure SMBus controllers?

Many standard PC and server host controllers only support SMBus operations
and do not set the I2C_FUNC_I2C flag. Since the driver heavily utilizes
SMBus commands, checking for full I2C functionality might prevent the driver
from probing on common hardware.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260622-support-fd5121-from-onsemi-v1-0-b31767689c65@onsemi.com?part=3