[net-next-2.6 PATCH 1/2] ethtool: Add PHY type to ethtool get_drvinfo

[net-next-2.6 PATCH 1/2] ethtool: Add PHY type to ethtool get_drvinfo

[Jeff Kirsher]

From: PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com>

Allow the PHY type to be passed from a driver to ethtool when
ethtool -i ethX is called.  With newer network cards having SFP
and SFP+ PHY cages, this information can be useful, especially
if the NIC supports hot-swapping of the PHY modules.

Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---

 include/linux/ethtool.h |   24 +++++++++++++++++++++++-
 1 files changed, 23 insertions(+), 1 deletions(-)

diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index edd03b7..d6606a5 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -59,7 +59,8 @@ struct ethtool_drvinfo {
 	char	bus_info[ETHTOOL_BUSINFO_LEN];	/* Bus info for this IF. */
 				/* For PCI devices, use pci_name(pci_dev). */
 	char	reserved1[32];
-	char	reserved2[12];
+	char	reserved2[11];
+	__u8	phy_type;	/* PHY type present on the NIC */
 	__u32	n_priv_flags;	/* number of flags valid in ETHTOOL_GPFLAGS */
 	__u32	n_stats;	/* number of u64's from ETHTOOL_GSTATS */
 	__u32	testinfo_len;
@@ -291,6 +292,27 @@ enum ethtool_flags {
 	ETH_FLAG_LRO		= (1 << 15),	/* LRO is enabled */
 };
 
+/*
+ * PHY types supported
+ *
+ * 0    - PHY not specified
+ * 1    - SFP/SFP+ Fiber (SR and LR)
+ * 2    - XFP Fiber (SR and LR)
+ * 3    - SFP+ Direct Attach (TwinAX)
+ * 4    - BASE-T (RJ-45)
+ * MAX  - PHY not present
+ */
+enum ethtool_phy_type {
+	ETH_PHY_UNSPECIFIED = 0,
+	ETH_PHY_SFP_FIBER,
+	ETH_PHY_XFP_FIBER,
+	ETH_PHY_DA_TWINAX,
+	ETH_PHY_BASE_T,
+
+	/* This must be the last entry */
+	ETH_PHY_NOT_PRESENT,
+};
+
 /* The following structures are for supporting RX network flow
  * classification configuration. Note, all multibyte fields, e.g.,
  * ip4src, ip4dst, psrc, pdst, spi, etc. are expected to be in network

[net-next-2.6 PATCH 2/2] ixgbe: Display currently attached PHY through ethtool get_drvinfo

[Jeff Kirsher]

From: PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com>

This patch uses the new ethtool interface to display what PHY
is currently connected to a NIC.  The results can be viewed in
ethtool -i ethX output.

Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---

 drivers/net/ixgbe/ixgbe_ethtool.c |   61 +++++++++++++++++++++++++++++++++++++
 1 files changed, 61 insertions(+), 0 deletions(-)

diff --git a/drivers/net/ixgbe/ixgbe_ethtool.c b/drivers/net/ixgbe/ixgbe_ethtool.c
index 9d2cc83..0012c65 100644
--- a/drivers/net/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ixgbe/ixgbe_ethtool.c
@@ -782,6 +782,67 @@ static void ixgbe_get_drvinfo(struct net_device *netdev,
 	drvinfo->n_stats = IXGBE_STATS_LEN;
 	drvinfo->testinfo_len = IXGBE_TEST_LEN;
 	drvinfo->regdump_len = ixgbe_get_regs_len(netdev);
+
+	/* Get PHY type */
+
+	/*
+	 * If the adapter is not up, we should re-identify the PHY type.
+	 * It might be stale otherwise.
+	 */
+	if (test_bit(__IXGBE_DOWN, &adapter->state)) {
+		/* clear the PHY type to ensure we do a full scan */
+		adapter->hw.phy.type = ixgbe_phy_unknown;
+		adapter->hw.phy.ops.identify(&adapter->hw);
+	}
+
+	switch (adapter->hw.phy.type) {
+	case ixgbe_phy_tn:
+	case ixgbe_phy_cu_unknown:
+		/* Copper 10G-BASET */
+		drvinfo->phy_type = ETH_PHY_BASE_T;
+		break;
+	case ixgbe_phy_qt:
+		drvinfo->phy_type = ETH_PHY_XFP_FIBER;
+		break;
+	case ixgbe_phy_nl:
+	case ixgbe_phy_tw_tyco:
+	case ixgbe_phy_tw_unknown:
+	case ixgbe_phy_sfp_ftl:
+	case ixgbe_phy_sfp_avago:
+	case ixgbe_phy_sfp_intel:
+	case ixgbe_phy_sfp_unknown:
+	case ixgbe_phy_unknown:
+		switch (adapter->hw.phy.sfp_type) {
+		/* SFP+ devices, further checking needed */
+		case ixgbe_sfp_type_da_cu:
+		case ixgbe_sfp_type_da_cu_core0:
+		case ixgbe_sfp_type_da_cu_core1:
+			drvinfo->phy_type = ETH_PHY_DA_TWINAX;
+			break;
+		case ixgbe_sfp_type_sr:
+		case ixgbe_sfp_type_lr:
+		case ixgbe_sfp_type_srlr_core0:
+		case ixgbe_sfp_type_srlr_core1:
+			drvinfo->phy_type = ETH_PHY_SFP_FIBER;
+			break;
+		case ixgbe_sfp_type_not_present:
+			drvinfo->phy_type = ETH_PHY_NOT_PRESENT;
+			break;
+		case ixgbe_sfp_type_unknown:
+		default:
+			ETH_PHY_UNSPECIFIED;
+			break;
+		}
+		break;
+	case ixgbe_phy_xaui:
+		drvinfo->phy_type = ETH_PHY_NOT_PRESENT;
+		break;
+	case ixgbe_phy_generic:
+	case ixgbe_phy_sfp_unsupported:
+	default:
+		drvinfo->phy_type = ETH_PHY_UNSPECIFIED;
+		break;
+	}
 }
 
 static void ixgbe_get_ringparam(struct net_device *netdev,

Re: [net-next-2.6 PATCH 1/2] ethtool: Add PHY type to ethtool get_drvinfo

[Ben Hutchings]

On Tue, 2009-11-17 at 08:13 -0800, Jeff Kirsher wrote:
> From: PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com>
> 
> Allow the PHY type to be passed from a driver to ethtool when
> ethtool -i ethX is called.  With newer network cards having SFP
> and SFP+ PHY cages, this information can be useful, especially
> if the NIC supports hot-swapping of the PHY modules.
[...]

I think this information belongs in ethtool_cmd, in the port and/or
transceiver fields.

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

Re: [net-next-2.6 PATCH 1/2] ethtool: Add PHY type to ethtool get_drvinfo

[Stephen Hemminger]

On Tue, 17 Nov 2009 08:13:24 -0800
Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:

> From: PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com>
> 
> Allow the PHY type to be passed from a driver to ethtool when
> ethtool -i ethX is called.  With newer network cards having SFP
> and SFP+ PHY cages, this information can be useful, especially
> if the NIC supports hot-swapping of the PHY modules.
> 
> Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---

Maybe revive usage of connector port in ethtool rather than adding new API?
It is already there but values are out of date with current hardware.

Re: [net-next-2.6 PATCH 1/2] ethtool: Add PHY type to ethtool get_drvinfo

[Waskiewicz Jr, Peter P]

On Tue, 17 Nov 2009, Stephen Hemminger wrote:

> On Tue, 17 Nov 2009 08:13:24 -0800
> Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:
> 
> > From: PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com>
> > 
> > Allow the PHY type to be passed from a driver to ethtool when
> > ethtool -i ethX is called.  With newer network cards having SFP
> > and SFP+ PHY cages, this information can be useful, especially
> > if the NIC supports hot-swapping of the PHY modules.
> > 
> > Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > ---
> 
> Maybe revive usage of connector port in ethtool rather than adding new API?
> It is already there but values are out of date with current hardware.

You're referring to the MODE_GSET port settings?  If so, I like this 
approach, and will update my patches accordingly.

Thanks Stephen,
-PJ

Re: [net-next-2.6 PATCH 1/2] ethtool: Add PHY type to ethtool get_drvinfo

[Stephen Hemminger]

On Tue, 17 Nov 2009 11:56:57 -0800 (Pacific Standard Time)
"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@intel.com> wrote:

> On Tue, 17 Nov 2009, Stephen Hemminger wrote:
> 
> > On Tue, 17 Nov 2009 08:13:24 -0800
> > Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:
> > 
> > > From: PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com>
> > > 
> > > Allow the PHY type to be passed from a driver to ethtool when
> > > ethtool -i ethX is called.  With newer network cards having SFP
> > > and SFP+ PHY cages, this information can be useful, especially
> > > if the NIC supports hot-swapping of the PHY modules.
> > > 
> > > Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> > > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > > ---
> > 
> > Maybe revive usage of connector port in ethtool rather than adding new API?
> > It is already there but values are out of date with current hardware.
> 
> You're referring to the MODE_GSET port settings?  If so, I like this 
> approach, and will update my patches accordingly.

Yes. cmd->port is always PORT_TP or PORT_FIBRE now but could be extended
Likewise cmd->transceiver could be modified.  I haven't seen an external transceiver
since the old fat yellow cable with vampire taps (and that was 20 yrs ago).

Re: [net-next-2.6 PATCH 1/2] ethtool: Add PHY type to ethtool get_drvinfo

[Waskiewicz Jr, Peter P]

On Tue, 17 Nov 2009, Stephen Hemminger wrote:

> On Tue, 17 Nov 2009 11:56:57 -0800 (Pacific Standard Time)
> "Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@intel.com> wrote:
> 
> > On Tue, 17 Nov 2009, Stephen Hemminger wrote:
> > 
> > > On Tue, 17 Nov 2009 08:13:24 -0800
> > > Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:
> > > 
> > > > From: PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com>
> > > > 
> > > > Allow the PHY type to be passed from a driver to ethtool when
> > > > ethtool -i ethX is called.  With newer network cards having SFP
> > > > and SFP+ PHY cages, this information can be useful, especially
> > > > if the NIC supports hot-swapping of the PHY modules.
> > > > 
> > > > Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> > > > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > > > ---
> > > 
> > > Maybe revive usage of connector port in ethtool rather than adding new API?
> > > It is already there but values are out of date with current hardware.
> > 
> > You're referring to the MODE_GSET port settings?  If so, I like this 
> > approach, and will update my patches accordingly.
> 
> Yes. cmd->port is always PORT_TP or PORT_FIBRE now but could be extended
> Likewise cmd->transceiver could be modified.  I haven't seen an external transceiver
> since the old fat yellow cable with vampire taps (and that was 20 yrs ago).

I have patches that I sent to Jeff for internal testing that fixes up the 
cmd->port field (per your and Ben's suggestion).  I like it much better 
too.  :-)

-PJ

Re: [net-next-2.6 PATCH 1/2] ethtool: Add PHY type to ethtool get_drvinfo

[Ben Hutchings]

On Tue, 2009-11-17 at 16:41 -0800, Stephen Hemminger wrote:
> On Tue, 17 Nov 2009 11:56:57 -0800 (Pacific Standard Time)
> "Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@intel.com> wrote:
> 
> > On Tue, 17 Nov 2009, Stephen Hemminger wrote:
> > 
> > > On Tue, 17 Nov 2009 08:13:24 -0800
> > > Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:
> > > 
> > > > From: PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com>
> > > > 
> > > > Allow the PHY type to be passed from a driver to ethtool when
> > > > ethtool -i ethX is called.  With newer network cards having SFP
> > > > and SFP+ PHY cages, this information can be useful, especially
> > > > if the NIC supports hot-swapping of the PHY modules.
> > > > 
> > > > Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> > > > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > > > ---
> > > 
> > > Maybe revive usage of connector port in ethtool rather than adding new API?
> > > It is already there but values are out of date with current hardware.
> > 
> > You're referring to the MODE_GSET port settings?  If so, I like this 
> > approach, and will update my patches accordingly.
> 
> Yes. cmd->port is always PORT_TP or PORT_FIBRE now but could be extended
> Likewise cmd->transceiver could be modified.  I haven't seen an external transceiver
> since the old fat yellow cable with vampire taps (and that was 20 yrs ago).

It seems to me there should be a transceiver type code or codes for
connectors like SFP where the bulk of the transceiver is internal but
the optical part is an external module.  SFP+ is a tricky case because
it also supports passive cables.

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.