All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Aryan Srivastava" <aryan.srivastava@alliedtelesis.co.nz>
Cc: linux-hwmon@vger.kernel.org
Subject: Re: [PATCH v0 2/2] hwmon: pmbus: Add tps546e25 to generic pmbus
Date: Fri, 04 Sep 2026 01:10:16 +0000	[thread overview]
Message-ID: <20260904011016.8BA331F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260904005351.2136374-3-aryan.srivastava@alliedtelesis.co.nz>

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

New issues:
- [Medium] The new `tps546e25` device entry incorrectly uses `pmbus_info_zero` instead of `pmbus_info_one`, which forces unnecessary dynamic page probing.
- [Low] The new compatible string is not documented in the device tree bindings.
- [Low] The new device is missing from the generic PMBus driver documentation.

Pre-existing issues:
- [High] Potential NULL pointer dereference of `device_info` in `pmbus_probe()`.
--

commit fc4eef8dbc6c89c58d89c8feeedc224bbb325745
Author: Aryan Srivastava <aryan.srivastava@alliedtelesis.co.nz>
Subject: hwmon: pmbus: Add tps546e25 to generic pmbus

This commit adds support for the tps546e25 device to the generic PMBus driver.
It operates over SMBus and is similar to other TI DCDC devices.

> diff --git a/drivers/hwmon/pmbus/pmbus.c b/drivers/hwmon/pmbus/pmbus.c
> index b629acbffbfb6..96a72950e7d36 100644
> --- a/drivers/hwmon/pmbus/pmbus.c
> +++ b/drivers/hwmon/pmbus/pmbus.c
> @@ -245,6 +245,7 @@ static const struct i2c_device_id pmbus_id[] = {
>  	{ .name = "tps544b25", .driver_data = (kernel_ulong_t)&pmbus_info_one },
>  	{ .name = "tps544c20", .driver_data = (kernel_ulong_t)&pmbus_info_one },
>  	{ .name = "tps544c25", .driver_data = (kernel_ulong_t)&pmbus_info_one },
> +	{ .name = "tps546e25", .driver_data = (kernel_ulong_t)&pmbus_info_zero },

[Severity: Medium]
Since this is similar to other TI DCDC devices, should this use pmbus_info_one
instead of pmbus_info_zero?

Using pmbus_info_zero forces dynamic page probing, which causes unnecessary
I2C/SMBus traffic. If the device ignores the data but ACKs out-of-range page
writes, it could expose 32 identical phantom pages in sysfs.

>  	{ .name = "udt020", .driver_data = (kernel_ulong_t)&pmbus_info_one },
>  	{ }
>  };


[Severity: Low]
Is it intentional that the new device is omitted from the device tree bindings?

Adding ti,tps546e25 to Documentation/devicetree/bindings/trivial-devices.yaml
would prevent dtbs_check warnings when this compatible string is used.


[Severity: Low]
Could we also update the supported hardware documentation in
Documentation/hwmon/pmbus.rst?

Adding the TPS546E25 to the list of Texas Instruments devices and its prefix
'tps546e25' would ensure users know it is supported by this driver.


[Severity: High]
This is a pre-existing issue, but I noticed a potential NULL pointer dereference
in pmbus_probe().

drivers/hwmon/pmbus/pmbus.c:pmbus_probe() {
    ...
	device_info = (struct pmbus_device_info *)i2c_get_match_data(client);
	if (device_info->flags) {
    ...
}

If the driver is bound manually via sysfs (e.g., using driver_override)
without an I2C ID that matches the driver's id_table, i2c_get_match_data()
will return NULL. The code immediately dereferences device_info->flags,
which will cause a kernel crash.

Does this need to be checked before dereferencing?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260904005351.2136374-1-aryan.srivastava@alliedtelesis.co.nz?part=2

      reply	other threads:[~2026-09-04  1:10 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-04  0:53 [PATCH v0 0/2] Add support for tps546e25 Aryan Srivastava
2026-09-04  0:53 ` [PATCH v0 1/2] hwmon: pmbus: Fix vout_mode parsing Aryan Srivastava
2026-09-04  1:07   ` sashiko-bot
2026-09-04 15:04   ` Guenter Roeck
2026-09-05  5:09     ` Aryan Srivastava
2026-09-04 15:06   ` Guenter Roeck
2026-09-04  0:53 ` [PATCH v0 2/2] hwmon: pmbus: Add tps546e25 to generic pmbus Aryan Srivastava
2026-09-04  1:10   ` sashiko-bot [this message]

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=20260904011016.8BA331F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=aryan.srivastava@alliedtelesis.co.nz \
    --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.