| Message ID | 20230923134904.3627402-3-vladimir.oltean@nxp.com |
|---|---|
| State | RFC |
| Headers | show |
| Series | Add C72/C73 copper backplane support for LX2160 | expand |
On 9/23/23 06:48, Vladimir Oltean wrote: > In networking, we have 2 distinct data types: > > - phy_interface_t describes the link between a MAC (or MAC-side PCS) and > an attached PHY or SFP cage > > - enum ethtool_link_mode_bit_indices describes the link between a local > PHY and a remote PHY (for example, gigabit RJ45 twisted copper pairs) > > Currently, phy_set_mode_ext(PHY_MODE_ETHERNET) takes arguments of the > phy_interface_t type, and there is no way to pass an argument of the > enum ethtool_link_mode_bit_indices type. The new PHY_MODE_ETHTOOL > intends to address that. > > It is true that there is currently some overlap between these data > types, namely: > > phy_interface_t enum ethtool_link_mode_bit_indices > ----------------------------------------------------------------- > PHY_INTERFACE_MODE_10GKR ETHTOOL_LINK_MODE_10000baseKR_Full_BIT > PHY_INTERFACE_MODE_1000BASEKX ETHTOOL_LINK_MODE_1000baseKX_Full_BIT > > but those overlaps were deemed to be mistakes, and PHY-to-PHY link modes > should only be added to ethtool_link_mode_bit_indices going forward. > Thus, I believe that the distinction is necessary, rather than hacking > more improper PHY modes. Some of the PHY-to-PHY link modes which may be > added in the future (to ethtool_link_mode_bit_indices and not to > phy_interface_t) are: > > ETHTOOL_LINK_MODE_100000baseKP4_Full_BIT > ETHTOOL_LINK_MODE_100000baseCR10_Full_BIT > ETHTOOL_LINK_MODE_25000baseKR_S_Full_BIT > ETHTOOL_LINK_MODE_25000baseCR_S_Full_BIT > > One user of PHY_MODE_ETHTOOL will be the MTIP backplane AN/LT + Lynx > SerDes PHY combo, where the backplane autoneg protocol (IEEE 802.3 > clause 73) selects the operating PHY-to-PHY link mode. > > There are electrical differences between the PHY-to-PHY backplane link > modes (like ETHTOOL_LINK_MODE_10000baseKR_Full_BIT) and their > non-backplane counterparts (like PHY_INTERFACE_MODE_10GBASER), namely > the number of TX signal equalization taps and their configurability. > This further justifies distinguishing between them in the generic PHY > API. > > Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> > --- > v1->v2: rename PHY_MODE_ETHERNET_PHY to PHY_MODE_ETHTOOL at Russell's > suggestion > > include/linux/phy/phy.h | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h > index 6be348f1fa0e..72ef4afcda81 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_ETHTOOL, Not feeling very comfortable with using ETHTOOL here because that is a Linux sub-subsystem name as opposed to the other enumeration values which are electrical modes of operation and/or industry standards names. How about PHY_MODE_ETHERNET_EXPLICIT or PHY_MODE_ETHERNET_LINKMODE?
Hi Florian, On Mon, Oct 02, 2023 at 12:19:57PM -0700, Florian Fainelli wrote: > > diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h > > index 6be348f1fa0e..72ef4afcda81 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_ETHTOOL, > > Not feeling very comfortable with using ETHTOOL here because that is a Linux > sub-subsystem name as opposed to the other enumeration values which are > electrical modes of operation and/or industry standards names. > > How about PHY_MODE_ETHERNET_EXPLICIT or PHY_MODE_ETHERNET_LINKMODE? > -- > Florian > I agree with your sentiment. I can rename this to PHY_MODE_ETHERNET_LINKMODE.
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h index 6be348f1fa0e..72ef4afcda81 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_ETHTOOL, PHY_MODE_MIPI_DPHY, PHY_MODE_SATA, PHY_MODE_LVDS, @@ -52,7 +53,7 @@ enum phy_media { }; enum phy_status_type { - /* Valid for PHY_MODE_ETHERNET */ + /* Valid for PHY_MODE_ETHERNET and PHY_MODE_ETHTOOL */ PHY_STATUS_CDR_LOCK, };
In networking, we have 2 distinct data types: - phy_interface_t describes the link between a MAC (or MAC-side PCS) and an attached PHY or SFP cage - enum ethtool_link_mode_bit_indices describes the link between a local PHY and a remote PHY (for example, gigabit RJ45 twisted copper pairs) Currently, phy_set_mode_ext(PHY_MODE_ETHERNET) takes arguments of the phy_interface_t type, and there is no way to pass an argument of the enum ethtool_link_mode_bit_indices type. The new PHY_MODE_ETHTOOL intends to address that. It is true that there is currently some overlap between these data types, namely: phy_interface_t enum ethtool_link_mode_bit_indices ----------------------------------------------------------------- PHY_INTERFACE_MODE_10GKR ETHTOOL_LINK_MODE_10000baseKR_Full_BIT PHY_INTERFACE_MODE_1000BASEKX ETHTOOL_LINK_MODE_1000baseKX_Full_BIT but those overlaps were deemed to be mistakes, and PHY-to-PHY link modes should only be added to ethtool_link_mode_bit_indices going forward. Thus, I believe that the distinction is necessary, rather than hacking more improper PHY modes. Some of the PHY-to-PHY link modes which may be added in the future (to ethtool_link_mode_bit_indices and not to phy_interface_t) are: ETHTOOL_LINK_MODE_100000baseKP4_Full_BIT ETHTOOL_LINK_MODE_100000baseCR10_Full_BIT ETHTOOL_LINK_MODE_25000baseKR_S_Full_BIT ETHTOOL_LINK_MODE_25000baseCR_S_Full_BIT One user of PHY_MODE_ETHTOOL will be the MTIP backplane AN/LT + Lynx SerDes PHY combo, where the backplane autoneg protocol (IEEE 802.3 clause 73) selects the operating PHY-to-PHY link mode. There are electrical differences between the PHY-to-PHY backplane link modes (like ETHTOOL_LINK_MODE_10000baseKR_Full_BIT) and their non-backplane counterparts (like PHY_INTERFACE_MODE_10GBASER), namely the number of TX signal equalization taps and their configurability. This further justifies distinguishing between them in the generic PHY API. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> --- v1->v2: rename PHY_MODE_ETHERNET_PHY to PHY_MODE_ETHTOOL at Russell's suggestion include/linux/phy/phy.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)