linux-stable.git/drivers/usb/chipidea, branch v3.15.7 Linux kernel stable tree usb: chipidea: udc: Disable auto ZLP generation on ep0 2014-07-28T15:08:19+00:00 Abbas Raza Abbas_Raza@mentor.com 2014-07-17T11:34:31+00:00 367d4803f7f685cba99c31722ba6e7736270f931 commit 953c66469735aed8d2ada639a72b150f01dae605 upstream. 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. Signed-off-by: Abbas Raza <Abbas_Raza@mentor.com> Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 953c66469735aed8d2ada639a72b150f01dae605 upstream.

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.

Signed-off-by: Abbas Raza <Abbas_Raza@mentor.com>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: chipidea: udc: delete td from req's td list at ep_dequeue 2014-07-09T18:21:24+00:00 Peter Chen peter.chen@freescale.com 2014-07-02T04:16:31+00:00 02aa24f7a8100e3aa8512030498fc7240f67d210 commit e4adcff09ca39ecbcc4851d40d0f0a5458e7b77a upstream. 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 <andrzej.p@samsung.com> Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit e4adcff09ca39ecbcc4851d40d0f0a5458e7b77a upstream.

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 <andrzej.p@samsung.com>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: chipidea: coordinate usb phy initialization for different phy type 2014-04-24T19:45:40+00:00 Peter Chen peter.chen@freescale.com 2014-04-24T00:15:27+00:00 cd84f009e98b3aa6109503f80f66ccf3e19e8fa9 For internal PHY (like UTMI), the phy clock may from internal pll, it is on/off on the fly, the access PORTSC.PTS will hang without phy clock. So, the usb_phy_init which will open phy clock needs to be called before hw_phymode_configure. See: http://marc.info/?l=linux-arm-kernel&m=139350618732108&w=2 For external PHY (like ulpi), it needs to configure portsc.pts before visit viewport, or the viewport can't be visited. so phy_phymode_configure needs to be called before usb_phy_init. See: cd0b42c2a6d2a74244f0053f8960f5dad5842278 It may not the best solution, but it can work for all situations. Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Chris Ruehl <chris.ruehl@gtsys.com.hk> Cc: shc_work@mail.ru Cc: denis@eukrea.com Cc: festevam@gmail.com Cc: stable <stable@vger.kernel.org> # 3.14 Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
For internal PHY (like UTMI), the phy clock may from internal pll,
it is on/off on the fly, the access PORTSC.PTS will hang without
phy clock. So, the usb_phy_init which will open phy clock needs to
be called before hw_phymode_configure.
See: http://marc.info/?l=linux-arm-kernel&m=139350618732108&w=2

For external PHY (like ulpi), it needs to configure portsc.pts before
visit viewport, or the viewport can't be visited. so phy_phymode_configure
needs to be called before usb_phy_init.
See: cd0b42c2a6d2a74244f0053f8960f5dad5842278

It may not the best solution, but it can work for all situations.

Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Chris Ruehl <chris.ruehl@gtsys.com.hk>
Cc: shc_work@mail.ru
Cc: denis@eukrea.com
Cc: festevam@gmail.com
Cc: stable <stable@vger.kernel.org> # 3.14
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: chipidea: add support for USB OTG controller on LSI Zevio SoCs 2014-03-12T19:32:21+00:00 Daniel Tang dt.tangr@gmail.com 2014-03-11T05:47:39+00:00 7b92e1ddb17f37caf37d4477483a62a425ba428f The USB controller in TI-NSPIRE calculators (LSI Zevio SoC) are based off either Freescale's USB OTG controller or the USB controller found in the IMX233, both of which are Chipidea compatible. This patch adds a device tree binding for the controller. Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Daniel Tang <dt.tangr@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
The USB controller in TI-NSPIRE calculators (LSI Zevio SoC) are based off either
Freescale's USB OTG controller or the USB controller found in the IMX233, both
of which are Chipidea compatible.

This patch adds a device tree binding for the controller.

Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Daniel Tang <dt.tangr@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: chipidea: imx: Use dev_name() for ci_hdrc name to distinguish USBs 2014-03-12T19:32:21+00:00 Alexander Shiyan shc_work@mail.ru 2014-03-11T05:47:38+00:00 c844d6c884f372dcde158c84b61c373ebc529519 Use dev_name() for ci_hdrc name to distinguish USBs Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Alexander Shiyan <shc_work@mail.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
Use dev_name() for ci_hdrc name to distinguish USBs

Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: chipidea: udc: refine isr_tr_complete_handler 2014-03-12T19:32:21+00:00 Peter Chen peter.chen@freescale.com 2014-03-11T05:47:37+00:00 d7b00e310b3342a6c5b8f648283ea55665614b67 Matthieu CASTET and Michael Grzeschik mentioned isr_tr_complete_handler is a bit messy at below: http://marc.info/?l=linux-usb&m=139047775001152&w=2 This commit creates a new function isr_setup_packet_handler to handle setup packet, it makes isr_tr_complete_handler easy to read. This is no functional change at this commit, tested with g_mass_storage and g_ether. Cc: Michael Grzeschik <mgr@pengutronix.de> Cc: Matthieu CASTET <matthieu.castet@parrot.com> Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
Matthieu CASTET and Michael Grzeschik mentioned isr_tr_complete_handler
is a bit messy at below:
http://marc.info/?l=linux-usb&m=139047775001152&w=2

This commit creates a new function isr_setup_packet_handler to handle
setup packet, it makes isr_tr_complete_handler easy to read.

This is no functional change at this commit, tested with g_mass_storage
and g_ether.

Cc: Michael Grzeschik <mgr@pengutronix.de>
Cc: Matthieu CASTET <matthieu.castet@parrot.com>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: chipidea: Propagate the real error code on platform_get_irq() failure 2014-02-25T01:07:53+00:00 Fabio Estevam fabio.estevam@freescale.com 2014-02-19T05:41:44+00:00 42d182124801573e06284200d81c3963962e753d No need to return a 'fake' return value on platform_get_irq() failure. Just return the error code itself instead. Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
No need to return a 'fake' return value on platform_get_irq() failure.

Just return the error code itself instead.

Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: chipidea: udc: add maximum-speed = full-speed option 2014-02-25T01:07:52+00:00 Michael Grzeschik m.grzeschik@pengutronix.de 2014-02-19T05:41:43+00:00 4f6743d5ca97ac66831add302cc5467db4ee3809 This patch makes it possible to set the chipidea udc into full-speed only mode. It is set by the oftree property "maximum-speed = full-speed". Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
This patch makes it possible to set the chipidea udc into full-speed only mode.
It is set by the oftree property "maximum-speed = full-speed".

Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: chipidea: use dev_get_platdata() 2014-02-25T01:07:52+00:00 Jingoo Han jg1.han@samsung.com 2014-02-19T05:41:42+00:00 fad56745a641750745d85f59d5cc640a1a4c1719 Use the wrapper function for retrieving the platform data instead of accessing dev->platform_data directly. This is a cosmetic change to make the code simpler and enhance the readability. Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
Use the wrapper function for retrieving the platform data instead
of accessing dev->platform_data directly. This is a cosmetic change
to make the code simpler and enhance the readability.

Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: chipidea: udc: refine ep operation at isr_tr_complete_handler 2014-02-25T01:07:52+00:00 Peter Chen peter.chen@freescale.com 2014-02-19T05:41:41+00:00 64fc06c40e01aa8129f5bc4c51567b5e205126b0 - delete the warning message at interrupt handler, and adds judgement at ep_enable, if non-ep0 requests ctrl transfer, it will indicate an error. - delete hw_test_and_clear_setup_status which is a broken code - Tested with g_mass_storage, g_ncm, g_ether Cc: matthieu.castet@parrot.com Reported-by: Michael Grzeschik <mgr@pengutronix.de> Acked-by: Michael Grzeschik <mgr@pengutronix.de> Tested-by: Michael Grzeschik <mgr@pengutronix.de> Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
- delete the warning message at interrupt handler, and adds judgement at
ep_enable, if non-ep0 requests ctrl transfer, it will indicate an error.
- delete hw_test_and_clear_setup_status which is a broken code
- Tested with g_mass_storage, g_ncm, g_ether

Cc: matthieu.castet@parrot.com
Reported-by: Michael Grzeschik <mgr@pengutronix.de>
Acked-by: Michael Grzeschik <mgr@pengutronix.de>
Tested-by: Michael Grzeschik <mgr@pengutronix.de>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>