netdev - Re: [RFC PATCH net-next 2/8] phy: introduce the PHY_MODE_ETHERNET_PHY mode for phy_set_mode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<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,