From nobody Sat Sep 13 20:52:53 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 7FC421DF24F; Sun, 3 Aug 2025 16:56: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=1754240164; cv=none; b=NcoOE9TC/4YjKrmU02tDDoz2Fg8lAdCSrZ/lhEvr4RyEUCO4ZW+ag/1eAKObDwkfYU+GkMkhaKUrdg9DMB7MDJfF7G37Lw04FS+YMMRg5ruQ67vqZZpBGk1OkFmWe9qJ4uO00r8U2/aWA6Hlt3pg3oPNXY+1W4IiFEu1OxdSR5c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754240164; c=relaxed/simple; bh=Ou4prkCgD3r9vp0EyHMeD0cvL027do7J+yQolBrNtZM=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=LqIyjeHY7mPpO2DiYgVetfHaDDCiFRCLEavwWe8Ke3LdnI/IwRPV2jcvl5vohUGQD3yH2/ewUyM8gcaVjVHQymyA4O2RyAGLrDTKWhjiLfi2mQB5gyD6LvP0BEIS6HYttCn8W8BPMtKfoXBToYWAKeEFrBvOhIJGyMxlhTRe/iA= 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=T7d8aKUH; 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="T7d8aKUH" Received: from sven-desktop.home.narfation.org (unknown [IPv6:2a00:1ca0:1d86:99fc::8c24]) by dvalin.narfation.org (Postfix) with UTF8SMTPSA id 90F1921025; Sun, 3 Aug 2025 16:55:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=narfation.org; s=20121; t=1754240154; 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=xhbAJZzJMhexzR97QbmwGz2nSA3Pj80XTZCx5wfqPDc=; b=T7d8aKUHWjPo9YZ+oevuaWqAfiWylPxceXe2R/wB5esWCstoDzbsoWKzZd2ghMuWCEKGTL jo5c0OEirSaDHze+YIIBkDmMtIOMvPISZHR9ahFYlncJikm4xCvclM6x1baZiJB1AXmNur FHARG3g3In+RIJMxbTqfgf9sD8fh3iw= From: Sven Eckelmann Date: Sun, 03 Aug 2025 18:54:38 +0200 Subject: [PATCH v2 1/4] 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: <20250803-i2c-rtl9300-multi-byte-v2-1-9b7b759fe2b6@narfation.org> References: <20250803-i2c-rtl9300-multi-byte-v2-0-9b7b759fe2b6@narfation.org> In-Reply-To: <20250803-i2c-rtl9300-multi-byte-v2-0-9b7b759fe2b6@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=2603; i=sven@narfation.org; h=from:subject:message-id; bh=fp5m+HrFVF1HrzGHiqewD50wt972OrHU8EebM/MHSdU=; b=owGbwMvMwCXmy1+ufVnk62nG02pJDBn9U/pfH/X/zv6o6FhfcPyxhX1Tqhp+NZ7uUT6tzP6/N +us8p/gjlIWBjEuBlkxRZY9V/LPb2Z/K/952sejMHNYmUCGMHBxCsBEqs0Z/hmw/vKbxKd/4Vi9 Updl+KJJi3q/T5825/yyD7+8RW1OttUyMtw//onXYZlkUIH2LzVm6X+9LmE/ys7ECm/Q+/3wTfK aBF4A 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 e064e8a4a1f0824abc82fa677866b85f99fbe4a7..1b3cbe3ea84a4fa480c5c00438e= ecc551d047348 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:52:53 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 3DF1E1DDA0E; Sun, 3 Aug 2025 16:56:01 +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=1754240162; cv=none; b=QLU3MwACUUIAxCQqCF8Wk8p86LlIqeSL8fD+iC0tRRULH3frMDiKM+jOB78BsWt+vRr2t5TMRDx6zqgQHcERsBDWSVIPMxDd2LM8kuK0SxTttSPku2ibPuXx0GxFI1SRL+WT9P9ojgQAkpAxpRAAf7kvGVCB58eLBLILh916r2k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754240162; c=relaxed/simple; bh=F3KerRZ9y/W49N23F2pnABpm9INuP0SzFFoSFXvVQe8=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=jpRdm6p2F4teSOT1q1ea4uQb4eDH5V5kp5sxfEqGMyNYX8G1S3c5VIqVM5jYsmzcduxeKxFgHkL9VcsE1LWOW0JBBLGL1aBg9i+TV+rlTmfrIiIrrQJZIM4an3sSe8OB8ji0ak3URJKedmP6mN9ekNvZcBuIeZ/AMxkhxUb9qXw= 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=ruOiMBAL; 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="ruOiMBAL" Received: from sven-desktop.home.narfation.org (unknown [IPv6:2a00:1ca0:1d86:99fc::8c24]) by dvalin.narfation.org (Postfix) with UTF8SMTPSA id 366E921029; Sun, 3 Aug 2025 16:55:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=narfation.org; s=20121; t=1754240159; 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=vE4nYdNaGEuI8DSTuxgnHMbOZcw4cjvKH08OXaLl71o=; b=ruOiMBAL7WajnkXtz+O2R/wk3p7OHU9g26aBlLUCevjWsuZigTTt1CG6ua0H/amPzde0A3 Sus4YXye9CHQww/thmTvzVgZxf0V3fjJIXmtXAlUsAoz6/FdzNT5OudlpNCeWmnU4HR8C7 pikNQ2l/4lmpEiLrrqDRW/TldZfnPIw= From: Sven Eckelmann Date: Sun, 03 Aug 2025 18:54:39 +0200 Subject: [PATCH v2 2/4] 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: <20250803-i2c-rtl9300-multi-byte-v2-2-9b7b759fe2b6@narfation.org> References: <20250803-i2c-rtl9300-multi-byte-v2-0-9b7b759fe2b6@narfation.org> In-Reply-To: <20250803-i2c-rtl9300-multi-byte-v2-0-9b7b759fe2b6@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=1704; i=sven@narfation.org; h=from:subject:message-id; bh=F3KerRZ9y/W49N23F2pnABpm9INuP0SzFFoSFXvVQe8=; b=owGbwMvMwCXmy1+ufVnk62nG02pJDBn9U/qPy4cFFYUEL/mlnqZu+tEjuSh3u66n9voEq8qna nLills7SlgYxLgYZMUUWfZcyT+/mf2t/OdpH4/CzGFlAhnCwMUpABMp8WT4KmP8Ojz+hvtef8EL c7PKZq7y3FfHlLiq/O33rccOfgvWYGQ4u35f5+TFh26maYotbL8femjCFccMj5j+zGM+80Q6mVt ZAA== 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 1b3cbe3ea84a4fa480c5c00438eecc551d047348..a10e5e6e00075fabb8906d56f09= f5b9141fbc06e 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:52:53 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 AF08F1C84AB; Sun, 3 Aug 2025 16:56: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=1754240167; cv=none; b=mL8ik4Ik0DtvdX0teMXpPolgTBt22IqeXkDFWxcLxZhqggWG4a4rnX2oxQTz1dsn5qZqqcJu7NaNI3sSCpPasEXQWSPuVK9iLtQgpA9ejQ6hbu0amCzT9m6ujxBEvBy60udOJYEpOuuvSkWVSMw7tbRNrspxBLp3BwTysPMe6QQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754240167; c=relaxed/simple; bh=Age11sHcgB0mkhSPalU1aHv3JmSrXv9AoOCMc2GPCL4=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=RVvGUu7Xy8i3R6K5jmw8VTJ2iiDptgze+QExwfbxIH2SXKQlG5EEonoKPmP3ZM4gsodgq3OeHiHn2+c7lhWXrjAEiDs/1kTxBzIwAbbdOZU4WDNpdvu0uqKph5OvRIj9DFhDW4qdQHkyaEcBGUVlmz+dvQ2TwIc1U1ZAjCiyubU= 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=wgo3jUvZ; 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="wgo3jUvZ" Received: from sven-desktop.home.narfation.org (unknown [IPv6:2a00:1ca0:1d86:99fc::8c24]) by dvalin.narfation.org (Postfix) with UTF8SMTPSA id D7FD8203A5; Sun, 3 Aug 2025 16:56:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=narfation.org; s=20121; t=1754240163; 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=mj+SQbgMiVuXLUs0BkAYEli0q0Swy751En7jGQHZNS0=; b=wgo3jUvZrPYWuAcfAubrfl5XKNZCV2LrO0MwRidfg4MahA//ELNY8H8vU0YoX5Nw+GlSM5 +sTfN2fxRfmG/ABPWtmvN+hY5i7isPjLlx/BXqOiHgSd/NE9iWnP/jgy0uMSe3MfAy7nSQ PRL9FyS8w+iRG0dC3juLuyMZI4nETNI= From: Sven Eckelmann Date: Sun, 03 Aug 2025 18:54:40 +0200 Subject: [PATCH v2 3/4] 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: <20250803-i2c-rtl9300-multi-byte-v2-3-9b7b759fe2b6@narfation.org> References: <20250803-i2c-rtl9300-multi-byte-v2-0-9b7b759fe2b6@narfation.org> In-Reply-To: <20250803-i2c-rtl9300-multi-byte-v2-0-9b7b759fe2b6@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=1971; i=sven@narfation.org; h=from:subject:message-id; bh=Age11sHcgB0mkhSPalU1aHv3JmSrXv9AoOCMc2GPCL4=; b=owGbwMvMwCXmy1+ufVnk62nG02pJDBn9U/qPLfv898Fjt193mqc80ZNwPXS9PcmrJHMDo869t 37z1h526ChlYRDjYpAVU2TZcyX//Gb2t/Kfp308CjOHlQlkCAMXpwBMZHcRw//8RdfvPlr2h9vA Ijem3ZzBln9N0Hwmy4TPXFl6Ig9Wpn5mZFi42Sv68zKfw/MnTK+6vs4tZu6kleJFnk+3ye78Yzx VqYYTAA== 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 a10e5e6e00075fabb8906d56f09f5b9141fbc06e..4e0844d97607f64386a6d7a7c40= 86a81fdd89d6c 100644 --- a/drivers/i2c/busses/i2c-rtl9300.c +++ b/drivers/i2c/busses/i2c-rtl9300.c @@ -284,15 +284,15 @@ 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; - 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:52:53 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 83BD81F4CAC; Sun, 3 Aug 2025 16:56: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=1754240171; cv=none; b=mMmfG+cW+CCB6abl4qHZpMALqgfiEYsnXbzM9qGUTLNkH2FTTM6G6L8HybH+RYHCqJiv3hnLK+99Lq8ND7gK6GrAy78tEwyDvh+eSTRC2kCh3rbeSv7QnHAdpHbXrcPErgtpOhC0UP9xprW+quq0eFDLwLVePLW1vXb2bylVoAI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754240171; c=relaxed/simple; bh=6yddMlBi7WZ4YQVI11Ue6hMVOoR7aFNZkS1jLdkvbo4=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=BADWj5Q/a2uI6s3lf9gUm1eYAoDHSuRUs+wJivzZV9yaDmFOyHH8jqRic2MNu/4PMj4WQ037ZqGFgK1kpbm7NLKpdd0/G6B6WNd28gI3fFyWS3/ykq0FDyMaFXe1EQk4w+UNzddB7rewX1uBuxcZQZ20Px6OIPY83pZ+6cJds6c= 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=ey4TcGwI; 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="ey4TcGwI" Received: from sven-desktop.home.narfation.org (unknown [IPv6:2a00:1ca0:1d86:99fc::8c24]) by dvalin.narfation.org (Postfix) with UTF8SMTPSA id A918D203A5; Sun, 3 Aug 2025 16:56:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=narfation.org; s=20121; t=1754240167; 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=cfKmvmHHO7KEEOi9sjrXNREYqdk1dnOlDxfndUQPLNo=; b=ey4TcGwI8FXn9WYZTnbtD8XytvVxXsGMt1xR+lSTYGrCBQuKbonzPIs6Byc8QZmDWU+44w sEHvRZ4lUYCCIOhEiQ/0XQtE8g4vHI16By0NZT6BVLaxU53B/xAHEvuYlzC87a8YwLHrTi VDseOlMYu0KTAT5rWwy3AhhoQxBtYp8= From: Sven Eckelmann Date: Sun, 03 Aug 2025 18:54:41 +0200 Subject: [PATCH v2 4/4] 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: <20250803-i2c-rtl9300-multi-byte-v2-4-9b7b759fe2b6@narfation.org> References: <20250803-i2c-rtl9300-multi-byte-v2-0-9b7b759fe2b6@narfation.org> In-Reply-To: <20250803-i2c-rtl9300-multi-byte-v2-0-9b7b759fe2b6@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=3818; i=sven@narfation.org; h=from:subject:message-id; bh=r1VAKLSBt866jA1z22qnHzmaVllA4WduqthhQIIFd7E=; b=owGbwMvMwCXmy1+ufVnk62nG02pJDBn9U/o/aEaeVNliy/nggMpSgX+XhBNU7lxYI912ni/vj PL2p9FXO0pZGMS4GGTFFFn2XMk/v5n9rfznaR+PwsxhZQIZwsDFKQATidzO8N/dSOcmc0Gha5xH V0f1j93/vynniba9uJfc//J/WcnevuOMDE08a0U3t1w96+9eIXFTopxN6c3Sk0+vTFDpayoTP/0 klREA 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 | 32 +++++++++++++++++++++++++++++--- 1 file changed, 29 insertions(+), 3 deletions(-) diff --git a/drivers/i2c/busses/i2c-rtl9300.c b/drivers/i2c/busses/i2c-rtl9= 300.c index 4e0844d97607f64386a6d7a7c4086a81fdd89d6c..cc8c6d680b41976164b49492997= 6bd34d367d4de 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 @@ -295,6 +305,21 @@ 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; + 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; @@ -313,6 +338,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