From: Hayes Wang <hayeswang@realtek.com>
To: Linmao Li <lilinmao@kylinos.cn>, Andrew Lunn <andrew@lunn.ch>
Cc: 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" <linux-usb@vger.kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: RE: [PATCH net v2] r8152: Use BMSR to detect the link state
Date: Tue, 13 Oct 2026 07:37:42 +0000 [thread overview]
Message-ID: <ea950637b76b4f43b3031a040d1e5fec@realtek.com> (raw)
In-Reply-To: <2bd3886a-da6e-4703-bd7a-9baa32bfd2f4@kylinos.cn>
Linmao Li <lilinmao@kylinos.cn>
> Sent: Friday, October 9, 2026 3:16 PM
[...]
> 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.
I prefer option a). Using PLA_PHYSTATUS for carrier detection is the approach
recommended by our hardware engineers, and we have tested and verified it.
> 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?
I’m not familiar with this part, so I need to confirm it with our PHY engineers.
Best Regards,
Hayes
next prev parent reply other threads:[~2026-10-13 7:38 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-05 10:52 [PATCH net v2] r8152: Use BMSR to detect the link state Linmao Li
2026-10-05 18:32 ` Birger Koblitz
2026-10-09 7:18 ` Linmao Li
2026-10-12 16:13 ` Birger Koblitz
2026-10-13 2:38 ` Linmao Li
2026-10-13 3:51 ` Birger Koblitz
2026-10-06 8:28 ` Hayes Wang
2026-10-06 16:10 ` Andrew Lunn
2026-10-09 7:16 ` Linmao Li
2026-10-09 12:22 ` Andrew Lunn
2026-10-13 2:36 ` Linmao Li
2026-10-13 10:30 ` Hayes Wang
2026-10-13 8:04 ` Hayes Wang
2026-10-13 7:37 ` Hayes Wang [this message]
2026-10-06 22:55 ` netdev-bot+sashiko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ea950637b76b4f43b3031a040d1e5fec@realtek.com \
--to=hayeswang@realtek.com \
--cc=andrew+netdev@lunn.ch \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=hsu.chih.kai@realtek.com \
--cc=kuba@kernel.org \
--cc=lilinmao@kylinos.cn \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mail@birger-koblitz.de \
--cc=netdev@vger.kernel.org \
--cc=nic_swsd@realtek.com \
--cc=pabeni@redhat.com \
--cc=stable@vger.kernel.org \
--cc=zhangxiangqian@kylinos.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.