1. 13 9月, 2016 1 次提交
  2. 09 9月, 2016 2 次提交
  3. 31 8月, 2016 1 次提交
  4. 15 8月, 2016 3 次提交
  5. 10 8月, 2016 1 次提交
    • R
      cdc-wdm: Clear read pipeline in case of error · c1da59da
      Robert Foss 提交于
      Implemented queued response handling. This queue is processed every time the
      WDM_READ flag is cleared.
      
      In case of a read error, userspace may not actually read the data, since the
      driver returns an error through wdm_poll. After this, the underlying device may
      attempt to send us more data, but the queue is not processed. While userspace is
      also blocked, because the read error is never cleared.
      
      After this patch, we proactively process the queue on a read error. If there was
      an outstanding response to handle, that will clear the error (or go through the
      same logic again, if another read error occurs). If there was no outstanding
      response, this will bring the queue size back to 0, unblocking a future response
      from the underlying device.
      Signed-off-by: NRobert Foss <robert.foss@collabora.com>
      Tested-by: NRobert Foss <robert.foss@collabora.com>
      Acked-by: NOliver Neukum <oneukum@suse.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c1da59da
  6. 09 8月, 2016 1 次提交
    • B
      cdc-wdm: fix "out-of-sync" due to missing notifications · 833415a3
      Bjørn Mork 提交于
      The driver enforces a strict one-to-one relationship between the
      received RESPONSE_AVAILABLE notifications and messages read from
      the device. At the same time, it will cancel the interrupt URB
      when there is no client holding the character device open.
      
      Many devices do not cope well with this behaviour.  They maintain
      a FIFO queue of messages, and send notifications on a best effort
      basis.  Messages are queued regardless of whether the notification
      is successful or not. So if the driver loses a single notification,
      which can easily happen when the interrupt URB is cancelled, then
      the device and driver becomes out-of-sync. New messages end up
      at the end of the queue, while the associated notification makes
      the driver read only the first message from the queue.
      
      This state is permanent from a user point of view. There is no
      no way to flush the device queue without resetting the device or
      using another driver.
      
      The problem is easy to hit with current QMI and MBIM command line
      tools, which typically close the character device after seeing
      the reply they expect. Any pending unsolicited messages from the
      device will then trigger the driver bug.
      
      Fix by always reading all queued messages from the device when
      the notification URB is first submitted.  This is expected to
      end with an -EPIPE status when there are no more pending
      messages, so demote the printk associated with -EPIPE to debug
      level.
      
      The workaround has been tested on a large number of different MBIM
      and QMI devices, as well as the Ericsson F5521gw and H5321gw modems
      with real Device Management functions.
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Acked-by: NOliver Neukum <oneukum@suse.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      833415a3
  7. 18 7月, 2016 4 次提交
  8. 08 6月, 2016 1 次提交
  9. 01 5月, 2016 1 次提交
  10. 14 4月, 2016 1 次提交
  11. 19 3月, 2016 1 次提交
  12. 21 2月, 2016 1 次提交
  13. 15 2月, 2016 1 次提交
  14. 04 2月, 2016 5 次提交
  15. 25 1月, 2016 3 次提交
  16. 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
  17. 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
  18. 23 7月, 2015 2 次提交
  19. 09 6月, 2015 1 次提交
  20. 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
  21. 25 5月, 2015 3 次提交
  22. 10 5月, 2015 1 次提交
  23. 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
  24. 26 3月, 2015 2 次提交