In I2C_FUNC_SMBUS_BLOCK_DATA case, the I2C Designware driver does not handle correctly when it receives the length of SMBus block data response from SMBus slave device, which is outside the range 1-32 bytes. Consequently, the I2C Designware bus is stuck and cannot recover. Because if IC_EMPTYFIFO_HOLD_MASTER_EN is set, which cannot be detected from the registers, the controller can be disabled if the STOP bit is set. But it is only set after receiving block data response length.
Hence, to prevent the bus from stuck condition, after receiving the invalid block data response length, the driver will read another byte with STOP bit set.
Cc: stable@vger.kernel.org Signed-off-by: Tam Nguyen tamnguyenchi@os.amperecomputing.com --- drivers/i2c/busses/i2c-designware-master.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-designware-master.c b/drivers/i2c/busses/i2c-designware-master.c index 55ea91a63382..94dadd785ed0 100644 --- a/drivers/i2c/busses/i2c-designware-master.c +++ b/drivers/i2c/busses/i2c-designware-master.c @@ -527,8 +527,19 @@ i2c_dw_read(struct dw_i2c_dev *dev)
regmap_read(dev->map, DW_IC_DATA_CMD, &tmp); /* Ensure length byte is a valid value */ - if (flags & I2C_M_RECV_LEN && - (tmp & DW_IC_DATA_CMD_DAT) <= I2C_SMBUS_BLOCK_MAX && tmp > 0) { + if (flags & I2C_M_RECV_LEN) { + /* + * if IC_EMPTYFIFO_HOLD_MASTER_EN is set, which cannot be + * detected from the registers, the controller can be + * disabled if the STOP bit is set. But it is only set + * after receiving block data response length in + * I2C_FUNC_SMBUS_BLOCK_DATA case. That needs to read + * another byte with STOP bit set when the block data + * response length is invalid to complete the transaction. + */ + if ((tmp & DW_IC_DATA_CMD_DAT) > I2C_SMBUS_BLOCK_MAX || tmp == 0) + tmp = 1; + len = i2c_dw_recv_len(dev, tmp); } *buf++ = tmp;
Hi
On 5/23/23 11:21, Tam Nguyen wrote:
In I2C_FUNC_SMBUS_BLOCK_DATA case, the I2C Designware driver does not handle correctly when it receives the length of SMBus block data response from SMBus slave device, which is outside the range 1-32 bytes. Consequently, the I2C Designware bus is stuck and cannot recover. Because if IC_EMPTYFIFO_HOLD_MASTER_EN is set, which cannot be detected from the registers, the controller can be disabled if the STOP bit is set. But it is only set after receiving block data response length.
Hence, to prevent the bus from stuck condition, after receiving the invalid block data response length, the driver will read another byte with STOP bit set.
Cc: stable@vger.kernel.org Signed-off-by: Tam Nguyen tamnguyenchi@os.amperecomputing.com
drivers/i2c/busses/i2c-designware-master.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-designware-master.c b/drivers/i2c/busses/i2c-designware-master.c index 55ea91a63382..94dadd785ed0 100644 --- a/drivers/i2c/busses/i2c-designware-master.c +++ b/drivers/i2c/busses/i2c-designware-master.c @@ -527,8 +527,19 @@ i2c_dw_read(struct dw_i2c_dev *dev) regmap_read(dev->map, DW_IC_DATA_CMD, &tmp); /* Ensure length byte is a valid value */
if (flags & I2C_M_RECV_LEN &&
(tmp & DW_IC_DATA_CMD_DAT) <= I2C_SMBUS_BLOCK_MAX && tmp > 0) {
if (flags & I2C_M_RECV_LEN) {
/*
* if IC_EMPTYFIFO_HOLD_MASTER_EN is set, which cannot be
* detected from the registers, the controller can be
* disabled if the STOP bit is set. But it is only set
* after receiving block data response length in
* I2C_FUNC_SMBUS_BLOCK_DATA case. That needs to read
* another byte with STOP bit set when the block data
* response length is invalid to complete the transaction.
*/
if ((tmp & DW_IC_DATA_CMD_DAT) > I2C_SMBUS_BLOCK_MAX || tmp == 0)
tmp = 1;
len = i2c_dw_recv_len(dev, tmp); } *buf++ = tmp;
Looks otherwise good to me but I'm wondering the "tmp == 0" test can it have the bit 11 set (on a HW where it's supported) and should it be covered with DW_IC_DATA_CMD_DAT mask too? Please see commit f53f15ba5a85 ("i2c: designware: Get right data length").
Hi Jarkko
On 5/24/2023 19:33, Jarkko Nikula wrote:
Hi
On 5/23/23 11:21, Tam Nguyen wrote:
In I2C_FUNC_SMBUS_BLOCK_DATA case, the I2C Designware driver does not handle correctly when it receives the length of SMBus block data response from SMBus slave device, which is outside the range 1-32 bytes. Consequently, the I2C Designware bus is stuck and cannot recover. Because if IC_EMPTYFIFO_HOLD_MASTER_EN is set, which cannot be detected from the registers, the controller can be disabled if the STOP bit is set. But it is only set after receiving block data response length.
Hence, to prevent the bus from stuck condition, after receiving the invalid block data response length, the driver will read another byte with STOP bit set.
Cc: stable@vger.kernel.org Signed-off-by: Tam Nguyen tamnguyenchi@os.amperecomputing.com
drivers/i2c/busses/i2c-designware-master.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-designware-master.c b/drivers/i2c/busses/i2c-designware-master.c index 55ea91a63382..94dadd785ed0 100644 --- a/drivers/i2c/busses/i2c-designware-master.c +++ b/drivers/i2c/busses/i2c-designware-master.c @@ -527,8 +527,19 @@ i2c_dw_read(struct dw_i2c_dev *dev) regmap_read(dev->map, DW_IC_DATA_CMD, &tmp); /* Ensure length byte is a valid value */ - if (flags & I2C_M_RECV_LEN && - (tmp & DW_IC_DATA_CMD_DAT) <= I2C_SMBUS_BLOCK_MAX && tmp > 0) { + if (flags & I2C_M_RECV_LEN) { + /* + * if IC_EMPTYFIFO_HOLD_MASTER_EN is set, which cannot be + * detected from the registers, the controller can be + * disabled if the STOP bit is set. But it is only set + * after receiving block data response length in + * I2C_FUNC_SMBUS_BLOCK_DATA case. That needs to read + * another byte with STOP bit set when the block data + * response length is invalid to complete the transaction. + */ + if ((tmp & DW_IC_DATA_CMD_DAT) > I2C_SMBUS_BLOCK_MAX || tmp == 0) + tmp = 1;
len = i2c_dw_recv_len(dev, tmp); } *buf++ = tmp;
Looks otherwise good to me but I'm wondering the "tmp == 0" test can it have the bit 11 set (on a HW where it's supported) and should it be covered with DW_IC_DATA_CMD_DAT mask too? Please see commit f53f15ba5a85 ("i2c: designware: Get right data length").
You're right. We should use the DW_IC_DATA_CMD_DAT mask to get the data part if HW supports reading bit 11 from IC_DATA_CMD. I will update it in v2.
Best regards, Tam Nguyen
Hi Jarkko,
Before pushing the v2 patch, I have one more question to ask.
The commit f53f15ba5a85 ("i2c: designware: Get right data length"), you mentioned, does not handle bit 11 set (on a HW where it's supported) correctly. "tmp" was not marked with DW_IC_DATA_CMD_DAT when passing to i2c_dw_recv_len function.
So I plan to update it in the v2 patch by adding this regmap_read(dev->map, DW_IC_DATA_CMD, &tmp); tmp &= DW_IC_DATA_CMD_DAT;
My question is: does it need a separate patch for this change?
Best regards, Tam Nguyen
On 5/25/2023 16:30, Tam Chi Nguyen wrote:
Hi Jarkko
On 5/24/2023 19:33, Jarkko Nikula wrote:
Hi
On 5/23/23 11:21, Tam Nguyen wrote:
In I2C_FUNC_SMBUS_BLOCK_DATA case, the I2C Designware driver does not handle correctly when it receives the length of SMBus block data response from SMBus slave device, which is outside the range 1-32 bytes. Consequently, the I2C Designware bus is stuck and cannot recover. Because if IC_EMPTYFIFO_HOLD_MASTER_EN is set, which cannot be detected from the registers, the controller can be disabled if the STOP bit is set. But it is only set after receiving block data response length.
Hence, to prevent the bus from stuck condition, after receiving the invalid block data response length, the driver will read another byte with STOP bit set.
Cc: stable@vger.kernel.org Signed-off-by: Tam Nguyen tamnguyenchi@os.amperecomputing.com
drivers/i2c/busses/i2c-designware-master.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-designware-master.c b/drivers/i2c/busses/i2c-designware-master.c index 55ea91a63382..94dadd785ed0 100644 --- a/drivers/i2c/busses/i2c-designware-master.c +++ b/drivers/i2c/busses/i2c-designware-master.c @@ -527,8 +527,19 @@ i2c_dw_read(struct dw_i2c_dev *dev) regmap_read(dev->map, DW_IC_DATA_CMD, &tmp); /* Ensure length byte is a valid value */ - if (flags & I2C_M_RECV_LEN && - (tmp & DW_IC_DATA_CMD_DAT) <= I2C_SMBUS_BLOCK_MAX && tmp > 0) { + if (flags & I2C_M_RECV_LEN) { + /* + * if IC_EMPTYFIFO_HOLD_MASTER_EN is set, which cannot be + * detected from the registers, the controller can be + * disabled if the STOP bit is set. But it is only set + * after receiving block data response length in + * I2C_FUNC_SMBUS_BLOCK_DATA case. That needs to read + * another byte with STOP bit set when the block data + * response length is invalid to complete the transaction. + */ + if ((tmp & DW_IC_DATA_CMD_DAT) > I2C_SMBUS_BLOCK_MAX || tmp == 0) + tmp = 1;
len = i2c_dw_recv_len(dev, tmp); } *buf++ = tmp;
Looks otherwise good to me but I'm wondering the "tmp == 0" test can it have the bit 11 set (on a HW where it's supported) and should it be covered with DW_IC_DATA_CMD_DAT mask too? Please see commit f53f15ba5a85 ("i2c: designware: Get right data length").
You're right. We should use the DW_IC_DATA_CMD_DAT mask to get the data part if HW supports reading bit 11 from IC_DATA_CMD. I will update it in v2.
Best regards, Tam Nguyen
Hi
On 6/2/23 07:30, Tam Chi Nguyen wrote:
Hi Jarkko,
Before pushing the v2 patch, I have one more question to ask.
The commit f53f15ba5a85 ("i2c: designware: Get right data length"), you mentioned, does not handle bit 11 set (on a HW where it's supported) correctly. "tmp" was not marked with DW_IC_DATA_CMD_DAT when passing to i2c_dw_recv_len function.
So I plan to update it in the v2 patch by adding this regmap_read(dev->map, DW_IC_DATA_CMD, &tmp); tmp &= DW_IC_DATA_CMD_DAT;
My question is: does it need a separate patch for this change?
I think for now bit 11 gets masked since tmp variable is assigned to u8 variables when calling i2c_dw_recv_len() and writing to *buf pointer but your proposal indeed makes code more robust both your patch point of view or any other future change. So separate patch makes sense in my opinion.
linux-stable-mirror@lists.linaro.org