[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z0WTpE8wkpjMiv_J@shell.armlinux.org.uk>
Date: Tue, 26 Nov 2024 09:23:48 +0000
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Andrew Lunn <andrew@...n.ch>, Heiner Kallweit <hkallweit1@...il.com>
Cc: Alexander Couzens <lynxis@...0.eu>, Andrew Lunn <andrew+netdev@...n.ch>,
AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
Broadcom internal kernel review list <bcm-kernel-feedback-list@...adcom.com>,
Daniel Golle <daniel@...rotopia.org>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Florian Fainelli <florian.fainelli@...adcom.com>,
Ioana Ciornei <ioana.ciornei@....com>,
Jakub Kicinski <kuba@...nel.org>,
Jose Abreu <Jose.Abreu@...opsys.com>,
linux-arm-kernel@...ts.infradead.org,
linux-mediatek@...ts.infradead.org,
Marcin Wojtas <marcin.s.wojtas@...il.com>,
Matthias Brugger <matthias.bgg@...il.com>, netdev@...r.kernel.org,
Paolo Abeni <pabeni@...hat.com>
Subject: [PATCH RFC net-next 00/16] net: add negotiation of in-band
capabilities
Hi,
Yes, this is one patch over the limit of 15 for netdev - but I think it's
important to include the last patch to head off review comments like "why
don't you remove phylink_phy_no_inband() in this series?"
Phylink's handling of in-band has been deficient for a long time, and
people keep hitting problems with it. Notably, situations with the way-
to-late standardized 2500Base-X and whether that should or should not
have in-band enabled. We have also been carrying a hack in the form of
phylink_phy_no_inband() for a PHY that has been used on a SFP module,
but has no in-band capabilities, not even for SGMII.
When phylink is trying to operate in in-band mode, this series will look
at the capabilities of the MAC-side PCS and PHY, and work out whether
in-band can or should be used, programming the PHY as appropriate. This
includes in-band bypass mode at the PHY.
We don't... yet... support that on the MAC side PCS, because that
requires yet more complexity.
Patch 1 passes struct phylink and struct phylink_pcs into
phylink_pcs_neg_mode() so we can look at more state in this function in
a future patch.
Patch 2 splits "cur_link_an_mode" (the MLO_AN_* mode) into two separate
purposes - a requested and an active mode. The active mode is the one
we will be using for the MAC, which becomes dependent on the result of
in-band negotiation.
Patch 3 adds debug to phylink_major_config() so we can see what is going
on with the requested and active AN modes.
Patch 4 adds to phylib a method to get the in-band capabilities of the
PHY from phylib. Patches 5 and 6 add implementations for BCM84881 and
some Marvell PHYs found on SFPs.
Patch 7 adds to phylib a method to configure the PHY in-band signalling,
and patch 8 implements it for those Marvell PHYs that support the method
in patch 4.
Patch 9 does the same as patch 4 but for the MAC-side PCS, with patches
10 through 14 adding support to several PCS.
Patch 15 adds the code to phylink_pcs_neg_mode() which looks at the
capabilities, and works out whether to use in-band or out-band mode for
driving the link between the MAC PCS and PHY.
Patch 16 removes the phylink_phy_no_inband() hack now that we are
publishing the in-band capabilities from the BCM84881 PHY driver.
drivers/net/ethernet/marvell/mvneta.c | 27 +-
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 25 +-
drivers/net/pcs/pcs-lynx.c | 22 ++
drivers/net/pcs/pcs-mtk-lynxi.c | 16 ++
drivers/net/pcs/pcs-xpcs.c | 28 ++
drivers/net/phy/bcm84881.c | 10 +
drivers/net/phy/marvell.c | 48 ++++
drivers/net/phy/phy.c | 52 ++++
drivers/net/phy/phylink.c | 352 +++++++++++++++++++-----
include/linux/phy.h | 34 +++
include/linux/phylink.h | 17 ++
11 files changed, 539 insertions(+), 92 deletions(-)
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
Powered by blists - more mailing lists