Re: [hwmon PATCH v2 8/8] hwmon: (adt7470) Fix PWM auto temp state array and bounds check
[email protected] Tue, 28 Jul 2026 00:40:14 +0000
| Newsgroups | org.kernel.vger.linux-hwmon |
|---|---|
| Message-ID | <[email protected]> |
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: Pre-existing issues: - [High] The driver violates HWMON subsystem guidelines by using a private mutex (`data->lock`) instead of the required `hwmon_lock()` API to serialize sysfs attributes registered outside the `info` structure. -- --- Patch [8]: [hwmon PATCH v2 8/8] hwmon: (adt7470) Fix PWM auto temp state array and bounds check --- commit 3702a967e9e4da59d546cf6a3b0fc208ec5ff2bf Author: Luiz Angelo Daros de Luca <[email protected]> hwmon: (adt7470) Fix PWM auto temp state array and bounds check This commit fixes a bounds checking issue in pwm_auto_temp_store() where values > 0xF could overflow into adjacent channel bits. It also corrects the array assignment so values are written to pwm_auto_temp instead of pwm_automatic after a successful I2C write. Closes: https://lore.kernel.org/all/[email protected]/#t > diff --git a/drivers/hwmon/adt7470.c b/drivers/hwmon/adt7470.c > index 772d2a409bb5c..c45b984c02e6b 100644 > --- a/drivers/hwmon/adt7470.c > +++ b/drivers/hwmon/adt7470.c > @@ -1049,8 +1049,10 @@ static ssize_t pwm_auto_temp_store(struct device *dev, > if (temp < 0) > return temp; > > + if (temp > 0xF) > + return -EINVAL; > + > mutex_lock(&data->lock); [Severity: High] This is a pre-existing issue, but does this driver violate the hwmon subsystem locking guidelines by using a private mutex here? According to the hardware monitoring API documentation, drivers must implement locking required for interrupt handling and for attributes registered outside the standard info structure using hwmon_lock() and hwmon_unlock(). The core relies on this to serialize thermal subsystem and sysfs operations. By using the private data->lock in pwm_auto_temp_store(), could this bypass the central hwmon locking mechanism and cause concurrency issues with the thermal subsystem? Would it make sense to update this to use hwmon_lock(dev)? > - data->pwm_automatic[attr->index] = temp; > > if (!(attr->index % 2)) { > mask = 0xF0; [ ... ] -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=8