From nobody Sat Sep 13 22:24:29 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 1027A253939; Sun, 10 Aug 2025 18:06:11 +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=1754849174; cv=none; b=u9gxwl4l9ZE6iiclJmns3bnnYBHwx3oJju+kf3dacFJYjGKU3RiRwOMgfXtZwUE2+e7P6oYNgqyMswRlWfLcCLkLOaoFGNCB0+H2Oym3MpKaqhsKe29IKwRAi8gh49xvgHMRvfZuDHVtKsrm1pbzG0X1t+6bv8n+1SIvrXeb8a0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754849174; c=relaxed/simple; bh=Dy/+oYKdSQIxukU4C6KAV+6/KmCRVwWWiaWUjTh0JOk=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=D76ZArIUJCHjSObHhQTgBaulT1/3nlkRDnYcLeWIUNKG3I/MkZD99ouNH0Oqf7V60pTYTAUuMTQZm3ial+6kI+CG2+dgAklAqtDXpHSO/K9fcAfD7sjZap1cFcoPk/TATHN2q8Po5cHuwLMU0wiqTy4skM2UQKu4LocEJ+Z4DHI= 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=cyKCwt0w; 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="cyKCwt0w" Received: from sven-desktop.home.narfation.org (unknown [IPv6:2a00:1ca0:1d86:99fc::8c24]) by dvalin.narfation.org (Postfix) with UTF8SMTPSA id EC1B5217D3; Sun, 10 Aug 2025 18:06:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=narfation.org; s=20121; t=1754849170; 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=oOlmykBK1nKMQAg+VZNiT71+qP2QWD1fWMQ0ok2PwcY=; b=cyKCwt0wMVHz01ij3DSgffeQCMUbL8iJchhWsk2lsgnL8r1tmB2CvEt4q7J72yFzd4EQB3 Gnwj33hkfQ0JS/8FcJx50HlxH99ECZFS5jZCfuMlSqp7JZCYvyEScoDXmgtPAQiLmigGh9 b7DDpVOT4nS9/EBEwS1C3AGfIbPkccM= From: Sven Eckelmann Date: Sun, 10 Aug 2025 20:05:13 +0200 Subject: [PATCH v5 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: <20250810-i2c-rtl9300-multi-byte-v5-1-cd9dca0db722@narfation.org> References: <20250810-i2c-rtl9300-multi-byte-v5-0-cd9dca0db722@narfation.org> In-Reply-To: <20250810-i2c-rtl9300-multi-byte-v5-0-cd9dca0db722@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, Wolfram Sang X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=1545; i=sven@narfation.org; h=from:subject:message-id; bh=nVUBLWVV5vK7ESr25xEtVVF15EuGnWZo3SbgG4GFu88=; b=owGbwMvMwCXmy1+ufVnk62nG02pJDBkz7rfPTdjnGz87U3hl3J4Sr70HG9dUnt3r4Vi/reUR5 9aTIv7FHaUsDGJcDLJiiix7ruSf38z+Vv7ztI9HYeawMoEMYeDiFICJzF7JyLD6bp38wqAet+dB 09/VvrzWlZKvbpCqu/u2fAXPB3mxy+6MDJOUf3Zxnzj5QPS2VCHXmSenLxyz3vBy+gZzhiMHVvC fV2YEAA== 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: stable@vger.kernel.org Fixes: c366be720235 ("i2c: Add driver for the RTL9300 I2C controller") Signed-off-by: Alex Guo Reviewed-by: Chris Packham Tested-by: Chris Packham Reviewed-by: Wolfram Sang 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 22:24:29 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 7F35C274FE0; Sun, 10 Aug 2025 18:06:14 +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=1754849176; cv=none; b=TAo2o3JWP4pFTP+eFEbSY5qztpU5/qpco7oTHYvAf57V4U+aKj11on45kBBrcY/pHw7E9snHR3177FExxR/UVBtLw7OZNpuMmUqZ7Cwlpyp+1pcRMRThq54CLD90jdYazvb7CCTVASQ+OX3Sud+4S/0vDsM3cBIP9G1iW5EL5bo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754849176; c=relaxed/simple; bh=TpthaIOH9bcG/HjS8GYzpaB2CYoNJEhUn+cipvQCF+o=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=JLoGMwkaiERMpSWioX0Ou7Nr//2KxyAsucfJHcRXpndZEW+rlXrPGMJUeUM9bXkUjvHvzSrpQaq+bmHJ56Sqkr0DjVClZAD+Y4oD+e9tkAvth4LO1y5tBF8z0Xd2VOhcUKU43+/yqN7hnO8AU1mrk6SneDMVvhhBQHsEVdRd6ck= 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=MYS7ztNV; 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="MYS7ztNV" Received: from sven-desktop.home.narfation.org (unknown [IPv6:2a00:1ca0:1d86:99fc::8c24]) by dvalin.narfation.org (Postfix) with UTF8SMTPSA id 4988521965; Sun, 10 Aug 2025 18:06:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=narfation.org; s=20121; t=1754849172; 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=iUzsjF6jNJPJu8ygajyyIZFBOGXBf9p3FjvBQBso4nE=; b=MYS7ztNVv6jL3Y3zetPj0+LyFbCCj+ef8an98bljhLbWdHmroeqQDi09hqDit18yPDqpHR sqepwUkvvlnzAMDGmqV7CptzBoG9AlBgJdS/i9+FlcWzss4NGpTNqlPb/RwQt6WIYNXyDA 5NmvTCU7Hp+5IWcfnWSgnbenz9eZBxs= From: Sven Eckelmann Date: Sun, 10 Aug 2025 20:05:14 +0200 Subject: [PATCH i2c-host-fixes v5 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: <20250810-i2c-rtl9300-multi-byte-v5-2-cd9dca0db722@narfation.org> References: <20250810-i2c-rtl9300-multi-byte-v5-0-cd9dca0db722@narfation.org> In-Reply-To: <20250810-i2c-rtl9300-multi-byte-v5-0-cd9dca0db722@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=2869; i=sven@narfation.org; h=from:subject:message-id; bh=1jT+A7C/CY/ODrnBGy3IEY79kMlFtxpeg+PKvR0HJjM=; b=owGbwMvMwCXmy1+ufVnk62nG02pJDBkz7neUCW2btLbnUDhXmuayC5xxkmaz2uMuHpR+vLZ6i /EC/dAPHaUsDGJcDLJiiix7ruSf38z+Vv7ztI9HYeawMoEMYeDiFICJXC5g+Gcz37O3rVnGNC+F yb78w5SL81RWih/6ZHg8Y1WGq6YZrwrD/1yF9c4zgt/kua7d1bD1yj6+NyaiVbof130x+jJx4hm r9ewA 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 Wr [A] 04 A 03 A 02 A 01 A 08 A 07 A 06 A 05 A 0b A 0a A 09 A P But the correct data transmission was expected to be Sr Addr Wr [A] 01 A 02 A 03 A 04 A 05 A 06 A 07 A 08 A 09 A 0a A 0b A 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. The second initialization (to 0) of vals was also be dropped because this array is initialized to 0 on the stack by using `=3D {};`. This makes the fix a lot more readable. 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 | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/i2c/busses/i2c-rtl9300.c b/drivers/i2c/busses/i2c-rtl9= 300.c index 568495720810b373c4fa3b31d3f4cdec7c64b5f9..4a538b2660802c98e1a51d2ed78= 2e154f2a5d1a0 100644 --- a/drivers/i2c/busses/i2c-rtl9300.c +++ b/drivers/i2c/busses/i2c-rtl9300.c @@ -143,10 +143,10 @@ static int rtl9300_i2c_write(struct rtl9300_i2c *i2c,= u8 *buf, int len) return -EIO; =20 for (i =3D 0; i < len; i++) { - if (i % 4 =3D=3D 0) - vals[i/4] =3D 0; - vals[i/4] <<=3D 8; - vals[i/4] |=3D buf[i]; + unsigned int shift =3D (i % 4) * 8; + unsigned int reg =3D i / 4; + + 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 22:24:29 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 7C41B3B29E; Sun, 10 Aug 2025 18:06:20 +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=1754849182; cv=none; b=lfgRWjKIE30tpycZ7/14zCkrZm6mhPIJU83t/00DCdfV7UrPo0MCJNUHjTXz/TgpsAgWUzvbzrmF6Vlwv0cslhvNcCoCOlU7YJAqVyqSBcKBgS+0OmchTRlCcfzndKcqPPpUuWcCiEVG39aIpeYCwMw6Yza5IcBLrrpN1DqvdZE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754849182; c=relaxed/simple; bh=JkSHmP5mjo+WXOJdZpYaGBO+h2dGd7a2OUfPAZBNFqg=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=QQyxXs4t0qTYL35RXY+SIGzbK0cKhe8J6NxjIXq8mRlHCd12kC4ELLVtTjxvWQK4Ix89W0MfrUqAdMmuNdJX3wrtP3v9k9hsCZ2cNDGOXfGfP4pgkqoFyPjGPlcsWhPecgxjcTbSSKWaKanUUcf94cPL+3aSw/LiBDz4bhYxrAA= 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=hYoWk2gQ; 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="hYoWk2gQ" Received: from sven-desktop.home.narfation.org (unknown [IPv6:2a00:1ca0:1d86:99fc::8c24]) by dvalin.narfation.org (Postfix) with UTF8SMTPSA id CDEA220019; Sun, 10 Aug 2025 18:06:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=narfation.org; s=20121; t=1754849178; 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=sgIYXfd+vWJAvPi6jchjBMNFQIUKjayvrf4gwD/0FZY=; b=hYoWk2gQmsZQUj/36HjbPjjCT4bpy7iYmGjhhry7H2U2jAoDPi1aBHS1hKmYFzJEuSO/ss zEC9Nov6zbink0IsRC0Osq7qOp9fxvO+yDPA03jEWWXfTXPV4Ju4toFqdunR9DfRr3Tf8x /MxgUMMXHKMhiZdddhBx99BtQDuZmlY= From: Sven Eckelmann Date: Sun, 10 Aug 2025 20:05:15 +0200 Subject: [PATCH i2c-host-fixes v5 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: <20250810-i2c-rtl9300-multi-byte-v5-3-cd9dca0db722@narfation.org> References: <20250810-i2c-rtl9300-multi-byte-v5-0-cd9dca0db722@narfation.org> In-Reply-To: <20250810-i2c-rtl9300-multi-byte-v5-0-cd9dca0db722@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=1823; i=sven@narfation.org; h=from:subject:message-id; bh=JkSHmP5mjo+WXOJdZpYaGBO+h2dGd7a2OUfPAZBNFqg=; b=owGbwMvMwCXmy1+ufVnk62nG02pJDBkz7nd4OVtsK/pvbHNkmfKH4Ab2t/MjTnpFmrz8l7iP+ czFoz9Od5SyMIhxMciKKbLsuZJ/fjP7W/nP0z4ehZnDygQyhIGLUwAm4iLK8N/jhGrFU6sZ4bfc 6xxW2f6QlM30OmGls7ilQT97hdzaT1oM/wsDYmo2WrrMuJXw6u++Bu27rrrBvLvuh174u2WPQNj bB5wA 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 implements the ETIMEDOUT error, it is more sensible to increase the timeout in such a way that 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 4a538b2660802c98e1a51d2ed782e154f2a5d1a0..4a282d57e2c1a72c95bdabdd9eb= 348a73df28c44 100644 --- a/drivers/i2c/busses/i2c-rtl9300.c +++ b/drivers/i2c/busses/i2c-rtl9300.c @@ -175,7 +175,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 22:24:29 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 0794E278E42; Sun, 10 Aug 2025 18:06:22 +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=1754849184; cv=none; b=bf0fp6bwT+jwMCHPyL1cHQapsX8su8nWSMJZWUpInT9MfJtuHC0WfOz9hxwyTWYK1aUor+9L9afxxocUghH7RpKy2kKS9tWuSl9QIAJ0lYrQ6d42RisdyzgYhV5CXT0RhZWJp1KulG5+VLHyA5j9bCkBY/63+q6s5Jc+3Y5o7So= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754849184; c=relaxed/simple; bh=BHNXsv6JbtDlzsvtQDJK95gj4z98l8CStiP1HYWY6xY=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=oxtP/HgMpeXICf9Bx/4l0qJLjOhDKieFNibfGLSgycAAYhNFI1c6m47T7A1lUajCPGvpOShNrsloVuwsMuzl/oyT8BU7PocqDX4lHa4X+9/VMqXXpcHkYQePqulFu/JKALy3e47ecA5hInNmSOVACgMwXLEAJSKsJDxwswGp+zg= 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=DEVYBaCo; 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="DEVYBaCo" Received: from sven-desktop.home.narfation.org (unknown [IPv6:2a00:1ca0:1d86:99fc::8c24]) by dvalin.narfation.org (Postfix) with UTF8SMTPSA id 42E9E217D3; Sun, 10 Aug 2025 18:06:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=narfation.org; s=20121; t=1754849181; 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=qp1mdvDUuZytnfOwpewyXGRbiR2bfJOyoqCmLTNrquQ=; b=DEVYBaCotOT89KlOF/vKqV7j0AWbYvYMsAP+jB8gMFNQthf65v3+hOheAKjFC6GP7AXKYE 4XoRN3gweHH88yXaDnYQscFP3Ofrdn5S14aX+Bnn9zeNDhmPOBp5lB/xIUrZ2idFykbZGa ldHlWogzIXLH13bdHhdyZ0SGHAy7A+Q= From: Sven Eckelmann Date: Sun, 10 Aug 2025 20:05:16 +0200 Subject: [PATCH i2c-host-fixes v5 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: <20250810-i2c-rtl9300-multi-byte-v5-4-cd9dca0db722@narfation.org> References: <20250810-i2c-rtl9300-multi-byte-v5-0-cd9dca0db722@narfation.org> In-Reply-To: <20250810-i2c-rtl9300-multi-byte-v5-0-cd9dca0db722@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=2060; i=sven@narfation.org; h=from:subject:message-id; bh=BHNXsv6JbtDlzsvtQDJK95gj4z98l8CStiP1HYWY6xY=; b=owGbwMvMwCXmy1+ufVnk62nG02pJDBkz7nfYpG5k7xdzdmBK0t793d5KOtxszeSDzWKbN9aF5 y0yCY3rKGVhEONikBVTZNlzJf/8Zva38p+nfTwKM4eVCWQIAxenAExkxQeG3+wPzhx9wsC3ziN4 noS556aftmvO7OmK2cZf88fJkVOrnZnhn7nrM2k7mdw/Kte1LksXFq+qLc66qxy9fe6XdSrRj44 Y8QAA 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 is 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 4a282d57e2c1a72c95bdabdd9eb348a73df28c44..cfafe089102aa208dde37096d51= 05d4140278ca9 100644 --- a/drivers/i2c/busses/i2c-rtl9300.c +++ b/drivers/i2c/busses/i2c-rtl9300.c @@ -285,15 +285,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 22:24:29 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 51A5B279798; Sun, 10 Aug 2025 18:06:25 +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=1754849186; cv=none; b=Xone5+XLaIhACsCFMXnntuWFiiuHqomtD7KXqwnxQM418/zzBJLK9Xj75kJpy+OBS9RezoQMNNKP+nie45eLI/lHzsNAEixMGaYYsURcIYCKA335BzhhPvDLXtys6e8XRX/faV9pssoF27IOJtsmtZ5c9AyuhMXktU9cCbJPNUE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754849186; c=relaxed/simple; bh=ooTLaHmQybwGGge1entEvKAX8SQk8v+ORITWDFz5als=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=r7TGb35FcrcN4/+1RbfK1KSHtbuJAkENY6a3sBv72U3zOA9XIIfXfeFRwB3dy0JWqL3076MhaHKTGcTGvO2U4QXnyUAcNKY2TKvVQtldLdX3HsLTA6QeK4QSvvUbL42ozuW6MelS0dcxtHECCGznDmYaN6QWyQdN8+GveIy+GLs= 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=m/dUMBp7; 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="m/dUMBp7" Received: from sven-desktop.home.narfation.org (unknown [IPv6:2a00:1ca0:1d86:99fc::8c24]) by dvalin.narfation.org (Postfix) with UTF8SMTPSA id 8E60020019; Sun, 10 Aug 2025 18:06:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=narfation.org; s=20121; t=1754849183; 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=SW0zXfcM4Brk/3nLi6+7vIwA4ZjqI+kW+3oPZQZhzOI=; b=m/dUMBp7G9I2F1pV73HSek5Ht7UeBTGruEVNsQ0KgpVNJUDqKPY3f5A7c/najIg5oaZK80 YvLCMu4hEP5Nw4WmUcRi1q97gfdLc8mcFUwI5kCOKqAs0gQaZSSXVHvaWpJPopeECBwtaI mAl7CVHGVTuEi+ippx1KtD4QD7VFUYQ= From: Sven Eckelmann Date: Sun, 10 Aug 2025 20:05:17 +0200 Subject: [PATCH i2c-host v5 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: <20250810-i2c-rtl9300-multi-byte-v5-5-cd9dca0db722@narfation.org> References: <20250810-i2c-rtl9300-multi-byte-v5-0-cd9dca0db722@narfation.org> In-Reply-To: <20250810-i2c-rtl9300-multi-byte-v5-0-cd9dca0db722@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=4114; i=sven@narfation.org; h=from:subject:message-id; bh=OTG3ecUJ9kF3MgzJErbZLX8C+EA6bsD6pcX+Od1rdNE=; b=owGbwMvMwCXmy1+ufVnk62nG02pJDBkz7ncY7orXvCN3b3Z3VkTFUab4eZFpN14WCX1Oea+zZ aHD6jzvjlIWBjEuBlkxRZY9V/LPb2Z/K/952sejMHNYmUCGMHBxCsBEZscw/K92Cde98DJ+8urs rRmHdLYru7IZpEcG3uvap8t3aHvKsb0M/90mi6zO4ZvYujcy4sNCCdNpuyKFZeVfntT6v8xko7+ uLy8A 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 skipping 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 | 37 +++++++++++++++++++++++++++++++++---- 1 file changed, 33 insertions(+), 4 deletions(-) diff --git a/drivers/i2c/busses/i2c-rtl9300.c b/drivers/i2c/busses/i2c-rtl9= 300.c index cfafe089102aa208dde37096d5105d4140278ca9..4b215f9a24e6aeb8ff078cfc03a= 54c7bd9a60c38 100644 --- a/drivers/i2c/busses/i2c-rtl9300.c +++ b/drivers/i2c/busses/i2c-rtl9300.c @@ -183,22 +183,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 @@ -296,6 +306,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; @@ -314,7 +343,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_BLOCK_DATA; + I2C_FUNC_SMBUS_BLOCK_DATA | I2C_FUNC_SMBUS_I2C_BLOCK; } =20 static const struct i2c_algorithm rtl9300_i2c_algo =3D { --=20 2.47.2