There are various functions within the USB core that will need to
disable USB 3.0 link power states.  For example, when a USB device
driver is being bound to an interface, we need to disable USB 3.0 LPM
until we know if the driver will allow hub-initiated LPM transitions.
Another example is when the USB core is switching alternate interface
settings.  The USB 3.0 timeout values are dependent on what endpoints
are enabled, so we want to ensure that LPM is disabled until the new alt
setting is fully installed.

Multiple functions need to disable LPM, and those functions can even be
nested.  For example, usb_bind_interface() could disable LPM, and then
call into the driver probe function, which may attempt to switch to a
different alt setting.  Therefore, we need to keep a count of the number
of functions that require LPM to be disabled at any point in time.

Introduce two new USB core API calls, usb_disable_lpm() and
usb_enable_lpm().  These functions increment and decrement a new
variable in the usb_device, lpm_disable_count.  If usb_disable_lpm()
fails, it will call usb_enable_lpm() in order to balance the
lpm_disable_count.

These two new functions must be called with the bandwidth_mutex locked.
If the bandwidth_mutex is not already held by the caller, it should
instead call usb_unlocked_disable_lpm() and usb_enable_lpm(), which take
the bandwidth_mutex before calling usb_disable_lpm() and
usb_enable_lpm(), respectively.

Introduce a new variable (timeout) in the usb3_lpm_params structure to
keep track of the currently enabled U1/U2 timeout values.  When
usb_disable_lpm() is called, and the USB device has the U1 or U2
timeouts set to a non-zero value (meaning either device-initiated or
hub-initiated LPM is enabled), attempt to disable LPM, regardless of the
state of the lpm_disable_count.  We want to ensure that all callers can
be guaranteed that LPM is disabled if usb_disable_lpm() returns zero.

Otherwise the following scenario could occur:

1. Driver A is being bound to interface 1.  usb_probe_interface()
disables LPM.  Driver A doesn't care if hub-initiated LPM is enabled, so
even though usb_disable_lpm() fails, the probe of the driver continues,
and the bandwidth mutex is dropped.

2. Meanwhile, Driver B is being bound to interface 2.
usb_probe_interface() grabs the bandwidth mutex and calls
usb_disable_lpm().  That call should attempt to disable LPM, even
though the lpm_disable_count is set to 1 by Driver A.

For usb_enable_lpm(), we attempt to enable LPM only when the
lpm_disable_count is zero.  If some step in enabling LPM fails, it will
only have a minimal impact on power consumption, and all USB device
drivers should still work properly.  Therefore don't bother to return
any error codes.

Don't enable device-initiated LPM if the device is unconfigured.  The
USB device will only accept the U1/U2_ENABLE control transfers in the
configured state.  Do enable hub-initiated LPM in that case, since
devices are allowed to accept the LGO_Ux link commands in any state.

Don't enable or disable LPM if the device is marked as not being LPM
capable.  This can happen if:
 - the USB device doesn't have a SS BOS descriptor,
 - the device's parent hub has a zeroed bHeaderDecodeLatency value, or
 - the xHCI host doesn't support LPM.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

There are several different exit latencies associated with coming out of
the U1 or U2 lower power link state.

Device Exit Latency (DEL) is the maximum time it takes for the USB
device to bring its upstream link into U0.  That can be found in the
SuperSpeed Extended Capabilities BOS descriptor for the device.  The
time it takes for a particular link in the tree to exit to U0 is the
maximum of either the parent hub's U1/U2 DEL, or the child's U1/U2 DEL.

Hubs introduce a further delay that effects how long it takes a child
device to transition to U0.  When a USB 3.0 hub receives a header
packet, it takes some time to decode that header and figure out which
downstream port the packet was destined for.  If the port is not in U0,
this hub header decode latency will cause an additional delay for
bringing the child device to U0.  This Hub Header Decode Latency is
found in the USB 3.0 hub descriptor.

We can use DEL and the header decode latency, along with additional
latencies imposed by each additional hub tier, to figure out the exit
latencies for both host-initiated and device-initiated exit to U0.

The Max Exit Latency (MEL) is the worst-case time it will take for a
host-initiated exit to U0, based on whether U1 or U2 link states are
enabled.  The ping or packet must traverse the path to the device, and
each hub along the way incurs the hub header decode latency in order to
figure out which device the transfer was bound for.  We say worst-case,
because some hubs may not be in the lowest link state that is enabled.
See the examples in section C.2.2.1.

Note that "HSD" is a "host specific delay" that the power appendix
architect has not been able to tell me how to calculate.  There's no way
to get HSD from the xHCI registers either, so I'm simply ignoring it.

The Path Exit Latency (PEL) is the worst-case time it will take for a
device-initiate exit to U0 to place all the links from the device to the
host into U0.

The System Exit Latency (SEL) is another device-initiated exit latency.
SEL is useful for USB 3.0 devices that need to send data to the host at
specific intervals.  The device may send an NRDY to indicate it isn't
ready to send data, then put its link into a lower power state.  If it
needs to have that data transmitted at a specific time, it can use SEL
to back calculate when it will need to bring the link back into U0 to
meet its deadlines.

SEL is the worst-case time from the device-initiated exit to U0, to when
the device will receive a packet from the host controller.  It includes
PEL, the time it takes for an ERDY to get to the host, a host-specific
delay for the host to process that ERDY, and the time it takes for the
packet to traverse the path to the device.  See Figure C-2 in the USB
3.0 bus specification.

Note: I have not been able to get good answers about what the
host-specific delay to process the ERDY should be.  The Intel HW
developers say it will be specific to the platform the xHCI host is
integrated into, and they say it's negligible.  Ignore this too.

Separate from these four exit latencies are the U1/U2 timeout values we
program into the parent hubs.  These timeouts tell the hub to attempt to
place the device into a lower power link state after the link has been
idle for that amount of time.

Create two arrays (one for U1 and one for U2) to store mel, pel, sel,
and the timeout values.  Store the exit latency values in nanosecond
units, since that's the smallest units used (DEL is in us, but the Hub
Header Decode Latency is in ns).

If a USB 3.0 device doesn't have a SuperSpeed Extended Capabilities BOS
descriptor, it's highly unlikely it will be able to handle LPM requests
properly.  So it's best to disable LPM for devices that don't have this
descriptor, and any children beneath it, if it's a USB 3.0 hub.  Warn
users when that happens, since it means they have a non-compliant USB
3.0 device or hub.

This patch assumes a simplified design where links deep in the tree will
not have U1 or U2 enabled unless all their parent links have the
corresponding LPM state enabled.  Eventually, we might want to allow a
different policy, and we can revisit this patch when that happens.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>

Refactor the code that sets the usb_device flag to indicate the device
support link power management (lpm_capable).  The current code sets
lpm_capable unconditionally if the USB devices have a USB 2.0 Extended
Capabilities Descriptor.  USB 3.0 devices can also have that descriptor,
but the xHCI driver code that uses lpm_capable will not run the USB 2.0
LPM test for devices under the USB 3.0 roothub.  Therefore, it's fine
only set lpm_capable for high speed devices in this refactoring.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

The BOS descriptor is normally fetched and stored in the usb_device->bos
during enumeration.  USB 3.0 roothubs don't undergo enumeration, but we
need them to have a BOS descriptor, since each xHCI host has a different
U1 and U2 exit latency.  Make sure to fetch the BOS descriptor for USB
3.0 roothubs.  It will be freed when the roothub usb_device is released.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>

USB2 LPM is disabled when device begin to suspend and enabled after device
is resumed. That's because USB spec does not define the transition from
U1/U2 state to U3 state.

If usb_port_suspend() fails, usb_port_resume() is never called, and USB2 LPM
is disabled in this situation. Enable USB2 LPM if port suspend fails.

This patch should be backported to kernels as old as 3.2, that contain
the commit 65580b43 "xHCI: set USB2
hardware LPM".
Signed-off-by: NAndiry Xu <andiry.xu@gmail.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org

Commit da0af6e7 ("usb: Bind devices to ACPI devices when possible") really
tries to force-bind devices even when impossible, unlike what it says in
the subject.

CONFIG_ACPI is not an indication that ACPI tables are actually present, nor
is an indication that any USB relevant information is present in them. There
is no reason to fail the creation of a USB bus if it can't bind it to
ACPI device during initialization.

On systems with CONFIG_ACPI set but without ACPI tables it would cause a
boot panic.
Signed-off-by: NSasha Levin <levinsasha928@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Keep the usb-serial support for dynamic IDs in sync with the usb
support.  This enables readout of dynamic device IDs for
usb-serial drivers.  Common code is exported from the usb core
system and reused by the usb-serial bus driver.
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This enables the current list of dynamic IDs to be read out through
either new_id or remove_id.
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit f397d7c4.

This series isn't quite ready for 3.5 just yet, so revert it and give
the author more time to get it correct.

Cc: Lan Tianyu <tianyu.lan@intel.com>
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>

If no default value is specified, then 'n' is used so the default value
used here is not needed. Furthermore, we should never change default
values depending on EXPERT mode. EXPERT mode should only make options
visible, not change them.

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.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>

Add struct usb_hub_port pointer port_data in the struct usb_hub and allocate
struct usb_hub_port perspectively for each ports to store private data.
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

ACPI offers two methods that allow us to infer whether or not a USB port
is removable. The _PLD method gives us information on whether the port is
"user visible" or not. If that's not present then we can fall back to the
_UPC method which tells us whether or not a port is connectable.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Built-in USB devices will typically have a representation in the system
ACPI tables. Add support for binding the two together so the USB code can
make use of the associated methods.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

It took me surprisingly long to find the location where the Linux
Foundation vendor id (0x1d6b) is set for the root hubs. A minor update
to three comments makes those locations (trivially) greppable.
Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
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: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

On some HCDs usb_unlink_urb() can directly call the
completion handler. That limits the spinlocks that can
be taken in the handler to locks not held while calling
usb_unlink_urb()
To prevent a race with resubmission, this patch exposes
usbcore's infrastructure for blocking submission, uses it
and so drops the lock without causing a race in usbhid.
Signed-off-by: NOliver Neukum <oneukum@suse.de>
Acked-by: NJiri Kosina <jkosina@suse.cz>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Tested-by: NSteffen Müller <steffen.mueller@radio-frei.de>
Signed-off-by: NSteffen Müller <steffen.mueller@radio-frei.de>
Signed-off-by: NStefan Seyfried <seife+kernel@b1-systems.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This option has been deprecated for many years now, and no userspace
tools use it anymore, so it should be safe to finally remove it.
Reported-by: NKay Sievers <kay@vrfy.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This option has been deprecated for many years now, and no userspace
tools use it anymore, so it should be safe to finally remove it.
Reported-by: NKay Sievers <kay@vrfy.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch (as1545) fixes a problem affecting several ASUS computers:
The machine crashes or corrupts memory when going into suspend if the
ehci-hcd driver is bound to any controllers.  Users have been forced
to unbind or unload ehci-hcd before putting their systems to sleep.

After extensive testing, it was determined that the machines don't
like going into suspend when any EHCI controllers are in the PCI D3
power state.  Presumably this is a firmware bug, but there's nothing
we can do about it except to avoid putting the controllers in D3
during system sleep.

The patch adds a new flag to indicate whether the problem is present,
and avoids changing the controller's power state if the flag is set.
Runtime suspend is unaffected; this matters only for system suspend.
However as a side effect, the controller will not respond to remote
wakeup requests while the system is asleep.  Hence USB wakeup is not
functional -- but of course, this is already true in the current state
of affairs.

This fixes Bugzilla #42728.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: NSteven Rostedt <rostedt@goodmis.org>
Tested-by: NAndrey Rahmatullin <wrar@wrar.name>
Tested-by: NOleksij Rempel (fishor) <bug-track@fisher-privat.net>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch (as154) fixes a self-deadlock that occurs when userspace
writes to the bConfigurationValue sysfs attribute for a hub with
children.  The task tries to lock the bandwidth_mutex at a time when
it already owns the lock:

	The attribute's method calls usb_set_configuration(),
	which calls usb_disable_device() with the bandwidth_mutex
	held.

	usb_disable_device() unregisters the existing interfaces,
	which causes the hub driver to be unbound.

	The hub_disconnect() routine calls hub_quiesce(), which
	calls usb_disconnect() for each of the hub's children.

	usb_disconnect() attempts to acquire the bandwidth_mutex
	around a call to usb_disable_device().

The solution is to make usb_disable_device() acquire the mutex for
itself instead of requiring the caller to hold it.  Then the mutex can
cover only the bandwidth deallocation operation and not the region
where the interfaces are unregistered.

This has the potential to change system behavior slightly when a
config change races with another config or altsetting change.  Some of
the bandwidth released from the old config might get claimed by the
other config or altsetting, make it impossible to restore the old
config in case of a failure.  But since we don't try to recover from
config-change failures anyway, this doesn't matter.

[This should be marked for stable kernels that contain the commit
fccf4e86 "USB: Free bandwidth when
usb_disable_device is called."
That commit was marked for stable kernels as old as 2.6.32.]
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When the Seagate Goflex USB3.0 device is attached to VIA xHCI
host, sometimes the device will downgrade mode to high speed.
By the USB analyzer, I found the device finished the link
training process and worked at superspeed mode. But the device
descriptor got from the device shows the device works at 2.1.
It is very strange and seems like the device controller of
Seagate Goflex has a little confusion.

The first 8 bytes of device descriptor should be:
12 01 00 03 00 00 00 09

But the first 8 bytes of wrong device descriptor are:
12 01 10 02 00 00 00 40

The wrong device descriptor caused the initialization of mass
storage failed. After a while, the device would be recognized
as a high speed device and works fine.

This patch will warm reset the device to fix the issue after
finding the bcdUSB field of device descriptor isn't 0x0300
but the speed mode of device is superspeed.

This patch should be backported to kernels as old as 3.2, or ones that
contain the commit 75d7cf72 "usbcore:
refine warm reset logic".
Signed-off-by: NElric Fu <elricfu1@gmail.com>
Acked-by: NAndiry Xu <Andiry.Xu@amd.com>
Acked-by: NSergei Shtylyov <sshtylyov@mvista.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org

This patch (as1533) fixes a race between root-hub suspend and remote
wakeup.  If a wakeup event occurs while a root hub is suspending, it
might not cause the suspend to fail.  Although the host controller
drivers check for pending wakeup events at the start of their
bus_suspend routines, they generally do not check for wakeup events
while the routines are running.

In addition, if a wakeup event occurs any time after khubd is frozen
and before the root hub is fully suspended, it might not cause a
system sleep transition to fail.  For example, the host controller
drivers do not fail root-hub suspends when a connect-change event is
pending.

To fix both these issues, this patch causes hcd_bus_suspend() to query
the controller driver's hub_status_data method after a root hub is
suspended, if the root hub is enabled for wakeup.  Any pending status
changes will count as wakeup events, causing the root hub to be
resumed and the overall suspend to fail with -EBUSY.

A significant point is that not all events are reflected immediately
in the status bits.  Both EHCI and UHCI controllers notify the CPU
when remote wakeup begins on a port, but the port's suspend-change
status bit doesn't get set until after the port has completed the
transition out of the suspend state, some 25 milliseconds later.
Consequently, the patch will interpret any nonzero return value from
hub_status_data as indicating a pending event, even if none of the
status bits are set in the data buffer.  Follow-up patches make the
necessary changes to ehci-hcd and uhci-hcd.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
CC: Chen Peter-B29397 <B29397@freescale.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch (as1532) fixes a mistake in the USB suspend code.  When the
system is going to sleep, we should ignore errors in powering down USB
devices, because they don't really matter.  The devices will go to low
power anyway when the entire USB bus gets suspended (except for
SuperSpeed devices; maybe they will need special treatment later).

However we should not ignore errors in suspending root hubs,
especially if the error indicates that the suspend raced with a wakeup
request.  Doing so might leave the bus powered on while the system was
supposed to be asleep, or it might cause the suspend of the root hub's
parent controller device to fail, or it might cause a wakeup request
to be ignored.

The patch fixes the problem by ignoring errors only when the device in
question is not a root hub.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NChen Peter <B29397@freescale.com>
CC: <stable@vger.kernel.org>
Tested-by: NChen Peter <peter.chen@freescale.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch (as1534c) updates the documentation for usb_unlink_urb and
related functions.  It explains that the caller must prevent the URB
being unlinked from getting deallocated while the unlink is taking
place.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch (as1517b) fixes an error in the USB scatter-gather library.
The library code uses urb->dev to determine whether or nor an URB is
currently active; the completion handler sets urb->dev to NULL.
However the core unlinking routines need to use urb->dev.  Since
unlinking always racing with completion, the completion handler must
not clear urb->dev -- it can lead to invalid memory accesses when a
transfer has to be cancelled.

This patch fixes the problem by getting rid of the lines that clear
urb->dev after urb has been submitted.  As a result we may end up
trying to unlink an URB that failed in submission or that has already
completed, so an extra check is added after each unlink to avoid
printing an error message when this happens.  The checks are updated
in both sg_complete() and sg_cancel(), and the second is updated to
match the first (currently it prints out unnecessary warning messages
if a device is unplugged while a transfer is in progress).
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: NIllia Zaitsev <I.Zaitsev@adbglobal.com>
CC: Ming Lei <tom.leiming@gmail.com>
CC: <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Many users of debugfs copy the implementation of default_open() when
they want to support a custom read/write function op.  This leads to a
proliferation of the default_open() implementation across the entire
tree.

Now that the common implementation has been consolidated into libfs we
can replace all the users of this function with simple_open().

This replacement was done with the following semantic patch:

<smpl>
@ open @
identifier open_f != simple_open;
identifier i, f;
@@
-int open_f(struct inode *i, struct file *f)
-{
(
-if (i->i_private)
-f->private_data = i->i_private;
|
-f->private_data = i->i_private;
)
-return 0;
-}

@ has_open depends on open @
identifier fops;
identifier open.open_f;
@@
struct file_operations fops = {
...
-.open = open_f,
+.open = simple_open,
...
};
</smpl>

[akpm@linux-foundation.org: checkpatch fixes]
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Julia Lawall <Julia.Lawall@lip6.fr>
Acked-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

can check MS_KERNMOUNT in flags now
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Non-hub device has no child, and even a real USB hub has ports far
less than USB_MAXCHILDREN, so there is no need using a fix array for
child devices, just allocate it dynamically according real port
number.
Signed-off-by: NHuajun Li <huajun.li.lee@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The kernel doc entry for usb_unlink_urb() contains the phrase "This
request is always asynchronous.". The "always" leads to the assumption
that the ->complete() callback is not called from within
usb_unlink_urb(). This is not true. The HCD is allowed to call the
->complete() from within ->urb_dequeue() if it is appropriate for the
hardware.
This patch updates the kernel doc so usb-device driver authors make sure
to drop all locks (and make sure it is okay to drop them) which are
acquired by the complete callback before calling usb_unlink_urb().
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There's really no point in having hcd->irq as a
signed integer when we consider the fact that
IRQ 0 means NO_IRQ. In order to avoid confusion,
make hcd->irq unsigned and fix users who were
passing -1 as the IRQ number to usb_add_hcd.
Tested-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Shows up on ia64 builds (and possibly elsewhere) for configs that
don't set PM_RUNTIME or PM_SLEEP as follows:

drivers/usb/core/hcd-pci.c:383:12: warning: 'suspend_common' defined but not used
drivers/usb/core/hcd-pci.c:438:12: warning: 'resume_common' defined but not used

As per above, the functions are only used if RUNTIME/SLEEP are set,
so make the two functions conditional on these Kconfig values.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The superspeed device attached to a USB 3.0 hub(such as VIA's)
doesn't respond the address device command after resume. The
root cause is the superspeed hub will miss the Hub Depth value
that is used as an offset into the route string to locate the
bits it uses to determine the downstream port number after
reset, and all packets can't be routed to the device attached
to the superspeed hub.

Hub driver sends a Set Hub Depth request to the superspeed hub
except for USB 3.0 root hub when the hub is initialized and
doesn't send the request again after reset due to the resume
process. So moving the code that sends the Set Hub Depth request
to the superspeed hub from hub_configure() to hub_activate()
is to cover those situations include initialization and reset.

The patch should be backported to kernels as old as 2.6.39.
Signed-off-by: NElric Fu <elricfu1@gmail.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: stable@vger.kernel.org

Now that USB 3.0 hub remote wakeup on port status changes is enabled,
and USB 3.0 device remote wakeup is handled in the USB core properly,
let's turn on auto-suspend for all USB 3.0 hubs.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

This patch takes care of the race condition between the Function Wake
Device Notification and the auto-suspend timeout for this situation:

Roothub
  | (U3)
hub A
  | (U3)
hub B
  | (U3)
device C

When device C signals a resume, the xHCI driver will set the wakeup_bits
for the roothub port that hub A is attached to.  However, since USB 3.0
hubs do not set a link state change bit on device-initiated resume, hub
A will not indicate a port event when polled.  Without this patch, khubd
will notice the wakeup-bits are set for the roothub port, it will resume
hub A, and then it will poll the events bits for hub A and notice that
nothing has changed.  Then it will be suspended after 2 seconds.

Change hub_activate() to look at the port link state for each USB 3.0
hub port, and set hub->change_bits if the link state is U0, indicating
the device has finished resume.  Change the resume function called by
hub_events(), hub_handle_remote_wakeup(), to check the link status
for resume instead of just the port's wakeup_bits.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

USB 3.0 hubs don't have a port suspend change bit (that bit is now
reserved).  Instead, when a host-initiated resume finishes, the hub sets
the port link state change bit.

When a USB 3.0 device initiates remote wakeup, the parent hubs with
their upstream links in U3 will pass the LFPS up the chain.  The first
hub that has an upstream link in U0 (which may be the roothub) will
reflect that LFPS back down the path to the device.

However, the parent hubs in the resumed path will not set their link
state change bit.  Instead, the device that initiated the resume has to
send an asynchronous "Function Wake" Device Notification up to the host
controller.  Therefore, we need a way to notify the USB core of a device
resume without going through the normal hub URB completion method.

First, make the xHCI roothub act like an external USB 3.0 hub and not
pass up the port link state change bit when a device-initiated resume
finishes.  Introduce a new xHCI bit field, port_remote_wakeup, so that
we can tell the difference between a port coming out of the U3Exit state
(host-initiated resume) and the RExit state (ending state of
device-initiated resume).

Since the USB core can't tell whether a port on a hub has resumed by
looking at the Hub Status buffer, we need to introduce a bitfield,
wakeup_bits, that indicates which ports have resumed.  When the xHCI
driver notices a port finishing a device-initiated resume, we call into
a new USB core function, usb_wakeup_notification(), that will set
the right bit in wakeup_bits, and kick khubd for that hub.

We also call usb_wakeup_notification() when the Function Wake Device
Notification is received by the xHCI driver.  This covers the case where
the link between the roothub and the first-tier hub is in U0, and the
hub reflects the resume signaling back to the device without giving any
indication it has done so until the device sends the Function Wake
notification.

Change the code in khubd that handles the remote wakeup to look at the
state the USB core thinks the device is in, and handle the remote wakeup
if the port's wakeup bit is set.

This patch only takes care of the case where the device is attached
directly to the roothub, or the USB 3.0 hub that is attached to the root
hub is the device sending the Function Wake Device Notification (e.g.
because a new USB device was attached).  The other cases will be covered
in a second patch.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>