From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Jiawen Wu <jiawenwu@trustnetic.com>
Cc: netdev@vger.kernel.org, mengyuanlou@net-swift.com
Subject: Re: [PATCH net-next 5/6] net: txgbe: Implement phylink pcs
Date: Mon, 10 Apr 2023 11:40:38 +0100 [thread overview]
Message-ID: <ZDPnpgYablOB5NRa@shell.armlinux.org.uk> (raw)
In-Reply-To: <00a701d96b7e$90edb890$b2c929b0$@trustnetic.com>
On Mon, Apr 10, 2023 at 03:32:12PM +0800, Jiawen Wu wrote:
> > > + struct phylink_link_state *state)
> > > +{
> > > + int lpa, bmsr;
> > > +
> > > + /* For C37 1000BASEX mode */
> > > + if (linkmode_test_bit(ETHTOOL_LINK_MODE_Autoneg_BIT,
> > > + state->advertising)) {
> > > + /* Reset link state */
> > > + state->link = false;
> > > +
> > > + /* Poll for link jitter */
> > > + read_poll_timeout(pcs_read, lpa, lpa,
> > > + 100, 50000, false, txgbe,
> > > + MDIO_MMD_VEND2, MII_LPA);
> >
> > What jitter are you referring to? If the link is down (and thus this
> > register reads zero), why do we have to spin here for 50ms each time?
> >
>
> I found that when the last interrupt arrives, the link status is often
> still down, but it will become up after a while. It is about 30ms on my
> test.
It is normal for the first read of the BMSR to report that the link is
down after it has come up. This is so that software can see if the link
has failed since it last read the BMSR. Phylink knows this, and will
re-request the link state via the pcs_get_state() callback
appropriately.
Is it reporting that the link is down after the second read of the
link status after the interrupt?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
next prev parent reply other threads:[~2023-04-10 10:40 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-03 6:45 [PATCH net-next 0/6] TXGBE PHYLINK support Jiawen Wu
2023-04-03 6:45 ` [PATCH net-next 1/6] net: txgbe: Add software nodes to support phylink Jiawen Wu
2023-04-03 12:35 ` Andrew Lunn
2023-04-03 6:45 ` [PATCH net-next 2/6] net: txgbe: Implement I2C bus master driver Jiawen Wu
2023-04-03 12:52 ` Andrew Lunn
2023-04-04 2:47 ` Jiawen Wu
2023-04-04 14:18 ` Andrew Lunn
2023-04-06 6:59 ` Jiawen Wu
2023-04-07 2:03 ` Andrew Lunn
2023-04-03 6:45 ` [PATCH net-next 3/6] net: txgbe: Add SFP module identify Jiawen Wu
2023-04-03 12:58 ` Andrew Lunn
2023-04-03 6:45 ` [PATCH net-next 4/6] net: txgbe: Support GPIO to SFP socket Jiawen Wu
2023-04-03 13:16 ` Andrew Lunn
2023-04-03 6:45 ` [PATCH net-next 5/6] net: txgbe: Implement phylink pcs Jiawen Wu
2023-04-03 13:47 ` Russell King (Oracle)
2023-04-10 7:32 ` Jiawen Wu
2023-04-10 10:40 ` Russell King (Oracle) [this message]
2023-04-11 2:34 ` Jiawen Wu
2023-04-11 6:32 ` Jiawen Wu
2023-04-03 6:45 ` [PATCH net-next 6/6] net: txgbe: Support phylink MAC layer Jiawen Wu
2023-04-03 13:22 ` Andrew Lunn
2023-04-03 13:51 ` Russell King (Oracle)
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=ZDPnpgYablOB5NRa@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=jiawenwu@trustnetic.com \
--cc=mengyuanlou@net-swift.com \
--cc=netdev@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).