diff mbox

ethtool: Support arbitrary speeds

Message ID 1231506974.3006.18.camel@achroite
State Not Applicable, archived
Delegated to: David Miller
Headers show

Commit Message

Ben Hutchings Jan. 9, 2009, 1:16 p.m. UTC 
The speed and speed_hi fields of struct ethtool_cmd together represent
a value in units of Mbit/s.  The valid speed settings are hardware-
dependent and should be checked by the driver.  Remove our validation
and allow arbitrary positive values.  Continue to report 0 and -1 as
"Unknown!" since some drivers will report these invalid values when
the link is down.

Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
On Thu, 2009-01-08 at 11:50 -0800, Rick Jones wrote:
> > 
> > I think 0, (u32)(-1) and (u16)(-1) may have to be special-cased as
> > unknown, but everything else can be treated as a number of Mbit/s.  I
> > don't know what a driver should do about an interface that really runs
> > at 65.535 Gbit/s though...
> 
> Something along these lines then? (assuming my mailer doesn't fubar this
> :( - I normally send matches via mailx)

That's kind of incomplete.  Here's my attempt.

In a quick test I found that the tg3 driver *doesn't* validate the speed
setting if autonegotiation is off, and will accept and report back e.g.
99.  But this patch doesn't create a new problem as you could already
set it to the unsupported speeds of 2500 and 10000.

Ben.

 ethtool.8 |    4 ++--
 ethtool.c |   42 ++++++++++--------------------------------
 2 files changed, 12 insertions(+), 34 deletions(-)

Comments

Rick Jones Jan. 9, 2009, 5:55 p.m. UTC | #1 
Ben Hutchings wrote:
> The speed and speed_hi fields of struct ethtool_cmd together represent
> a value in units of Mbit/s.  The valid speed settings are hardware-
> dependent and should be checked by the driver.  Remove our validation
> and allow arbitrary positive values.  Continue to report 0 and -1 as
> "Unknown!" since some drivers will report these invalid values when
> the link is down.
> 
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
> ---
> On Thu, 2009-01-08 at 11:50 -0800, Rick Jones wrote:
> 
>>>I think 0, (u32)(-1) and (u16)(-1) may have to be special-cased as
>>>unknown, but everything else can be treated as a number of Mbit/s.  I
>>>don't know what a driver should do about an interface that really runs
>>>at 65.535 Gbit/s though...
>>
>>Something along these lines then? (assuming my mailer doesn't fubar this
>>:( - I normally send matches via mailx)
> 
> 
> That's kind of incomplete.  Here's my attempt.
> 
> In a quick test I found that the tg3 driver *doesn't* validate the speed
> setting if autonegotiation is off, and will accept and report back e.g.
> 99.  But this patch doesn't create a new problem as you could already
> set it to the unsupported speeds of 2500 and 10000.

I'm fine with yanking the vetting on set - didn't do it initially 
because what got me patching in the first place does the setting of the 
speeds "elsewhere" so set support wasn't an issue.

WRT the get part:

> @@ -893,30 +884,17 @@ static void dump_advertised(struct ethtool_cmd *ep)
>  
>  static int dump_ecmd(struct ethtool_cmd *ep)
>  {
> +	u32 speed;
> +
>  	dump_supported(ep);
>  	dump_advertised(ep);
>  
>  	fprintf(stdout, "	Speed: ");
> -	switch (ethtool_cmd_speed(ep)) {
> -	case SPEED_10:
> -		fprintf(stdout, "10Mb/s\n");
> -		break;
> -	case SPEED_100:
> -		fprintf(stdout, "100Mb/s\n");
> -		break;
> -	case SPEED_1000:
> -		fprintf(stdout, "1000Mb/s\n");
> -		break;
> -	case SPEED_2500:
> -		fprintf(stdout, "2500Mb/s\n");
> -		break;
> -	case SPEED_10000:
> -		fprintf(stdout, "10000Mb/s\n");
> -		break;
> -	default:
> -		fprintf(stdout, "Unknown! (%i)\n", ethtool_cmd_speed(ep));
> -		break;
> -	};
> +	speed = ethtool_cmd_speed(ep);
> +	if (speed == 0 || speed == (u16)(-1) || speed == (u32)(-1))
> +		fprintf(stdout, "Unknown!\n");

Doesn't that need to keep the reporting of the unknown speed in parens 
like the original?

rick jones
--
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
Ben Hutchings Jan. 9, 2009, 6:24 p.m. UTC | #2 
On Fri, 2009-01-09 at 09:55 -0800, Rick Jones wrote:
> Ben Hutchings wrote:
[...]
> > +	speed = ethtool_cmd_speed(ep);
> > +	if (speed == 0 || speed == (u16)(-1) || speed == (u32)(-1))
> > +		fprintf(stdout, "Unknown!\n");
> 
> Doesn't that need to keep the reporting of the unknown speed in parens 
> like the original?

We'll only be doing it for known invalid values, so the value isn't
useful information.  I suppose it's conceivable that there are tools out
there that are parsing the output and expect "Unknown! (0)" when link is
down.

Ben.
Rick Jones Jan. 9, 2009, 6:40 p.m. UTC | #3 
>>Doesn't that need to keep the reporting of the unknown speed in parens 
>>like the original?
> 
> 
> We'll only be doing it for known invalid values, so the value isn't
> useful information.  I suppose it's conceivable that there are tools out
> there that are parsing the output and expect "Unknown! (0)" when link is
> down.

That was my paranoid assumption :) (albeit for the 65535 value :)

rick
--
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
Jeff Garzik March 6, 2009, 11:20 a.m. UTC | #4 
Ben Hutchings wrote:
> The speed and speed_hi fields of struct ethtool_cmd together represent
> a value in units of Mbit/s.  The valid speed settings are hardware-
> dependent and should be checked by the driver.  Remove our validation
> and allow arbitrary positive values.  Continue to report 0 and -1 as
> "Unknown!" since some drivers will report these invalid values when
> the link is down.
> 
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
> ---
> On Thu, 2009-01-08 at 11:50 -0800, Rick Jones wrote:
>>> I think 0, (u32)(-1) and (u16)(-1) may have to be special-cased as
>>> unknown, but everything else can be treated as a number of Mbit/s.  I
>>> don't know what a driver should do about an interface that really runs
>>> at 65.535 Gbit/s though...
>> Something along these lines then? (assuming my mailer doesn't fubar this
>> :( - I normally send matches via mailx)
> 
> That's kind of incomplete.  Here's my attempt.
> 
> In a quick test I found that the tg3 driver *doesn't* validate the speed
> setting if autonegotiation is off, and will accept and report back e.g.
> 99.  But this patch doesn't create a new problem as you could already
> set it to the unsupported speeds of 2500 and 10000.
> 
> Ben.
> 
>  ethtool.8 |    4 ++--
>  ethtool.c |   42 ++++++++++--------------------------------
>  2 files changed, 12 insertions(+), 34 deletions(-)

ACK, can you rediff against current git repo?


--
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
Jeff Garzik March 6, 2009, 12:27 p.m. UTC | #5 
Ben Hutchings wrote:
> The speed and speed_hi fields of struct ethtool_cmd together represent
> a value in units of Mbit/s.  The valid speed settings are hardware-
> dependent and should be checked by the driver.  Remove our validation
> and allow arbitrary positive values.  Continue to report 0 and -1 as
> "Unknown!" since some drivers will report these invalid values when
> the link is down.
> 
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
> ---
> On Thu, 2009-01-08 at 11:50 -0800, Rick Jones wrote:
>>> I think 0, (u32)(-1) and (u16)(-1) may have to be special-cased as
>>> unknown, but everything else can be treated as a number of Mbit/s.  I
>>> don't know what a driver should do about an interface that really runs
>>> at 65.535 Gbit/s though...
>> Something along these lines then? (assuming my mailer doesn't fubar this
>> :( - I normally send matches via mailx)
> 
> That's kind of incomplete.  Here's my attempt.
> 
> In a quick test I found that the tg3 driver *doesn't* validate the speed
> setting if autonegotiation is off, and will accept and report back e.g.
> 99.  But this patch doesn't create a new problem as you could already
> set it to the unsupported speeds of 2500 and 10000.
> 
> Ben.
> 
>  ethtool.8 |    4 ++--
>  ethtool.c |   42 ++++++++++--------------------------------
>  2 files changed, 12 insertions(+), 34 deletions(-)
> 

applied


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

Patch

diff --git a/ethtool.8 b/ethtool.8
index 1beb387..1504a23 100644
--- a/ethtool.8
+++ b/ethtool.8
@@ -183,7 +183,7 @@  ethtool \- Display or change ethernet card settings
 
 .B ethtool \-s
 .I ethX
-.B4 speed 10 100 1000 2500 10000
+.BI speed \ N
 .B2 duplex half full
 .B4 port tp aui bnc mii fibre
 .B2 autoneg on off
@@ -343,7 +343,7 @@  All following options only apply if
 .B \-s
 was specified.
 .TP
-.A4 speed 10 100 1000 2500 10000
+.BI speed \ N
 Set speed in Mb/s.
 .B ethtool
 with just the device name as an argument will show you the supported device speeds.
diff --git a/ethtool.c b/ethtool.c
index a7c02d0..bcc865e 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -107,7 +107,7 @@  static struct option {
     char *opthelp;
 } args[] = {
     { "-s", "--change", MODE_SSET, "Change generic options",
-		"		[ speed 10|100|1000|2500|10000 ]\n"
+		"		[ speed %%d ]\n"
 		"		[ duplex half|full ]\n"
 		"		[ port tp|aui|bnc|mii|fibre ]\n"
 		"		[ autoneg on|off ]\n"
@@ -608,17 +608,8 @@  static void parse_cmdline(int argc, char **argp)
 				i += 1;
 				if (i >= argc)
 					show_usage(1);
-				if (!strcmp(argp[i], "10"))
-					speed_wanted = SPEED_10;
-				else if (!strcmp(argp[i], "100"))
-					speed_wanted = SPEED_100;
-				else if (!strcmp(argp[i], "1000"))
-					speed_wanted = SPEED_1000;
-				else if (!strcmp(argp[i], "2500"))
-					speed_wanted = SPEED_2500;
-				else if (!strcmp(argp[i], "10000"))
-					speed_wanted = SPEED_10000;
-				else
+				speed_wanted = strtol(argp[i], NULL, 10);
+				if (speed_wanted <= 0)
 					show_usage(1);
 				break;
 			} else if (!strcmp(argp[i], "duplex")) {
@@ -893,30 +884,17 @@  static void dump_advertised(struct ethtool_cmd *ep)
 
 static int dump_ecmd(struct ethtool_cmd *ep)
 {
+	u32 speed;
+
 	dump_supported(ep);
 	dump_advertised(ep);
 
 	fprintf(stdout, "	Speed: ");
-	switch (ethtool_cmd_speed(ep)) {
-	case SPEED_10:
-		fprintf(stdout, "10Mb/s\n");
-		break;
-	case SPEED_100:
-		fprintf(stdout, "100Mb/s\n");
-		break;
-	case SPEED_1000:
-		fprintf(stdout, "1000Mb/s\n");
-		break;
-	case SPEED_2500:
-		fprintf(stdout, "2500Mb/s\n");
-		break;
-	case SPEED_10000:
-		fprintf(stdout, "10000Mb/s\n");
-		break;
-	default:
-		fprintf(stdout, "Unknown! (%i)\n", ethtool_cmd_speed(ep));
-		break;
-	};
+	speed = ethtool_cmd_speed(ep);
+	if (speed == 0 || speed == (u16)(-1) || speed == (u32)(-1))
+		fprintf(stdout, "Unknown!\n");
+	else
+		fprintf(stdout, "%uMb/s\n", speed);
 
 	fprintf(stdout, "	Duplex: ");
 	switch (ep->duplex) {