The function that handles xHCI command completion is much too long and
there is need to be broken up into individual functions for each command
completion to improve code readablity.
This patch refactors the code in TRB_CONFIG_EP switch case, in
handle_cmd_completion(), into a fuction named xhci_handle_cmd_config_ep().

There were added two additional variables, 'add_flags' and 'drop_flags',
to reduce line length below 80 chars and improve code readability.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>

This patch removes the variable 'ep_ring' that is assigned in
TRB_CONFIG_EP switch case but never used.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>

The function that handles xHCI command completion is much too long and
there is need to be broken up into individual functions for each command
completion to improve code readablity.
This patch refactors the code in TRB_EVAL_CONTEXT switch case in
handle_cmd_completion() into a fuction named xhci_handle_cmd_eval_ctx().
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>

The function that handles xHCI command completion is much too long and
there is need to be broken up into individual functions for each command
completion to improve code readablity.
This patch refactors the code in TRB_NEC_GET_FW switch case in
handle_cmd_completion() into a fuction named xhci_handle_cmd_nec_get_fw().
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>

The function that handles xHCI command completion is much too long and
there is need to be broken up into individual functions for each command
completion to improve code readablity.
This patch refactors the code in TRB_RESET_DEV switch case in
handle_cmd_completion() into a fuction named xhci_handle_cmd_reset_dev().
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>

Since the slot id retrieved from the Reset Device TRB matches the slot id in
the command completion event, which is available, there is no need to determine
it again.
This patch removes the uneccessary reassignment to slot id and adds a WARN_ON
in case the two Slot ID fields differ (although according xhci spec rev1.0
they should not differ).
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>

The function that handles xHCI command completion is much too long and
there is need to be broken up into individual functions for each command
completion to improve code readablity.
This patch refactors the code in TRB_ADDR_DEV switch case in
handle_cmd_completion() into a fuction named xhci_handle_cmd_addr_dev().
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>

The function that handles xHCI command completion is much too long and
there is need to be broken up into individual functions for each command
completion to improve code readablity.
This patch refactors the code in TRB_DISABLE_SLOT switch case in
handle_cmd_completion() into a fuction named xhci_handle_cmd_disable_slot().
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>

The function that handles xHCI command completion is much too long and
there is need to be broken up into individual functions for each command
completion to improve code readablity.
This patch refactors the code in TRB_ENABLE_SLOT switch case in
handle_cmd_completion() into a fuction named xhci_handle_cmd_enable_slot().
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>

This patch renames the function handlers of a triggered Command Completion
Event that correspond to each command type into 'xhci_handle_cmd_<type>'.
That is done to give a consistent naming space to all the functions that
handle Command Completion Events and that will permit the code reader to
reference to them more easily.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>

This patch removes the "adjective" argument from xhci_giveback_urb_in_irq(),
since it is not used in the function anymore.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>

The usage of USB_CTRL_SET_TIMEOUT in xhci is incorrect.
The definition of USB_CTRL_SET_TIMEOUT is 5000ms. The
input timeout to wait_for_completion_interruptible_timeout
is jiffies. That makes the timeout be longer than what
we want, such as 50s in some platform.

The patch is to use XHCI_CMD_DEFAULT_TIMEOUT instead of
USB_CTRL_SET_TIMEOUT as command completion event timeout.
Signed-off-by: xiao jin <jin.xiao@intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>

'xhci_del_comp_mod_timer' is local to this file.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>

The USB core currently handles enabling and disabling optional USB power
management features during device transitions (device suspend/resume,
driver bind/unbind, device reset, and device disconnect).  Those
optional power features include Latency Tolerance Messaging (LTM),
USB 3.0 Link PM, and USB 2.0 Link PM.

The USB core currently enables LPM on device enumeration and disables
USB 2.0 Link PM when the device is reset.  However, the xHCI driver
disables LPM when the device is disconnected and the device context is
freed.  Push the call up into the USB core, in order to be consistent
with the core handling all power management enabling and disabling.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>

Some usb3 devices falsely claim they support usb2 hardware Link PM
when connected to a usb2 port. We only trust hardwired devices
or devices with the later BESL LPM support to be LPM enabled as default.

[Note: Sarah re-worked the original patch to move the code into the USB
core, and updated it to check whether the USB device supports BESL,
instead of checking if the xHCI port it's connected to supports BESL
encoding.]

This patch should be backported to kernels as old as 3.11, that
contain the commit a558ccdc "usb: xhci:
add USB2 Link power management BESL support".  Without this fix, some
USB 3.0 devices will not enumerate or work properly under USB 2.0 ports
on Haswell-ULT systems.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org

How it's supposed to work:
--------------------------

USB 2.0 Link PM is a lower power state that some newer USB 2.0 devices
support.  USB 3.0 devices certified by the USB-IF are required to
support it if they are plugged into a USB 2.0 only port, or a USB 2.0
cable is used.  USB 2.0 Link PM requires both a USB device and a host
controller that supports USB 2.0 hardware-enabled LPM.

USB 2.0 Link PM is designed to be enabled once by software, and the host
hardware handles transitions to the L1 state automatically.  The premise
of USB 2.0 Link PM is to be able to put the device into a lower power
link state when the bus is idle or the device NAKs USB IN transfers for
a specified amount of time.

...but hardware is broken:
--------------------------

It turns out many USB 3.0 devices claim to support USB 2.0 Link PM (by
setting the LPM bit in their USB 2.0 BOS descriptor), but they don't
actually implement it correctly.  This manifests as the USB device
refusing to respond to transfers when it is plugged into a USB 2.0 only
port under the Haswell-ULT/Lynx Point LP xHCI host.

These devices pass the xHCI driver's simple test to enable USB 2.0 Link
PM, wait for the port to enter L1, and then bring it back into L0.  They
only start to break when L1 entry is interleaved with transfers.

Some devices then fail to respond to the next control transfer (usually
a Set Configuration).  This results in devices never enumerating.

Other mass storage devices (such as a later model Western Digital My
Passport USB 3.0 hard drive) respond fine to going into L1 between
control transfers.  They ACK the entry, come out of L1 when the host
needs to send a control transfer, and respond properly to those control
transfers.  However, when the first READ10 SCSI command is sent, the
device NAKs the data phase while it's reading from the spinning disk.
Eventually, the host requests to put the link into L1, and the device
ACKs that request.  Then it never responds to the data phase of the
READ10 command.  This results in not being able to read from the drive.

Some mass storage devices (like the Corsair Survivor USB 3.0 flash
drive) are well behaved.  They ACK the entry into L1 during control
transfers, and when SCSI commands start coming in, they NAK the requests
to go into L1, because they need to be at full power.

Not all USB 3.0 devices advertise USB 2.0 link PM support.  My Point
Grey USB 3.0 webcam advertises itself as a USB 2.1 device, but doesn't
have a USB 2.0 BOS descriptor, so we don't enable USB 2.0 Link PM.  I
suspect that means the device isn't certified.

What do we do about it?
-----------------------

There's really no good way for the kernel to test these devices.
Therefore, the kernel needs to disable USB 2.0 Link PM by default, and
distros will have to enable it by writing 1 to the sysfs file
/sys/bus/usb/devices/../power/usb2_hardware_lpm.  Rip out the xHCI Link
PM test, since it's not sufficient to detect these buggy devices, and
don't automatically enable LPM after the device is addressed.

This patch should be backported to kernels as old as 3.11, that
contain the commit a558ccdc "usb: xhci:
add USB2 Link power management BESL support".  Without this fix, some
USB 3.0 devices will not enumerate or work properly under USB 2.0 ports
on Haswell-ULT systems.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org

To enable USB 2.0 Link Power Management (LPM), the xHCI host controller
needs the device slot ID to generate the device address used in L1 entry
tokens.  That information is set in the L1 device slot ID field of the
USB 2.0 LPM registers.

Currently, the L1 device slot ID is overwritten when the xHCI driver
initiates the software test of USB 2.0 Link PM in
xhci_usb2_software_lpm_test.  It is never cleared when USB 2.0 Link PM
is disabled for the device.  That should be harmless, because the
Hardware LPM Enable (HLE) bit is cleared when USB 2.0 Link PM is
disabled, so the host should not pay attention to the slot ID.

This patch should have no effect on host behavior, but since
xhci_usb2_software_lpm_test is going away in an upcoming bug fix patch,
we need to move that code to the function that enables and disables USB
2.0 Link PM.

This patch should be backported to kernels as old as 3.11, that contain
the commit a558ccdc "usb: xhci: add USB2
Link power management BESL support".  The upcoming bug fix patch is also
marked for that stable kernel.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org

Before the USB core resets a device, we need to disable the L1 timeout
for the roothub, if USB 2.0 Link PM is enabled.  Otherwise the port may
transition into L1 in between descriptor fetches, before we know if the
USB device descriptors changed.  LPM will be re-enabled after the
full device descriptors are fetched, and we can confirm the device still
supports USB 2.0 LPM after the reset.

We don't need to wait for the USB device to exit L1 before resetting the
device, since the xHCI roothub port diagrams show a transition to the
Reset state from any of the Ux states (see Figure 34 in the 2012-08-14
xHCI specification update).

This patch should be backported to kernels as old as 3.2, that contain
the commit 65580b43 "xHCI: set USB2
hardware LPM".  That was the first commit to enable USB 2.0
hardware-driven Link Power Management.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org

The non-DT for EXYNOS SoCs is not supported from v3.11.
Thus, there is no need to support non-DT for Exynos OHCI driver.

The 'include/linux/platform_data/usb-ohci-exynos.h' file has been
used for non-DT support. Thus, the 'usb-ohci-exynos.h' file can
be removed.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Remove the use of local_irq_save() and IRQF_DISABLED, no longer needed since
interrupt handlers are always run with interrupts disabled on the
current CPU.

Tested successfully with 3.12.0-rc4 on my PC. Didn't find
any issue because of this change.
Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch changes the initial delay before the startup of a newly
scheduled isochronous stream.  Currently the stream doesn't start
for at least 5 ms (40 microframes).  This value is just an estimate;
it has no real justification.

Instead, we can start the stream as soon as possible after the
scheduling computations are complete.  Essentially this requires
nothing more than reading the frame counter after the stream is
scheduled, instead of before.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch continues the scheduling changes in ehci-hcd by adding a
table to store the bandwidth allocation below each TT.  This will
speed up the scheduling code, as it will no longer need to read
through the entire schedule to compute the bandwidth currently in use.

Properly speaking, the FS/LS budget calculations should be done in
terms of full-speed bytes per microframe, as described in the USB-2
spec.  However the driver currently uses microseconds per microframe,
and the scheduling code isn't robust enough at this point to change
over.  For the time being, we leave the calculations as they are.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 476e4bf9.

Manjunath is no longer at Linaro, the email address bounces.  Given
that, and the fact that others have reported problems with these
patches, I'm reverting them until someone from Linaro who can SUPPORT
THEM submits them.

I will no longer accept patches from linaro.com developers unless a
senior Linaro developer has signed off on them, which did not happen
with this patch set.
Reported-by: Olof Johansson <olof@lixom.net>
Cc: Manjunath Goudar <manjunath.goudar@linaro.org>
Cc: Manjunath Goudar <csmanjuvijay@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Arnd Bergmann <arnd@arndb.de>

This reverts commit 056ca85d.

Manjunath is no longer at Linaro, the email address bounces.  Given
that, and the fact that others have reported problems with these
patches, I'm reverting them until someone from Linaro who can SUPPORT
THEM submits them.

I will no longer accept patches from linaro.com developers unless a
senior Linaro developer has signed off on them, which did not happen
with this patch set.
Reported-by: Olof Johansson <olof@lixom.net>
Cc: Manjunath Goudar <manjunath.goudar@linaro.org>
Cc: Manjunath Goudar <csmanjuvijay@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Arnd Bergmann <arnd@arndb.de>

This reverts commit 19d33943.

Manjunath is no longer at Linaro, the email address bounces.  Given
that, and the fact that others have reported problems with these
patches, I'm reverting them until someone from Linaro who can SUPPORT
THEM submits them.

I will no longer accept patches from linaro.com developers unless a
senior Linaro developer has signed off on them, which did not happen
with this patch set.
Reported-by: Olof Johansson <olof@lixom.net>
Cc: Manjunath Goudar <manjunath.goudar@linaro.org>
Cc: Manjunath Goudar <csmanjuvijay@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Arnd Bergmann <arnd@arndb.de>

This reverts commit 86a63f10.

Manjunath is no longer at Linaro, the email address bounces.  Given
that, and the fact that others have reported problems with these
patches, I'm reverting them until someone from Linaro who can SUPPORT
THEM submits them.

I will no longer accept patches from linaro.com developers unless a
senior Linaro developer has signed off on them, which did not happen
with this patch set.
Reported-by: Olof Johansson <olof@lixom.net>
Cc: Manjunath Goudar <manjunath.goudar@linaro.org>
Cc: Manjunath Goudar <csmanjuvijay@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Arnd Bergmann <arnd@arndb.de>

This reverts commit 018258b4.

Manjunath is no longer at Linaro, the email address bounces.  Given
that, and the fact that others have reported problems with these
patches, I'm reverting them until someone from Linaro who can SUPPORT
THEM submits them.

I will no longer accept patches from linaro.com developers unless a
senior Linaro developer has signed off on them, which did not happen
with this patch set.
Reported-by: Olof Johansson <olof@lixom.net>
Cc: Manjunath Goudar <manjunath.goudar@linaro.org>
Cc: Manjunath Goudar <csmanjuvijay@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Arnd Bergmann <arnd@arndb.de>

This reverts commit fea0896f.

Manjunath is no longer at Linaro, the email address bounces.  Given
that, and the fact that others have reported problems with these
patches, I'm reverting them until someone from Linaro who can SUPPORT
THEM submits them.

I will no longer accept patches from linaro.com developers unless a
senior Linaro developer has signed off on them, which did not happen
with this patch set.
Reported-by: Olof Johansson <olof@lixom.net>
Cc: Manjunath Goudar <manjunath.goudar@linaro.org>
Cc: Manjunath Goudar <csmanjuvijay@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Arnd Bergmann <arnd@arndb.de>

This reverts commit 36a87587.

Manjunath is no longer at Linaro, the email address bounces.  Given
that, and the fact that others have reported problems with these
patches, I'm reverting them until someone from Linaro who can SUPPORT
THEM submits them.

I will no longer accept patches from linaro.com developers unless a
senior Linaro developer has signed off on them, which did not happen
with this patch set.
Reported-by: Olof Johansson <olof@lixom.net>
Cc: Manjunath Goudar <manjunath.goudar@linaro.org>
Cc: Manjunath Goudar <csmanjuvijay@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Arnd Bergmann <arnd@arndb.de>

Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

including:

- removing of trailing whitespace
- removing spaces before array indexing (foo [] to foo[])
- reindention of a switch-case block
- spaces to tabs
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Make sure to return errors from tiocmget rather than rely on
uninitialised stack data.

Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Export usb_serial_generic_write_start which is needed when implementing
a custom resume function while still relying on the generic write
implementation.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Add memory-flags parameter to usb_serial_generic_write_start which is
called from write, resume and completion handler, all with different
allocation requirements.

Note that by using the memory flag to determine when called from the
completion handler, everything will work as before even if the
completion handler is run with interrupts enabled (as suggested).
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Clean up some comments, drop excessive comments and fix-up style.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The DECLARE_BITMAP macro should be used for declaring this bitmap.
This commit converts the busmap from a struct to a simple (static)
bitmap, using the DECLARE_BITMAP macro from linux/types.h.

Please review, as I'm new to kernel development, I don't know if this
has any hidden side effects!

Suggested by joe@perches.com
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Currently, Samsung is using 'EXYNOS' as the name of Samsung SoCs.
Thus, ehci-exynos is preferred than ehci-s5p.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The non-DT for EXYNOS SoCs is not supported from v3.11.
Thus, there is no need to support non-DT for Exynos EHCI driver.

The 'include/linux/platform_data/usb-ehci-s5p.h' file has been
used for non-DT support. Thus, the 'usb-ehci-s5p.h' file can
be removed.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Since commit ca914350 "ARM: EXYNOS: Remove unused board files",
s5p_device_ehci is not used anymore. Thus, s5p_device_ehci can
be removed. Also, unnecessary S5P_DEV_USB_EHCI option is removed.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>