From nobody Sun Oct 5 14:37:46 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 0722E21D3F8; Sat, 2 Aug 2025 10:42:24 +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=1754131346; cv=none; b=EiYFhE/ooPmUZOrhrrTmPuVs6WKwpoX2Zvhi9VYLzvwPNnHT+ofajGPLsy37srut8kpVHBMojekeKZHGdYudDO4owF0b7V4M9DVYgDW22eRD5ypijQiD3rvRHHLd6YTs4YN9R222qsJviOrFsojEwOChrEg+A8UGe9hcCtEQkZo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754131346; c=relaxed/simple; bh=M0ExxDwTq+EgVN8lGTAmv4NykEunoEBCeVqoYoEzVV8=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=AAFyq5EUhzcUa19jqNyrgrSK9vBqCOq6SFrfFSXHFruaz0bPVCgh/RtXied0JusMQYg2gza4oYbcGCg+Z6jAcMLvV+ypSJbuOM3vTaVjJvD4GNJjhgtjULQ94btfegbT45IzB7TEgOe/3mogPCkri3whV7kPDOXXU4QaQ9x4dYI= 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=fB40SNN2; 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="fB40SNN2" Received: from sven-desktop.home.narfation.org (unknown [IPv6:2a00:1ca0:1d86:99fc::8c24]) by dvalin.narfation.org (Postfix) with UTF8SMTPSA id D22F721796; Sat, 2 Aug 2025 10:32:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=narfation.org; s=20121; t=1754130741; 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=EOSCWi+cF2PB35Nc47+WAwgactGXBAdhUs+k7UcT1bA=; b=fB40SNN2iRDnG8l+IM3I2mcVINhp60BhxnhHfIjixbAA/rtuD/6LXGfLsWfxGideg4meAX rQPV63+6+LislFRmCOS2Ui9SB8UmuJ9rgcC0d2LhbTvDjdHenwKosToBNU1aGmGF3tHiQy SVbSxM61nHvqZ2m5ar4EtPdhvVId7ro= From: Sven Eckelmann Date: Sat, 02 Aug 2025 12:32:00 +0200 Subject: [PATCH 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: <20250802-i2c-rtl9300-multi-byte-v1-1-5f687e0098e2@narfation.org> References: <20250802-i2c-rtl9300-multi-byte-v1-0-5f687e0098e2@narfation.org> In-Reply-To: <20250802-i2c-rtl9300-multi-byte-v1-0-5f687e0098e2@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=2587; i=sven@narfation.org; h=from:subject:message-id; bh=fvbdbX5YpMEdiI0iyuFqcxzjPuLZ5q8XQBDJiObeHFE=; b=owGbwMvMwCXmy1+ufVnk62nG02pJDBm9L026bW4tvJNXs/i02w/G8hPThRab8Qnd+vy6yNlwc 1Rq8uHTHaUsDGJcDLJiiix7ruSf38z+Vv7ztI9HYeawMoEMYeDiFICJhHoz/M++aXzb6K3FKsmS 9z522dPtJ29TW7olU/Pu8nn7OiRWXtrJyHBnnY/X4k8RS6xOlehJSQSIXTWOmtT1MiOTM/oDRz3 rDgYA 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: 04-03-02-01 reg 1: 08-07-06-05 reg 2: 0c-0b-0a-09 reg 3: 10-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: 01-02-03-04 reg 1: 05-06-07-08 reg 2: 00-09-0a-0b reg 3: 00-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 Sun Oct 5 14:37:46 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 DCC8E21FF58; Sat, 2 Aug 2025 10:42:24 +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=1754131347; cv=none; b=mt2adFPc/KKLs9K3yhRmvUQ3gGtEvDUWNQoj2ZGrohnyBFqEMy8eJMwmPM+5EwQsbmytyzirnoqKuqcLD6NoolGiiFiH55wIRxqu815e/lMK7D5ocgPhs/3y1gttzoyZYPprQo353GqDNS0kARJ2ZdxwrBYT/XdBDOqkQfSf6Rw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754131347; c=relaxed/simple; bh=F3KerRZ9y/W49N23F2pnABpm9INuP0SzFFoSFXvVQe8=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=QqTu1VHai2+CPoD/UcdSBX6Og0sqltrAMOv2F6GTN40JBYZL78KN0AHYnTdIlxLFaFJvkpTrKouMCqn7MOfgIcM1wf4rqLbP5dQ9ENeJpBugT+NULX5o6SqHjv6f3imFVR4V2gzXrZ0m9QAQ0LLZPWaHZOkqQWrPqP9eS6JiSsU= 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=bTYHLmcv; 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="bTYHLmcv" Received: from sven-desktop.home.narfation.org (unknown [IPv6:2a00:1ca0:1d86:99fc::8c24]) by dvalin.narfation.org (Postfix) with UTF8SMTPSA id 8AFF221797; Sat, 2 Aug 2025 10:32:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=narfation.org; s=20121; t=1754130742; 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=bTYHLmcvuCIn0yzd2AvjK0aEzvZYC9vDWxEScVQB3aAarkbJwqI/OBK1CuGVW95fOH1fnj YoGem1ooSIUmGutnZyc9hXi+BCXzyxdrBINmyCeMIMLumO5GfiNLgohw8CVhWITmFjFxcY dvvQ60jPl9E7bZbpBCN0gFCMLTOKYmk= From: Sven Eckelmann Date: Sat, 02 Aug 2025 12:32:01 +0200 Subject: [PATCH 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: <20250802-i2c-rtl9300-multi-byte-v1-2-5f687e0098e2@narfation.org> References: <20250802-i2c-rtl9300-multi-byte-v1-0-5f687e0098e2@narfation.org> In-Reply-To: <20250802-i2c-rtl9300-multi-byte-v1-0-5f687e0098e2@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+ufVnk62nG02pJDBm9L00+2lx6G5TG0/tU+tPElUIzoo/7/vS4s9sj+1THw beWKbXMHaUsDGJcDLJiiix7ruSf38z+Vv7ztI9HYeawMoEMYeDiFICJfGhl+J+i+GWGvoH3JiPR 1zfiLoeockqwrZHcGXJpcVBle5DlsTiG/3H6EWt7jRRLo2/m+Kybvci52XzZXU2TRPOb3nMuP/r zhgcA 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 Sun Oct 5 14:37:46 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 071D221146C; Sat, 2 Aug 2025 10:42:24 +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=1754131346; cv=none; b=Wg/g0Qwwnmaoa45Lf40TwG5EFwFEYdSqA9PygDzRYFBygdL7KbnoR7vqxBUAAWBDk6uDczBq8HQz6IRJm6kcuuwFl29AKo/Ca4TBfGnCTCW167m7J2+iYCbvwGzM7zpjIBgfePYRqiikHPmkKJkpqeApsLI5ZxMtwHBzPqjxe5o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754131346; c=relaxed/simple; bh=D4SrjSCVF/QFFZGZ8db0byFl9K4OB6LkB7i7Fsk/Uh4=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=fsljsVqoQcZs4LO4/WhNt0moA1gkaQAtPljm26+qaYbjBQ8GqkhLUadBupCxxN0+zcYlVZ0rmd2db4YMt9g307Ama8hSgTxmEWiM5S+O8FBrTAa2H2eocgI1uQOvnYboF9p6ekbsK068PnW/JUzf5AUqMlmpE2ol3VUbamatCNs= 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=0Amdm/9u; 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="0Amdm/9u" Received: from sven-desktop.home.narfation.org (unknown [IPv6:2a00:1ca0:1d86:99fc::8c24]) by dvalin.narfation.org (Postfix) with UTF8SMTPSA id 274C421798; Sat, 2 Aug 2025 10:32:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=narfation.org; s=20121; t=1754130743; 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=vwQxvH0aQAdhk+KtdLO2G0fuUHwUbVgID2tMIZca1T4=; b=0Amdm/9uQ7aI+HwC1GivSNN/uk5VKv33DBM4CkJNC8ztNC2v41suTaeUH5C5b7R7RIOanJ wMrgq9KqDvtrNZ/ZuQD75EVlCRZSPsR7hJVk8p5jVV4iM27oXa+CrTZD2Y/t10zLCvYFdB efANxJ6BpeHUvwTRKaTq8LMCl4JB8Nw= From: Sven Eckelmann Date: Sat, 02 Aug 2025 12:32:02 +0200 Subject: [PATCH 3/4] i2c: rtl9300: Add missing count byte for SMBus Block 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: <20250802-i2c-rtl9300-multi-byte-v1-3-5f687e0098e2@narfation.org> References: <20250802-i2c-rtl9300-multi-byte-v1-0-5f687e0098e2@narfation.org> In-Reply-To: <20250802-i2c-rtl9300-multi-byte-v1-0-5f687e0098e2@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=1548; i=sven@narfation.org; h=from:subject:message-id; bh=D4SrjSCVF/QFFZGZ8db0byFl9K4OB6LkB7i7Fsk/Uh4=; b=owGbwMvMwCXmy1+ufVnk62nG02pJDBm9L01e1j2XSuU/fs9NISvN8NYfbfNCR2/rtd8026NLu LWyfs3pKGVhEONikBVTZNlzJf/8Zva38p+nfTwKM4eVCWQIAxenAEwk8SPDP7OPL672f9xSeefo OWvlpOnBlz4nsGgdvl3j2q3zU+5q8neGf8qZwu9EG71k13Uu63sl0nfZxt1n18TWzmf2GW2qKkX tbAA= 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. 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 a10e5e6e00075fabb8906d56f09f5b9141fbc06e..ed82e6c21aaf46000a263740123= ffba833578cc2 100644 --- a/drivers/i2c/busses/i2c-rtl9300.c +++ b/drivers/i2c/busses/i2c-rtl9300.c @@ -288,7 +288,7 @@ static int rtl9300_i2c_smbus_xfer(struct i2c_adapter *a= dap, u16 addr, unsigned s 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; } --=20 2.47.2 From nobody Sun Oct 5 14:37:46 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 5316E2206B7; Sat, 2 Aug 2025 10:42:24 +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=1754131347; cv=none; b=JjAncsnK4X8QyACKN7sa07j4NUTIMcP8esSJBxEbSxyULdCw9GyhqKYBjWC8uf38SNZRkX+Tu3VAzfty0owhD+k5KhFrapMPu37xDLnJet55mlQfyzmwPuWhMUjD62vIF3hO6pMpWfzchpM6wanJ6O2hyIayUFwgsZppKgC606k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754131347; c=relaxed/simple; bh=29F1+RXPw1Dc/x/sjm2BkHuKggNrrD6bpYFT21Gu5Z8=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=S1f0A9WjgtcjJHCxF4mbLfjhF+tB6oawEWFeT3zOWhpiH26wosw0jJNqdu/OYMY4Kdd/MMwgOBAWtW6P/o9MVbnwNKhOacikZRX9Ogg4YaMIQXPHLh+stPPpvjRtfFjUJjCWv99mQpEPT8N65AQj+4DSYYS3hQ050yMJNfSnMX0= 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=ZzaWYyn3; 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="ZzaWYyn3" Received: from sven-desktop.home.narfation.org (unknown [IPv6:2a00:1ca0:1d86:99fc::8c24]) by dvalin.narfation.org (Postfix) with UTF8SMTPSA id A156421799; Sat, 2 Aug 2025 10:32:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=narfation.org; s=20121; t=1754130743; 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=+5xOplr6ovXoGtviwtawCgHS3qIHk1mZlTK35oAHU/o=; b=ZzaWYyn3Q5yQmOYY/vgRQEOcnnqL+lYQOJMqd7SvdnoNU6CwhMe3Il7NCVyrQcbkRN1O+h JKcEWQKxlpuLZvdgy9n7txRgukiGmx9ZYzV2/igJZAMd48oFkHzJnDf1vHczIVQ2Fpm7rR 7nCDkcUwFd6vo1ECWcTUlvmGzjNHufI= From: Sven Eckelmann Date: Sat, 02 Aug 2025 12:32:03 +0200 Subject: [PATCH 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: <20250802-i2c-rtl9300-multi-byte-v1-4-5f687e0098e2@narfation.org> References: <20250802-i2c-rtl9300-multi-byte-v1-0-5f687e0098e2@narfation.org> In-Reply-To: <20250802-i2c-rtl9300-multi-byte-v1-0-5f687e0098e2@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=3814; i=sven@narfation.org; h=from:subject:message-id; bh=wU1p33zKAgTDAe62H5t47SqeyXmVfEZJanT+0snjcS8=; b=owGbwMvMwCXmy1+ufVnk62nG02pJDBm9L028ed3fBKmcz6uwPMJnligSNbXk6M5Fv2UETutyn FGdcXZVRykLgxgXg6yYIsueK/nnN7O/lf887eNRmDmsTCBDGLg4BWAith2MDNdfWSsLGno7Xw/m rnzawD9fcJXi8ozuL9K3QlnvPdKp9mb4zX6BtTDNZmdr1azU/u2XS8RfTypcvGZ/XOrhPzsTbwS 85AYA 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 ed82e6c21aaf46000a263740123ffba833578cc2..e136f774fd1a6be03339a3c1b70= c1a93a92ee55c 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]; 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