RE: [PATCH net v2] r8152: Use BMSR to detect the link state

[Hayes Wang <hayeswang@realtek.com>]

Andrew Lunn <andrew@lunn.ch>
> Sent: Friday, October 9, 2026 8:22 PM
> To: Linmao Li <lilinmao@kylinos.cn>
> Cc: Hayes Wang <hayeswang@realtek.com>; Andrew Lunn
> <andrew+netdev@lunn.ch>; David S . Miller <davem@davemloft.net>; Eric
> Dumazet <edumazet@kernel.org>; Jakub Kicinski <kuba@kernel.org>; Paolo
> Abeni <pabeni@redhat.com>; Chih Kai Hsu <hsu.chih.kai@realtek.com>;
> nic_swsd <nic_swsd@realtek.com>; Birger Koblitz <mail@birger-koblitz.de>;
> Xiangqian Zhang <zhangxiangqian@kylinos.cn>; linux-usb@vger.kernel.org;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org; stable@vger.kernel.org
> Subject: Re: [PATCH net v2] r8152: Use BMSR to detect the link state
> 
> 
> External mail : This email originated from outside the organization. Do not
> reply, click links, or open attachments unless you recognize the sender and
> know the content is safe.
> 
> 
> 
> > Hi Hayes, Andrew,
> >
> > Thanks. Since the newer ICs notify only when the link status changes,
> > the driver cannot rely on another link up notification after the link
> > has settled, so v2 can leave the carrier off when the first read
> > returns the latched link down.
> >
> > Before sending v3, which approach would you prefer? Both fixed the
> > problem in my tests on an RTL8153B with v7.3-rc6:
> >
> > a) Keep carrier detection on PLA_PHYSTATUS and read BMSR once before
> >    carrier on, only to clear the latch. This is the option I asked
> >    about on v1.
> >
> > b) Detect carrier from BMSR and read it again when the first read
> >    returns link down, as genphy_update_link() does in interrupt mode.
> >
> > Neither depends on another notification. Neither reports a short link
> > drop that recovers before the link work runs: with a) a later speed
> > query still sees the latched link down, with b) the latch is cleared.
> >
> > Hayes, for b): is BMSR_LSTATUS reliable as the carrier source on all
> > chips supported by r8152?
> 
> Ideally we want a list of devices which correctly do notification on every
> change of link state, and which are broken.

I think all of our ICs have the same situation.

> For those that work, read the BMSR once and report the down, and then later
> on the second event, report the up.
> 
> For those devices which are broken, double read the BMSR.  The danger is,
> somebody who quickly unplugs and replugs the cable is not going to get the
> down notification. The dhcp client will not restart, so the old IP address will be
> used, for the next hour to day, and the network is broken.

Could this actually happen? 
I think it would take several seconds for the link to go down and then come back up.
Wouldn't this issue occur only if the link transitions from up to down and back up before the driver processes the link-down event?


Best Regards,
Hayes