user/sven/linux.git/drivers/usb/class, branch v3.18.28

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

2016-02-15T20:42:29Z

[ 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:42:29Z

[ 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:42:28Z

[ 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-22T17:24:43Z

[ Upstream commit f33a7f72e5fc033daccbb8d4753d7c5c41a4d67b ] 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 Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin

USB: usbtmc: add device quirk for Rigol DS6104

2015-12-03T03:58:22Z

[ Upstream commit f50420223071b6ff4b586308f5c27eec54694a81 ] Recently we purchased the Rigol DS6104 and when I try to operate it from my Linux pc, everything works well with the default usbtmc driver, except when I want to download a big datachunk like a screenshot. This bitmapfile has a size of 1152054 bytes but I receive a smaller file and no new packets can be read. When I took a look at the driver source, I found this "Rigol quirk" and I added the id of the new DS series oscilloscopes to this list. I compiled it and loaded the new driver and now everything seems to work fine. Signed-off-by: Teunis van Beelen Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

cdc-acm: Add support of ATOL FPrint fiscal printers

2015-07-03T16:34:28Z

[ Upstream commit 15bf722e6f6c0b884521a0363204532e849deb7f ] 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 Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

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

2015-05-17T23:12:37Z

[ Upstream commit 0d3bba0287d4e284c3ec7d3397e81eec920d5e7e ] 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 Signed-off-by: Sasha Levin

cdc-acm: add sanity checks

2015-05-17T23:12:37Z

[ Upstream commit 7e860a6e7aa62b337a61110430cd633db5b0d2dd ] Check the special CDC headers for a plausible minimum length. Another big operating systems ignores such garbage. Signed-off-by: Oliver Neukum CC: stable@vger.kernel.org Reviewed-by: Adam Lee Tested-by: Adam Lee Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

cdc-wdm: fix endianness bug in debug statements

2015-05-17T23:11:53Z

[ Upstream commit 323ece54e0761198946ecd0c2091f1d2bfdfcb64 ] 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 Signed-off-by: Sasha Levin

cdc-acm: memory leak in error case

2015-01-16T14:59:52Z

commit d908f8478a8d18e66c80a12adb27764920c1f1ca upstream. If probe() fails not only the attributes need to be removed but also the memory freed. Reported-by: Ahmed Tamrawi Signed-off-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman