myri10ge: improve port type reporting in ethtool output

Improve the reporting of the port type in ethtool,
update for new boards.

Signed-off-by: Brice Goglin <brice@myri.com>

      * parse the product code to deterimine the interface type
@@ -1623,10 +1625,19 @@ myri10ge_get_settings(struct net_device *netdev,
struct ethtool_cmd *cmd)
             return 0;
         }
     }
-    if (*ptr == 'R' || *ptr == 'Q') {
-        /* We've found either an XFP or quad ribbon fiber */
+    if (*ptr == '2')
+        ptr++;
+    if (*ptr == 'R' || *ptr == 'Q' || *ptr == 'S') {
+        /* We've found either an XFP, quad ribbon fiber, or SFP+ */
         cmd->port = PORT_FIBRE;
+        cmd->supported |= SUPPORTED_FIBRE;
+        cmd->advertising |= ADVERTISED_FIBRE;
     }
+    if (*ptr == 'R' || *ptr == 'S')
+        cmd->transceiver = XCVR_EXTERNAL;
+    else
+        cmd->transceiver = XCVR_INTERNAL;
+
     return 0;
 }
 

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Mon, 2009-10-19 at 07:35 +0200, Brice Goglin wrote:
> Improve the reporting of the port type in ethtool,
> update for new boards.
> 
> Signed-off-by: Brice Goglin <brice@myri.com>
> 
> --- a/drivers/net/myri10ge/myri10ge.c
> +++ b/drivers/net/myri10ge/myri10ge.c
> @@ -75,7 +75,7 @@
>  #include "myri10ge_mcp.h"
>  #include "myri10ge_mcp_gen_header.h"
>  
> -#define MYRI10GE_VERSION_STR "1.5.0-1.432"
> +#define MYRI10GE_VERSION_STR "1.5.1-1.450"
>  
>  MODULE_DESCRIPTION("Myricom 10G driver (10GbE)");
>  MODULE_AUTHOR("Maintainer: help@myri.com");
> @@ -1601,6 +1601,8 @@ myri10ge_get_settings(struct net_device *netdev,
> struct ethtool_cmd *cmd)
>      cmd->autoneg = AUTONEG_DISABLE;
>      cmd->speed = SPEED_10000;
>      cmd->duplex = DUPLEX_FULL;
> +    cmd->supported = SUPPORTED_10000baseT_Full;
> +    cmd->advertising = ADVERTISED_10000baseT_Full;
[...]

Lying about link modes is not an improvement.

Ben.

Ben Hutchings wrote:

> Lying about link modes is not an improvement.

OK, so we're probably doing something wrong. I suspect we're not
alone.  At least we don't set SUPPORTED_TP for CX4, like I've
seen some NICs do.

Can somebody suggest how we can tell ethtool that
the NIC supports 10Gb only (no autoneg down to 1Gb or lower)
for copper (10Gbase-CX4)?   How about for fiber (10Gbase-{S,L})R?



Thanks,

Drew
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Mon, 2009-10-19 at 08:34 -0400, Andrew Gallatin wrote:
> Ben Hutchings wrote:
> 
> > Lying about link modes is not an improvement.
> 
> OK, so we're probably doing something wrong. I suspect we're not
> alone.  At least we don't set SUPPORTED_TP for CX4, like I've
> seen some NICs do.
> 
> Can somebody suggest how we can tell ethtool that
> the NIC supports 10Gb only (no autoneg down to 1Gb or lower)
> for copper (10Gbase-CX4)?   How about for fiber (10Gbase-{S,L})R?

What's wrong with what you already do?  Customers expect to see
something on the supported line?

Ben.

Ben Hutchings wrote:
> On Mon, 2009-10-19 at 08:34 -0400, Andrew Gallatin wrote:
>> Ben Hutchings wrote:
>>
>>> Lying about link modes is not an improvement.
>> OK, so we're probably doing something wrong. I suspect we're not
>> alone.  At least we don't set SUPPORTED_TP for CX4, like I've
>> seen some NICs do.
>>
>> Can somebody suggest how we can tell ethtool that
>> the NIC supports 10Gb only (no autoneg down to 1Gb or lower)
>> for copper (10Gbase-CX4)?   How about for fiber (10Gbase-{S,L})R?
> 
> What's wrong with what you already do?  Customers expect to see
> something on the supported line?

Exactly.  One has complained because drivers for
other vendors NICs show this, even if they are fibre NICs
or CX4 NICs, and don't actually support 10GbaseT.

I'm happy to back this part out, and resubmit the patch without
it. There is still some fairly valuable stuff in the patch
-- mainly updating the NIC detection logic for new NICs to
detect fibre vs copper.

Drew
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Mon, 2009-10-19 at 09:30 -0400, Andrew Gallatin wrote:
> Ben Hutchings wrote:
> > On Mon, 2009-10-19 at 08:34 -0400, Andrew Gallatin wrote:
> >> Ben Hutchings wrote:
> >>
> >>> Lying about link modes is not an improvement.
> >> OK, so we're probably doing something wrong. I suspect we're not
> >> alone.  At least we don't set SUPPORTED_TP for CX4, like I've
> >> seen some NICs do.
> >>
> >> Can somebody suggest how we can tell ethtool that
> >> the NIC supports 10Gb only (no autoneg down to 1Gb or lower)
> >> for copper (10Gbase-CX4)?   How about for fiber (10Gbase-{S,L})R?
> > 
> > What's wrong with what you already do?  Customers expect to see
> > something on the supported line?
> 
> Exactly.  One has complained because drivers for
> other vendors NICs show this, even if they are fibre NICs
> or CX4 NICs, and don't actually support 10GbaseT.

Let's fix the other drivers then.  Labelling these NICs as supporting
10GBASE-T is liable to confuse more people (and tools) in the long run.

> I'm happy to back this part out, and resubmit the patch without
> it. There is still some fairly valuable stuff in the patch
> -- mainly updating the NIC detection logic for new NICs to
> detect fibre vs copper.

Sure.

You should also set port = PORT_OTHER for CX4 or KX4.  Currently it
looks like you don't set port, so it appears as 0 == PORT_TP.

Ben.