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

[Guenter Roeck]

On 10/8/25 22:56, Lakshay Piplani wrote:
> > -----Original Message-----
> > From: Guenter Roeck <groeck7@xxxxxxxxx> On Behalf Of Guenter Roeck
> > Sent: Wednesday, October 8, 2025 7:41 PM
> > To: Lakshay Piplani <lakshay.piplani@xxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx;
> > linux-iio@xxxxxxxxxxxxxxx; jic23@xxxxxxxxxx; dlechner@xxxxxxxxxxxx;
> > nuno.sa@xxxxxxxxxx; andy@xxxxxxxxxx; marcelo.schmitt1@xxxxxxxxx;
> > gregkh@xxxxxxxxxxxxxxxxxxx; viro@xxxxxxxxxxxxxxxxxx; peterz@xxxxxxxxxxxxx;
> > jstephan@xxxxxxxxxxxx; robh@xxxxxxxxxx; krzk+dt@xxxxxxxxxx;
> > conor+dt@xxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx
> > Cc: jdelvare@xxxxxxxx; Vikash Bansal <vikash.bansal@xxxxxxx>; Priyanka
> > Jain <priyanka.jain@xxxxxxx>; Shashank Rebbapragada
> > <shashank.rebbapragada@xxxxxxx>
> > Subject: [EXT] Re: [PATCH v4 0/2] iio: temperature: Add support for NXP
> > P3T175x temperature sensors
> >
> > [You don't often get email from linux@xxxxxxxxxxxx. 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