Re: [PATCH v3 1/2] i2c: imx: fix locked bus on SMBus block-read of 0 (atomic)

[Vincent Jardin <vjardin@free.fr>]

Hi Bot,

Le 13/07/26 18:26, sashiko-bot@kernel.org a écrit :
> - [High] `i2c_imx_prepare_read()` fails to clear `I2CR_TXAK` for SMBus block reads, causing the block length byte to be incorrectly NACKed.
> - [High] The interrupt-driven SMBus block read path (`i2c_imx_isr_read_block_data_len`) fails to properly terminate the transaction when receiving an invalid length (0 or > I2C_SMBUS_BLOCK_MAX), leaving the I2C bus stuck.

Both topics were already raised on v1 and v2 and answered. No change with v3,
so no need to reopend those threads.

> [Severity: High]
> This isn't a bug introduced by this patch, but does the interrupt-driven
> SMBus block read path in i2c_imx_isr_read_block_data_len() fail to properly
> terminate the transaction when receiving an invalid length?
 [...}
> I see the commit message acknowledges this flaw exists in the interrupt
> path but defers fixing it to a separate patch. Since that patch is not
> included in this series, the hang remains active in the codebase.

See 2/2 of this serie.

Same for v1: https://lore.kernel.org/all/ahRoKMLtrirbowbj@L30177.local/
and v2: https://lore.kernel.org/all/ahVZPLHymdsZtgg5@L30177.local/

> [Severity: High]
> This is a pre-existing issue, but does i2c_imx_prepare_read() fail to clear
> I2CR_TXAK for SMBus block reads?
> 
> In i2c_imx_prepare_read(), there is no check for I2C_M_RECV_LEN:
> 
> 	if (msgs->len - 1)
> 		temp &= ~I2CR_TXAK;
 [...}
> A compliant SMBus slave will immediately abort the transaction upon receiving
> a nack, causing all subsequent data bytes to read as 0xFF. Should this check
> include the I2C_M_RECV_LEN flag to properly clear TXAK?

Already explained with v1:
  https://lore.kernel.org/all/ahRmjr9cxYmkYvm5@L30177.local/

Best regards,
  Vincent