linux-stable.git/drivers/usb/chipidea, branch linux-3.17.y

usb: chipidea: Fix oops when removing the ci_hdrc module

2014-11-14T18:10:34+00:00

commit 9680b60ed79edaf52f84b65cbb20859bbb26cb68 upstream.

The call of 'kfree(ci->hw_bank.regmap)' in ci_hdrc_remove() sometimes causes
a kernel oops when removing the ci_hdrc module.

Since there is no separate memory allocated for the ci->hw_bank.regmap array,
there is no need to free it.

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

usb: chipidea: msm: Initialize PHY on reset event

2014-09-11T00:30:39+00:00

Initialize USB PHY after every Link controller reset

Cc: 3.16+ 
Cc: Tim Bird 
Signed-off-by: Peter Chen 
Signed-off-by: Ivan T. Ivanov 
Signed-off-by: Greg Kroah-Hartman

usb: chipidea: msm: Use USB PHY API to control PHY state

2014-09-11T00:30:39+00:00

PHY drivers keep track of the current state of the hardware,
so don't change PHY settings under it.

Cc: 3.16+ 
Cc: Tim Bird 
Signed-off-by: Peter Chen 
Signed-off-by: Ivan T. Ivanov 
Acked-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

Merge tag 'usb-3.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb

2014-08-05T03:11:28+00:00

Pull USB updates from Greg KH:
 "Here is the big USB driver update for 3.17-rc1.

  Loads of gadget driver changes in here, including some big file
  movements to make things easier to manage over time.  There's also the
  usual xhci and uas driver updates, and a handful of other changes in
  here.  The changelog has the full details.

  All of these have been in linux-next for a while"

* tag 'usb-3.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (211 commits)
  USB: devio: fix issue with log flooding
  uas: Log a warning when we cannot use uas because the hcd lacks streams
  uas: Only complain about missing sg if all other checks succeed
  xhci: Add missing checks for xhci_alloc_command failure
  xhci: Rename Asrock P67 pci product-id to EJ168
  xhci: Blacklist using streams on the Etron EJ168 controller
  uas: Limit qdepth to 32 when connected over usb-2
  uwb/whci: use correct structure type name in sizeof
  usb-core bInterval quirk
  USB: serial: ftdi_sio: Add support for new Xsens devices
  USB: serial: ftdi_sio: Annotate the current Xsens PID assignments
  usb: chipidea: debug: fix sparse non static symbol warnings
  usb: ci_hdrc_imx doc: fsl,usbphy is required
  usb: ci_hdrc_imx: Return -EINVAL for missing USB PHY
  usb: core: allow zero packet flag for interrupt urbs
  usb: lvstest: Fix sparse warnings generated by kbuild test bot
  USB: core: hcd-pci: free IRQ before disabling PCI device when shutting down
  phy: miphy365x: Represent each PHY channel as a DT subnode
  phy: miphy365x: Provide support for the MiPHY356x Generic PHY
  phy: miphy365x: Add Device Tree bindings for the MiPHY365x
  ...

usb: chipidea: debug: fix sparse non static symbol warnings

2014-07-22T23:31:37+00:00

Fixes the following sparse warnings:

drivers/usb/chipidea/debug.c:211:5: warning:
 symbol 'ci_otg_show' was not declared. Should it be static?
drivers/usb/chipidea/debug.c:334:5: warning:
 symbol 'ci_registers_show' was not declared. Should it be static?

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

usb: ci_hdrc_imx: Return -EINVAL for missing USB PHY

2014-07-22T23:31:36+00:00

-ENODEV is interpreted by the generic driver probing function as a
non-matching driver. This leads to a missing probe failure message.

Also a missing USB PHY is more of an invalid configuration of the usb
driver because it is necessary.

This patch returns -EINVAL if devm_usb_get_phy_by_phandle() returned -ENODEV.

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

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