| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20260131184337.6e48c759@jic23-huawei>
Date: Sat, 31 Jan 2026 18:43:37 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: Jean-Baptiste Maneyrol <Jean-Baptiste.Maneyrol@....com>
Cc: "akemnade@...nel.org" <akemnade@...nel.org>, David Lechner
<dlechner@...libre.com>, Nuno Sá <nuno.sa@...log.com>, Andy
Shevchenko <andy@...nel.org>, Aaro Koskinen <aaro.koskinen@....fi>, Andreas
Kemnade <andreas@...nade.info>, Kevin Hilman <khilman@...libre.com>, Roger
Quadros <rogerq@...nel.org>, Tony Lindgren <tony@...mide.com>, Rob Herring
<robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
<conor+dt@...nel.org>, Jonathan Cameron <Jonathan.Cameron@...wei.com>,
"linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH 1/2] iio: imu: inv-mpu9150: fix irq ack preventing irq
storms
On Fri, 30 Jan 2026 16:17:58 +0000
Jean-Baptiste Maneyrol <Jean-Baptiste.Maneyrol@....com> wrote:
> >
> >________________________________________
> >From: Jonathan Cameron <jic23@...nel.org>
> >Sent: Sunday, January 11, 2026 13:30
> >To: akemnade@...nel.org <akemnade@...nel.org>
> >Cc: Jean-Baptiste Maneyrol <Jean-Baptiste.Maneyrol@....com>; David Lechner <dlechner@...libre.com>; Nuno Sá <nuno.sa@...log.com>; Andy Shevchenko <andy@...nel.org>; Aaro Koskinen <aaro.koskinen@....fi>; Andreas Kemnade <andreas@...nade.info>; Kevin Hilman <khilman@...libre.com>; Roger Quadros <rogerq@...nel.org>; Tony Lindgren <tony@...mide.com>; Rob Herring <robh@...nel.org>; Krzysztof Kozlowski <krzk+dt@...nel.org>; Conor Dooley <conor+dt@...nel.org>; Jonathan Cameron <Jonathan.Cameron@...wei.com>; linux-iio@...r.kernel.org <linux-iio@...r.kernel.org>; linux-kernel@...r.kernel.org <linux-kernel@...r.kernel.org>; linux-omap@...r.kernel.org <linux-omap@...r.kernel.org>; devicetree@...r.kernel.org <devicetree@...r.kernel.org>
> >Subject: Re: [PATCH 1/2] iio: imu: inv-mpu9150: fix irq ack preventing irq storms
> >
> >On Wed, 31 Dec 2025 22: 14: 16 +0100 akemnade@ kernel. org wrote: > From: Andreas Kemnade <andreas@ kemnade. info> > > IRQ needs to be acked. for some odd reasons, reading from irq status does > not reliable help, enable acking from
> >ZjQcmQRYFpfptBannerStart
> >This Message Is From an External Sender
> >This message came from outside your organization.
> >
> >ZjQcmQRYFpfptBannerEnd
> >On Wed, 31 Dec 2025 22:14:16 +0100
> >akemnade@...nel.org wrote:
> >
> >> From: Andreas Kemnade <andreas@...nade.info>
> >>
> >> IRQ needs to be acked. for some odd reasons, reading from irq status does
> >> not reliable help, enable acking from any register to be on the safe side
> >> and read the irq status register. Comments in the code indicate a known
> >> unreliability with that register.
> >> The blamed commit was tested with mpu6050 in lg,p895 and lg,p880 according
> >> to Tested-bys. But with the MPU9150 in the Epson Moverio BT-200 this leads
> >> to irq storms without properly acking the irq.
> >>
> >> Fixes: 0a3b517c8089 ("iio: imu: inv_mpu6050: fix interrupt status read for old buggy chips")
> >> Signed-off-by: Andreas Kemnade <andreas@...nade.info>
> >Jean-Baptiste,
> >
> >If you have time to look at this that would be great.
> >
> >Whilst here I'll note the defines in this driver could really do with consistency
> >improvements. I'd like to see GENMASK() and BIT() used everywhere.
> >Currently it's mostly the style used in this patch with a few fields in
> >the newer style.
> >
> >Thanks
> >
> >Jonathan
>
> Hello Jonathan,
>
> sorry for the late response. This is a very old chip, I'm sorry I won't be
> able to check the modification on my side.
>
> By looking at it, it seems correct if it is indeed fixing the issue. I'm
> giving my acknowledgement to the patch.
>
> Acked-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@....com>
Good enough for me.
Applied to my local tree for now as we are close to the merge window
and I'll probably rebase before pushing these out.
Thanks,
Jonathan
>
> Thanks,
> JB
>
> >
> >> ---
> >> drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 8 ++++++++
> >> drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h | 2 ++
> >> drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c | 5 ++++-
> >> 3 files changed, 14 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
> >> index b2fa1f4957a5b..5796896d54cd8 100644
> >> --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
> >> +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
> >> @@ -1943,6 +1943,14 @@ int inv_mpu_core_probe(struct regmap *regmap, int irq, const char *name,
> >> irq_type);
> >> return -EINVAL;
> >> }
> >> +
> >> + /*
> >> + * Acking interrupts by status register does not work reliably
> >> + * but seem to work when this bit is set.
> >> + */
> >> + if (st->chip_type == INV_MPU9150)
> >> + st->irq_mask |= INV_MPU6050_INT_RD_CLEAR;
> >> +
> >> device_set_wakeup_capable(dev, true);
> >>
> >> st->vdd_supply = devm_regulator_get(dev, "vdd");
> >> diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h b/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h
> >> index 211901f8b8eb6..6239b1a803f77 100644
> >> --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h
> >> +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h
> >> @@ -390,6 +390,8 @@ struct inv_mpu6050_state {
> >> /* enable level triggering */
> >> #define INV_MPU6050_LATCH_INT_EN 0x20
> >> #define INV_MPU6050_BIT_BYPASS_EN 0x2
> >> +/* allow acking interrupts by any register read */
> >> +#define INV_MPU6050_INT_RD_CLEAR 0x10
> >>
> >> /* Allowed timestamp period jitter in percent */
> >> #define INV_MPU6050_TS_PERIOD_JITTER 4
> >> diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c b/drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c
> >> index 10a4733420759..22c1ce66f99ee 100644
> >> --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c
> >> +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c
> >> @@ -248,7 +248,6 @@ static irqreturn_t inv_mpu6050_interrupt_handle(int irq, void *p)
> >> switch (st->chip_type) {
> >> case INV_MPU6000:
> >> case INV_MPU6050:
> >> - case INV_MPU9150:
> >> /*
> >> * WoM is not supported and interrupt status read seems to be broken for
> >> * some chips. Since data ready is the only interrupt, bypass interrupt
> >> @@ -257,6 +256,10 @@ static irqreturn_t inv_mpu6050_interrupt_handle(int irq, void *p)
> >> wom_bits = 0;
> >> int_status = INV_MPU6050_BIT_RAW_DATA_RDY_INT;
> >> goto data_ready_interrupt;
> >> + case INV_MPU9150:
> >> + /* IRQ needs to be acked */
> >> + wom_bits = 0;
> >> + break;
> >> case INV_MPU6500:
> >> case INV_MPU6515:
> >> case INV_MPU6880:
> >>
> >
>
Powered by blists - more mailing lists