[PATCH linux-6.18.y] hwmon: (lm90) Consistently use our own mutex

[PATCH linux-6.18.y] hwmon: (lm90) Consistently use our own mutex

[Jean Delvare]

The backport of commits b09a45601094 ("hwmon: (lm90) Stop work before
releasing hwmon device") and 873e919e3101 ("hwmon: (lm90) Add lock
protection to lm90_alert") to stable branch 6.18 makes use of the
hwmon_lock()/hwmon_unlock() API. While this API is available in
kernel v6.18, the lm90 driver was not ported to it until v6.19.
Mixing the use of different locking models within the same driver is
unsafe and should be avoided.

Update the backports to consistently use the driver's own mutex.

Signed-off-by: Jean Delvare <jdelvare@suse.de>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Fixes: bed1fc32e0eb ("hwmon: (lm90) Add lock protection to lm90_alert")
Fixes: c98107817b0f ("hwmon: (lm90) Stop work before releasing hwmon device")
---
This is needed for longterm kernel 6.18 only. The backports to older
branches are already correct.

 drivers/hwmon/lm90.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

--- linux-6.18.orig/drivers/hwmon/lm90.c
+++ linux-6.18/drivers/hwmon/lm90.c
@@ -2614,9 +2614,9 @@ static void lm90_stop_work(void *_data)
 {
 	struct lm90_data *data = _data;
 
-	hwmon_lock(data->hwmon_dev);
+	mutex_lock(&data->update_lock);
 	data->shutdown = true;
-	hwmon_unlock(data->hwmon_dev);
+	mutex_unlock(&data->update_lock);
 	cancel_delayed_work_sync(&data->alert_work);
 	cancel_work_sync(&data->report_work);
 }
@@ -2963,7 +2963,7 @@ static void lm90_alert(struct i2c_client
 		 */
 		struct lm90_data *data = i2c_get_clientdata(client);
 
-		hwmon_lock(data->hwmon_dev);
+		mutex_lock(&data->update_lock);
 		if (!data->shutdown && (data->flags & LM90_HAVE_BROKEN_ALERT) &&
 		    (data->current_alarms & data->alert_alarms)) {
 			if (!(data->config & 0x80)) {
@@ -2973,7 +2973,7 @@ static void lm90_alert(struct i2c_client
 			schedule_delayed_work(&data->alert_work,
 				max_t(int, HZ, msecs_to_jiffies(data->update_interval)));
 		}
-		hwmon_unlock(data->hwmon_dev);
+		mutex_unlock(&data->update_lock);
 	} else {
 		dev_dbg(&client->dev, "Everything OK\n");
 	}


-- 
Jean Delvare
SUSE L3 Support

Re: [PATCH linux-6.18.y] hwmon: (lm90) Consistently use our own mutex

[Greg KH]

On Fri, Oct 30, 2026 at 09:24:10AM +0100, Jean Delvare wrote:
> The backport of commits b09a45601094 ("hwmon: (lm90) Stop work before
> releasing hwmon device") and 873e919e3101 ("hwmon: (lm90) Add lock
> protection to lm90_alert") to stable branch 6.18 makes use of the
> hwmon_lock()/hwmon_unlock() API. While this API is available in
> kernel v6.18, the lm90 driver was not ported to it until v6.19.
> Mixing the use of different locking models within the same driver is
> unsafe and should be avoided.
> 
> Update the backports to consistently use the driver's own mutex.

Oh that's going to cause problems over time, right?  Why can't we take
the change that did the port instead to make this easier to maintain,
otherwise we will be hitting this problem constantly for any changes for
the next X years that this kernel is alive.

thanks,

greg k-h

Re: [PATCH linux-6.18.y] hwmon: (lm90) Consistently use our own mutex

[Jean Delvare]

Hi Greg,

On Fri, 2026-10-30 at 09:41 +0100, Greg KH wrote:
> On Fri, Oct 30, 2026 at 09:24:10AM +0100, Jean Delvare wrote:
> > The backport of commits b09a45601094 ("hwmon: (lm90) Stop work before
> > releasing hwmon device") and 873e919e3101 ("hwmon: (lm90) Add lock
> > protection to lm90_alert") to stable branch 6.18 makes use of the
> > hwmon_lock()/hwmon_unlock() API. While this API is available in
> > kernel v6.18, the lm90 driver was not ported to it until v6.19.
> > Mixing the use of different locking models within the same driver is
> > unsafe and should be avoided.
> > 
> > Update the backports to consistently use the driver's own mutex.
> 
> Oh that's going to cause problems over time, right?  Why can't we take
> the change that did the port instead to make this easier to maintain,
> otherwise we will be hitting this problem constantly for any changes for
> the next X years that this kernel is alive.

Any lm90 backport involving locking will have to be adjusted for all
longterm and distribution kernels < 6.18 anyway, so this does not cause
extra work.

But you are right that it could cause trouble in the future if someone
backports a fix without paying attention to the locking model
difference, as it will not cause a build failure nor even warning, as
it has happened twice already.

Backporting e9b64fae44be ("hwmon: (lm90) Rely on subsystem locking")
should work too, I see it applies nicely on top of kernel 6.18.59, so
you can apply that (to linux-6.18.y only!) instead of my fix-up patch
if you prefer.

Thanks,
-- 
Jean Delvare
SUSE L3 Support

Re: [PATCH linux-6.18.y] hwmon: (lm90) Consistently use our own mutex

[Guenter Roeck]

On 10/30/26 11:21, Jean Delvare wrote:
> Hi Greg,
> 
> On Fri, 2026-10-30 at 09:41 +0100, Greg KH wrote:
>> On Fri, Oct 30, 2026 at 09:24:10AM +0100, Jean Delvare wrote:
>>> The backport of commits b09a45601094 ("hwmon: (lm90) Stop work before
>>> releasing hwmon device") and 873e919e3101 ("hwmon: (lm90) Add lock
>>> protection to lm90_alert") to stable branch 6.18 makes use of the
>>> hwmon_lock()/hwmon_unlock() API. While this API is available in
>>> kernel v6.18, the lm90 driver was not ported to it until v6.19.
>>> Mixing the use of different locking models within the same driver is
>>> unsafe and should be avoided.
>>>
>>> Update the backports to consistently use the driver's own mutex.
>>
>> Oh that's going to cause problems over time, right?  Why can't we take
>> the change that did the port instead to make this easier to maintain,
>> otherwise we will be hitting this problem constantly for any changes for
>> the next X years that this kernel is alive.
> 
> Any lm90 backport involving locking will have to be adjusted for all
> longterm and distribution kernels < 6.18 anyway, so this does not cause
> extra work.
> 
> But you are right that it could cause trouble in the future if someone
> backports a fix without paying attention to the locking model
> difference, as it will not cause a build failure nor even warning, as
> it has happened twice already.
> 
> Backporting e9b64fae44be ("hwmon: (lm90) Rely on subsystem locking")
> should work too, I see it applies nicely on top of kernel 6.18.59, so
> you can apply that (to linux-6.18.y only!) instead of my fix-up patch
> if you prefer.
> 

That would be ok with me.
Thanks,
Guenter

Re: [PATCH linux-6.18.y] hwmon: (lm90) Consistently use our own mutex

[Sasha Levin]

> Oh that's going to cause problems over time, right?  Why can't we take
> the change that did the port instead to make this easier to maintain,
> otherwise we will be hitting this problem constantly for any changes for
> the next X years that this kernel is alive.

Agreed. I queued e9b64fae44be ("hwmon: (lm90) Rely on subsystem locking") for
6.18 instead of the stable-only patch. It applies cleanly and leaves lm90 with
the single hwmon_lock model that mainline uses.

Jean, thanks for catching this.

-- 
Thanks,
Sasha