From: Vladimir Oltean <vladimir.oltean@nxp.com>
To: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>
Cc: linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
Heiner Kallweit <hkallweit1@gmail.com>,
Andrew Lunn <andrew@lunn.ch>,
Florian Fainelli <f.fainelli@gmail.com>,
Madalin Bucur <madalin.bucur@nxp.com>,
Ioana Ciornei <ioana.ciornei@nxp.com>,
Camelia Groza <camelia.groza@nxp.com>,
Li Yang <leoyang.li@nxp.com>, Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor@kernel.org>,
Sean Anderson <sean.anderson@seco.com>,
Maxime Chevallier <maxime.chevallier@bootlin.com>,
Vinod Koul <vkoul@kernel.org>,
Kishon Vijay Abraham I <kishon@kernel.org>
Subject: Re: [RFC PATCH v2 net-next 08/15] net: phylink: allow PCS to handle C73 autoneg for phy-mode = "internal"
Date: Mon, 2 Oct 2023 17:17:43 +0300 [thread overview]
Message-ID: <20231002141743.lbmb66q22dmuyi6f@skbuf> (raw)
In-Reply-To: <20230923134904.3627402-9-vladimir.oltean@nxp.com>
Hi Russell,
On Sat, Sep 23, 2023 at 04:48:57PM +0300, Vladimir Oltean wrote:
> Some phylink and phylib based systems might want to operate on backplane
> media types ("K" in the name), and thus, picking a phy_interface_t for
> them becomes a challenge.
>
> phy_interface_t is a description of the connection between the MAC and
> the PHY, or if a MAC-side PCS is present, the connection between that
> and the next link segment (which can be remote).
>
> A MAC-side PCS is so far considered to be a PCS handling link modes with
> optional C37 autoneg. But C73 autoneg (for backplanes and SFP28 modules)
> is not at the same level in the OSI layering, so that existing model may
> or may not apply.
>
> (a) If we say that the PCS is MAC-side for C73 modes as well, the
> implication seems to be that the phy-mode should be one of
> PHY_INTERFACE_MODE_10GBASEKR, PHY_INTERFACE_MODE_1000BASEKX, etc.
> Similar to PHY_INTERFACE_MODE_1000BASEX which imitates the link mode
> ETHTOOL_LINK_MODE_1000baseX_Full_BIT.
>
> (b) If we say that the PCS is not MAC-side, but rather that the
> phylink_pcs represents an entire non-phylib backplane PHY which may
> negotiate one of many link modes (like a copper phylib PHY), then
> the phy-mode should probably be one of PHY_INTERFACE_MODE_XGMII,
> XLGMII etc. Or rather, because there is no MII pinout per se and the
> backplane PHY / phylink_pcs is internal, we can also use
> PHY_INTERFACE_MODE_INTERNAL.
>
> The trouble with (a), in my opinion, is that if we let the phy_interface_t
> follow the link mode like in the case of Base-X fiber modes, we have to
> consider the fact that C73 PHYs can advertise multiple link modes, so
> the phy_interface_t selection will be arbitrary, and any phy_interface_t
> selection will have to leave in the "supported" and "advertised" masks
> of link modes all the other backplane modes. This may be hard to justify.
>
> That is the reasoning based on which I selected this phy-mode to
> describe the setup in Layerscape SoCs which have integrated backplane
> autoneg support. The changes in phylink permit the managed =
> "in-band-status" fwnode property to be extended for C73 autoneg, which
> is then controllable through ethtool. With phy-mode = "internal" in an
> in-band autoneg mode, we advertise all backplane link modes. The list is
> not exhaustive and may be extended in the future.
>
> Link: https://lore.kernel.org/netdev/ZOXlpkbcAZ4okric@shell.armlinux.org.uk/
> Link: https://lore.kernel.org/netdev/ZGIkGmyL8yL1q1zp@shell.armlinux.org.uk/
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---
> v1->v2: patch is new
>
> drivers/net/phy/phylink.c | 19 ++++++++++++++++++-
> include/linux/phylink.h | 1 +
> 2 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
> index 548130d77302..88ace7e203c3 100644
> --- a/drivers/net/phy/phylink.c
> +++ b/drivers/net/phy/phylink.c
> @@ -972,6 +972,21 @@ static int phylink_parse_mode(struct phylink *pl,
> phylink_set(pl->supported, 100000baseDR2_Full);
> break;
>
> + case PHY_INTERFACE_MODE_INTERNAL:
> + phylink_set(pl->supported, 1000baseKX_Full);
> + phylink_set(pl->supported, 10000baseKX4_Full);
> + phylink_set(pl->supported, 10000baseKR_Full);
> + phylink_set(pl->supported, 25000baseCR_Full);
> + phylink_set(pl->supported, 25000baseKR_Full);
> + phylink_set(pl->supported, 25000baseCR_S_Full);
> + phylink_set(pl->supported, 25000baseKR_S_Full);
> + phylink_set(pl->supported, 40000baseKR4_Full);
> + phylink_set(pl->supported, 50000baseKR2_Full);
> + phylink_set(pl->supported, 50000baseKR_Full);
> + phylink_set(pl->supported, 100000baseKR4_Full);
> + phylink_set(pl->supported, 100000baseKR2_Full);
> + break;
> +
> default:
> phylink_err(pl,
> "incorrect link mode %s for in-band status\n",
> @@ -1109,7 +1124,9 @@ static void phylink_mac_config(struct phylink *pl,
>
> static bool phylink_pcs_handles_an(phy_interface_t iface, unsigned int mode)
> {
> - return phy_interface_mode_is_8023z(iface) && phylink_autoneg_inband(mode);
> + return (phy_interface_mode_is_8023z(iface) ||
> + iface == PHY_INTERFACE_MODE_INTERNAL) &&
> + phylink_autoneg_inband(mode);
> }
>
> static void phylink_pcs_an_restart(struct phylink *pl)
> diff --git a/include/linux/phylink.h b/include/linux/phylink.h
> index 2b886ea654bb..7e8e26001587 100644
> --- a/include/linux/phylink.h
> +++ b/include/linux/phylink.h
> @@ -141,6 +141,7 @@ static inline unsigned int phylink_pcs_neg_mode(unsigned int mode,
>
> case PHY_INTERFACE_MODE_1000BASEX:
> case PHY_INTERFACE_MODE_2500BASEX:
> + case PHY_INTERFACE_MODE_INTERNAL:
> /* 1000base-X is designed for use media-side for Fibre
> * connections, and thus the Autoneg bit needs to be
> * taken into account. We also do this for 2500base-X
> --
> 2.34.1
>
What do you think about this change?
next prev parent reply other threads:[~2023-10-02 14:17 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-23 13:48 [RFC PATCH v2 net-next 00/15] Add C72/C73 copper backplane support for LX2160 Vladimir Oltean
2023-09-23 13:48 ` [RFC PATCH v2 net-next 01/15] phy: introduce phy_get_status() and use it to report CDR lock Vladimir Oltean
2023-10-02 19:16 ` Florian Fainelli
2023-09-23 13:48 ` [RFC PATCH v2 net-next 02/15] phy: introduce the PHY_MODE_ETHTOOL mode for phy_set_mode_ext() Vladimir Oltean
2023-10-02 19:19 ` Florian Fainelli
2023-10-03 16:04 ` Vladimir Oltean
2023-09-23 13:48 ` [RFC PATCH v2 net-next 03/15] phy: ethernet: add configuration interface for copper backplane Ethernet PHYs Vladimir Oltean
2023-09-28 13:36 ` Simon Horman
2023-09-28 19:05 ` Simon Horman
2023-10-02 13:11 ` Vladimir Oltean
2023-10-02 17:20 ` Simon Horman
2023-09-23 13:48 ` [RFC PATCH v2 net-next 04/15] phy: allow querying the address of protocol converters through phy_get_status() Vladimir Oltean
2023-09-29 16:23 ` Vinod Koul
2023-10-02 10:09 ` Vladimir Oltean
2023-09-23 13:48 ` [RFC PATCH v2 net-next 05/15] net: add 25GBase-KR-S and 25GBase-CR-S to ethtool link mode UAPI Vladimir Oltean
2023-10-03 11:19 ` Russell King (Oracle)
2023-09-23 13:48 ` [RFC PATCH v2 net-next 06/15] net: mii: add C73 base page helpers Vladimir Oltean
2023-09-23 13:48 ` [RFC PATCH v2 net-next 07/15] net: phylink: centralize phy_interface_mode_is_8023z() && phylink_autoneg_inband() checks Vladimir Oltean
2023-09-28 13:38 ` Simon Horman
2023-10-03 11:27 ` Russell King (Oracle)
2023-10-03 21:03 ` Vladimir Oltean
2023-09-23 13:48 ` [RFC PATCH v2 net-next 08/15] net: phylink: allow PCS to handle C73 autoneg for phy-mode = "internal" Vladimir Oltean
2023-10-02 14:17 ` Vladimir Oltean [this message]
2023-10-03 11:06 ` Russell King (Oracle)
2023-10-03 15:00 ` Vladimir Oltean
2023-09-23 13:48 ` [RFC PATCH v2 net-next 09/15] net: ethtool: introduce ethtool_link_mode_str() Vladimir Oltean
2023-10-03 11:30 ` Russell King (Oracle)
2023-10-04 0:08 ` Florian Fainelli
2023-09-23 13:48 ` [RFC PATCH v2 net-next 10/15] net: phylink: support all ethtool port modes with inband modes Vladimir Oltean
2023-09-23 13:49 ` [RFC PATCH v2 net-next 11/15] net: phylink: support the 25GBase-KR-S and 25GBase-CR-S link modes too Vladimir Oltean
2023-10-03 11:31 ` Russell King (Oracle)
2023-10-03 16:24 ` Vladimir Oltean
2023-09-23 13:49 ` [RFC PATCH v2 net-next 12/15] net: phylink: add the 25G link modes to phylink_c73_priority_resolution[] Vladimir Oltean
2023-10-03 13:16 ` Russell King (Oracle)
2023-10-03 16:33 ` Vladimir Oltean
2023-09-23 13:49 ` [RFC PATCH v2 net-next 13/15] dt-bindings: lynx-pcs: add properties for backplane mode Vladimir Oltean
2023-09-24 11:49 ` Krzysztof Kozlowski
2023-10-02 12:19 ` Vladimir Oltean
2023-09-23 13:49 ` [RFC PATCH v2 net-next 14/15] net: pcs: mtip_backplane: add driver for MoreThanIP backplane AN/LT core Vladimir Oltean
2023-09-28 19:06 ` Simon Horman
2023-09-23 13:49 ` [RFC PATCH v2 net-next 15/15] net: pcs: lynx: use MTIP AN/LT block for copper backplanes Vladimir Oltean
2023-10-03 13:14 ` Russell King (Oracle)
2023-10-03 19:00 ` Vladimir Oltean
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231002141743.lbmb66q22dmuyi6f@skbuf \
--to=vladimir.oltean@nxp.com \
--cc=andrew@lunn.ch \
--cc=camelia.groza@nxp.com \
--cc=conor@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=f.fainelli@gmail.com \
--cc=hkallweit1@gmail.com \
--cc=ioana.ciornei@nxp.com \
--cc=kishon@kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=leoyang.li@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=madalin.bucur@nxp.com \
--cc=maxime.chevallier@bootlin.com \
--cc=rmk+kernel@armlinux.org.uk \
--cc=robh+dt@kernel.org \
--cc=sean.anderson@seco.com \
--cc=vkoul@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox