Re: [PATCH 2/3] iio: accel: Add support for ICM42370P

Hi Joshua!
On Fri, 2026-08-07 at 15:40 +0200, Kanak Shilledar wrote:
> Hi Joshua,
> 
> On Fri, 2026-08-07 at 12:09 +0200, Joshua Crofts wrote:
> > [You don't often get email from [email protected]. Learn why
> > this is important at
> > https://aka.ms/LearnAboutSenderIdentification ]
> > 
> > On Thu, 6 Aug 2026 14:46:28 +0200
> > Kanak Shilledar <[email protected]> wrote:
> > 
> > > Add support for the Invensense ICM42370P MEMS MotionTracking 3-
> > > axis
> > > accelerometer with a built-in temperature sensor. Compared to
> > > other
> > > sensors from the same vendor ICM42370 uses a different way of
> > > handling
> > > register banks. Although the device supports I2C, SPI, and I3C,
> > > implement only I2C support.  Provide basic support for raw sensor
> > > reads and a sysfs interface for setting the calibration bias.
> > > Keep
> > > 
[snip]
> > > +static irqreturn_t inv_icm42370_irq_timestamp(int irq, void
> > > *_data)
> > > +{
> > > +     struct inv_icm42370_data *dev_data = _data;
> > > +
> > > +     dev_data->timestamp = iio_get_time_ns(dev_data-
> > > >indio_accel);
> > > +
> > > +     return IRQ_WAKE_THREAD;
> > > +}
> > > +
> > > +static irqreturn_t inv_icm42370_irq_handler(int irq, void
> > > *_data)
> > > +{
> > > +     struct inv_icm42370_data *dev_data = _data;
> > > +     unsigned int status;
> > > +     int ret;
> > > +
> > > +     mutex_lock(&dev_data->lock);
> > 
> > Use guard(mutex) from cleanup.h, it eliminates the need to use
> > gotos
> > and
> > labels for cleaning up functions (a lot of examples in IIO for
> > this).
> 
> Will convert all instances of mutex operations with a guard(mutex).
> 
> > > +
> > > +     ret = regmap_read(dev_data->map,
> > > INV_ICM42370_REG_INT_STATUS,
> > > &status);
> > > +     if (ret)
> > > +             goto out_unlock;
> > > +
> > > +out_unlock:
> > > +     mutex_unlock(&dev_data->lock);
> > > +     return IRQ_HANDLED;
> > 
> > Not sure, but is it okay to always return IRQ_HANDLED, even on
> > regmap
> > failure?
> 
> From some reference drivers it seems to be common, but we will
> investigate this.

To conclude this thread, I went through the drivers and there are only
3 return values (c.f. linux/irqreturn.h) and interrupt is caused by the
device which is not shared by any other driver, thus we should mark the
interrupt as handled even on failure.
> 
> > 
> > > 
Thanks and Regards,
Kanak Shilledar

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQRZbIB7R61KYt5yWsuslrbqDH4eIAUCan26kAAKCRCslrbqDH4e
IOIAAP48VXNtMPwc/vHLJpePr1UD6kSoLkff1XOd3fn/Vwco7wEA1Apf0PlT2NLu
tI+soFH8XPgkJLaUSF4ZhG0jSR/AnAk=
=cQ1c
-----END PGP SIGNATURE-----