linux.git/drivers/usb, branch v3.6-rc7

Merge branch 'chipidea-stable' into usb-linus

2012-09-12T18:12:31+00:00

Chipidea patches for 3.6

Signed-off-by: Greg Kroah-Hartman

usb: chipidea: udc: don't stall endpoint if request list is empty in isr_tr_complete_low

2012-09-12T17:58:38+00:00

When attaching an imx28 or imx53 in USB gadget mode to a Windows host and
starting a rndis connection we see this message every 4-10 seconds:

    g_ether gadget: high speed config #2: RNDIS

Analysis shows that each time this message is printed, the rndis connection is
re-establish due to a reset because of a stalled endpoint (ep 0, dir 1). The
endpoint is stalled because the reqeust complete bit on that endpoint is set,
but in isr_tr_complete_low() the endpoint request list (mEp->qh.queue) is
empty.

This patch removed this check, because the code doesn't take the following
situation into account:

The loop over all endpoints in isr_tr_complete_handler() will call ep_nuke() on
both ep0/dir0 and ep/dir1 in the first loop. Pending reqeusts will be flushed
and completed here. There seems to be a race condition, the request is nuked,
but the request complete bit will be set, too. The subsequent check (in
ep0/dir1's loop cycle) for endpoint request list (mEp->qh.queue) empty will
fail.

Both other mainline chipidea drivers (mv_udc_core.c and fsl_udc_core.c) don't
have this check.

Cc: stable 
Signed-off-by: Michael Grzeschik 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Alexander Shishkin 
Signed-off-by: Greg Kroah-Hartman

usb: chipidea: cleanup dma_pool if udc_start() fails

2012-09-12T17:58:38+00:00

If udc_start() fails the qh_pool dma-pool cannot be closed because
it's still in use. This patch factors out the dma_pool_free() loop
into destroy_eps() and calls it in the error path of udc_start(),
too.

Cc: stable 
Reviewed-by: Richard Zhao 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Alexander Shishkin 
Signed-off-by: Greg Kroah-Hartman

usb: chipidea: udc: fix error path in udc_start()

2012-09-12T17:58:38+00:00

This patch fixes the error path of udc_start(). Now NULL is used to
unset the peripheral with otg_set_peripheral().

Cc: stable 
Reviewed-by: Richard Zhao 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Alexander Shishkin 
Signed-off-by: Greg Kroah-Hartman

usb: chipidea: udc: add pullup fuction, needed by the uvc gadget

2012-09-12T17:58:38+00:00

Add function to physicaly enable or disable of pullup connection on the USB-D+
line. The uvc gaget will fail, if this function is not implemented.

Cc: stable 
Signed-off-by: Michael Grzeschik 
Acked-by: Felipe Balbi 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Alexander Shishkin 
Signed-off-by: Greg Kroah-Hartman

usb: chipidea: udc: fix setup of endpoint maxpacket size

2012-09-12T17:58:37+00:00

This patch changes the setup of the endpoint maxpacket size. All non control
endpoints are initialized with an undefined ((unsigned short)~0) maxpacket
size. The maxpacket size of Endpoint 0 will be kept at CTRL_PAYLOAD_MAX.

Some gadget drivers check for the maxpacket size before they enable the
endpoint, which leads to a wrong state in these drivers.

Cc: stable 
Signed-off-by: Michael Grzeschik 
Acked-by: Felipe Balbi 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Alexander Shishkin 
Signed-off-by: Greg Kroah-Hartman

USB: option: replace ZTE K5006-Z entry with vendor class rule

2012-09-11T19:34:29+00:00

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 
Cc: stable 
Signed-off-by: Bjørn Mork 
Signed-off-by: Greg Kroah-Hartman

EHCI: Update qTD next pointer in QH overlay region during unlink

2012-09-10T23:01:37+00:00

There is a possibility of QH overlay region having reference to a stale
qTD pointer during unlink.

Consider an endpoint having two pending qTD before unlink process begins.
The endpoint's QH queue looks like this.

qTD1 --> qTD2 --> Dummy

To unlink qTD2, QH is removed from asynchronous list and Asynchronous
Advance Doorbell is programmed.  The qTD1's next qTD pointer is set to
qTD2'2 next qTD pointer and qTD2 is retired upon controller's doorbell
interrupt.  If QH's current qTD pointer points to qTD1, transfer overlay
region still have reference to qTD2. But qtD2 is just unlinked and freed.
This may cause EHCI system error.  Fix this by updating qTD next pointer
in QH overlay region with the qTD next pointer of the current qTD.

Signed-off-by: Pavankumar Kondeti 
Acked-by: Alan Stern 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

USB: cdc-wdm: fix wdm_find_device* return value

2012-09-10T22:33:00+00:00

A logic error made the wdm_find_device* functions
return a bogus pointer into static data instead of
the intended NULL no matching device was found.

Cc: stable  # v3.4+
Cc: Oliver Neukum 
Signed-off-by: Bjørn Mork 
Signed-off-by: Greg Kroah-Hartman

USB: ftdi_sio: do not claim CDC ACM function

2012-09-10T17:55:52+00:00

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 
Reported-by: Xiaofan Chen 
Cc: stable 
Cc: Alan Cox 
Cc: Bruno Thomsen 
Signed-off-by: Bjørn Mork 
Signed-off-by: Greg Kroah-Hartman