On Mon, 22 Dec 2025 09:22:06 +0200
Petre Rodan <petre.rodan@subdimension.ro> wrote:
> hello Jonathan,
>
> On Sun, Dec 21, 2025 at 06:38:26PM +0000, Jonathan Cameron wrote:
> > On Thu, 18 Dec 2025 13:05:54 +0200
> > Petre Rodan <petre.rodan@subdimension.ro> wrote:
> >
> > > Interrupt falling/rising flags should only be defined in the device tree.
> > >
> > > Fixes: 713337d9143e ("iio: pressure: Honeywell mprls0025pa pressure sensor")
> > > Signed-off-by: Petre Rodan <petre.rodan@subdimension.ro>
> > Gah. We shoudn't have let this slip through in 2023.
> > Some old drivers have done this for many years and for those we definitely
> > can't be sure there aren't boards with it set wrong in DT that will see
> > a regression with this fix.
> >
> > For a 2023 driver, maybe we can gamble that no one has broken DT (where this
> > would annoyingly be a regression). One other question below.
> >
> >
> > > ---
> > > drivers/iio/pressure/mprls0025pa.c | 5 ++---
> > > 1 file changed, 2 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/iio/pressure/mprls0025pa.c b/drivers/iio/pressure/mprls0025pa.c
> > > index 243a5717b88f..fc04988b9437 100644
> > > --- a/drivers/iio/pressure/mprls0025pa.c
> > > +++ b/drivers/iio/pressure/mprls0025pa.c
> > > @@ -14,6 +14,7 @@
> > > #include <linux/bits.h>
> > > #include <linux/delay.h>
> > > #include <linux/errno.h>
> > > +#include <linux/interrupt.h>
> > > #include <linux/math64.h>
> > > #include <linux/mod_devicetable.h>
> > > #include <linux/module.h>
> > > @@ -404,9 +405,7 @@ int mpr_common_probe(struct device *dev, const struct mpr_ops *ops, int irq)
> > >
> > > if (data->irq > 0) {
> > > ret = devm_request_irq(dev, data->irq, mpr_eoc_handler,
> > > - IRQF_TRIGGER_RISING,
> > > - dev_name(dev),
> > > - data);
> > > + IRQF_ONESHOT, dev_name(dev), data);
> > IRQF_ONESHOT addition here needs a separate explanation. Might well be correct
> > but it's not related to your patch description.
>
> do you feel like IRQF_TRIGGER_NONE would be a better fit?
That would be the minimal change.
>
> I used ONESHOT just because it seemed like a good idea to isolate the sensor while the handler is running (if I understand the documentation correctly).
It's normally only necessary for devices where we might get
more interrupts signalled before we have performed all the operations
we need to for the one we are already handling. E.g. level interrupts
with a threaded handler, or IIRC any freerunning pulse type interrupt.
Jonathan
>
> best regards,
> peter
>
> >
> > > if (ret)
> > > return dev_err_probe(dev, ret,
> > > "request irq %d failed\n", data->irq);
> > >
> >
>