From nobody Sat Sep 13 20:26:27 2025 Received: from dvalin.narfation.org (dvalin.narfation.org [213.160.73.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CC8CB28B419; Mon, 4 Aug 2025 19:18:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.160.73.56 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754335084; cv=none; b=dT//8S9bwxxL4arV4/P2A5XcSHDSiu2M7Ptgtttdt8EgBjeCc0CJsTOsPHPicDmOGZeGMvOcbfDr4zqcP1eM1/BHipDVo2z2DNY62VbFhPsr5cZU+l72hhMDT6y1wM8618iap57R1qCas2ljcYBEc8VjlAE3MWwdZtTd3nXw+28= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754335084; c=relaxed/simple; bh=Vtq5UPmLTFY5VZzrysY3oADq9EGeBvOKx8b4u8R8igY=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=XN6P+c3Kukmaq6ffWVh0BdnmWIdmGbw173Tl5bJ3YYSxaLFOMhTh+0c7PhRkwaha1469PJ/Eoi16UfqTc1MzwchtUac+eMnJb7FsCy7ZR2whPTBzSEND9NCl0P8LH7Es73jItbc5pGYYhq9VA1f28WVJTP8WzHLO3YsAJP8z0cA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=narfation.org; spf=pass smtp.mailfrom=narfation.org; dkim=pass (1024-bit key) header.d=narfation.org header.i=@narfation.org header.b=yFQbBo5t; arc=none smtp.client-ip=213.160.73.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=narfation.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=narfation.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=narfation.org header.i=@narfation.org header.b="yFQbBo5t" Received: from sven-desktop.home.narfation.org (unknown [IPv6:2a00:1ca0:1d86:99fc::8c24]) by dvalin.narfation.org (Postfix) with UTF8SMTPSA id 950802061C; Mon, 4 Aug 2025 19:17:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=narfation.org; s=20121; t=1754335074; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=d/nKJw/7X53cuiGpQWRkSvrWgGuyU70edIJRDqZBDww=; b=yFQbBo5t5RI41HugyH5HPvfICR+3xMGvqSxQF+slG6FMx/r2n8QiEtpy93psmJ5cVLT7Be O3SwoXxAXB47jYcEcXkAkBBbn3t7hlF4cC+Hp/7VIwoaAFSIHWz8FfJr9voSVNAO5BBpD2 u1Rw4b/0cvL+BYru1ifK/PTZtFCrtY4= From: Sven Eckelmann Date: Mon, 04 Aug 2025 21:17:00 +0200 Subject: [PATCH v3 1/5] i2c: rtl9300: Fix out-of-bounds bug in rtl9300_i2c_smbus_xfer Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20250804-i2c-rtl9300-multi-byte-v3-1-e20607e1b28c@narfation.org> References: <20250804-i2c-rtl9300-multi-byte-v3-0-e20607e1b28c@narfation.org> In-Reply-To: <20250804-i2c-rtl9300-multi-byte-v3-0-e20607e1b28c@narfation.org> To: Chris Packham , Andi Shyti Cc: linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org, Jonas Jelonek , Harshal Gohel , Simon Wunderlich , Sven Eckelmann , Alex Guo , stable@vger.kernel.org X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=1485; i=sven@narfation.org; h=from:subject:message-id; bh=qwD7fnxgQyI3+hiAHukxxaPljiRg7DlNTwOPEpk3kj8=; b=owGbwMvMwCXmy1+ufVnk62nG02pJDBkT2cO27jWte3q+YZ3U7uoPz6QWBW+8/eJfioPLjAOWP raMVTcVO0pZGMS4GGTFFFn2XMk/v5n9rfznaR+PwsxhZQIZwsDFKQATOfCSkWHCuUSe3VmP/cKk GtsmpFxlVpZdeCOt/US2UImsym2O+54M/4uFf6ew1C3hTXzoMM+k1nbmlkdOUo6/OR7EvZiV3tS RxwIA X-Developer-Key: i=sven@narfation.org; a=openpgp; fpr=522D7163831C73A635D12FE5EC371482956781AF From: Alex Guo The data->block[0] variable comes from user. Without proper check, the variable may be very large to cause an out-of-bounds bug. Fix this bug by checking the value of data->block[0] first. 1. commit 39244cc75482 ("i2c: ismt: Fix an out-of-bounds bug in ismt_access()") 2. commit 92fbb6d1296f ("i2c: xgene-slimpro: Fix out-of-bounds bug in xgene_slimpro_i2c_xfer()") Cc: Fixes: c366be720235 ("i2c: Add driver for the RTL9300 I2C controller") Signed-off-by: Alex Guo Reviewed-by: Chris Packham Tested-by: Chris Packham Signed-off-by: Sven Eckelmann --- drivers/i2c/busses/i2c-rtl9300.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/i2c/busses/i2c-rtl9300.c b/drivers/i2c/busses/i2c-rtl9= 300.c index e064e8a4a1f0824abc82fa677866b85f99fbe4a7..568495720810b373c4fa3b31d3f= 4cdec7c64b5f9 100644 --- a/drivers/i2c/busses/i2c-rtl9300.c +++ b/drivers/i2c/busses/i2c-rtl9300.c @@ -281,6 +281,10 @@ static int rtl9300_i2c_smbus_xfer(struct i2c_adapter *= adap, u16 addr, unsigned s ret =3D rtl9300_i2c_reg_addr_set(i2c, command, 1); if (ret) goto out_unlock; + if (data->block[0] < 1 || data->block[0] > I2C_SMBUS_BLOCK_MAX) { + ret =3D -EINVAL; + goto out_unlock; + } ret =3D rtl9300_i2c_config_xfer(i2c, chan, addr, data->block[0]); if (ret) goto out_unlock; --=20 2.47.2 From nobody Sat Sep 13 20:26:27 2025 Received: from dvalin.narfation.org (dvalin.narfation.org [213.160.73.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 529EB22FAFD; Mon, 4 Aug 2025 19:17:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.160.73.56 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754335082; cv=none; b=qDAinDHsSUsZFppjVr1sccEiRVEVu7DNtamOGiwObmFuiqeZACdNnqCllNv9nZstgGh18YPP4UTvTfKDY1lpjUbG2GeYnmzlRsbY4beiv8MDBHhu1fmwo0Rv0QnShl76snCPq3z/6I+b3JYvsmr834mmgFsfqaBYissR9XFvZO0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754335082; c=relaxed/simple; bh=N/S7BI7MFx+Ev1eeKr/+tw8r5HeDR9bkWd4h5J5xilc=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=kyvCdZGdmVLhEDq3/xCU87dFX9BHvCNATuRnsjFinHTSOBejef6slG7QvOKReVcCbURFbdyAoLFOuKs6xtxZn7NbOqlhtJvXfqMqoo8JqJCT5u8SFeeAnvQ1y5HuvdaMv9Y22xTc0dwfpxTnITiptDqrxjJdvuoULtJww24Pnq8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=narfation.org; spf=pass smtp.mailfrom=narfation.org; dkim=pass (1024-bit key) header.d=narfation.org header.i=@narfation.org header.b=aDJ5v2xJ; arc=none smtp.client-ip=213.160.73.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=narfation.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=narfation.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=narfation.org header.i=@narfation.org header.b="aDJ5v2xJ" Received: from sven-desktop.home.narfation.org (unknown [IPv6:2a00:1ca0:1d86:99fc::8c24]) by dvalin.narfation.org (Postfix) with UTF8SMTPSA id 260A920D95; Mon, 4 Aug 2025 19:17:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=narfation.org; s=20121; t=1754335078; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=aYv+aJLVqc/Q7SRWlS3EVfQqT8kNYcHz9Tdrzi3KQYI=; b=aDJ5v2xJ/9Cg4tyqApERIbghvB+bQQkgeBLfmm6wKL7GqIGJxsqE9C3s5cufC+RrO7tCXg p65vVLu+Xg0axSO2DuvFkp69Bblik3GOnKc91HDKlCuNncIFA/Pl2Hfw0jpds8LGTy49ci L5idZkYIa3ySn5it/s6k6Yne8U7uyLk= From: Sven Eckelmann Date: Mon, 04 Aug 2025 21:17:01 +0200 Subject: [PATCH v3 2/5] i2c: rtl9300: Fix multi-byte I2C write Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20250804-i2c-rtl9300-multi-byte-v3-2-e20607e1b28c@narfation.org> References: <20250804-i2c-rtl9300-multi-byte-v3-0-e20607e1b28c@narfation.org> In-Reply-To: <20250804-i2c-rtl9300-multi-byte-v3-0-e20607e1b28c@narfation.org> To: Chris Packham , Andi Shyti Cc: linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org, Jonas Jelonek , Harshal Gohel , Simon Wunderlich , Sven Eckelmann , stable@vger.kernel.org X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=2729; i=sven@narfation.org; h=from:subject:message-id; bh=PJ7UiIgP7qua5GKVS7qfgulOeNPjtXHCwjTgGFNPZMc=; b=owGbwMvMwCXmy1+ufVnk62nG02pJDBkT2cNnWhXk6c//ofrBODe2fGbI8iT9c6cbT372+Oep3 iOblTKho5SFQYyLQVZMkWXPlfzzm9nfyn+e9vEozBxWJpAhDFycAjARlU5GhrtiAvo1t/9IHJt0 /Mtj9Vc9jr4aolzO34O2rdk6dW9N7mFGhl6DiPNsCSEzN+T/u2NmvnGb35ZnNYdXPb8S0ljJkHJ gBQ8A X-Developer-Key: i=sven@narfation.org; a=openpgp; fpr=522D7163831C73A635D12FE5EC371482956781AF From: Harshal Gohel The RTL93xx I2C controller has 4 32 bit registers to store the bytes for the upcoming I2C transmission. The first byte is stored in the least-significant byte of the first register. And the last byte in the most significant byte of the last register. A map of the transferred bytes to their order in the registers is: reg 0: 0x04_03_02_01 reg 1: 0x08_07_06_05 reg 2: 0x0c_0b_0a_09 reg 3: 0x10_0f_0e_0d The i2c_read() function basically demonstrates how the hardware would pick up bytes from this register set. But the i2c_write() function was just pushing bytes one after another to the least significant byte of a register AFTER shifting the last one to the next more significant byte position. If you would then have tried to send a buffer with numbers 1-11 using i2c_write(), you would have ended up with following register content: reg 0: 0x01_02_03_04 reg 1: 0x05_06_07_08 reg 2: 0x00_09_0a_0b reg 3: 0x00_00_00_00 On the wire, you would then have seen: Sr Addr Rd/Wr [A] 04 A 03 A 02 A 01 A 08 A 07 A 06 A 05 A 0b A 0a A 09 A/= NA P But the correct data transmission was expected to be Sr Addr Rd/Wr [A] 01 A 02 A 03 A 04 A 05 A 06 A 07 A 08 A 09 A 0a A 0b A/= NA P Because of this multi-byte ordering problem, only single byte i2c_write() operations were executed correctly (on the wire). By shifting the byte directly to the correct end position in the register, it is possible to avoid this incorrect byte ordering and fix multi-byte transmissions. Cc: Fixes: c366be720235 ("i2c: Add driver for the RTL9300 I2C controller") Signed-off-by: Harshal Gohel Co-developed-by: Sven Eckelmann Signed-off-by: Sven Eckelmann Reviewed-by: Chris Packham Tested-by: Chris Packham --- drivers/i2c/busses/i2c-rtl9300.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/i2c/busses/i2c-rtl9300.c b/drivers/i2c/busses/i2c-rtl9= 300.c index 568495720810b373c4fa3b31d3f4cdec7c64b5f9..616d13e6d7088d2b5dc94dca134= 86caf10fc43f3 100644 --- a/drivers/i2c/busses/i2c-rtl9300.c +++ b/drivers/i2c/busses/i2c-rtl9300.c @@ -143,10 +143,13 @@ static int rtl9300_i2c_write(struct rtl9300_i2c *i2c,= u8 *buf, int len) return -EIO; =20 for (i =3D 0; i < len; i++) { + unsigned int shift =3D (i % 4) * 8; + unsigned int reg =3D i / 4; + if (i % 4 =3D=3D 0) - vals[i/4] =3D 0; - vals[i/4] <<=3D 8; - vals[i/4] |=3D buf[i]; + vals[reg] =3D 0; + + vals[reg] |=3D buf[i] << shift; } =20 return regmap_bulk_write(i2c->regmap, i2c->reg_base + RTL9300_I2C_MST_DAT= A_WORD0, --=20 2.47.2 From nobody Sat Sep 13 20:26:27 2025 Received: from dvalin.narfation.org (dvalin.narfation.org [213.160.73.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 46D7B28B4FA; Mon, 4 Aug 2025 19:18:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.160.73.56 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754335084; cv=none; b=HBqLWH26rRCey6RMtbsU8qCvClpXCewDLyNeAPwiH6UeNwVEJsYPc3+rkrwpWpf/kiVOtlzygCR/ySGFF+aaV6AuKmL09buoILq63TJJ90Suo/LfoXV3Wad/MUg7qRu6ASzmlAmZuEk7QqS4IrKF+pQeCSYS+8rSCQFaQMXgVSc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754335084; c=relaxed/simple; bh=3hoEoAnN6KRhnO1uwCszA4VyBjhI9zYhjoqErVGcx7k=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=ngbfQyGI3SP86bWUyNlh64pUZs1UEdQ0zKEEev/45upwaFsRVPIrEeikFHnVrt48J71GpnY8jVk15i1yIuuSvA2gvyLTl5KeDg0XUypj43BjyCBOJpWm2p32Rq8caFe8pyhxBi0IEteYOJOCefuGMLBc4eIgrJtJeuwZ4sl+us0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=narfation.org; spf=pass smtp.mailfrom=narfation.org; dkim=pass (1024-bit key) header.d=narfation.org header.i=@narfation.org header.b=BgvXvou8; arc=none smtp.client-ip=213.160.73.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=narfation.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=narfation.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=narfation.org header.i=@narfation.org header.b="BgvXvou8" Received: from sven-desktop.home.narfation.org (unknown [IPv6:2a00:1ca0:1d86:99fc::8c24]) by dvalin.narfation.org (Postfix) with UTF8SMTPSA id 6093321025; Mon, 4 Aug 2025 19:18:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=narfation.org; s=20121; t=1754335081; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Wd02ogiR3yNdP4gSs9IelS+hTKAuH/xjjfYBusMhees=; b=BgvXvou87BwBj+i/OeteYOUb4L+hFeJ5DUlO6iCEb6jkFyJQpGo6zgAsLLGkGn3hawvXuB 4OTchq9Iby2PfixIfbcu+Eh6b/N4T0+U3pOgvHYK+JApzT5rYca30e9YTJwf+pGsmTf2ie pirIqFYtlNVNQ7miSo196QWyaCpihFo= From: Sven Eckelmann Date: Mon, 04 Aug 2025 21:17:02 +0200 Subject: [PATCH v3 3/5] i2c: rtl9300: Increase timeout for transfer polling Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20250804-i2c-rtl9300-multi-byte-v3-3-e20607e1b28c@narfation.org> References: <20250804-i2c-rtl9300-multi-byte-v3-0-e20607e1b28c@narfation.org> In-Reply-To: <20250804-i2c-rtl9300-multi-byte-v3-0-e20607e1b28c@narfation.org> To: Chris Packham , Andi Shyti Cc: linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org, Jonas Jelonek , Harshal Gohel , Simon Wunderlich , Sven Eckelmann , stable@vger.kernel.org X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=1830; i=sven@narfation.org; h=from:subject:message-id; bh=3hoEoAnN6KRhnO1uwCszA4VyBjhI9zYhjoqErVGcx7k=; b=owGbwMvMwCXmy1+ufVnk62nG02pJDBkT2cNPF+4uXnj9qOOcBuMApfk/xS3TuxbOm7+WTeajl OUvO3/NjlIWBjEuBlkxRZY9V/LPb2Z/K/952sejMHNYmUCGMHBxCsBEWKwY/leGzrr49BG//L9i ddOv+p4Jpp0XjRt4SuM3CDFx/K9938DIcE+t/eTWpRuTzv/Onh8+fY7crt0mE86tmCy3L+XLio2 vXBkA X-Developer-Key: i=sven@narfation.org; a=openpgp; fpr=522D7163831C73A635D12FE5EC371482956781AF The timeout for transfers was only set to 2ms. Because of this relatively low limit, 12-byte read operations to the frontend MCU of a RTL8239 POE PSE chip cluster was consistently resulting in a timeout. The original OpenWrt downstream driver [1] was not using any timeout limit at all. This is also possible by setting the timeout_us parameter of regmap_read_poll_timeout() to 0. But since the driver currently is implements the ETIMEDOUT error, it is more sensible to increase the timeout in such a way that the communication with the (quite common) Realtek I2C-connected POE management solution is possible. [1] https://git.openwrt.org/?p=3Dopenwrt/openwrt.git;a=3Dblob;f=3Dtarget/li= nux/realtek/files-6.12/drivers/i2c/busses/i2c-rtl9300.c;h=3Dc4d973195ef39dc= 56d6207e665d279745525fcac#l202 Cc: Fixes: c366be720235 ("i2c: Add driver for the RTL9300 I2C controller") Signed-off-by: Sven Eckelmann Reviewed-by: Chris Packham Tested-by: Chris Packham --- drivers/i2c/busses/i2c-rtl9300.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-rtl9300.c b/drivers/i2c/busses/i2c-rtl9= 300.c index 616d13e6d7088d2b5dc94dca13486caf10fc43f3..b8e8f416c5658058819dc0c75af= 7aa5f18f3f7a9 100644 --- a/drivers/i2c/busses/i2c-rtl9300.c +++ b/drivers/i2c/busses/i2c-rtl9300.c @@ -178,7 +178,7 @@ static int rtl9300_i2c_execute_xfer(struct rtl9300_i2c = *i2c, char read_write, return ret; =20 ret =3D regmap_read_poll_timeout(i2c->regmap, i2c->reg_base + RTL9300_I2C= _MST_CTRL1, - val, !(val & RTL9300_I2C_MST_CTRL1_I2C_TRIG), 100, 2000); + val, !(val & RTL9300_I2C_MST_CTRL1_I2C_TRIG), 100, 100000); if (ret) return ret; =20 --=20 2.47.2 From nobody Sat Sep 13 20:26:27 2025 Received: from dvalin.narfation.org (dvalin.narfation.org [213.160.73.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1F79928FAA7; Mon, 4 Aug 2025 19:18:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.160.73.56 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754335087; cv=none; b=M2ni/M2sBcPCDS2pbu3iJYyDdON4b71eJKxcEgotj5Rjydfao7wDaC0sZrKPyce3OZOW+W3L46gletsQPH7+KA2SzLR8/rncETo49O7Qpr3p8lMH2UrXUYx7sIpVEeaAnPjZ85yPaAgZCE/zEDbQVVTezwh0UsedaK2WHzLczgk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754335087; c=relaxed/simple; bh=rfjnSZM5LDZLCKkk3DIvlsIirLOIa+aP9kL7m+7VmW8=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=THWx6vPQGEJrZsppX3E+mIBJqCepZf6IVacOdpAobcdKW8u2IQQHZgwUYR77//loHnLPnMJlz7WsoIXp/tFcpowKsSuVgckvbA5cpk7fcCO/pNS4odolvxvDDYqxmDH94BcDhcGw+wzZQLBONAGIJienjz6AdZD1v9WFeC0CPUw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=narfation.org; spf=pass smtp.mailfrom=narfation.org; dkim=pass (1024-bit key) header.d=narfation.org header.i=@narfation.org header.b=IMyRnzZJ; arc=none smtp.client-ip=213.160.73.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=narfation.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=narfation.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=narfation.org header.i=@narfation.org header.b="IMyRnzZJ" Received: from sven-desktop.home.narfation.org (unknown [IPv6:2a00:1ca0:1d86:99fc::8c24]) by dvalin.narfation.org (Postfix) with UTF8SMTPSA id 621FD2034F; Mon, 4 Aug 2025 19:18:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=narfation.org; s=20121; t=1754335084; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=TDIUbfgsBCB+yTlIqmuoRGtDd86IV1sv8zA0Nww0V2Y=; b=IMyRnzZJLN2PYP428sp2sa1noNXOxBbpTYplXtfJqzOdlasnYT4CM4a1Q6JpiHa9+KXm4E rP+jbLRmdSts8BQ2RO/UpLTcpn5P7NnSkT+uaYUVrfPzMU42mB6c8AUcg0WdhZa5k+3OYg knJ9zXe0wk3ey4oE+MDaQmlwwU5mEDg= From: Sven Eckelmann Date: Mon, 04 Aug 2025 21:17:03 +0200 Subject: [PATCH v3 4/5] i2c: rtl9300: Add missing count byte for SMBus Block Ops Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20250804-i2c-rtl9300-multi-byte-v3-4-e20607e1b28c@narfation.org> References: <20250804-i2c-rtl9300-multi-byte-v3-0-e20607e1b28c@narfation.org> In-Reply-To: <20250804-i2c-rtl9300-multi-byte-v3-0-e20607e1b28c@narfation.org> To: Chris Packham , Andi Shyti Cc: linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org, Jonas Jelonek , Harshal Gohel , Simon Wunderlich , Sven Eckelmann , stable@vger.kernel.org X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=2057; i=sven@narfation.org; h=from:subject:message-id; bh=rfjnSZM5LDZLCKkk3DIvlsIirLOIa+aP9kL7m+7VmW8=; b=owGbwMvMwCXmy1+ufVnk62nG02pJDBkT2cPl21UTLxwKuSDdp67MlKlz60eeg6Tumw3rJJieK 1l0STp0lLIwiHExyIopsuy5kn9+M/tb+c/TPh6FmcPKBDKEgYtTACaSfImRYUd5oc1bC6ZLqc+s LQ2CknJCA6+xb3/eX1xferKoQseIgZHh35lt96/weNnM+mKonWZ4Yg7zqXOnDTaxB31/85P/0/1 ODgA= X-Developer-Key: i=sven@narfation.org; a=openpgp; fpr=522D7163831C73A635D12FE5EC371482956781AF The expected on-wire format of an SMBus Block Write is S Addr Wr [A] Comm [A] Count [A] Data [A] Data [A] ... [A] Data [A] P Everything starting from the Count byte is provided by the I2C subsystem in the array data->block. But the driver was skipping the Count byte (data->block[0]) when sending it to the RTL93xx I2C controller. Only the actual data could be seen on the wire: S Addr Wr [A] Comm [A] Data [A] Data [A] ... [A] Data [A] P This wire format is not SMBus Block Write compatible but matches the format of an I2C Block Write. Simply adding the count byte to the buffer for the I2C controller enough to fix the transmission. This also affects read because the I2C controller must receive the count byte + $count * data bytes. Cc: Fixes: c366be720235 ("i2c: Add driver for the RTL9300 I2C controller") Signed-off-by: Sven Eckelmann Reviewed-by: Chris Packham Tested-by: Chris Packham --- drivers/i2c/busses/i2c-rtl9300.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/i2c/busses/i2c-rtl9300.c b/drivers/i2c/busses/i2c-rtl9= 300.c index b8e8f416c5658058819dc0c75af7aa5f18f3f7a9..8310675668fdddc9626a5813bee= 050cc55a61c09 100644 --- a/drivers/i2c/busses/i2c-rtl9300.c +++ b/drivers/i2c/busses/i2c-rtl9300.c @@ -288,15 +288,15 @@ static int rtl9300_i2c_smbus_xfer(struct i2c_adapter = *adap, u16 addr, unsigned s ret =3D -EINVAL; goto out_unlock; } - ret =3D rtl9300_i2c_config_xfer(i2c, chan, addr, data->block[0]); + ret =3D rtl9300_i2c_config_xfer(i2c, chan, addr, data->block[0] + 1); if (ret) goto out_unlock; if (read_write =3D=3D I2C_SMBUS_WRITE) { - ret =3D rtl9300_i2c_write(i2c, &data->block[1], data->block[0]); + ret =3D rtl9300_i2c_write(i2c, &data->block[0], data->block[0] + 1); if (ret) goto out_unlock; } - len =3D data->block[0]; + len =3D data->block[0] + 1; break; =20 default: --=20 2.47.2 From nobody Sat Sep 13 20:26:27 2025 Received: from dvalin.narfation.org (dvalin.narfation.org [213.160.73.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EAFBA29117A; Mon, 4 Aug 2025 19:18:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.160.73.56 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754335091; cv=none; b=JJcPpLEc0r1Zl9M1XDh6IB6apKoX8fx+u4jqlE5Sr64mSneDqOOIWykwtihJn6Vk9LCOPU9eN2gtyC70MbW29YBNazfh0DGPrjYgaFOQp30tKiN3E5YFtbtITJQaY5pklNwcTUIsH21Ygmzh2iIYbW1sb5Dy7vdZKe3VXpue5NA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754335091; c=relaxed/simple; bh=1x+TVFg1EE/G/icLAxbMuHtD3kejMkgtnyrVojEfsxA=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=XUyno9VvznIisD3NLS+yn5gz6+ZIxrZKOl3pWvh0WRq6xS/A32P9kFeaLt4BGhv3ztKeqA8lkyMp9JItMaKAvMcbSkIpVreqlZxfdMoSKgVOevE4+OAM5AbtQiLD2QwIcBSgfYAMnNCwh8S4hX9+nEd/MKRtMlt6JcaTN7SMJ2E= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=narfation.org; spf=pass smtp.mailfrom=narfation.org; dkim=pass (1024-bit key) header.d=narfation.org header.i=@narfation.org header.b=MfevM9aj; arc=none smtp.client-ip=213.160.73.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=narfation.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=narfation.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=narfation.org header.i=@narfation.org header.b="MfevM9aj" Received: from sven-desktop.home.narfation.org (unknown [IPv6:2a00:1ca0:1d86:99fc::8c24]) by dvalin.narfation.org (Postfix) with UTF8SMTPSA id 402652034F; Mon, 4 Aug 2025 19:18:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=narfation.org; s=20121; t=1754335088; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ovzcnQ/xHGgA/gscprR6UDZ8vi5gGtYCjZ76laWNKFw=; b=MfevM9ajZMSDO6ynAxHauMF6zCgBqXRCS14SdahXbqnUV3eg5aXUuUnxPo/wqD+TzjCWKM 85gYUOvK8cEt8I9GdXzc6X1z9pcEUGnjdOnfLSNBx+2s56eSk7rW54IUk6quT+ldn+yb8m HmXuwYYZtlYg6c5eMTryuYq29FxRFek= From: Sven Eckelmann Date: Mon, 04 Aug 2025 21:17:04 +0200 Subject: [PATCH v3 5/5] i2c: rtl9300: Implement I2C block read and write Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20250804-i2c-rtl9300-multi-byte-v3-5-e20607e1b28c@narfation.org> References: <20250804-i2c-rtl9300-multi-byte-v3-0-e20607e1b28c@narfation.org> In-Reply-To: <20250804-i2c-rtl9300-multi-byte-v3-0-e20607e1b28c@narfation.org> To: Chris Packham , Andi Shyti Cc: linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org, Jonas Jelonek , Harshal Gohel , Simon Wunderlich , Sven Eckelmann X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=4066; i=sven@narfation.org; h=from:subject:message-id; bh=qPUvBuXwx+gCbsn+FKrdc55Ikb834EBPsr9ria12TBc=; b=owGbwMvMwCXmy1+ufVnk62nG02pJDBkT2cOrCquuOax/8eXDv9csXZ88Z82/KsRTH/hi3Unnh R0cWlZlHaUsDGJcDLJiiix7ruSf38z+Vv7ztI9HYeawMoEMYeDiFICJfHBn+GcQ3pFmsOhi0rfM hZZHjVLMtS/H9j27rsK0dc+80Dm8tZkM/2s8XZwPzdeQqIvQWvp7w3Gte/oHd8zkO5vl/SzNhS3 WgAsA X-Developer-Key: i=sven@narfation.org; a=openpgp; fpr=522D7163831C73A635D12FE5EC371482956781AF From: Harshal Gohel It was noticed that the original implementation of SMBus Block Write in the driver was actually an I2C Block Write. Both differ only in the Count byte before the actual data: S Addr Wr [A] Comm [A] Count [A] Data [A] Data [A] ... [A] Data [A] P The I2C Block Write is just skipping this Count byte and starts directly with the data: S Addr Wr [A] Comm [A] Data [A] Data [A] ... [A] Data [A] P The I2C controller of RTL93xx doesn't handle this Count byte special and it is simply another one of (16 possible) data bytes. Adding support for the I2C Block Write therefore only requires to skip the count byte (0) in data->block. It is similar for reads. The SMBUS Block read is having a Count byte before the data: S Addr Wr [A] Comm [A] Sr Addr Rd [A] [Count] A [Data] A [Data] A ... A [Data] NA P And the I2C Block Read is directly starting with the actual data: S Addr Wr [A] Comm [A] Sr Addr Rd [A] [Data] A [Data] A ... A [Data] NA P The I2C controller is also not handling this byte in a special way. It simply provides every byte after the Rd marker + Ack as part of the 16 byte receive buffer (registers). The content of this buffer just has to be copied to the right position in the receive data->block. Signed-off-by: Harshal Gohel Co-developed-by: Sven Eckelmann Signed-off-by: Sven Eckelmann Reviewed-by: Chris Packham Tested-by: Chris Packham --- drivers/i2c/busses/i2c-rtl9300.c | 36 +++++++++++++++++++++++++++++++++--- 1 file changed, 33 insertions(+), 3 deletions(-) diff --git a/drivers/i2c/busses/i2c-rtl9300.c b/drivers/i2c/busses/i2c-rtl9= 300.c index 8310675668fdddc9626a5813bee050cc55a61c09..2fa425b141ea394a7c1857d3ccd= 073b12a187520 100644 --- a/drivers/i2c/busses/i2c-rtl9300.c +++ b/drivers/i2c/busses/i2c-rtl9300.c @@ -186,22 +186,32 @@ static int rtl9300_i2c_execute_xfer(struct rtl9300_i2= c *i2c, char read_write, return -EIO; =20 if (read_write =3D=3D I2C_SMBUS_READ) { - if (size =3D=3D I2C_SMBUS_BYTE || size =3D=3D I2C_SMBUS_BYTE_DATA) { + switch (size) { + case I2C_SMBUS_BYTE: + case I2C_SMBUS_BYTE_DATA: ret =3D regmap_read(i2c->regmap, i2c->reg_base + RTL9300_I2C_MST_DATA_WORD0, &val); if (ret) return ret; data->byte =3D val & 0xff; - } else if (size =3D=3D I2C_SMBUS_WORD_DATA) { + break; + case I2C_SMBUS_WORD_DATA: ret =3D regmap_read(i2c->regmap, i2c->reg_base + RTL9300_I2C_MST_DATA_WORD0, &val); if (ret) return ret; data->word =3D val & 0xffff; - } else { + break; + case I2C_SMBUS_I2C_BLOCK_DATA: + ret =3D rtl9300_i2c_read(i2c, &data->block[1], len); + if (ret) + return ret; + break; + default: ret =3D rtl9300_i2c_read(i2c, &data->block[0], len); if (ret) return ret; + break; } } =20 @@ -299,6 +309,25 @@ static int rtl9300_i2c_smbus_xfer(struct i2c_adapter *= adap, u16 addr, unsigned s len =3D data->block[0] + 1; break; =20 + case I2C_SMBUS_I2C_BLOCK_DATA: + ret =3D rtl9300_i2c_reg_addr_set(i2c, command, 1); + if (ret) + goto out_unlock; + if (data->block[0] < 1 || data->block[0] > I2C_SMBUS_BLOCK_MAX) { + ret =3D -EINVAL; + goto out_unlock; + } + ret =3D rtl9300_i2c_config_xfer(i2c, chan, addr, data->block[0]); + if (ret) + goto out_unlock; + if (read_write =3D=3D I2C_SMBUS_WRITE) { + ret =3D rtl9300_i2c_write(i2c, &data->block[1], data->block[0]); + if (ret) + goto out_unlock; + } + len =3D data->block[0]; + break; + default: dev_err(&adap->dev, "Unsupported transaction %d\n", size); ret =3D -EOPNOTSUPP; @@ -317,6 +346,7 @@ static u32 rtl9300_i2c_func(struct i2c_adapter *a) { return I2C_FUNC_SMBUS_QUICK | I2C_FUNC_SMBUS_BYTE | I2C_FUNC_SMBUS_BYTE_DATA | I2C_FUNC_SMBUS_WORD_DATA | + I2C_FUNC_SMBUS_READ_I2C_BLOCK | I2C_FUNC_SMBUS_WRITE_I2C_BLOCK | I2C_FUNC_SMBUS_BLOCK_DATA; } =20 --=20 2.47.2