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