1. 19 3月, 2016 1 次提交
  2. 21 2月, 2016 1 次提交
  3. 15 2月, 2016 1 次提交
  4. 04 2月, 2016 5 次提交
  5. 25 1月, 2016 3 次提交
  6. 23 11月, 2015 1 次提交
    • J
      USB: cdc_acm: Ignore Infineon Flash Loader utility · f33a7f72
      Jonas Jonsson 提交于
      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: NJonas Jonsson <jonas@ludd.ltu.se>
      Tested-by: NDaniele Palmas <dnlplm@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      f33a7f72
  7. 20 11月, 2015 1 次提交
    • J
      usblp: do not set TASK_INTERRUPTIBLE before lock · 19cd80a2
      Jiri Slaby 提交于
      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 [<ffffffffa0c588d0>] 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:
      ...
       [<ffffffff8106e1c6>] warn_slowpath_fmt+0x46/0x50
       [<ffffffff8109a8bd>] __might_sleep+0x7d/0x90
       [<ffffffff8171b20f>] mutex_lock_interruptible_nested+0x2f/0x4b0
       [<ffffffffa0c588fc>] usblp_wwait+0xcc/0x310 [usblp]
       [<ffffffffa0c58bb2>] usblp_write+0x72/0x350 [usblp]
       [<ffffffff8121ed98>] __vfs_write+0x28/0xf0
      ...
      
      Commit 7f477358 (usblp: Implement the
      ENOSPC convention) moved the set prior locking. So move it back after
      the lock.
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Fixes: 7f477358 ("usblp: Implement the ENOSPC convention")
      Acked-By: NPete Zaitcev <zaitcev@yahoo.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      19cd80a2
  8. 23 7月, 2015 2 次提交
  9. 09 6月, 2015 1 次提交
  10. 02 6月, 2015 1 次提交
    • T
      USB: usbtmc: add device quirk for Rigol DS6104 · f5042022
      Teunis van Beelen 提交于
      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: NTeunis van Beelen <teuniz@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f5042022
  11. 25 5月, 2015 3 次提交
  12. 10 5月, 2015 1 次提交
  13. 28 4月, 2015 1 次提交
    • Q
      cdc-acm: prevent infinite loop when parsing CDC headers. · 0d3bba02
      Quentin Casasnovas 提交于
      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: NPhil Turnbull <phil.turnbull@oracle.com>
      Signed-off-by: NQuentin 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: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0d3bba02
  14. 26 3月, 2015 7 次提交
  15. 25 2月, 2015 1 次提交
    • B
      cdc-acm: Add support for Denso cradle CU-321 · b20b1618
      Björn Gerhart 提交于
      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: NBjoern Gerhart <oss@airbjorn.de>
      Acked-by: NOliver Neukum <oneukum@suse.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b20b1618
  16. 01 2月, 2015 2 次提交
  17. 25 11月, 2014 2 次提交
  18. 07 11月, 2014 1 次提交
  19. 06 11月, 2014 1 次提交
  20. 04 11月, 2014 4 次提交