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

[Carlos Song (OSS)]

> -----Original Message-----
> From: Vincent Jardin <vjardin@xxxxxxx>
> Sent: Tuesday, May 26, 2026 12:43 AM
> To: Oleksij Rempel <o.rempel@xxxxxxxxxxxxxx>; Pengutronix Kernel Team
> <kernel@xxxxxxxxxxxxxx>; Andi Shyti <andi.shyti@xxxxxxxxxx>; Frank Li
> <frank.li@xxxxxxx>; Sascha Hauer <s.hauer@xxxxxxxxxxxxxx>; Fabio Estevam
> <festevam@xxxxxxxxx>; Wolfram Sang <wsa@xxxxxxxxxx>; Kaushal Butala
> <kaushalkernelmailinglist@xxxxxxxxx>; Shawn Guo
> <shawn.guo@xxxxxxxxxxxxx>; Stefan Eichenberger
> <stefan.eichenberger@xxxxxxxxxxx>
> Cc: linux-i2c@xxxxxxxxxxxxxxx; imx@xxxxxxxxxxxxxxx;
> linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Vincent
> Jardin <vjardin@xxxxxxx>; stable@xxxxxxxxxxxxxxx
> Subject: [PATCH v2 0/2] i2c: imx: fix SMBus block-read of 0 locking the bus
> 
> [You don't often get email from vjardin@xxxxxxx. 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@xxxxxxx>
>