From: Dominique Martinet <asmadeus@codewreck.org>
To: Vincent Jardin <vjardin@free.fr>
Cc: Oleksij Rempel <o.rempel@pengutronix.de>,
Pengutronix Kernel Team <kernel@pengutronix.de>,
Andi Shyti <andi.shyti@kernel.org>, Frank Li <Frank.Li@nxp.com>,
Sascha Hauer <s.hauer@pengutronix.de>,
Fabio Estevam <festevam@gmail.com>, Wolfram Sang <wsa@kernel.org>,
Kaushal Butala <kaushalkernelmailinglist@gmail.com>,
Shawn Guo <shawn.guo@freescale.com>,
Stefan Eichenberger <stefan.eichenberger@toradex.com>,
linux-i2c@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org,
Carlos Song <carlos.song@nxp.com>,
Stefan Eichenberger <eichest@gmail.com>
Subject: Re: [PATCH v3 0/2] i2c: imx: fix SMBus block-read of 0 locking the bus [stable backport question/offer]
Date: Fri, 21 Aug 2026 18:07:35 +0900 [thread overview]
Message-ID: <aogVVwPlOmCqFsg_@codewreck.org> (raw)
In-Reply-To: <20260713-for-upstream-i2c-lx2160-fix-v1-v3-0-073ac9e103a5@free.fr>
Vincent Jardin wrote on Mon, Jul 13, 2026 at 08:11:58PM +0200:
> i2c-imx rejects an SMBus Block Read byte count of 0 (valid per SMBus 3.1
> 6.5.7) as -EPROTO and returns without emitting a NACK + STOP, leaving the
> target holding SDA so the bus stays stuck until a power cycle.
>
> It was triggered by an MPQ8785 PMBus regulator on a LX2160A i2c
> bus: when the kernel binds it using the pmbus/hwmon framework, the bus
> locks up and it does never recovers. It was confirmed with a scope, with
> and without the fix.
>
> The same bug is occuring with two independently introduced spots, so the
> fix is two patches with their respective Fixes: tags and backport ranges
>
> 1/2 atomic/polling path Fixes: 8e8782c71595 v3.16+
> 2/2 IRQ-driven state machine Fixes: 5f5c2d4579ca v6.13+
Silly question (half for stable people, half for i2c-imx maintainers),
but the backport for commit cb2fc3785769 ("i2c: imx: fix locked bus on
SMBus block-read of 0 (atomic)") to stable brought in b460b15b3cc2
("i2c: imx: separate atomic, dma and non-dma use case") (also 6.13+) as
a dep (all the way back to 5.10!);
with that commit in, 5f5c2d4579ca ("i2c: imx: prevent rescheduling in non
dma mode") applies almost cleanly on 6.6/6.12[1]... So should we grab
more easy fixes?
In particular, I doubt I'll ever hit this SMBus 3.1 bug, but
5f5c2d4579ca also was a real fix[2], so would it make sense to jump in
and get both 5f5c2d4579ca and 07fd9385f0d8 ("i2c: imx: fix locked bus on
SMBus block-read of 0 (IRQ)") for 6.6/6.12?
[1] just a trivial context conflict in the struct there, but it starts
being more iffy on 6.1 and earlier kernels
[2] ... We actually ran into that bug on 5.10, our kludgy backport being
the reason I noticed during today's 5.10.266-rc1 testing...
Honestly, I wouldn't have considered backporting either as b460b15b3cc2
("i2c: imx: separate atomic, dma and non-dma use case") looks too big to
backport to me, so I definitely wouldn't have done it before, but that
ship has sailed (it's in the 5.10 -rc right now, but it's been merged a
couple of weeks ago in higher versions stables), so at this point I
don't think it's worth reverting either and we might as well keep
falling forward...
tl;dr: If maintainers agree, I can send these two for a future 6.6/6.12:
5f5c2d4579ca ("i2c: imx: prevent rescheduling in non dma mode")
07fd9385f0d8 ("i2c: imx: fix locked bus on SMBus block-read of 0 (IRQ)")
Thanks,
--
Dominique Martinet | Asmadeus
prev parent reply other threads:[~2026-08-21 9:08 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-13 18:11 [PATCH v3 0/2] i2c: imx: fix SMBus block-read of 0 locking the bus Vincent Jardin
2026-07-13 18:11 ` [PATCH v3 1/2] i2c: imx: fix locked bus on SMBus block-read of 0 (atomic) Vincent Jardin
2026-07-13 18:12 ` [PATCH v3 2/2] i2c: imx: fix locked bus on SMBus block-read of 0 (IRQ) Vincent Jardin
2026-07-14 15:00 ` [PATCH v3 0/2] i2c: imx: fix SMBus block-read of 0 locking the bus Andi Shyti
2026-07-14 15:18 ` Vincent Jardin
2026-07-14 15:45 ` Wolfram Sang
2026-07-16 15:03 ` Andi Shyti
2026-08-21 9:07 ` Dominique Martinet [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aogVVwPlOmCqFsg_@codewreck.org \
--to=asmadeus@codewreck.org \
--cc=Frank.Li@nxp.com \
--cc=andi.shyti@kernel.org \
--cc=carlos.song@nxp.com \
--cc=eichest@gmail.com \
--cc=festevam@gmail.com \
--cc=imx@lists.linux.dev \
--cc=kaushalkernelmailinglist@gmail.com \
--cc=kernel@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=o.rempel@pengutronix.de \
--cc=s.hauer@pengutronix.de \
--cc=shawn.guo@freescale.com \
--cc=stable@vger.kernel.org \
--cc=stefan.eichenberger@toradex.com \
--cc=vjardin@free.fr \
--cc=wsa@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox