Re: [PATCH net] net: mii: Fix unknown speed after link up

From: Andrew Lunn

Date: Thu Oct 01 2026 - 08:36:02 EST


On Thu, Oct 01, 2026 at 10:09:00AM +0800, Linmao Li wrote:
>
> 在 2026/10/1 5:47, Andrew Lunn 写道:
> > On Wed, Sep 30, 2026 at 07:38:42PM +0800, Linmao Li wrote:
> > > mii_ethtool_get_link_ksettings() reads BMSR only once. Since
> > > BMSR_LSTATUS is latched low, the first query after link up can
> > > report SPEED_UNKNOWN even though the link is already up.
> > >
> > > This is seen with r8152, which detects carrier using a MAC register
> > > without clearing the BMSR latch. NetworkManager can then keep
> > > reporting 0 Mb/s until the next carrier change.
> > >
> > > Read BMSR twice to obtain the current link status, as mii_link_ok()
> > > already does.
> > There is a reason for this latch behaviour, so you should not ignore
> > it. It ensures a link down is reported, even if it is for a short
> > period.
> >
> > I suggest you change the code to detect link based on BMSR, not a MAC
> > register. Better still, throw away all the mii code and port it to
> > phylink. A lot of code will go away because phylink/phylib and PHY
> > drivers will implement it.
> Hi Andrew,
>
> Thanks for the review.
>
> The existing read in mii_ethtool_get_link_ksettings() already clears
> the latch, but I understand your concern about preserving short
> link-down events.
>
> For a focused r8152 fix, would it be acceptable to read BMSR once
> before netif_carrier_on(), only when set_carrier() is transitioning
> from carrier off to on? This would retain the existing MAC-based
> carrier detection and clear the latched status before announcing
> link up.
>
> Or would you prefer changing carrier detection itself to use BMSR?
> Could a phylink conversion be handled separately?

I would prefer the carrier detection be based on BMSR. However, the
current code is based on interrupt URBs, and it is not clear if you
will get two interrupts. You need to test that first.

A phylink conversion can be separate.

Andrew