[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20211130011812.08baccdc@thinkpad>
Date: Tue, 30 Nov 2021 01:18:12 +0100
From: Marek BehĂșn <kabel@...nel.org>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: netdev@...r.kernel.org, Andrew Lunn <andrew@...n.ch>,
Jakub Kicinski <kuba@...nel.org>, davem@...emloft.net
Subject: Re: [PATCH net 6/6] net: dsa: mv88e6xxx: Link in pcs_get_state() if
AN is bypassed
On Mon, 29 Nov 2021 23:14:17 +0000
"Russell King (Oracle)" <linux@...linux.org.uk> wrote:
> On Mon, Nov 29, 2021 at 08:58:23PM +0100, Marek BehĂșn wrote:
> > static int mv88e6xxx_serdes_pcs_get_state(struct mv88e6xxx_chip *chip,
> > - u16 status, u16 lpa,
> > + u16 ctrl, u16 status, u16 lpa,
> > struct phylink_link_state *state)
> > {
> > + state->link = !!(status & MV88E6390_SGMII_PHY_STATUS_LINK);
> > +
> > if (status & MV88E6390_SGMII_PHY_STATUS_SPD_DPL_VALID) {
> > - state->link = !!(status & MV88E6390_SGMII_PHY_STATUS_LINK);
> > + state->an_complete = !!(ctrl & BMCR_ANENABLE);
>
> I think I'd much rather report the value of BMSR_ANEGCAPABLE - since
> an_complete controls the BMSR_ANEGCAPABLE bit in the emulated PHY
> that userspace sees. Otherwise, an_complete is not used.
>
> state->link is the key that phylink uses to know whether it can
> trust the status being reported.
Isn't BMSR_ANEGCAPABLE set to 1 even if aneg is disabled in BMCR?
I will test tomorrow.
The reason why I used BMCR_ANENABLE is that if we don't enable AN, the
PHY will report SPD_DPL_VALID if link is up. But clearly AN is not
completed in that case, because it was never enabled in the first place.
Marek
Powered by blists - more mailing lists