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

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.

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.

07fd9385f0d8 on its own buys nothing there either: it patches
i2c_imx_isr_read_block_data_len(), which only exists once 5f5c2d4579ca is
applied.

Your premise is right that b460b15b3cc2 is now everywhere, but
5f5c2d4579ca also carries five Fixes: follow-ups, four of them tagged
Cc: stable # v6.13+, none of which are on 6.6/6.12 - so doing it properly
means backporting a six-commit ISR state-machine rework into two frozen
trees, and upstream was still fixing that rework in February.

-- 
Thanks,
Sasha