Re: [EXT] Re: [PATCH v4 0/2] iio: temperature: Add support for NXP P3T175x temperature sensors

[Jonathan Cameron <jic23@kernel.org>]

On Thu, 9 Oct 2025 15:37:42 -0700
Guenter Roeck <linux@roeck-us.net> wrote:

> On 10/8/25 22:56, Lakshay Piplani wrote:
> >   
> >> -----Original Message-----
> >> From: Guenter Roeck <groeck7@gmail.com> On Behalf Of Guenter Roeck
> >> Sent: Wednesday, October 8, 2025 7:41 PM
> >> To: Lakshay Piplani <lakshay.piplani@nxp.com>; linux-kernel@vger.kernel.org;
> >> linux-iio@vger.kernel.org; jic23@kernel.org; dlechner@baylibre.com;
> >> nuno.sa@analog.com; andy@kernel.org; marcelo.schmitt1@gmail.com;
> >> gregkh@linuxfoundation.org; viro@zeniv.linux.org.uk; peterz@infradead.org;
> >> jstephan@baylibre.com; robh@kernel.org; krzk+dt@kernel.org;
> >> conor+dt@kernel.org; devicetree@vger.kernel.org
> >> Cc: jdelvare@suse.com; Vikash Bansal <vikash.bansal@nxp.com>; Priyanka
> >> Jain <priyanka.jain@nxp.com>; Shashank Rebbapragada
> >> <shashank.rebbapragada@nxp.com>
> >> Subject: [EXT] Re: [PATCH v4 0/2] iio: temperature: Add support for NXP
> >> P3T175x temperature sensors
> >>
> >> [You don't often get email from linux@roeck-us.net. Learn why this is
> >> important at https://aka.ms/LearnAboutSenderIdentification ]
> >>
> >> Caution: This is an external email. Please take care when clicking links or
> >> opening attachments. When in doubt, report the message using the 'Report
> >> this email' button
> >>
> >>
> >> On 10/8/25 03:07, Lakshay Piplani wrote:  
> >>> This patch adds support for the P3T1750/P3T1755 temperature sensors  
> >> under the IIO subsystem.  
> >>>
> >>> P3T1750/P3T1755 support two operational modes:
> >>> 1. Comparator Mode
> >>> 2. Interrupt (Latched) Mode
> >>>
> >>> The HWMON subsystem is more suitable for implementing drivers for  
> >> comparator mode operations.  
> >>> Reason:
> >>>     - Temperature thresholds can be polled and exposed via sysfs.
> >>>     - Register reads do not clear status, allowing safe alarm state derivation.
> >>>     - Matches existing drivers under hwmon.
> >>>
> >>> The IIO subsystem is more suitable for implementing drivers for interrupt  
> >> (latched) mode operations.  
> >>> Reason:
> >>>     - Interrupt mode uses edge-triggered ALERT/IBI signal interrupts, which  
> >> can be pushed to user space using iio_push_event.  
> >>>     - IIO's event API (IIO_EV_TYPE_THRESH) supports timestamped  
> >> rising/falling edge events.  
> >>>     - I3C IBI integration maps naturally to IIO's event push model.
> >>>     - No persistent alarm bits are available; so polling in HWMON may result in  
> >> missing events.  
> >>>  
> >>
> >> This is just wrong. Interrupt support can just as well be implemented in a
> >> hwmon driver.
> >>
> >> Guenter  
> > 
> > Hi Guenter,
> > 
> > Thanks - agreed, hwmon drivers can support interrupts.
> > The distinction I meant to highlight is about semantic alignment.
> > Both P3T1750 and P3T1755 does not provide alarm/status bits. In TM=1 (interrupt mode), the alert is latched
> > but cleared on register read, with no way to query alarm state afterward.
> > 
> > HWMON typically polls alarm flags via IRQs, expecting them to remain asserted during threshold violations.
> > Without persistent bits, supporting interrupts in hwmon would require emulating state in software, which diverges  
> 
> So ? Various drivers already do that. It is not even necessary to "emulate
> the state in software". Just store the state in the interrupt handler, and
> report (and clear) the state when the alarm file(s) are read.
> 
> > from its ABI and could mislead userspace expecting stable *_alarm files.  
> 
> This is just incorrect.
> 
> > IIO's event API, being edge-triggered and timestamped, aligns more naturally with
> > this transient behavior and with I3C IBI signaling.
> > 
> > I'll reword the cover letter to clarify that this is a design choice based on ABI semantics, not a limitation of hwmon.  
> 
> Again, that design choice is not a reason to have two drivers for the same chip.
> 
> Guenter

+1.  I'm not seeing anything yet that rules out a straight forward hwmon driver for this
and as it is a simple temperature sensor hwmon is preferred home.

Jonathan