linux-kernel - Re: [Patch V4] i2c: imx-lpi2c: fix SMBus block read NACK after byte count

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aYKnAfQTvSrjJLhE@zenone.zhora.eu>
Date: Wed, 4 Feb 2026 02:55:34 +0100
From: Andi Shyti <andi.shyti@...nel.org>
To: Carlos Song <carlos.song@....com>
Cc: aisheng.dong@....com, s.hauer@...gutronix.de, kernel@...gutronix.de, 
	festevam@...il.com, pandy.gao@....com, vz@...ia.com, wsa@...nel.org, 
	B38611@...escale.com, linux-i2c@...r.kernel.org, imx@...ts.linux.dev, 
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org, Frank Li <Frank.Li@....com>
Subject: Re: [Patch V4] i2c: imx-lpi2c: fix SMBus block read NACK after byte
 count

Hi Carlos,

On Fri, Jan 23, 2026 at 06:54:58PM +0800, Carlos Song wrote:
> The LPI2C controller sends a NACK at the end of a receive command
> unless another receive command is already queued in MTDR. During
> SMBus block reads, this causes the controller to NACK immediately
> after receiving the block length byte, aborting the transfer before
> the data bytes are read.
> 
> Fix this by queueing a second receive command as soon as the block
> length byte is received, keeping MTDR non-empty and ensuring
> continuous ACKs. The initial receive command reads the block length,
> and the subsequent command reads the remaining data bytes according
> to the reported length.
> 
> Fixes: a55fa9d0e42e ("i2c: imx-lpi2c: add low power i2c bus driver")
> Signed-off-by: Carlos Song <carlos.song@....com>
> Reviewed-by: Frank Li <Frank.Li@....com>

merged to i2c/i2c-host-fixes.

Thanks,
Andi