Merge 3.5-rc4 into usb-next

This is to get the USB fixes that were merged in the 3.5-rc4 tree into usb-next
so that everyone can sync up properly.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Revert "usb/uas: make sure data urb is gone if we receive status before that"

This reverts commit e4d8318a85779b25b880187b1b1c44e797bd7d4b.

This patch makes uas.c call usb_unlink_urb on data urbs.  The data urbs
get freed in the completion callback.  This is illegal according to the
usb_unlink_urb documentation.

This patch also makes the code expect the data completion callback
being called before the status completion callback.  This isn't
guaranteed to be the case, even though the actual data transfer should
be finished by the time the status is received.

Background:  The ehci irq handler for example only know that there are
finished transfers, it then has go check the QHs & TDs to see which
transfers did actually finish.  It has no way to figure in which order
the transfers did complete.  The xhci driver can call the callbacks in
completion order thanks to the event queue.  This does nicely explain
why the driver is solid on a (usb2) xhci port whereas it goes crazy on
ehci in my testing.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Revert "usb/uas: one only one status URB/host on stream-less connection"

This reverts commit ceb3f91fd53c9fbd7b292fc2754ba4efffeeeedb.

IMO the real bug is assigning status urbs to scsi requests.  First there
is no such link in the non-stream case.  Also there isn't nessesarely a
scsi request in the first place, for example when submitting task
management requests.

This patch just papers over the real bug and introduces different status
urb handling in the stream/non-stream case for no good reason.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
uas: fix sense urb handling

Stop reusing sense urbs, just allocate a fresh one each time and free it
when done.

Stop storing a sense urb pointer in the scsi request, all you can do
with it is misusing.  For example requeuing the sense urb, then f*ck it
up by picking the wrong one in case tagged requests don't finish in the
same order you've submitted them.  Also note that (not-yet supported)
task management ops don't have a scsi request in the first place.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
uas: keep track of command state, finish scsi cmd when really done.

Set state bits after submitting data urbs & command urbs, so we know
what is in flight.  Clear data bits when the data urb is finished, clear
command bit when we see the status urb for the command.  Finish the scsi
command after running both status and data completion handlers for the
command.

Add a cmd status logging function for debugging purposes.  Hook it into
the error handler, so we see in the log what status a command is in
which the scsi layer wants cancel.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
uas: improve error handling

(1) Handle data pipe errors: When the data urb failed we
    didn't transfer anything, update scsi_cmnd accordingly.
(2) Cancel data transfers when we got back an error on the
    status pipe.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
uas: track urbs, kill inflight urbs on disconnect.

Use separate anchors for data and sense urbs, which
I think will be useful when implementing error handling.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
uas: task mgmt & error handling

Add task management support, wind up in abort and device reset error
handlers.  Cancel all in-flight urbs in bus reset handler.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB: FHCI: Reusing QUICC Engine USB Controller registers from immap_qe.h

The struct fhci_regs (in drivers/usb/host/fhci.h) is basically a redefinition
of the struct qe_usb_ctlr (in arch/powerpc/include/asm/immap_qe.h).

The qe_usb_ctlr struct is preferrable once it uses accurately the registers'
names found in the Freescale's QUICC Engine Block Reference Manuals (QEIWRM.pdf
Rev.4.4 Chapter 19 for MPC836xE series and MPC8323ERM.pdf Rev.2 Chapter 36 for
MPC832xE series), making easier to map the FHCI device driver to the hardware
manual. Also, as the FHCI driver uses the USB Controller registers, the name
qe_usb_ctlr is a more precise representation of the hardware than fhci_regs.

Signed-off-by: Guilherme Maciel Ferreira <guilherme.maciel.ferreira@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB: EHCI: define extension registers like normal ones

This patch (as1562) cleans up the definitions of the EHCI extended
registers to be consistent with the definitions of the standard
registers.  This makes the code look a lot nicer, with no functional
change.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ARM: OMAP: USB: Fixup ehci_hcd_omap_probe error path

A recent commit, [PATCH] Fix OMAP EHCI suspend/resume failure
(i693) '354ab856' causes ehci probe to fail on omap3xxx. This
exposed bugs in the ehci_hcd_omap_probe error path causing
an oops.

On the error path, call usb_remove_hcd if usb_add_hcd has been
called, and call usb_put_hcd if usb_alloc_hcd has been called.

Tested on BB-xM.

Signed-off-by: Russ.Dill@ti.com
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix OMAP EHCI suspend/resume failure (i693) '354ab856' causes

an oops on boot for all omap3xxx platforms that use usbhs_omap for
EHCI. The actual oops comes from faulty ehci-omap cleanup, but the
failure caused by the change is evidenced here:

[    3.655059] ehci-omap ehci-omap.0: utmi_p1_gfclk failed error:-2
[    3.661376] ehci-omap: probe of ehci-omap.0 failed with error -2

utmi_p1_gfclk is a clock that exists on OMAP4, but not OMAP3. In the
OMAP3 case, it is configured as a dummy clock. However, OMAP4 lists
the dev_id as NULL, but OMAP3 lists it as "usbhs_omap".

Attempting to get that clock from ehci-omap then fails. The solution
is to just change the clock3xxx_data.c for dummy clocks used in the
errata fix to match the dev_id, NULL, used in clock44xx_data.c.

Tested on BB-xM.

Signed-off-by: Russ Dill <Russ.Dill@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: chipidea: remove unneeded NULL check

As reported by Dan Carpenter, there is a NULL check in udc_start() that
follows a dereference of the pointer that's being checked. However, at
that point udc pointer shouldn't ever be NULL and if it is, the dereference
should cause an oops.

Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Richard Zhao <richard.zhao@freescale.com>
Acked-by: Marek Vasut <marex@denx.de>
usb: chipidea: drop useless arch-check

msm glue layer compiles on all arches just
fine. Let's drop the unnecessary ARCH check
so we have easier compile tests.

Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Richard Zhao <richard.zhao@freescale.com>
Acked-by: Marek Vasut <marex@denx.de>
usb: chipidea: msm: add missing section annotation

No functional changes, it will just free up some
code if we don't have hotplug.

Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Richard Zhao <richard.zhao@freescale.com>
Acked-by: Marek Vasut <marex@denx.de>
usb: chipidea: msm: add remove method

allow this driver to be removed too.

Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Richard Zhao <richard.zhao@freescale.com>
USB: Chipidea: rename struct ci13xxx_udc_driver to struct ci13xxx_platform_data

This patch rename struct ci13xxx_udc_driver and var with the type.

ci13xxx_platform_data reflect it's passed from platfrom driver.

Signed-off-by: Richard Zhao <richard.zhao@freescale.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
USB: Chipidea: rename struct ci13xxx variables from udc to ci

struct ci13xxx represent the controller, which may be device or host,
so name its variables as ci.

Signed-off-by: Richard Zhao <richard.zhao@freescale.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Reviewed-by: Marek Vasut <marex@denx.de>
USB: Chipidea: add unified ci13xxx_{add,remove}_device for platform drivers

Platform drivers do the similar things to add/remove ci13xxx device, so
create a unified one.

Signed-off-by: Richard Zhao <richard.zhao@freescale.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
USB: Chipidea: add ci13xxx device id management

We use ida_simple_get and ida_simple_remove to manage the ids.

Signed-off-by: Richard Zhao <richard.zhao@freescale.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>