Subject: Re: [PATCH net-next 5/6] net: txgbe: Implement phylink pcs

From: "Russell King (Oracle)" <[email-masked]>
Date: Mon, 10 Apr 2023 11:40:38 +0100

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!