Re: [RFC PATCH net-next 2/8] phy: introduce the PHY_MODE_ETHERNET_PHY mode for phy_set_mode_ext()

From: Sean Anderson <sean.anderson@seco.com>
To: Vladimir Oltean <vladimir.oltean@nxp.com>,
	netdev@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-phy@lists.infradead.org
Cc: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>,
	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>,
	Maxime Chevallier <maxime.chevallier@bootlin.com>,
	Vinod Koul <vkoul@kernel.org>,
	Kishon Vijay Abraham I <kishon@kernel.org>
Subject: Re: [RFC PATCH net-next 2/8] phy: introduce the PHY_MODE_ETHERNET_PHY mode for phy_set_mode_ext()
Date: Mon, 21 Aug 2023 13:30:46 -0400	[thread overview]
Message-ID: <2c8cb48c-5b0f-5712-8c50-ea285df829ec@seco.com> (raw)
In-Reply-To: <20230817150644.3605105-3-vladimir.oltean@nxp.com>

On 8/17/23 11:06, Vladimir Oltean wrote:
> As opposed to PHY_MODE_ETHERNET which takes a phy_interface_t as is
> expected to be used by an Ethernet MAC driver, PHY_MODE_ETHERNET takes
> an enum ethtool_link_mode_bit_indices and expects to be used by an
> Ethernet PHY driver.
> 
> It is true that the phy_interface_t type also contains definitions for
> PHY_INTERFACE_MODE_10GKR and PHY_INTERFACE_MODE_1000BASEKX, but those
> were deemed to be mistakes, and shouldn't be used going forward, when
> 10GBase-KR and 1GBase-KX are really link modes. Thus, I believe that the
> distinction is necessary, rather than hacking more improper PHY modes.

10GBase-KR and 1000Base-KX are both electrically (e.g. link mode) and
functionally (e.g. phy mode) different from 10GBase-R and 1000Base-X due
to differing autonegotiation. So the phy modes are still relevant, and
should still be used to ensure the correct form of autonegotiation is
selected.

That said, I do agree that from the phy's (serdes's) point of view,
there are only electrical differences between these modes.

However, I'm not sure we need to have a separate mode here. I think this
would only be necessary if there were electrically-incompatible modes
which shared the same signalling. E.g. if 802.3 decided that they wanted
a "long range backplane ethernet" or somesuch with different
drive/equalization requirements from 1000BASE-KX et al. but with the
same signalling. Otherwise, we can infer the link mode from the phy
mode.

--Sean

> In particular to the Lynx SerDes, it can be used (as the PMA/PMD layer)
> in conjunction with a separate backplane AN/LT block to form a
> full-fledged copper backplane Ethernet PHY. The configuration of the
> lanes is relatively similar to what is done for a typical MAC-to-PHY
> link, except that we allow tuning the electrical equalization parameters
> of the link (support for which will come as a separate change).
> 
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---
>  include/linux/phy/phy.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> index 456d21c67e4f..7e10761303fc 100644
> --- a/include/linux/phy/phy.h
> +++ b/include/linux/phy/phy.h
> @@ -39,6 +39,7 @@ enum phy_mode {
>  	PHY_MODE_UFS_HS_B,
>  	PHY_MODE_PCIE,
>  	PHY_MODE_ETHERNET,
> +	PHY_MODE_ETHERNET_PHY,
>  	PHY_MODE_MIPI_DPHY,
>  	PHY_MODE_SATA,
>  	PHY_MODE_LVDS,

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy