linux/drivers/usb/serial, branch v3.0

USB: Add new FT232H chip to drivers/usb/serial/ftdi_sio.c

2011-06-27T20:46:44Z

appended patch adds support for the new FTDI FT232H chip. This chip is a single channel version of the dual FT2232H/quad FT4232H, coming with it's own default PID 0x6014 (FT2232H uses the same PID 0x6010 like FT2232C, FT4232H has also it's own PID). The patch was checked on an UM232H module and a terminal program with TX/RX shorted to that typing in the terminal reproduced the characters. Signed-off-by: Uwe Bonnes Cc: stable Signed-off-by: Greg Kroah-Hartman

USB: TI 3410/5052 USB Serial Driver: Fix mem leak when firmware is too big.

2011-06-14T21:20:30Z

If the size of the firmware exceeds TI_FIRMWARE_BUF_SIZE we'll leak 'fw_p' by failing to call release_firmware(). This patch fixes the leak. Signed-off-by: Jesper Juhl Signed-off-by: Greg Kroah-Hartman

USB: serial: add another 4N-GALAXY.DE PID to ftdi_sio driver

2011-06-08T20:48:30Z

E.g. newer CAN 2.0 A/B <=> USB 2.0 converters report idProduct=f3c2. Signed-off-by: Steffen Sledz Cc: stable Signed-off-by: Greg Kroah-Hartman

Revert "USB: option: add ID for ZTE MF 330"

2011-06-07T22:03:37Z

This reverts commit a559d2c8c1bf652ea2d0ecd6ab4a250fcdb37db8. 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 Cc: Michael Tokarev Cc: Dominik Brodowski Cc: stable Signed-off-by: Greg Kroah-Hartman

USB: option Add blacklist for ZTE K3765-Z (19d2:2002)

2011-06-06T22:58:57Z

The funtion option_send_status times out when sending USB messages to the interfaces 0, 1, and 2 of this UMTS stick. This results in a 5s timeout in the function causing other tty operations to feel very sluggish. This patch adds a blacklist entry for these 3 interfaces on the ZTE K3765-Z device. I was also able to reproduce the problem with v2.6.38 and v2.6.39. This is very similar to a problem fixed in commit 7a89e4cb9cdaba92f5fbc509945cf4e3c48db4e2 Author: Herton Ronaldo Krzesinski Date: Wed Mar 9 09:19:48 2011 +0000 USB: serial: option: Apply OPTION_BLACKLIST_SENDSETUP also for ZTE MF626 Signed-off-by: Torsten Hilbrich Cc: stable Signed-off-by: Greg Kroah-Hartman

option: add Prolink PH300 modem IDs

2011-06-06T22:58:15Z

Simple ID addition. Signed-off-by: Dan Williams Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman

option: add Alcatel X200 to sendsetup blacklist

2011-06-06T22:58:14Z

This modem really wants sendsetup blacklisted for interfaces 0 and 1, otherwise the kernel hardlocks for about 10 seconds while waiting for the modem's firmware to respond, which it of course doesn't do. A slight complication here is that TCT (who owns the Alcatel brand) used the same USB IDs for the X200 as the X060s despite the devices having completely different firmware and AT command sets, so we end up adding the X060s to the blacklist at the same time. PSA to OEMs: don't use the same USB IDs for different devices. Really. It makes your kittens cry. Signed-off-by: Dan Williams Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman

option: add Zoom 4597 modem USB IDs

2011-06-06T22:58:14Z

Uses Longcheer-based firmware and AT command set. Signed-off-by: Dan Williams Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman

USB: option: add support for Huawei E353 device

2011-05-17T18:20:22Z

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: Marcin Galczynski Cc: stable Signed-off-by: Greg Kroah-Hartman

drivers/usb/serial/opticon.c: Release resources on kmalloc failure

2011-05-13T22:51:08Z

Several resources have been allocated before this kmalloc failure, and thus they should be released in this error handling code, as done in nearby error handling code. The semantic match that finds this problem is: (http://coccinelle.lip6.fr/) // @r exists@ local idexpression urb; statement S; position p1,p2; @@ urb = usb_alloc_urb@p1(...); ... when != urb if (urb == NULL) S ... when != urb ( return <+...urb...+>; | return@p2 ...; ) @script:python@ p1 << r.p1; p2 << r.p2; @@ cocci.print_main("",p1) cocci.print_secs("",p2) // Signed-off-by: Julia Lawall Signed-off-by: Greg Kroah-Hartman