diff mbox series

[RFC,v2,net-next,02/15] phy: introduce the PHY_MODE_ETHTOOL mode for phy_set_mode_ext()

Message ID 20230923134904.3627402-3-vladimir.oltean@nxp.com (mailing list archive)
State RFC
Delegated to: Netdev Maintainers
Headers show
Series Add C72/C73 copper backplane support for LX2160 | expand

Checks

Context Check Description
netdev/series_format success Posting correctly formatted
netdev/tree_selection success Clearly marked for net-next
netdev/fixes_present success Fixes tag not required for -next series
netdev/header_inline success No static functions without inline keyword in header files
netdev/build_32bit success Errors and warnings before: 1445 this patch: 1445
netdev/cc_maintainers success CCed 3 of 3 maintainers
netdev/build_clang success Errors and warnings before: 1376 this patch: 1376
netdev/verify_signedoff success Signed-off-by tag matches author and committer
netdev/deprecated_api success None detected
netdev/check_selftest success No net selftest shell script
netdev/verify_fixes success No Fixes tag
netdev/build_allmodconfig_warn success Errors and warnings before: 1483 this patch: 1483
netdev/checkpatch success total: 0 errors, 0 warnings, 0 checks, 15 lines checked
netdev/kdoc success Errors and warnings before: 0 this patch: 0
netdev/source_inline success Was 0 now: 0

Commit Message

Vladimir Oltean Sept. 23, 2023, 1:48 p.m. UTC
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(-)

Comments

Florian Fainelli Oct. 2, 2023, 7:19 p.m. UTC | #1
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?
Vladimir Oltean Oct. 3, 2023, 4:04 p.m. UTC | #2
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 mbox series

Patch

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,
 };