<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/net/usb, branch v4.6.2</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>asix: Fix offset calculation in asix_rx_fixup() causing slow transmissions</title>
<updated>2016-06-01T19:17:58+00:00</updated>
<author>
<name>John Stultz</name>
<email>john.stultz@linaro.org</email>
</author>
<published>2016-05-17T03:36:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f40ec93496a7c63346fc5f3ac80442c82ebad6a2'/>
<id>f40ec93496a7c63346fc5f3ac80442c82ebad6a2</id>
<content type='text'>
commit cd9e2e5d3ff148be9ea210f622ce3e8e8292fcd6 upstream.

In testing with HiKey, we found that since
commit 3f30b158eba5 ("asix: On RX avoid creating bad Ethernet
frames"),
we're seeing lots of noise during network transfers:

[  239.027993] asix 1-1.1:1.0 eth0: asix_rx_fixup() Data Header synchronisation was lost, remaining 988
[  239.037310] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 0x54ebb5ec, offset 4
[  239.045519] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 0xcdffe7a2, offset 4
[  239.275044] asix 1-1.1:1.0 eth0: asix_rx_fixup() Data Header synchronisation was lost, remaining 988
[  239.284355] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 0x1d36f59d, offset 4
[  239.292541] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 0xaef3c1e9, offset 4
[  239.518996] asix 1-1.1:1.0 eth0: asix_rx_fixup() Data Header synchronisation was lost, remaining 988
[  239.528300] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 0x2881912, offset 4
[  239.536413] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 0x5638f7e2, offset 4

And network throughput ends up being pretty bursty and slow with
a overall throughput of at best ~30kB/s (where as previously we
got 1.1MB/s with the slower USB1.1 "full speed" host).

We found the issue also was reproducible on a x86_64 system,
using a "high-speed" USB2.0 port but the throughput did not
measurably drop (possibly due to the scp transfer being cpu
bound on my slow test hardware).

After lots of debugging, I found the check added in the
problematic commit seems to be calculating the offset
incorrectly.

In the normal case, in the main loop of the function, we do:
(where offset is zero, or set to "offset += (copy_length + 1) &amp;
0xfffe" in the previous loop)
    rx-&gt;header = get_unaligned_le32(skb-&gt;data +
                                    offset);
    offset += sizeof(u32);

But the problematic patch calculates:
    offset = ((rx-&gt;remaining + 1) &amp; 0xfffe) + sizeof(u32);
    rx-&gt;header = get_unaligned_le32(skb-&gt;data + offset);

Adding some debug logic to check those offset calculation used
to find rx-&gt;header, the one in problematic code is always too
large by sizeof(u32).

Thus, this patch removes the incorrect " + sizeof(u32)" addition
in the problematic calculation, and resolves the issue.

Cc: Dean Jenkins &lt;Dean_Jenkins@mentor.com&gt;
Cc: "David B. Robins" &lt;linux@davidrobins.net&gt;
Cc: Mark Craske &lt;Mark_Craske@mentor.com&gt;
Cc: Emil Goode &lt;emilgoode@gmail.com&gt;
Cc: "David S. Miller" &lt;davem@davemloft.net&gt;
Cc: YongQin Liu &lt;yongqin.liu@linaro.org&gt;
Cc: Guodong Xu &lt;guodong.xu@linaro.org&gt;
Cc: Ivan Vecera &lt;ivecera@redhat.com&gt;
Cc: linux-usb@vger.kernel.org
Cc: netdev@vger.kernel.org
Reported-by: Yongqin Liu &lt;yongqin.liu@linaro.org&gt;
Signed-off-by: John Stultz &lt;john.stultz@linaro.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit cd9e2e5d3ff148be9ea210f622ce3e8e8292fcd6 upstream.

In testing with HiKey, we found that since
commit 3f30b158eba5 ("asix: On RX avoid creating bad Ethernet
frames"),
we're seeing lots of noise during network transfers:

[  239.027993] asix 1-1.1:1.0 eth0: asix_rx_fixup() Data Header synchronisation was lost, remaining 988
[  239.037310] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 0x54ebb5ec, offset 4
[  239.045519] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 0xcdffe7a2, offset 4
[  239.275044] asix 1-1.1:1.0 eth0: asix_rx_fixup() Data Header synchronisation was lost, remaining 988
[  239.284355] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 0x1d36f59d, offset 4
[  239.292541] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 0xaef3c1e9, offset 4
[  239.518996] asix 1-1.1:1.0 eth0: asix_rx_fixup() Data Header synchronisation was lost, remaining 988
[  239.528300] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 0x2881912, offset 4
[  239.536413] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 0x5638f7e2, offset 4

And network throughput ends up being pretty bursty and slow with
a overall throughput of at best ~30kB/s (where as previously we
got 1.1MB/s with the slower USB1.1 "full speed" host).

We found the issue also was reproducible on a x86_64 system,
using a "high-speed" USB2.0 port but the throughput did not
measurably drop (possibly due to the scp transfer being cpu
bound on my slow test hardware).

After lots of debugging, I found the check added in the
problematic commit seems to be calculating the offset
incorrectly.

In the normal case, in the main loop of the function, we do:
(where offset is zero, or set to "offset += (copy_length + 1) &amp;
0xfffe" in the previous loop)
    rx-&gt;header = get_unaligned_le32(skb-&gt;data +
                                    offset);
    offset += sizeof(u32);

But the problematic patch calculates:
    offset = ((rx-&gt;remaining + 1) &amp; 0xfffe) + sizeof(u32);
    rx-&gt;header = get_unaligned_le32(skb-&gt;data + offset);

Adding some debug logic to check those offset calculation used
to find rx-&gt;header, the one in problematic code is always too
large by sizeof(u32).

Thus, this patch removes the incorrect " + sizeof(u32)" addition
in the problematic calculation, and resolves the issue.

Cc: Dean Jenkins &lt;Dean_Jenkins@mentor.com&gt;
Cc: "David B. Robins" &lt;linux@davidrobins.net&gt;
Cc: Mark Craske &lt;Mark_Craske@mentor.com&gt;
Cc: Emil Goode &lt;emilgoode@gmail.com&gt;
Cc: "David S. Miller" &lt;davem@davemloft.net&gt;
Cc: YongQin Liu &lt;yongqin.liu@linaro.org&gt;
Cc: Guodong Xu &lt;guodong.xu@linaro.org&gt;
Cc: Ivan Vecera &lt;ivecera@redhat.com&gt;
Cc: linux-usb@vger.kernel.org
Cc: netdev@vger.kernel.org
Reported-by: Yongqin Liu &lt;yongqin.liu@linaro.org&gt;
Signed-off-by: John Stultz &lt;john.stultz@linaro.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>net/smscx5xx: use the device tree for mac address</title>
<updated>2016-05-02T00:57:45+00:00</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2016-04-29T07:05:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c489565b536ff5382460273fd9513f0adebec024'/>
<id>c489565b536ff5382460273fd9513f0adebec024</id>
<content type='text'>
This takes the MAC address for smsc75xx/smsc95xx USB network devices
from a the device tree. This is required to get a usable persistent
address on the popular beagleboard, whose hardware designers
accidentally forgot that an ethernet device really requires an a
MAC address to be functional.

The Raspberry Pi also ships smsc9514 without a serial EEPROM, stores
the MAC address in ROM accessible via VC4 firmware.

The smsc75xx and smsc95xx drivers are just two copies of the
same code, so better fix both.

[lkundrak@v3.sk: updated to use of_get_property() as per suggestion from
Arnd, reworded the message and comments a bit]

Tested-by: Lubomir Rintel &lt;lkundrak@v3.sk&gt;
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Lubomir Rintel &lt;lkundrak@v3.sk&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>
This takes the MAC address for smsc75xx/smsc95xx USB network devices
from a the device tree. This is required to get a usable persistent
address on the popular beagleboard, whose hardware designers
accidentally forgot that an ethernet device really requires an a
MAC address to be functional.

The Raspberry Pi also ships smsc9514 without a serial EEPROM, stores
the MAC address in ROM accessible via VC4 firmware.

The smsc75xx and smsc95xx drivers are just two copies of the
same code, so better fix both.

[lkundrak@v3.sk: updated to use of_get_property() as per suggestion from
Arnd, reworded the message and comments a bit]

Tested-by: Lubomir Rintel &lt;lkundrak@v3.sk&gt;
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Lubomir Rintel &lt;lkundrak@v3.sk&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>pegasus: fixes reported packet length</title>
<updated>2016-04-28T21:05:25+00:00</updated>
<author>
<name>Petko Manolov</name>
<email>petkan@mip-labs.com</email>
</author>
<published>2016-04-27T11:24:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1a8deec09d12c1a2946f131aa171d5e0479333de'/>
<id>1a8deec09d12c1a2946f131aa171d5e0479333de</id>
<content type='text'>
The default Pegasus setup was to append the status and CRC at the end of each
received packet.  The status bits are used to update various stats, but CRC has
been ignored.  The new default is to not append CRC at the end of RX packets.

Signed-off-by: Petko Manolov &lt;petkan@mip-labs.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>
The default Pegasus setup was to append the status and CRC at the end of each
received packet.  The status bits are used to update various stats, but CRC has
been ignored.  The new default is to not append CRC at the end of RX packets.

Signed-off-by: Petko Manolov &lt;petkan@mip-labs.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>pegasus: fixes URB buffer allocation size;</title>
<updated>2016-04-28T21:05:24+00:00</updated>
<author>
<name>Petko Manolov</name>
<email>petkan@mip-labs.com</email>
</author>
<published>2016-04-27T11:24:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b7302ca05871e50208bc328cbc8199a21f5d876e'/>
<id>b7302ca05871e50208bc328cbc8199a21f5d876e</id>
<content type='text'>
usb_fill_bulk_urb() receives buffer length parameter 8 bytes larger
than what's allocated by alloc_skb(); This seems to be a problem with
older (pegasus usb-1.1) devices, which may silently return more data
than the maximal packet length.

Reported-by: Lincoln Ramsay &lt;a1291762@gmail.com&gt;
Signed-off-by: Petko Manolov &lt;petkan@mip-labs.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>
usb_fill_bulk_urb() receives buffer length parameter 8 bytes larger
than what's allocated by alloc_skb(); This seems to be a problem with
older (pegasus usb-1.1) devices, which may silently return more data
than the maximal packet length.

Reported-by: Lincoln Ramsay &lt;a1291762@gmail.com&gt;
Signed-off-by: Petko Manolov &lt;petkan@mip-labs.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>lan78xx: workaround of forced 100 Full/Half duplex mode error</title>
<updated>2016-04-28T20:36:12+00:00</updated>
<author>
<name>Woojung Huh</name>
<email>woojung.huh@microchip.com</email>
</author>
<published>2016-04-25T22:22:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=14437e3fa284f465dbbc8611fd4331ca8d60e986'/>
<id>14437e3fa284f465dbbc8611fd4331ca8d60e986</id>
<content type='text'>
At forced 100 Full &amp; Half duplex mode, chip may fail to set mode correctly
when cable is switched between long(~50+m) and short one.
As workaround, set to 10 before setting to 100 at forced 100 F/H mode.

Signed-off-by: Woojung Huh &lt;woojung.huh@microchip.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>
At forced 100 Full &amp; Half duplex mode, chip may fail to set mode correctly
when cable is switched between long(~50+m) and short one.
As workaround, set to 10 before setting to 100 at forced 100 F/H mode.

Signed-off-by: Woojung Huh &lt;woojung.huh@microchip.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>lan78xx: fix statistics counter error</title>
<updated>2016-04-28T20:36:11+00:00</updated>
<author>
<name>Woojung Huh</name>
<email>woojung.huh@microchip.com</email>
</author>
<published>2016-04-25T22:22:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=74d79a2e30c476ccc7d45ecf978f38d815287f81'/>
<id>74d79a2e30c476ccc7d45ecf978f38d815287f81</id>
<content type='text'>
Fix rx_bytes, tx_bytes and tx_frames error in netdev.stats.
- rx_bytes counted bytes excluding size of struct ethhdr.
- tx_packets didn't count multiple packets in a single urb
- tx_bytes included 8 bytes of extra commands.

Signed-off-by: Woojung Huh &lt;woojung.huh@microchip.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>
Fix rx_bytes, tx_bytes and tx_frames error in netdev.stats.
- rx_bytes counted bytes excluding size of struct ethhdr.
- tx_packets didn't count multiple packets in a single urb
- tx_bytes included 8 bytes of extra commands.

Signed-off-by: Woojung Huh &lt;woojung.huh@microchip.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cdc_mbim: apply "NDP to end" quirk to all Huawei devices</title>
<updated>2016-04-15T01:04:04+00:00</updated>
<author>
<name>Bjørn Mork</name>
<email>bjorn@mork.no</email>
</author>
<published>2016-04-12T14:11:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c5b5343cfbc9f46af65033fa4f407d7b7d98371d'/>
<id>c5b5343cfbc9f46af65033fa4f407d7b7d98371d</id>
<content type='text'>
We now have a positive report of another Huawei device needing
this quirk: The ME906s-158 (12d1:15c1).  This is an m.2 form
factor modem with no obvious relationship to the E3372 (12d1:157d)
we already have a quirk entry for.  This is reason enough to
believe the quirk might be necessary for any number of current
and future Huawei devices.

Applying the quirk to all Huawei devices, since it is crucial
to any device affected by the firmware bug, while the impact
on non-affected devices is negligible.

The quirk can if necessary be disabled per-device by writing
N to /sys/class/net/&lt;iface&gt;/cdc_ncm/ndp_to_end

Reported-by: Andreas Fett &lt;andreas.fett@secunet.com&gt;
Signed-off-by: Bjørn Mork &lt;bjorn@mork.no&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>
We now have a positive report of another Huawei device needing
this quirk: The ME906s-158 (12d1:15c1).  This is an m.2 form
factor modem with no obvious relationship to the E3372 (12d1:157d)
we already have a quirk entry for.  This is reason enough to
believe the quirk might be necessary for any number of current
and future Huawei devices.

Applying the quirk to all Huawei devices, since it is crucial
to any device affected by the firmware bug, while the impact
on non-affected devices is negligible.

The quirk can if necessary be disabled per-device by writing
N to /sys/class/net/&lt;iface&gt;/cdc_ncm/ndp_to_end

Reported-by: Andreas Fett &lt;andreas.fett@secunet.com&gt;
Signed-off-by: Bjørn Mork &lt;bjorn@mork.no&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: usb: cdc_ncm: adding Telit LE910 V2 mobile broadband card</title>
<updated>2016-03-31T21:15:35+00:00</updated>
<author>
<name>Daniele Palmas</name>
<email>dnlplm@gmail.com</email>
</author>
<published>2016-03-31T13:16:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=79f4223257bfef52b0a26d0d7ad4019e764be6ce'/>
<id>79f4223257bfef52b0a26d0d7ad4019e764be6ce</id>
<content type='text'>
Telit LE910 V2 is a mobile broadband card with no ARP capabilities:
the patch makes this device to use wwan_noarp_info struct

Signed-off-by: Daniele Palmas &lt;dnlplm@gmail.com&gt;
Reviewed-by: Bjørn Mork &lt;bjorn@mork.no&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>
Telit LE910 V2 is a mobile broadband card with no ARP capabilities:
the patch makes this device to use wwan_noarp_info struct

Signed-off-by: Daniele Palmas &lt;dnlplm@gmail.com&gt;
Reviewed-by: Bjørn Mork &lt;bjorn@mork.no&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>qmi_wwan: add "D-Link DWM-221 B1" device id</title>
<updated>2016-03-29T00:12:01+00:00</updated>
<author>
<name>Bjørn Mork</name>
<email>bjorn@mork.no</email>
</author>
<published>2016-03-28T20:38:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e84810c7b85a2d7897797b3ad3e879168a8e032a'/>
<id>e84810c7b85a2d7897797b3ad3e879168a8e032a</id>
<content type='text'>
Thomas reports:
"Windows:

00 diagnostics
01 modem
02 at-port
03 nmea
04 nic

Linux:

T:  Bus=02 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#=  4 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=00(&gt;ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=2001 ProdID=7e19 Rev=02.32
S:  Manufacturer=Mobile Connect
S:  Product=Mobile Connect
S:  SerialNumber=0123456789ABCDEF
C:  #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I:  If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
I:  If#= 5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage"

Reported-by: Thomas Schäfer &lt;tschaefer@t-online.de&gt;
Signed-off-by: Bjørn Mork &lt;bjorn@mork.no&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>
Thomas reports:
"Windows:

00 diagnostics
01 modem
02 at-port
03 nmea
04 nic

Linux:

T:  Bus=02 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#=  4 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=00(&gt;ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=2001 ProdID=7e19 Rev=02.32
S:  Manufacturer=Mobile Connect
S:  Product=Mobile Connect
S:  SerialNumber=0123456789ABCDEF
C:  #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I:  If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
I:  If#= 5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage"

Reported-by: Thomas Schäfer &lt;tschaefer@t-online.de&gt;
Signed-off-by: Bjørn Mork &lt;bjorn@mork.no&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drivers/net/usb/plusb.c: Fix typo</title>
<updated>2016-03-28T02:33:56+00:00</updated>
<author>
<name>Diego Viola</name>
<email>diego.viola@gmail.com</email>
</author>
<published>2016-03-27T23:58:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a69f0e281d9eb08eb277be051f920ea863e258e2'/>
<id>a69f0e281d9eb08eb277be051f920ea863e258e2</id>
<content type='text'>
Signed-off-by: Diego Viola &lt;diego.viola@gmail.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>
Signed-off-by: Diego Viola &lt;diego.viola@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
</feed>
