[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2c8cb48c-5b0f-5712-8c50-ea285df829ec@seco.com>
Date: Mon, 21 Aug 2023 13:30:46 -0400
From: Sean Anderson <sean.anderson@...o.com>
To: Vladimir Oltean <vladimir.oltean@....com>, netdev@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-phy@...ts.infradead.org
Cc: "Russell King (Oracle)" <rmk+kernel@...linux.org.uk>,
Heiner Kallweit <hkallweit1@...il.com>,
Andrew Lunn <andrew@...n.ch>,
Florian Fainelli <f.fainelli@...il.com>,
Madalin Bucur <madalin.bucur@....com>,
Ioana Ciornei <ioana.ciornei@....com>,
Camelia Groza <camelia.groza@....com>,
Li Yang <leoyang.li@....com>, Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor@...nel.org>,
Maxime Chevallier <maxime.chevallier@...tlin.com>,
Vinod Koul <vkoul@...nel.org>,
Kishon Vijay Abraham I <kishon@...nel.org>
Subject: Re: [RFC PATCH net-next 2/8] phy: introduce the PHY_MODE_ETHERNET_PHY
mode for phy_set_mode_ext()
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@....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,
Powered by blists - more mailing lists