[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <0b7b6086-ec1c-4623-b836-a1450d39b44e@roeck-us.net>
Date: Thu, 13 Nov 2025 09:42:05 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: Lakshay Piplani <lakshay.piplani@....com>
Cc: linux-hwmon@...r.kernel.org, linux-kernel@...r.kernel.org,
vikash.bansal@....com, priyanka.jain@....com,
shashank.rebbapragada@....com
Subject: Re: [PATCH] hwmon: (lm75) Add software-based alarm support for NXP
P3T1750/P3T1755
On Thu, Nov 13, 2025 at 04:50:11PM +0530, Lakshay Piplani wrote:
> NXP P3T1750/P3T1755 does not provide readable alarm/status bits. To support
> the standard tempX_alarm attribute, implement the comparator mode threshold
> checks in the software using THIGH and TLOW registers.
>
The ABI says "The driver should just reflect the hardware implementation",
which really means that it should not try to implement software based
alarm attributes.
This is in line with all other drivers: We don't try to simulate alarms if
not provided by hardware. The key point here is that the absence of alarm
attributes means that userspace has to poll temperature values to determine
if there is an alarm or not. This gets lost here: As long as the alarm file
is not read, the driver won't report an alarm. Userspace polling on the
alarm attribute (using the poll or epoll system call, or udev events) won't
get notified and miss that an alarm was triggered. This would be much worse
than the current situation.
Granted, many drivers don't implement interrupts and would also not get
notified, but that is a driver limitation and not an argument for
implementing software based alarms.
Guenter
Powered by blists - more mailing lists