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

[Lakshay Piplani <lakshay.piplani@nxp.com>]

> -----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
from its ABI and could mislead userspace expecting stable *_alarm files.
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.
Thanks again for the review.

Best regards,
Lakshay