All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Abdurrahman Hussain" <abdurrahman@nexthop.ai>
Cc: linux-hwmon@vger.kernel.org
Subject: Re: [PATCH] hwmon: (pmbus/xdpe1a2g7b) Add regulator support
Date: Sat, 20 Jun 2026 06:53:57 +0000	[thread overview]
Message-ID: <20260620065358.0FA801F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260619-xdpe1a2g7b-v1-1-428c3847be0d@nexthop.ai>

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

  reply	other threads:[~2026-06-20  6:53 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-20  6:44 [PATCH] hwmon: (pmbus/xdpe1a2g7b) Add regulator support Abdurrahman Hussain
2026-06-20  6:53 ` sashiko-bot [this message]
2026-06-20  7:47   ` Abdurrahman Hussain

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260620065358.0FA801F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=abdurrahman@nexthop.ai \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.