[<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