<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/drivers/net, branch v3.18-rc3</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>Merge tag 'master-2014-10-30' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless</title>
<updated>2014-10-31T20:18:35+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2014-10-31T20:18:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=99a49ce613057f1934e1c378808374fd683b1541'/>
<id>99a49ce613057f1934e1c378808374fd683b1541</id>
<content type='text'>
John W. Linville says:

====================
pull request: wireless 2014-10-31

Please pull this small batch of spooky fixes intended for the 3.18
stream...boo!

Cyril Brulebois adds an rt2x00 device ID.

Dan Carpenter provides a one-line masking fix for an ath9k debugfs
entry.

Larry Finger gives us a package of small rtlwifi fixes which add some
bits that were left out of some feature updates that were included
in the merge window.  Hopefully this isn't a sign that the rtlwifi
base is getting too big...

Marc Yang brings a fix for a temporary mwifiex stall when doing 11n
RX reordering.

Please let me know if there are problems!
====================

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
John W. Linville says:

====================
pull request: wireless 2014-10-31

Please pull this small batch of spooky fixes intended for the 3.18
stream...boo!

Cyril Brulebois adds an rt2x00 device ID.

Dan Carpenter provides a one-line masking fix for an ath9k debugfs
entry.

Larry Finger gives us a package of small rtlwifi fixes which add some
bits that were left out of some feature updates that were included
in the merge window.  Hopefully this isn't a sign that the rtlwifi
base is getting too big...

Marc Yang brings a fix for a temporary mwifiex stall when doing 11n
RX reordering.

Please let me know if there are problems!
====================

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drivers: net: cpsw: Support ALLMULTI and fix IFF_PROMISC in switch mode</title>
<updated>2014-10-31T20:17:56+00:00</updated>
<author>
<name>Lennart Sorensen</name>
<email>lsorense@csclub.uwaterloo.ca</email>
</author>
<published>2014-10-31T17:38:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=1e5c4bc497c0a96e1ad2974539d353870f2cb0b6'/>
<id>1e5c4bc497c0a96e1ad2974539d353870f2cb0b6</id>
<content type='text'>
The cpsw driver did not support the IFF_ALLMULTI flag which makes dynamic
multicast routing not work.  Related to this, when enabling IFF_PROMISC
in switch mode, all registered multicast addresses are flushed, resulting
in only broadcast and unicast traffic being received.

A new cpsw_ale_set_allmulti function now scans through the ALE entry
table and adds/removes the host port from the unregistered multicast
port mask of each vlan entry depending on the state of IFF_ALLMULTI.
In promiscious mode, cpsw_ale_set_allmulti is used to force reception
of all multicast traffic in addition to the unicast and broadcast traffic.

With this change dynamic multicast and promiscious mode both work in
switch mode.

Signed-off-by: Len Sorensen &lt;lsorense@csclub.uwaterloo.ca&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The cpsw driver did not support the IFF_ALLMULTI flag which makes dynamic
multicast routing not work.  Related to this, when enabling IFF_PROMISC
in switch mode, all registered multicast addresses are flushed, resulting
in only broadcast and unicast traffic being received.

A new cpsw_ale_set_allmulti function now scans through the ALE entry
table and adds/removes the host port from the unregistered multicast
port mask of each vlan entry depending on the state of IFF_ALLMULTI.
In promiscious mode, cpsw_ale_set_allmulti is used to force reception
of all multicast traffic in addition to the unicast and broadcast traffic.

With this change dynamic multicast and promiscious mode both work in
switch mode.

Signed-off-by: Len Sorensen &lt;lsorense@csclub.uwaterloo.ca&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drivers: net: cpsw: Fix broken loop condition in switch mode</title>
<updated>2014-10-31T20:17:56+00:00</updated>
<author>
<name>Lennart Sorensen</name>
<email>lsorense@csclub.uwaterloo.ca</email>
</author>
<published>2014-10-31T17:28:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=6f979eb3fcfb4c3f42f230d174db4bbad0080710'/>
<id>6f979eb3fcfb4c3f42f230d174db4bbad0080710</id>
<content type='text'>
0d961b3b52f566f823070ce2366511a7f64b928c (drivers: net: cpsw: fix buggy
loop condition) accidentally fixed a loop comparison in too many places
while fixing a real bug.

It was correct to fix the dual_emac mode section since there 'i' is used
as an index into priv-&gt;slaves which is a 0 based array.

However the other two changes (which are only used in switch mode)
are wrong since there 'i' is actually the ALE port number, and port 0
is the host port, while port 1 and up are the slave ports.

Putting the loop condition back in the switch mode section fixes it.

A comment has been added to point out the intent clearly to avoid future
confusion.  Also a comment is fixed that said the opposite of what was
actually happening.

Signed-off-by: Len Sorensen &lt;lsorense@csclub.uwaterloo.ca&gt;
Acked-by: Heiko Schocher &lt;hs@denx.de&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
0d961b3b52f566f823070ce2366511a7f64b928c (drivers: net: cpsw: fix buggy
loop condition) accidentally fixed a loop comparison in too many places
while fixing a real bug.

It was correct to fix the dual_emac mode section since there 'i' is used
as an index into priv-&gt;slaves which is a 0 based array.

However the other two changes (which are only used in switch mode)
are wrong since there 'i' is actually the ALE port number, and port 0
is the host port, while port 1 and up are the slave ports.

Putting the loop condition back in the switch mode section fixes it.

A comment has been added to point out the intent clearly to avoid future
confusion.  Also a comment is fixed that said the opposite of what was
actually happening.

Signed-off-by: Len Sorensen &lt;lsorense@csclub.uwaterloo.ca&gt;
Acked-by: Heiko Schocher &lt;hs@denx.de&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>stmmac: pci: set default of the filter bins</title>
<updated>2014-10-31T20:09:57+00:00</updated>
<author>
<name>Andy Shevchenko</name>
<email>andriy.shevchenko@linux.intel.com</email>
</author>
<published>2014-10-31T16:28:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=1e19e084eae727654052339757ab7f1eaff58bad'/>
<id>1e19e084eae727654052339757ab7f1eaff58bad</id>
<content type='text'>
The commit 3b57de958e2a brought the support for a different amount of the
filter bins, but didn't update the PCI driver accordingly. This patch appends
the default values when the device is enumerated via PCI bus.

Fixes: 3b57de958e2a (net: stmmac: Support devicetree configs for mcast and ucast filter entries)
Signed-off-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The commit 3b57de958e2a brought the support for a different amount of the
filter bins, but didn't update the PCI driver accordingly. This patch appends
the default values when the device is enumerated via PCI bus.

Fixes: 3b57de958e2a (net: stmmac: Support devicetree configs for mcast and ucast filter entries)
Signed-off-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: smc91x: Fix gpios for device tree based booting</title>
<updated>2014-10-31T19:54:18+00:00</updated>
<author>
<name>Tony Lindgren</name>
<email>tony@atomide.com</email>
</author>
<published>2014-10-30T16:59:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=7d2911c4381555b31ef0bcae42a0dbf9ade7426e'/>
<id>7d2911c4381555b31ef0bcae42a0dbf9ade7426e</id>
<content type='text'>
With legacy booting, the platform init code was taking care of
the configuring of GPIOs. With device tree based booting, things
may or may not work depending what bootloader has configured or
if the legacy platform code gets called.

Let's add support for the pwrdn and reset GPIOs to the smc91x
driver to fix the issues of smc91x not working properly when
booted in device tree mode.

And let's change n900 to use these settings as some versions
of the bootloader do not configure things properly causing
errors.

Reported-by: Kevin Hilman &lt;khilman@linaro.org&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
With legacy booting, the platform init code was taking care of
the configuring of GPIOs. With device tree based booting, things
may or may not work depending what bootloader has configured or
if the legacy platform code gets called.

Let's add support for the pwrdn and reset GPIOs to the smc91x
driver to fix the issues of smc91x not working properly when
booted in device tree mode.

And let's change n900 to use these settings as some versions
of the bootloader do not configure things properly causing
errors.

Reported-by: Kevin Hilman &lt;khilman@linaro.org&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>r8152: stop submitting intr for -EPROTO</title>
<updated>2014-10-31T17:55:10+00:00</updated>
<author>
<name>hayeswang</name>
<email>hayeswang@realtek.com</email>
</author>
<published>2014-10-31T05:35:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=d59c876dd61f3c151db077f9d73774e605f2b35e'/>
<id>d59c876dd61f3c151db077f9d73774e605f2b35e</id>
<content type='text'>
For Renesas USB 3.0 host controller, when unplugging the usb hub which
has the RTL8153 plugged, the driver would get -EPROTO for interrupt
transfer. There is high probability to get the information of "HC died;
cleaning up", if the driver continues to submit the interrupt transfer
before the disconnect() is called.

[ 1024.197678] r8152 9-1.4:1.0 eth0: intr status -71
[ 1024.213673] r8152 9-1.4:1.0 eth0: intr status -71
[ 1024.229668] r8152 9-1.4:1.0 eth0: intr status -71
[ 1024.245661] r8152 9-1.4:1.0 eth0: intr status -71
[ 1024.261653] r8152 9-1.4:1.0 eth0: intr status -71
[ 1024.277648] r8152 9-1.4:1.0 eth0: intr status -71
[ 1024.293642] r8152 9-1.4:1.0 eth0: intr status -71
[ 1024.309638] r8152 9-1.4:1.0 eth0: intr status -71
[ 1024.325633] r8152 9-1.4:1.0 eth0: intr status -71
[ 1024.341627] r8152 9-1.4:1.0 eth0: intr status -71
[ 1024.357621] r8152 9-1.4:1.0 eth0: intr status -71
[ 1024.373615] r8152 9-1.4:1.0 eth0: intr status -71
[ 1024.383097] usb 9-1: USB disconnect, device number 2
[ 1024.383103] usb 9-1.4: USB disconnect, device number 6
[ 1029.391010] xhci_hcd 0000:04:00.0: xHCI host not responding to stop endpoint command.
[ 1029.391016] xhci_hcd 0000:04:00.0: Assuming host is dying, halting host.
[ 1029.392551] xhci_hcd 0000:04:00.0: HC died; cleaning up
[ 1029.421480] usb 8-1: USB disconnect, device number 2

Signed-off-by: Hayes Wang &lt;hayeswang@realtek.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
For Renesas USB 3.0 host controller, when unplugging the usb hub which
has the RTL8153 plugged, the driver would get -EPROTO for interrupt
transfer. There is high probability to get the information of "HC died;
cleaning up", if the driver continues to submit the interrupt transfer
before the disconnect() is called.

[ 1024.197678] r8152 9-1.4:1.0 eth0: intr status -71
[ 1024.213673] r8152 9-1.4:1.0 eth0: intr status -71
[ 1024.229668] r8152 9-1.4:1.0 eth0: intr status -71
[ 1024.245661] r8152 9-1.4:1.0 eth0: intr status -71
[ 1024.261653] r8152 9-1.4:1.0 eth0: intr status -71
[ 1024.277648] r8152 9-1.4:1.0 eth0: intr status -71
[ 1024.293642] r8152 9-1.4:1.0 eth0: intr status -71
[ 1024.309638] r8152 9-1.4:1.0 eth0: intr status -71
[ 1024.325633] r8152 9-1.4:1.0 eth0: intr status -71
[ 1024.341627] r8152 9-1.4:1.0 eth0: intr status -71
[ 1024.357621] r8152 9-1.4:1.0 eth0: intr status -71
[ 1024.373615] r8152 9-1.4:1.0 eth0: intr status -71
[ 1024.383097] usb 9-1: USB disconnect, device number 2
[ 1024.383103] usb 9-1.4: USB disconnect, device number 6
[ 1029.391010] xhci_hcd 0000:04:00.0: xHCI host not responding to stop endpoint command.
[ 1029.391016] xhci_hcd 0000:04:00.0: Assuming host is dying, halting host.
[ 1029.392551] xhci_hcd 0000:04:00.0: HC died; cleaning up
[ 1029.421480] usb 8-1: USB disconnect, device number 2

Signed-off-by: Hayes Wang &lt;hayeswang@realtek.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drivers/net: macvtap and tun depend on INET</title>
<updated>2014-10-31T03:50:26+00:00</updated>
<author>
<name>Ben Hutchings</name>
<email>ben@decadent.org.uk</email>
</author>
<published>2014-10-31T03:10:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=de11b0e8c569b96c2cf6a811e3805b7aeef498a3'/>
<id>de11b0e8c569b96c2cf6a811e3805b7aeef498a3</id>
<content type='text'>
These drivers now call ipv6_proxy_select_ident(), which is defined
only if CONFIG_INET is enabled.  However, they have really depended
on CONFIG_INET for as long as they have allowed sending GSO packets
from userland.

Reported-by: kbuild test robot &lt;fengguang.wu@intel.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Fixes: f43798c27684 ("tun: Allow GSO using virtio_net_hdr")
Fixes: b9fb9ee07e67 ("macvtap: add GSO/csum offload support")
Fixes: 5188cd44c55d ("drivers/net, ipv6: Select IPv6 fragment idents for virtio UFO packets")
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
These drivers now call ipv6_proxy_select_ident(), which is defined
only if CONFIG_INET is enabled.  However, they have really depended
on CONFIG_INET for as long as they have allowed sending GSO packets
from userland.

Reported-by: kbuild test robot &lt;fengguang.wu@intel.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Fixes: f43798c27684 ("tun: Allow GSO using virtio_net_hdr")
Fixes: b9fb9ee07e67 ("macvtap: add GSO/csum offload support")
Fixes: 5188cd44c55d ("drivers/net, ipv6: Select IPv6 fragment idents for virtio UFO packets")
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drivers/net, ipv6: Select IPv6 fragment idents for virtio UFO packets</title>
<updated>2014-10-31T00:01:18+00:00</updated>
<author>
<name>Ben Hutchings</name>
<email>ben@decadent.org.uk</email>
</author>
<published>2014-10-30T18:27:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=5188cd44c55db3e92cd9e77a40b5baa7ed4340f7'/>
<id>5188cd44c55db3e92cd9e77a40b5baa7ed4340f7</id>
<content type='text'>
UFO is now disabled on all drivers that work with virtio net headers,
but userland may try to send UFO/IPv6 packets anyway.  Instead of
sending with ID=0, we should select identifiers on their behalf (as we
used to).

Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Fixes: 916e4cf46d02 ("ipv6: reuse ip6_frag_id from ip6_ufo_append_data")
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
UFO is now disabled on all drivers that work with virtio net headers,
but userland may try to send UFO/IPv6 packets anyway.  Instead of
sending with ID=0, we should select identifiers on their behalf (as we
used to).

Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Fixes: 916e4cf46d02 ("ipv6: reuse ip6_frag_id from ip6_ufo_append_data")
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drivers/net: Disable UFO through virtio</title>
<updated>2014-10-31T00:01:18+00:00</updated>
<author>
<name>Ben Hutchings</name>
<email>ben@decadent.org.uk</email>
</author>
<published>2014-10-30T18:27:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=3d0ad09412ffe00c9afa201d01effdb6023d09b4'/>
<id>3d0ad09412ffe00c9afa201d01effdb6023d09b4</id>
<content type='text'>
IPv6 does not allow fragmentation by routers, so there is no
fragmentation ID in the fixed header.  UFO for IPv6 requires the ID to
be passed separately, but there is no provision for this in the virtio
net protocol.

Until recently our software implementation of UFO/IPv6 generated a new
ID, but this was a bug.  Now we will use ID=0 for any UFO/IPv6 packet
passed through a tap, which is even worse.

Unfortunately there is no distinction between UFO/IPv4 and v6
features, so disable UFO on taps and virtio_net completely until we
have a proper solution.

We cannot depend on VM managers respecting the tap feature flags, so
keep accepting UFO packets but log a warning the first time we do
this.

Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Fixes: 916e4cf46d02 ("ipv6: reuse ip6_frag_id from ip6_ufo_append_data")
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
IPv6 does not allow fragmentation by routers, so there is no
fragmentation ID in the fixed header.  UFO for IPv6 requires the ID to
be passed separately, but there is no provision for this in the virtio
net protocol.

Until recently our software implementation of UFO/IPv6 generated a new
ID, but this was a bug.  Now we will use ID=0 for any UFO/IPv6 packet
passed through a tap, which is even worse.

Unfortunately there is no distinction between UFO/IPv4 and v6
features, so disable UFO on taps and virtio_net completely until we
have a proper solution.

We cannot depend on VM managers respecting the tap feature flags, so
keep accepting UFO packets but log a warning the first time we do
this.

Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Fixes: 916e4cf46d02 ("ipv6: reuse ip6_frag_id from ip6_ufo_append_data")
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mlx4: Avoid leaking steering rules on flow creation error flow</title>
<updated>2014-10-30T23:48:58+00:00</updated>
<author>
<name>Or Gerlitz</name>
<email>ogerlitz@mellanox.com</email>
</author>
<published>2014-10-30T13:59:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=571e1b2c7a4c2fd5faa1648462a6b65fa26530d7'/>
<id>571e1b2c7a4c2fd5faa1648462a6b65fa26530d7</id>
<content type='text'>
If mlx4_ib_create_flow() attempts to create &gt; 1 rules with the
firmware, and one of these registrations fail, we leaked the
already created flow rules.

One example of the leak is when the registration of the VXLAN ghost
steering rule fails, we didn't unregister the original rule requested
by the user, introduced in commit d2fce8a9060d "mlx4: Set
user-space raw Ethernet QPs to properly handle VXLAN traffic".

While here, add dump of the VXLAN portion of steering rules
so it can actually be seen when flow creation fails.

Signed-off-by: Or Gerlitz &lt;ogerlitz@mellanox.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If mlx4_ib_create_flow() attempts to create &gt; 1 rules with the
firmware, and one of these registrations fail, we leaked the
already created flow rules.

One example of the leak is when the registration of the VXLAN ghost
steering rule fails, we didn't unregister the original rule requested
by the user, introduced in commit d2fce8a9060d "mlx4: Set
user-space raw Ethernet QPs to properly handle VXLAN traffic".

While here, add dump of the VXLAN portion of steering rules
so it can actually be seen when flow creation fails.

Signed-off-by: Or Gerlitz &lt;ogerlitz@mellanox.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
</feed>
