[PATCH v2 0/2] i2c: imx: fix SMBus block-read of 0 locking the bus

[Carlos Song (OSS)]

> -----Original Message-----
> From: Vincent Jardin <vjardin at free.fr>
> Sent: Tuesday, May 26, 2026 12:43 AM
> To: Oleksij Rempel <o.rempel at pengutronix.de>; Pengutronix Kernel Team
> <kernel at pengutronix.de>; Andi Shyti <andi.shyti at kernel.org>; Frank Li
> <frank.li at nxp.com>; Sascha Hauer <s.hauer at pengutronix.de>; Fabio Estevam
> <festevam at gmail.com>; Wolfram Sang <wsa at kernel.org>; Kaushal Butala
> <kaushalkernelmailinglist at gmail.com>; Shawn Guo
> <shawn.guo at freescale.com>; Stefan Eichenberger
> <stefan.eichenberger at toradex.com>
> Cc: linux-i2c at vger.kernel.org; imx at lists.linux.dev;
> linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org; Vincent
> Jardin <vjardin at free.fr>; stable at vger.kernel.org
> Subject: [PATCH v2 0/2] i2c: imx: fix SMBus block-read of 0 locking the bus
> 
> [You don't often get email from vjardin at free.fr. Learn why this is important at
> https://aka.ms/LearnAboutSenderIdentification ]
> 
> i2c-imx rejects a SMBus Block Read byte count of 0 (valid per SMBus 3.1
> 6.5.7) and it returns without a NACK+STOP, leaving the target holding SDA so the
> bus is stuck until a power cycle occur.
> 
> 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+
> 


Hi Vincent,

Thanks for working on this fix, this looks good to me.

SMBus block reads with a length of 0 seem quite uncommon in practice.
Was this triggered by a specific device behavior, or mainly found
during boundary / compliance testing?

Regarding the handling of len == 0,
I see that the patch sets:

    msg->buf[0] = 0;
    msg->len = 2;

It relies on the last-byte STOP handling together with TXAK. It will help I2C-IMX generate NACK + STOP and
release the bus, right? len = 0 is a legal behavior, So it go into a successful path.
But len > I2C_SMBUS_BLOCK_MAX is abnormal behavior. So it go into a fail path.
Do I understand it right?

Also, if possible could you briefly describe how you validated this change
(e.g. test setup or steps, with and without the fix)?

Thanks again for the fix.

Carlos

> ---
> Changes in v2:
> - Handle when count > I2C_SMBUS_BLOCK_MAX the same way as count == 0
>   Reported by the Sashiko AI review on v1.
> 
> ---
> Vincent Jardin (2):
>       i2c: imx: fix locked bus on SMBus block-read of 0 (atomic)
>       i2c: imx: fix locked bus on SMBus block-read of 0 (IRQ)
> 
>  drivers/i2c/busses/i2c-imx.c | 36 +++++++++++++++++++++++++++++++++---
>  1 file changed, 33 insertions(+), 3 deletions(-)
> ---
> base-commit: 6916d5703ddf9a38f1f6c2cc793381a24ee914c6
> change-id: 20260525-for-upstream-i2c-lx2160-fix-v1-0cba0a0093e5
> 
> Best regards,
> --
> Vincent Jardin <vjardin at free.fr>
>