Skip to content

GitLab

Switch branch/tag
  1. 23 Jan, 2016 1 commit
    • Jonas Jonsson's avatar
      USB: cdc_acm: Ignore Infineon Flash Loader utility · 71cb0184
      Jonas Jonsson authored 
      commit f33a7f72

 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: default avatarJonas Jonsson <jonas@ludd.ltu.se>
Tested-by: default avatarDaniele Palmas <dnlplm@gmail.com>
Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      71cb0184
  3. 29 Jun, 2015 1 commit
  5. 28 Apr, 2015 1 commit
    • Quentin Casasnovas's avatar
      cdc-acm: prevent infinite loop when parsing CDC headers. · 0d3bba02
      Quentin Casasnovas authored 
      Phil and I found out a problem with commit:

  7e860a6e ("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: 7e860a6e

 ("cdc-acm: add sanity checks")
Signed-off-by: default avatarPhil Turnbull <phil.turnbull@oracle.com>
Signed-off-by: default avatarQuentin Casasnovas <quentin.casasnovas@oracle.com>
CC: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
CC: Oliver Neukum <oneukum@suse.de>
CC: Adam Lee <adam8157@gmail.com>
CC: <stable@vger.kernel.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0d3bba02
  7. 26 Mar, 2015 3 commits
  9. 24 Feb, 2015 1 commit
    • Björn Gerhart's avatar
      cdc-acm: Add support for Denso cradle CU-321 · b20b1618
      Björn Gerhart authored 
      
In order to support an older USB cradle by Denso, I added its vendor- and product-ID to the array of usb_device_id acm_ids. In this way cdc-acm feels responsible for this cradle. The related /dev/ttyACM node is being created properly, and the data transfer works.

However, later cradle models by Denso do have proper descriptors, so the patch is not required for these. At the same time both the older and the later model have the same vendor- and product-ID, but they both work with the patched driver.

Declaration of the Denso cradles I tested:
- both models have the same IDs: vendorID 0x076d, productID 0x0006
- older model: Denso CU-321 (descriptors not properly set)
- later model: Denso CU-821 (with proper descriptors)
Signed-off-by: default avatarBjoern Gerhart <oss@airbjorn.de>
Acked-by: default avatarOliver Neukum <oneukum@suse.de>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b20b1618
  11. 31 Jan, 2015 2 commits
  13. 25 Nov, 2014 2 commits
  15. 06 Nov, 2014 1 commit
  17. 05 Nov, 2014 1 commit
  19. 03 Nov, 2014 3 commits
  21. 27 May, 2014 16 commits
  23. 16 Apr, 2014 2 commits
  25. 05 Dec, 2013 1 commit
  27. 03 Dec, 2013 3 commits
  29. 25 Jul, 2013 1 commit
  31. 17 Jun, 2013 1 commit
    • Greg Kroah-Hartman's avatar
      USB: cdc-acm: remove unneeded spin_lock_irqsave/restore on write path · 71c2fb03
      Greg Kroah-Hartman authored 
      When writing data we were:
	lock
	do some work
	unlock
	call function
		lock
		do some work
		unlock
		return
	return

It turns out, that "function" was only ever called in the one place, so
instead of locking/unlocking for no good reason, just inline the
function and only grab the lock once.

This has sped up the pathological case of sending 1 byte packets to a
loop-back cdc-acm device from 49600 bytes per second to 50100 bytes a
second on my workstation.  A tiny increase yes, but noticable, and now
the spinlock isn't the hottest thing on the perf graph anymore.  Yes, we
are still waiting for the hardware for the most part, but getting rid of
a spinlock_irq_save() call for every packet is still a good thing.

And we end up deleting lines of code, always a win overall.

This was found by using a Teensy 3.0 device and the test program and
firmware located at:
	http://www.pjrc.com/teensy/benchmark_usb_serial_receive.html

Reported-by: default avatarPaul Stoffregen <paul@pjrc.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      71c2fb03
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7