We want to do everything we can to ensure that USB 3.0 Link Power
Management (LPM) can be disabled when it is enabled.  If LPM can't be
disabled, we can't suspend USB 3.0 devices, or reset them.  To make sure
we can submit the command to disable LPM, allocate a command in the
xhci_hcd structure, and reserve one TRB on the command ring.

We only need one command per xHCI driver instance, because LPM is only
disabled or enabled while the USB core is holding the bandwidth_mutex
that is shared between the xHCI USB 2.0 and USB 3.0 roothubs.  The
bandwidth_mutex will be held until the command completes, or times out.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

The upcoming USB 3.0 Link PM patches will introduce new API to enable
and disable low-power link states.  We must be able to disable LPM in
order to reset a device, or place the device into U3 (device suspend).
Therefore, we need to make sure the Evaluate Context command to disable
the LPM timeouts can't fail due to there being no room on the command
ring.

Introduce a new flag to the function that queues the Evaluate Context
command, command_must_succeed.  This tells the ring handler that a TRB
has already been reserved for the command (by incrementing
xhci->cmd_ring_reserved_trbs), and basically ensures that prepare_ring()
won't fail.  A similar flag was already implemented for the Configure
Endpoint command queuing function.

All functions that currently call xhci_configure_endpoint() to issue an
Evaluate Context command pass "false" for the "must_succeed" parameter,
so this patch should have no effect on current xHCI driver behavior.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

USB 3.0 hubs can be put into a mode where the hub can automatically
request that the link go into a deeper link power state after the link
has been idle for a specified amount of time.  Each of the new USB 3.0
link states (U1 and U2) have their own timeout that can be programmed
per port.

Change the xHCI roothub emulation code to handle the request to set the
U1 and U2 timeouts.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

When the xHCI driver needs to clean up memory (perhaps due to a failed
register restore on resume from S3 or resume from S4), it needs to reset
the number of reserved TRBs on the command ring to zero.  Otherwise,
several resume cycles (about 30) with a UAS device attached will
continually increment the number of reserved TRBs, until all command
submissions fail because there isn't enough room on the command ring.

This patch should be backported to kernels as old as 2.6.32,
that contain the commit 913a8a34
"USB: xhci: Change how xHCI commands are handled."
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org

Some more data structures must be freed and counters
reset if an XHCI controller has lost power. The failure
to do so renders some chips inoperative after a certain number
of S4 cycles.

This patch should be backported to kernels as old as 3.2,
that contain the commits c29eea62
"xhci: Implement HS/FS/LS bandwidth checking." and
commit 839c817c
"xhci: Implement HS/FS/LS bandwidth checking."
Signed-off-by: NOliver Neukum <oneukum@suse.de>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org

Sergio reported that when he recorded audio from a USB headset mic
plugged into the USB 3.0 port on his ASUS N53SV-DH72, the audio sounded
"robotic".  When plugged into the USB 2.0 port under EHCI on the same
laptop, the audio sounded fine.  The device is:

Bus 002 Device 004: ID 046d:0a0c Logitech, Inc. Clear Chat Comfort USB Headset

The problem was tracked down to the Fresco Logic xHCI host controller
not correctly reporting short transfers on isochronous IN endpoints.
The driver would submit a 96 byte transfer, the device would only send
88 or 90 bytes, and the xHCI host would report the transfer had a
"successful" completion code, with an untransferred buffer length of 8
or 6 bytes.

The successful completion code and non-zero untransferred length is a
contradiction.  The xHCI host is supposed to only mark a transfer as
successful if all the bytes are transferred.  Otherwise, the transfer
should be marked with a short packet completion code.  Without the EHCI
bus trace, we wouldn't know whether the xHCI driver should trust the
completion code or the untransferred length.  With it, we know to trust
the untransferred length.

Add a new xHCI quirk for the Fresco Logic host controller.  If a
transfer is reported as successful, but the untransferred length is
non-zero, print a warning.  For the Fresco Logic host, change the
completion code to COMP_SHORT_TX and process the transfer like a short
transfer.

This should be backported to stable kernels that contain the commit
f5182b41 "xhci: Disable MSI for some
Fresco Logic hosts."  That commit was marked for stable kernels as old
as 2.6.36.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: NSergio Correia <lists@uece.net>
Tested-by: NSergio Correia <lists@uece.net>
Cc: stable@vger.kernel.org
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

The CI13xxx usb host needs the root TT support to work properly.
Allow selecting this for the CI13xxx too.
Signed-off-by: NMarek Vasut <marex@denx.de>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch (as1556) works around a bug in the Philips ISP1562 EHCI
controller.  Although the controller claims to support frame-list
lengths smaller than the default of 1024 for its periodic schedule, in
fact smaller values don't work.  A new quirk flag is added to indicate
when the bug is present, and if it is then the schedule size is left
at the default value.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch (as1555) improves the code ehci-hcd uses while checking the
periodic schedule for isochronous transfers to full-speed devices.  In
addition to making sure that a new transfer does not violate the
restrictions on the high-speed schedule, it also has to check the
restrictions on the full-speed part of the bus, i.e., the part beyond
the Transaction Translator (TT).

It does this by calling tt_available() (or tt_no_collision() if
CONFIG_USB_EHCI_TT_NEWSCHED isn't enabled).  However it calls that
routine on each pass through a loop over the frames being modified,
which is an unnecessary expense because tt_available() (or
tt_no_collision) already does its own loop over frames.  It is
sufficient to do the check just once, before starting the loop.

In addition, the function calls incorrectly converted the transfer's
period from microframes to frames by doing a left shift instead of a
right shift.  The patch fixes this while moving the calls.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit bebc56d5.

The call here is fragile and not well thought out, so revert it, it's
not fully baked yet and I don't want this to go into 3.5.

Cc: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Currently usb_put_transceiver calls put_device so this is a no-op but it
is better to keep API usage consistent as ohci->transceiver is allocated
with usb_get_transceiver.

While at there remove one extra ohci->transceiver test as the code block
has already tested it.
Signed-off-by: NJarkko Nikula <jarkko.nikula@bitmer.com>
Acked-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Currently usb_put_transceiver calls put_device so this is a no-op but it
is better to keep API usage consistent as ehci->transceiver is allocated
with usb_get_transceiver.

While at there remove one extra ehci->transceiver test as the code block
has already tested it.
Signed-off-by: NJarkko Nikula <jarkko.nikula@bitmer.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Move child's pointer to the struct usb_hub_port since the child device
is directly associated with the port. Provide usb_get_hub_child_device()
to get child's pointer.
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This adds EHCI host support to the chipidea driver. We want it to be
part of the hdrc driver and not a standalone (sub-)driver module, as
the structure of ehci-hcd.c suggests, so for chipidea controller we
hack it to not provide platform-related code, but only the ehci hcd.

The ehci-platform driver won't work for us here too, because the
controller uses the same registers for both device and host mode and
also otg-related bits, so it's not really possible to put ehci registers
into a separate resource.

This is not a pretty solution, but the alternative is exporting symbols
from the chipidea driver to a ehci-chipidea driver and doing all the
module refcounting.
Signed-off-by: NAlexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix driver to work properly in big endian mode.
Signed-off-by: NSteven J. Hill <sjhill@mips.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

A possible race condition appears because we are not initializing
the ohci->regs before calling usb_hcd_request_irqs().
We move the call to ohci_init() in hcd->driver->reset() instead of
hcd->driver->start() to fix this.
This was experienced when we share the same IRQ line between OHCI and EHCI
controllers.
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Tested-by: NChristian Eggers <christian.eggers@kathrein.de>
Cc: stable <stable@vger.kernel.org>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When PHY reset pin is connected to a GPIO on external GPIO chip
(e.g. I2C), we should not call the gpio_set_value() function, but
gpio_set_value_cansleep().
Signed-off-by: NIgor Grinberg <grinberg@compulab.co.il>
Acked-by: NFelipe Balbi <balbi@ti.com>
Tested-by: NGovindraj.R <govindraj.raja@ti.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The Davinci USB platform device (in mach-davinci/usb.c) uses "ohci"
as the name. To allow autoloading of the relevant driver, the module
needs to set the MODULE_ALIAS.
Signed-off-by: NJan Luebbe <jlu@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Testing BUILD_BUG_ON xhci_doorbell_array structure 2 time, redundant statement
Signed-off-by: NGirish Verma <girish.gcet@gmail.com>
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>

 ---
 drivers/usb/host/xhci.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch changes the output format specifier of a debugging line in
the xhci-hcd driver.  An URB's transfer_buffer_length should be
printed in decimal; there's no reason to print it in hex.  Especially
since the actual_length value, printed earlier on the same line, is
already in decimal.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue' (1fcb57d0) created a regression
with Beagleboard xM if booting the kernel after running 'usb start' under u-boot.

Finishing the reset before calling 'usb_add_hcd' fixes the regression. This is most likely due to
usb_add_hcd calling the driver's reset and init functions which expect the hardware to be
up and running.
Signed-off-by: NRuss Dill <Russ.Dill@ti.com>
Acked-by: NFelipe Balbi <balbi@ti.com>
Cc: stable <stable@vger.kernel.org> [3.4]
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The upcoming Intel Lynx Point chipset includes an xHCI host controller
that can have ports switched from the EHCI host controller, just like
the Intel Panther Point xHCI host.  This time, ports from both EHCI
hosts can be switched to the xHCI host controller.  The PCI config
registers to do the port switching are in the exact same place in the
xHCI PCI configuration registers, with the same semantics.

Hooray for shipping patches for next-gen hardware before the current gen
hardware is even available for purchase!

This patch should be backported to stable kernels as old as 3.0,
that contain commit 69e848c2
"Intel xhci: Support EHCI/xHCI port switching."
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org

If the user chooses to say "no" to CONFIG_USB_XHCI_HCD on a system
with an Intel Panther Point chipset, the PCI quirks code or the EHCI
driver will switch the ports over to the xHCI host, but the xHCI driver
will never load.  The ports will be powered off and seem "dead" to the
user.

Fix this by only switching the ports over if CONFIG_USB_XHCI_HCD is
either compiled in, or compiled as a module.

This patch should be backported to stable kernels as old as 3.0,
that contain commit 69e848c2
"Intel xhci: Support EHCI/xHCI port switching."
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: NEric Anholt <eric.anholt@intel.com>
Reported-by: NDavid Bein <d.bein@f5.com>
Cc: stable@vger.kernel.org

While testing unplugging an UVC HD webcam with usb-redirection (so through
usbdevfs), my userspace usb-redir code was getting a value of -1 in
iso_frame_desc[n].status, which according to Documentation/usb/error-codes.txt
is not a valid value.

The source of this -1 is the default case in xhci-ring.c:process_isoc_td()
adding a kprintf there showed the value of trb_comp_code to be COMP_TX_ERR
in this case, so this patch adds handling for that completion code to
process_isoc_td().

This was observed and tested with the following xhci controller:
1033:0194 NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04)

Note: I also wonder if setting frame->status to -1 (-EPERM) is the best we can
do, but since I cannot come up with anything better I've left that as is.

This patch should be backported to kernels as old as 2.6.36, which contain the
commit 04e51901 "USB: xHCI: Isochronous
transfer implementation".
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org

This commit adds a bit-array to xhci bus_state for keeping track of
which ports are undergoing a resume transition. If any of the bits
are set when xhci_hub_status_data() is called, the routine will return
a non-zero value even if no ports have any status changes pending.
This will allow usbcore to handle races between root-hub suspend and
port wakeup.

This patch should be backported to kernels as old as 3.4, that contain
the commit 879d38e6 "USB: fix race
between root-hub suspend and remote wakeup".
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: stable@vger.kernel.org

dbg() was a very old USB-specific macro that should no longer
be used. This patch removes it from being used in the driver
and uses dev_dbg() instead.

CC: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
CC: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
CC: Tobias Klauser <tklauser@distanz.ch>
CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

dbg() was a very old USB-specific macro that should no longer
be used. This patch removes it from being used in the driver
and uses dev_dbg() instead.

CC: Rusty Russell <rusty@rustcorp.com.au>
CC: David Howells <dhowells@redhat.com>
CC: Alan Stern <stern@rowland.harvard.edu>
CC: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

dbg() was a very old USB-specific macro that should no longer
be used. This patch removes it from being used in the driver
and uses dev_dbg() instead.

CC: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

dbg() was a very old USB-specific macro that should no longer
be used. This patch removes it from being used in the driver
and uses dev_dbg() instead.

CC: Alan Stern <stern@rowland.harvard.edu>
CC: Lennert Buytenhek <kernel@wantstofly.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

dbg() was a very old USB-specific macro that should no longer
be used. This patch removes it from being used in the driver
and uses dev_dbg() instead.

CC: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

dbg() was a very old USB-specific macro that should no longer
be used. This patch removes it from being used in the driver
and uses dev_dbg() instead.

CC: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

dbg() was a very old USB-specific macro that should no longer
be used. This patch removes it from being used in the driver
and uses dev_dbg() instead.

CC: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit af4e1ee0 (usb-next)

    "USB: remove err() macro"

was preceeded by a tree-wide cleanup of users, however this
one squeaked through the cracks because it had whitespace
between the function name and the bracket for the args.

Map it onto dev_err, just like all the "pre-commits" made
in advance of af4e1ee0, such as the example seen in
the commit d57b1772:

    "USB: ohci-xls.c: remove err() usage"

Build tested with the ARM magician_defconfig settings.

Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit af4e1ee0 (usb-next)

    "USB: remove err() macro"

was preceeded by a tree-wide cleanup of users, however this
one squeaked through the cracks because it had whitespace
between the function name and the bracket for the args.

Map it onto dev_err, just like all the "pre-commits" made
in advance of af4e1ee0, such as the example seen in
the commit d57b1772:

    "USB: ohci-xls.c: remove err() usage"

Build tested with the MIPS pnx8550-jbs_defconfig settings.

Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit af4e1ee0 (usb-next)

    "USB: remove err() macro"

was preceeded by a tree-wide cleanup of users, however this
one squeaked through the cracks because it had whitespace
between the function name and the bracket for the args.

Map it onto dev_err, just like all the "pre-commits" made
in advance of af4e1ee0, such as the example seen in
the commit d57b1772:

    "USB: ohci-xls.c: remove err() usage"

Build tested with the MIPS gpr_defconfig settings.

Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The immediately preceding gpio_direction_output() already set the value,
so there's no need to repeat it. This also prevents gpio_set_value() from
WARNing when the GPIO is sleepable (e.g. is on an I2C expander); the set
direction API is always sleepable, but plain set_value isn't.

Cc: <stable@vger.kernel.org> # v3.3
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch (as1547) rearranges the Power Management parts of the
ehci-tegra driver to match the conventions used in other EHCI platform
drivers.  In particular, the controller should not be powered down by
the root hub's suspend routine; the controller's power level should be
managed by the controller's own PM methods.

The end result of the patch is that the standard ehci_bus_suspend()
and ehci_bus_resume() methods can be used instead of special-purpose
routines.  The driver now uses the standard dev_pm_ops methods instead
of legacy power management.  Since there is no supported wakeup
mechanism for the controller, runtime suspend is forbidden by default
(this can be overridden via sysfs, if desired).

These adjustments are needed in order to make ehci-tegra compatible
with recent changes to the USB core.  The core now checks the root
hub's status following bus suspend; if the controller is automatically
powered down during bus suspend then the check will fail and the root
hub will be resumed immediately.  Doing the controller power-down in a
separate method avoids this problem.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Acked-by: NStephen Warren <swarren@wwwdotorg.org>
Tested-by: NStephen Warren <swarren@wwwdotorg.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

ohci-nxp duplicates the isp1301 driver. This patch removes this code and makes
ohci-nxp use the new separate isp1301 driver instead.
Signed-off-by: NRoland Stigge <stigge@antcom.de>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch adds device tree support to ohci-nxp.c
Signed-off-by: NRoland Stigge <stigge@antcom.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>