linux-stable.git/drivers/usb/chipidea, branch v3.16.2

usb: chipidea: udc: Disable auto ZLP generation on ep0

2014-07-17T23:51:22+00:00

There are 2 methods for ZLP (zero-length packet) generation:
1) In software
2) Automatic generation by device controller

1) is implemented in UDC driver and it attaches ZLP to IN packet if
   descriptor->size < wLength
2) can be enabled/disabled by setting ZLT bit in the QH

When gadget ffs is connected to ubuntu host, the host sends
get descriptor request and wLength in setup packet is 255 while the
size of descriptor which will be sent by gadget in IN packet is
64 byte. So the composite driver sets req->zero = 1.
In UDC driver following code will be executed then

        if (hwreq->req.zero && hwreq->req.length
            && (hwreq->req.length % hwep->ep.maxpacket == 0))
                add_td_to_list(hwep, hwreq, 0);

Case-A:
So in case of ubuntu host, UDC driver will attach a ZLP to the IN packet.
ubuntu host will request 255 byte in IN request, gadget will send 64 byte
with ZLP and host will come to know that there is no more data.
But hold on, by default ZLT=0 for endpoint 0 so hardware also tries to
automatically generate the ZLP which blocks enumeration for ~6 seconds due
to endpoint 0 STALL, NAKs are sent to host for any requests (OUT/PING)

Case-B:
In case when gadget ffs is connected to Apple device, Apple device sends
setup packet with wLength=64. So descriptor->size = 64 and wLength=64
therefore req->zero = 0 and UDC driver will not attach any ZLP to the
IN packet. Apple device requests 64 bytes, gets 64 bytes and doesn't
further request for IN data. But ZLT=0 by default for endpoint 0 so
hardware tries to automatically generate the ZLP which blocks enumeration
for ~6 seconds due to endpoint 0 STALL, NAKs are sent to host for any
requests (OUT/PING)

According to USB2.0 specs:

    8.5.3.2 Variable-length Data Stage
    A control pipe may have a variable-length data phase in which the
    host requests more data than is contained in the specified data
    structure. When all of the data structure is returned to the host,
    the function should indicate that the Data stage is ended by
    returning a packet that is shorter than the MaxPacketSize for the
    pipe. If the data structure is an exact multiple of wMaxPacketSize
    for the pipe, the function will return a zero-length packet to indicate
    the end of the Data stage.

In Case-A mentioned above:
If we disable software ZLP generation & ZLT=0 for endpoint 0 OR if software
ZLP generation is not disabled but we set ZLT=1 for endpoint 0 then
enumeration doesn't block for 6 seconds.

In Case-B mentioned above:
If we disable software ZLP generation & ZLT=0 for endpoint then enumeration
still blocks due to ZLP automatically generated by hardware and host not needing
it. But if we keep software ZLP generation enabled but we set ZLT=1 for
endpoint 0 then enumeration doesn't block for 6 seconds.

So the proper solution for this issue seems to disable automatic ZLP generation
by hardware (i.e by setting ZLT=1 for endpoint 0) and let software (UDC driver)
handle the ZLP generation based on req->zero field.

Cc: stable@vger.kernel.org
Signed-off-by: Abbas Raza 
Signed-off-by: Peter Chen 
Signed-off-by: Greg Kroah-Hartman

usb: chipidea: udc: delete td from req's td list at ep_dequeue

2014-07-02T06:06:02+00:00

We need to delete un-finished td from current request's td list
at ep_dequeue API, otherwise, this non-user td will be remained
at td list before this request is freed. So if we do ep_queue->
ep_dequeue->ep_queue sequence, when the complete interrupt for
the second ep_queue comes, we search td list for this request,
the first td (added by the first ep_queue) will be handled, and
its status is still active, so we will consider the this transfer
still not be completed, but in fact, it has completed. It causes
the peripheral side considers it never receives current data for
this transfer.

We met this problem when do "Error Recovery Test - Device Configured"
test item for USBCV2 MSC test, the host has never received ACK for
the IN token for CSW due to peripheral considers it does not get this
CBW, the USBCV test log like belows:

--------------------------------------------------------------------------
INFO
Issuing BOT MSC Reset, reset should always succeed
INFO
Retrieving status on CBW endpoint
INFO
CBW endpoint status = 0x0
INFO
Retrieving status on CSW endpoint
INFO
CSW endpoint status = 0x0
INFO
Issuing required command (Test Unit Ready) to verify device has recovered
INFO
Issuing CBW (attempt #1):
INFO
|----- CBW LUN                  = 0x0
INFO
|----- CBW Flags                = 0x0
INFO
|----- CBW Data Transfer Length = 0x0
INFO
|----- CBW CDB Length           = 0x6
INFO
|----- CBW CDB-00 = 0x0
INFO
|----- CBW CDB-01 = 0x0
INFO
|----- CBW CDB-02 = 0x0
INFO
|----- CBW CDB-03 = 0x0
INFO
|----- CBW CDB-04 = 0x0
INFO
|----- CBW CDB-05 = 0x0
INFO
Issuing CSW : try 1
INFO
CSW Bulk Request timed out!
ERROR
Failed CSW phase : should have been success or stall
FAIL
(5.3.4) The CSW status value must be 0x00, 0x01, or 0x02.
ERROR
BOTCommonMSCRequest failed:  error=80004000

Cc: Andrzej Pietrasiewicz 
Cc: stable@vger.kernel.org
Signed-off-by: Peter Chen 
Signed-off-by: Greg Kroah-Hartman

usb: chipidea: udc: update gadget states according to ch9

2014-05-23T02:36:44+00:00

Update device states according to ch9 in USB 2.0 specification

Signed-off-by: Peter Chen 
Signed-off-by: Greg Kroah-Hartman

usb: chipidea: msm: Initialize offset of the capability registers

2014-05-23T02:36:44+00:00

Since commit 62bb84e (usb: gadget: ci13xxx: convert to platform device)
start address of the capability registers is not passed correctly to
udc_probe(). Fix this.

Signed-off-by: Peter Chen 
Signed-off-by: Ivan T. Ivanov 
Signed-off-by: Greg Kroah-Hartman

usb: chipidea: msm: Add device tree support

2014-05-23T02:36:44+00:00

Allows controller to be specified via device tree.
Pass PHY phandle specified in DT to core driver.

Signed-off-by: Peter Chen 
Signed-off-by: Ivan T. Ivanov 
Signed-off-by: Greg Kroah-Hartman

chipidea: usbmisc_imx: Allow USB OTG to work on mx51

2014-05-23T02:36:43+00:00

The field PLLDIVVALUE of register PHY_CTRL_1 selects the reference clock source
for the PHY:
00 = sysclock uses 19.2 MHz
01 = sysclock uses 24 MHz
10 = sysclock uses 26 MHz
11 = sysclock uses 27 MHz

The reset value for this field is 10 according to the reference manual, and
even though this reset value works for mx53, it does not work for mx51.

So instead of relying on the reset value for the PLLDIVVALUE field, explicitly
set it to 01 so that a 24MHz clock can be selected for the PHY and allowing both
mx51 and mx53 to have USB OTG port functional.

Succesfully tested 'g_ether' on a imx51-babbage and on a imx53-qsb boards.

Signed-off-by: Peter Chen 
Signed-off-by: Fabio Estevam 
Signed-off-by: Greg Kroah-Hartman

usb: chipidea: using one inline function to cover queue work operations

2014-05-23T02:35:02+00:00

The otg queue work include operations: one is disable interrupt,
another one is call kernel queue work API. Many codes do this
operation, using one inline function to instead of them.

Signed-off-by: Peter Chen 
Signed-off-by: Greg Kroah-Hartman

usb: chipidea: udc: delete useless code

2014-05-23T02:35:01+00:00

Delete useless code

Signed-off-by: Peter Chen 
Signed-off-by: Greg Kroah-Hartman

usb: chipidea: update TODO list

2014-05-23T02:35:01+00:00

Update TODO list

Signed-off-by: Peter Chen 
Signed-off-by: Greg Kroah-Hartman

usb: chipidea: debug: add debug file for OTG variables

2014-04-24T19:56:35+00:00

This patch adds a debug file for OTG vairables show.

Signed-off-by: Peter Chen 
Signed-off-by: Li Jun 
Signed-off-by: Greg Kroah-Hartman