1. 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
  2. 26 3月, 2015 3 次提交
  3. 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
  4. 01 2月, 2015 2 次提交
  5. 25 11月, 2014 2 次提交
  6. 07 11月, 2014 1 次提交
  7. 06 11月, 2014 1 次提交
  8. 04 11月, 2014 3 次提交
  9. 28 5月, 2014 16 次提交
  10. 17 4月, 2014 2 次提交
  11. 05 12月, 2013 1 次提交
  12. 04 12月, 2013 3 次提交
  13. 26 7月, 2013 1 次提交
  14. 18 6月, 2013 1 次提交
    • G
      USB: cdc-acm: remove unneeded spin_lock_irqsave/restore on write path · 71c2fb03
      Greg Kroah-Hartman 提交于
      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.htmlReported-by: NPaul Stoffregen <paul@pjrc.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      71c2fb03
  15. 22 3月, 2013 2 次提交