Re: [PATCH net-next v6 3/3] net: stmmac: sun8i: add support for Allwinner H616 EMAC1

[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 new H616 EMAC1 variant (`emac_variant_h616_emac1` in
  drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c) is meant to be…

--

net: stmmac: sun8i: add support for Allwinner H616 EMAC1

This adds an emac_variant for the H616 secondary EMAC. The variant uses a
dedicated syscon register at 0x34 and is described as RMII-only at 10/100
Mbps. It is wired internally to the co-packaged AC200/AC300 EPHY.

> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
> index 5691da796454d..47954537b29e4 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c

[ ... ]

> @@ -143,6 +150,13 @@ static const struct emac_variant emac_variant_h6 = {
>  	.tx_delay_max = 7,
>  };
>  
> +static const struct emac_variant emac_variant_h616_emac1 = {
> +	.syscon_field = &sun8i_syscon_reg_field_emac1,
> +	/* The co-packaged AC200/AC300 PHY does not use the H3 PHY controls. */
> +	.soc_has_internal_phy = false,
> +	.support_rmii = true,
> +};

[Severity: Low]
Does anything actually restrict this variant to RMII?

The only place support_mii, support_rmii and support_rgmii appear is in
dwmac-sun8i.c: the kernel-doc, the struct emac_variant definition and the
variant initializers. Nothing reads them.

sun8i_dwmac_set_syscon() picks the register value from plat->phy_interface
and does it the same way for every variant:

drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c:sun8i_dwmac_set_syscon() {
    ...
	switch (plat->phy_interface) {
	case PHY_INTERFACE_MODE_MII:
		/* default */
		break;
	case PHY_INTERFACE_MODE_RGMII:
	case PHY_INTERFACE_MODE_RGMII_ID:
	case PHY_INTERFACE_MODE_RGMII_RXID:
	case PHY_INTERFACE_MODE_RGMII_TXID:
		reg |= SYSCON_EPIT | SYSCON_ETCS_INT_GMII;
		break;
	case PHY_INTERFACE_MODE_RMII:
		reg |= SYSCON_RMII_EN | SYSCON_ETCS_EXT_GMII;
		break;
    ...
	regmap_field_write(gmac->regmap_field, reg);
    ...
}

Suppose a DT node with "allwinner,sun50i-h616-emac1" sets phy-mode to "mii"
or "rgmii*". Probe would still succeed, and a value without SYSCON_RMII_EN
would be written to the new register at 0x34. This MAC has no external pins.

dwmac-sun8i has no get_interfaces callback, so stmmac_phylink_setup() adds
the DT-supplied mode to supported_interfaces as is:

	if (phy_interface_empty(config->supported_interfaces))
		__set_bit(priv->plat->phy_interface,
			  config->supported_interfaces);

sun8i_dwmac_setup() also always advertises MAC_10 | MAC_100 | MAC_1000 in
mac->link.caps. With a non-RMII phy-mode, phylink could then allow gigabit
on a 10/100-only MAC.

The commit message says:

    Add an EMAC1 variant using the dedicated register and enable only RMII.

There is also no in-tree binding for "allwinner,sun50i-h616-emac1" yet. As
far as I can tell, only a correct DT enforces the RMII-only restriction.

Older variants such as emac_variant_v3s have the same unchecked flags, but
this new variant's RMII-only behaviour depends on them. Would it make sense
to reject unsupported phy_interface values in sun8i_dwmac_set_syscon() or at
probe? Another option is a get_interfaces callback built from the support_*
flags. If neither fits, the commit message could say the restriction comes
only from the DT.

[ ... ]

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260927-submit-h616-emac1-v1-v6-0-e64971f4e414%40gmail.com