linux-kernel - [PATCH 2/2] i2c: designware: abort the transfer if receiving byte count of 0

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 for Android: free password hash cracker in your pocket

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

Message-Id: <20230811124624.12792-2-yann@sionneau.net>
Date:   Fri, 11 Aug 2023 14:46:24 +0200
From:   Yann Sionneau <yann@...nneau.net>
To:     Jarkko Nikula <jarkko.nikula@...ux.intel.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>
Cc:     linux-i2c@...r.kernel.org, linux-kernel@...r.kernel.org,
        Yann Sionneau <ysionneau@...ray.eu>,
        Jonathan Borne <jborne@...ray.eu>
Subject: [PATCH 2/2] i2c: designware: abort the transfer if receiving byte count of 0

From: Yann Sionneau <ysionneau@...ray.eu>

Context:
It's not clear whether Linux SMBus stack supports receiving 0
as byte count for SMBus read data block.

Linux supports SMBus v2.0 spec, which says "The byte count may not be 0."
Which does not seem very clear to me, as a non-native speaker.
(Note that v3.0 of the spec says "The byte count may be 0.")

Some drivers explicitly return -EPROTO in case of byte count 0.

The issue:
Regardless of whether Linux supports byte count of 0, if this happens
the i2c-designware driver goes into an unrecoverable state holding
SCL low if the IP is synthesized with the IC_EMPTYFIFO_HOLD_MASTER_EN
parameter.

The fix proposed by this patch:
Abort the transfer by sending a STOP condition on the bus.

Another approach would be to ignore the issue and let the driver
timeout and disable the IP. The IP disabling is fixed by the previous
patch in this patch series.
The current patch just makes the recovery faster since Abort is sent
directly without waiting for the timeout to happen. With this patch,
disabling the IP is not necessary anymore.

Co-developed-by: Jonathan Borne <jborne@...ray.eu>
Signed-off-by: Jonathan Borne <jborne@...ray.eu>
Tested-by: Yann Sionneau <ysionneau@...ray.eu>
Signed-off-by: Yann Sionneau <ysionneau@...ray.eu>
---
 drivers/i2c/busses/i2c-designware-master.c | 20 +++++++++++++++++---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/busses/i2c-designware-master.c b/drivers/i2c/busses/i2c-designware-master.c
index b55c19b2515a..fa5301566bb1 100644
--- a/drivers/i2c/busses/i2c-designware-master.c
+++ b/drivers/i2c/busses/i2c-designware-master.c
@@ -499,6 +499,15 @@ i2c_dw_recv_len(struct dw_i2c_dev *dev, u8 len)
 	return len;
 }

+static void
+i2c_dw_abort(struct dw_i2c_dev *dev)
+{
+	u32 enable;
+
+	regmap_read(dev->map, DW_IC_ENABLE, &enable);
+	regmap_write(dev->map, DW_IC_ENABLE, enable | DW_IC_ENABLE_ABORT);
+}
+
 static void
 i2c_dw_read(struct dw_i2c_dev *dev)
 {
@@ -526,11 +535,16 @@ i2c_dw_read(struct dw_i2c_dev *dev)
 			u32 flags = msgs[dev->msg_read_idx].flags;

 			regmap_read(dev->map, DW_IC_DATA_CMD, &tmp);
+			tmp &= DW_IC_DATA_CMD_DAT;
+
 			/* Ensure length byte is a valid value */
-			if (flags & I2C_M_RECV_LEN &&
-			    (tmp & DW_IC_DATA_CMD_DAT) <= I2C_SMBUS_BLOCK_MAX && (tmp & DW_IC_DATA_CMD_DAT) > 0) {
-				len = i2c_dw_recv_len(dev, tmp);
+			if (flags & I2C_M_RECV_LEN) {
+				if ((tmp <= I2C_SMBUS_BLOCK_MAX) && (tmp != 0))
+					len = i2c_dw_recv_len(dev, tmp);
+				else
+					i2c_dw_abort(dev);
 			}
+
 			*buf++ = tmp;
 			dev->rx_outstanding--;
 		}
-- 
2.17.1