Message-ID: <20251012181537.6600e6b8@jic23-huawei>
Date: Sun, 12 Oct 2025 18:15:37 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: Guenter Roeck <linux@...ck-us.net>
Cc: Lakshay Piplani <lakshay.piplani@....com>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
 "dlechner@...libre.com" <dlechner@...libre.com>, "nuno.sa@...log.com"
 <nuno.sa@...log.com>, "andy@...nel.org" <andy@...nel.org>,
 "marcelo.schmitt1@...il.com" <marcelo.schmitt1@...il.com>,
 "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
 "viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>, "peterz@...radead.org"
 <peterz@...radead.org>, "jstephan@...libre.com" <jstephan@...libre.com>,
 "robh@...nel.org" <robh@...nel.org>, "krzk+dt@...nel.org"
 <krzk+dt@...nel.org>, "conor+dt@...nel.org" <conor+dt@...nel.org>,
 "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
 "jdelvare@...e.com" <jdelvare@...e.com>, Vikash Bansal
 <vikash.bansal@....com>, Priyanka Jain <priyanka.jain@....com>, Shashank
 Rebbapragada <shashank.rebbapragada@....com>
Subject: Re: [EXT] Re: [PATCH v4 0/2] iio: temperature: Add support for NXP
 P3T175x temperature sensors

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

> On 10/8/25 22:56, Lakshay Piplani wrote:
> >   
> >> -----Original Message-----
> >> From: Guenter Roeck <groeck7@...il.com> On Behalf Of Guenter Roeck
> >> Sent: Wednesday, October 8, 2025 7:41 PM
> >> To: Lakshay Piplani <lakshay.piplani@....com>; linux-kernel@...r.kernel.org;
> >> linux-iio@...r.kernel.org; jic23@...nel.org; dlechner@...libre.com;
> >> nuno.sa@...log.com; andy@...nel.org; marcelo.schmitt1@...il.com;
> >> gregkh@...uxfoundation.org; viro@...iv.linux.org.uk; peterz@...radead.org;
> >> jstephan@...libre.com; robh@...nel.org; krzk+dt@...nel.org;
> >> conor+dt@...nel.org; devicetree@...r.kernel.org
> >> Cc: jdelvare@...e.com; Vikash Bansal <vikash.bansal@....com>; Priyanka
> >> Jain <priyanka.jain@....com>; Shashank Rebbapragada
> >> <shashank.rebbapragada@....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@...ck-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

Powered by blists - more mailing lists