[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210213201642.GS1463@shell.armlinux.org.uk>
Date: Sat, 13 Feb 2021 20:16:43 +0000
From: Russell King - ARM Linux admin <linux@...linux.org.uk>
To: Michael Walle <michael@...le.cc>
Cc: Vladimir Oltean <olteanv@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Antoine Tenart <atenart@...nel.org>,
Quentin Schulz <quentin.schulz@...tlin.com>,
netdev@...r.kernel.org, Heiner Kallweit <hkallweit1@...il.com>,
Andrew Lunn <andrew@...n.ch>,
Florian Fainelli <f.fainelli@...il.com>,
Ioana Ciornei <ioana.ciornei@....com>,
Maxim Kochetkov <fido_max@...ox.ru>,
Bjarni Jonasson <bjarni.jonasson@...rochip.com>,
Steen Hegelund <steen.hegelund@...rochip.com>,
UNGLinuxDriver@...rochip.com
Subject: Re: [PATCH net-next 1/2] net: phylink: explicitly configure in-band
autoneg for PHYs that support it
On Sat, Feb 13, 2021 at 08:57:46PM +0100, Michael Walle wrote:
> But then why bother with config_inband_aneg() at all and just enable
> it unconditionally in config_init(). [and maybe keep the return -EINVAL].
> Which then begs the question, does it makes sense on (Q)SGMII links at
> all?
There are three cases. There are PHYs which operate in SGMII mode:
1) with in-band signalling enabled or disabled.
2) only with in-band signalling enabled.
3) with no in-band signalling capability.
Most Marvell PHYs can be configured and fall into class (1), although
changing that configuration is disruptive to the entire PHY. There is
at least one Broadcom PHY we support that falls into class (3) and it
appears on SFP modules. It sounds like AR803x fall into class (2).
--
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