linux-stable.git/drivers/net/usb, branch linux-3.19.y

usbnet: Fix tx_bytes statistic running backward in cdc_ncm

2015-04-29T08:23:44+00:00

[ Upstream commit 7a1e890e2168e33fb62d84528e996b8b4b478fea ]

cdc_ncm disagrees with usbnet about how much framing overhead should
be counted in the tx_bytes statistics, and tries 'fix' this by
decrementing tx_bytes on the transmit path.  But statistics must never
be decremented except due to roll-over; this will thoroughly confuse
user-space.  Also, tx_bytes is only incremented by usbnet in the
completion path.

Fix this by requiring drivers that set FLAG_MULTI_FRAME to set a
tx_bytes delta along with the tx_packets count.

Fixes: beeecd42c3b4 ("net: cdc_ncm/cdc_mbim: adding NCM protocol statistics")
Signed-off-by: Ben Hutchings 
Signed-off-by: Bjørn Mork 
Signed-off-by: Greg Kroah-Hartman

usbnet: Fix tx_packets stat for FLAG_MULTI_FRAME drivers

2015-04-29T08:23:44+00:00

[ Upstream commit 1e9e39f4a29857a396ac7b669d109f697f66695e ]

Currently the usbnet core does not update the tx_packets statistic for
drivers with FLAG_MULTI_PACKET and there is no hook in the TX
completion path where they could do this.

cdc_ncm and dependent drivers are bumping tx_packets stat on the
transmit path while asix and sr9800 aren't updating it at all.

Add a packet count in struct skb_data so these drivers can fill it
in, initialise it to 1 for other drivers, and add the packet count
to the tx_packets statistic on completion.

Signed-off-by: Ben Hutchings 
Tested-by: Bjørn Mork 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

Revert "net: cx82310_eth: use common match macro"

2015-03-26T12:59:34+00:00

[ Upstream commit 8d006e0105978619fb472e150c88b0d49337fe2b ]

This reverts commit 11ad714b98f6d9ca0067568442afe3e70eb94845 because
it breaks cx82310_eth.

The custom USB_DEVICE_CLASS macro matches
bDeviceClass, bDeviceSubClass and bDeviceProtocol
but the common USB_DEVICE_AND_INTERFACE_INFO matches
bInterfaceClass, bInterfaceSubClass and bInterfaceProtocol instead, which are
not specified.

Signed-off-by: Ondrej Zary 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

usb: plusb: Add support for National Instruments host-to-host cable

2015-03-18T13:10:52+00:00

[ Upstream commit 42c972a1f390e3bc51ca1e434b7e28764992067f ]

The National Instruments USB Host-to-Host Cable is based on the Prolific
PL-25A1 chipset.  Add its VID/PID so the plusb driver will recognize it.

Signed-off-by: Ben Shelton 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: usb: sr9700: Use 'SR_' prefix for the common register macros

2015-02-04T21:53:02+00:00

The commone register macors (e.g. RSR) is too commont to drivers, it may
be conflict with the architectures (e.g. xtensa, sh).

The related warnings (with allmodconfig under xtensa):

    CC [M]  drivers/net/usb/sr9700.o
  In file included from drivers/net/usb/sr9700.c:24:0:
  drivers/net/usb/sr9700.h:65:0: warning: "RSR" redefined
   #define RSR   0x06
   ^
  In file included from ./arch/xtensa/include/asm/bitops.h:22:0,
                   from include/linux/bitops.h:36,
                   from include/linux/kernel.h:10,
                   from include/linux/list.h:8,
                   from include/linux/module.h:9,
                   from drivers/net/usb/sr9700.c:13:
  ./arch/xtensa/include/asm/processor.h:190:0: note: this is the location of the previous definition
   #define RSR(v,sr) __asm__ __volatile__ ("rsr %0,"__stringify(sr) : "=a"(v));
   ^

Signed-off-by: Chen Gang 
Signed-off-by: David S. Miller

r8152: remove sram_read

2015-01-19T21:16:32+00:00

Read OCP register 0xa43a~0xa43b would clear some flags which the hw
would use, and it may let the device lost. However, the unit of
reading is 4 bytes. That is, it would read 0xa438~0xa43b when calling
sram_read() to read OCP_SRAM_DATA.

Signed-off-by: Hayes Wang 
Signed-off-by: David S. Miller

r8152: remove generic_ocp_read before writing

2015-01-19T21:16:32+00:00

For ocp_write_word() and ocp_write_byte(), there is a generic_ocp_read()
which is used to read the whole 4 byte data, keep the unchanged bytes,
and modify the expected bytes. However, the "byen" could be used to
determine which bytes of the 4 bytes to write, so the action could be
removed.

Signed-off-by: Hayes Wang 
Signed-off-by: David S. Miller

usb/kaweth: use GFP_ATOMIC under spin_lock in usb_start_wait_urb()

2015-01-12T21:42:49+00:00

Commit e4c7f259c5be ("USB: kaweth.c: use GFP_ATOMIC under spin_lock")
makes sure that kaweth_internal_control_msg() allocates memory with GFP_ATOMIC,
but kaweth_internal_control_msg() also calls usb_start_wait_urb()
that still allocates memory with GFP_NOIO.

The patch fixes usb_start_wait_urb() as well.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov 
Acked-by: Oliver Neukum 
Signed-off-by: David S. Miller

r8152: support ndo_features_check

2015-01-06T18:29:13+00:00

Support ndo_features_check to avoid:
 - the transport offset is more than the hw limitation when using hw checksum.
 - the skb->len of a GSO packet is more than the limitation.

Signed-off-by: Hayes Wang 
Signed-off-by: David S. Miller

qmi_wwan: Set random MAC on devices with buggy fw

2015-01-02T21:41:47+00:00

Some buggy firmwares export an incorrect MAC address (00:a0:c6:00:00:00). This
makes for example checking devices for random MAC addresses tricky, and you
might end up with multiple network interfaces with the same address.

This patch tries to fix, or at least improve, the situation by setting the MAC
address of devices with this firmware bug to a random address. I tested the
patch with two devices that has this firmware bug (Huawei E398 and E392), and
network traffic worked fine after changing the address.

Signed-off-by: Kristian Evensen 
Signed-off-by: David S. Miller