linux-stable.git/drivers/net/usb, branch v3.10.30

dm9601: work around tx fifo sync issue on dm962x

2014-01-09T20:24:22+00:00

commit 4263c86dca5198da6bd3ad826d0b2304fbe25776 upstream.

Certain dm962x revisions contain an bug, where if a USB bulk transfer retry
(E.G. if bulk crc mismatch) happens right after a transfer with odd or
maxpacket length, the internal tx hardware fifo gets out of sync causing
the interface to stop working.

Work around it by adding up to 3 bytes of padding to ensure this situation
cannot trigger.

This workaround also means we never pass multiple-of-maxpacket size skb's
to usbnet, so the length adjustment to handle usbnet's padding of those can
be removed.

Reported-by: Joseph Chang 
Signed-off-by: Peter Korsgaard 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

dm9601: fix reception of full size ethernet frames on dm9620/dm9621a

2014-01-09T20:24:22+00:00

commit 407900cfb54bdb2cfa228010b6697305f66b2948 upstream.

dm9620/dm9621a require room for 4 byte padding even in dm9601 (3 byte
header) mode.

Signed-off-by: Peter Korsgaard 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

usbnet: fix status interrupt urb handling

2013-12-08T15:29:24+00:00

[ Upstream commit 52f48d0d9aaa621ffa5e08d79da99a3f8c93b848 ]

Since commit 7b0c5f21f348a66de495868b8df0284e8dfd6bbf
"sierra_net: keep status interrupt URB active", sierra_net triggers
status interrupt polling before the net_device is opened (in order to
properly receive the sync message response).

To be able to receive further interrupts, the interrupt urb needs to be
re-submitted, so this patch removes the bogus check for netif_running().

Signed-off-by: Felix Fietkau 
Tested-by: Dan Williams 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: qmi_wwan: add new Qualcomm devices

2013-10-13T23:08:35+00:00

commit 0470667caa8261beb8a9141102b04a5357dd45b5 upstream.

Adding the device list from the Windows driver description files
included with a new Qualcomm MDM9615 based device, "Alcatel-sbell
ASB TL131 TDD LTE", from China Mobile.  This device is tested
and verified to work.  The others are assumed to work based on
using the same Windows driver.

Many of these devices support multiple QMI/wwan ports, requiring
multiple interface matching entries.  All devices are composite,
providing a mix of one or more serial, storage or Android Debug
Brigde functions in addition to the wwan function.

This device list included an update of one previously known device,
which was incorrectly assumed to have a Gobi 2K layout.  This is
corrected.

Reported-by: 王康 
Signed-off-by: Bjørn Mork 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

dm9601: fix IFF_ALLMULTI handling

2013-10-13T23:08:30+00:00

[ Upstream commit bf0ea6380724beb64f27a722dfc4b0edabff816e ]

Pass-all-multicast is controlled by bit 3 in RX control, not bit 2
(pass undersized frames).

Reported-by: Joseph Chang 
Signed-off-by: Peter Korsgaard 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: usb: cdc_ether: Use wwan interface for Telit modules

2013-10-01T16:17:45+00:00

commit 0092820407901a0b2c4e343e85f96bb7abfcded1 upstream.

Signed-off-by: Fabio Porcedda 
Acked-by: Oliver Neukum 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: usb: Add HP hs2434 device to ZLP exception table

2013-09-14T13:54:55+00:00

[ Upstream commit 03803a59e32453ee5737c6096a295f748f03cc49 ]

This patch adds another entry (HP hs2434 Mobile Broadband) to the list
of exceptional devices that require a zero length packet in order to
function properly. This list was added in commit 844e88f0. The hs2434
is manufactured by Sierra Wireless, who also produces the MC7710,
which the ZLP exception list was created for in the first place. So
hopefully it is just this one producer's devices that will need this
workaround.

Tested on a DM1-4310NR HP notebook, which does not function without this
change.

Signed-off-by: Rob Gardner 
Acked-by: Bjørn Mork 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

usbnet: do not pretend to support SG/TSO

2013-08-12T01:35:25+00:00

[ Upstream commit 20f0170377264e8449b6987041f0bcc4d746d3ed ]

usbnet doesn't support yet SG, so drivers should not advertise SG or TSO
capabilities, as they allow TCP stack to build large TSO packets that
need to be linearized and might use order-5 pages.

This adds an extra copy overhead and possible allocation failures.

Current code ignore skb_linearize() return code so crashes are even
possible.

Best is to not pretend SG/TSO is supported, and add this again when/if
usbnet really supports SG for devices who could get a performance gain.

Based on a prior patch from Freddy Xin 

Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

qmi_wwan: add various Novatel Gobi1K IDs

2013-06-24T07:08:38+00:00

Found in the Windows INF files while investigating the
Novatel/Verizon USB-1000 device.  The USB-1000 is verified as
a Gobi1K device and works with QMI after loading appropriate
firmware.

Signed-off-by: Dan Williams 
Acked-by: Bjørn Mork 
Signed-off-by: David S. Miller

qmi_wwan/cdc_ether: let qmi_wwan handle the Huawei E1820

2013-06-11T09:43:22+00:00

Another QMI speaking Qualcomm based device, which should be
driven by qmi_wwan, while cdc_ether should ignore it.

Like on other Huawei devices, the wwan function can appear
either as a single vendor specific interface or as a CDC ECM
class function using separate control and data interfaces.
The ECM control interface protocol is 0xff, likely in an
attempt to indicate that vendor specific management is
required.

In addition to the near standard CDC class, Huawei also add
vendor specific AT management commands to their firmwares.
This is probably an attempt to support non-Windows systems
using standard class drivers.  Unfortunately, this part of
the firmware is often buggy.  Linux is much better off using
whatever native vendor specific management protocol the
device offers, and Windows uses, whenever possible. This
means QMI in the case of Qualcomm based devices.

The E1820 has been verified to work fine with QMI.

Matching on interface number is necessary to distiguish the
wwan function from serial functions in the single interface
mode, as both function types will have class/subclass/function
set to ff/ff/ff.

The control interface number does not change in CDC ECM mode,
so the interface number matching rule is sufficient to handle
both modes.  The cdc_ether blacklist entry is only relevant in
CDC ECM mode, but using a similar interface number based rule
helps document this as a transfer from one driver to another.

Other Huawei 02/06/ff devices are left with the cdc_ether driver
because we do not know whether they are based on Qualcomm chips.
The Huawei specific AT command management is known to be somewhat
hardware independent, and their usage of these class codes may
also be independent of the modem hardware.

Reported-by: Graham Inggs 
Signed-off-by: Bjørn Mork 
Signed-off-by: David S. Miller