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]
Message-ID: <YfbUYcOLiikv9Pyv@shell.armlinux.org.uk>
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!

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ