[PATCH net-next 0/4] net: stmmac: Fix VLAN handling when interface is down

[Ovidiu Panait]

Hi Russell,

> On Mon, Feb 23, 2026 at 12:40:58PM +0000, Ovidiu Panait wrote:
> > VLAN register accesses on the MAC side require the PHY RX clock to be
> > active. When the network interface is down, the PHY is suspended and
> > the RX clock is unavailable, causing VLAN operations to fail with
> > timeouts.
> >
> > The VLAN core automatically removes VID 0 after the interface goes down
> > and re-adds it when it comes back up, so these timeouts happen during
> > normal interface down/up:
> >
> >     # ip link set end1 down
> >     renesas-gbeth 15c40000.ethernet end1: Timeout accessing
> MAC_VLAN_Tag_Filter
> >     renesas-gbeth 15c40000.ethernet end1: failed to kill vid 0081/0
> >
> > Adding VLANs while the interface is down also fails:
> >
> >     # ip link add link end1 name end1.10 type vlan id 10
> >     renesas-gbeth 15c40000.ethernet end1: Timeout accessing
> MAC_VLAN_Tag_Filter
> >     RTNETLINK answers: Device or resource busy
> >
> > Patches 3-4 address this by deferring hardware writes when the
> > interface is down and reconfiguring the VLAN state on interface up.
> >
> > Patches 1-2 fix some issues in the existing VLAN implementation.
> 
> First point to make is that when the netdev supports
> NETIF_F_VLAN_FEATURES, receive clock stop is disabled. In stmmac:
> 
>         /* Disable EEE RX clock stop to ensure VLAN register access works
>          * correctly.
>          */
>         if (!(priv->plat->flags & STMMAC_FLAG_RX_CLK_RUNS_IN_LPI) &&
>             !(priv->dev->features & NETIF_F_VLAN_FEATURES))
>                 config->eee_rx_clk_stop_enable = true;
> 
> in phylink:
> 
>         if (pl->mac_supports_eee_ops) {
>                 /* Explicitly configure whether the PHY is allowed to stop
> it's
>                  * receive clock.
>                  */
>                 ret = phy_eee_rx_clock_stop(phy,
>                                             pl->config-
> >eee_rx_clk_stop_enable);
> 
> and also in phylink's phylink_rx_clk_stop_block():
> 
>         /* Disable PHY receive clock stop if this is the first time this
>          * function has been called and clock-stop was previously enabled.
>          */
>         if (pl->mac_rx_clk_stop_blocked++ == 0 &&
>             pl->mac_supports_eee_ops && pl->phydev &&
>             pl->config->eee_rx_clk_stop_enable)
>                 phy_eee_rx_clock_stop(pl->phydev, false);
> 
> So, given that when stmmac supports VLAN, eee_rx_clk_stop_enable will be
> false, so phylink_rx_clk_stop_block() does nothing useful and receive
> clock stop at the PHY will be disabled.
> 

Thanks for pointing this out. I will drop the receive clock stop
block/unblock calls in the next version.

> 
> So a few questions:
> 
> 1) when the network interface is opened or resumed, a DMA reset is
> performed which resets all hardware state, including VLAN state. On
> resume, we call stmmac_restore_hw_vlan_rx_fltr(), but to me it looks
> like that is incomplete, and bits of the VLAN configuration don't get
> restored on resume. Please can you look at this and confirm whether
> this is indeed the problem.
> 

I checked and calling only stmmac_restore_hw_vlan_rx_fltr() on resume
is not enough, the VLAN hash table and the VLAN_TAG control bits are
not being restored. stmmac_restore_hw_vlan_rx_fltr() also reads the
VLAN_HASH_TABLE register, which is always zero, due to the previous
DMA reset.

> 2) If we can fully restore the VLAN configuration on resume, I suspect
> the driver will be doing the same work at resume as at open time, so
> this code should be shared.
> 

Yes, both resume and open need to restore the full VLAN state, so the same
code can be used for both paths.

I will prepare a new version for this series to include these changes.

Thanks!
Ovidiu

> Please can you look at both of these points.
> 
> Thanks.
> 
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!