From nobody Mon Apr 6 09:12:36 2026 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C6316318EC9 for ; Thu, 26 Feb 2026 13:11:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.43 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772111502; cv=none; b=s81es/TqWYYlxS++sgKhO69xJBIeW4KyBSRSNsIGMqsKb8U+BDN8rEntEcmGwQ4BRACPOvU7ZBg14FYSVpK4TRBFBviWkvugKPFiNTMovjyOZo4LqrCH7voBrCu89wn5G28RFKpsVBrESKTsOvnu6sjWX2IMRX4XOGj8ybbdzRo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772111502; c=relaxed/simple; bh=BjoqhXFbnW4O6mRBJ4tlQbQzL834URssLT4o7VANrbY=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=JzeKRGI1FAb1omCcw7q9t1rZj41Myi3AcdaY1++JaPtlNT+2UI/rteEAxEpbIP8XuqkzOVGhSUAIBRITEPLkZrY3XFvrR2MO3GPJc79zc9Ncj+qQwNe7g6Y3jUeAtkOPAurrbwfhBdYcPr6U0+9ekkzMrFkZd5VXF1B/vZXZ3AU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=R/EiG1Kw; arc=none smtp.client-ip=209.85.128.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="R/EiG1Kw" Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-4837584120eso5964225e9.1 for ; Thu, 26 Feb 2026 05:11:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772111498; x=1772716298; darn=vger.kernel.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to; bh=0gpTv0cQ1xaud3+6Hv+n3cMevQTI+cIYX2yYWA3C2vw=; b=R/EiG1Kwf3dl2WGPK8JaAdZwH/pZCfau/wpmzbhY3w0KUBWfrGLeN+K8h+ZChIJru6 k/oCSOFX8xzdxuhj0hDQTOMl7qIn86OQWYeRk7EPUmjw19qAfghgy3O2yq3tL78bd1Uy qf1XiTiTVYGF1EaEm2GW3U3U8QUaq5FqaBAE/dahkYD6H4GOEclP76Cb4008mFVRXkWC TYh+4z5KYOi2JRPUaiYtauuTTioiyrekKXQRJsZZbZWuzUQMbnjdcyXM6EBaXzrv6372 HOHajvY3NeUr7xVD8kc+7MFEP1h8qh1fVLt8qAps1iN2v+jm8LzEnB27MgFmY7tL6nyF Bayw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772111498; x=1772716298; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=0gpTv0cQ1xaud3+6Hv+n3cMevQTI+cIYX2yYWA3C2vw=; b=Cs+0MAsdsTgTLUWelmhO36PDUpc5GhIQUOEdmVGwWn1WqhmTbF+8ZT/f8N5qu6Lgwa rrnBbe5pEVwwqejoGIKY/jehUcDakd0eUkw569ibMMnd8QiqLkZgL16PgnFtskHf0INj 0Yt80ghgzoqhOBESwG7XPTZ2d3Lu5oUhwqrbXf23DZkAEs6jNrhuISTTQbnaLh9L1AHw Dq2Sxn1brwq4XDjMJnwEhiMsdlA6dqhk+tT52yfrX259E/5x8e5qxu0Voi3Mo+Va2h6P timcjuy6P5STWBjSVk1dvAqond9CnLBWc3/QgOeqW6i1ykBIZ9zbuWcrX1lvQtt798uR H4SQ== X-Forwarded-Encrypted: i=1; AJvYcCXMxIsILwK5tFNDqAuGqBLRqd8d3tzB8fV1T2CEzew/UhkJjd+50fc2so5ytkKLdwaH+FEbmUpGqivwsHI=@vger.kernel.org X-Gm-Message-State: AOJu0Yx05LEMtUc+b/5cb1FL+pR+948ay4ti499La5LgAeIRLSHR0A4+ OPziw/oXi03ZIKXwB4AnMxuAmNIuKv52OkZVTCymujLakQyvhZdWFcxt X-Gm-Gg: ATEYQzyf6oCqrzgPTS3GhmkRmwKtgAf7pKvfHZSvvz79jIB/oSoJQvRq3UkPQuQ1R1l Ooim/EmAsjZ/u7SG7+1TItoJnc8v/HrLNSGgYOFcB+i+aoVBIp2AVb9BJiL6j+QKKHJ5HDWePOl KCKkRwBkGPVESdpMa04xzRjWLK/PunYvOBXht4Gy4z+mJ6P12IE2p2lIfymtBzET7tt/Dn+uLMQ +qRBTUQ1QcsLn6KOz8bqyHW86GkA9OAm13sNGu+TOXXPS3rox18JMOTOZ7UDIIOpIAswjKyYV/h VrkDEg25rpuFQO1Fbox+q19JRh/52eZSpdh6kx0Gm8Zep5ynPEa1c4QR//zcNeUSHVfVnJoYj2b Vzl19LojEEUsahh7dGeKHjiiBMdH+Uznorj0kDE/jhyq86gC0RyK+joBeUsFduKjkcOtAnTW7Xr GZ2b71C1U1mM/AOzo8bnoza+2v3nJQ8oQ9bSpW41mFg24Cu0CG/VO1yTBxf9MV+/0= X-Received: by 2002:a05:600c:83ce:b0:477:7b16:5f9f with SMTP id 5b1f17b1804b1-483c21a9ab7mr73637575e9.31.1772111497833; Thu, 26 Feb 2026 05:11:37 -0800 (PST) Received: from [192.168.0.253] (5D59A51C.catv.pool.telekom.hu. [93.89.165.28]) by smtp.googlemail.com with ESMTPSA id 5b1f17b1804b1-483bfb789efsm64827145e9.2.2026.02.26.05.11.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Feb 2026 05:11:37 -0800 (PST) From: Gabor Juhos Date: Thu, 26 Feb 2026 14:11:27 +0100 Subject: [PATCH v4 1/2] i2c: pxa: defer reset on Armada 3700 when recovery is used 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: <20260226-i2c-pxa-fix-i2c-communication-v4-1-797a091dae87@gmail.com> References: <20260226-i2c-pxa-fix-i2c-communication-v4-0-797a091dae87@gmail.com> In-Reply-To: <20260226-i2c-pxa-fix-i2c-communication-v4-0-797a091dae87@gmail.com> To: Andi Shyti , Wolfram Sang , Wolfram Sang , Andy Shevchenko , Russell King , Andrew Lunn , Hanna Hawa Cc: Robert Marko , linux-i2c@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Gabor Juhos , Linus Walleij , stable@vger.kernel.org X-Mailer: b4 0.14.2 The I2C communication is completely broken on the Armada 3700 platform since commit 0b01392c18b9 ("i2c: pxa: move to generic GPIO recovery"). For example, on the Methode uDPU board, probing of the two onboard temperature sensors fails ... [ 7.271713] i2c i2c-0: using pinctrl states for GPIO recovery [ 7.277503] i2c i2c-0: PXA I2C adapter [ 7.282199] i2c i2c-1: using pinctrl states for GPIO recovery [ 7.288241] i2c i2c-1: PXA I2C adapter [ 7.292947] sfp sfp-eth1: Host maximum power 3.0W [ 7.299614] sfp sfp-eth0: Host maximum power 3.0W [ 7.308178] lm75 1-0048: supply vs not found, using dummy regulator [ 32.489631] lm75 1-0048: probe with driver lm75 failed with error -121 [ 32.496833] lm75 1-0049: supply vs not found, using dummy regulator [ 82.890614] lm75 1-0049: probe with driver lm75 failed with error -121 ... and accessing the plugged-in SFP modules also does not work: [ 511.298537] sfp sfp-eth1: please wait, module slow to respond [ 536.488530] sfp sfp-eth0: please wait, module slow to respond ... [ 1065.688536] sfp sfp-eth1: failed to read EEPROM: -EREMOTEIO [ 1090.888532] sfp sfp-eth0: failed to read EEPROM: -EREMOTEIO After a discussion [1], there was an attempt to fix the problem by reverting the offending change by commit 7b211c767121 ("Revert "i2c: pxa: move to generic GPIO recovery""), but that only helped to fix the issue in the 6.1.y stable tree. The reason behind the partial succes is that there was another change in commit 20cb3fce4d60 ("i2c: Set i2c pinctrl recovery info from it's device pinctrl") in the 6.3-rc1 cycle which broke things further. The cause of the problem is the same in case of both offending commits mentioned above. Namely, the I2C core code changes the pinctrl state to GPIO while running the recovery initialization code. Although the PXA specific initialization also does this, but the key difference is that it happens before the controller is getting enabled in i2c_pxa_reset(), whereas in the case of the generic initialization it happens after that. Change the code to reset the controller only before the first transfer instead of before registering the controller. This ensures that the controller is not enabled at the time when the generic recovery code performs the pinctrl state changes, thus avoids the problem described above. As the result this change restores the original behaviour, which in turn makes the I2C communication to work again as it can be seen from the following log: [ 7.363250] i2c i2c-0: using pinctrl states for GPIO recovery [ 7.369041] i2c i2c-0: PXA I2C adapter [ 7.373673] i2c i2c-1: using pinctrl states for GPIO recovery [ 7.379742] i2c i2c-1: PXA I2C adapter [ 7.384506] sfp sfp-eth1: Host maximum power 3.0W [ 7.393013] sfp sfp-eth0: Host maximum power 3.0W [ 7.399266] lm75 1-0048: supply vs not found, using dummy regulator [ 7.407257] hwmon hwmon0: temp1_input not attached to any thermal zone [ 7.413863] lm75 1-0048: hwmon0: sensor 'tmp75c' [ 7.418746] lm75 1-0049: supply vs not found, using dummy regulator [ 7.426371] hwmon hwmon1: temp1_input not attached to any thermal zone [ 7.432972] lm75 1-0049: hwmon1: sensor 'tmp75c' [ 7.755092] sfp sfp-eth1: module MENTECHOPTO POS22-LDCC-KR rev= 1.0 sn MNC208U90009 dc 200828 [ 7.764997] mvneta d0040000.ethernet eth1: unsupported SFP module: no = common interface modes [ 7.785362] sfp sfp-eth0: module Mikrotik S-RJ01 rev= 1.0 sn 61B103C55C58 dc 201022 [ 7.803426] hwmon hwmon2: temp1_input not attached to any thermal zone Link: https://lore.kernel.org/r/20230926160255.330417-1-robert.marko@sartur= a.hr #1 Cc: stable@vger.kernel.org # 6.3+ Fixes: 20cb3fce4d60 ("i2c: Set i2c pinctrl recovery info from it's device p= inctrl") Tested-by: Robert Marko Signed-off-by: Gabor Juhos Reviewed-by: Linus Walleij --- Changes in v4: - rebase on tip of i2c/i2c-host-fixes - add Tested-by tag from Robert - Link to v3: https://lore.kernel.org/r/20250827-i2c-pxa-fix-i2c-communic= ation-v3-1-052c9b1966a2@gmail.com Changes in v3: - rebase on tip of i2c/for-current - rework the patch and use a different approach which does not requires modification in the I2C core code and update commit description acccordingly - remove Imre's SoB tag, it should have been a Reviewed-by tag, but due to the rework this is an entirely different patch so that does not apply anyway - use Link tag for the URL of the referenced LKML thread - Link to v2: https://lore.kernel.org/r/20250811-i2c-pxa-fix-i2c-communic= ation-v2-2-ca42ea818dc9@gmail.com Changes in v2: - rebase and retest on tip of i2c/for-current - Link to v1: https://lore.kernel.org/r/20250511-i2c-pxa-fix-i2c-communic= ation-v1-2-e9097d09a015@gmail.com --- drivers/i2c/busses/i2c-pxa.c | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c index 09af3b3625f1107d2722cb026e67b69b07cca2e3..f55840b2eb9ab70aad43bd7f4f4= 4c39aa4d9c67f 100644 --- a/drivers/i2c/busses/i2c-pxa.c +++ b/drivers/i2c/busses/i2c-pxa.c @@ -268,6 +268,7 @@ struct pxa_i2c { struct pinctrl *pinctrl; struct pinctrl_state *pinctrl_default; struct pinctrl_state *pinctrl_recovery; + bool reset_before_xfer; }; =20 #define _IBMR(i2c) ((i2c)->reg_ibmr) @@ -1144,6 +1145,11 @@ static int i2c_pxa_xfer(struct i2c_adapter *adap, { struct pxa_i2c *i2c =3D adap->algo_data; =20 + if (i2c->reset_before_xfer) { + i2c_pxa_reset(i2c); + i2c->reset_before_xfer =3D false; + } + return i2c_pxa_internal_xfer(i2c, msgs, num, i2c_pxa_do_xfer); } =20 @@ -1521,7 +1527,16 @@ static int i2c_pxa_probe(struct platform_device *dev) } } =20 - i2c_pxa_reset(i2c); + /* + * Skip reset on Armada 3700 when recovery is used to avoid + * controller hang due to the pinctrl state changes done by + * the generic recovery initialization code. The reset will + * be performed later, prior to the first transfer. + */ + if (i2c_type =3D=3D REGS_A3700 && i2c->adap.bus_recovery_info) + i2c->reset_before_xfer =3D true; + else + i2c_pxa_reset(i2c); =20 ret =3D i2c_add_numbered_adapter(&i2c->adap); if (ret < 0) --=20 2.53.0 From nobody Mon Apr 6 09:12:36 2026 Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F2CC431A561 for ; Thu, 26 Feb 2026 13:11:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.51 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772111505; cv=none; b=r1vIX8hkNCDPqs/dkRrw9Mcl19oo7yROHKpK9snWPVQLXAXku+H1hIhWaHEipp1pcaX8tvWrakdbxIP/CZe2ejGFDNB97DF16ERCTfXKKsRoO/I9RQ/XAmodJrlQ2/KTeVqtNaFan0hc0dQzO+eNYLwIEOIQQHILGvXdhoZwJx0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772111505; c=relaxed/simple; bh=8emF7QR2KVdwdMj2Ew+1DoEgtt+qnkW+kxvqAJh6kbw=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=NxOW7qzNSyLlC8Q6YuOmC7iVPNhgteSschAw6CToFUG+vd+ZPHURmez7gt5sUsgeDWlK2jMInzDQmWZnN+ZuSMeRe2XIJHS6ECC27TOrXYwlL1Ut2KI4d+G9l4KQCfjACDqj/HKnhCiOjKArUoZJaMvqSVBbNwHF35HQzhkSUds= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=TpQOJgP4; arc=none smtp.client-ip=209.85.128.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="TpQOJgP4" Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-4806cc07ce7so10070695e9.1 for ; Thu, 26 Feb 2026 05:11:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772111500; x=1772716300; darn=vger.kernel.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to; bh=vgeR7jOGELUtY0ZmhFwjtCwPGAZoEdq03U4EngMFDbI=; b=TpQOJgP4w9njPDeRCGoDmhq9cKIUK8X8xhHjn3nNHxbhAtn61I6akHGaCBnlDtnfNP xwDar559EX3aZ2F8jWD70Ua48ZTk0YertT2X7ubCu2ARqjOfR1JTxKUBuWc78bkOEGcN DHdWPf3hSBo80RRD8c/wZtmu2bC6VugXLzkZsQWvvTsTRiw8Vjsp37qG6CzbExwZm1xw bJMylHqPtqhMfrBtSEIvmcier6GKewlPecDaZ4Dh4vorSHz2683lZzoxiEKgZsMqfQO/ iazpDzZjXS5C+1sHUE/ELvhWjMNhE2DKHhWIo8jewBxkWck3C3C+cQGB6yA924OTEyzN b0eA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772111500; x=1772716300; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=vgeR7jOGELUtY0ZmhFwjtCwPGAZoEdq03U4EngMFDbI=; b=AvYFVZvW2x+/DdFz/tIF8rcbBGIZr17TUdEiJLPZKqHhXSsG8T4VMxYlpVKgTje0+m r7SaWVjS+xqIN+SJvHlj6jYH1tqLbZgHveMJbczoMh+S5ee8QdjZenaDsV8/U41/8Ufv /oX9SifXfLFfryQZgn3vZilYnl2nVIaMhHhl4G5iAVsn7UqjjVwGTQTphpXWlwzIJaGR cZb3wpppAa6MhGKtisRSqbBP+Q5QPUhiZd2hbQ0VsiRZyz/gAfTOlqIHUJiPCbc42BIj Yc9Pq4kB0SYzObTz/u14b80KZ9Z0aHArMw7LiGHjPRJlhSA20ij2pVmoMP5xerqbg/xF LN4g== X-Forwarded-Encrypted: i=1; AJvYcCViJ5MFybTHmfvjm/QO64COr2NGvG95er8z/dmJAVm0/fluRje3JSwoDWr0zlXgK1AuDqQACikd6QlqIEI=@vger.kernel.org X-Gm-Message-State: AOJu0YxXEdpfE3GqqVe/GzRqBTvYbVfELiG6OIFzEY3gTM/VPURDtBCC GW7V+DIR43DHIBf+RjoMAr5gAsOXMS4IjoFLSEFdyMdbMsDXeCDr8tk3 X-Gm-Gg: ATEYQzyotarLK7Dfc4iPORBeT1yD21Ma7nesSb5NAnQ1zwzz0pUcvYP3cuHBWbg5hpl PPKXM1FBoJe+H6Zfi1ok5gz3AvbUkibCrHwQ2RSdJT99xFjnZvScSc/tJahwsq6oiLwqE4UqR8Y LJ8JvmHrmnl6Lvb3+vFEEycd9hjPahuc81n9VAB7wrDantCpzoE+aG04OYOfiO4LO/EUpYb2ybi aloe7vxZk/Ef2mxRy/Y0Bo7GIA6B6eC2d4FA0fG/Gi9oqrJiNrSshDj0ke/HmmQJ9QVLYjhC8uQ B0gfA35DNcA9ge1tBEoQ5DRdDrRSV4LItUqx6+nrQKpOlXvmE1ctkUsT3aJg8/gqTZFnpxOsKXh 0FOJkSpnVXOLu7Pu8225NU4BdNLReNMaZCU+VScjwQ1tyDUiu9Uz6OCbASAigeXBYY5030Gj3vt waL2++8fCj8hjcvpj0V+V7jSb34wh9SQJgIZvdj7kUHj+yBALyxTgV X-Received: by 2002:a05:600c:8211:b0:477:76bf:e1fb with SMTP id 5b1f17b1804b1-483c3de3dd6mr38027625e9.16.1772111500174; Thu, 26 Feb 2026 05:11:40 -0800 (PST) Received: from [192.168.0.253] (5D59A51C.catv.pool.telekom.hu. [93.89.165.28]) by smtp.googlemail.com with ESMTPSA id 5b1f17b1804b1-483bfb789efsm64827145e9.2.2026.02.26.05.11.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Feb 2026 05:11:38 -0800 (PST) From: Gabor Juhos Date: Thu, 26 Feb 2026 14:11:28 +0100 Subject: [PATCH v4 2/2] i2c: pxa: handle 'Early Bus Busy' condition on Armada 3700 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: <20260226-i2c-pxa-fix-i2c-communication-v4-2-797a091dae87@gmail.com> References: <20260226-i2c-pxa-fix-i2c-communication-v4-0-797a091dae87@gmail.com> In-Reply-To: <20260226-i2c-pxa-fix-i2c-communication-v4-0-797a091dae87@gmail.com> To: Andi Shyti , Wolfram Sang , Wolfram Sang , Andy Shevchenko , Russell King , Andrew Lunn , Hanna Hawa Cc: Robert Marko , linux-i2c@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Gabor Juhos , Linus Walleij , stable@vger.kernel.org, Imre Kaloz X-Mailer: b4 0.14.2 Under some circumstances I2C recovery fails on Armada 3700. At least on the Methode uDPU board, removing and replugging an SFP module fails often, like this: [ 36.953127] sfp sfp-eth1: module removed [ 38.468549] i2c i2c-1: i2c_pxa: timeout waiting for bus free [ 38.486960] sfp sfp-eth1: module MENTECHOPTO POS22-LDCC-KR rev= 1.0 sn MNC208U90009 dc 200828 [ 38.496867] mvneta d0040000.ethernet eth1: unsupported SFP module: no = common interface modes [ 38.521448] hwmon hwmon2: temp1_input not attached to any thermal zone [ 39.249196] sfp sfp-eth1: module removed ... [ 292.568799] sfp sfp-eth1: please wait, module slow to respond ... [ 625.208814] sfp sfp-eth1: failed to read EEPROM: -EREMOTEIO Note that the 'unsupported SFP module' messages are not relevant. The module is used only for testing the I2C recovery funcionality, because the error can be triggered easily with this specific one. Enabling debug in the i2c-pxa driver reveals the following: [ 82.034678] sfp sfp-eth1: module removed [ 90.008654] i2c i2c-1: slave_0x50 error: timeout with active message [ 90.015112] i2c i2c-1: msg_num: 2 msg_idx: 0 msg_ptr: 0 [ 90.020464] i2c i2c-1: IBMR: 00000003 IDBR: 000000a0 ICR: 000007e0 ISR= : 00000802 [ 90.027906] i2c i2c-1: log: [ 90.030787] This continues until the retries are exhausted ... [ 110.192489] i2c i2c-1: slave_0x50 error: exhausted retries [ 110.198012] i2c i2c-1: msg_num: 2 msg_idx: 0 msg_ptr: 0 [ 110.203323] i2c i2c-1: IBMR: 00000003 IDBR: 000000a0 ICR: 000007e0 ISR= : 00000802 [ 110.210810] i2c i2c-1: log: [ 110.213633] ... then the whole sequence starts again ... [ 115.368641] i2c i2c-1: slave_0x50 error: timeout with active message ... while finally the SFP core gives up: [ 671.975258] sfp sfp-eth1: failed to read EEPROM: -EREMOTEIO When we analyze the log, it can be seen that bit 1 and 11 is set in the ISR (Interface Status Register). Bit 1 indicates the ACK/NACK status, but the purpose of bit 11 is not documented in the driver code unfortunately. The 'Functional Specification' document of the Armada 3700 SoCs family however says that this bit indicates an 'Early Bus Busy' condition. The document also notes that whenever this bit is set, it is not possible to initiate a transaction on the I2C bus. The observed behaviour corresponds to this statement. Unfortunately, I2C recovery does not help as it never runs in this special case. Although the driver checks the busyness of the bus at several places, but since it does not consider the A3700 specific bit in these checks it can't determine the actual status of the bus correctly which results in the errors above. In order to fix the problem, add a new member to struct 'i2c_pxa' to store a controller specific bitmask containing the bits indicating the busy status, and use that in the code while checking the actual status of the bus. This ensures that the correct status can be determined on the Armada 3700 based devices without causing functional changes on devices based on other SoCs. With the change applied, the driver detects the busy condition, and runs the recovery process: [ 742.617312] i2c i2c-1: state:i2c_pxa_wait_bus_not_busy:449: ISR=3D0000= 0802, ICR=3D000007e0, IBMR=3D03 [ 742.626099] i2c i2c-1: i2c_pxa: timeout waiting for bus free [ 742.631933] i2c i2c-1: recovery: resetting controller, ISR=3D0x00000802 [ 742.638421] i2c i2c-1: recovery: IBMR 0x00000003 ISR 0x00000000 This clears the EBB bit in the ISR register, so it makes it possible to initiate transactions on the I2C bus again. After this patch, the SFP module used for testing can be removed and replugged numerous times without causing the error described at the beginning. Previously, the error happened after a few such attempts. The patch has been tested also with the following kernel versions: 5.10.251, 5.15.201, 6.1.164, 6.6.127, 6.12.74, 6.14.11, 6.15.10, 6.16.1, 6.18.13, 6.19.3 It improves recovery on all of them. Cc: stable@vger.kernel.org # 5.10+ Reviewed-by: Imre Kaloz Tested-by: Robert Marko Signed-off-by: Gabor Juhos Reviewed-by: Linus Walleij --- Changes in v4: - rebase on tip of i2c/i2c-host-fixes - add Tested-by tag from Robert - update list of tested kernels - Link to v3: https://lore.kernel.org/r/20250827-i2c-pxa-fix-i2c-communic= ation-v3-2-052c9b1966a2@gmail.com Changes in v3: - rebase on tip of i2c/for-current - use Reviewed-by tag for Imre - remove Fixes tag as the problem is not caused by the previously mention= ed commit, simply it is not handled by the code yet - update list of tested kernels - Link to v2: https://lore.kernel.org/r/20250811-i2c-pxa-fix-i2c-communic= ation-v2-3-ca42ea818dc9@gmail.com Changes in v2: - rebase and retest on tip of i2c/for-current - Link to v1: https://lore.kernel.org/r/20250511-i2c-pxa-fix-i2c-communic= ation-v1-3-e9097d09a015@gmail.com --- drivers/i2c/busses/i2c-pxa.c | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c index f55840b2eb9ab70aad43bd7f4f44c39aa4d9c67f..9a8b154ab69e1b934b82a4e68a9= 7a2dce3673408 100644 --- a/drivers/i2c/busses/i2c-pxa.c +++ b/drivers/i2c/busses/i2c-pxa.c @@ -71,6 +71,7 @@ #define ISR_GCAD (1 << 8) /* general call address detected */ #define ISR_SAD (1 << 9) /* slave address detected */ #define ISR_BED (1 << 10) /* bus error no ACK/NAK */ +#define ISR_A3700_EBB (1 << 11) /* early bus busy for armada 3700 */ =20 #define ILCR_SLV_SHIFT 0 #define ILCR_SLV_MASK (0x1FF << ILCR_SLV_SHIFT) @@ -263,6 +264,7 @@ struct pxa_i2c { bool highmode_enter; u32 fm_mask; u32 hs_mask; + u32 busy_mask; =20 struct i2c_bus_recovery_info recovery; struct pinctrl *pinctrl; @@ -430,7 +432,7 @@ static int i2c_pxa_wait_bus_not_busy(struct pxa_i2c *i2= c) =20 while (1) { isr =3D readl(_ISR(i2c)); - if (!(isr & (ISR_IBB | ISR_UB))) + if (!(isr & i2c->busy_mask)) return 0; =20 if (isr & ISR_SAD) @@ -467,7 +469,7 @@ static int i2c_pxa_wait_master(struct pxa_i2c *i2c) * quick check of the i2c lines themselves to ensure they've * gone high... */ - if ((readl(_ISR(i2c)) & (ISR_UB | ISR_IBB)) =3D=3D 0 && + if ((readl(_ISR(i2c)) & i2c->busy_mask) =3D=3D 0 && readl(_IBMR(i2c)) =3D=3D (IBMR_SCLS | IBMR_SDAS)) { if (i2c_debug > 0) dev_dbg(&i2c->adap.dev, "%s: done\n", __func__); @@ -488,7 +490,7 @@ static int i2c_pxa_set_master(struct pxa_i2c *i2c) if (i2c_debug) dev_dbg(&i2c->adap.dev, "setting to bus master\n"); =20 - if ((readl(_ISR(i2c)) & (ISR_UB | ISR_IBB)) !=3D 0) { + if ((readl(_ISR(i2c)) & i2c->busy_mask) !=3D 0) { dev_dbg(&i2c->adap.dev, "%s: unit is busy\n", __func__); if (!i2c_pxa_wait_master(i2c)) { dev_dbg(&i2c->adap.dev, "%s: error: unit busy\n", __func__); @@ -514,7 +516,7 @@ static int i2c_pxa_wait_slave(struct pxa_i2c *i2c) dev_dbg(&i2c->adap.dev, "%s: %ld: ISR=3D%08x, ICR=3D%08x, IBMR=3D%02x\n= ", __func__, (long)jiffies, readl(_ISR(i2c)), readl(_ICR(i2c)), readl(_IB= MR(i2c))); =20 - if ((readl(_ISR(i2c)) & (ISR_UB|ISR_IBB)) =3D=3D 0 || + if ((readl(_ISR(i2c)) & i2c->busy_mask) =3D=3D 0 || (readl(_ISR(i2c)) & ISR_SAD) !=3D 0 || (readl(_ICR(i2c)) & ICR_SCLE) =3D=3D 0) { if (i2c_debug > 1) @@ -1177,7 +1179,7 @@ static int i2c_pxa_pio_set_master(struct pxa_i2c *i2c) /* * Wait for the bus to become free. */ - while (timeout-- && readl(_ISR(i2c)) & (ISR_IBB | ISR_UB)) + while (timeout-- && readl(_ISR(i2c)) & i2c->busy_mask) udelay(1000); =20 if (timeout < 0) { @@ -1322,7 +1324,7 @@ static void i2c_pxa_unprepare_recovery(struct i2c_ada= pter *adap) * handing control of the bus back to avoid the bus changing state. */ isr =3D readl(_ISR(i2c)); - if (isr & (ISR_UB | ISR_IBB)) { + if (isr & i2c->busy_mask) { dev_dbg(&i2c->adap.dev, "recovery: resetting controller, ISR=3D0x%08x\n", isr); i2c_pxa_do_reset(i2c); @@ -1479,6 +1481,10 @@ static int i2c_pxa_probe(struct platform_device *dev) i2c->fm_mask =3D pxa_reg_layout[i2c_type].fm; i2c->hs_mask =3D pxa_reg_layout[i2c_type].hs; =20 + i2c->busy_mask =3D ISR_UB | ISR_IBB; + if (i2c_type =3D=3D REGS_A3700) + i2c->busy_mask |=3D ISR_A3700_EBB; + if (i2c_type !=3D REGS_CE4100) i2c->reg_isar =3D i2c->reg_base + pxa_reg_layout[i2c_type].isar; =20 --=20 2.53.0