Re: [PATCH net-next v3 4/9] net: dsa: realtek: rtl8365mb: set RGMII mode for family D

[netdev-bot+sashiko@kernel.org]

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.

> 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

[ ... ]

> @@ -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.

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