Re: [PATCH v3 0/2] i2c: imx: fix SMBus block-read of 0 locking the bus [stable backport question/offer]

[Dominique Martinet <asmadeus@codewreck.org>]

Sasha Levin wrote on Tue, Aug 25, 2026 at 07:49:30AM -0400:
> Dominique Martinet wrote on Fri, Aug 21, 2026 at 06:07:35PM +0900:
> > 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 for the offer, but let's not take these on 6.6/6.12.

Ok, thanks for taking the time to check and reply!

> 5f5c2d4579ca splits the read path, and the split leaves the block_err
> handling in the atomic variant only, while the live non-dma path ends up
> back in the unfixed handler. On 6.6/6.12 the block-read-of-0 fix that
> shipped in 6.12.101 and its 6.6 sibling landed in the shared
> i2c_imx_read(), which both paths still go through - so pulling the rework
> in would actually re-open the bus lockup those trees are already
> protected against.

Yes, a backport would only make sense with both patches...

> Your premise is right that b460b15b3cc2 is now everywhere, but
> 5f5c2d4579ca also carries five Fixes: follow-ups, four of them tagged

... but now that you've pointed out the others I agree it's more trouble
than it's worth (even if they all apply cleanly after trivially fixing
5f5c2d4579ca's backport), so I'm fine with this
(And that can be reconsidered if more people report timeouts fixed by
5f5c2d4579ca...)


Thanks,
-- 
Dominique Martinet | Asmadeus