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

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

[Linmao Li]

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.

Tested on an RTL8153B with a 6.6-based kernel. Traces confirmed
LSTATUS=0 followed by LSTATUS=1 in the same query in 20 rebind runs.
NetworkManager reported 1000 Mb/s in all 10 managed-device runs.
With the cable unplugged or the PHY powered down, the speed is still
reported as unknown.

Fixes: f6f2e946aa4d ("net: mii: Fix the Speed display when the network cable is not connected")
Cc: stable@vger.kernel.org
Signed-off-by: Linmao Li <lilinmao@kylinos.cn>
---
Runtime testing used a 6.6-based kernel containing the change identified
by the Fixes tag. The tested drivers/net/mii.c is identical to the
patched version based on net/main.

 drivers/net/mii.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/mii.c b/drivers/net/mii.c
index 37bc3131d31a..bd4fdcb55df3 100644
--- a/drivers/net/mii.c
+++ b/drivers/net/mii.c
@@ -163,6 +163,8 @@ void mii_ethtool_get_link_ksettings(struct mii_if_info *mii,
 	advertising = ADVERTISED_TP | ADVERTISED_MII;
 
 	bmcr = mii->mdio_read(dev, mii->phy_id, MII_BMCR);
+	/* BMSR_LSTATUS is latched low, dummy read to get the current state */
+	mii->mdio_read(dev, mii->phy_id, MII_BMSR);
 	bmsr = mii->mdio_read(dev, mii->phy_id, MII_BMSR);
 	if (mii->supports_gmii) {
 		ctrl1000 = mii->mdio_read(dev, mii->phy_id, MII_CTRL1000);
-- 
2.25.1

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

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

    Andrew

---
pw-bot: cr

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

[Linmao Li]

在 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?

Thanks,
Linmao

>
>      Andrew
>
> ---
> pw-bot: cr

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

[Andrew Lunn]

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