Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH] drivers/isdn/hisax: Add printf format/argument verification and fix fallout
From: David Miller @ 2010-11-17 18:58 UTC (permalink / raw)
  To: joe; +Cc: linux-kernel, isdn, netdev
In-Reply-To: <f92d95e7dc0afca09c2d76880b76973e4eafb169.1289451201.git.joe@perches.com>

From: Joe Perches <joe@perches.com>
Date: Wed, 10 Nov 2010 20:54:58 -0800

> Add __attribute__((format... to several functins
> Make formats and arguments match.
> 
> Signed-off-by: Joe Perches <joe@perches.com>

Applied, thanks.

^ permalink raw reply

* Re: [PATCH net-next-2.6] clarify documentation for net.ipv4.igmp_max_memberships
From: David Miller @ 2010-11-17 19:22 UTC (permalink / raw)
  To: jeder
  Cc: netdev, rdunlap, opurdila, apetlund, William.Allen.Simpson,
	ian.campbell, linux-doc, linux-kernel, jpirko
In-Reply-To: <1289835691.8257.1274.camel@jerms-wks.usersys.redhat.com>

From: Jeremy Eder <jeder@redhat.com>
Date: Mon, 15 Nov 2010 10:41:31 -0500

> This patch helps clarify documentation for
> net.ipv4.igmp_max_memberships by providing a formula for
> calculating the maximum number of multicast groups that can be
> subscribed to, plus defining the theoretical limit.
> 
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
> Signed-off-by: Jeremy Eder <jeder@redhat.com>

Applied, thanks Jeremy.

^ permalink raw reply

* Re: [PATCH net-next 1/4] rtnetlink: Link address family API
From: David Miller @ 2010-11-17 19:30 UTC (permalink / raw)
  To: tgraf; +Cc: netdev
In-Reply-To: <20101116143014.GA26669@canuck.infradead.org>

From: Thomas Graf <tgraf@infradead.org>
Date: Tue, 16 Nov 2010 09:30:14 -0500

> Each net_device contains address family specific data such as
> per device settings and statistics. We already expose this data
> via procfs/sysfs and partially netlink.
> 
> The netlink method requires the requester to send one RTM_GETLINK
> request for each address family it wishes to receive data of
> and then merge this data itself.
> 
> This patch implements a new API which combines all address family
> specific link data in a new netlink attribute IFLA_AF_SPEC.
> IFLA_AF_SPEC contains a sequence of nested attributes, one for each
> address family which in turn defines the structure of its own
> attribute. Example:
> 
>    [IFLA_AF_SPEC] = {
>        [AF_INET] = {
>            [IFLA_INET_CONF] = ...,
>        },
>        [AF_INET6] = {
>            [IFLA_INET6_FLAGS] = ...,
>            [IFLA_INET6_CONF] = ...,
>        }
>    }
> 
> The API also allows for address families to implement a function
> which parses the IFLA_AF_SPEC attribute sent by userspace to
> implement address family specific link options.
> 
> Signed-off-by: Thomas Graf <tgraf@infradead.org>

Applied, but note that as-implemented it has the "partial update"
problem.  When we can't get the af-specific ops for a "parse"
operation, we just skip that AF yet we let the modifications of
the other AF's succeed and make it appear to the user that
everything got updated and all the attributes were consumed.

I don't know what we can do about this with how things work
right now.

^ permalink raw reply

* Re: [PATCH net-next 2/4] inet: Define IPV4_DEVCONF_MAX
From: David Miller @ 2010-11-17 19:30 UTC (permalink / raw)
  To: tgraf; +Cc: netdev
In-Reply-To: <20101116143120.GB26669@canuck.infradead.org>

From: Thomas Graf <tgraf@infradead.org>
Date: Tue, 16 Nov 2010 09:31:20 -0500

> Define IPV4_DEVCONF_MAX to get rid of MAX - 1 notation.
> 
> Signed-off-by: Thomas Graf <tgraf@infradead.org>

Applied.

^ permalink raw reply

* Re: [PATCH net-next 3/4] ipv4: AF_INET link address family
From: David Miller @ 2010-11-17 19:30 UTC (permalink / raw)
  To: tgraf; +Cc: netdev
In-Reply-To: <20101116143248.GC26669@canuck.infradead.org>

From: Thomas Graf <tgraf@infradead.org>
Date: Tue, 16 Nov 2010 09:32:48 -0500

> Implements the AF_INET link address family exposing the per
> device configuration settings via netlink using the attribute
> IFLA_INET_CONF.
> 
> The format of IFLA_INET_CONF differs depending on the direction
> the attribute is sent. The attribute sent by the kernel consists
> of a u32 array, basically a 1:1 copy of in_device->cnf.data[].
> The attribute expected by the kernel must consist of a sequence
> of nested u32 attributes, each representing a change request,
> e.g.
> 	[IFLA_INET_CONF] = {
> 		[IPV4_DEVCONF_FORWARDING] = 1,
> 		[IPV4_DEVCONF_NOXFRM] = 0,
> 	}
> 
> libnl userspace API documentation and example available from:
> http://www.infradead.org/~tgr/libnl/doc-git/group__link__inet.html
> 
> Signed-off-by: Thomas Graf <tgraf@infradead.org>

Applied.

^ permalink raw reply

* Re: [PATCH net-next 4/4] ipv6: AF_INET6 link address family
From: David Miller @ 2010-11-17 19:30 UTC (permalink / raw)
  To: tgraf; +Cc: netdev, yoshfuji
In-Reply-To: <20101116143357.GD26669@canuck.infradead.org>

From: Thomas Graf <tgraf@infradead.org>
Date: Tue, 16 Nov 2010 09:33:57 -0500

> IPv6 already exposes some address family data via netlink in the
> IFLA_PROTINFO attribute if RTM_GETLINK request is sent with the
> address family set to AF_INET6. We take over this format and
> reuse all the code.
> 
> Signed-off-by: Thomas Graf <tgraf@infradead.org>
> Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>

Applied.

^ permalink raw reply

* Re: [PATCH net-next 0/5] qlcnic: Bug fixes
From: David Miller @ 2010-11-17 19:51 UTC (permalink / raw)
  To: anirban.chakraborty; +Cc: netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <alpine.OSX.2.00.1011161510040.88679@macintosh-2.local>

From: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
Date: Tue, 16 Nov 2010 16:07:38 -0800

> Please apply following patches to net-next.

All applied, thank you.

^ permalink raw reply

* Re: [PATCH] r8169: fix checksum broken
From: David Miller @ 2010-11-17 19:54 UTC (permalink / raw)
  To: romieu; +Cc: shanwei, netdev
In-Reply-To: <20101112231325.GB6676@electric-eye.fr.zoreil.com>

From: Francois Romieu <romieu@fr.zoreil.com>
Date: Sat, 13 Nov 2010 00:13:25 +0100

> Francois Romieu <romieu@fr.zoreil.com> :
> [...]
>> Which kind of device do you use : PCI-E 8168 / 810x or PCI 8169 ?
> 
> Wrong page. Forget it.
> 
> Acked-by: Francois Romieu <romieu@fr.zoreil.com>

Applied, thanks.

^ permalink raw reply

* Re: [PATCH] r8169: fix checksum broken
From: David Miller @ 2010-11-17 19:55 UTC (permalink / raw)
  To: romieu; +Cc: shanwei, netdev, jgarzik
In-Reply-To: <20101115210122.GA22621@electric-eye.fr.zoreil.com>

From: Francois Romieu <romieu@fr.zoreil.com>
Date: Mon, 15 Nov 2010 22:01:23 +0100

> Shan Wei <shanwei@cn.fujitsu.com> :
> [...]
>> If these are right, driver will set ip_summed with CHECKSUM_UNNECESSARY for other
>> upper protocol, e.g. sctp, igmp protocol. This will cause protocol stack ignores 
>> checksum check for packets with invalid checksum. 
> 
> The documentation of these bits is identical for the 8139c+ and the 8169.

Also applied, thank you.

^ permalink raw reply

* Re: [PATCH] net: bnx2x: fix error value sign
From: David Miller @ 2010-11-17 20:23 UTC (permalink / raw)
  To: eric.dumazet; +Cc: segoon, kernel-janitors, eilong, netdev, linux-kernel
In-Reply-To: <1289766728.2743.147.camel@edumazet-laptop>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 14 Nov 2010 21:32:08 +0100

> Le dimanche 14 novembre 2010 à 21:29 +0100, Eric Dumazet a écrit :
> 
>> I remember sending same patch in the past... it was lost somehow...
> 
> Ah, it was another issue, patch was not lost ;)

:-)  Applied, thanks everyone.

^ permalink raw reply

* Re: [PATCH 06/11] drivers/net/s2io.c: Remove unnecessary casts of pci_get_drvdata
From: David Miller @ 2010-11-17 20:28 UTC (permalink / raw)
  To: joe
  Cc: trivial, ramkrishna.vepa, sivakumar.subramani, sreenivasa.honnur,
	jon.mason, netdev, linux-kernel
In-Reply-To: <5add1304ab2cd7f730a81a85598ef7357b087a86.1289851770.git.joe@perches.com>

From: Joe Perches <joe@perches.com>
Date: Mon, 15 Nov 2010 12:13:57 -0800

> Signed-off-by: Joe Perches <joe@perches.com>

Applied.

^ permalink raw reply

* Re: [PATCH 07/11] drivers/net/vxge/vxge-main.c: Remove unnecessary casts of pci_get_drvdata
From: David Miller @ 2010-11-17 20:28 UTC (permalink / raw)
  To: jon.mason
  Cc: joe, trivial, Ramkrishna.Vepa, Sivakumar.Subramani,
	Sreenivasa.Honnur, netdev, linux-kernel
In-Reply-To: <20101115225056.GA12891@exar.com>

From: Jon Mason <jon.mason@exar.com>
Date: Mon, 15 Nov 2010 16:50:56 -0600

> On Mon, Nov 15, 2010 at 12:13:58PM -0800, Joe Perches wrote:
>> Signed-off-by: Joe Perches <joe@perches.com>
> 
> Looks good to me.
> 
> Acked-by: Jon Mason <jon.mason@exar.com>

Applied.

^ permalink raw reply

* Re: [PATCH] net: more Kconfig whitespace cleanup
From: David Miller @ 2010-11-17 20:29 UTC (permalink / raw)
  To: phdm; +Cc: netdev
In-Reply-To: <1289673809-17825-1-git-send-email-phdm@macqel.be>

From: Philippe De Muyter <phdm@macqel.be>
Date: Sat, 13 Nov 2010 19:43:29 +0100

> indentation for TSI108_ETH entry was too big.
> 
> Signed-off-by: Philippe De Muyter <phdm@macqel.be>

Applied.

^ permalink raw reply

* Re: [PATCH] net: use the macros defined for the members of flowi
From: David Miller @ 2010-11-17 20:29 UTC (permalink / raw)
  To: xiaosuo; +Cc: netdev
In-Reply-To: <1289623435-22713-1-git-send-email-xiaosuo@gmail.com>

From: Changli Gao <xiaosuo@gmail.com>
Date: Sat, 13 Nov 2010 12:43:55 +0800

> Use the macros defined for the members of flowi to clean the code up.
> 
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>

Applied, thank you.

^ permalink raw reply

* Re: [PATCH 09/14] drivers/net/can/sja1000: Use printf extension %pR for struct resource
From: David Miller @ 2010-11-17 20:29 UTC (permalink / raw)
  To: joe-6d6DIl74uiNBDgjK7y7TUQ
  Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
	netdev-u79uwXL29TY76Z2rM5mHXA, trivial-DgEjT+Ai2ygdnm+yROfE0A,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA, wg-5Yr1BZd7O62+XT7JhA+gdA
In-Reply-To: <199bf35f52ea48bef79d4b40b504b0c85dca6fad.1289597644.git.joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org>

From: Joe Perches <joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org>
Date: Fri, 12 Nov 2010 13:37:59 -0800

> Using %pR standardizes the struct resource output.
> 
> Signed-off-by: Joe Perches <joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org>

Applied.

^ permalink raw reply

* Re: [net-next-2.6 PATCH v2] net: zero kobject in rx_queue_release
From: David Miller @ 2010-11-17 20:29 UTC (permalink / raw)
  To: john.r.fastabend; +Cc: netdev, eric.dumazet, therbert
In-Reply-To: <20101116163139.2084.20075.stgit@jf-dev1-dcblab>

From: John Fastabend <john.r.fastabend@intel.com>
Date: Tue, 16 Nov 2010 08:31:39 -0800

> netif_set_real_num_rx_queues() can decrement and increment
> the number of rx queues. For example ixgbe does this as
> features and offloads are toggled. Presumably this could
> also happen across down/up on most devices if the available
> resources changed (cpu offlined).
> 
> The kobject needs to be zero'd in this case so that the
> state is not preserved across kobject_put()/kobject_init_and_add().
> 
> This resolves the following error report.
> 
> ixgbe 0000:03:00.0: eth2: NIC Link is Up 10 Gbps, Flow Control: RX/TX
> kobject (ffff880324b83210): tried to init an initialized object, something is seriously wrong.
> Pid: 1972, comm: lldpad Not tainted 2.6.37-rc18021qaz+ #169
> Call Trace:
>  [<ffffffff8121c940>] kobject_init+0x3a/0x83
>  [<ffffffff8121cf77>] kobject_init_and_add+0x23/0x57
>  [<ffffffff8107b800>] ? mark_lock+0x21/0x267
>  [<ffffffff813c6d11>] net_rx_queue_update_kobjects+0x63/0xc6
>  [<ffffffff813b5e0e>] netif_set_real_num_rx_queues+0x5f/0x78
>  [<ffffffffa0261d49>] ixgbe_set_num_queues+0x1c6/0x1ca [ixgbe]
>  [<ffffffffa0262509>] ixgbe_init_interrupt_scheme+0x1e/0x79c [ixgbe]
>  [<ffffffffa0274596>] ixgbe_dcbnl_set_state+0x167/0x189 [ixgbe]
> 
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>

Applied.

^ permalink raw reply

* Re: [PATCH] net: ipv4: tcp_probe: cleanup snprintf() use
From: David Miller @ 2010-11-17 20:30 UTC (permalink / raw)
  To: segoon
  Cc: kernel-janitors, kuznet, pekkas, jmorris, yoshfuji, kaber, netdev,
	linux-kernel
In-Reply-To: <1289754368-31660-1-git-send-email-segoon@openwall.com>

From: Vasiliy Kulikov <segoon@openwall.com>
Date: Sun, 14 Nov 2010 20:06:08 +0300

> snprintf() returns number of bytes that were copied if there is no overflow.
> This code uses return value as number of copied bytes.  Theoretically format
> string '%lu.%09lu %pI4:%u %pI4:%u %d %#x %#x %u %u %u %u\n' may be expanded
> up to 163 bytes.  In reality tv.tv_sec is just few bytes instead of 20, 2 ports
> are just 5 bytes each instead of 10, length is 5 bytes instead of 10.  The rest
> is an unstrusted input.  Theoretically if tv_sec is big then copy_to_user() would
> overflow tbuf.
> 
> tbuf was increased to fit in 163 bytes.  snprintf() is used to follow return
> value semantic.
> 
> Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>

Applied, thanks.

^ permalink raw reply

* Re: [PATCH] gianfar: fix signedness issue
From: David Miller @ 2010-11-17 20:40 UTC (permalink / raw)
  To: nikai; +Cc: galak, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20101115215942.354b0394@absol.kitzblitz>

From: Nicolas Kaiser <nikai@nikai.net>
Date: Mon, 15 Nov 2010 21:59:42 +0100

> irq_of_parse_and_map() has an unsigned return type.
> Testing for a negative error value doesn't work here.
> 
> Signed-off-by: Nicolas Kaiser <nikai@nikai.net>
> ---
> I see that in numerous places the return value is tested
> for NO_IRQ. I hope it's the right thing to do here as well?

I think it is, applied, thank you.

^ permalink raw reply

* extended netdevice naming proposal
From: Matt Domsch @ 2010-11-17 22:06 UTC (permalink / raw)
  To: linux-hotplug, netdev, narendra_k; +Cc: jcm, notting

While this _is_ the original bikeshedding problem, as long as I'm
going to use biosdevname to change names for embedded NICs, perhaps I
can be so bold as to change them for USB add-in cards too?

There are quite a few dimensions to the problem:
* device location (onboard, PCI, other bus)
* multiple ports on a single add-in card
* with Network Partitioning (NPAR) and SR-IOV, the OS sees multiple
  network interfaces (physical or virtual interfaces) but a single external port
* the suffix .1234 currently used for vlans (ala vconfig)
* A single PCI device may drive multiple external ports

As such, here is a naming proposal, aimed to keep within 15
characters for most configurations.

(location)(slot)#(port)/(instance).(vlan)

location := NIC on Motherboard = net1, net2, net3, net4
   (note: people hated the TLA collision with 'lom', so avoiding that here).
         := PCI slot = pci1, pci2, pci3, pci4
 these correspond to chassis labels, information is available in
 $PIRQ, SMBIOS or ACPI, which biosdevname retrieves and uses.

For single- or multi-port cards in PCI slots, append #(port):
   pci1#1, pci1#2, pci1#3, pci1#4  for 4 ports on a card in PCI slot 1

There is currently no way to get this port info from BIOS.  Several people
have suggested using adding a PCI capabilities field to expose this
info in a standard way, but that's a ways off. Until then, biosdevname
can guess (assume ascending MAC order on the single card).

For NPAR/SR-IOV where the physical port is shared by several
instances, append /(instance):
   net1/1, net1/2 pci1#1/1, pci1#1/2,
   pci1#1/2, pci1#1/3, ...

For each of the above where vconfig sets up a vlan:
   pci1#/1.1000, pci1#1/2.1001, pci1#1/2.1003, pci1#1/3.1004, ...
vconfig simply appends .{vlan#} to the already  named device when creating a new vlan netdevice.

BIOS definitely doesn't know about these, as they aren't exposed until
after the OS is running, so the mechanism that creates them (such as
following modprobe ixgbevf) would have to, and I think that can be
done with a udev rule, if we can somehow expose the port number of the
underlying PF when we throw the message to udev on creation of the VF.

And of course, BIOS knows nothing about vlans, so vconfig would add that.


If we have no more than 99 PCI slots, no more than 99 ports on a
single card, no more than 999 instances/virtual functions (we need at
least 128, perhaps more than 256 at some point, so hex vs decimal
doesn't buy us much here), no more than 4k VLANs, we get:

len("pci99#99/999.4095") = 17

If we really have that many, we're in trouble in other ways, so let's
hope that's good enough.

Thoughts?  Overkill?

Thanks,
Matt

-- 
Matt Domsch
Technology Strategist
Dell | Office of the CTO

^ permalink raw reply

* Re: [PATCH net-next 1/4] rtnetlink: Link address family API
From: Thomas Graf @ 2010-11-17 22:58 UTC (permalink / raw)
  To: David Miller; +Cc: netdev
In-Reply-To: <20101117.113035.229752488.davem@davemloft.net>

On Wed, Nov 17, 2010 at 11:30:35AM -0800, David Miller wrote:
> Applied, but note that as-implemented it has the "partial update"
> problem.  When we can't get the af-specific ops for a "parse"
> operation, we just skip that AF yet we let the modifications of
> the other AF's succeed and make it appear to the user that
> everything got updated and all the attributes were consumed.
> 
> I don't know what we can do about this with how things work
> right now.

I absolutely agree and this problem isn't limited to this specific
case at all. All netlink based implementations I am aware of will
silently skip over any unknown attribute type and thus only apply
updates partially.

What I can will do in this specific case is check if all af ops
can be looked up before starting to update things.

Some of the newer netlink interfaces are actually both atomic and
always leave a consistent state. For those which do not I strongly
believe that we should limit inconsistency to a minimum were
possible but leave any kind of fallback mechanism to userspace. I
am experimenting with this in userspace. By listening to
notifications and with the help of sequence numbers it is possible
to reliably switch back to a previous "version" of a link, address,
... even if there are multiple writers.

^ permalink raw reply

* [RFC PATCH] ethtool: allow setting MDI-X state
From: Jesse Brandeburg @ 2010-11-17 23:16 UTC (permalink / raw)
  To: netdev, bhutchings

ethtool recently added support for reading MDI-X state, this
patch finishes the implementation, adding the complementary write
command.

Add support to ethtool for controlling the MDI-X (crossover)
state of a network port.  Most adapters correctly negotiate
MDI-X, but some ill-behaved switches have trouble and end up
picking the wrong MDI setting, which results in complete loss of
link.  Usually this error condition can be observed with multiple
ethtool -r ethX required before link is achieved.

usage is ethtool -s eth0 mdix [auto|on|off]

Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
---

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

diff --git a/ethtool.8 b/ethtool.8
index 1760924..c96e35d 100644
--- a/ethtool.8
+++ b/ethtool.8
@@ -196,6 +196,7 @@ ethtool \- Display or change ethernet card settings
 .BI speed \ N
 .B2 duplex half full
 .B4 port tp aui bnc mii fibre
+.B3 mdix auto on off
 .B2 autoneg on off
 .RB [ advertise
 .IR N ]
@@ -452,6 +453,13 @@ Sets full or half duplex mode.
 .A4 port tp aui bnc mii fibre
 Selects device port.
 .TP
+.A3 mdix auto on off
+Selects MDI-X mode for port. May be used to override the automatic detection
+feature of most adapters.  Auto means automatic detection of MDI status, on
+forces MDI-X (crossover) mode, while off means MDI (straight through) mode.
+Depending on implementation an ethtool -r ethX command may be necessary to
+cause the change to take effect.
+.TP
 .A2 autoneg on off
 Specifies whether autonegotiation should be enabled. Autonegotiation 
 is enabled by deafult, but in some network devices may have trouble
diff --git a/ethtool.c b/ethtool.c
index 239912b..fcc7998 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -157,6 +157,7 @@ static struct option {
 		"		[ speed %d ]\n"
 		"		[ duplex half|full ]\n"
 		"		[ port tp|aui|bnc|mii|fibre ]\n"
+		"		[ mdix auto|on|off ]\n"
 		"		[ autoneg on|off ]\n"
 		"		[ advertise %x ]\n"
 		"		[ phyad %d ]\n"
@@ -353,6 +354,7 @@ static s32 coal_tx_frames_high_wanted = -1;
 static int speed_wanted = -1;
 static int duplex_wanted = -1;
 static int port_wanted = -1;
+static int mdix_wanted = -1;
 static int autoneg_wanted = -1;
 static int phyad_wanted = -1;
 static int xcvr_wanted = -1;
@@ -1048,6 +1050,20 @@ static void parse_cmdline(int argc, char **argp)
 				else
 					show_usage(1);
 				break;
+			} else if (!strcmp(argp[i], "mdix")) {
+				gset_changed = 1;
+				i += 1;
+				if (i >= argc)
+					show_usage(1);
+				if (!strcmp(argp[i], "auto"))
+					mdix_wanted = ETH_TP_MDI_INVALID;
+				else if (!strcmp(argp[i], "on"))
+					mdix_wanted = ETH_TP_MDI_X;
+				else if (!strcmp(argp[i], "off"))
+					mdix_wanted = ETH_TP_MDI;
+				else
+					show_usage(1);
+				break;
 			} else if (!strcmp(argp[i], "autoneg")) {
 				i += 1;
 				if (i >= argc)
@@ -1124,6 +1140,20 @@ static void parse_cmdline(int argc, char **argp)
 					i = argc;
 				}
 				break;
+			} else if (!strcmp(argp[i], "mdix")) {
+				gset_changed = 1;
+				i += 1;
+				if (i >= argc)
+					show_usage(1);
+				if (!strcmp(argp[i], "auto"))
+					mdix_wanted = ETH_TP_MDI_INVALID;
+				else if (!strcmp(argp[i], "on"))
+					mdix_wanted = ETH_TP_MDI_X;
+				else if (!strcmp(argp[i], "off"))
+					mdix_wanted = ETH_TP_MDI;
+				else
+					show_usage(1);
+				break;
 			}
 			show_usage(1);
 		}
@@ -2525,6 +2555,8 @@ static int do_sset(int fd, struct ifreq *ifr)
 				ecmd.duplex = duplex_wanted;
 			if (port_wanted != -1)
 				ecmd.port = port_wanted;
+			if (mdix_wanted != -1)
+				ecmd.eth_tp_mdix = mdix_wanted;
 			if (autoneg_wanted != -1)
 				ecmd.autoneg = autoneg_wanted;
 			if (phyad_wanted != -1)
@@ -2566,6 +2598,8 @@ static int do_sset(int fd, struct ifreq *ifr)
 				fprintf(stderr, "  not setting phy_address\n");
 			if (xcvr_wanted != -1)
 				fprintf(stderr, "  not setting transceiver\n");
+			if (mdix_wanted != -1)
+				fprintf(stderr, "  not setting mdix\n");
 		}
 	}
 


^ permalink raw reply related

* [RFC PATCH 0/3] e1000/e1000e/igb MDI-X control implementation
From: Jesse Brandeburg @ 2010-11-17 23:29 UTC (permalink / raw)
  To: netdev

this patch series is RFC for implemenation, I've briefly tested
it to make sure I still get link after setting MDI-X and I see
the status change in ethtool.

The basic idea is to fill out the MDI-X read functionality with
some write functionality.

the e1000e patch is actually what drove this change as some users
have found wonky switches that must have MDI/MDI-X forced.

---

Jesse Brandeburg (3):
      e1000: configure and read mdix settings
      igb: update to allow reading/setting mdix
      e1000e: implement MDI-X control


 drivers/net/e1000/e1000.h         |    1 -
 drivers/net/e1000/e1000_ethtool.c |   13 +++++++++++++
 drivers/net/e1000/e1000_main.c    |    2 +-
 drivers/net/e1000e/e1000.h        |    1 -
 drivers/net/e1000e/ethtool.c      |    4 ++++
 drivers/net/e1000e/netdev.c       |    2 +-
 drivers/net/igb/igb.h             |    1 -
 drivers/net/igb/igb_ethtool.c     |   14 ++++++++++++++
 drivers/net/igb/igb_main.c        |    2 +-
 9 files changed, 34 insertions(+), 6 deletions(-)

-- 
jesse.brandeburg@intel.com

^ permalink raw reply

* [RFC PATCH 1/3] e1000e: implement MDI-X control
From: Jesse Brandeburg @ 2010-11-17 23:29 UTC (permalink / raw)
  To: netdev
In-Reply-To: <20101117232645.3513.20655.stgit@jbrandeb-ich9b.jf.intel.com>

some users report issues with link failing when connected
to certain switches.  This gives the user the ability to
control the MDI-X state from the driver.

This is in regards to the related ethtool patch and
bugzilla.kernel.org bug 11998

Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
CC: bruce.w.allan@intel.com
CC: n.poppelier@xs4all.nl
CC: bastien@durel.org
CC: jsveiga@it.eng.br
---

 drivers/net/e1000e/e1000.h   |    1 -
 drivers/net/e1000e/ethtool.c |    4 ++++
 drivers/net/e1000e/netdev.c  |    2 +-
 3 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/net/e1000e/e1000.h b/drivers/net/e1000e/e1000.h
index fdc67fe..10469b2 100644
--- a/drivers/net/e1000e/e1000.h
+++ b/drivers/net/e1000e/e1000.h
@@ -81,7 +81,6 @@ struct e1000_info;
 /* How many Rx Buffers do we bundle into one write to the hardware ? */
 #define E1000_RX_BUFFER_WRITE		16 /* Must be power of 2 */
 
-#define AUTO_ALL_MODES			0
 #define E1000_EEPROM_APME		0x0400
 
 #define E1000_MNG_VLAN_NONE		(-1)
diff --git a/drivers/net/e1000e/ethtool.c b/drivers/net/e1000e/ethtool.c
index 8984d16..f518c9b 100644
--- a/drivers/net/e1000e/ethtool.c
+++ b/drivers/net/e1000e/ethtool.c
@@ -285,6 +285,10 @@ static int e1000_set_settings(struct net_device *netdev,
 		}
 	}
 
+	/* MDI-X => 2; MDI =>1; Auto =>0 */
+	if (ecmd->eth_tp_mdix && (hw->phy.media_type == e1000_media_type_copper))
+		hw->phy.mdix = ecmd->eth_tp_mdix;
+
 	/* reset the link */
 
 	if (netif_running(adapter->netdev)) {
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index 68e79c2..9e7d864 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -5842,7 +5842,7 @@ static int __devinit e1000_probe(struct pci_dev *pdev,
 
 	/* Copper options */
 	if (adapter->hw.phy.media_type == e1000_media_type_copper) {
-		adapter->hw.phy.mdix = AUTO_ALL_MODES;
+		adapter->hw.phy.mdix = ETH_TP_MDI_INVALID;
 		adapter->hw.phy.disable_polarity_correction = 0;
 		adapter->hw.phy.ms_type = e1000_ms_hw_default;
 	}


^ permalink raw reply related

* [RFC PATCH 3/3] e1000: configure and read mdix settings
From: Jesse Brandeburg @ 2010-11-17 23:29 UTC (permalink / raw)
  To: netdev
In-Reply-To: <20101117232645.3513.20655.stgit@jbrandeb-ich9b.jf.intel.com>

Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
---

 drivers/net/e1000/e1000.h         |    1 -
 drivers/net/e1000/e1000_ethtool.c |   13 +++++++++++++
 drivers/net/e1000/e1000_main.c    |    2 +-
 3 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/net/e1000/e1000.h b/drivers/net/e1000/e1000.h
index a881dd0..e2767ab 100644
--- a/drivers/net/e1000/e1000.h
+++ b/drivers/net/e1000/e1000.h
@@ -130,7 +130,6 @@ struct e1000_adapter;
 /* How many Rx Buffers do we bundle into one write to the hardware ? */
 #define E1000_RX_BUFFER_WRITE	16	/* Must be power of 2 */
 
-#define AUTO_ALL_MODES            0
 #define E1000_EEPROM_82544_APM    0x0004
 #define E1000_EEPROM_APME         0x0400
 
diff --git a/drivers/net/e1000/e1000_ethtool.c b/drivers/net/e1000/e1000_ethtool.c
index f4d0922..5e2c83f 100644
--- a/drivers/net/e1000/e1000_ethtool.c
+++ b/drivers/net/e1000/e1000_ethtool.c
@@ -174,6 +174,14 @@ static int e1000_get_settings(struct net_device *netdev,
 
 	ecmd->autoneg = ((hw->media_type == e1000_media_type_fiber) ||
 			 hw->autoneg) ? AUTONEG_ENABLE : AUTONEG_DISABLE;
+
+	/* MDI-X => 2; MDI =>1; Invalid =>0 */
+	if ((hw->media_type == e1000_media_type_copper) &&
+	    netif_carrier_ok(netdev))
+		ecmd->eth_tp_mdix = hw->mdix;
+	else
+		ecmd->eth_tp_mdix = ETH_TP_MDI_INVALID;
+
 	return 0;
 }
 
@@ -203,6 +211,11 @@ static int e1000_set_settings(struct net_device *netdev,
 			return -EINVAL;
 		}
 
+	/* MDI-X => 2; MDI =>1; Auto =>0 */
+	if ((ecmd->eth_tp_mdix != -1) &&
+	    (hw->media_type == e1000_media_type_copper))
+		hw->mdix = ecmd->eth_tp_mdix;
+
 	/* reset the link */
 
 	if (netif_running(adapter->netdev)) {
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 4686c39..0252a01 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -860,7 +860,7 @@ static int e1000_init_hw_struct(struct e1000_adapter *adapter,
 	/* Copper options */
 
 	if (hw->media_type == e1000_media_type_copper) {
-		hw->mdix = AUTO_ALL_MODES;
+		hw->mdix = ETH_TP_MDI_INVALID;
 		hw->disable_polarity_correction = false;
 		hw->master_slave = E1000_MASTER_SLAVE;
 	}


^ permalink raw reply related

* [RFC PATCH 2/3] igb: update to allow reading/setting mdix
From: Jesse Brandeburg @ 2010-11-17 23:29 UTC (permalink / raw)
  To: netdev
In-Reply-To: <20101117232645.3513.20655.stgit@jbrandeb-ich9b.jf.intel.com>

Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
CC: Carolyn Wyborny <carolyn.wyborny@intel.com>
---

 drivers/net/igb/igb.h         |    1 -
 drivers/net/igb/igb_ethtool.c |   14 ++++++++++++++
 drivers/net/igb/igb_main.c    |    2 +-
 3 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/net/igb/igb.h b/drivers/net/igb/igb.h
index edab9c4..04f7a05 100644
--- a/drivers/net/igb/igb.h
+++ b/drivers/net/igb/igb.h
@@ -120,7 +120,6 @@ struct vf_data_storage {
 /* How many Rx Buffers do we bundle into one write to the hardware ? */
 #define IGB_RX_BUFFER_WRITE	16	/* Must be power of 2 */
 
-#define AUTO_ALL_MODES            0
 #define IGB_EEPROM_APME         0x0400
 
 #ifndef IGB_MASTER_SLAVE
diff --git a/drivers/net/igb/igb_ethtool.c b/drivers/net/igb/igb_ethtool.c
index a70e16b..bfeee01 100644
--- a/drivers/net/igb/igb_ethtool.c
+++ b/drivers/net/igb/igb_ethtool.c
@@ -191,6 +191,15 @@ static int igb_get_settings(struct net_device *netdev, struct ethtool_cmd *ecmd)
 	}
 
 	ecmd->autoneg = hw->mac.autoneg ? AUTONEG_ENABLE : AUTONEG_DISABLE;
+
+	/* MDI-X => 2; MDI =>1; Invalid =>0 */
+	if ((hw->phy.media_type == e1000_media_type_copper) &&
+	    netif_carrier_ok(netdev))
+		ecmd->eth_tp_mdix = hw->phy.is_mdix ? ETH_TP_MDI_X :
+		                                      ETH_TP_MDI;
+	else
+		ecmd->eth_tp_mdix = ETH_TP_MDI_INVALID;
+
 	return 0;
 }
 
@@ -225,6 +234,11 @@ static int igb_set_settings(struct net_device *netdev, struct ethtool_cmd *ecmd)
 		}
 	}
 
+	/* MDI-X => 2; MDI =>1; Auto =>0 */
+	if ((ecmd->eth_tp_mdix != -1) &&
+	    (hw->phy.media_type == e1000_media_type_copper))
+		hw->phy.mdix = ecmd->eth_tp_mdix;
+
 	/* reset the link */
 	if (netif_running(adapter->netdev)) {
 		igb_down(adapter);
diff --git a/drivers/net/igb/igb_main.c b/drivers/net/igb/igb_main.c
index 892d196..338825f 100644
--- a/drivers/net/igb/igb_main.c
+++ b/drivers/net/igb/igb_main.c
@@ -1838,7 +1838,7 @@ static int __devinit igb_probe(struct pci_dev *pdev,
 
 	/* Copper options */
 	if (hw->phy.media_type == e1000_media_type_copper) {
-		hw->phy.mdix = AUTO_ALL_MODES;
+		hw->phy.mdix = ETH_TP_MDI_INVALID;
 		hw->phy.disable_polarity_correction = false;
 		hw->phy.ms_type = e1000_ms_hw_default;
 	}


^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox