From: Stanislaw Pal <kuncy7@gmail.com>
To: "Linus Walleij" <linus.walleij@linaro.org>,
"Alvin Šipraga" <alsi@bang-olufsen.dk>,
"Andrew Lunn" <andrew@lunn.ch>,
"Vladimir Oltean" <olteanv@gmail.com>,
"David S . Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@google.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Stanislaw Pal <kuncy7@gmail.com>
Subject: [PATCH net v2] net: dsa: realtek: rtl8365mb: wait out the full chip reset time
Date: Tue, 8 Sep 2026 19:44:03 +0200 [thread overview]
Message-ID: <20260908174403.420507-1-kuncy7@gmail.com> (raw)
The reset bit clears well before the RTL8365MB/RTL8367S has finished its
internal bring-up, so configuring it right away makes register writes to
blocks that are not up yet get lost. The switch is then left half
configured: the CPU port link comes up and the switch still transmits
towards the CPU, but nothing the CPU sends is ever forwarded - no MIB TX
counter moves on any user port, while the MAC reports every frame as
transmitted without errors.
The driver already documents the 1 s reset time the chip needs and polls
with a 1 s timeout, but stops waiting as soon as the bit clears. Sleep
out the remainder of that second instead, measured from the reset write,
so the total wait stays at 1 s regardless of how long the poll took.
Seen on a TP-Link Archer AX55 v1 (IPQ5018 + RTL8367S, 2.5G HSGMII trunk)
on roughly three out of four boots. Unbinding and rebinding the driver
always fixed it at runtime. With this patch: 6 out of 6 clean boots.
Fixes: 4af2950c50c8 ("net: dsa: realtek-smi: add rtl8365mb subdriver for RTL8365MB-VC")
Signed-off-by: Stanislaw Pal <kuncy7@gmail.com>
---
Changes in v2:
- Declare "remaining" as long instead of unsigned long and drop the cast
from the comparison, so the sign is carried by the type (Andrew Lunn).
- Name the affected parts in the opening sentence instead of "the chip".
- Link to v1: https://lore.kernel.org/all/20260907191940.806734-1-kuncy7@gmail.com/
---
--- a/drivers/net/dsa/realtek/rtl8365mb_main.c
+++ b/drivers/net/dsa/realtek/rtl8365mb_main.c
@@ -136,6 +136,9 @@
#define RTL8365MB_CHIP_RESET_SW_MASK 0x0002
#define RTL8365MB_CHIP_RESET_HW_MASK 0x0001
+/* Time the chip needs to complete a reset, per Realtek documentation */
+#define RTL8365MB_CHIP_RESET_TIME_MS 1000
+
/* Interrupt polarity register */
#define RTL8365MB_INTR_POLARITY_REG 0x1100
#define RTL8365MB_INTR_POLARITY_MASK 0x0001
@@ -2980,18 +2983,38 @@
static int rtl8365mb_reset_chip(struct realtek_priv *priv)
{
+ unsigned long deadline;
+ long remaining;
u32 val;
+ int ret;
priv->write_reg_noack(priv, RTL8365MB_CHIP_RESET_REG,
FIELD_PREP(RTL8365MB_CHIP_RESET_HW_MASK, 1));
+ deadline = jiffies + msecs_to_jiffies(RTL8365MB_CHIP_RESET_TIME_MS);
+
/* Realtek documentation says the chip needs 1 second to reset. Sleep
* for 100 ms before accessing any registers to prevent ACK timeouts.
*/
msleep(100);
- return regmap_read_poll_timeout(priv->map, RTL8365MB_CHIP_RESET_REG, val,
- !(val & RTL8365MB_CHIP_RESET_HW_MASK),
- 20000, 1e6);
+ ret = regmap_read_poll_timeout(priv->map, RTL8365MB_CHIP_RESET_REG, val,
+ !(val & RTL8365MB_CHIP_RESET_HW_MASK),
+ 20000, 1e6);
+ if (ret)
+ return ret;
+
+ /* The bit clearing only means the reset was accepted, not that the
+ * chip is ready: register writes issued before the documented reset
+ * time has elapsed are silently dropped by blocks that are still
+ * coming up, which leaves the switch half configured. Wait out
+ * whatever is left of that second, measured from the reset write, so
+ * the poll above does not add to the total.
+ */
+ remaining = (long)(deadline - jiffies);
+ if (remaining > 0)
+ msleep(jiffies_to_msecs(remaining));
+
+ return 0;
}
static int rtl8365mb_setup(struct dsa_switch *ds)
next reply other threads:[~2026-09-08 17:44 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-08 17:44 Stanislaw Pal [this message]
2026-09-08 20:35 ` [PATCH net v2] net: dsa: realtek: rtl8365mb: wait out the full chip reset time Linus Walleij
2026-09-08 21:36 ` Luiz Angelo Daros de Luca
2026-09-09 10:13 ` Stanislaw Pal
2026-09-09 11:31 ` Alvin Šipraga
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260908174403.420507-1-kuncy7@gmail.com \
--to=kuncy7@gmail.com \
--cc=alsi@bang-olufsen.dk \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.