1. 29 2月, 2012 2 次提交
  2. 25 2月, 2012 1 次提交
  3. 15 2月, 2012 1 次提交
  4. 02 2月, 2012 1 次提交
  5. 25 1月, 2012 1 次提交
  6. 13 1月, 2012 1 次提交
  7. 05 1月, 2012 1 次提交
    • J
      usb: option: add ZD Incorporated HSPA modem · 3c8c9316
      Janne Snabb 提交于
      Add support for Chinese Noname HSPA USB modem which is apparently
      manufactured by a company called ZD Incorporated (based on texts in the
      Windows drivers).
      
      This product is available at least from Dealextreme (SKU 80032) and
      possibly in India with name Olive V-MW250. It is based on Qualcomm
      MSM6280 chip.
      
      I needed to also add "options usb-storage quirks=0685:7000:i" in modprobe
      configuration because udevd or the kernel keeps poking the embedded
      fake-cd-rom which fails and causes the device to reset. There might be
      a better way to accomplish the same. usb_modeswitch is not needed with
      this device.
      Signed-off-by: NJanne Snabb <snabb@epipe.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      3c8c9316
  8. 14 12月, 2011 1 次提交
    • B
      USB: option: Removing one bogus and adding some new Huawei combinations · 02a551c9
      Bjørn Mork 提交于
      Huawei use the product code HUAWEI_PRODUCT_E353 (0x1506) for a
      number of different devices, which each can appear with a number
      of different descriptor sets.  Different types of interfaces
      can be identified by looking at the subclass and protocol fields
      
      Subclass 1 protocol 8 is actually the data interface of a CDC
      ECM set, with subclass 1 protocol 9 as the control interface.
      Neither support serial data communcation, and cannot therefore
      be supported by this driver.
      
      At the same time, add a few other sets which appear if the
      device is configured in "Windows mode" using this modeswitch
      message:
      55534243000000000000000000000011060000000100000000000000000000
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      02a551c9
  9. 13 12月, 2011 1 次提交
  10. 27 11月, 2011 2 次提交
  11. 19 11月, 2011 2 次提交
  12. 16 11月, 2011 1 次提交
  13. 18 9月, 2011 4 次提交
  14. 23 8月, 2011 4 次提交
  15. 09 8月, 2011 4 次提交
  16. 08 6月, 2011 1 次提交
    • G
      Revert "USB: option: add ID for ZTE MF 330" · 3095ec89
      Greg Kroah-Hartman 提交于
      This reverts commit a559d2c8.
      
      Turns out that device id 0x1d6b:0x0002 is a USB hub, which causes havoc
      when the option driver tries to bind to it.
      
      So revert this as it doesn't seem to be needed at all.
      
      Thanks to Michael Tokarev and Paweł Drobek for working on resolving this
      issue.
      
      Cc: Paweł Drobek <pawel.drobek@gmail.com>
      Cc: Michael Tokarev <mjt@tls.msk.ru>
      Cc: Dominik Brodowski <linux@dominikbrodowski.net>
      Cc: stable <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      3095ec89
  17. 07 6月, 2011 4 次提交
  18. 18 5月, 2011 1 次提交
    • M
      USB: option: add support for Huawei E353 device · 610ba42f
      Marcin Gałczyński 提交于
      I am sharing patch to the devices/usb/serial/option.c. This allows
      operation of Huawei E353 broadband modem using the “option” driver. The
      patch simply adds new constant with proper product ID and an entry to
      usb_device_id. I worked on the 2.6.38.6 sources. Tested on Dell inspiron
      1764 (i3 core cpu) and brand new Huawei E353 modem, Fedora 15 beta.
      
      Looking at the type of change, i doubt it has potential to introduce
      problems in other parts of kernel or the driver itself.
      Signed-off-by: NMarcin Galczynski <marcin@galczynski.pl>
      Cc: stable <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      610ba42f
  19. 30 4月, 2011 1 次提交
  20. 14 4月, 2011 1 次提交
  21. 10 3月, 2011 1 次提交
  22. 23 1月, 2011 1 次提交
  23. 01 12月, 2010 1 次提交
    • D
      usb-wwan: implement TIOCGSERIAL and TIOCSSERIAL to avoid blocking close(2) · 02303f73
      Dan Williams 提交于
      Some devices (ex ZTE 2726) simply don't respond at all when data is sent
      to some of their USB interfaces.  The data gets stuck in the TTYs queue
      and sits there until close(2), which them blocks because closing_wait
      defaults to 30 seconds (even though the fd is O_NONBLOCK).  This is
      rarely desired.  Implement the standard mechanism to adjust closing_wait
      and let applications handle it how they want to.
      Signed-off-by: NDan Williams <dcbw@redhat.com>
      02303f73
  24. 11 11月, 2010 2 次提交