Re: [PATCH v3 11/13] hwmon: spd5118: Remove 16-bit addressing

[sashiko-bot@kernel.org]

Sashiko AI review found 1 potential issue(s):
- [Medium] The driver violates hwmon subsystem locking rules by using a custom `nvmem_lock`, and correcting this exposes an initialization order race condition where the NVMEM interface is exposed before the hwmon device is registered.
--

commit 8460c5a9338d8916bf61ccb3e598518750ec6cf9
Author: Akhil R <akhilrajeev@nvidia.com>

hwmon: spd5118: Remove 16-bit addressing

This commit removes 16-bit addressing support for the spd5118 driver,
as it is not required for I3C and has no known users. It updates the
regmap configuration and probe functions to only use 8-bit addressing.

> diff --git a/drivers/hwmon/spd5118.c b/drivers/hwmon/spd5118.c
> index 5da44571b6a0ce..8fdde35e68cd3f 100644
> --- a/drivers/hwmon/spd5118.c
> +++ b/drivers/hwmon/spd5118.c
> @@ -78,7 +75,6 @@ static const unsigned short normal_i2c[] = {
>  struct spd5118_data {
>  	struct regmap *regmap;
>  	struct mutex nvmem_lock;
> -	bool is_16bit;
>  };

Does this custom lock violate the hwmon subsystem locking guidelines?

The guidelines state that drivers must serialize attributes registered by
other means using hwmon_lock() and hwmon_unlock().

If this code is updated to comply with the guideline by replacing
nvmem_lock with hwmon_lock(data->hwmon_dev), could it expose a race
condition during initialization?

Looking at spd5118_common_probe():

spd5118_common_probe()
    spd5118_nvmem_init(dev, data);
    ...
    hwmon_dev = devm_hwmon_device_register_with_info(dev, ...);

Since spd5118_nvmem_init() is called before the hwmon device is registered,
would this expose the nvmem sysfs file to userspace while the hwmon
locking context is still unregistered, potentially leading to a NULL
pointer dereference?

Should the hwmon device registration happen before the nvmem device
registration to prevent this sequence?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260423085718.70762-1-akhilrajeev@nvidia.com?part=11