RE: [PATCH] ethtool: don't overwrite useful bits in advertising bitfield

-----Original Message-----
From: Ben Hutchings [mailto:bhutchings@solarflare.com]
Sent: den 21 augusti 2012 17:12
To: Johan Gunnarsson
Cc: netdev@vger.kernel.org; Mikael Starvik
Subject: RE: [PATCH] ethtool: don't overwrite useful bits in
advertising bitfield

On Tue, 2012-08-21 at 10:41 +0200, Johan Gunnarsson wrote:

quoted

quoted

-----Original Message-----
From: netdev-owner@vger.kernel.org [mailto:netdev-
owner@vger.kernel.org] On Behalf Of Ben Hutchings
Sent: den 20 augusti 2012 17:23
To: Johan Gunnarsson
Cc: netdev@vger.kernel.org; Mikael Starvik
Subject: Re: [PATCH] ethtool: don't overwrite useful bits in
advertising bitfield

On Tue, 2012-08-14 at 16:15 +0200, Johan Gunnarsson wrote:

quoted

There are bits in this bitfield that we want to leave untouched

(PAUSE

quoted

and ASYM_PAUSE bits) when changing other bits (speed and duplex

bits.)

quoted

Previously, these were always overwritten to zero when running

commands

quoted

like "ethtool -s eth0 speed 10 duplex full autoneg off".

This is right in principle, but the implementation isn't quite

right.

quoted

quoted

quoted

Signed-off-by: Johan Gunnarsson <redacted>
---
 ethtool.c |   45 +++++++++++++++++++++++++++++++--------------
 1 file changed, 31 insertions(+), 14 deletions(-)

diff --git a/ethtool.c b/ethtool.c
index e573357..efa12c7 100644
--- a/ethtool.c
+++ b/ethtool.c

@@ -46,6 +46,18 @@
 #define MAX_ADDR_LEN	32
 #endif

+#define ALL_ADVERTISED_MODES \
+	(ADVERTISED_10baseT_Half | \
+	 ADVERTISED_10baseT_Full | \
+	 ADVERTISED_100baseT_Half | \
+	 ADVERTISED_100baseT_Full | \
+	 ADVERTISED_1000baseT_Half | \
+	 ADVERTISED_1000baseT_Full | \
+	 ADVERTISED_2500baseX_Full | \
+	 ADVERTISED_10000baseT_Full | \
+	 ADVERTISED_20000baseMLD2_Full | \
+	 ADVERTISED_20000baseKR2_Full)

This is missing the new 40G modes (not a regression, I realise).

I'll add the 40G modes. There is also a bunch of 10G modes missing.

Shall I add these too?

Yes please.

Alright.

quoted

quoted

[...]

quoted

@@ -2405,19 +2421,20 @@ static int do_sset(struct cmd_context

*ctx)

quoted

quoted

quoted

 			}
 			if (autoneg_wanted == AUTONEG_ENABLE &&
 			    advertising_wanted == 0) {
-				ecmd.advertising = ecmd.supported &
-					(ADVERTISED_10baseT_Half |
-					 ADVERTISED_10baseT_Full |
-					 ADVERTISED_100baseT_Half |
-					 ADVERTISED_100baseT_Full |
-					 ADVERTISED_1000baseT_Half |
-					 ADVERTISED_1000baseT_Full |
-					 ADVERTISED_2500baseX_Full |
-					 ADVERTISED_10000baseT_Full |
-					 ADVERTISED_20000baseMLD2_Full |
-					 ADVERTISED_20000baseKR2_Full);
+				/* Auto negotation enabled, but with
+				 * unspecified speed and duplex: enable

all

quoted

quoted

quoted

+				 * supported speeds and duplexes.
+				 */
+				ecmd.advertising = (ecmd.advertising &
+					~ALL_ADVERTISED_MODES) |
+					(ALL_ADVERTISED_MODES &

ecmd.supported);

quoted

quoted

Perhaps we should also warn if there's a 'supported' flag we don't
recognise, because we don't know whether it's a link mode and we

might

quoted

quoted

be failing to enable/disable it as requested.

You mean if ecmd.supported has bits enabled that ALL_ADVERTISED_MODES
hasn't? I don't think that's a good idea, because that happens very
often (for example PAUSE bits in my case.)

No, I mean if it has bits enabled that are not defined at all
(currently
any of bits 27-31).

Not totally sure I follow. Care to show me?

quoted

quoted

quoted

 			} else if (advertising_wanted > 0) {
-				ecmd.advertising = advertising_wanted;
+				/* Enable all requested modes */
+				ecmd.advertising = (ecmd.advertising &
+					~ALL_ADVERTISED_MODES) |
+					(advertising_wanted &

ecmd.supported);

quoted

quoted

I don't think the '& ecmd.supported' here is right.  If an autoneg
device supports some new link mode L that is not in
ALL_ADVERTISED_MODES, but not link mode M which the user requested,
then
this can silently fail because the resulting advertising mask will
include L but not M.

We should either use advertising_wanted unmasked and let the driver
validate it, or report an error if it's not present in the

supported

quoted

quoted

mask.  I think we should be consistent with the following case,

i.e.

quoted

quoted

let
the driver validate it.

How about remove "& ecmd.supported", but also warn if trying to add

an

quoted

unsupported mode? Similar to the previous case.

[...]

I don't think this is similar and I don't think we need to do both.

So let's go for the removed "& ecmd.supported" then.

Ben.

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