Re: [PATCH AUTOSEL 7.0-6.18] hwmon: (pmbus/isl68137) Add support for Renesas RAA228942 and RAA228943

[sashiko-bot@kernel.org]

Sashiko AI review found 1 potential issue(s):
- [High] Unchecked dereference of `i2c_match_id()` in probe function causes a kernel panic when using Device Tree fallback compatibles, forcing unnecessary driver updates.
--

commit b782f8e0961d8ebf5fabe49f49ad99e6bb11a058
Author: Dawei Liu <dawei.liu.jy@renesas.com>

hwmon: (pmbus/isl68137) Add support for Renesas RAA228942 and RAA228943

This commit adds I2C device IDs for the Renesas RAA228942 and RAA228943
chips. The commit message notes that devicetree will use fallback
compatibles and no dedicated OF match entries are needed.

Link: https://lore.kernel.org/r/20260325090208.857-3-dawei.liu.jy@renesas.com

> At the Linux PMBus hwmon interface level currently supported by this
> driver, these devices are compatible with the existing 2-rail non-TC
> controllers, so devicetree will use fallback compatibles and no
> dedicated OF match entries are needed.

If no dedicated OF match entries are needed and fallback compatibles are
used, does this addition to the I2C device ID table serve as a workaround
for a NULL pointer dereference during probe?

Looking at isl68137_probe():

drivers/hwmon/pmbus/isl68137.c:isl68137_probe() {
    ...
    switch (i2c_match_id(raa_dmpvr_id, client)->driver_data) {
    case raa_dmpvr1_2rail:
    ...
}

If a device is probed via a fallback compatible and its exact name isn't
present in the raa_dmpvr_id table, wouldn't i2c_match_id() return NULL
and cause a kernel panic when dereferencing ->driver_data?

> diff --git a/drivers/hwmon/pmbus/isl68137.c b/drivers/hwmon/pmbus/isl68137.c
> index 3e3a887aad050..c8930f2d54237 100644
> --- a/drivers/hwmon/pmbus/isl68137.c
> +++ b/drivers/hwmon/pmbus/isl68137.c
> @@ -498,6 +498,8 @@ static const struct i2c_device_id raa_dmpvr_id[] = {
>  	{"raa228228", raa_dmpvr2_2rail_nontc},
>  	{"raa228244", raa_dmpvr2_2rail_nontc},
>  	{"raa228246", raa_dmpvr2_2rail_nontc},
> +	{"raa228942", raa_dmpvr2_2rail_nontc},
> +	{"raa228943", raa_dmpvr2_2rail_nontc},
>  	{"raa229001", raa_dmpvr2_2rail},
>  	{"raa229004", raa_dmpvr2_2rail},

Could isl68137_probe() be updated to use i2c_get_match_data() instead?

This would extract match data directly from the OF fallback node without
panicking, making the raa_dmpvr_id additions unnecessary.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260420131539.986432-72-sashal@kernel.org?part=1