linux-kernel - Re: [PATCH net] net: phy: Fix qca8081 with speeds lower than 2.5Gb/s

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 30 Jan 2022 18:09:37 +0000
From:   "Russell King (Oracle)" <linux@...linux.org.uk>
To:     Jonathan McDowell <noodles@...th.li>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Heiner Kallweit <hkallweit1@...il.com>,
        David Miller <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Luo Jie <luoj@...eaurora.org>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, Robert Marko <robimarko@...il.com>
Subject: Re: [PATCH net] net: phy: Fix qca8081 with speeds lower than 2.5Gb/s

On Sun, Jan 30, 2022 at 03:18:10PM +0000, Jonathan McDowell wrote:
> On Sun, Jan 30, 2022 at 12:40:57PM +0000, Russell King (Oracle) wrote:
> > On Sun, Jan 30, 2022 at 10:25:28AM +0000, Jonathan McDowell wrote:
> > > A typo in qca808x_read_status means we try to set SMII mode on the port
> > > rather than SGMII when the link speed is not 2.5Gb/s. This results in no
> > > traffic due to the mismatch in configuration between the phy and the
> > > mac.
> > > 
> > > Fixes: 79c7bc0521545 ("net: phy: add qca8081 read_status")
> > > Signed-off-by: Jonathan McDowell <noodles@...th.li>
> > > ---
> > >  drivers/net/phy/at803x.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
> > > index 5b6c0d120e09..7077e3a92d31 100644
> > > --- a/drivers/net/phy/at803x.c
> > > +++ b/drivers/net/phy/at803x.c
> > > @@ -1691,7 +1691,7 @@ static int qca808x_read_status(struct phy_device *phydev)
> > >  	if (phydev->link && phydev->speed == SPEED_2500)
> > >  		phydev->interface = PHY_INTERFACE_MODE_2500BASEX;
> > >  	else
> > > -		phydev->interface = PHY_INTERFACE_MODE_SMII;
> > > +		phydev->interface = PHY_INTERFACE_MODE_SGMII;
> > 
> > Is it intentional to set the interface to SGMII also when there is no
> > link?
> 
> My reading of the code is that if this was just a GigE capable phy the
> interface would be set once and never changed/unset. The only reason
> it happens here is because the link changes to support the 2.5G mode, so
> there's no problem with it defaulting to SGMII even when the external
> link isn't actually up. Perhap Luo can confirm if this is the case?

My point is that other PHY drivers only change the interface mode when
the link comes up, and we ought to have consistency between PHY drivers
rather than each PHY driver deciding on different behaviours - unless
there is a good reason to be different.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!