linux-toradex.git/drivers/usb/class, branch v4.1.20

cdc-acm:exclude Samsung phone 04e8:685d

2016-02-15T20:45:20+00:00

[ Upstream commit e912e685f372ab62a2405a1acd923597f524e94a ]

This phone needs to be handled by a specialised firmware tool
and is reported to crash irrevocably if cdc-acm takes it.

Signed-off-by: Oliver Neukum 
CC: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

usb: cdc-acm: send zero packet for intel 7260 modem

2016-02-15T20:45:20+00:00

[ Upstream commit ffdb1e369a73b380fce95b05f8498d92c43842b4 ]

For Intel 7260 modem, it is needed for host side to send zero
packet if the BULK OUT size is equal to USB endpoint max packet
length. Otherwise, modem side may still wait for more data and
cannot give response to host side.

Signed-off-by: Konrad Leszczynski 
Signed-off-by: Lu Baolu 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

usb: cdc-acm: handle unlinked urb in acm read callback

2016-02-15T20:45:20+00:00

[ Upstream commit 19454462acb1bdef80542061bdc9b410e4ed1ff6 ]

In current acm driver, the bulk-in callback function ignores the
URBs unlinked in usb core.

This causes unexpected data loss in some cases. For example,
runtime suspend entry will unlinked all urbs and set urb->status
to -ENOENT even those urbs might have data not processed yet.
Hence, data loss occurs.

This patch lets bulk-in callback function handle unlinked urbs
to avoid data loss.

Signed-off-by: Tang Jian Qiang 
Signed-off-by: Lu Baolu 
Cc: stable@vger.kernel.org
Acked-by: Oliver Neukum 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

USB: cdc_acm: Ignore Infineon Flash Loader utility

2016-01-23T04:54:09+00:00

commit f33a7f72e5fc033daccbb8d4753d7c5c41a4d67b upstream.

Some modems, such as the Telit UE910, are using an Infineon Flash Loader
utility. It has two interfaces, 2/2/0 (Abstract Modem) and 10/0/0 (CDC
Data). The latter can be used as a serial interface to upgrade the
firmware of the modem. However, that isn't possible when the cdc-acm
driver takes control of the device.

The following is an explanation of the behaviour by Daniele Palmas during
discussion on linux-usb.

"This is what happens when the device is turned on (without modifying
the drivers):

[155492.352031] usb 1-3: new high-speed USB device number 27 using ehci-pci
[155492.485429] usb 1-3: config 1 interface 0 altsetting 0 endpoint 0x81 has an invalid bInterval 255, changing to 11
[155492.485436] usb 1-3: New USB device found, idVendor=058b, idProduct=0041
[155492.485439] usb 1-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[155492.485952] cdc_acm 1-3:1.0: ttyACM0: USB ACM device

This is the flashing device that is caught by the cdc-acm driver. Once
the ttyACM appears, the application starts sending a magic string
(simple write on the file descriptor) to keep the device in flashing
mode. If this magic string is not properly received in a certain time
interval, the modem goes on in normal operative mode:

[155493.748094] usb 1-3: USB disconnect, device number 27
[155494.916025] usb 1-3: new high-speed USB device number 28 using ehci-pci
[155495.059978] usb 1-3: New USB device found, idVendor=1bc7, idProduct=0021
[155495.059983] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[155495.059986] usb 1-3: Product: 6 CDC-ACM + 1 CDC-ECM
[155495.059989] usb 1-3: Manufacturer: Telit
[155495.059992] usb 1-3: SerialNumber: 359658044004697
[155495.138958] cdc_acm 1-3:1.0: ttyACM0: USB ACM device
[155495.140832] cdc_acm 1-3:1.2: ttyACM1: USB ACM device
[155495.142827] cdc_acm 1-3:1.4: ttyACM2: USB ACM device
[155495.144462] cdc_acm 1-3:1.6: ttyACM3: USB ACM device
[155495.145967] cdc_acm 1-3:1.8: ttyACM4: USB ACM device
[155495.147588] cdc_acm 1-3:1.10: ttyACM5: USB ACM device
[155495.154322] cdc_ether 1-3:1.12 wwan0: register 'cdc_ether' at usb-0000:00:1a.7-3, Mobile Broadband Network Device, 00:00:11:12:13:14

Using the cdc-acm driver, the string, though being sent in the same way
than using the usb-serial-simple driver (I can confirm that the data is
passing properly since I used an hw usb sniffer), does not make the
device to stay in flashing mode."

Signed-off-by: Jonas Jonsson 
Tested-by: Daniele Palmas 
Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman

usblp: do not set TASK_INTERRUPTIBLE before lock

2015-12-09T19:03:25+00:00

commit 19cd80a214821f4b558560ebd76bfb2c38b4f3d8 upstream.

It is not permitted to set task state before lock. usblp_wwait sets
the state to TASK_INTERRUPTIBLE and calls mutex_lock_interruptible.
Upon return from that function, the state will be TASK_RUNNING again.

This is clearly a bug and a warning is generated with LOCKDEP too:
WARNING: CPU: 1 PID: 5109 at kernel/sched/core.c:7404 __might_sleep+0x7d/0x90()
do not call blocking ops when !TASK_RUNNING; state=1 set at [] usblp_wwait+0xa0/0x310 [usblp]
Modules linked in: ...
CPU: 1 PID: 5109 Comm: captmon Tainted: G        W       4.2.5-0.gef2823b-default #1
Hardware name: LENOVO 23252SG/23252SG, BIOS G2ET33WW (1.13 ) 07/24/2012
 ffffffff81a4edce ffff880236ec7ba8 ffffffff81716651 0000000000000000
 ffff880236ec7bf8 ffff880236ec7be8 ffffffff8106e146 0000000000000282
 ffffffff81a50119 000000000000028b 0000000000000000 ffff8802dab7c508
Call Trace:
...
 [] warn_slowpath_fmt+0x46/0x50
 [] __might_sleep+0x7d/0x90
 [] mutex_lock_interruptible_nested+0x2f/0x4b0
 [] usblp_wwait+0xcc/0x310 [usblp]
 [] usblp_write+0x72/0x350 [usblp]
 [] __vfs_write+0x28/0xf0
...

Commit 7f477358e2384c54b190cc3b6ce28277050a041b (usblp: Implement the
ENOSPC convention) moved the set prior locking. So move it back after
the lock.

Signed-off-by: Jiri Slaby 
Fixes: 7f477358e2 ("usblp: Implement the ENOSPC convention")
Acked-By: Pete Zaitcev 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

cdc-acm: Add support of ATOL FPrint fiscal printers

2015-06-29T19:35:29+00:00

commit 15bf722e6f6c0b884521a0363204532e849deb7f upstream.

ATOL FPrint fiscal printers require usb_clear_halt to be executed
to work properly. Add quirk to fix the issue.

Signed-off-by: Alexey Sokolov 
Signed-off-by: Greg Kroah-Hartman

cdc-acm: prevent infinite loop when parsing CDC headers.

2015-04-28T10:53:16+00:00

Phil and I found out a problem with commit:

  7e860a6e7aa6 ("cdc-acm: add sanity checks")

It added some sanity checks to ignore potential garbage in CDC headers but
also introduced a potential infinite loop.  This can happen at the first
loop iteration (elength = 0 in that case) if the description isn't a
DT_CS_INTERFACE or later if 'buffer[0]' is zero.

It should also be noted that the wrong length was being added to 'buffer'
in case 'buffer[1]' was not a DT_CS_INTERFACE descriptor, since elength was
assigned after that check in the loop.

A specially crafted USB device could be used to trigger this infinite loop.

Fixes: 7e860a6e7aa6 ("cdc-acm: add sanity checks")
Signed-off-by: Phil Turnbull 
Signed-off-by: Quentin Casasnovas 
CC: Sergei Shtylyov 
CC: Oliver Neukum 
CC: Adam Lee 
CC: 
Signed-off-by: Greg Kroah-Hartman

cdc-wdm: error returns need to be translated

2015-03-26T09:51:57+00:00

One more case of error codes not correctly being
correctly returned to user space.

Signed-off-by: Olive Neukum 0
Signed-off-by: Greg Kroah-Hartman

cdc-wdm: fix endianness bug in debug statements

2015-03-26T09:51:56+00:00

Values directly from descriptors given in debug statements
must be converted to native endianness.

Signed-off-by: Oliver Neukum 
CC: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

cdc-wdm: unify error handling in write

2015-03-26T09:51:56+00:00

This makes sure the error handling path is the same for
all error conditions, thus reducing code duplication.

Signed-off-by: Oliver Neukum 0
Signed-off-by: Greg Kroah-Hartman