linux-stable.git/drivers/usb/serial, branch v3.6.2 Linux kernel stable tree USB: serial: fix up bug with missing {} 2012-10-07T15:39:30+00:00 Greg Kroah-Hartman gregkh@linuxfoundation.org 2012-09-19T07:15:21+00:00 cef87aeb39d942deac8196e46c4233721357cce2 commit 44b0f0836b62171617d56c6528c821ceaa6ea506 upstream. As reported by Fengguang: FYI, coccinelle warns about drivers/usb/serial/usb-serial.c:1415:3-51: code aligned with following code on line 1416 vim +1415 drivers/usb/serial/usb-serial.c 1412 /* we only set the reset_resume field if the serial_driver has one */ 1413 for (sd = serial_drivers; *sd; ++sd) { 1414 if ((*sd)->reset_resume) > 1415 udriver->reset_resume = usb_serial_reset_resume; > 1416 break; 1417 } Reported-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 44b0f0836b62171617d56c6528c821ceaa6ea506 upstream.

As reported by Fengguang:

FYI, coccinelle warns about

drivers/usb/serial/usb-serial.c:1415:3-51: code aligned with following code on line 1416

vim +1415 drivers/usb/serial/usb-serial.c

  1412          /* we only set the reset_resume field if the serial_driver has one */
  1413          for (sd = serial_drivers; *sd; ++sd) {
  1414                  if ((*sd)->reset_resume)
> 1415                          udriver->reset_resume = usb_serial_reset_resume;
> 1416                          break;
  1417          }

Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB: qcaux: add Pantech vendor class match 2012-10-07T15:39:30+00:00 Bjørn Mork bjorn@mork.no 2012-09-19T20:02:03+00:00 782d8021f3300f226ef7000119a8c98ab91bf446 commit c638eb2872b3af079501e7ee44cbb8a5cce9b4b5 upstream. The three Pantech devices UML190 (106c:3716), UML290 (106c:3718) and P4200 (106c:3721) all use the same subclasses to identify vendor specific functions. Replace the existing device specific entries with generic vendor matching, adding support for the P4200. Signed-off-by: Bjørn Mork <bjorn@mork.no> Cc: Thomas Schäfer <tschaefer@t-online.de> Acked-by: Dan Williams <dcbw@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit c638eb2872b3af079501e7ee44cbb8a5cce9b4b5 upstream.

The three Pantech devices UML190 (106c:3716), UML290 (106c:3718) and
P4200 (106c:3721) all use the same subclasses to identify vendor
specific functions.  Replace the existing device specific entries
with generic vendor matching, adding support for the P4200.

Signed-off-by: Bjørn Mork <bjorn@mork.no>
Cc: Thomas Schäfer <tschaefer@t-online.de>
Acked-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB: ftdi_sio: add TIAO USB Multi-Protocol Adapter (TUMPA) support 2012-10-07T15:39:30+00:00 Antonio Ospite ospite@studenti.unina.it 2012-09-23T07:57:25+00:00 7135bbef51bf1c2624c6e87952b3d1b99a9bd0ed commit 54575b05af36959dfb6a49a3e9ca0c2b456b7126 upstream. TIAO/DIYGADGET USB Multi-Protocol Adapter (TUMPA) is an FTDI FT2232H based device which provides an easily accessible JTAG, SPI, I2C, serial breakout. http://www.diygadget.com/tiao-usb-multi-protocol-adapter-jtag-spi-i2c-serial.html http://www.tiaowiki.com/w/TIAO_USB_Multi_Protocol_Adapter_User%27s_Manual FTDI FT2232H provides two serial channels (A and B), but on the TUMPA channel A is dedicated to JTAG/SPI while channel B can be used for UART/RS-232: use the ftdi_jtag_quirk to expose only channel B as a usb-serial interface to userspace. Signed-off-by: Antonio Ospite <ospite@studenti.unina.it> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 54575b05af36959dfb6a49a3e9ca0c2b456b7126 upstream.

TIAO/DIYGADGET USB Multi-Protocol Adapter (TUMPA) is an FTDI FT2232H
based device which provides an easily accessible JTAG, SPI, I2C, serial
breakout.

http://www.diygadget.com/tiao-usb-multi-protocol-adapter-jtag-spi-i2c-serial.html
http://www.tiaowiki.com/w/TIAO_USB_Multi_Protocol_Adapter_User%27s_Manual

FTDI FT2232H provides two serial channels (A and B), but on the TUMPA
channel A is dedicated to JTAG/SPI while channel B can be used for
UART/RS-232: use the ftdi_jtag_quirk to expose only channel B as
a usb-serial interface to userspace.

Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB: option: blacklist QMI interface on ZTE MF683 2012-10-07T15:39:29+00:00 Bjørn Mork bjorn@mork.no 2012-09-19T20:02:12+00:00 0eccd99ec841350981e50b36e162a5dd18873699 commit 160c9425ac52cb30502be2d9c5e848cec91bb115 upstream. Interface #5 on ZTE MF683 is a QMI/wwan interface. Signed-off-by: Bjørn Mork <bjorn@mork.no> Cc: Shawn J. Goff <shawn7400@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 160c9425ac52cb30502be2d9c5e848cec91bb115 upstream.

Interface #5 on ZTE MF683 is a QMI/wwan interface.

Signed-off-by: Bjørn Mork <bjorn@mork.no>
Cc: Shawn J. Goff <shawn7400@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB: option: replace ZTE K5006-Z entry with vendor class rule 2012-09-11T19:34:29+00:00 Bjørn Mork bjorn@mork.no 2012-09-11T07:40:31+00:00 ba9edaa468869a8cea242a411066b0f490751798 Fix the ZTE K5006-Z entry so that it actually matches anything commit f1b5c997 USB: option: add ZTE K5006-Z added a device specific entry assuming that the device would use class/subclass/proto == ff/ff/ff like other ZTE devices. It turns out that ZTE has started using vendor specific subclass and protocol codes: T: Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 4 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=19d2 ProdID=1018 Rev= 0.00 S: Manufacturer=ZTE,Incorporated S: Product=ZTE LTE Technologies MSM S: SerialNumber=MF821Vxxxxxxx C:* #Ifs= 5 Cfg#= 1 Atr=c0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=86 Prot=10 Driver=(none) E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=02 Prot=05 Driver=(none) E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=02 Prot=01 Driver=(none) E: Ad=83(I) Atr=03(Int.) MxPS= 64 Ivl=2ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=06 Prot=00 Driver=qmi_wwan E: Ad=85(I) Atr=03(Int.) MxPS= 64 Ivl=2ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#= 4 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms We do not have any information on how ZTE intend to use these codes, but let us assume for now that the 3 sets matching serial functions in the K5006-Z always will identify a serial function in a ZTE device. Cc: Thomas Schäfer <tschaefer@t-online.de> Cc: stable <stable@vger.kernel.org> Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
Fix the ZTE K5006-Z entry so that it actually matches anything

  commit f1b5c997 USB: option: add ZTE K5006-Z

added a device specific entry assuming that the device would use
class/subclass/proto == ff/ff/ff like other ZTE devices. It
turns out that ZTE has started using vendor specific subclass
and protocol codes:

T:  Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#=  4 Spd=480  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=19d2 ProdID=1018 Rev= 0.00
S:  Manufacturer=ZTE,Incorporated
S:  Product=ZTE LTE Technologies MSM
S:  SerialNumber=MF821Vxxxxxxx
C:* #Ifs= 5 Cfg#= 1 Atr=c0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=86 Prot=10 Driver=(none)
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=02 Prot=05 Driver=(none)
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=02 Prot=01 Driver=(none)
E:  Ad=83(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=06 Prot=00 Driver=qmi_wwan
E:  Ad=85(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 4 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms

We do not have any information on how ZTE intend to use these
codes, but let us assume for now that the 3 sets matching
serial functions in the K5006-Z always will identify a serial
function in a ZTE device.

Cc: Thomas Schäfer <tschaefer@t-online.de>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB: ftdi_sio: do not claim CDC ACM function 2012-09-10T17:55:52+00:00 Bjørn Mork bjorn@mork.no 2012-09-10T10:01:05+00:00 f08dea734844aa42ec57c229b0b73b3d7d21f810 The Microchip vid:pid 04d8:000a is used for their CDC ACM demo firmware application. This is a device with a single function conforming to the CDC ACM specification and with the intention of demonstrating CDC ACM class firmware and driver interaction. The demo is used on a number of development boards, and may also be used unmodified by vendors using Microchip hardware. Some vendors have re-used this vid:pid for other types of firmware, emulating FTDI chips. Attempting to continue to support such devices without breaking class based applications that by matching on interface class/subclass/proto being ff/ff/00. I have no information about the actual device or interface descriptors, but this will at least make the proper CDC ACM devices work again. Anyone having details of the offending device's descriptors should update this entry with the details. Reported-by: Florian Wöhrl <fw@woehrl.biz> Reported-by: Xiaofan Chen <xiaofanc@gmail.com> Cc: stable <stable@vger.kernel.org> Cc: Alan Cox <alan@linux.intel.com> Cc: Bruno Thomsen <bruno.thomsen@gmail.com> Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
The Microchip vid:pid 04d8:000a is used for their CDC ACM
demo firmware application.  This is a device with a single
function conforming to the CDC ACM specification and with
the intention of demonstrating CDC ACM class firmware and
driver interaction.  The demo is used on a number of
development boards, and may also be used unmodified by
vendors using Microchip hardware.

Some vendors have re-used this vid:pid for other types of
firmware, emulating FTDI chips. Attempting to continue to
support such devices without breaking class based
applications that by matching on interface
class/subclass/proto being ff/ff/00.  I have no information
about the actual device or interface descriptors, but this
will at least make the proper CDC ACM devices work again.
Anyone having details of the offending device's descriptors
should update this entry with the details.

Reported-by: Florian Wöhrl <fw@woehrl.biz>
Reported-by: Xiaofan Chen <xiaofanc@gmail.com>
Cc: stable <stable@vger.kernel.org>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Bruno Thomsen <bruno.thomsen@gmail.com>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB: ftdi_sio: PID for NZR SEM 16+ USB 2012-09-05T23:43:49+00:00 Horst Schirmeier horst@schirmeier.com 2012-08-30T22:00:28+00:00 26a538b9ea2a3ee10dafc0068f0560dfd7b7ba37 This adds the USB PID for the NZR SEM 16+ USB energy monitor device <http://www.nzr.de>. It works perfectly with the GPL software on <http://schou.dk/linux/sparometer/>. Signed-off-by: Horst Schirmeier <horst@schirmeier.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
This adds the USB PID for the NZR SEM 16+ USB energy monitor device
<http://www.nzr.de>.  It works perfectly with the GPL software on
<http://schou.dk/linux/sparometer/>.

Signed-off-by: Horst Schirmeier <horst@schirmeier.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB: ftdi-sio: add support for more Physik Instrumente devices 2012-09-05T23:43:49+00:00 Éric Piel piel@delmic.com 2012-09-04T15:25:06+00:00 dafc4f7be1a556ca3868d343c00127728b397068 Commit b69cc672052540 added support for the E-861. After acquiring a C-867, I realised that every Physik Instrumente's device has a different PID. They are listed in the Windows device driver's .inf file. So here are all PIDs for the current (and probably future) USB devices from Physik Instrumente. Compiled, but only actually tested on the E-861 and C-867. Signed-off-by: Éric Piel <piel@delmic.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
Commit b69cc672052540 added support for the E-861.  After acquiring a C-867, I
realised that every Physik Instrumente's device has a different PID. They are
listed in the Windows device driver's .inf file. So here are all PIDs for the
current (and probably future) USB devices from Physik Instrumente.

Compiled, but only actually tested on the E-861 and C-867.

Signed-off-by: Éric Piel <piel@delmic.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB: qcserial: fix port handling on Gobi 1K and 2K+ 2012-08-16T16:48:03+00:00 Dan Williams dcbw@redhat.com 2012-07-23T19:26:07+00:00 731879f8e3d4c61220462160311fa650a8b96abf Bjorn's latest patchset does break Gobi 1K and 2K because on both devices as it claims usb interface 0. That's because usbif 0 is not handled in the switch statement, and thus the if0 gets claimed when it should not. So let's just make things even simpler yet, and handle both the 1K and 2K+ cases separately. This patch should not affect the new Sierra device support, because those devices are matched via interface-specific matching and thus should never hit the composite code. Signed-off-by: Dan Williams <dcbw@redhat.com> Tested-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
Bjorn's latest patchset does break Gobi 1K and 2K because on both
devices as it claims usb interface 0.  That's because usbif 0 is not
handled in the switch statement, and thus the if0 gets claimed when it
should not.  So let's just make things even simpler yet, and handle both
the 1K and 2K+ cases separately.  This patch should not affect the new
Sierra device support, because those devices are matched via
interface-specific matching and thus should never hit the composite
code.

Signed-off-by: Dan Williams <dcbw@redhat.com>
Tested-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB: serial: Fix mos7840 timeout 2012-08-15T22:10:50+00:00 Mark Ferrell mferrell@uplogix.com 2012-07-24T18:38:31+00:00 1e658489ba8d87b7c89ca6f734b8319acc534dbc * mos7840 driver was using multiple of HZ for the timeout handed off to usb_control_msg(). Changed the timeout to use msecs instead. * Remove unused WAIT_FOR_EVER definition Signed-off-by: Mark Ferrell <mferrell@uplogix.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
* mos7840 driver was using multiple of HZ for the timeout handed off to
  usb_control_msg().  Changed the timeout to use msecs instead.

* Remove unused WAIT_FOR_EVER definition

Signed-off-by: Mark Ferrell <mferrell@uplogix.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>