Re: [PATCH net-next v3 4/9] net: dsa: realtek: rtl8365mb: set RGMII mode for family D
flat view
From: netdev-bot+sashiko@kernel.org
Date: 2026-10-11 19:51:25
Also in:
lkml
Thank you for your contribution! Sashiko AI review found more severe issue(s) in other patches of this series. This mail is only an FYI, in case you want to address the nit picks below when you respin. Low priority / nit picks for your consideration: - [Low] The concern says the family-D branch in rtl8365mb_ext_config_rgmii() can never run because no… -- net: dsa: realtek: rtl8365mb: set RGMII mode for family D This commit adds family D specific RGMII setup for extension interface 1 in rtl8365mb_ext_config_rgmii(). It clears the EXT1 RGMII TX clock delay field in EXT_TXC_DLY and binds the RGMII/MII pin mux to MAC7 when MAC4 is not using extension 1. It also disables SerDes 1, which shares those pins.
quoted hunk ↗ jump to hunk
diff --git a/drivers/net/dsa/realtek/rtl8365mb_main.c b/drivers/net/dsa/realtek/rtl8365mb_main.c index 8f3295c232362..c15b88ba7bb5c 100644 --- a/drivers/net/dsa/realtek/rtl8365mb_main.c +++ b/drivers/net/dsa/realtek/rtl8365mb_main.c
[ ... ]
quoted hunk ↗ jump to hunk
@@ -1263,6 +1284,35 @@ static int rtl8365mb_ext_config_rgmii(struct realtek_priv *priv, int port, if (ret) return ret; + if (rtl8365mb_get_family(priv) == RTL8365MB_FAMILY_D && + extint->id == 1) {
[Severity: Low]
This isn't a bug, but can this branch in rtl8365mb_ext_config_rgmii()
run at this point in the series?
At this commit, no rtl8365mb_chip_infos[] entry seems to use
RTL8365MB_FAMILY_D, so the new block looks like dead code for now. The DT
binding in Documentation/devicetree/bindings/net/dsa/realtek.yaml already
lists RTL8367S-VB (0x6642), which puts the binding a little ahead of the
driver while bisecting.
The later patch "net: dsa: realtek: rtl8365mb: add support for
RTL8367S-VB" adds the entry:
.name = "RTL8367S-VB",
.chip_id = 0x6642,
.chip_ver = 0x0010,
.family = RTL8365MB_FAMILY_D,
That makes this branch reachable and brings the binding and the chip table
back in line. At the intermediate commits, an RTL8367S-VB device tree just
fails chip ID matching, the same as before the series. So I don't see a
runtime regression here, only an ordering detail in the series.
quoted hunk ↗ jump to hunk
+ ret = regmap_update_bits(priv->map, + RTL8365MB_D_REG_EXT_TXC_DLY, + RTL8365MB_D_EXT1_RGMII_TX_DLY_MASK, 0); + if (ret) + return ret;
[ ... ] -- Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/e84d76ee-03df-49b0-8c9a-b289dfae8728%40yahoo.com