This reverts commit ca9c9d0c.

Rafael wants more time to work on the user api to handle port power
issues, so let's just revert the sysfs changes for now.
Reported-by: NRafael J. Wysocki <rjw@sisk.pl>
Cc: Lan Tianyu <tianyu.lan@intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit ff823c79 ("usb: move children
to struct usb_port") forgot to consider the hub_disconnect sequence,
which releases ports before quiescing the hub, which will lead to a
use-after-free, since hub_quiesce() will try to disconnect ports'
children, which are already deallocated. Simple modprobe dummy_hcd &&
rmmod dummy_hcd will illustrate the problem.

This patch moves deallocation of hub's ports after hub_quiesce() call
in hub_disconnect().

Cc: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NAlexander Shishkin <alexander.shishkin@linux.intel.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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

This patch adds two sysfs files for each usb hub port to allow userspace
to control the port power policy.

For an upcoming Intel xHCI roothub, this will translate into ACPI calls
to completely power off or power on the port.  As a reminder, when these
ports are completely powered off, the USB host and device will see a
physical disconnect.  All future USB device connections will be lost,
and the device will not be able to signal a remote wakeup.

The control sysfs file can be written to with two options:
"on" - port power must be on.
"off" - port must be off.

The state sysfs file reports usb port's power state:
"on" - powered on
"off" - powered off
"error" - can't get power state

For now, let userspace dictate the port power off policy.  Future
patches may add an in-kernel policy.
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In the upcoming USB port power off patches, we need to know whether a
USB port can ever see a disconnect event.  Often USB ports are internal
to a system, and users can't disconnect USB devices from that port.
Sometimes those ports will remain empty, because the OEM chose not to
connect an internal USB device to that port.

According to ACPI Spec 9.13, PLD indicates whether USB port is
user visible and _UPC indicates whether a USB device can be connected to
the USB port (we'll call this "connectible").  Here's a matrix of the
possible combinations:

Visible Connectible
		Name		Example
-------------------------------------------------------------------------

Yes	No	Unknown		(Invalid state.)

Yes	Yes	Hot-plug	USB ports on the outside of a laptop.
				A user could freely connect and disconnect
				USB devices.

No	Yes	Hard-wired	A USB modem hard-wired to a port on the
				inside of a laptop.

No	No	Not used	The port is internal to the system and
				will remain empty.

Represent each of these four states with an enum usb_port_connect_type.
The four states are USB_PORT_CONNECT_TYPE_UNKNOWN,
USB_PORT_CONNECT_TYPE_HOT_PLUG, USB_PORT_CONNECT_TYPE_HARD_WIRED, and
USB_PORT_NOT_USED.  When we get the USB port's acpi_handle, store the
state in connect_type in struct usb_port.
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In the ACPI DSDT table, only usb root hub and usb ports are ACPI device
nodes.  Originally, we bound the usb port's ACPI node to the usb device
attached to the port.  However, we want to access those ACPI port
methods when the port is empty, and there's no usb_device associated
with that port.

Now that the usb port is a real device, we can bind the port's ACPI node
to struct usb_port instead.
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The usb_device structure contains an array of usb_device "children".
This array is only valid if the usb_device is a hub, so it makes no
sense to store it there.  Instead, store the usb_device child
in its parent usb_port structure.

Since usb_port is an internal USB core structure, add a new function to
get the USB device child, usb_hub_find_child().  Add a new macro,
usb_hub_get_each_child(), to iterate over all the children attached to a
particular USB hub.

Remove the printing the USB children array pointer from the usb-ip
driver, since it's really not necessary.
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch turns each USB port on a hub into a new struct device.  This
new device has the USB hub interface device as its parent.  The port
devices are stored in a new structure (usb_port), and an array of
usb_ports are dynamically allocated once we know how many ports the USB
hub has.

Move the port_owner variable out of usb_hub and into this new structure.

A new file will be created in the hub interface sysfs directory, so
add documentation.
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When a whole class of devices (possibly from a specific vendor, or
across multiple vendors) require a quirk, explictly listing all devices
in the class make the quirks table unnecessarily large. Fix this by
allowing matching devices based on interface information.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Phy may need to change settings when port connect change.
Signed-off-by: NRichard Zhao <richard.zhao@freescale.com>
Tested-by: NSubodh Nijsure <snijsure@grid-net.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Send the USB device's serial, product, and manufacturer strings to the
/dev/random driver to help seed its pools.

Cc: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: NGreg KH <greg@kroah.com>
Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
Cc: stable@vger.kernel.org

USB 3.0 devices can optionally support Latency Tolerance Messaging
(LTM).  Add a new sysfs file in the device directory to show whether a
device is LTM capable.  This file will be present for both USB 2.0 and
USB 3.0 devices.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

USB 3.0 devices may optionally support a new feature called Latency
Tolerance Messaging.  If both the xHCI host controller and the device
support LTM, it should be turned on in order to give the system hardware
a better clue about the latency tolerance values of its PCI devices.

Once a Set Feature request to enable LTM is received, the USB 3.0 device
will begin to send LTM updates as its buffers fill or empty, and it can
tolerate more or less latency.

The USB 3.0 spec, section C.4.2 says that LTM should be disabled just
before the device is placed into suspend.  Then the device will send an
updated LTM notification, so that the system doesn't think it should
remain in an active state in order to satisfy the latency requirements
of the suspended device.

The Set and Clear Feature LTM enable command can only be sent to a
configured device.  The device will respond with an error if that
command is sent while it is in the Default or Addressed state.  Make
sure to check udev->actconfig in usb_enable_ltm() and usb_disable_ltm(),
and don't send those commands when the device is unconfigured.

LTM should be enabled once a new configuration is installed in
usb_set_configuration().  If we end up sending duplicate Set Feature LTM
Enable commands on a switch from one installed configuration to another
configuration, that should be harmless.

Make sure that LTM is disabled before the device is unconfigured in
usb_disable_device().  If no drivers are bound to the device, it doesn't
make sense to allow the device to control the latency tolerance of the
xHCI host controller.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

The USB 3.0 specification says that sending a Set Feature or Clear
Feature for U1/U2 Enable is not a valid request when the device is in
the Default or Addressed state.  It is only valid when the device is in
the Configured state.

The original LPM patch attempted to disable LPM after the device had
been reset by hub_port_init(), before it had the configuration
reinstalled.  The TI hub I tested with did not fail the Clear Feature
U1/U2 Enable request that khubd sent while it was in the addressed
state, which is why I didn't catch it.

Move the LPM disable before the device reset, so that we can send the
Clear Feature U1/U2 Enable successfully, and balance the LPM disable
count.

Also delete any calls to usb_enable_lpm() on error paths that lead to
re-enumeration.  The calls will fail because the device isn't
configured, and it's not useful to balance the LPM disable count because
the usb_device is about to be destroyed before re-enumeration.

Fix the early exit path ("done" label) to call usb_enable_lpm() to
balance the LPM disable count.

Note that calling usb_reset_and_verify_device() with an unconfigured
device may fail on the first call to usb_disable_lpm().  That's because
the LPM disable count is initialized to 0 (LPM enabled), and
usb_disable_lpm() will attempt to send a Clear Feature U1/U2 request to
a device in the Addressed state.  The next patch will fix that.

This commit should be backported to kernels as old as 3.5, that contain
the commit 8306095f "USB: Disable USB
3.0 LPM in critical sections."
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org

This patch is to convert port_owners type from void * to struct dev_state *
in order to make code more readable.
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The host controller port status register supports CAS (Cold Attach
Status) bit. This bit could be set when USB3.0 device is connected
when system is in Sx state. When the system wakes to S0 this port
status with CAS bit is reported and this port can't be used by any
device.

When CAS bit is set the port should be reset by warm reset. This
was not supported by xhci driver.

The issue was found when pendrive was connected to suspended
platform. The link state of "Compliance Mode" was reported together
with CAS bit. This link state was also not supported by xhci and
core/hub.c.

The CAS bit is defined only for xhci root hub port and it is
not supported on regular hubs. The link status is used to force
warm reset on port. Make the USB core issue a warm reset when port
is in ether the 'inactive' or 'compliance mode'. Change the xHCI driver
to report 'compliance mode' when the CAS is set. This force warm reset
on the root hub port.

This patch should be backported to stable kernels as old as 3.2, that
contain the commit 10d674a8 "USB: When
hot reset for USB3 fails, try warm reset."
Signed-off-by: NStanislaw Ledwon <staszek.ledwon@linux.intel.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: NAndiry Xu <andiry.xu@amd.com>
Cc: stable@vger.kernel.org

We check "u1_params" instead of checking "u2_params".
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

When CONFIG_PM=n, make sure that the usb_[unlocked_][en/dis]able_lpm
declarations are visible in include/linux/usb.h, and exported from
drivers/usb/core/hub.c.

Before this patch, if CONFIG_USB_SUSPEND was turned off, it would cause
build errors:

drivers/usb/core/hub.c: In function 'usb_disable_lpm':
drivers/usb/core/hub.c:3394:2: error: implicit declaration of function 'usb_enable_lpm' [-Werror=implicit-function-declaration]
drivers/usb/core/hub.c: At top level:
drivers/usb/core/hub.c:3424:6: warning: conflicting types for 'usb_enable_lpm' [enabled by default]
drivers/usb/core/hub.c:3394:2: note: previous implicit declaration of 'usb_enable_lpm' was here
drivers/usb/core/driver.c: In function 'usb_probe_interface':
drivers/usb/core/driver.c:339:2: error: implicit declaration of function 'usb_unlocked_disable_lpm' [-Werror=implicit-function-declaration]
drivers/usb/core/driver.c:364:3: error: implicit declaration of function 'usb_unlocked_enable_lpm' [-Werror=implicit-function-declaration]
drivers/usb/core/message.c: In function 'usb_set_interface':
drivers/usb/core/message.c:1314:2: error: implicit declaration of function 'usb_disable_lpm' [-Werror=implicit-function-declaration]
drivers/usb/core/message.c:1323:3: error: implicit declaration of function 'usb_enable_lpm' [-Werror=implicit-function-declaration]
drivers/usb/core/message.c:1368:2: error: implicit declaration of function 'usb_unlocked_enable_lpm' [-Werror=implicit-function-declaration]
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Reported-by: NChen Peter-B29397 <B29397@freescale.com>

There are several places where the USB core needs to disable USB 3.0
Link PM:
 - usb_bind_interface
 - usb_unbind_interface
 - usb_driver_claim_interface
 - usb_port_suspend/usb_port_resume
 - usb_reset_and_verify_device
 - usb_set_interface
 - usb_reset_configuration
 - usb_set_configuration

Use the new LPM disable/enable functions to temporarily disable LPM
around these critical sections.

We need to protect the critical section around binding and unbinding USB
interface drivers.  USB drivers may want to disable hub-initiated USB
3.0 LPM, which will change the value of the U1/U2 timeouts that the xHCI
driver will install.  We need to disable LPM completely until the driver
is bound to the interface, and the driver has a chance to enable
whatever alternate interface setting it needs in its probe routine.
Then re-enable USB3 LPM, and recalculate the U1/U2 timeout values.

We also need to disable LPM in usb_driver_claim_interface,
because drivers like usbfs can bind to an interface through that
function.  Note, there is no way currently for userspace drivers to
disable hub-initiated USB 3.0 LPM.  Revisit this later.

When a driver is unbound, the U1/U2 timeouts may change because we are
unbinding the last driver that needed hub-initiated USB 3.0 LPM to be
disabled.

USB LPM must be disabled when a USB device is going to be suspended.
The USB 3.0 spec does not define a state transition from U1 or U2 into
U3, so we need to bring the device into U0 by disabling LPM before we
can place it into U3.  Therefore, call usb_unlocked_disable_lpm() in
usb_port_suspend(), and call usb_unlocked_enable_lpm() in
usb_port_resume().  If the port suspend fails, make sure to re-enable
LPM by calling usb_unlocked_enable_lpm(), since usb_port_resume() will
not be called on a failed port suspend.

USB 3.0 devices lose their USB 3.0 LPM settings (including whether USB
device-initiated LPM is enabled) across device suspend.  Therefore,
disable LPM before the device will be reset in
usb_reset_and_verify_device(), and re-enable LPM after the reset is
complete and the configuration/alt settings are re-installed.

The calculated U1/U2 timeout values are heavily dependent on what USB
device endpoints are currently enabled.  When any of the enabled
endpoints on the device might change, due to a new configuration, or new
alternate interface setting, we need to first disable USB 3.0 LPM, add
or delete endpoints from the xHCI schedule, install the new interfaces
and alt settings, and then re-enable LPM.  Do this in usb_set_interface,
usb_reset_configuration, and usb_set_configuration.

Basically, there is a call to disable and then enable LPM in all
functions that lock the bandwidth_mutex.  One exception is
usb_disable_device, because the device is disconnecting or otherwise
going away, and we should not care about whether USB 3.0 LPM is enabled.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

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>

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

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>

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>

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

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 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>

Refactor the code to check for a remote wakeup on a port into its own
function.  Keep the behavior the same, and set connect_change in
hub_events if the device disconnected on resume.  Cleanup references to
hdev->children[i-1] to use a common variable.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

USB 3.0 hubs have a different remote wakeup policy than USB 2.0 hubs.
USB 2.0 hubs, once they have remote wakeup enabled, will always send
remote wakes when anything changes on a port.

However, USB 3.0 hubs have a per-port remote wake up policy that is off
by default.  The Set Feature remote wake mask can be changed for any
port, enabling remote wakeup for a connect, disconnect, or overcurrent
event, much like EHCI and xHCI host controller "wake on" port status
bits.  The bits are cleared to zero on the initial hub power on, or
after the hub has been reset.

Without this patch, when a USB 3.0 hub gets suspended, it will not send
a remote wakeup on device connect or disconnect.  This would show up to
the user as "dead ports" unless they ran lsusb -v (since newer versions
of lsusb use the sysfs files, rather than sending control transfers).

Change the hub driver's suspend method to enable remote wake up for
disconnect, connect, and overcurrent for all ports on the hub.  Modify
the xHCI driver's roothub code to handle that request, and set the "wake
on" bits in the port status registers accordingly.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

The USB 3.0 bus specification introduces a new type of power management
called function suspend.  The idea is to be able to suspend different
functions (i.e. a scanner or an SD card reader on a USB printer)
independently.  A device can be in U0, but have one or more functions
suspended.  Thus, signaling a function resume with the standard device
remote wake signaling was not possible.

Instead, a device will (without prompt from the host) send a "device
notification" for the function remote wake.  A new Set Feature Function
Remote Wake was developed to turn remote wake up on and off for each
function.

USB 3.0 devices can still go into device suspend (U3), and signal a
remote wakeup to bring the link back into U1.  However, they now use the
function remote wake device notification to allow the host to know which
function woke the device from U3.

The spec is a bit ambiguous about whether a function is allowed to
signal a remote wakeup if the function has been enabled for remote
wakeup, but not placed in function suspend before the device is placed
into U3.

Section 9.2.5.1 says "Suspending a device with more than one function
effectively suspends all the functions within the device."  I interpret
that to mean that putting a device in U3 suspends all functions, and
thus if the host has previously enabled remote wake for those functions,
it should be able to signal a remote wake up on port status changes.
However, hub vendors may have a different interpretation, and it can't
hurt to put the function into suspend before putting the device into U3.

I cannot get an answer out of the USB 3.0 spec architects about this
ambiguity, so I'm erring on the safe side and always suspending the
first function before placing the device in U3.  Note, this code should
be fixed if we ever find any USB 3.0 devices that have more than one
function.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

When the USB 3.0 hub support went in, I disabled selective suspend for
all external USB 3.0 hubs because they used a different mechanism to
enable remote wakeup.  In fact, other USB 3.0 devices that could signal
remote wakeup would have been prevented from going into suspend because
they would have stalled the SetFeature Device Remote Wakeup request.

This patch adds support for the USB 3.0 way of enabling remote wake up
(with a SetFeature Function Suspend request), and enables selective
suspend for all hubs during hub_probe.  It assumes that all USB 3.0 have
only one "function" as defined by the interface association descriptor,
which is true of all the USB 3.0 devices I've seen so far.  FIXME if
that turns out to change later.

After a device signals a remote wakeup, it is supposed to send a Device
Notification packet to the host controller, signaling which function
sent the remote wakeup.  The host can then put any other functions back
into function suspend.  Since we don't have support for function suspend
(and no devices currently support it), we'll just assume the hub
function will resume the device properly when it received the port
status change notification, and simply ignore any device notification
events from the xHCI host controller.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

Hubs have a flag to indicate whether a given port carries removable devices
or not. This is not strictly accurate in that some built-in devices
will be flagged as removable, but followup patches will make use of platform
data to make this more reliable.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

module_param(bool) used to counter-intuitively take an int.  In
fddd5201 (mid-2009) we allowed bool or int/unsigned int using a messy
trick.

It's time to remove the int/unsigned int option.  For this version
it'll simply give a warning, but it'll break next kernel version.
Acked-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>