lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20251120213805.4135-2-ptpt52@gmail.com>
Date: Fri, 21 Nov 2025 05:38:05 +0800
From: Chen Minqiang <ptpt52@...il.com>
To: Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Matthias Brugger <matthias.bgg@...il.com>,
	AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
	"Chester A. Unal" <chester.a.unal@...nc9.com>,
	Daniel Golle <daniel@...rotopia.org>,
	DENG Qingfang <dqfext@...il.com>,
	Sean Wang <sean.wang@...iatek.com>,
	Andrew Lunn <andrew@...n.ch>
Cc: linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	linux-mediatek@...ts.infradead.org,
	netdev@...r.kernel.org,
	Chen Minqiang <ptpt52@...il.com>
Subject: [PATCH v2 2/2] net: dsa: mt7530: fix active-low reset sequence

With GPIO_ACTIVE_LOW configured in DTS, gpiod_set_value(1) asserts reset
(drives the line low), and gpiod_set_value(0) deasserts reset (drives high).

Update the reset sequence so that the driver:
 - asserts reset by driving the GPIO low first
 - waits for the required reset interval
 - deasserts reset by driving it high

This ensures MT7531 receives a correct low-to-high reset pulse.

Compatibility notes:

The previous implementation contained a polarity mismatch: the DTS
described the reset line as active-high, while the driver asserted reset
by driving the GPIO low. The two mistakes matched each other, so the
reset sequence accidentally worked.

This patch fixes both sides: the DTS is corrected to use
GPIO_ACTIVE_LOW, and the driver now asserts reset by driving the line
low (value = 1 for active-low) and then deasserts it by driving it high
(value = 0).

Because the old behaviour relied on a matched pair of bugs, this change
is not compatible with mixed combinations of old DTS and new kernel, or
new DTS and old kernel. Both sides must be updated together.

Upstream DTS and upstream kernels will remain fully compatible after
this patch. Out-of-tree DT blobs must update their reset-gpios flags to
match the correct hardware polarity, or the switch may remain stuck in
reset or fail to reset properly.

There is no practical way to maintain compatibility with the previous
incorrect behaviour without adding non-detectable heuristics, so fixing
the binding and the driver together is the correct approach.

Signed-off-by: Chen Minqiang <ptpt52@...il.com>
---
 drivers/net/dsa/mt7530.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index 548b85befbf4..24c9adff191d 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -2405,9 +2405,9 @@ mt7530_setup(struct dsa_switch *ds)
 		usleep_range(5000, 5100);
 		reset_control_deassert(priv->rstc);
 	} else {
-		gpiod_set_value_cansleep(priv->reset, 0);
-		usleep_range(5000, 5100);
 		gpiod_set_value_cansleep(priv->reset, 1);
+		usleep_range(5000, 5100);
+		gpiod_set_value_cansleep(priv->reset, 0);
 	}
 
 	/* Waiting for MT7530 got to stable */
@@ -2643,9 +2643,9 @@ mt7531_setup(struct dsa_switch *ds)
 		usleep_range(5000, 5100);
 		reset_control_deassert(priv->rstc);
 	} else {
-		gpiod_set_value_cansleep(priv->reset, 0);
-		usleep_range(5000, 5100);
 		gpiod_set_value_cansleep(priv->reset, 1);
+		usleep_range(5000, 5100);
+		gpiod_set_value_cansleep(priv->reset, 0);
 	}
 
 	/* Waiting for MT7530 got to stable */
-- 
2.17.1


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ