1. 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
  2. 01 2月, 2015 2 次提交
  3. 25 11月, 2014 2 次提交
  4. 07 11月, 2014 1 次提交
  5. 06 11月, 2014 1 次提交
  6. 04 11月, 2014 3 次提交
  7. 28 5月, 2014 16 次提交
  8. 17 4月, 2014 2 次提交
  9. 05 12月, 2013 1 次提交
  10. 04 12月, 2013 3 次提交
  11. 26 7月, 2013 1 次提交
  12. 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
  13. 22 3月, 2013 2 次提交
  14. 19 3月, 2013 2 次提交
  15. 16 3月, 2013 1 次提交
  16. 12 3月, 2013 1 次提交