2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
* USB hub driver.
|
|
|
|
*
|
|
|
|
* (C) Copyright 1999 Linus Torvalds
|
|
|
|
* (C) Copyright 1999 Johannes Erdfelt
|
|
|
|
* (C) Copyright 1999 Gregory P. Smith
|
|
|
|
* (C) Copyright 2001 Brad Hards (bhards@bigpond.net.au)
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/errno.h>
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/moduleparam.h>
|
|
|
|
#include <linux/completion.h>
|
|
|
|
#include <linux/sched.h>
|
|
|
|
#include <linux/list.h>
|
|
|
|
#include <linux/slab.h>
|
|
|
|
#include <linux/ioctl.h>
|
|
|
|
#include <linux/usb.h>
|
|
|
|
#include <linux/usbdevice_fs.h>
|
2010-04-25 05:21:52 +08:00
|
|
|
#include <linux/usb/hcd.h>
|
2012-07-11 11:09:28 +08:00
|
|
|
#include <linux/usb/otg.h>
|
2010-07-22 06:05:01 +08:00
|
|
|
#include <linux/usb/quirks.h>
|
2014-09-19 23:32:21 +08:00
|
|
|
#include <linux/workqueue.h>
|
2006-01-11 22:55:29 +08:00
|
|
|
#include <linux/mutex.h>
|
2012-07-04 23:22:20 +08:00
|
|
|
#include <linux/random.h>
|
2013-01-23 04:26:30 +08:00
|
|
|
#include <linux/pm_qos.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
#include <asm/uaccess.h>
|
|
|
|
#include <asm/byteorder.h>
|
|
|
|
|
2013-01-11 20:10:38 +08:00
|
|
|
#include "hub.h"
|
2014-08-19 09:51:53 +08:00
|
|
|
#include "otg_whitelist.h"
|
2005-04-17 06:20:36 +08:00
|
|
|
|
USB: check port changes before hub runtime suspend for some bug device
The hub status endpoint has a long 'bInterval', which is 255ms
for FS/LS device and 256ms for HS device according to USB 2.0 spec,
so the device connection change may be reported later more than 255ms
via status pipe.
The connection change in hub may have been happened already on the
downstream ports, but no status URB completes when it is killed
in hub_suspend(auto), so the connection change may be missed by some
buggy hub devices, which won't generate remote wakeup signal after
their remote wakeup is enabled and they are put into suspend state.
The problem can be observed at least on the below Genesys Logic, Inc.
hub devices:
0x05e3,0x0606
0x05e3,0x0608
In theory, there is no way to fix the problem completely, but we
can make it less likely to occur by this patch.
This patch introduces one quirk of HUB_QUIRK_CHECK_PORTS_AUTOSUSPEND
to check ports' change during hub_suspend(auto) for the buggy
devices. If ports' change is found, terminate the auto suspend and
return to working state.
So for the buggy hubs, if the connection change happend before
the ports' check, it can be handled correctly. If it happens between
the ports' check and enabling remote wakeup/entering suspend, it
will be missed. Considered the interval is quite short, it is very
less likely to happen during the window.
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-24 11:59:24 +08:00
|
|
|
#define USB_VENDOR_GENESYS_LOGIC 0x05e3
|
|
|
|
#define HUB_QUIRK_CHECK_PORT_AUTOSUSPEND 0x01
|
|
|
|
|
2012-05-15 00:20:37 +08:00
|
|
|
/* Protect struct usb_device->state and ->children members
|
2005-11-18 06:10:32 +08:00
|
|
|
* Note: Both are also protected by ->dev.sem, except that ->state can
|
2005-04-17 06:20:36 +08:00
|
|
|
* change to USB_STATE_NOTATTACHED even when the semaphore isn't held. */
|
|
|
|
static DEFINE_SPINLOCK(device_state_lock);
|
|
|
|
|
2014-09-19 23:32:21 +08:00
|
|
|
/* workqueue to process hub events */
|
|
|
|
static struct workqueue_struct *hub_wq;
|
|
|
|
static void hub_event(struct work_struct *work);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2014-05-21 09:08:28 +08:00
|
|
|
/* synchronize hub-port add/remove and peering operations */
|
|
|
|
DEFINE_MUTEX(usb_port_peer_mutex);
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/* cycle leds on hubs that aren't blinking for attention */
|
2015-10-26 11:55:36 +08:00
|
|
|
static bool blinkenlights;
|
2015-08-08 16:03:34 +08:00
|
|
|
module_param(blinkenlights, bool, S_IRUGO);
|
|
|
|
MODULE_PARM_DESC(blinkenlights, "true to cycle leds on hubs");
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2008-10-10 22:24:45 +08:00
|
|
|
/*
|
|
|
|
* Device SATA8000 FW1.0 from DATAST0R Technology Corp requires about
|
|
|
|
* 10 seconds to send reply for the initial 64-byte descriptor request.
|
|
|
|
*/
|
|
|
|
/* define initial 64-byte descriptor request timeout in milliseconds */
|
|
|
|
static int initial_descriptor_timeout = USB_CTRL_GET_TIMEOUT;
|
|
|
|
module_param(initial_descriptor_timeout, int, S_IRUGO|S_IWUSR);
|
2008-12-15 15:32:01 +08:00
|
|
|
MODULE_PARM_DESC(initial_descriptor_timeout,
|
|
|
|
"initial 64-byte descriptor request timeout in milliseconds "
|
|
|
|
"(default 5000 - 5.0 seconds)");
|
2008-10-10 22:24:45 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
* As of 2.6.10 we introduce a new USB device initialization scheme which
|
|
|
|
* closely resembles the way Windows works. Hopefully it will be compatible
|
|
|
|
* with a wider range of devices than the old scheme. However some previously
|
|
|
|
* working devices may start giving rise to "device not accepting address"
|
|
|
|
* errors; if that happens the user can try the old scheme by adjusting the
|
|
|
|
* following module parameters.
|
|
|
|
*
|
|
|
|
* For maximum flexibility there are two boolean parameters to control the
|
|
|
|
* hub driver's behavior. On the first initialization attempt, if the
|
|
|
|
* "old_scheme_first" parameter is set then the old scheme will be used,
|
|
|
|
* otherwise the new scheme is used. If that fails and "use_both_schemes"
|
|
|
|
* is set, then the driver will make another attempt, using the other scheme.
|
|
|
|
*/
|
2015-10-26 11:55:36 +08:00
|
|
|
static bool old_scheme_first;
|
2005-04-17 06:20:36 +08:00
|
|
|
module_param(old_scheme_first, bool, S_IRUGO | S_IWUSR);
|
|
|
|
MODULE_PARM_DESC(old_scheme_first,
|
|
|
|
"start with the old device initialization scheme");
|
|
|
|
|
2012-01-13 07:02:20 +08:00
|
|
|
static bool use_both_schemes = 1;
|
2005-04-17 06:20:36 +08:00
|
|
|
module_param(use_both_schemes, bool, S_IRUGO | S_IWUSR);
|
|
|
|
MODULE_PARM_DESC(use_both_schemes,
|
|
|
|
"try the other device initialization scheme if the "
|
|
|
|
"first one fails");
|
|
|
|
|
2007-10-11 04:27:07 +08:00
|
|
|
/* Mutual exclusion for EHCI CF initialization. This interferes with
|
|
|
|
* port reset on some companion controllers.
|
|
|
|
*/
|
|
|
|
DECLARE_RWSEM(ehci_cf_port_reset_rwsem);
|
|
|
|
EXPORT_SYMBOL_GPL(ehci_cf_port_reset_rwsem);
|
|
|
|
|
2013-01-23 04:26:30 +08:00
|
|
|
#define HUB_DEBOUNCE_TIMEOUT 2000
|
2008-04-28 23:07:07 +08:00
|
|
|
#define HUB_DEBOUNCE_STEP 25
|
|
|
|
#define HUB_DEBOUNCE_STABLE 100
|
|
|
|
|
2014-09-19 23:32:21 +08:00
|
|
|
static void hub_release(struct kref *kref);
|
2008-06-18 22:00:29 +08:00
|
|
|
static int usb_reset_and_verify_device(struct usb_device *udev);
|
|
|
|
|
2010-12-07 13:00:19 +08:00
|
|
|
static inline char *portspeed(struct usb_hub *hub, int portstatus)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2016-04-20 22:28:09 +08:00
|
|
|
if (hub_is_superspeedplus(hub->hdev))
|
|
|
|
return "10.0 Gb/s";
|
2010-12-07 13:00:19 +08:00
|
|
|
if (hub_is_superspeed(hub->hdev))
|
|
|
|
return "5.0 Gb/s";
|
2010-03-05 00:32:30 +08:00
|
|
|
if (portstatus & USB_PORT_STAT_HIGH_SPEED)
|
2013-10-11 05:41:27 +08:00
|
|
|
return "480 Mb/s";
|
2010-03-05 00:32:30 +08:00
|
|
|
else if (portstatus & USB_PORT_STAT_LOW_SPEED)
|
2005-04-17 06:20:36 +08:00
|
|
|
return "1.5 Mb/s";
|
|
|
|
else
|
|
|
|
return "12 Mb/s";
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Note that hdev or one of its children must be locked! */
|
2013-01-23 04:26:30 +08:00
|
|
|
struct usb_hub *usb_hub_to_struct_hub(struct usb_device *hdev)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2012-09-05 13:44:32 +08:00
|
|
|
if (!hdev || !hdev->actconfig || !hdev->maxchild)
|
2009-07-23 02:41:18 +08:00
|
|
|
return NULL;
|
2005-04-17 06:20:36 +08:00
|
|
|
return usb_get_intfdata(hdev->actconfig->interface[0]);
|
|
|
|
}
|
|
|
|
|
2015-06-16 09:08:26 +08:00
|
|
|
int usb_device_supports_lpm(struct usb_device *udev)
|
2012-02-21 00:31:26 +08:00
|
|
|
{
|
2015-12-11 04:27:21 +08:00
|
|
|
/* Some devices have trouble with LPM */
|
|
|
|
if (udev->quirks & USB_QUIRK_NO_LPM)
|
|
|
|
return 0;
|
|
|
|
|
2012-02-21 00:31:26 +08:00
|
|
|
/* USB 2.1 (and greater) devices indicate LPM support through
|
|
|
|
* their USB 2.0 Extended Capabilities BOS descriptor.
|
|
|
|
*/
|
2015-04-14 19:06:55 +08:00
|
|
|
if (udev->speed == USB_SPEED_HIGH || udev->speed == USB_SPEED_FULL) {
|
2012-02-21 00:31:26 +08:00
|
|
|
if (udev->bos->ext_cap &&
|
|
|
|
(USB_LPM_SUPPORT &
|
|
|
|
le32_to_cpu(udev->bos->ext_cap->bmAttributes)))
|
|
|
|
return 1;
|
|
|
|
return 0;
|
|
|
|
}
|
USB: Calculate USB 3.0 exit latencies for LPM.
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
2012-02-21 04:02:19 +08:00
|
|
|
|
usb/xhci: Change how we indicate a host supports Link PM.
The xHCI driver currently uses a USB core internal field,
udev->lpm_capable, to indicate the xHCI driver knows how to calculate
the LPM timeout values. If this value is set for the host controller
udev, it means Link PM can be enabled for child devices under that host.
Change the code so the xHCI driver isn't mucking with USB core internal
fields. Instead, indicate the xHCI driver doesn't support Link PM on
this host by clearing the U1 and U2 exit latencies in the roothub
SuperSpeed Extended Capabilities BOS descriptor.
The code to check for the roothub setting U1 and U2 exit latencies to
zero will also disable LPM for external devices that do that same. This
was already effectively done with commit
ae8963adb4ad8c5f2a89ca1d99fb7bb721e7599f "usb: Don't enable LPM if the
exit latency is zero." Leave that code in place, so that if a device
sets one exit latency value to zero, but the other is set to a valid
value, LPM is only enabled for the U1 or U2 state that had the valid
value. This is the same behavior the code had before.
Also, change messages about missing Link PM information from warning
level to info level. Only print a warning about the first device that
doesn't support LPM, to avoid log spam. Further, cleanup some
unnecessary line breaks to help people to grep for the error messages.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
2014-01-18 06:15:44 +08:00
|
|
|
/*
|
|
|
|
* According to the USB 3.0 spec, all USB 3.0 devices must support LPM.
|
|
|
|
* However, there are some that don't, and they set the U1/U2 exit
|
|
|
|
* latencies to zero.
|
USB: Calculate USB 3.0 exit latencies for LPM.
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
2012-02-21 04:02:19 +08:00
|
|
|
*/
|
|
|
|
if (!udev->bos->ss_cap) {
|
usb/xhci: Change how we indicate a host supports Link PM.
The xHCI driver currently uses a USB core internal field,
udev->lpm_capable, to indicate the xHCI driver knows how to calculate
the LPM timeout values. If this value is set for the host controller
udev, it means Link PM can be enabled for child devices under that host.
Change the code so the xHCI driver isn't mucking with USB core internal
fields. Instead, indicate the xHCI driver doesn't support Link PM on
this host by clearing the U1 and U2 exit latencies in the roothub
SuperSpeed Extended Capabilities BOS descriptor.
The code to check for the roothub setting U1 and U2 exit latencies to
zero will also disable LPM for external devices that do that same. This
was already effectively done with commit
ae8963adb4ad8c5f2a89ca1d99fb7bb721e7599f "usb: Don't enable LPM if the
exit latency is zero." Leave that code in place, so that if a device
sets one exit latency value to zero, but the other is set to a valid
value, LPM is only enabled for the U1 or U2 state that had the valid
value. This is the same behavior the code had before.
Also, change messages about missing Link PM information from warning
level to info level. Only print a warning about the first device that
doesn't support LPM, to avoid log spam. Further, cleanup some
unnecessary line breaks to help people to grep for the error messages.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
2014-01-18 06:15:44 +08:00
|
|
|
dev_info(&udev->dev, "No LPM exit latency info found, disabling LPM.\n");
|
USB: Calculate USB 3.0 exit latencies for LPM.
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
2012-02-21 04:02:19 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
usb/xhci: Change how we indicate a host supports Link PM.
The xHCI driver currently uses a USB core internal field,
udev->lpm_capable, to indicate the xHCI driver knows how to calculate
the LPM timeout values. If this value is set for the host controller
udev, it means Link PM can be enabled for child devices under that host.
Change the code so the xHCI driver isn't mucking with USB core internal
fields. Instead, indicate the xHCI driver doesn't support Link PM on
this host by clearing the U1 and U2 exit latencies in the roothub
SuperSpeed Extended Capabilities BOS descriptor.
The code to check for the roothub setting U1 and U2 exit latencies to
zero will also disable LPM for external devices that do that same. This
was already effectively done with commit
ae8963adb4ad8c5f2a89ca1d99fb7bb721e7599f "usb: Don't enable LPM if the
exit latency is zero." Leave that code in place, so that if a device
sets one exit latency value to zero, but the other is set to a valid
value, LPM is only enabled for the U1 or U2 state that had the valid
value. This is the same behavior the code had before.
Also, change messages about missing Link PM information from warning
level to info level. Only print a warning about the first device that
doesn't support LPM, to avoid log spam. Further, cleanup some
unnecessary line breaks to help people to grep for the error messages.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
2014-01-18 06:15:44 +08:00
|
|
|
if (udev->bos->ss_cap->bU1devExitLat == 0 &&
|
|
|
|
udev->bos->ss_cap->bU2DevExitLat == 0) {
|
|
|
|
if (udev->parent)
|
|
|
|
dev_info(&udev->dev, "LPM exit latency is zeroed, disabling LPM.\n");
|
|
|
|
else
|
|
|
|
dev_info(&udev->dev, "We don't know the algorithms for LPM for this host, disabling LPM.\n");
|
USB: Calculate USB 3.0 exit latencies for LPM.
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
2012-02-21 04:02:19 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
usb/xhci: Change how we indicate a host supports Link PM.
The xHCI driver currently uses a USB core internal field,
udev->lpm_capable, to indicate the xHCI driver knows how to calculate
the LPM timeout values. If this value is set for the host controller
udev, it means Link PM can be enabled for child devices under that host.
Change the code so the xHCI driver isn't mucking with USB core internal
fields. Instead, indicate the xHCI driver doesn't support Link PM on
this host by clearing the U1 and U2 exit latencies in the roothub
SuperSpeed Extended Capabilities BOS descriptor.
The code to check for the roothub setting U1 and U2 exit latencies to
zero will also disable LPM for external devices that do that same. This
was already effectively done with commit
ae8963adb4ad8c5f2a89ca1d99fb7bb721e7599f "usb: Don't enable LPM if the
exit latency is zero." Leave that code in place, so that if a device
sets one exit latency value to zero, but the other is set to a valid
value, LPM is only enabled for the U1 or U2 state that had the valid
value. This is the same behavior the code had before.
Also, change messages about missing Link PM information from warning
level to info level. Only print a warning about the first device that
doesn't support LPM, to avoid log spam. Further, cleanup some
unnecessary line breaks to help people to grep for the error messages.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
2014-01-18 06:15:44 +08:00
|
|
|
if (!udev->parent || udev->parent->lpm_capable)
|
|
|
|
return 1;
|
2012-02-21 00:31:26 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
USB: Calculate USB 3.0 exit latencies for LPM.
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
2012-02-21 04:02:19 +08:00
|
|
|
/*
|
|
|
|
* Set the Maximum Exit Latency (MEL) for the host to initiate a transition from
|
|
|
|
* either U1 or U2.
|
|
|
|
*/
|
|
|
|
static void usb_set_lpm_mel(struct usb_device *udev,
|
|
|
|
struct usb3_lpm_parameters *udev_lpm_params,
|
|
|
|
unsigned int udev_exit_latency,
|
|
|
|
struct usb_hub *hub,
|
|
|
|
struct usb3_lpm_parameters *hub_lpm_params,
|
|
|
|
unsigned int hub_exit_latency)
|
|
|
|
{
|
|
|
|
unsigned int total_mel;
|
|
|
|
unsigned int device_mel;
|
|
|
|
unsigned int hub_mel;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Calculate the time it takes to transition all links from the roothub
|
|
|
|
* to the parent hub into U0. The parent hub must then decode the
|
|
|
|
* packet (hub header decode latency) to figure out which port it was
|
|
|
|
* bound for.
|
|
|
|
*
|
|
|
|
* The Hub Header decode latency is expressed in 0.1us intervals (0x1
|
|
|
|
* means 0.1us). Multiply that by 100 to get nanoseconds.
|
|
|
|
*/
|
|
|
|
total_mel = hub_lpm_params->mel +
|
|
|
|
(hub->descriptor->u.ss.bHubHdrDecLat * 100);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* How long will it take to transition the downstream hub's port into
|
|
|
|
* U0? The greater of either the hub exit latency or the device exit
|
|
|
|
* latency.
|
|
|
|
*
|
|
|
|
* The BOS U1/U2 exit latencies are expressed in 1us intervals.
|
|
|
|
* Multiply that by 1000 to get nanoseconds.
|
|
|
|
*/
|
|
|
|
device_mel = udev_exit_latency * 1000;
|
|
|
|
hub_mel = hub_exit_latency * 1000;
|
|
|
|
if (device_mel > hub_mel)
|
|
|
|
total_mel += device_mel;
|
|
|
|
else
|
|
|
|
total_mel += hub_mel;
|
|
|
|
|
|
|
|
udev_lpm_params->mel = total_mel;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Set the maximum Device to Host Exit Latency (PEL) for the device to initiate
|
|
|
|
* a transition from either U1 or U2.
|
|
|
|
*/
|
|
|
|
static void usb_set_lpm_pel(struct usb_device *udev,
|
|
|
|
struct usb3_lpm_parameters *udev_lpm_params,
|
|
|
|
unsigned int udev_exit_latency,
|
|
|
|
struct usb_hub *hub,
|
|
|
|
struct usb3_lpm_parameters *hub_lpm_params,
|
|
|
|
unsigned int hub_exit_latency,
|
|
|
|
unsigned int port_to_port_exit_latency)
|
|
|
|
{
|
|
|
|
unsigned int first_link_pel;
|
|
|
|
unsigned int hub_pel;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* First, the device sends an LFPS to transition the link between the
|
|
|
|
* device and the parent hub into U0. The exit latency is the bigger of
|
|
|
|
* the device exit latency or the hub exit latency.
|
|
|
|
*/
|
|
|
|
if (udev_exit_latency > hub_exit_latency)
|
|
|
|
first_link_pel = udev_exit_latency * 1000;
|
|
|
|
else
|
|
|
|
first_link_pel = hub_exit_latency * 1000;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* When the hub starts to receive the LFPS, there is a slight delay for
|
|
|
|
* it to figure out that one of the ports is sending an LFPS. Then it
|
|
|
|
* will forward the LFPS to its upstream link. The exit latency is the
|
|
|
|
* delay, plus the PEL that we calculated for this hub.
|
|
|
|
*/
|
|
|
|
hub_pel = port_to_port_exit_latency * 1000 + hub_lpm_params->pel;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* According to figure C-7 in the USB 3.0 spec, the PEL for this device
|
|
|
|
* is the greater of the two exit latencies.
|
|
|
|
*/
|
|
|
|
if (first_link_pel > hub_pel)
|
|
|
|
udev_lpm_params->pel = first_link_pel;
|
|
|
|
else
|
|
|
|
udev_lpm_params->pel = hub_pel;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Set the System Exit Latency (SEL) to indicate the total worst-case time from
|
|
|
|
* when a device initiates a transition to U0, until when it will receive the
|
|
|
|
* first packet from the host controller.
|
|
|
|
*
|
|
|
|
* Section C.1.5.1 describes the four components to this:
|
|
|
|
* - t1: device PEL
|
|
|
|
* - t2: time for the ERDY to make it from the device to the host.
|
|
|
|
* - t3: a host-specific delay to process the ERDY.
|
|
|
|
* - t4: time for the packet to make it from the host to the device.
|
|
|
|
*
|
|
|
|
* t3 is specific to both the xHCI host and the platform the host is integrated
|
|
|
|
* into. The Intel HW folks have said it's negligible, FIXME if a different
|
|
|
|
* vendor says otherwise.
|
|
|
|
*/
|
|
|
|
static void usb_set_lpm_sel(struct usb_device *udev,
|
|
|
|
struct usb3_lpm_parameters *udev_lpm_params)
|
|
|
|
{
|
|
|
|
struct usb_device *parent;
|
|
|
|
unsigned int num_hubs;
|
|
|
|
unsigned int total_sel;
|
|
|
|
|
|
|
|
/* t1 = device PEL */
|
|
|
|
total_sel = udev_lpm_params->pel;
|
|
|
|
/* How many external hubs are in between the device & the root port. */
|
|
|
|
for (parent = udev->parent, num_hubs = 0; parent->parent;
|
|
|
|
parent = parent->parent)
|
|
|
|
num_hubs++;
|
|
|
|
/* t2 = 2.1us + 250ns * (num_hubs - 1) */
|
|
|
|
if (num_hubs > 0)
|
|
|
|
total_sel += 2100 + 250 * (num_hubs - 1);
|
|
|
|
|
|
|
|
/* t4 = 250ns * num_hubs */
|
|
|
|
total_sel += 250 * num_hubs;
|
|
|
|
|
|
|
|
udev_lpm_params->sel = total_sel;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void usb_set_lpm_parameters(struct usb_device *udev)
|
|
|
|
{
|
|
|
|
struct usb_hub *hub;
|
|
|
|
unsigned int port_to_port_delay;
|
|
|
|
unsigned int udev_u1_del;
|
|
|
|
unsigned int udev_u2_del;
|
|
|
|
unsigned int hub_u1_del;
|
|
|
|
unsigned int hub_u2_del;
|
|
|
|
|
2015-12-10 15:59:25 +08:00
|
|
|
if (!udev->lpm_capable || udev->speed < USB_SPEED_SUPER)
|
USB: Calculate USB 3.0 exit latencies for LPM.
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
2012-02-21 04:02:19 +08:00
|
|
|
return;
|
|
|
|
|
2013-01-23 04:26:30 +08:00
|
|
|
hub = usb_hub_to_struct_hub(udev->parent);
|
USB: Calculate USB 3.0 exit latencies for LPM.
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
2012-02-21 04:02:19 +08:00
|
|
|
/* It doesn't take time to transition the roothub into U0, since it
|
|
|
|
* doesn't have an upstream link.
|
|
|
|
*/
|
|
|
|
if (!hub)
|
|
|
|
return;
|
|
|
|
|
|
|
|
udev_u1_del = udev->bos->ss_cap->bU1devExitLat;
|
2013-08-31 23:09:13 +08:00
|
|
|
udev_u2_del = le16_to_cpu(udev->bos->ss_cap->bU2DevExitLat);
|
USB: Calculate USB 3.0 exit latencies for LPM.
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
2012-02-21 04:02:19 +08:00
|
|
|
hub_u1_del = udev->parent->bos->ss_cap->bU1devExitLat;
|
2013-08-31 23:09:13 +08:00
|
|
|
hub_u2_del = le16_to_cpu(udev->parent->bos->ss_cap->bU2DevExitLat);
|
USB: Calculate USB 3.0 exit latencies for LPM.
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
2012-02-21 04:02:19 +08:00
|
|
|
|
|
|
|
usb_set_lpm_mel(udev, &udev->u1_params, udev_u1_del,
|
|
|
|
hub, &udev->parent->u1_params, hub_u1_del);
|
|
|
|
|
|
|
|
usb_set_lpm_mel(udev, &udev->u2_params, udev_u2_del,
|
|
|
|
hub, &udev->parent->u2_params, hub_u2_del);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Appendix C, section C.2.2.2, says that there is a slight delay from
|
|
|
|
* when the parent hub notices the downstream port is trying to
|
|
|
|
* transition to U0 to when the hub initiates a U0 transition on its
|
|
|
|
* upstream port. The section says the delays are tPort2PortU1EL and
|
|
|
|
* tPort2PortU2EL, but it doesn't define what they are.
|
|
|
|
*
|
|
|
|
* The hub chapter, sections 10.4.2.4 and 10.4.2.5 seem to be talking
|
|
|
|
* about the same delays. Use the maximum delay calculations from those
|
|
|
|
* sections. For U1, it's tHubPort2PortExitLat, which is 1us max. For
|
|
|
|
* U2, it's tHubPort2PortExitLat + U2DevExitLat - U1DevExitLat. I
|
|
|
|
* assume the device exit latencies they are talking about are the hub
|
|
|
|
* exit latencies.
|
|
|
|
*
|
|
|
|
* What do we do if the U2 exit latency is less than the U1 exit
|
|
|
|
* latency? It's possible, although not likely...
|
|
|
|
*/
|
|
|
|
port_to_port_delay = 1;
|
|
|
|
|
|
|
|
usb_set_lpm_pel(udev, &udev->u1_params, udev_u1_del,
|
|
|
|
hub, &udev->parent->u1_params, hub_u1_del,
|
|
|
|
port_to_port_delay);
|
|
|
|
|
|
|
|
if (hub_u2_del > hub_u1_del)
|
|
|
|
port_to_port_delay = 1 + hub_u2_del - hub_u1_del;
|
|
|
|
else
|
|
|
|
port_to_port_delay = 1 + hub_u1_del;
|
|
|
|
|
|
|
|
usb_set_lpm_pel(udev, &udev->u2_params, udev_u2_del,
|
|
|
|
hub, &udev->parent->u2_params, hub_u2_del,
|
|
|
|
port_to_port_delay);
|
|
|
|
|
|
|
|
/* Now that we've got PEL, calculate SEL. */
|
|
|
|
usb_set_lpm_sel(udev, &udev->u1_params);
|
|
|
|
usb_set_lpm_sel(udev, &udev->u2_params);
|
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/* USB 2.0 spec Section 11.24.4.5 */
|
2001-09-17 15:00:00 +08:00
|
|
|
static int get_hub_descriptor(struct usb_device *hdev, void *data)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2001-09-17 15:00:00 +08:00
|
|
|
int i, ret, size;
|
|
|
|
unsigned dtype;
|
|
|
|
|
|
|
|
if (hub_is_superspeed(hdev)) {
|
|
|
|
dtype = USB_DT_SS_HUB;
|
|
|
|
size = USB_DT_SS_HUB_SIZE;
|
|
|
|
} else {
|
|
|
|
dtype = USB_DT_HUB;
|
|
|
|
size = sizeof(struct usb_hub_descriptor);
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
for (i = 0; i < 3; i++) {
|
|
|
|
ret = usb_control_msg(hdev, usb_rcvctrlpipe(hdev, 0),
|
|
|
|
USB_REQ_GET_DESCRIPTOR, USB_DIR_IN | USB_RT_HUB,
|
2001-09-17 15:00:00 +08:00
|
|
|
dtype << 8, 0, data, size,
|
2005-04-17 06:20:36 +08:00
|
|
|
USB_CTRL_GET_TIMEOUT);
|
|
|
|
if (ret >= (USB_DT_HUB_NONVAR_SIZE + 2))
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* USB 2.0 spec Section 11.24.2.1
|
|
|
|
*/
|
|
|
|
static int clear_hub_feature(struct usb_device *hdev, int feature)
|
|
|
|
{
|
|
|
|
return usb_control_msg(hdev, usb_sndctrlpipe(hdev, 0),
|
|
|
|
USB_REQ_CLEAR_FEATURE, USB_RT_HUB, feature, 0, NULL, 0, 1000);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* USB 2.0 spec Section 11.24.2.2
|
|
|
|
*/
|
2013-01-23 04:26:30 +08:00
|
|
|
int usb_clear_port_feature(struct usb_device *hdev, int port1, int feature)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
return usb_control_msg(hdev, usb_sndctrlpipe(hdev, 0),
|
|
|
|
USB_REQ_CLEAR_FEATURE, USB_RT_PORT, feature, port1,
|
|
|
|
NULL, 0, 1000);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* USB 2.0 spec Section 11.24.2.13
|
|
|
|
*/
|
|
|
|
static int set_port_feature(struct usb_device *hdev, int port1, int feature)
|
|
|
|
{
|
|
|
|
return usb_control_msg(hdev, usb_sndctrlpipe(hdev, 0),
|
|
|
|
USB_REQ_SET_FEATURE, USB_RT_PORT, feature, port1,
|
|
|
|
NULL, 0, 1000);
|
|
|
|
}
|
|
|
|
|
2014-05-21 09:08:17 +08:00
|
|
|
static char *to_led_name(int selector)
|
|
|
|
{
|
|
|
|
switch (selector) {
|
|
|
|
case HUB_LED_AMBER:
|
|
|
|
return "amber";
|
|
|
|
case HUB_LED_GREEN:
|
|
|
|
return "green";
|
|
|
|
case HUB_LED_OFF:
|
|
|
|
return "off";
|
|
|
|
case HUB_LED_AUTO:
|
|
|
|
return "auto";
|
|
|
|
default:
|
|
|
|
return "??";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
* USB 2.0 spec Section 11.24.2.7.1.10 and table 11-7
|
|
|
|
* for info about using port indicators
|
|
|
|
*/
|
2014-05-21 09:08:17 +08:00
|
|
|
static void set_port_led(struct usb_hub *hub, int port1, int selector)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2014-05-21 09:08:17 +08:00
|
|
|
struct usb_port *port_dev = hub->ports[port1 - 1];
|
|
|
|
int status;
|
|
|
|
|
|
|
|
status = set_port_feature(hub->hdev, (selector << 8) | port1,
|
2005-04-17 06:20:36 +08:00
|
|
|
USB_PORT_FEAT_INDICATOR);
|
2014-05-21 09:08:17 +08:00
|
|
|
dev_dbg(&port_dev->dev, "indicator %s status %d\n",
|
|
|
|
to_led_name(selector), status);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
#define LED_CYCLE_PERIOD ((2*HZ)/3)
|
|
|
|
|
2015-08-08 16:03:34 +08:00
|
|
|
static void led_work(struct work_struct *work)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2006-11-22 22:57:56 +08:00
|
|
|
struct usb_hub *hub =
|
|
|
|
container_of(work, struct usb_hub, leds.work);
|
2005-04-17 06:20:36 +08:00
|
|
|
struct usb_device *hdev = hub->hdev;
|
|
|
|
unsigned i;
|
|
|
|
unsigned changed = 0;
|
|
|
|
int cursor = -1;
|
|
|
|
|
|
|
|
if (hdev->state != USB_STATE_CONFIGURED || hub->quiescing)
|
|
|
|
return;
|
|
|
|
|
2013-08-22 20:49:40 +08:00
|
|
|
for (i = 0; i < hdev->maxchild; i++) {
|
2005-04-17 06:20:36 +08:00
|
|
|
unsigned selector, mode;
|
|
|
|
|
|
|
|
/* 30%-50% duty cycle */
|
|
|
|
|
|
|
|
switch (hub->indicator[i]) {
|
|
|
|
/* cycle marker */
|
|
|
|
case INDICATOR_CYCLE:
|
|
|
|
cursor = i;
|
|
|
|
selector = HUB_LED_AUTO;
|
|
|
|
mode = INDICATOR_AUTO;
|
|
|
|
break;
|
|
|
|
/* blinking green = sw attention */
|
|
|
|
case INDICATOR_GREEN_BLINK:
|
|
|
|
selector = HUB_LED_GREEN;
|
|
|
|
mode = INDICATOR_GREEN_BLINK_OFF;
|
|
|
|
break;
|
|
|
|
case INDICATOR_GREEN_BLINK_OFF:
|
|
|
|
selector = HUB_LED_OFF;
|
|
|
|
mode = INDICATOR_GREEN_BLINK;
|
|
|
|
break;
|
|
|
|
/* blinking amber = hw attention */
|
|
|
|
case INDICATOR_AMBER_BLINK:
|
|
|
|
selector = HUB_LED_AMBER;
|
|
|
|
mode = INDICATOR_AMBER_BLINK_OFF;
|
|
|
|
break;
|
|
|
|
case INDICATOR_AMBER_BLINK_OFF:
|
|
|
|
selector = HUB_LED_OFF;
|
|
|
|
mode = INDICATOR_AMBER_BLINK;
|
|
|
|
break;
|
|
|
|
/* blink green/amber = reserved */
|
|
|
|
case INDICATOR_ALT_BLINK:
|
|
|
|
selector = HUB_LED_GREEN;
|
|
|
|
mode = INDICATOR_ALT_BLINK_OFF;
|
|
|
|
break;
|
|
|
|
case INDICATOR_ALT_BLINK_OFF:
|
|
|
|
selector = HUB_LED_AMBER;
|
|
|
|
mode = INDICATOR_ALT_BLINK;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (selector != HUB_LED_AUTO)
|
|
|
|
changed = 1;
|
|
|
|
set_port_led(hub, i + 1, selector);
|
|
|
|
hub->indicator[i] = mode;
|
|
|
|
}
|
|
|
|
if (!changed && blinkenlights) {
|
|
|
|
cursor++;
|
2013-08-22 20:49:40 +08:00
|
|
|
cursor %= hdev->maxchild;
|
2005-04-17 06:20:36 +08:00
|
|
|
set_port_led(hub, cursor + 1, HUB_LED_GREEN);
|
|
|
|
hub->indicator[cursor] = INDICATOR_CYCLE;
|
|
|
|
changed++;
|
|
|
|
}
|
|
|
|
if (changed)
|
2014-02-02 11:16:46 +08:00
|
|
|
queue_delayed_work(system_power_efficient_wq,
|
|
|
|
&hub->leds, LED_CYCLE_PERIOD);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* use a short timeout for hub/port status fetches */
|
|
|
|
#define USB_STS_TIMEOUT 1000
|
|
|
|
#define USB_STS_RETRIES 5
|
|
|
|
|
|
|
|
/*
|
|
|
|
* USB 2.0 spec Section 11.24.2.6
|
|
|
|
*/
|
|
|
|
static int get_hub_status(struct usb_device *hdev,
|
|
|
|
struct usb_hub_status *data)
|
|
|
|
{
|
|
|
|
int i, status = -ETIMEDOUT;
|
|
|
|
|
2011-05-20 20:53:25 +08:00
|
|
|
for (i = 0; i < USB_STS_RETRIES &&
|
|
|
|
(status == -ETIMEDOUT || status == -EPIPE); i++) {
|
2005-04-17 06:20:36 +08:00
|
|
|
status = usb_control_msg(hdev, usb_rcvctrlpipe(hdev, 0),
|
|
|
|
USB_REQ_GET_STATUS, USB_DIR_IN | USB_RT_HUB, 0, 0,
|
|
|
|
data, sizeof(*data), USB_STS_TIMEOUT);
|
|
|
|
}
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* USB 2.0 spec Section 11.24.2.7
|
2015-12-10 15:59:29 +08:00
|
|
|
* USB 3.1 takes into use the wValue and wLength fields, spec Section 10.16.2.6
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
|
|
|
static int get_port_status(struct usb_device *hdev, int port1,
|
2015-12-10 15:59:29 +08:00
|
|
|
void *data, u16 value, u16 length)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
int i, status = -ETIMEDOUT;
|
|
|
|
|
2011-05-20 20:53:25 +08:00
|
|
|
for (i = 0; i < USB_STS_RETRIES &&
|
|
|
|
(status == -ETIMEDOUT || status == -EPIPE); i++) {
|
2005-04-17 06:20:36 +08:00
|
|
|
status = usb_control_msg(hdev, usb_rcvctrlpipe(hdev, 0),
|
2015-12-10 15:59:29 +08:00
|
|
|
USB_REQ_GET_STATUS, USB_DIR_IN | USB_RT_PORT, value,
|
|
|
|
port1, data, length, USB_STS_TIMEOUT);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
2015-12-10 15:59:29 +08:00
|
|
|
static int hub_ext_port_status(struct usb_hub *hub, int port1, int type,
|
|
|
|
u16 *status, u16 *change, u32 *ext_status)
|
2008-03-04 04:15:43 +08:00
|
|
|
{
|
|
|
|
int ret;
|
2015-12-10 15:59:29 +08:00
|
|
|
int len = 4;
|
|
|
|
|
|
|
|
if (type != HUB_PORT_STATUS)
|
|
|
|
len = 8;
|
2008-03-04 04:15:43 +08:00
|
|
|
|
|
|
|
mutex_lock(&hub->status_mutex);
|
2015-12-10 15:59:29 +08:00
|
|
|
ret = get_port_status(hub->hdev, port1, &hub->status->port, type, len);
|
|
|
|
if (ret < len) {
|
2013-03-28 04:14:01 +08:00
|
|
|
if (ret != -ENODEV)
|
|
|
|
dev_err(hub->intfdev,
|
|
|
|
"%s failed (err = %d)\n", __func__, ret);
|
2008-03-04 04:15:43 +08:00
|
|
|
if (ret >= 0)
|
|
|
|
ret = -EIO;
|
|
|
|
} else {
|
|
|
|
*status = le16_to_cpu(hub->status->port.wPortStatus);
|
|
|
|
*change = le16_to_cpu(hub->status->port.wPortChange);
|
2015-12-10 15:59:29 +08:00
|
|
|
if (type != HUB_PORT_STATUS && ext_status)
|
|
|
|
*ext_status = le32_to_cpu(
|
|
|
|
hub->status->port.dwExtPortStatus);
|
2008-03-04 04:15:43 +08:00
|
|
|
ret = 0;
|
|
|
|
}
|
|
|
|
mutex_unlock(&hub->status_mutex);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2015-12-10 15:59:29 +08:00
|
|
|
static int hub_port_status(struct usb_hub *hub, int port1,
|
|
|
|
u16 *status, u16 *change)
|
|
|
|
{
|
|
|
|
return hub_ext_port_status(hub, port1, HUB_PORT_STATUS,
|
|
|
|
status, change, NULL);
|
|
|
|
}
|
|
|
|
|
2014-09-19 23:32:21 +08:00
|
|
|
static void kick_hub_wq(struct usb_hub *hub)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2014-09-19 23:32:21 +08:00
|
|
|
struct usb_interface *intf;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2014-09-19 23:32:21 +08:00
|
|
|
if (hub->disconnected || work_pending(&hub->events))
|
|
|
|
return;
|
2009-12-08 02:01:37 +08:00
|
|
|
|
2014-09-19 23:32:21 +08:00
|
|
|
/*
|
|
|
|
* Suppress autosuspend until the event is proceed.
|
|
|
|
*
|
|
|
|
* Be careful and make sure that the symmetric operation is
|
|
|
|
* always called. We are here only when there is no pending
|
|
|
|
* work for this hub. Therefore put the interface either when
|
|
|
|
* the new work is called or when it is canceled.
|
|
|
|
*/
|
|
|
|
intf = to_usb_interface(hub->intfdev);
|
|
|
|
usb_autopm_get_interface_no_resume(intf);
|
|
|
|
kref_get(&hub->kref);
|
|
|
|
|
|
|
|
if (queue_work(hub_wq, &hub->events))
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* the work has already been scheduled */
|
|
|
|
usb_autopm_put_interface_async(intf);
|
|
|
|
kref_put(&hub->kref, hub_release);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2014-09-19 23:32:22 +08:00
|
|
|
void usb_kick_hub_wq(struct usb_device *hdev)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2013-01-23 04:26:30 +08:00
|
|
|
struct usb_hub *hub = usb_hub_to_struct_hub(hdev);
|
2009-07-23 02:41:18 +08:00
|
|
|
|
|
|
|
if (hub)
|
2014-09-19 23:32:21 +08:00
|
|
|
kick_hub_wq(hub);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
USB/xHCI: Support device-initiated USB 3.0 resume.
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-11-15 10:00:01 +08:00
|
|
|
/*
|
|
|
|
* Let the USB core know that a USB 3.0 device has sent a Function Wake Device
|
|
|
|
* Notification, which indicates it had initiated remote wakeup.
|
|
|
|
*
|
|
|
|
* USB 3.0 hubs do not report the port link state change from U3 to U0 when the
|
|
|
|
* device initiates resume, so the USB core will not receive notice of the
|
|
|
|
* resume through the normal hub interrupt URB.
|
|
|
|
*/
|
|
|
|
void usb_wakeup_notification(struct usb_device *hdev,
|
|
|
|
unsigned int portnum)
|
|
|
|
{
|
|
|
|
struct usb_hub *hub;
|
|
|
|
|
|
|
|
if (!hdev)
|
|
|
|
return;
|
|
|
|
|
2013-01-23 04:26:30 +08:00
|
|
|
hub = usb_hub_to_struct_hub(hdev);
|
USB/xHCI: Support device-initiated USB 3.0 resume.
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-11-15 10:00:01 +08:00
|
|
|
if (hub) {
|
|
|
|
set_bit(portnum, hub->wakeup_bits);
|
2014-09-19 23:32:21 +08:00
|
|
|
kick_hub_wq(hub);
|
USB/xHCI: Support device-initiated USB 3.0 resume.
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-11-15 10:00:01 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(usb_wakeup_notification);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/* completion function, fires on port status changes and various faults */
|
IRQ: Maintain regs pointer globally rather than passing to IRQ handlers
Maintain a per-CPU global "struct pt_regs *" variable which can be used instead
of passing regs around manually through all ~1800 interrupt handlers in the
Linux kernel.
The regs pointer is used in few places, but it potentially costs both stack
space and code to pass it around. On the FRV arch, removing the regs parameter
from all the genirq function results in a 20% speed up of the IRQ exit path
(ie: from leaving timer_interrupt() to leaving do_IRQ()).
Where appropriate, an arch may override the generic storage facility and do
something different with the variable. On FRV, for instance, the address is
maintained in GR28 at all times inside the kernel as part of general exception
handling.
Having looked over the code, it appears that the parameter may be handed down
through up to twenty or so layers of functions. Consider a USB character
device attached to a USB hub, attached to a USB controller that posts its
interrupts through a cascaded auxiliary interrupt controller. A character
device driver may want to pass regs to the sysrq handler through the input
layer which adds another few layers of parameter passing.
I've build this code with allyesconfig for x86_64 and i386. I've runtested the
main part of the code on FRV and i386, though I can't test most of the drivers.
I've also done partial conversion for powerpc and MIPS - these at least compile
with minimal configurations.
This will affect all archs. Mostly the changes should be relatively easy.
Take do_IRQ(), store the regs pointer at the beginning, saving the old one:
struct pt_regs *old_regs = set_irq_regs(regs);
And put the old one back at the end:
set_irq_regs(old_regs);
Don't pass regs through to generic_handle_irq() or __do_IRQ().
In timer_interrupt(), this sort of change will be necessary:
- update_process_times(user_mode(regs));
- profile_tick(CPU_PROFILING, regs);
+ update_process_times(user_mode(get_irq_regs()));
+ profile_tick(CPU_PROFILING);
I'd like to move update_process_times()'s use of get_irq_regs() into itself,
except that i386, alone of the archs, uses something other than user_mode().
Some notes on the interrupt handling in the drivers:
(*) input_dev() is now gone entirely. The regs pointer is no longer stored in
the input_dev struct.
(*) finish_unlinks() in drivers/usb/host/ohci-q.c needs checking. It does
something different depending on whether it's been supplied with a regs
pointer or not.
(*) Various IRQ handler function pointers have been moved to type
irq_handler_t.
Signed-Off-By: David Howells <dhowells@redhat.com>
(cherry picked from 1b16e7ac850969f38b375e511e3fa2f474a33867 commit)
2006-10-05 21:55:46 +08:00
|
|
|
static void hub_irq(struct urb *urb)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2006-09-14 03:38:41 +08:00
|
|
|
struct usb_hub *hub = urb->context;
|
2007-08-25 03:42:52 +08:00
|
|
|
int status = urb->status;
|
2009-03-13 19:19:18 +08:00
|
|
|
unsigned i;
|
2005-04-17 06:20:36 +08:00
|
|
|
unsigned long bits;
|
|
|
|
|
2007-08-25 03:42:52 +08:00
|
|
|
switch (status) {
|
2005-04-17 06:20:36 +08:00
|
|
|
case -ENOENT: /* synchronous unlink */
|
|
|
|
case -ECONNRESET: /* async unlink */
|
|
|
|
case -ESHUTDOWN: /* hardware going away */
|
|
|
|
return;
|
|
|
|
|
|
|
|
default: /* presumably an error */
|
|
|
|
/* Cause a hub reset after 10 consecutive errors */
|
2015-08-08 16:03:34 +08:00
|
|
|
dev_dbg(hub->intfdev, "transfer --> %d\n", status);
|
2005-04-17 06:20:36 +08:00
|
|
|
if ((++hub->nerrors < 10) || hub->error)
|
|
|
|
goto resubmit;
|
2007-08-25 03:42:52 +08:00
|
|
|
hub->error = status;
|
2005-04-17 06:20:36 +08:00
|
|
|
/* FALL THROUGH */
|
2006-09-14 03:38:41 +08:00
|
|
|
|
2014-09-19 23:32:23 +08:00
|
|
|
/* let hub_wq handle things */
|
2005-04-17 06:20:36 +08:00
|
|
|
case 0: /* we got data: port status changed */
|
|
|
|
bits = 0;
|
|
|
|
for (i = 0; i < urb->actual_length; ++i)
|
|
|
|
bits |= ((unsigned long) ((*hub->buffer)[i]))
|
|
|
|
<< (i*8);
|
|
|
|
hub->event_bits[0] = bits;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
hub->nerrors = 0;
|
|
|
|
|
2014-09-19 23:32:23 +08:00
|
|
|
/* Something happened, let hub_wq figure it out */
|
2014-09-19 23:32:21 +08:00
|
|
|
kick_hub_wq(hub);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
resubmit:
|
|
|
|
if (hub->quiescing)
|
|
|
|
return;
|
|
|
|
|
2015-08-11 23:12:45 +08:00
|
|
|
status = usb_submit_urb(hub->urb, GFP_ATOMIC);
|
|
|
|
if (status != 0 && status != -ENODEV && status != -EPERM)
|
2015-08-08 16:03:34 +08:00
|
|
|
dev_err(hub->intfdev, "resubmit --> %d\n", status);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* USB 2.0 spec Section 11.24.2.3 */
|
|
|
|
static inline int
|
2015-08-08 16:03:34 +08:00
|
|
|
hub_clear_tt_buffer(struct usb_device *hdev, u16 devinfo, u16 tt)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2013-06-28 07:10:20 +08:00
|
|
|
/* Need to clear both directions for control ep */
|
|
|
|
if (((devinfo >> 11) & USB_ENDPOINT_XFERTYPE_MASK) ==
|
|
|
|
USB_ENDPOINT_XFER_CONTROL) {
|
|
|
|
int status = usb_control_msg(hdev, usb_sndctrlpipe(hdev, 0),
|
|
|
|
HUB_CLEAR_TT_BUFFER, USB_RT_PORT,
|
|
|
|
devinfo ^ 0x8000, tt, NULL, 0, 1000);
|
|
|
|
if (status)
|
|
|
|
return status;
|
|
|
|
}
|
2009-11-19 00:37:15 +08:00
|
|
|
return usb_control_msg(hdev, usb_sndctrlpipe(hdev, 0),
|
2005-04-17 06:20:36 +08:00
|
|
|
HUB_CLEAR_TT_BUFFER, USB_RT_PORT, devinfo,
|
|
|
|
tt, NULL, 0, 1000);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2014-09-19 23:32:23 +08:00
|
|
|
* enumeration blocks hub_wq for a long time. we use keventd instead, since
|
2005-04-17 06:20:36 +08:00
|
|
|
* long blocking there is the exception, not the rule. accordingly, HCDs
|
|
|
|
* talking to TTs must queue control transfers (not just bulk and iso), so
|
|
|
|
* both can talk to the same hub concurrently.
|
|
|
|
*/
|
2009-06-29 22:43:32 +08:00
|
|
|
static void hub_tt_work(struct work_struct *work)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2006-11-22 22:57:56 +08:00
|
|
|
struct usb_hub *hub =
|
2009-06-29 22:43:32 +08:00
|
|
|
container_of(work, struct usb_hub, tt.clear_work);
|
2005-04-17 06:20:36 +08:00
|
|
|
unsigned long flags;
|
|
|
|
|
2015-08-08 16:03:34 +08:00
|
|
|
spin_lock_irqsave(&hub->tt.lock, flags);
|
2012-10-02 03:21:12 +08:00
|
|
|
while (!list_empty(&hub->tt.clear_list)) {
|
2009-04-23 04:03:05 +08:00
|
|
|
struct list_head *next;
|
2005-04-17 06:20:36 +08:00
|
|
|
struct usb_tt_clear *clear;
|
|
|
|
struct usb_device *hdev = hub->hdev;
|
2009-06-29 22:43:32 +08:00
|
|
|
const struct hc_driver *drv;
|
2005-04-17 06:20:36 +08:00
|
|
|
int status;
|
|
|
|
|
2009-04-23 04:03:05 +08:00
|
|
|
next = hub->tt.clear_list.next;
|
2015-08-08 16:03:34 +08:00
|
|
|
clear = list_entry(next, struct usb_tt_clear, clear_list);
|
|
|
|
list_del(&clear->clear_list);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/* drop lock so HCD can concurrently report other TT errors */
|
2015-08-08 16:03:34 +08:00
|
|
|
spin_unlock_irqrestore(&hub->tt.lock, flags);
|
|
|
|
status = hub_clear_tt_buffer(hdev, clear->devinfo, clear->tt);
|
2013-03-28 04:14:01 +08:00
|
|
|
if (status && status != -ENODEV)
|
2015-08-08 16:03:34 +08:00
|
|
|
dev_err(&hdev->dev,
|
2005-04-17 06:20:36 +08:00
|
|
|
"clear tt %d (%04x) error %d\n",
|
|
|
|
clear->tt, clear->devinfo, status);
|
2009-06-29 22:43:32 +08:00
|
|
|
|
|
|
|
/* Tell the HCD, even if the operation failed */
|
|
|
|
drv = clear->hcd->driver;
|
|
|
|
if (drv->clear_tt_buffer_complete)
|
|
|
|
(drv->clear_tt_buffer_complete)(clear->hcd, clear->ep);
|
|
|
|
|
2005-04-19 08:39:34 +08:00
|
|
|
kfree(clear);
|
2009-06-29 22:43:32 +08:00
|
|
|
spin_lock_irqsave(&hub->tt.lock, flags);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2015-08-08 16:03:34 +08:00
|
|
|
spin_unlock_irqrestore(&hub->tt.lock, flags);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2013-01-23 04:26:29 +08:00
|
|
|
/**
|
|
|
|
* usb_hub_set_port_power - control hub port's power state
|
2013-06-18 22:28:48 +08:00
|
|
|
* @hdev: USB device belonging to the usb hub
|
|
|
|
* @hub: target hub
|
2013-01-23 04:26:29 +08:00
|
|
|
* @port1: port index
|
|
|
|
* @set: expected status
|
|
|
|
*
|
|
|
|
* call this function to control port's power via setting or
|
|
|
|
* clearing the port's PORT_POWER feature.
|
2013-08-03 02:10:04 +08:00
|
|
|
*
|
|
|
|
* Return: 0 if successful. A negative error code otherwise.
|
2013-01-23 04:26:29 +08:00
|
|
|
*/
|
2013-06-18 22:28:48 +08:00
|
|
|
int usb_hub_set_port_power(struct usb_device *hdev, struct usb_hub *hub,
|
|
|
|
int port1, bool set)
|
2013-01-23 04:26:29 +08:00
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (set)
|
|
|
|
ret = set_port_feature(hdev, port1, USB_PORT_FEAT_POWER);
|
|
|
|
else
|
2013-01-23 04:26:30 +08:00
|
|
|
ret = usb_clear_port_feature(hdev, port1, USB_PORT_FEAT_POWER);
|
|
|
|
|
2014-05-21 09:08:52 +08:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
if (set)
|
|
|
|
set_bit(port1, hub->power_bits);
|
|
|
|
else
|
|
|
|
clear_bit(port1, hub->power_bits);
|
|
|
|
return 0;
|
2013-01-23 04:26:29 +08:00
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/**
|
2009-06-29 22:43:32 +08:00
|
|
|
* usb_hub_clear_tt_buffer - clear control/bulk TT state in high speed hub
|
|
|
|
* @urb: an URB associated with the failed or incomplete split transaction
|
2005-04-17 06:20:36 +08:00
|
|
|
*
|
|
|
|
* High speed HCDs use this to tell the hub driver that some split control or
|
|
|
|
* bulk transaction failed in a way that requires clearing internal state of
|
|
|
|
* a transaction translator. This is normally detected (and reported) from
|
|
|
|
* interrupt context.
|
|
|
|
*
|
|
|
|
* It may not be possible for that hub to handle additional full (or low)
|
|
|
|
* speed transactions until that state is fully cleared out.
|
2013-08-03 02:10:04 +08:00
|
|
|
*
|
|
|
|
* Return: 0 if successful. A negative error code otherwise.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
2009-06-29 22:43:32 +08:00
|
|
|
int usb_hub_clear_tt_buffer(struct urb *urb)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2009-06-29 22:43:32 +08:00
|
|
|
struct usb_device *udev = urb->dev;
|
|
|
|
int pipe = urb->pipe;
|
2005-04-17 06:20:36 +08:00
|
|
|
struct usb_tt *tt = udev->tt;
|
|
|
|
unsigned long flags;
|
|
|
|
struct usb_tt_clear *clear;
|
|
|
|
|
|
|
|
/* we've got to cope with an arbitrary number of pending TT clears,
|
|
|
|
* since each TT has "at least two" buffers that can need it (and
|
|
|
|
* there can be many TTs per hub). even if they're uncommon.
|
|
|
|
*/
|
2015-04-30 17:32:53 +08:00
|
|
|
clear = kmalloc(sizeof *clear, GFP_ATOMIC);
|
|
|
|
if (clear == NULL) {
|
2015-08-08 16:03:34 +08:00
|
|
|
dev_err(&udev->dev, "can't save CLEAR_TT_BUFFER state\n");
|
2005-04-17 06:20:36 +08:00
|
|
|
/* FIXME recover somehow ... RESET_TT? */
|
2009-06-29 22:43:32 +08:00
|
|
|
return -ENOMEM;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* info that CLEAR_TT_BUFFER needs */
|
|
|
|
clear->tt = tt->multi ? udev->ttport : 1;
|
|
|
|
clear->devinfo = usb_pipeendpoint (pipe);
|
|
|
|
clear->devinfo |= udev->devnum << 4;
|
2015-08-08 16:03:34 +08:00
|
|
|
clear->devinfo |= usb_pipecontrol(pipe)
|
2005-04-17 06:20:36 +08:00
|
|
|
? (USB_ENDPOINT_XFER_CONTROL << 11)
|
|
|
|
: (USB_ENDPOINT_XFER_BULK << 11);
|
2015-08-08 16:03:34 +08:00
|
|
|
if (usb_pipein(pipe))
|
2005-04-17 06:20:36 +08:00
|
|
|
clear->devinfo |= 1 << 15;
|
2009-06-29 22:43:32 +08:00
|
|
|
|
|
|
|
/* info for completion callback */
|
|
|
|
clear->hcd = bus_to_hcd(udev->bus);
|
|
|
|
clear->ep = urb->ep;
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/* tell keventd to clear state for this TT */
|
2015-08-08 16:03:34 +08:00
|
|
|
spin_lock_irqsave(&tt->lock, flags);
|
|
|
|
list_add_tail(&clear->clear_list, &tt->clear_list);
|
2009-06-29 22:43:32 +08:00
|
|
|
schedule_work(&tt->clear_work);
|
2015-08-08 16:03:34 +08:00
|
|
|
spin_unlock_irqrestore(&tt->lock, flags);
|
2009-06-29 22:43:32 +08:00
|
|
|
return 0;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2009-06-29 22:43:32 +08:00
|
|
|
EXPORT_SYMBOL_GPL(usb_hub_clear_tt_buffer);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2014-05-21 09:08:57 +08:00
|
|
|
static void hub_power_on(struct usb_hub *hub, bool do_delay)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
int port1;
|
2006-04-28 03:54:22 +08:00
|
|
|
|
|
|
|
/* Enable power on each port. Some hubs have reserved values
|
|
|
|
* of LPSM (> 2) in their descriptors, even though they are
|
|
|
|
* USB 2.0 hubs. Some hubs do not implement port-power switching
|
|
|
|
* but only emulate it. In all cases, the ports won't work
|
|
|
|
* unless we send these messages to the hub.
|
|
|
|
*/
|
2014-05-21 09:08:12 +08:00
|
|
|
if (hub_is_port_power_switchable(hub))
|
2005-04-17 06:20:36 +08:00
|
|
|
dev_dbg(hub->intfdev, "enabling power on all ports\n");
|
2006-04-28 03:54:22 +08:00
|
|
|
else
|
|
|
|
dev_dbg(hub->intfdev, "trying to enable port power on "
|
|
|
|
"non-switchable hub\n");
|
2013-08-22 20:49:40 +08:00
|
|
|
for (port1 = 1; port1 <= hub->hdev->maxchild; port1++)
|
2014-05-21 09:08:52 +08:00
|
|
|
if (test_bit(port1, hub->power_bits))
|
2013-01-23 04:26:30 +08:00
|
|
|
set_port_feature(hub->hdev, port1, USB_PORT_FEAT_POWER);
|
|
|
|
else
|
|
|
|
usb_clear_port_feature(hub->hdev, port1,
|
|
|
|
USB_PORT_FEAT_POWER);
|
2008-09-23 02:44:26 +08:00
|
|
|
if (do_delay)
|
2014-05-21 09:08:57 +08:00
|
|
|
msleep(hub_power_on_good_delay(hub));
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static int hub_hub_status(struct usb_hub *hub,
|
|
|
|
u16 *status, u16 *change)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
2007-02-05 22:56:15 +08:00
|
|
|
mutex_lock(&hub->status_mutex);
|
2005-04-17 06:20:36 +08:00
|
|
|
ret = get_hub_status(hub->hdev, &hub->status->hub);
|
2013-03-28 04:14:01 +08:00
|
|
|
if (ret < 0) {
|
|
|
|
if (ret != -ENODEV)
|
|
|
|
dev_err(hub->intfdev,
|
|
|
|
"%s failed (err = %d)\n", __func__, ret);
|
|
|
|
} else {
|
2005-04-17 06:20:36 +08:00
|
|
|
*status = le16_to_cpu(hub->status->hub.wHubStatus);
|
2013-10-11 05:41:27 +08:00
|
|
|
*change = le16_to_cpu(hub->status->hub.wHubChange);
|
2005-04-17 06:20:36 +08:00
|
|
|
ret = 0;
|
|
|
|
}
|
2007-02-05 22:56:15 +08:00
|
|
|
mutex_unlock(&hub->status_mutex);
|
2005-04-17 06:20:36 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
USB: Allow USB 3.0 ports to be disabled.
If hot and warm reset fails, or a port remains in the Compliance Mode,
the USB core needs to be able to disable a USB 3.0 port. Unlike USB 2.0
ports, once the port is placed into the Disabled link state, it will not
report any new device connects. To get device connect notifications, we
need to put the link into the Disabled state, and then the RxDetect
state.
The xHCI driver needs to atomically clear all change bits on USB 3.0
port disable, so that we get Port Status Change Events for future port
changes. We could technically do this in the USB core instead of in the
xHCI roothub code, since the port state machine can't advance out of the
disabled state until we set the link state to RxDetect. However,
external USB 3.0 hubs don't need this code. They are level-triggered,
not edge-triggered like xHCI, so they will continue to send interrupt
events when any change bit is set. Therefore it doesn't make sense to
put this code in the USB core.
This patch is part of a series to fix several reports of infinite loops
on device enumeration failure. This includes John, when he boots with
a USB 3.0 device (Roseweil eusb3 enclosure) attached to his NEC 0.96
host controller. The fix requires warm reset support, so it does not
make sense to backport this patch to stable kernels without warm reset
support.
This patch should be backported to kernels as old as 3.2, contain the
commit ID 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine warm
reset logic"
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: John Covici <covici@ccs.covici.com>
Cc: stable@vger.kernel.org
2012-11-15 08:42:32 +08:00
|
|
|
static int hub_set_port_link_state(struct usb_hub *hub, int port1,
|
|
|
|
unsigned int link_status)
|
|
|
|
{
|
|
|
|
return set_port_feature(hub->hdev,
|
|
|
|
port1 | (link_status << 3),
|
|
|
|
USB_PORT_FEAT_LINK_STATE);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If USB 3.0 ports are placed into the Disabled state, they will no longer
|
|
|
|
* detect any device connects or disconnects. This is generally not what the
|
|
|
|
* USB core wants, since it expects a disabled port to produce a port status
|
|
|
|
* change event when a new device connects.
|
|
|
|
*
|
|
|
|
* Instead, set the link state to Disabled, wait for the link to settle into
|
|
|
|
* that state, clear any change bits, and then put the port into the RxDetect
|
|
|
|
* state.
|
|
|
|
*/
|
|
|
|
static int hub_usb3_port_disable(struct usb_hub *hub, int port1)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
int total_time;
|
|
|
|
u16 portchange, portstatus;
|
|
|
|
|
|
|
|
if (!hub_is_superspeed(hub->hdev))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2014-07-18 01:12:13 +08:00
|
|
|
ret = hub_port_status(hub, port1, &portstatus, &portchange);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* USB controller Advanced Micro Devices, Inc. [AMD] FCH USB XHCI
|
|
|
|
* Controller [1022:7814] will have spurious result making the following
|
|
|
|
* usb 3.0 device hotplugging route to the 2.0 root hub and recognized
|
|
|
|
* as high-speed device if we set the usb 3.0 port link state to
|
|
|
|
* Disabled. Since it's already in USB_SS_PORT_LS_RX_DETECT state, we
|
|
|
|
* check the state here to avoid the bug.
|
|
|
|
*/
|
|
|
|
if ((portstatus & USB_PORT_STAT_LINK_STATE) ==
|
|
|
|
USB_SS_PORT_LS_RX_DETECT) {
|
|
|
|
dev_dbg(&hub->ports[port1 - 1]->dev,
|
|
|
|
"Not disabling port; link state is RxDetect\n");
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
USB: Allow USB 3.0 ports to be disabled.
If hot and warm reset fails, or a port remains in the Compliance Mode,
the USB core needs to be able to disable a USB 3.0 port. Unlike USB 2.0
ports, once the port is placed into the Disabled link state, it will not
report any new device connects. To get device connect notifications, we
need to put the link into the Disabled state, and then the RxDetect
state.
The xHCI driver needs to atomically clear all change bits on USB 3.0
port disable, so that we get Port Status Change Events for future port
changes. We could technically do this in the USB core instead of in the
xHCI roothub code, since the port state machine can't advance out of the
disabled state until we set the link state to RxDetect. However,
external USB 3.0 hubs don't need this code. They are level-triggered,
not edge-triggered like xHCI, so they will continue to send interrupt
events when any change bit is set. Therefore it doesn't make sense to
put this code in the USB core.
This patch is part of a series to fix several reports of infinite loops
on device enumeration failure. This includes John, when he boots with
a USB 3.0 device (Roseweil eusb3 enclosure) attached to his NEC 0.96
host controller. The fix requires warm reset support, so it does not
make sense to backport this patch to stable kernels without warm reset
support.
This patch should be backported to kernels as old as 3.2, contain the
commit ID 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine warm
reset logic"
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: John Covici <covici@ccs.covici.com>
Cc: stable@vger.kernel.org
2012-11-15 08:42:32 +08:00
|
|
|
ret = hub_set_port_link_state(hub, port1, USB_SS_PORT_LS_SS_DISABLED);
|
2013-03-28 04:14:01 +08:00
|
|
|
if (ret)
|
USB: Allow USB 3.0 ports to be disabled.
If hot and warm reset fails, or a port remains in the Compliance Mode,
the USB core needs to be able to disable a USB 3.0 port. Unlike USB 2.0
ports, once the port is placed into the Disabled link state, it will not
report any new device connects. To get device connect notifications, we
need to put the link into the Disabled state, and then the RxDetect
state.
The xHCI driver needs to atomically clear all change bits on USB 3.0
port disable, so that we get Port Status Change Events for future port
changes. We could technically do this in the USB core instead of in the
xHCI roothub code, since the port state machine can't advance out of the
disabled state until we set the link state to RxDetect. However,
external USB 3.0 hubs don't need this code. They are level-triggered,
not edge-triggered like xHCI, so they will continue to send interrupt
events when any change bit is set. Therefore it doesn't make sense to
put this code in the USB core.
This patch is part of a series to fix several reports of infinite loops
on device enumeration failure. This includes John, when he boots with
a USB 3.0 device (Roseweil eusb3 enclosure) attached to his NEC 0.96
host controller. The fix requires warm reset support, so it does not
make sense to backport this patch to stable kernels without warm reset
support.
This patch should be backported to kernels as old as 3.2, contain the
commit ID 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine warm
reset logic"
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: John Covici <covici@ccs.covici.com>
Cc: stable@vger.kernel.org
2012-11-15 08:42:32 +08:00
|
|
|
return ret;
|
|
|
|
|
|
|
|
/* Wait for the link to enter the disabled state. */
|
|
|
|
for (total_time = 0; ; total_time += HUB_DEBOUNCE_STEP) {
|
|
|
|
ret = hub_port_status(hub, port1, &portstatus, &portchange);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
if ((portstatus & USB_PORT_STAT_LINK_STATE) ==
|
|
|
|
USB_SS_PORT_LS_SS_DISABLED)
|
|
|
|
break;
|
|
|
|
if (total_time >= HUB_DEBOUNCE_TIMEOUT)
|
|
|
|
break;
|
|
|
|
msleep(HUB_DEBOUNCE_STEP);
|
|
|
|
}
|
|
|
|
if (total_time >= HUB_DEBOUNCE_TIMEOUT)
|
2014-05-21 09:08:17 +08:00
|
|
|
dev_warn(&hub->ports[port1 - 1]->dev,
|
|
|
|
"Could not disable after %d ms\n", total_time);
|
USB: Allow USB 3.0 ports to be disabled.
If hot and warm reset fails, or a port remains in the Compliance Mode,
the USB core needs to be able to disable a USB 3.0 port. Unlike USB 2.0
ports, once the port is placed into the Disabled link state, it will not
report any new device connects. To get device connect notifications, we
need to put the link into the Disabled state, and then the RxDetect
state.
The xHCI driver needs to atomically clear all change bits on USB 3.0
port disable, so that we get Port Status Change Events for future port
changes. We could technically do this in the USB core instead of in the
xHCI roothub code, since the port state machine can't advance out of the
disabled state until we set the link state to RxDetect. However,
external USB 3.0 hubs don't need this code. They are level-triggered,
not edge-triggered like xHCI, so they will continue to send interrupt
events when any change bit is set. Therefore it doesn't make sense to
put this code in the USB core.
This patch is part of a series to fix several reports of infinite loops
on device enumeration failure. This includes John, when he boots with
a USB 3.0 device (Roseweil eusb3 enclosure) attached to his NEC 0.96
host controller. The fix requires warm reset support, so it does not
make sense to backport this patch to stable kernels without warm reset
support.
This patch should be backported to kernels as old as 3.2, contain the
commit ID 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine warm
reset logic"
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: John Covici <covici@ccs.covici.com>
Cc: stable@vger.kernel.org
2012-11-15 08:42:32 +08:00
|
|
|
|
|
|
|
return hub_set_port_link_state(hub, port1, USB_SS_PORT_LS_RX_DETECT);
|
|
|
|
}
|
|
|
|
|
2005-08-11 05:04:13 +08:00
|
|
|
static int hub_port_disable(struct usb_hub *hub, int port1, int set_state)
|
|
|
|
{
|
2014-05-21 09:08:17 +08:00
|
|
|
struct usb_port *port_dev = hub->ports[port1 - 1];
|
2005-08-11 05:04:13 +08:00
|
|
|
struct usb_device *hdev = hub->hdev;
|
2007-05-04 23:52:20 +08:00
|
|
|
int ret = 0;
|
2005-08-11 05:04:13 +08:00
|
|
|
|
2014-05-21 09:08:17 +08:00
|
|
|
if (port_dev->child && set_state)
|
|
|
|
usb_set_device_state(port_dev->child, USB_STATE_NOTATTACHED);
|
USB: Allow USB 3.0 ports to be disabled.
If hot and warm reset fails, or a port remains in the Compliance Mode,
the USB core needs to be able to disable a USB 3.0 port. Unlike USB 2.0
ports, once the port is placed into the Disabled link state, it will not
report any new device connects. To get device connect notifications, we
need to put the link into the Disabled state, and then the RxDetect
state.
The xHCI driver needs to atomically clear all change bits on USB 3.0
port disable, so that we get Port Status Change Events for future port
changes. We could technically do this in the USB core instead of in the
xHCI roothub code, since the port state machine can't advance out of the
disabled state until we set the link state to RxDetect. However,
external USB 3.0 hubs don't need this code. They are level-triggered,
not edge-triggered like xHCI, so they will continue to send interrupt
events when any change bit is set. Therefore it doesn't make sense to
put this code in the USB core.
This patch is part of a series to fix several reports of infinite loops
on device enumeration failure. This includes John, when he boots with
a USB 3.0 device (Roseweil eusb3 enclosure) attached to his NEC 0.96
host controller. The fix requires warm reset support, so it does not
make sense to backport this patch to stable kernels without warm reset
support.
This patch should be backported to kernels as old as 3.2, contain the
commit ID 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine warm
reset logic"
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: John Covici <covici@ccs.covici.com>
Cc: stable@vger.kernel.org
2012-11-15 08:42:32 +08:00
|
|
|
if (!hub->error) {
|
|
|
|
if (hub_is_superspeed(hub->hdev))
|
|
|
|
ret = hub_usb3_port_disable(hub, port1);
|
|
|
|
else
|
2013-01-23 04:26:30 +08:00
|
|
|
ret = usb_clear_port_feature(hdev, port1,
|
USB: Allow USB 3.0 ports to be disabled.
If hot and warm reset fails, or a port remains in the Compliance Mode,
the USB core needs to be able to disable a USB 3.0 port. Unlike USB 2.0
ports, once the port is placed into the Disabled link state, it will not
report any new device connects. To get device connect notifications, we
need to put the link into the Disabled state, and then the RxDetect
state.
The xHCI driver needs to atomically clear all change bits on USB 3.0
port disable, so that we get Port Status Change Events for future port
changes. We could technically do this in the USB core instead of in the
xHCI roothub code, since the port state machine can't advance out of the
disabled state until we set the link state to RxDetect. However,
external USB 3.0 hubs don't need this code. They are level-triggered,
not edge-triggered like xHCI, so they will continue to send interrupt
events when any change bit is set. Therefore it doesn't make sense to
put this code in the USB core.
This patch is part of a series to fix several reports of infinite loops
on device enumeration failure. This includes John, when he boots with
a USB 3.0 device (Roseweil eusb3 enclosure) attached to his NEC 0.96
host controller. The fix requires warm reset support, so it does not
make sense to backport this patch to stable kernels without warm reset
support.
This patch should be backported to kernels as old as 3.2, contain the
commit ID 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine warm
reset logic"
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: John Covici <covici@ccs.covici.com>
Cc: stable@vger.kernel.org
2012-11-15 08:42:32 +08:00
|
|
|
USB_PORT_FEAT_ENABLE);
|
|
|
|
}
|
2013-03-28 04:14:01 +08:00
|
|
|
if (ret && ret != -ENODEV)
|
2014-05-21 09:08:17 +08:00
|
|
|
dev_err(&port_dev->dev, "cannot disable (err = %d)\n", ret);
|
2005-08-11 05:04:13 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2007-05-04 23:52:20 +08:00
|
|
|
/*
|
2011-02-27 12:33:56 +08:00
|
|
|
* Disable a port and mark a logical connect-change event, so that some
|
2014-09-19 23:32:23 +08:00
|
|
|
* time later hub_wq will disconnect() any existing usb_device on the port
|
2007-05-04 23:52:20 +08:00
|
|
|
* and will re-enumerate if there actually is a device attached.
|
|
|
|
*/
|
|
|
|
static void hub_port_logical_disconnect(struct usb_hub *hub, int port1)
|
|
|
|
{
|
2014-05-21 09:08:17 +08:00
|
|
|
dev_dbg(&hub->ports[port1 - 1]->dev, "logical disconnect\n");
|
2007-05-04 23:52:20 +08:00
|
|
|
hub_port_disable(hub, port1, 1);
|
2005-11-19 01:06:34 +08:00
|
|
|
|
2007-05-04 23:52:20 +08:00
|
|
|
/* FIXME let caller ask to power down the port:
|
|
|
|
* - some devices won't enumerate without a VBUS power cycle
|
|
|
|
* - SRP saves power that way
|
|
|
|
* - ... new call, TBD ...
|
|
|
|
* That's easy if this hub can switch power per-port, and
|
2014-09-19 23:32:23 +08:00
|
|
|
* hub_wq reactivates the port later (timer, SRP, etc).
|
2007-05-04 23:52:20 +08:00
|
|
|
* Powerdown must be optional, because of reset/DFU.
|
|
|
|
*/
|
|
|
|
|
|
|
|
set_bit(port1, hub->change_bits);
|
2014-09-19 23:32:21 +08:00
|
|
|
kick_hub_wq(hub);
|
2007-05-04 23:52:20 +08:00
|
|
|
}
|
|
|
|
|
2009-10-28 03:20:13 +08:00
|
|
|
/**
|
|
|
|
* usb_remove_device - disable a device's port on its parent hub
|
|
|
|
* @udev: device to be disabled and removed
|
|
|
|
* Context: @udev locked, must be able to sleep.
|
|
|
|
*
|
2014-09-19 23:32:23 +08:00
|
|
|
* After @udev's port has been disabled, hub_wq is notified and it will
|
2009-10-28 03:20:13 +08:00
|
|
|
* see that the device has been disconnected. When the device is
|
|
|
|
* physically unplugged and something is plugged in, the events will
|
|
|
|
* be received and processed normally.
|
2013-08-03 02:10:04 +08:00
|
|
|
*
|
|
|
|
* Return: 0 if successful. A negative error code otherwise.
|
2009-10-28 03:20:13 +08:00
|
|
|
*/
|
|
|
|
int usb_remove_device(struct usb_device *udev)
|
|
|
|
{
|
|
|
|
struct usb_hub *hub;
|
|
|
|
struct usb_interface *intf;
|
|
|
|
|
|
|
|
if (!udev->parent) /* Can't remove a root hub */
|
|
|
|
return -EINVAL;
|
2013-01-23 04:26:30 +08:00
|
|
|
hub = usb_hub_to_struct_hub(udev->parent);
|
2009-10-28 03:20:13 +08:00
|
|
|
intf = to_usb_interface(hub->intfdev);
|
|
|
|
|
|
|
|
usb_autopm_get_interface(intf);
|
|
|
|
set_bit(udev->portnum, hub->removed_bits);
|
|
|
|
hub_port_logical_disconnect(hub, udev->portnum);
|
|
|
|
usb_autopm_put_interface(intf);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-04-28 23:06:42 +08:00
|
|
|
enum hub_activation_type {
|
2009-12-08 02:01:37 +08:00
|
|
|
HUB_INIT, HUB_INIT2, HUB_INIT3, /* INITs must come first */
|
2008-09-23 02:44:26 +08:00
|
|
|
HUB_POST_RESET, HUB_RESUME, HUB_RESET_RESUME,
|
2008-04-28 23:06:42 +08:00
|
|
|
};
|
2008-03-04 04:15:51 +08:00
|
|
|
|
2008-09-23 02:44:26 +08:00
|
|
|
static void hub_init_func2(struct work_struct *ws);
|
|
|
|
static void hub_init_func3(struct work_struct *ws);
|
|
|
|
|
2008-04-28 23:07:17 +08:00
|
|
|
static void hub_activate(struct usb_hub *hub, enum hub_activation_type type)
|
2008-03-04 04:15:51 +08:00
|
|
|
{
|
|
|
|
struct usb_device *hdev = hub->hdev;
|
2010-12-24 03:12:42 +08:00
|
|
|
struct usb_hcd *hcd;
|
|
|
|
int ret;
|
2008-03-04 04:15:51 +08:00
|
|
|
int port1;
|
2008-04-28 23:07:17 +08:00
|
|
|
int status;
|
2008-04-28 23:07:07 +08:00
|
|
|
bool need_debounce_delay = false;
|
2008-09-23 02:44:26 +08:00
|
|
|
unsigned delay;
|
|
|
|
|
|
|
|
/* Continue a partial initialization */
|
2015-12-17 02:32:38 +08:00
|
|
|
if (type == HUB_INIT2 || type == HUB_INIT3) {
|
|
|
|
device_lock(hub->intfdev);
|
|
|
|
|
|
|
|
/* Was the hub disconnected while we were waiting? */
|
2016-08-05 23:49:45 +08:00
|
|
|
if (hub->disconnected)
|
|
|
|
goto disconnected;
|
2015-12-17 02:32:38 +08:00
|
|
|
if (type == HUB_INIT2)
|
|
|
|
goto init2;
|
2008-09-23 02:44:26 +08:00
|
|
|
goto init3;
|
2015-12-17 02:32:38 +08:00
|
|
|
}
|
|
|
|
kref_get(&hub->kref);
|
2008-03-04 04:15:51 +08:00
|
|
|
|
2012-02-18 13:32:27 +08:00
|
|
|
/* The superspeed hub except for root hub has to use Hub Depth
|
|
|
|
* value as an offset into the route string to locate the bits
|
|
|
|
* it uses to determine the downstream port number. So hub driver
|
|
|
|
* should send a set hub depth request to superspeed hub after
|
|
|
|
* the superspeed hub is set configuration in initialization or
|
|
|
|
* reset procedure.
|
|
|
|
*
|
|
|
|
* After a resume, port power should still be on.
|
2008-04-28 23:07:17 +08:00
|
|
|
* For any other type of activation, turn it on.
|
|
|
|
*/
|
2008-09-23 02:44:26 +08:00
|
|
|
if (type != HUB_RESUME) {
|
2012-02-18 13:32:27 +08:00
|
|
|
if (hdev->parent && hub_is_superspeed(hdev)) {
|
|
|
|
ret = usb_control_msg(hdev, usb_sndctrlpipe(hdev, 0),
|
|
|
|
HUB_SET_DEPTH, USB_RT_HUB,
|
|
|
|
hdev->level - 1, 0, NULL, 0,
|
|
|
|
USB_CTRL_SET_TIMEOUT);
|
|
|
|
if (ret < 0)
|
|
|
|
dev_err(hub->intfdev,
|
|
|
|
"set hub depth failed\n");
|
|
|
|
}
|
2008-09-23 02:44:26 +08:00
|
|
|
|
|
|
|
/* Speed up system boot by using a delayed_work for the
|
|
|
|
* hub's initial power-up delays. This is pretty awkward
|
|
|
|
* and the implementation looks like a home-brewed sort of
|
|
|
|
* setjmp/longjmp, but it saves at least 100 ms for each
|
|
|
|
* root hub (assuming usbcore is compiled into the kernel
|
|
|
|
* rather than as a module). It adds up.
|
|
|
|
*
|
|
|
|
* This can't be done for HUB_RESUME or HUB_RESET_RESUME
|
|
|
|
* because for those activation types the ports have to be
|
|
|
|
* operational when we return. In theory this could be done
|
|
|
|
* for HUB_POST_RESET, but it's easier not to.
|
|
|
|
*/
|
|
|
|
if (type == HUB_INIT) {
|
2015-08-21 13:17:46 +08:00
|
|
|
delay = hub_power_on_good_delay(hub);
|
2014-05-21 09:08:57 +08:00
|
|
|
|
|
|
|
hub_power_on(hub, false);
|
2014-03-07 23:24:48 +08:00
|
|
|
INIT_DELAYED_WORK(&hub->init_work, hub_init_func2);
|
2014-02-02 11:16:46 +08:00
|
|
|
queue_delayed_work(system_power_efficient_wq,
|
|
|
|
&hub->init_work,
|
2008-09-23 02:44:26 +08:00
|
|
|
msecs_to_jiffies(delay));
|
2008-10-28 00:07:44 +08:00
|
|
|
|
|
|
|
/* Suppress autosuspend until init is done */
|
2009-12-08 02:01:37 +08:00
|
|
|
usb_autopm_get_interface_no_resume(
|
|
|
|
to_usb_interface(hub->intfdev));
|
2008-09-23 02:44:26 +08:00
|
|
|
return; /* Continues at init2: below */
|
2010-12-24 03:12:42 +08:00
|
|
|
} else if (type == HUB_RESET_RESUME) {
|
|
|
|
/* The internal host controller state for the hub device
|
|
|
|
* may be gone after a host power loss on system resume.
|
|
|
|
* Update the device's info so the HW knows it's a hub.
|
|
|
|
*/
|
|
|
|
hcd = bus_to_hcd(hdev->bus);
|
|
|
|
if (hcd->driver->update_hub_device) {
|
|
|
|
ret = hcd->driver->update_hub_device(hcd, hdev,
|
|
|
|
&hub->tt, GFP_NOIO);
|
|
|
|
if (ret < 0) {
|
|
|
|
dev_err(hub->intfdev, "Host not "
|
|
|
|
"accepting hub info "
|
|
|
|
"update.\n");
|
|
|
|
dev_err(hub->intfdev, "LS/FS devices "
|
|
|
|
"and hubs may not work "
|
|
|
|
"under this hub\n.");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
hub_power_on(hub, true);
|
2008-09-23 02:44:26 +08:00
|
|
|
} else {
|
|
|
|
hub_power_on(hub, true);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
init2:
|
2008-04-28 23:07:17 +08:00
|
|
|
|
2014-05-21 09:08:17 +08:00
|
|
|
/*
|
2014-09-19 23:32:23 +08:00
|
|
|
* Check each port and set hub->change_bits to let hub_wq know
|
2008-04-28 23:06:42 +08:00
|
|
|
* which ports need attention.
|
2008-03-04 04:15:51 +08:00
|
|
|
*/
|
|
|
|
for (port1 = 1; port1 <= hdev->maxchild; ++port1) {
|
2014-05-21 09:08:17 +08:00
|
|
|
struct usb_port *port_dev = hub->ports[port1 - 1];
|
|
|
|
struct usb_device *udev = port_dev->child;
|
2008-03-04 04:15:51 +08:00
|
|
|
u16 portstatus, portchange;
|
|
|
|
|
2008-04-28 23:06:42 +08:00
|
|
|
portstatus = portchange = 0;
|
|
|
|
status = hub_port_status(hub, port1, &portstatus, &portchange);
|
|
|
|
if (udev || (portstatus & USB_PORT_STAT_CONNECTION))
|
2014-05-21 09:08:17 +08:00
|
|
|
dev_dbg(&port_dev->dev, "status %04x change %04x\n",
|
|
|
|
portstatus, portchange);
|
2008-04-28 23:06:42 +08:00
|
|
|
|
2014-05-21 09:08:17 +08:00
|
|
|
/*
|
|
|
|
* After anything other than HUB_RESUME (i.e., initialization
|
2008-04-28 23:06:42 +08:00
|
|
|
* or any sort of reset), every port should be disabled.
|
|
|
|
* Unconnected ports should likewise be disabled (paranoia),
|
|
|
|
* and so should ports for which we have no usb_device.
|
|
|
|
*/
|
|
|
|
if ((portstatus & USB_PORT_STAT_ENABLE) && (
|
|
|
|
type != HUB_RESUME ||
|
|
|
|
!(portstatus & USB_PORT_STAT_CONNECTION) ||
|
|
|
|
!udev ||
|
|
|
|
udev->state == USB_STATE_NOTATTACHED)) {
|
2010-05-07 18:09:27 +08:00
|
|
|
/*
|
|
|
|
* USB3 protocol ports will automatically transition
|
|
|
|
* to Enabled state when detect an USB3.0 device attach.
|
2013-10-08 02:58:20 +08:00
|
|
|
* Do not disable USB3 protocol ports, just pretend
|
|
|
|
* power was lost
|
2010-05-07 18:09:27 +08:00
|
|
|
*/
|
2013-10-08 02:58:20 +08:00
|
|
|
portstatus &= ~USB_PORT_STAT_ENABLE;
|
|
|
|
if (!hub_is_superspeed(hdev))
|
2013-01-23 04:26:30 +08:00
|
|
|
usb_clear_port_feature(hdev, port1,
|
2010-05-07 18:09:27 +08:00
|
|
|
USB_PORT_FEAT_ENABLE);
|
2008-03-04 04:15:51 +08:00
|
|
|
}
|
|
|
|
|
2008-04-28 23:07:07 +08:00
|
|
|
/* Clear status-change flags; we'll debounce later */
|
|
|
|
if (portchange & USB_PORT_STAT_C_CONNECTION) {
|
|
|
|
need_debounce_delay = true;
|
2013-01-23 04:26:30 +08:00
|
|
|
usb_clear_port_feature(hub->hdev, port1,
|
2008-04-28 23:07:07 +08:00
|
|
|
USB_PORT_FEAT_C_CONNECTION);
|
|
|
|
}
|
|
|
|
if (portchange & USB_PORT_STAT_C_ENABLE) {
|
|
|
|
need_debounce_delay = true;
|
2013-01-23 04:26:30 +08:00
|
|
|
usb_clear_port_feature(hub->hdev, port1,
|
2008-04-28 23:07:07 +08:00
|
|
|
USB_PORT_FEAT_C_ENABLE);
|
|
|
|
}
|
2013-10-16 08:45:00 +08:00
|
|
|
if (portchange & USB_PORT_STAT_C_RESET) {
|
|
|
|
need_debounce_delay = true;
|
|
|
|
usb_clear_port_feature(hub->hdev, port1,
|
|
|
|
USB_PORT_FEAT_C_RESET);
|
|
|
|
}
|
2011-11-03 21:07:18 +08:00
|
|
|
if ((portchange & USB_PORT_STAT_C_BH_RESET) &&
|
|
|
|
hub_is_superspeed(hub->hdev)) {
|
|
|
|
need_debounce_delay = true;
|
2013-01-23 04:26:30 +08:00
|
|
|
usb_clear_port_feature(hub->hdev, port1,
|
2011-11-03 21:07:18 +08:00
|
|
|
USB_PORT_FEAT_C_BH_PORT_RESET);
|
|
|
|
}
|
2009-10-28 03:20:13 +08:00
|
|
|
/* We can forget about a "removed" device when there's a
|
|
|
|
* physical disconnect or the connect status changes.
|
|
|
|
*/
|
|
|
|
if (!(portstatus & USB_PORT_STAT_CONNECTION) ||
|
|
|
|
(portchange & USB_PORT_STAT_C_CONNECTION))
|
|
|
|
clear_bit(port1, hub->removed_bits);
|
|
|
|
|
2008-04-28 23:06:42 +08:00
|
|
|
if (!udev || udev->state == USB_STATE_NOTATTACHED) {
|
2014-09-19 23:32:23 +08:00
|
|
|
/* Tell hub_wq to disconnect the device or
|
2008-04-28 23:06:42 +08:00
|
|
|
* check for a new connection
|
|
|
|
*/
|
2014-01-08 14:45:42 +08:00
|
|
|
if (udev || (portstatus & USB_PORT_STAT_CONNECTION) ||
|
|
|
|
(portstatus & USB_PORT_STAT_OVERCURRENT))
|
2008-04-28 23:06:42 +08:00
|
|
|
set_bit(port1, hub->change_bits);
|
|
|
|
|
|
|
|
} else if (portstatus & USB_PORT_STAT_ENABLE) {
|
USB: Set wakeup bits for all children hubs.
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-01-25 03:46:50 +08:00
|
|
|
bool port_resumed = (portstatus &
|
|
|
|
USB_PORT_STAT_LINK_STATE) ==
|
|
|
|
USB_SS_PORT_LS_U0;
|
2008-04-28 23:06:42 +08:00
|
|
|
/* The power session apparently survived the resume.
|
|
|
|
* If there was an overcurrent or suspend change
|
2014-09-19 23:32:23 +08:00
|
|
|
* (i.e., remote wakeup request), have hub_wq
|
USB: Set wakeup bits for all children hubs.
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-01-25 03:46:50 +08:00
|
|
|
* take care of it. Look at the port link state
|
|
|
|
* for USB 3.0 hubs, since they don't have a suspend
|
|
|
|
* change bit, and they don't set the port link change
|
|
|
|
* bit on device-initiated resume.
|
2008-04-28 23:06:42 +08:00
|
|
|
*/
|
USB: Set wakeup bits for all children hubs.
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-01-25 03:46:50 +08:00
|
|
|
if (portchange || (hub_is_superspeed(hub->hdev) &&
|
|
|
|
port_resumed))
|
2008-04-28 23:06:42 +08:00
|
|
|
set_bit(port1, hub->change_bits);
|
2008-03-04 04:15:51 +08:00
|
|
|
|
2008-04-28 23:06:42 +08:00
|
|
|
} else if (udev->persist_enabled) {
|
|
|
|
#ifdef CONFIG_PM
|
2008-03-04 04:15:51 +08:00
|
|
|
udev->reset_resume = 1;
|
2008-04-28 23:06:42 +08:00
|
|
|
#endif
|
2013-01-23 04:26:30 +08:00
|
|
|
/* Don't set the change_bits when the device
|
|
|
|
* was powered off.
|
|
|
|
*/
|
2014-05-21 09:08:52 +08:00
|
|
|
if (test_bit(port1, hub->power_bits))
|
2013-01-23 04:26:30 +08:00
|
|
|
set_bit(port1, hub->change_bits);
|
2008-04-28 23:06:55 +08:00
|
|
|
|
2008-04-28 23:06:42 +08:00
|
|
|
} else {
|
2014-09-19 23:32:23 +08:00
|
|
|
/* The power session is gone; tell hub_wq */
|
2008-04-28 23:06:42 +08:00
|
|
|
usb_set_device_state(udev, USB_STATE_NOTATTACHED);
|
|
|
|
set_bit(port1, hub->change_bits);
|
2008-03-04 04:15:51 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-04-28 23:07:07 +08:00
|
|
|
/* If no port-status-change flags were set, we don't need any
|
|
|
|
* debouncing. If flags were set we can try to debounce the
|
2014-09-19 23:32:23 +08:00
|
|
|
* ports all at once right now, instead of letting hub_wq do them
|
2008-04-28 23:07:07 +08:00
|
|
|
* one at a time later on.
|
|
|
|
*
|
2014-09-19 23:32:23 +08:00
|
|
|
* If any port-status changes do occur during this delay, hub_wq
|
2008-04-28 23:07:07 +08:00
|
|
|
* will see them later and handle them normally.
|
|
|
|
*/
|
2008-09-23 02:44:26 +08:00
|
|
|
if (need_debounce_delay) {
|
|
|
|
delay = HUB_DEBOUNCE_STABLE;
|
|
|
|
|
|
|
|
/* Don't do a long sleep inside a workqueue routine */
|
|
|
|
if (type == HUB_INIT2) {
|
2014-03-07 23:24:48 +08:00
|
|
|
INIT_DELAYED_WORK(&hub->init_work, hub_init_func3);
|
2014-02-02 11:16:46 +08:00
|
|
|
queue_delayed_work(system_power_efficient_wq,
|
|
|
|
&hub->init_work,
|
2008-09-23 02:44:26 +08:00
|
|
|
msecs_to_jiffies(delay));
|
2015-12-17 02:32:38 +08:00
|
|
|
device_unlock(hub->intfdev);
|
2008-09-23 02:44:26 +08:00
|
|
|
return; /* Continues at init3: below */
|
|
|
|
} else {
|
|
|
|
msleep(delay);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
init3:
|
2008-04-28 23:07:17 +08:00
|
|
|
hub->quiescing = 0;
|
|
|
|
|
|
|
|
status = usb_submit_urb(hub->urb, GFP_NOIO);
|
|
|
|
if (status < 0)
|
|
|
|
dev_err(hub->intfdev, "activate --> %d\n", status);
|
|
|
|
if (hub->has_indicators && blinkenlights)
|
2014-02-02 11:16:46 +08:00
|
|
|
queue_delayed_work(system_power_efficient_wq,
|
|
|
|
&hub->leds, LED_CYCLE_PERIOD);
|
2008-04-28 23:07:17 +08:00
|
|
|
|
|
|
|
/* Scan all ports that need attention */
|
2014-09-19 23:32:21 +08:00
|
|
|
kick_hub_wq(hub);
|
2009-12-08 02:01:37 +08:00
|
|
|
|
2016-08-05 23:49:45 +08:00
|
|
|
if (type == HUB_INIT2 || type == HUB_INIT3) {
|
|
|
|
/* Allow autosuspend if it was suppressed */
|
|
|
|
disconnected:
|
2009-12-08 02:01:37 +08:00
|
|
|
usb_autopm_put_interface_async(to_usb_interface(hub->intfdev));
|
2015-12-17 02:32:38 +08:00
|
|
|
device_unlock(hub->intfdev);
|
2016-08-05 23:49:45 +08:00
|
|
|
}
|
2015-12-17 02:32:38 +08:00
|
|
|
|
|
|
|
kref_put(&hub->kref, hub_release);
|
2008-03-04 04:15:51 +08:00
|
|
|
}
|
|
|
|
|
2008-09-23 02:44:26 +08:00
|
|
|
/* Implement the continuations for the delays above */
|
|
|
|
static void hub_init_func2(struct work_struct *ws)
|
|
|
|
{
|
|
|
|
struct usb_hub *hub = container_of(ws, struct usb_hub, init_work.work);
|
|
|
|
|
|
|
|
hub_activate(hub, HUB_INIT2);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void hub_init_func3(struct work_struct *ws)
|
|
|
|
{
|
|
|
|
struct usb_hub *hub = container_of(ws, struct usb_hub, init_work.work);
|
|
|
|
|
|
|
|
hub_activate(hub, HUB_INIT3);
|
|
|
|
}
|
|
|
|
|
2008-04-28 23:07:31 +08:00
|
|
|
enum hub_quiescing_type {
|
|
|
|
HUB_DISCONNECT, HUB_PRE_RESET, HUB_SUSPEND
|
|
|
|
};
|
|
|
|
|
|
|
|
static void hub_quiesce(struct usb_hub *hub, enum hub_quiescing_type type)
|
|
|
|
{
|
|
|
|
struct usb_device *hdev = hub->hdev;
|
|
|
|
int i;
|
|
|
|
|
2014-09-19 23:32:23 +08:00
|
|
|
/* hub_wq and related activity won't re-trigger */
|
2008-04-28 23:07:31 +08:00
|
|
|
hub->quiescing = 1;
|
|
|
|
|
|
|
|
if (type != HUB_SUSPEND) {
|
|
|
|
/* Disconnect all the children */
|
|
|
|
for (i = 0; i < hdev->maxchild; ++i) {
|
2012-09-05 13:44:32 +08:00
|
|
|
if (hub->ports[i]->child)
|
|
|
|
usb_disconnect(&hub->ports[i]->child);
|
2008-04-28 23:07:31 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-09-19 23:32:23 +08:00
|
|
|
/* Stop hub_wq and related activity */
|
2008-04-28 23:07:31 +08:00
|
|
|
usb_kill_urb(hub->urb);
|
|
|
|
if (hub->has_indicators)
|
|
|
|
cancel_delayed_work_sync(&hub->leds);
|
|
|
|
if (hub->tt.hub)
|
2012-10-23 16:33:12 +08:00
|
|
|
flush_work(&hub->tt.clear_work);
|
2008-04-28 23:07:31 +08:00
|
|
|
}
|
|
|
|
|
2014-05-21 09:08:07 +08:00
|
|
|
static void hub_pm_barrier_for_all_ports(struct usb_hub *hub)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < hub->hdev->maxchild; ++i)
|
|
|
|
pm_runtime_barrier(&hub->ports[i]->dev);
|
|
|
|
}
|
|
|
|
|
2008-03-04 04:15:43 +08:00
|
|
|
/* caller has locked the hub device */
|
|
|
|
static int hub_pre_reset(struct usb_interface *intf)
|
|
|
|
{
|
|
|
|
struct usb_hub *hub = usb_get_intfdata(intf);
|
|
|
|
|
2008-04-28 23:07:31 +08:00
|
|
|
hub_quiesce(hub, HUB_PRE_RESET);
|
2014-05-21 09:08:07 +08:00
|
|
|
hub->in_reset = 1;
|
|
|
|
hub_pm_barrier_for_all_ports(hub);
|
2007-05-31 03:38:16 +08:00
|
|
|
return 0;
|
2005-11-19 01:06:34 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* caller has locked the hub device */
|
2007-05-31 03:38:16 +08:00
|
|
|
static int hub_post_reset(struct usb_interface *intf)
|
2005-11-19 01:06:34 +08:00
|
|
|
{
|
2006-06-02 01:37:24 +08:00
|
|
|
struct usb_hub *hub = usb_get_intfdata(intf);
|
|
|
|
|
2014-05-21 09:08:07 +08:00
|
|
|
hub->in_reset = 0;
|
|
|
|
hub_pm_barrier_for_all_ports(hub);
|
2008-04-28 23:07:17 +08:00
|
|
|
hub_activate(hub, HUB_POST_RESET);
|
2007-05-31 03:38:16 +08:00
|
|
|
return 0;
|
2005-11-19 01:06:34 +08:00
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
static int hub_configure(struct usb_hub *hub,
|
|
|
|
struct usb_endpoint_descriptor *endpoint)
|
|
|
|
{
|
2009-09-05 01:53:24 +08:00
|
|
|
struct usb_hcd *hcd;
|
2005-04-17 06:20:36 +08:00
|
|
|
struct usb_device *hdev = hub->hdev;
|
|
|
|
struct device *hub_dev = hub->intfdev;
|
|
|
|
u16 hubstatus, hubchange;
|
2005-06-21 12:15:16 +08:00
|
|
|
u16 wHubCharacteristics;
|
2005-04-17 06:20:36 +08:00
|
|
|
unsigned int pipe;
|
2012-09-05 13:44:31 +08:00
|
|
|
int maxp, ret, i;
|
2009-06-29 22:56:54 +08:00
|
|
|
char *message = "out of memory";
|
2012-12-18 22:25:47 +08:00
|
|
|
unsigned unit_load;
|
|
|
|
unsigned full_load;
|
2014-05-21 09:08:28 +08:00
|
|
|
unsigned maxchild;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2009-10-28 03:18:46 +08:00
|
|
|
hub->buffer = kmalloc(sizeof(*hub->buffer), GFP_KERNEL);
|
2005-04-17 06:20:36 +08:00
|
|
|
if (!hub->buffer) {
|
|
|
|
ret = -ENOMEM;
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
|
|
|
hub->status = kmalloc(sizeof(*hub->status), GFP_KERNEL);
|
|
|
|
if (!hub->status) {
|
|
|
|
ret = -ENOMEM;
|
|
|
|
goto fail;
|
|
|
|
}
|
2007-02-05 22:56:15 +08:00
|
|
|
mutex_init(&hub->status_mutex);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
hub->descriptor = kmalloc(sizeof(*hub->descriptor), GFP_KERNEL);
|
|
|
|
if (!hub->descriptor) {
|
|
|
|
ret = -ENOMEM;
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Request the entire hub descriptor.
|
|
|
|
* hub->descriptor can handle USB_MAXCHILDREN ports,
|
|
|
|
* but the hub can/will return fewer bytes here.
|
|
|
|
*/
|
2001-09-17 15:00:00 +08:00
|
|
|
ret = get_hub_descriptor(hdev, hub->descriptor);
|
2005-04-17 06:20:36 +08:00
|
|
|
if (ret < 0) {
|
|
|
|
message = "can't read hub descriptor";
|
|
|
|
goto fail;
|
|
|
|
} else if (hub->descriptor->bNbrPorts > USB_MAXCHILDREN) {
|
|
|
|
message = "hub has too many ports!";
|
|
|
|
ret = -ENODEV;
|
|
|
|
goto fail;
|
2013-03-25 18:50:27 +08:00
|
|
|
} else if (hub->descriptor->bNbrPorts == 0) {
|
|
|
|
message = "hub doesn't have any ports!";
|
|
|
|
ret = -ENODEV;
|
|
|
|
goto fail;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2014-05-21 09:08:28 +08:00
|
|
|
maxchild = hub->descriptor->bNbrPorts;
|
|
|
|
dev_info(hub_dev, "%d port%s detected\n", maxchild,
|
|
|
|
(maxchild == 1) ? "" : "s");
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2014-05-21 09:08:28 +08:00
|
|
|
hub->ports = kzalloc(maxchild * sizeof(struct usb_port *), GFP_KERNEL);
|
2012-09-05 13:44:32 +08:00
|
|
|
if (!hub->ports) {
|
2009-06-29 22:56:54 +08:00
|
|
|
ret = -ENOMEM;
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
2005-06-21 12:15:16 +08:00
|
|
|
wHubCharacteristics = le16_to_cpu(hub->descriptor->wHubCharacteristics);
|
2012-12-18 22:25:47 +08:00
|
|
|
if (hub_is_superspeed(hdev)) {
|
|
|
|
unit_load = 150;
|
|
|
|
full_load = 900;
|
|
|
|
} else {
|
|
|
|
unit_load = 100;
|
|
|
|
full_load = 500;
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2001-09-17 15:00:00 +08:00
|
|
|
/* FIXME for USB 3.0, skip for now */
|
|
|
|
if ((wHubCharacteristics & HUB_CHAR_COMPOUND) &&
|
|
|
|
!(hub_is_superspeed(hdev))) {
|
2013-10-11 05:41:27 +08:00
|
|
|
char portstr[USB_MAXCHILDREN + 1];
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2014-05-21 09:08:28 +08:00
|
|
|
for (i = 0; i < maxchild; i++)
|
2001-09-17 15:00:00 +08:00
|
|
|
portstr[i] = hub->descriptor->u.hs.DeviceRemovable
|
2005-04-17 06:20:36 +08:00
|
|
|
[((i + 1) / 8)] & (1 << ((i + 1) % 8))
|
|
|
|
? 'F' : 'R';
|
2014-05-21 09:08:28 +08:00
|
|
|
portstr[maxchild] = 0;
|
2005-04-17 06:20:36 +08:00
|
|
|
dev_dbg(hub_dev, "compound device; port removable status: %s\n", portstr);
|
|
|
|
} else
|
|
|
|
dev_dbg(hub_dev, "standalone hub\n");
|
|
|
|
|
2005-06-21 12:15:16 +08:00
|
|
|
switch (wHubCharacteristics & HUB_CHAR_LPSM) {
|
2011-12-08 14:35:22 +08:00
|
|
|
case HUB_CHAR_COMMON_LPSM:
|
|
|
|
dev_dbg(hub_dev, "ganged power switching\n");
|
|
|
|
break;
|
|
|
|
case HUB_CHAR_INDV_PORT_LPSM:
|
|
|
|
dev_dbg(hub_dev, "individual port power switching\n");
|
|
|
|
break;
|
|
|
|
case HUB_CHAR_NO_LPSM:
|
|
|
|
case HUB_CHAR_LPSM:
|
|
|
|
dev_dbg(hub_dev, "no power switching (usb 1.0)\n");
|
|
|
|
break;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2005-06-21 12:15:16 +08:00
|
|
|
switch (wHubCharacteristics & HUB_CHAR_OCPM) {
|
2011-12-08 14:35:22 +08:00
|
|
|
case HUB_CHAR_COMMON_OCPM:
|
|
|
|
dev_dbg(hub_dev, "global over-current protection\n");
|
|
|
|
break;
|
|
|
|
case HUB_CHAR_INDV_PORT_OCPM:
|
|
|
|
dev_dbg(hub_dev, "individual port over-current protection\n");
|
|
|
|
break;
|
|
|
|
case HUB_CHAR_NO_OCPM:
|
|
|
|
case HUB_CHAR_OCPM:
|
|
|
|
dev_dbg(hub_dev, "no over-current protection\n");
|
|
|
|
break;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2015-08-12 12:34:37 +08:00
|
|
|
spin_lock_init(&hub->tt.lock);
|
|
|
|
INIT_LIST_HEAD(&hub->tt.clear_list);
|
2009-06-29 22:43:32 +08:00
|
|
|
INIT_WORK(&hub->tt.clear_work, hub_tt_work);
|
2005-04-17 06:20:36 +08:00
|
|
|
switch (hdev->descriptor.bDeviceProtocol) {
|
2011-12-08 14:35:22 +08:00
|
|
|
case USB_HUB_PR_FS:
|
|
|
|
break;
|
|
|
|
case USB_HUB_PR_HS_SINGLE_TT:
|
|
|
|
dev_dbg(hub_dev, "Single TT\n");
|
|
|
|
hub->tt.hub = hdev;
|
|
|
|
break;
|
|
|
|
case USB_HUB_PR_HS_MULTI_TT:
|
|
|
|
ret = usb_set_interface(hdev, 0, 1);
|
|
|
|
if (ret == 0) {
|
|
|
|
dev_dbg(hub_dev, "TT per port\n");
|
|
|
|
hub->tt.multi = 1;
|
|
|
|
} else
|
|
|
|
dev_err(hub_dev, "Using single TT (err %d)\n",
|
|
|
|
ret);
|
|
|
|
hub->tt.hub = hdev;
|
|
|
|
break;
|
|
|
|
case USB_HUB_PR_SS:
|
|
|
|
/* USB 3.0 hubs don't have a TT */
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
dev_dbg(hub_dev, "Unrecognized hub protocol %d\n",
|
|
|
|
hdev->descriptor.bDeviceProtocol);
|
|
|
|
break;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2005-08-14 09:41:04 +08:00
|
|
|
/* Note 8 FS bit times == (8 bits / 12000000 bps) ~= 666ns */
|
2005-06-21 12:15:16 +08:00
|
|
|
switch (wHubCharacteristics & HUB_CHAR_TTTT) {
|
2013-10-11 05:41:27 +08:00
|
|
|
case HUB_TTTT_8_BITS:
|
|
|
|
if (hdev->descriptor.bDeviceProtocol != 0) {
|
|
|
|
hub->tt.think_time = 666;
|
2005-08-14 09:41:04 +08:00
|
|
|
dev_dbg(hub_dev, "TT requires at most %d "
|
|
|
|
"FS bit times (%d ns)\n",
|
2013-10-11 05:41:27 +08:00
|
|
|
8, hub->tt.think_time);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case HUB_TTTT_16_BITS:
|
|
|
|
hub->tt.think_time = 666 * 2;
|
|
|
|
dev_dbg(hub_dev, "TT requires at most %d "
|
|
|
|
"FS bit times (%d ns)\n",
|
|
|
|
16, hub->tt.think_time);
|
|
|
|
break;
|
|
|
|
case HUB_TTTT_24_BITS:
|
|
|
|
hub->tt.think_time = 666 * 3;
|
|
|
|
dev_dbg(hub_dev, "TT requires at most %d "
|
|
|
|
"FS bit times (%d ns)\n",
|
|
|
|
24, hub->tt.think_time);
|
|
|
|
break;
|
|
|
|
case HUB_TTTT_32_BITS:
|
|
|
|
hub->tt.think_time = 666 * 4;
|
|
|
|
dev_dbg(hub_dev, "TT requires at most %d "
|
|
|
|
"FS bit times (%d ns)\n",
|
|
|
|
32, hub->tt.think_time);
|
|
|
|
break;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* probe() zeroes hub->indicator[] */
|
2005-06-21 12:15:16 +08:00
|
|
|
if (wHubCharacteristics & HUB_CHAR_PORTIND) {
|
2005-04-17 06:20:36 +08:00
|
|
|
hub->has_indicators = 1;
|
|
|
|
dev_dbg(hub_dev, "Port indicators are supported\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
dev_dbg(hub_dev, "power on to power good time: %dms\n",
|
|
|
|
hub->descriptor->bPwrOn2PwrGood * 2);
|
|
|
|
|
|
|
|
/* power budgeting mostly matters with bus-powered hubs,
|
|
|
|
* and battery-powered root hubs (may provide just 8 mA).
|
|
|
|
*/
|
|
|
|
ret = usb_get_status(hdev, USB_RECIP_DEVICE, 0, &hubstatus);
|
2013-07-31 03:35:40 +08:00
|
|
|
if (ret) {
|
2005-04-17 06:20:36 +08:00
|
|
|
message = "can't get hub status";
|
|
|
|
goto fail;
|
|
|
|
}
|
2012-12-18 22:25:47 +08:00
|
|
|
hcd = bus_to_hcd(hdev->bus);
|
2005-04-25 23:18:32 +08:00
|
|
|
if (hdev == hdev->bus->root_hub) {
|
2012-12-18 22:25:47 +08:00
|
|
|
if (hcd->power_budget > 0)
|
|
|
|
hdev->bus_mA = hcd->power_budget;
|
|
|
|
else
|
2014-05-21 09:08:28 +08:00
|
|
|
hdev->bus_mA = full_load * maxchild;
|
2012-12-18 22:25:47 +08:00
|
|
|
if (hdev->bus_mA >= full_load)
|
|
|
|
hub->mA_per_port = full_load;
|
2005-11-24 01:03:12 +08:00
|
|
|
else {
|
|
|
|
hub->mA_per_port = hdev->bus_mA;
|
|
|
|
hub->limited_power = 1;
|
|
|
|
}
|
2005-04-25 23:18:32 +08:00
|
|
|
} else if ((hubstatus & (1 << USB_DEVICE_SELF_POWERED)) == 0) {
|
2012-12-18 22:25:47 +08:00
|
|
|
int remaining = hdev->bus_mA -
|
|
|
|
hub->descriptor->bHubContrCurrent;
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
dev_dbg(hub_dev, "hub controller current requirement: %dmA\n",
|
|
|
|
hub->descriptor->bHubContrCurrent);
|
2005-11-24 01:03:12 +08:00
|
|
|
hub->limited_power = 1;
|
|
|
|
|
2014-05-21 09:08:28 +08:00
|
|
|
if (remaining < maxchild * unit_load)
|
2012-12-18 22:25:47 +08:00
|
|
|
dev_warn(hub_dev,
|
2005-11-24 01:03:12 +08:00
|
|
|
"insufficient power available "
|
|
|
|
"to use all downstream ports\n");
|
2012-12-18 22:25:47 +08:00
|
|
|
hub->mA_per_port = unit_load; /* 7.2.1 */
|
|
|
|
|
2005-11-24 01:03:12 +08:00
|
|
|
} else { /* Self-powered external hub */
|
|
|
|
/* FIXME: What about battery-powered external hubs that
|
|
|
|
* provide less current per port? */
|
2012-12-18 22:25:47 +08:00
|
|
|
hub->mA_per_port = full_load;
|
2005-04-25 23:18:32 +08:00
|
|
|
}
|
2012-12-18 22:25:47 +08:00
|
|
|
if (hub->mA_per_port < full_load)
|
2005-11-24 01:03:12 +08:00
|
|
|
dev_dbg(hub_dev, "%umA bus power budget for each child\n",
|
|
|
|
hub->mA_per_port);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
ret = hub_hub_status(hub, &hubstatus, &hubchange);
|
|
|
|
if (ret < 0) {
|
|
|
|
message = "can't get hub status";
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* local power status reports aren't always correct */
|
|
|
|
if (hdev->actconfig->desc.bmAttributes & USB_CONFIG_ATT_SELFPOWER)
|
|
|
|
dev_dbg(hub_dev, "local power source is %s\n",
|
|
|
|
(hubstatus & HUB_STATUS_LOCAL_POWER)
|
|
|
|
? "lost (inactive)" : "good");
|
|
|
|
|
2005-06-21 12:15:16 +08:00
|
|
|
if ((wHubCharacteristics & HUB_CHAR_OCPM) == 0)
|
2005-04-17 06:20:36 +08:00
|
|
|
dev_dbg(hub_dev, "%sover-current condition exists\n",
|
|
|
|
(hubstatus & HUB_STATUS_OVERCURRENT) ? "" : "no ");
|
|
|
|
|
2006-10-12 11:05:59 +08:00
|
|
|
/* set up the interrupt endpoint
|
|
|
|
* We use the EP's maxpacket size instead of (PORTS+1+7)/8
|
|
|
|
* bytes as USB2.0[11.12.3] says because some hubs are known
|
|
|
|
* to send more data (and thus cause overflow). For root hubs,
|
|
|
|
* maxpktsize is defined in hcd.c's fake endpoint descriptors
|
|
|
|
* to be big enough for at least USB_MAXCHILDREN ports. */
|
2005-04-17 06:20:36 +08:00
|
|
|
pipe = usb_rcvintpipe(hdev, endpoint->bEndpointAddress);
|
|
|
|
maxp = usb_maxpacket(hdev, pipe, usb_pipeout(pipe));
|
|
|
|
|
|
|
|
if (maxp > sizeof(*hub->buffer))
|
|
|
|
maxp = sizeof(*hub->buffer);
|
|
|
|
|
|
|
|
hub->urb = usb_alloc_urb(0, GFP_KERNEL);
|
|
|
|
if (!hub->urb) {
|
|
|
|
ret = -ENOMEM;
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
|
|
|
usb_fill_int_urb(hub->urb, hdev, pipe, *hub->buffer, maxp, hub_irq,
|
|
|
|
hub, endpoint->bInterval);
|
|
|
|
|
|
|
|
/* maybe cycle the hub leds */
|
|
|
|
if (hub->has_indicators && blinkenlights)
|
2013-10-11 05:41:27 +08:00
|
|
|
hub->indicator[0] = INDICATOR_CYCLE;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2014-05-21 09:08:28 +08:00
|
|
|
mutex_lock(&usb_port_peer_mutex);
|
|
|
|
for (i = 0; i < maxchild; i++) {
|
2013-08-22 20:49:39 +08:00
|
|
|
ret = usb_hub_create_port_device(hub, i + 1);
|
|
|
|
if (ret < 0) {
|
2012-09-05 13:44:31 +08:00
|
|
|
dev_err(hub->intfdev,
|
|
|
|
"couldn't create port%d device.\n", i + 1);
|
2014-05-21 09:08:28 +08:00
|
|
|
break;
|
2013-08-22 20:49:39 +08:00
|
|
|
}
|
|
|
|
}
|
2014-05-21 09:08:28 +08:00
|
|
|
hdev->maxchild = i;
|
2014-06-18 07:16:32 +08:00
|
|
|
for (i = 0; i < hdev->maxchild; i++) {
|
|
|
|
struct usb_port *port_dev = hub->ports[i];
|
|
|
|
|
|
|
|
pm_runtime_put(&port_dev->dev);
|
|
|
|
}
|
|
|
|
|
2014-05-21 09:08:28 +08:00
|
|
|
mutex_unlock(&usb_port_peer_mutex);
|
|
|
|
if (ret < 0)
|
|
|
|
goto fail;
|
2012-09-05 13:44:31 +08:00
|
|
|
|
2014-09-19 23:32:23 +08:00
|
|
|
/* Update the HCD's internal representation of this hub before hub_wq
|
2014-06-06 05:23:04 +08:00
|
|
|
* starts getting port status changes for devices under the hub.
|
|
|
|
*/
|
|
|
|
if (hcd->driver->update_hub_device) {
|
|
|
|
ret = hcd->driver->update_hub_device(hcd, hdev,
|
|
|
|
&hub->tt, GFP_KERNEL);
|
|
|
|
if (ret < 0) {
|
|
|
|
message = "can't update HCD hub info";
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-01-21 22:18:00 +08:00
|
|
|
usb_hub_adjust_deviceremovable(hdev, hub->descriptor);
|
|
|
|
|
2008-04-28 23:07:17 +08:00
|
|
|
hub_activate(hub, HUB_INIT);
|
2005-04-17 06:20:36 +08:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
fail:
|
2015-08-12 12:34:37 +08:00
|
|
|
dev_err(hub_dev, "config failed, %s (err %d)\n",
|
2005-04-17 06:20:36 +08:00
|
|
|
message, ret);
|
|
|
|
/* hub_disconnect() frees urb and descriptor */
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2007-05-04 23:55:11 +08:00
|
|
|
static void hub_release(struct kref *kref)
|
|
|
|
{
|
|
|
|
struct usb_hub *hub = container_of(kref, struct usb_hub, kref);
|
|
|
|
|
2014-09-19 23:32:19 +08:00
|
|
|
usb_put_dev(hub->hdev);
|
2007-05-04 23:55:11 +08:00
|
|
|
usb_put_intf(to_usb_interface(hub->intfdev));
|
|
|
|
kfree(hub);
|
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
static unsigned highspeed_hubs;
|
|
|
|
|
|
|
|
static void hub_disconnect(struct usb_interface *intf)
|
|
|
|
{
|
2012-03-12 21:00:19 +08:00
|
|
|
struct usb_hub *hub = usb_get_intfdata(intf);
|
2012-05-15 00:20:37 +08:00
|
|
|
struct usb_device *hdev = interface_to_usbdev(intf);
|
2014-01-07 23:43:02 +08:00
|
|
|
int port1;
|
2012-09-05 13:44:31 +08:00
|
|
|
|
2014-09-19 23:32:21 +08:00
|
|
|
/*
|
|
|
|
* Stop adding new hub events. We do not want to block here and thus
|
|
|
|
* will not try to remove any pending work item.
|
|
|
|
*/
|
2007-05-04 23:55:11 +08:00
|
|
|
hub->disconnected = 1;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2006-06-02 01:37:24 +08:00
|
|
|
/* Disconnect all children and quiesce the hub */
|
|
|
|
hub->error = 0;
|
2008-04-28 23:07:31 +08:00
|
|
|
hub_quiesce(hub, HUB_DISCONNECT);
|
2006-06-02 01:37:24 +08:00
|
|
|
|
2014-05-21 09:08:28 +08:00
|
|
|
mutex_lock(&usb_port_peer_mutex);
|
|
|
|
|
2014-01-07 23:43:02 +08:00
|
|
|
/* Avoid races with recursively_mark_NOTATTACHED() */
|
|
|
|
spin_lock_irq(&device_state_lock);
|
|
|
|
port1 = hdev->maxchild;
|
|
|
|
hdev->maxchild = 0;
|
|
|
|
usb_set_intfdata(intf, NULL);
|
|
|
|
spin_unlock_irq(&device_state_lock);
|
2012-09-12 19:48:31 +08:00
|
|
|
|
2014-01-07 23:43:02 +08:00
|
|
|
for (; port1 > 0; --port1)
|
|
|
|
usb_hub_remove_port_device(hub, port1);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2014-05-21 09:08:28 +08:00
|
|
|
mutex_unlock(&usb_port_peer_mutex);
|
|
|
|
|
2007-05-04 23:55:11 +08:00
|
|
|
if (hub->hdev->speed == USB_SPEED_HIGH)
|
2005-04-17 06:20:36 +08:00
|
|
|
highspeed_hubs--;
|
|
|
|
|
|
|
|
usb_free_urb(hub->urb);
|
2012-09-05 13:44:31 +08:00
|
|
|
kfree(hub->ports);
|
2005-04-19 08:39:34 +08:00
|
|
|
kfree(hub->descriptor);
|
|
|
|
kfree(hub->status);
|
2009-10-28 03:18:46 +08:00
|
|
|
kfree(hub->buffer);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2013-01-23 04:26:29 +08:00
|
|
|
pm_suspend_ignore_children(&intf->dev, false);
|
2007-05-04 23:55:11 +08:00
|
|
|
kref_put(&hub->kref, hub_release);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static int hub_probe(struct usb_interface *intf, const struct usb_device_id *id)
|
|
|
|
{
|
|
|
|
struct usb_host_interface *desc;
|
|
|
|
struct usb_endpoint_descriptor *endpoint;
|
|
|
|
struct usb_device *hdev;
|
|
|
|
struct usb_hub *hub;
|
|
|
|
|
|
|
|
desc = intf->cur_altsetting;
|
|
|
|
hdev = interface_to_usbdev(intf);
|
|
|
|
|
2012-10-24 11:59:25 +08:00
|
|
|
/*
|
|
|
|
* Set default autosuspend delay as 0 to speedup bus suspend,
|
|
|
|
* based on the below considerations:
|
|
|
|
*
|
|
|
|
* - Unlike other drivers, the hub driver does not rely on the
|
|
|
|
* autosuspend delay to provide enough time to handle a wakeup
|
|
|
|
* event, and the submitted status URB is just to check future
|
|
|
|
* change on hub downstream ports, so it is safe to do it.
|
|
|
|
*
|
|
|
|
* - The patch might cause one or more auto supend/resume for
|
|
|
|
* below very rare devices when they are plugged into hub
|
|
|
|
* first time:
|
|
|
|
*
|
|
|
|
* devices having trouble initializing, and disconnect
|
|
|
|
* themselves from the bus and then reconnect a second
|
|
|
|
* or so later
|
|
|
|
*
|
|
|
|
* devices just for downloading firmware, and disconnects
|
|
|
|
* themselves after completing it
|
|
|
|
*
|
|
|
|
* For these quite rare devices, their drivers may change the
|
|
|
|
* autosuspend delay of their parent hub in the probe() to one
|
|
|
|
* appropriate value to avoid the subtle problem if someone
|
|
|
|
* does care it.
|
|
|
|
*
|
|
|
|
* - The patch may cause one or more auto suspend/resume on
|
|
|
|
* hub during running 'lsusb', but it is probably too
|
|
|
|
* infrequent to worry about.
|
|
|
|
*
|
|
|
|
* - Change autosuspend delay of hub can avoid unnecessary auto
|
|
|
|
* suspend timer for hub, also may decrease power consumption
|
|
|
|
* of USB bus.
|
2014-08-04 17:44:46 +08:00
|
|
|
*
|
|
|
|
* - If user has indicated to prevent autosuspend by passing
|
|
|
|
* usbcore.autosuspend = -1 then keep autosuspend disabled.
|
2012-10-24 11:59:25 +08:00
|
|
|
*/
|
2014-11-30 06:47:05 +08:00
|
|
|
#ifdef CONFIG_PM
|
2014-08-04 17:44:46 +08:00
|
|
|
if (hdev->dev.power.autosuspend_delay >= 0)
|
|
|
|
pm_runtime_set_autosuspend_delay(&hdev->dev, 0);
|
2014-08-28 07:55:29 +08:00
|
|
|
#endif
|
2012-10-24 11:59:25 +08:00
|
|
|
|
2014-05-23 22:45:54 +08:00
|
|
|
/*
|
|
|
|
* Hubs have proper suspend/resume support, except for root hubs
|
|
|
|
* where the controller driver doesn't have bus_suspend and
|
|
|
|
* bus_resume methods.
|
|
|
|
*/
|
|
|
|
if (hdev->parent) { /* normal device */
|
|
|
|
usb_enable_autosuspend(hdev);
|
|
|
|
} else { /* root hub */
|
|
|
|
const struct hc_driver *drv = bus_to_hcd(hdev->bus)->driver;
|
|
|
|
|
|
|
|
if (drv->bus_suspend && drv->bus_resume)
|
|
|
|
usb_enable_autosuspend(hdev);
|
|
|
|
}
|
2010-01-09 01:56:54 +08:00
|
|
|
|
2008-06-12 15:49:47 +08:00
|
|
|
if (hdev->level == MAX_TOPO_LEVEL) {
|
2008-12-15 15:32:01 +08:00
|
|
|
dev_err(&intf->dev,
|
|
|
|
"Unsupported bus topology: hub nested too deep\n");
|
2008-06-12 15:49:47 +08:00
|
|
|
return -E2BIG;
|
|
|
|
}
|
|
|
|
|
2006-04-03 02:18:09 +08:00
|
|
|
#ifdef CONFIG_USB_OTG_BLACKLIST_HUB
|
|
|
|
if (hdev->parent) {
|
|
|
|
dev_warn(&intf->dev, "ignoring external hub\n");
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/* Some hubs have a subclass of 1, which AFAICT according to the */
|
|
|
|
/* specs is not defined, but it works */
|
|
|
|
if ((desc->desc.bInterfaceSubClass != 0) &&
|
|
|
|
(desc->desc.bInterfaceSubClass != 1)) {
|
|
|
|
descriptor_error:
|
2015-08-12 12:34:37 +08:00
|
|
|
dev_err(&intf->dev, "bad descriptor, ignoring hub\n");
|
2005-04-17 06:20:36 +08:00
|
|
|
return -EIO;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Multiple endpoints? What kind of mutant ninja-hub is this? */
|
|
|
|
if (desc->desc.bNumEndpoints != 1)
|
|
|
|
goto descriptor_error;
|
|
|
|
|
|
|
|
endpoint = &desc->endpoint[0].desc;
|
|
|
|
|
2006-09-28 02:58:53 +08:00
|
|
|
/* If it's not an interrupt in endpoint, we'd better punt! */
|
|
|
|
if (!usb_endpoint_is_int_in(endpoint))
|
2005-04-17 06:20:36 +08:00
|
|
|
goto descriptor_error;
|
|
|
|
|
|
|
|
/* We found a hub */
|
2015-08-12 12:34:37 +08:00
|
|
|
dev_info(&intf->dev, "USB hub found\n");
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2005-10-25 03:38:24 +08:00
|
|
|
hub = kzalloc(sizeof(*hub), GFP_KERNEL);
|
2005-04-17 06:20:36 +08:00
|
|
|
if (!hub) {
|
2015-08-12 12:34:37 +08:00
|
|
|
dev_dbg(&intf->dev, "couldn't kmalloc hub struct\n");
|
2005-04-17 06:20:36 +08:00
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
|
2007-05-04 23:55:11 +08:00
|
|
|
kref_init(&hub->kref);
|
2005-04-17 06:20:36 +08:00
|
|
|
hub->intfdev = &intf->dev;
|
|
|
|
hub->hdev = hdev;
|
2006-11-22 22:57:56 +08:00
|
|
|
INIT_DELAYED_WORK(&hub->leds, led_work);
|
2008-09-23 02:44:26 +08:00
|
|
|
INIT_DELAYED_WORK(&hub->init_work, NULL);
|
2014-09-19 23:32:21 +08:00
|
|
|
INIT_WORK(&hub->events, hub_event);
|
2007-05-04 23:55:11 +08:00
|
|
|
usb_get_intf(intf);
|
2014-09-19 23:32:19 +08:00
|
|
|
usb_get_dev(hdev);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2015-08-12 12:34:37 +08:00
|
|
|
usb_set_intfdata(intf, hub);
|
2006-11-10 03:44:33 +08:00
|
|
|
intf->needs_remote_wakeup = 1;
|
2013-01-23 04:26:29 +08:00
|
|
|
pm_suspend_ignore_children(&intf->dev, true);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
if (hdev->speed == USB_SPEED_HIGH)
|
|
|
|
highspeed_hubs++;
|
|
|
|
|
USB: check port changes before hub runtime suspend for some bug device
The hub status endpoint has a long 'bInterval', which is 255ms
for FS/LS device and 256ms for HS device according to USB 2.0 spec,
so the device connection change may be reported later more than 255ms
via status pipe.
The connection change in hub may have been happened already on the
downstream ports, but no status URB completes when it is killed
in hub_suspend(auto), so the connection change may be missed by some
buggy hub devices, which won't generate remote wakeup signal after
their remote wakeup is enabled and they are put into suspend state.
The problem can be observed at least on the below Genesys Logic, Inc.
hub devices:
0x05e3,0x0606
0x05e3,0x0608
In theory, there is no way to fix the problem completely, but we
can make it less likely to occur by this patch.
This patch introduces one quirk of HUB_QUIRK_CHECK_PORTS_AUTOSUSPEND
to check ports' change during hub_suspend(auto) for the buggy
devices. If ports' change is found, terminate the auto suspend and
return to working state.
So for the buggy hubs, if the connection change happend before
the ports' check, it can be handled correctly. If it happens between
the ports' check and enabling remote wakeup/entering suspend, it
will be missed. Considered the interval is quite short, it is very
less likely to happen during the window.
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-24 11:59:24 +08:00
|
|
|
if (id->driver_info & HUB_QUIRK_CHECK_PORT_AUTOSUSPEND)
|
|
|
|
hub->quirk_check_port_auto_suspend = 1;
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
if (hub_configure(hub, endpoint) >= 0)
|
|
|
|
return 0;
|
|
|
|
|
2015-08-12 12:34:37 +08:00
|
|
|
hub_disconnect(intf);
|
2005-04-17 06:20:36 +08:00
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
hub_ioctl(struct usb_interface *intf, unsigned int code, void *user_data)
|
|
|
|
{
|
2015-08-12 12:34:37 +08:00
|
|
|
struct usb_device *hdev = interface_to_usbdev(intf);
|
2013-01-23 04:26:30 +08:00
|
|
|
struct usb_hub *hub = usb_hub_to_struct_hub(hdev);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/* assert ifno == 0 (part of hub spec) */
|
|
|
|
switch (code) {
|
|
|
|
case USBDEVFS_HUB_PORTINFO: {
|
|
|
|
struct usbdevfs_hub_portinfo *info = user_data;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
spin_lock_irq(&device_state_lock);
|
|
|
|
if (hdev->devnum <= 0)
|
|
|
|
info->nports = 0;
|
|
|
|
else {
|
|
|
|
info->nports = hdev->maxchild;
|
|
|
|
for (i = 0; i < info->nports; i++) {
|
2012-09-05 13:44:32 +08:00
|
|
|
if (hub->ports[i]->child == NULL)
|
2005-04-17 06:20:36 +08:00
|
|
|
info->port[i] = 0;
|
|
|
|
else
|
|
|
|
info->port[i] =
|
2012-09-05 13:44:32 +08:00
|
|
|
hub->ports[i]->child->devnum;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
spin_unlock_irq(&device_state_lock);
|
|
|
|
|
|
|
|
return info->nports + 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
default:
|
|
|
|
return -ENOSYS;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-06-29 22:56:54 +08:00
|
|
|
/*
|
|
|
|
* Allow user programs to claim ports on a hub. When a device is attached
|
|
|
|
* to one of these "claimed" ports, the program will "own" the device.
|
|
|
|
*/
|
|
|
|
static int find_port_owner(struct usb_device *hdev, unsigned port1,
|
2014-03-10 16:36:40 +08:00
|
|
|
struct usb_dev_state ***ppowner)
|
2009-06-29 22:56:54 +08:00
|
|
|
{
|
2013-06-18 22:28:48 +08:00
|
|
|
struct usb_hub *hub = usb_hub_to_struct_hub(hdev);
|
|
|
|
|
2009-06-29 22:56:54 +08:00
|
|
|
if (hdev->state == USB_STATE_NOTATTACHED)
|
|
|
|
return -ENODEV;
|
|
|
|
if (port1 == 0 || port1 > hdev->maxchild)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2013-06-18 22:28:48 +08:00
|
|
|
/* Devices not managed by the hub driver
|
2009-06-29 22:56:54 +08:00
|
|
|
* will always have maxchild equal to 0.
|
|
|
|
*/
|
2013-06-18 22:28:48 +08:00
|
|
|
*ppowner = &(hub->ports[port1 - 1]->port_owner);
|
2009-06-29 22:56:54 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* In the following three functions, the caller must hold hdev's lock */
|
2012-07-06 14:13:52 +08:00
|
|
|
int usb_hub_claim_port(struct usb_device *hdev, unsigned port1,
|
2014-03-10 16:36:40 +08:00
|
|
|
struct usb_dev_state *owner)
|
2009-06-29 22:56:54 +08:00
|
|
|
{
|
|
|
|
int rc;
|
2014-03-10 16:36:40 +08:00
|
|
|
struct usb_dev_state **powner;
|
2009-06-29 22:56:54 +08:00
|
|
|
|
|
|
|
rc = find_port_owner(hdev, port1, &powner);
|
|
|
|
if (rc)
|
|
|
|
return rc;
|
|
|
|
if (*powner)
|
|
|
|
return -EBUSY;
|
|
|
|
*powner = owner;
|
|
|
|
return rc;
|
|
|
|
}
|
2014-03-08 20:53:34 +08:00
|
|
|
EXPORT_SYMBOL_GPL(usb_hub_claim_port);
|
2009-06-29 22:56:54 +08:00
|
|
|
|
2012-07-06 14:13:52 +08:00
|
|
|
int usb_hub_release_port(struct usb_device *hdev, unsigned port1,
|
2014-03-10 16:36:40 +08:00
|
|
|
struct usb_dev_state *owner)
|
2009-06-29 22:56:54 +08:00
|
|
|
{
|
|
|
|
int rc;
|
2014-03-10 16:36:40 +08:00
|
|
|
struct usb_dev_state **powner;
|
2009-06-29 22:56:54 +08:00
|
|
|
|
|
|
|
rc = find_port_owner(hdev, port1, &powner);
|
|
|
|
if (rc)
|
|
|
|
return rc;
|
|
|
|
if (*powner != owner)
|
|
|
|
return -ENOENT;
|
|
|
|
*powner = NULL;
|
|
|
|
return rc;
|
|
|
|
}
|
2014-03-08 20:53:34 +08:00
|
|
|
EXPORT_SYMBOL_GPL(usb_hub_release_port);
|
2009-06-29 22:56:54 +08:00
|
|
|
|
2014-03-10 16:36:40 +08:00
|
|
|
void usb_hub_release_all_ports(struct usb_device *hdev, struct usb_dev_state *owner)
|
2009-06-29 22:56:54 +08:00
|
|
|
{
|
2013-01-23 04:26:30 +08:00
|
|
|
struct usb_hub *hub = usb_hub_to_struct_hub(hdev);
|
2009-06-29 22:56:54 +08:00
|
|
|
int n;
|
|
|
|
|
2012-09-05 13:44:31 +08:00
|
|
|
for (n = 0; n < hdev->maxchild; n++) {
|
|
|
|
if (hub->ports[n]->port_owner == owner)
|
|
|
|
hub->ports[n]->port_owner = NULL;
|
2009-06-29 22:56:54 +08:00
|
|
|
}
|
2012-09-05 13:44:31 +08:00
|
|
|
|
2009-06-29 22:56:54 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* The caller must hold udev's lock */
|
|
|
|
bool usb_device_is_owned(struct usb_device *udev)
|
|
|
|
{
|
|
|
|
struct usb_hub *hub;
|
|
|
|
|
|
|
|
if (udev->state == USB_STATE_NOTATTACHED || !udev->parent)
|
|
|
|
return false;
|
2013-01-23 04:26:30 +08:00
|
|
|
hub = usb_hub_to_struct_hub(udev->parent);
|
2012-09-05 13:44:31 +08:00
|
|
|
return !!hub->ports[udev->portnum - 1]->port_owner;
|
2009-06-29 22:56:54 +08:00
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
static void recursively_mark_NOTATTACHED(struct usb_device *udev)
|
|
|
|
{
|
2013-01-23 04:26:30 +08:00
|
|
|
struct usb_hub *hub = usb_hub_to_struct_hub(udev);
|
2005-04-17 06:20:36 +08:00
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < udev->maxchild; ++i) {
|
2012-09-05 13:44:32 +08:00
|
|
|
if (hub->ports[i]->child)
|
|
|
|
recursively_mark_NOTATTACHED(hub->ports[i]->child);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2010-01-09 01:57:28 +08:00
|
|
|
if (udev->state == USB_STATE_SUSPENDED)
|
2007-12-22 08:54:15 +08:00
|
|
|
udev->active_duration -= jiffies;
|
2005-04-17 06:20:36 +08:00
|
|
|
udev->state = USB_STATE_NOTATTACHED;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* usb_set_device_state - change a device's current state (usbcore, hcds)
|
|
|
|
* @udev: pointer to device whose state should be changed
|
|
|
|
* @new_state: new state value to be stored
|
|
|
|
*
|
|
|
|
* udev->state is _not_ fully protected by the device lock. Although
|
|
|
|
* most transitions are made only while holding the lock, the state can
|
|
|
|
* can change to USB_STATE_NOTATTACHED at almost any time. This
|
|
|
|
* is so that devices can be marked as disconnected as soon as possible,
|
|
|
|
* without having to wait for any semaphores to be released. As a result,
|
|
|
|
* all changes to any device's state must be protected by the
|
|
|
|
* device_state_lock spinlock.
|
|
|
|
*
|
|
|
|
* Once a device has been added to the device tree, all changes to its state
|
|
|
|
* should be made using this routine. The state should _not_ be set directly.
|
|
|
|
*
|
|
|
|
* If udev->state is already USB_STATE_NOTATTACHED then no change is made.
|
|
|
|
* Otherwise udev->state is set to new_state, and if new_state is
|
|
|
|
* USB_STATE_NOTATTACHED then all of udev's descendants' states are also set
|
|
|
|
* to USB_STATE_NOTATTACHED.
|
|
|
|
*/
|
|
|
|
void usb_set_device_state(struct usb_device *udev,
|
|
|
|
enum usb_device_state new_state)
|
|
|
|
{
|
|
|
|
unsigned long flags;
|
2011-02-09 06:25:48 +08:00
|
|
|
int wakeup = -1;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
spin_lock_irqsave(&device_state_lock, flags);
|
|
|
|
if (udev->state == USB_STATE_NOTATTACHED)
|
|
|
|
; /* do nothing */
|
2005-09-13 10:39:39 +08:00
|
|
|
else if (new_state != USB_STATE_NOTATTACHED) {
|
2006-01-25 00:40:27 +08:00
|
|
|
|
|
|
|
/* root hub wakeup capabilities are managed out-of-band
|
|
|
|
* and may involve silicon errata ... ignore them here.
|
|
|
|
*/
|
|
|
|
if (udev->parent) {
|
2006-08-31 03:47:02 +08:00
|
|
|
if (udev->state == USB_STATE_SUSPENDED
|
|
|
|
|| new_state == USB_STATE_SUSPENDED)
|
|
|
|
; /* No change to wakeup settings */
|
|
|
|
else if (new_state == USB_STATE_CONFIGURED)
|
2014-09-19 10:13:50 +08:00
|
|
|
wakeup = (udev->quirks &
|
|
|
|
USB_QUIRK_IGNORE_REMOTE_WAKEUP) ? 0 :
|
|
|
|
udev->actconfig->desc.bmAttributes &
|
|
|
|
USB_CONFIG_ATT_WAKEUP;
|
2006-08-31 03:47:02 +08:00
|
|
|
else
|
2011-02-09 06:25:48 +08:00
|
|
|
wakeup = 0;
|
2006-01-25 00:40:27 +08:00
|
|
|
}
|
2007-12-22 08:54:15 +08:00
|
|
|
if (udev->state == USB_STATE_SUSPENDED &&
|
|
|
|
new_state != USB_STATE_SUSPENDED)
|
|
|
|
udev->active_duration -= jiffies;
|
|
|
|
else if (new_state == USB_STATE_SUSPENDED &&
|
|
|
|
udev->state != USB_STATE_SUSPENDED)
|
|
|
|
udev->active_duration += jiffies;
|
2006-08-31 03:47:02 +08:00
|
|
|
udev->state = new_state;
|
2005-09-13 10:39:39 +08:00
|
|
|
} else
|
2005-04-17 06:20:36 +08:00
|
|
|
recursively_mark_NOTATTACHED(udev);
|
|
|
|
spin_unlock_irqrestore(&device_state_lock, flags);
|
2011-02-09 06:25:48 +08:00
|
|
|
if (wakeup >= 0)
|
|
|
|
device_set_wakeup_capable(&udev->dev, wakeup);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2009-02-18 22:43:47 +08:00
|
|
|
EXPORT_SYMBOL_GPL(usb_set_device_state);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2008-04-09 04:24:46 +08:00
|
|
|
/*
|
2011-02-22 22:53:41 +08:00
|
|
|
* Choose a device number.
|
|
|
|
*
|
|
|
|
* Device numbers are used as filenames in usbfs. On USB-1.1 and
|
|
|
|
* USB-2.0 buses they are also used as device addresses, however on
|
|
|
|
* USB-3.0 buses the address is assigned by the controller hardware
|
|
|
|
* and it usually is not the same as the device number.
|
|
|
|
*
|
2008-04-09 04:24:46 +08:00
|
|
|
* WUSB devices are simple: they have no hubs behind, so the mapping
|
|
|
|
* device <-> virtual port number becomes 1:1. Why? to simplify the
|
|
|
|
* life of the device connection logic in
|
|
|
|
* drivers/usb/wusbcore/devconnect.c. When we do the initial secret
|
|
|
|
* handshake we need to assign a temporary address in the unauthorized
|
|
|
|
* space. For simplicity we use the first virtual port number found to
|
|
|
|
* be free [drivers/usb/wusbcore/devconnect.c:wusbhc_devconnect_ack()]
|
|
|
|
* and that becomes it's address [X < 128] or its unauthorized address
|
|
|
|
* [X | 0x80].
|
|
|
|
*
|
|
|
|
* We add 1 as an offset to the one-based USB-stack port number
|
|
|
|
* (zero-based wusb virtual port index) for two reasons: (a) dev addr
|
|
|
|
* 0 is reserved by USB for default address; (b) Linux's USB stack
|
|
|
|
* uses always #1 for the root hub of the controller. So USB stack's
|
|
|
|
* port #1, which is wusb virtual-port #0 has address #2.
|
2009-04-28 10:57:26 +08:00
|
|
|
*
|
|
|
|
* Devices connected under xHCI are not as simple. The host controller
|
|
|
|
* supports virtualization, so the hardware assigns device addresses and
|
|
|
|
* the HCD must setup data structures before issuing a set address
|
|
|
|
* command to the hardware.
|
2008-04-09 04:24:46 +08:00
|
|
|
*/
|
2011-02-22 22:53:41 +08:00
|
|
|
static void choose_devnum(struct usb_device *udev)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
int devnum;
|
|
|
|
struct usb_bus *bus = udev->bus;
|
|
|
|
|
2014-09-19 23:32:24 +08:00
|
|
|
/* be safe when more hub events are proceed in parallel */
|
2016-04-25 20:48:38 +08:00
|
|
|
mutex_lock(&bus->devnum_next_mutex);
|
2008-04-09 04:24:46 +08:00
|
|
|
if (udev->wusb) {
|
|
|
|
devnum = udev->portnum + 1;
|
|
|
|
BUG_ON(test_bit(devnum, bus->devmap.devicemap));
|
|
|
|
} else {
|
|
|
|
/* Try to allocate the next devnum beginning at
|
|
|
|
* bus->devnum_next. */
|
|
|
|
devnum = find_next_zero_bit(bus->devmap.devicemap, 128,
|
|
|
|
bus->devnum_next);
|
|
|
|
if (devnum >= 128)
|
|
|
|
devnum = find_next_zero_bit(bus->devmap.devicemap,
|
|
|
|
128, 1);
|
2013-10-11 05:41:27 +08:00
|
|
|
bus->devnum_next = (devnum >= 127 ? 1 : devnum + 1);
|
2008-04-09 04:24:46 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
if (devnum < 128) {
|
|
|
|
set_bit(devnum, bus->devmap.devicemap);
|
|
|
|
udev->devnum = devnum;
|
|
|
|
}
|
2016-04-25 20:48:38 +08:00
|
|
|
mutex_unlock(&bus->devnum_next_mutex);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2011-02-22 22:53:41 +08:00
|
|
|
static void release_devnum(struct usb_device *udev)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
if (udev->devnum > 0) {
|
|
|
|
clear_bit(udev->devnum, udev->bus->devmap.devicemap);
|
|
|
|
udev->devnum = -1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-02-22 22:53:41 +08:00
|
|
|
static void update_devnum(struct usb_device *udev, int devnum)
|
2008-04-09 04:24:46 +08:00
|
|
|
{
|
|
|
|
/* The address for a WUSB device is managed by wusbcore. */
|
|
|
|
if (!udev->wusb)
|
|
|
|
udev->devnum = devnum;
|
|
|
|
}
|
|
|
|
|
2010-01-10 17:15:03 +08:00
|
|
|
static void hub_free_dev(struct usb_device *udev)
|
|
|
|
{
|
|
|
|
struct usb_hcd *hcd = bus_to_hcd(udev->bus);
|
|
|
|
|
|
|
|
/* Root hubs aren't real devices, so don't free HCD resources */
|
|
|
|
if (hcd->driver->free_dev && udev->parent)
|
|
|
|
hcd->driver->free_dev(hcd, udev);
|
|
|
|
}
|
|
|
|
|
usb: resume child device when port is powered on
Unconditionally wake up the child device when the power session is
recovered.
This addresses the following scenarios:
1/ The device may need a reset on power-session loss, without this
change port power-on recovery exposes khubd to scenarios that
usb_port_resume() is set to handle. Prior to port power control the
only time a power session would be lost is during dpm_suspend of the
hub. In that scenario usb_port_resume() is guaranteed to be called
prior to khubd running for that port. With this change we wakeup the
child device as soon as possible (prior to khubd running again for this
port).
Although khubd has facilities to wake a child device it will only do
so if the portstatus / portchange indicates a suspend state. In the
case of port power control we are not coming from a hub-port-suspend
state. This implementation simply uses pm_request_resume() to wake the
device and relies on the port_dev->status_lock to prevent any collisions
between khubd and usb_port_resume().
2/ This mechanism rate limits port power toggling. The minimum port
power on/off period is now gated by the child device suspend/resume
latency. Empirically this mitigates devices downgrading their connection
on perceived instability of the host connection. This ratelimiting is
really only relevant to port power control testing, but it is a nice
side effect of closing the above race. Namely, the race of khubd for
the given port running while a usb_port_resume() event is pending.
3/ Going forward we are finding that power-session recovery requires
warm-resets (http://marc.info/?t=138659232900003&r=1&w=2). This
mechanism allows for warm-resets to be requested at the same point in
the resume path for hub dpm_suspend power session losses, or port
rpm_suspend power session losses.
4/ If the device *was* disconnected the only time we'll know for sure is
after a failed resume, so it's necessary for usb_port_runtime_resume()
to expedite a usb_port_resume() to clean up the removed device. The
reasoning for this is "least surprise" for the user. Turning on a port
means that hotplug detection is again enabled for the port, it is
surprising that devices that were removed while the port was off are not
disconnected until they are attempted to be used. As a user "why would
I try to use a device I removed from the system?"
1, 2, and 4 are not a problem in the system dpm_resume() case because,
although the power-session is lost, khubd is frozen until after device
resume. For the rpm_resume() case pm_request_resume() is used to
request re-validation of the device, and if it happens to collide with a
khubd run we rely on the port_dev->status_lock to synchronize those
operations.
Besides testing, the primary scenario where this mechanism is expected
to be triggered is when the user changes the port power policy
(control/pm_qos_no_poweroff, or power/control). Each time power is
enabled want to revalidate the child device, where the revalidation is
handled by usb_port_resume().
Given that this arranges for port_dev->child to be de-referenced in
usb_port_runtime_resume() we need to make sure not to collide with
usb_disconnect() that frees the usb_device. To this end we hold the
port active with the "child_usage" reference across the disconnect
event. Subsequently, the need to access hub->child_usage_bits lead to
the creation of hub_disconnect_children() to remove any ambiguity of
which "hub" is being acted on in usb_disconnect() (prompted-by sharp
eyes from Alan).
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-21 09:09:36 +08:00
|
|
|
static void hub_disconnect_children(struct usb_device *udev)
|
|
|
|
{
|
|
|
|
struct usb_hub *hub = usb_hub_to_struct_hub(udev);
|
|
|
|
int i;
|
|
|
|
|
|
|
|
/* Free up all the children before we remove this device */
|
|
|
|
for (i = 0; i < udev->maxchild; i++) {
|
|
|
|
if (hub->ports[i]->child)
|
|
|
|
usb_disconnect(&hub->ports[i]->child);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/**
|
|
|
|
* usb_disconnect - disconnect a device (usbcore-internal)
|
|
|
|
* @pdev: pointer to device being disconnected
|
|
|
|
* Context: !in_interrupt ()
|
|
|
|
*
|
|
|
|
* Something got disconnected. Get rid of it and all of its children.
|
|
|
|
*
|
|
|
|
* If *pdev is a normal device then the parent hub must already be locked.
|
2016-02-04 06:35:23 +08:00
|
|
|
* If *pdev is a root hub then the caller must hold the usb_bus_idr_lock,
|
2013-09-14 03:57:34 +08:00
|
|
|
* which protects the set of root hubs as well as the list of buses.
|
2005-04-17 06:20:36 +08:00
|
|
|
*
|
|
|
|
* Only hub drivers (including virtual root hub drivers for host
|
|
|
|
* controllers) should ever call this.
|
|
|
|
*
|
|
|
|
* This call is synchronous, and may not be used in an interrupt context.
|
|
|
|
*/
|
|
|
|
void usb_disconnect(struct usb_device **pdev)
|
|
|
|
{
|
usb: resume child device when port is powered on
Unconditionally wake up the child device when the power session is
recovered.
This addresses the following scenarios:
1/ The device may need a reset on power-session loss, without this
change port power-on recovery exposes khubd to scenarios that
usb_port_resume() is set to handle. Prior to port power control the
only time a power session would be lost is during dpm_suspend of the
hub. In that scenario usb_port_resume() is guaranteed to be called
prior to khubd running for that port. With this change we wakeup the
child device as soon as possible (prior to khubd running again for this
port).
Although khubd has facilities to wake a child device it will only do
so if the portstatus / portchange indicates a suspend state. In the
case of port power control we are not coming from a hub-port-suspend
state. This implementation simply uses pm_request_resume() to wake the
device and relies on the port_dev->status_lock to prevent any collisions
between khubd and usb_port_resume().
2/ This mechanism rate limits port power toggling. The minimum port
power on/off period is now gated by the child device suspend/resume
latency. Empirically this mitigates devices downgrading their connection
on perceived instability of the host connection. This ratelimiting is
really only relevant to port power control testing, but it is a nice
side effect of closing the above race. Namely, the race of khubd for
the given port running while a usb_port_resume() event is pending.
3/ Going forward we are finding that power-session recovery requires
warm-resets (http://marc.info/?t=138659232900003&r=1&w=2). This
mechanism allows for warm-resets to be requested at the same point in
the resume path for hub dpm_suspend power session losses, or port
rpm_suspend power session losses.
4/ If the device *was* disconnected the only time we'll know for sure is
after a failed resume, so it's necessary for usb_port_runtime_resume()
to expedite a usb_port_resume() to clean up the removed device. The
reasoning for this is "least surprise" for the user. Turning on a port
means that hotplug detection is again enabled for the port, it is
surprising that devices that were removed while the port was off are not
disconnected until they are attempted to be used. As a user "why would
I try to use a device I removed from the system?"
1, 2, and 4 are not a problem in the system dpm_resume() case because,
although the power-session is lost, khubd is frozen until after device
resume. For the rpm_resume() case pm_request_resume() is used to
request re-validation of the device, and if it happens to collide with a
khubd run we rely on the port_dev->status_lock to synchronize those
operations.
Besides testing, the primary scenario where this mechanism is expected
to be triggered is when the user changes the port power policy
(control/pm_qos_no_poweroff, or power/control). Each time power is
enabled want to revalidate the child device, where the revalidation is
handled by usb_port_resume().
Given that this arranges for port_dev->child to be de-referenced in
usb_port_runtime_resume() we need to make sure not to collide with
usb_disconnect() that frees the usb_device. To this end we hold the
port active with the "child_usage" reference across the disconnect
event. Subsequently, the need to access hub->child_usage_bits lead to
the creation of hub_disconnect_children() to remove any ambiguity of
which "hub" is being acted on in usb_disconnect() (prompted-by sharp
eyes from Alan).
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-21 09:09:36 +08:00
|
|
|
struct usb_port *port_dev = NULL;
|
|
|
|
struct usb_device *udev = *pdev;
|
2014-08-19 08:56:21 +08:00
|
|
|
struct usb_hub *hub = NULL;
|
|
|
|
int port1 = 1;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/* mark the device as inactive, so any further urb submissions for
|
|
|
|
* this device (and any of its children) will fail immediately.
|
2011-03-31 09:57:33 +08:00
|
|
|
* this quiesces everything except pending urbs.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
|
|
|
usb_set_device_state(udev, USB_STATE_NOTATTACHED);
|
2011-02-22 22:53:41 +08:00
|
|
|
dev_info(&udev->dev, "USB disconnect, device number %d\n",
|
|
|
|
udev->devnum);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2005-11-18 06:10:32 +08:00
|
|
|
usb_lock_device(udev);
|
|
|
|
|
usb: resume child device when port is powered on
Unconditionally wake up the child device when the power session is
recovered.
This addresses the following scenarios:
1/ The device may need a reset on power-session loss, without this
change port power-on recovery exposes khubd to scenarios that
usb_port_resume() is set to handle. Prior to port power control the
only time a power session would be lost is during dpm_suspend of the
hub. In that scenario usb_port_resume() is guaranteed to be called
prior to khubd running for that port. With this change we wakeup the
child device as soon as possible (prior to khubd running again for this
port).
Although khubd has facilities to wake a child device it will only do
so if the portstatus / portchange indicates a suspend state. In the
case of port power control we are not coming from a hub-port-suspend
state. This implementation simply uses pm_request_resume() to wake the
device and relies on the port_dev->status_lock to prevent any collisions
between khubd and usb_port_resume().
2/ This mechanism rate limits port power toggling. The minimum port
power on/off period is now gated by the child device suspend/resume
latency. Empirically this mitigates devices downgrading their connection
on perceived instability of the host connection. This ratelimiting is
really only relevant to port power control testing, but it is a nice
side effect of closing the above race. Namely, the race of khubd for
the given port running while a usb_port_resume() event is pending.
3/ Going forward we are finding that power-session recovery requires
warm-resets (http://marc.info/?t=138659232900003&r=1&w=2). This
mechanism allows for warm-resets to be requested at the same point in
the resume path for hub dpm_suspend power session losses, or port
rpm_suspend power session losses.
4/ If the device *was* disconnected the only time we'll know for sure is
after a failed resume, so it's necessary for usb_port_runtime_resume()
to expedite a usb_port_resume() to clean up the removed device. The
reasoning for this is "least surprise" for the user. Turning on a port
means that hotplug detection is again enabled for the port, it is
surprising that devices that were removed while the port was off are not
disconnected until they are attempted to be used. As a user "why would
I try to use a device I removed from the system?"
1, 2, and 4 are not a problem in the system dpm_resume() case because,
although the power-session is lost, khubd is frozen until after device
resume. For the rpm_resume() case pm_request_resume() is used to
request re-validation of the device, and if it happens to collide with a
khubd run we rely on the port_dev->status_lock to synchronize those
operations.
Besides testing, the primary scenario where this mechanism is expected
to be triggered is when the user changes the port power policy
(control/pm_qos_no_poweroff, or power/control). Each time power is
enabled want to revalidate the child device, where the revalidation is
handled by usb_port_resume().
Given that this arranges for port_dev->child to be de-referenced in
usb_port_runtime_resume() we need to make sure not to collide with
usb_disconnect() that frees the usb_device. To this end we hold the
port active with the "child_usage" reference across the disconnect
event. Subsequently, the need to access hub->child_usage_bits lead to
the creation of hub_disconnect_children() to remove any ambiguity of
which "hub" is being acted on in usb_disconnect() (prompted-by sharp
eyes from Alan).
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-21 09:09:36 +08:00
|
|
|
hub_disconnect_children(udev);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/* deallocate hcd/hardware state ... nuking all pending urbs and
|
|
|
|
* cleaning up all state associated with the current configuration
|
|
|
|
* so that the hardware is now fully quiesced.
|
|
|
|
*/
|
2015-08-12 12:34:37 +08:00
|
|
|
dev_dbg(&udev->dev, "unregistering device\n");
|
2005-04-17 06:20:36 +08:00
|
|
|
usb_disable_device(udev, 0);
|
2008-10-22 03:28:46 +08:00
|
|
|
usb_hcd_synchronize_unlinks(udev);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2013-01-20 01:53:33 +08:00
|
|
|
if (udev->parent) {
|
usb: resume child device when port is powered on
Unconditionally wake up the child device when the power session is
recovered.
This addresses the following scenarios:
1/ The device may need a reset on power-session loss, without this
change port power-on recovery exposes khubd to scenarios that
usb_port_resume() is set to handle. Prior to port power control the
only time a power session would be lost is during dpm_suspend of the
hub. In that scenario usb_port_resume() is guaranteed to be called
prior to khubd running for that port. With this change we wakeup the
child device as soon as possible (prior to khubd running again for this
port).
Although khubd has facilities to wake a child device it will only do
so if the portstatus / portchange indicates a suspend state. In the
case of port power control we are not coming from a hub-port-suspend
state. This implementation simply uses pm_request_resume() to wake the
device and relies on the port_dev->status_lock to prevent any collisions
between khubd and usb_port_resume().
2/ This mechanism rate limits port power toggling. The minimum port
power on/off period is now gated by the child device suspend/resume
latency. Empirically this mitigates devices downgrading their connection
on perceived instability of the host connection. This ratelimiting is
really only relevant to port power control testing, but it is a nice
side effect of closing the above race. Namely, the race of khubd for
the given port running while a usb_port_resume() event is pending.
3/ Going forward we are finding that power-session recovery requires
warm-resets (http://marc.info/?t=138659232900003&r=1&w=2). This
mechanism allows for warm-resets to be requested at the same point in
the resume path for hub dpm_suspend power session losses, or port
rpm_suspend power session losses.
4/ If the device *was* disconnected the only time we'll know for sure is
after a failed resume, so it's necessary for usb_port_runtime_resume()
to expedite a usb_port_resume() to clean up the removed device. The
reasoning for this is "least surprise" for the user. Turning on a port
means that hotplug detection is again enabled for the port, it is
surprising that devices that were removed while the port was off are not
disconnected until they are attempted to be used. As a user "why would
I try to use a device I removed from the system?"
1, 2, and 4 are not a problem in the system dpm_resume() case because,
although the power-session is lost, khubd is frozen until after device
resume. For the rpm_resume() case pm_request_resume() is used to
request re-validation of the device, and if it happens to collide with a
khubd run we rely on the port_dev->status_lock to synchronize those
operations.
Besides testing, the primary scenario where this mechanism is expected
to be triggered is when the user changes the port power policy
(control/pm_qos_no_poweroff, or power/control). Each time power is
enabled want to revalidate the child device, where the revalidation is
handled by usb_port_resume().
Given that this arranges for port_dev->child to be de-referenced in
usb_port_runtime_resume() we need to make sure not to collide with
usb_disconnect() that frees the usb_device. To this end we hold the
port active with the "child_usage" reference across the disconnect
event. Subsequently, the need to access hub->child_usage_bits lead to
the creation of hub_disconnect_children() to remove any ambiguity of
which "hub" is being acted on in usb_disconnect() (prompted-by sharp
eyes from Alan).
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-21 09:09:36 +08:00
|
|
|
port1 = udev->portnum;
|
|
|
|
hub = usb_hub_to_struct_hub(udev->parent);
|
|
|
|
port_dev = hub->ports[port1 - 1];
|
2013-01-20 01:53:33 +08:00
|
|
|
|
|
|
|
sysfs_remove_link(&udev->dev.kobj, "port");
|
|
|
|
sysfs_remove_link(&port_dev->dev.kobj, "device");
|
2013-01-23 04:26:29 +08:00
|
|
|
|
usb: resume child device when port is powered on
Unconditionally wake up the child device when the power session is
recovered.
This addresses the following scenarios:
1/ The device may need a reset on power-session loss, without this
change port power-on recovery exposes khubd to scenarios that
usb_port_resume() is set to handle. Prior to port power control the
only time a power session would be lost is during dpm_suspend of the
hub. In that scenario usb_port_resume() is guaranteed to be called
prior to khubd running for that port. With this change we wakeup the
child device as soon as possible (prior to khubd running again for this
port).
Although khubd has facilities to wake a child device it will only do
so if the portstatus / portchange indicates a suspend state. In the
case of port power control we are not coming from a hub-port-suspend
state. This implementation simply uses pm_request_resume() to wake the
device and relies on the port_dev->status_lock to prevent any collisions
between khubd and usb_port_resume().
2/ This mechanism rate limits port power toggling. The minimum port
power on/off period is now gated by the child device suspend/resume
latency. Empirically this mitigates devices downgrading their connection
on perceived instability of the host connection. This ratelimiting is
really only relevant to port power control testing, but it is a nice
side effect of closing the above race. Namely, the race of khubd for
the given port running while a usb_port_resume() event is pending.
3/ Going forward we are finding that power-session recovery requires
warm-resets (http://marc.info/?t=138659232900003&r=1&w=2). This
mechanism allows for warm-resets to be requested at the same point in
the resume path for hub dpm_suspend power session losses, or port
rpm_suspend power session losses.
4/ If the device *was* disconnected the only time we'll know for sure is
after a failed resume, so it's necessary for usb_port_runtime_resume()
to expedite a usb_port_resume() to clean up the removed device. The
reasoning for this is "least surprise" for the user. Turning on a port
means that hotplug detection is again enabled for the port, it is
surprising that devices that were removed while the port was off are not
disconnected until they are attempted to be used. As a user "why would
I try to use a device I removed from the system?"
1, 2, and 4 are not a problem in the system dpm_resume() case because,
although the power-session is lost, khubd is frozen until after device
resume. For the rpm_resume() case pm_request_resume() is used to
request re-validation of the device, and if it happens to collide with a
khubd run we rely on the port_dev->status_lock to synchronize those
operations.
Besides testing, the primary scenario where this mechanism is expected
to be triggered is when the user changes the port power policy
(control/pm_qos_no_poweroff, or power/control). Each time power is
enabled want to revalidate the child device, where the revalidation is
handled by usb_port_resume().
Given that this arranges for port_dev->child to be de-referenced in
usb_port_runtime_resume() we need to make sure not to collide with
usb_disconnect() that frees the usb_device. To this end we hold the
port active with the "child_usage" reference across the disconnect
event. Subsequently, the need to access hub->child_usage_bits lead to
the creation of hub_disconnect_children() to remove any ambiguity of
which "hub" is being acted on in usb_disconnect() (prompted-by sharp
eyes from Alan).
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-21 09:09:36 +08:00
|
|
|
/*
|
|
|
|
* As usb_port_runtime_resume() de-references udev, make
|
|
|
|
* sure no resumes occur during removal
|
|
|
|
*/
|
|
|
|
if (!test_and_set_bit(port1, hub->child_usage_bits))
|
|
|
|
pm_runtime_get_sync(&port_dev->dev);
|
2013-01-20 01:53:33 +08:00
|
|
|
}
|
|
|
|
|
2008-12-06 03:10:34 +08:00
|
|
|
usb_remove_ep_devs(&udev->ep0);
|
2006-07-02 10:09:35 +08:00
|
|
|
usb_unlock_device(udev);
|
|
|
|
|
|
|
|
/* Unregister the device. The device driver is responsible
|
2008-12-06 03:10:34 +08:00
|
|
|
* for de-configuring the device and invoking the remove-device
|
|
|
|
* notifier chain (used by usbfs and possibly others).
|
2006-07-02 10:09:35 +08:00
|
|
|
*/
|
|
|
|
device_del(&udev->dev);
|
2005-06-21 12:15:16 +08:00
|
|
|
|
2006-07-02 10:09:35 +08:00
|
|
|
/* Free the device number and delete the parent's children[]
|
2005-04-17 06:20:36 +08:00
|
|
|
* (or root_hub) pointer.
|
|
|
|
*/
|
2011-02-22 22:53:41 +08:00
|
|
|
release_devnum(udev);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/* Avoid races with recursively_mark_NOTATTACHED() */
|
|
|
|
spin_lock_irq(&device_state_lock);
|
|
|
|
*pdev = NULL;
|
|
|
|
spin_unlock_irq(&device_state_lock);
|
|
|
|
|
usb: resume child device when port is powered on
Unconditionally wake up the child device when the power session is
recovered.
This addresses the following scenarios:
1/ The device may need a reset on power-session loss, without this
change port power-on recovery exposes khubd to scenarios that
usb_port_resume() is set to handle. Prior to port power control the
only time a power session would be lost is during dpm_suspend of the
hub. In that scenario usb_port_resume() is guaranteed to be called
prior to khubd running for that port. With this change we wakeup the
child device as soon as possible (prior to khubd running again for this
port).
Although khubd has facilities to wake a child device it will only do
so if the portstatus / portchange indicates a suspend state. In the
case of port power control we are not coming from a hub-port-suspend
state. This implementation simply uses pm_request_resume() to wake the
device and relies on the port_dev->status_lock to prevent any collisions
between khubd and usb_port_resume().
2/ This mechanism rate limits port power toggling. The minimum port
power on/off period is now gated by the child device suspend/resume
latency. Empirically this mitigates devices downgrading their connection
on perceived instability of the host connection. This ratelimiting is
really only relevant to port power control testing, but it is a nice
side effect of closing the above race. Namely, the race of khubd for
the given port running while a usb_port_resume() event is pending.
3/ Going forward we are finding that power-session recovery requires
warm-resets (http://marc.info/?t=138659232900003&r=1&w=2). This
mechanism allows for warm-resets to be requested at the same point in
the resume path for hub dpm_suspend power session losses, or port
rpm_suspend power session losses.
4/ If the device *was* disconnected the only time we'll know for sure is
after a failed resume, so it's necessary for usb_port_runtime_resume()
to expedite a usb_port_resume() to clean up the removed device. The
reasoning for this is "least surprise" for the user. Turning on a port
means that hotplug detection is again enabled for the port, it is
surprising that devices that were removed while the port was off are not
disconnected until they are attempted to be used. As a user "why would
I try to use a device I removed from the system?"
1, 2, and 4 are not a problem in the system dpm_resume() case because,
although the power-session is lost, khubd is frozen until after device
resume. For the rpm_resume() case pm_request_resume() is used to
request re-validation of the device, and if it happens to collide with a
khubd run we rely on the port_dev->status_lock to synchronize those
operations.
Besides testing, the primary scenario where this mechanism is expected
to be triggered is when the user changes the port power policy
(control/pm_qos_no_poweroff, or power/control). Each time power is
enabled want to revalidate the child device, where the revalidation is
handled by usb_port_resume().
Given that this arranges for port_dev->child to be de-referenced in
usb_port_runtime_resume() we need to make sure not to collide with
usb_disconnect() that frees the usb_device. To this end we hold the
port active with the "child_usage" reference across the disconnect
event. Subsequently, the need to access hub->child_usage_bits lead to
the creation of hub_disconnect_children() to remove any ambiguity of
which "hub" is being acted on in usb_disconnect() (prompted-by sharp
eyes from Alan).
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-21 09:09:36 +08:00
|
|
|
if (port_dev && test_and_clear_bit(port1, hub->child_usage_bits))
|
|
|
|
pm_runtime_put(&port_dev->dev);
|
|
|
|
|
2010-01-10 17:15:03 +08:00
|
|
|
hub_free_dev(udev);
|
|
|
|
|
2006-07-02 10:09:35 +08:00
|
|
|
put_device(&udev->dev);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2007-11-27 14:11:55 +08:00
|
|
|
#ifdef CONFIG_USB_ANNOUNCE_NEW_DEVICES
|
2005-04-17 06:20:36 +08:00
|
|
|
static void show_string(struct usb_device *udev, char *id, char *string)
|
|
|
|
{
|
|
|
|
if (!string)
|
|
|
|
return;
|
2012-10-28 16:05:51 +08:00
|
|
|
dev_info(&udev->dev, "%s: %s\n", id, string);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2007-11-27 14:11:55 +08:00
|
|
|
static void announce_device(struct usb_device *udev)
|
|
|
|
{
|
|
|
|
dev_info(&udev->dev, "New USB device found, idVendor=%04x, idProduct=%04x\n",
|
|
|
|
le16_to_cpu(udev->descriptor.idVendor),
|
|
|
|
le16_to_cpu(udev->descriptor.idProduct));
|
2008-12-15 15:32:01 +08:00
|
|
|
dev_info(&udev->dev,
|
|
|
|
"New USB device strings: Mfr=%d, Product=%d, SerialNumber=%d\n",
|
2007-11-27 14:11:55 +08:00
|
|
|
udev->descriptor.iManufacturer,
|
|
|
|
udev->descriptor.iProduct,
|
|
|
|
udev->descriptor.iSerialNumber);
|
|
|
|
show_string(udev, "Product", udev->product);
|
|
|
|
show_string(udev, "Manufacturer", udev->manufacturer);
|
|
|
|
show_string(udev, "SerialNumber", udev->serial);
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
#else
|
2007-11-27 14:11:55 +08:00
|
|
|
static inline void announce_device(struct usb_device *udev) { }
|
2005-04-17 06:20:36 +08:00
|
|
|
#endif
|
|
|
|
|
|
|
|
|
2007-01-11 21:35:50 +08:00
|
|
|
/**
|
2009-12-09 04:50:41 +08:00
|
|
|
* usb_enumerate_device_otg - FIXME (usbcore-internal)
|
2007-01-11 21:35:50 +08:00
|
|
|
* @udev: newly addressed device (in ADDRESS state)
|
|
|
|
*
|
2009-12-09 04:50:41 +08:00
|
|
|
* Finish enumeration for On-The-Go devices
|
2013-08-03 02:10:04 +08:00
|
|
|
*
|
|
|
|
* Return: 0 if successful. A negative error code otherwise.
|
2007-01-11 21:35:50 +08:00
|
|
|
*/
|
2009-12-09 04:50:41 +08:00
|
|
|
static int usb_enumerate_device_otg(struct usb_device *udev)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2007-08-01 11:34:05 +08:00
|
|
|
int err = 0;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
#ifdef CONFIG_USB_OTG
|
|
|
|
/*
|
|
|
|
* OTG-aware devices on OTG-capable root hubs may be able to use SRP,
|
|
|
|
* to wake us after we've powered off VBUS; and HNP, switching roles
|
|
|
|
* "host" to "peripheral". The OTG descriptor helps figure this out.
|
|
|
|
*/
|
|
|
|
if (!udev->bus->is_b_host
|
|
|
|
&& udev->config
|
|
|
|
&& udev->parent == udev->bus->root_hub) {
|
2009-12-04 21:47:43 +08:00
|
|
|
struct usb_otg_descriptor *desc = NULL;
|
2005-04-17 06:20:36 +08:00
|
|
|
struct usb_bus *bus = udev->bus;
|
2015-08-31 16:20:49 +08:00
|
|
|
unsigned port1 = udev->portnum;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/* descriptor may appear anywhere in config */
|
2015-08-31 16:20:49 +08:00
|
|
|
err = __usb_get_extra_descriptor(udev->rawdescriptors[0],
|
|
|
|
le16_to_cpu(udev->config[0].desc.wTotalLength),
|
|
|
|
USB_DT_OTG, (void **) &desc);
|
|
|
|
if (err || !(desc->bmAttributes & USB_OTG_HNP))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
dev_info(&udev->dev, "Dual-Role OTG device on %sHNP port\n",
|
|
|
|
(port1 == bus->otg_port) ? "" : "non-");
|
|
|
|
|
|
|
|
/* enable HNP before suspend, it's simpler */
|
|
|
|
if (port1 == bus->otg_port) {
|
|
|
|
bus->b_hnp_enable = 1;
|
|
|
|
err = usb_control_msg(udev,
|
|
|
|
usb_sndctrlpipe(udev, 0),
|
|
|
|
USB_REQ_SET_FEATURE, 0,
|
|
|
|
USB_DEVICE_B_HNP_ENABLE,
|
|
|
|
0, NULL, 0,
|
|
|
|
USB_CTRL_SET_TIMEOUT);
|
|
|
|
if (err < 0) {
|
|
|
|
/*
|
|
|
|
* OTG MESSAGE: report errors here,
|
|
|
|
* customize to match your product.
|
|
|
|
*/
|
|
|
|
dev_err(&udev->dev, "can't set HNP mode: %d\n",
|
|
|
|
err);
|
|
|
|
bus->b_hnp_enable = 0;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2015-08-31 16:20:49 +08:00
|
|
|
} else if (desc->bLength == sizeof
|
|
|
|
(struct usb_otg_descriptor)) {
|
|
|
|
/* Set a_alt_hnp_support for legacy otg device */
|
|
|
|
err = usb_control_msg(udev,
|
|
|
|
usb_sndctrlpipe(udev, 0),
|
|
|
|
USB_REQ_SET_FEATURE, 0,
|
|
|
|
USB_DEVICE_A_ALT_HNP_SUPPORT,
|
|
|
|
0, NULL, 0,
|
|
|
|
USB_CTRL_SET_TIMEOUT);
|
|
|
|
if (err < 0)
|
|
|
|
dev_err(&udev->dev,
|
|
|
|
"set a_alt_hnp_support failed: %d\n",
|
|
|
|
err);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
#endif
|
2007-08-01 11:34:05 +08:00
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
2009-12-09 04:50:41 +08:00
|
|
|
* usb_enumerate_device - Read device configs/intfs/otg (usbcore-internal)
|
2007-08-01 11:34:05 +08:00
|
|
|
* @udev: newly addressed device (in ADDRESS state)
|
|
|
|
*
|
|
|
|
* This is only called by usb_new_device() and usb_authorize_device()
|
|
|
|
* and FIXME -- all comments that apply to them apply here wrt to
|
|
|
|
* environment.
|
|
|
|
*
|
|
|
|
* If the device is WUSB and not authorized, we don't attempt to read
|
|
|
|
* the string descriptors, as they will be errored out by the device
|
|
|
|
* until it has been authorized.
|
2013-08-03 02:10:04 +08:00
|
|
|
*
|
|
|
|
* Return: 0 if successful. A negative error code otherwise.
|
2007-08-01 11:34:05 +08:00
|
|
|
*/
|
2009-12-09 04:50:41 +08:00
|
|
|
static int usb_enumerate_device(struct usb_device *udev)
|
2007-08-01 11:34:05 +08:00
|
|
|
{
|
|
|
|
int err;
|
2014-08-19 09:51:53 +08:00
|
|
|
struct usb_hcd *hcd = bus_to_hcd(udev->bus);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2007-08-01 11:34:05 +08:00
|
|
|
if (udev->config == NULL) {
|
|
|
|
err = usb_get_configuration(udev);
|
|
|
|
if (err < 0) {
|
2013-03-28 04:14:01 +08:00
|
|
|
if (err != -ENODEV)
|
|
|
|
dev_err(&udev->dev, "can't read configurations, error %d\n",
|
|
|
|
err);
|
2012-07-19 18:39:13 +08:00
|
|
|
return err;
|
2007-08-01 11:34:05 +08:00
|
|
|
}
|
|
|
|
}
|
2013-12-10 03:40:29 +08:00
|
|
|
|
|
|
|
/* read the standard strings and cache them if present */
|
|
|
|
udev->product = usb_cache_string(udev, udev->descriptor.iProduct);
|
|
|
|
udev->manufacturer = usb_cache_string(udev,
|
|
|
|
udev->descriptor.iManufacturer);
|
|
|
|
udev->serial = usb_cache_string(udev, udev->descriptor.iSerialNumber);
|
|
|
|
|
2009-12-09 04:50:41 +08:00
|
|
|
err = usb_enumerate_device_otg(udev);
|
2012-07-19 18:39:13 +08:00
|
|
|
if (err < 0)
|
|
|
|
return err;
|
|
|
|
|
2014-08-19 09:51:53 +08:00
|
|
|
if (IS_ENABLED(CONFIG_USB_OTG_WHITELIST) && hcd->tpl_support &&
|
2014-09-29 10:09:31 +08:00
|
|
|
!is_targeted(udev)) {
|
2014-08-19 09:51:53 +08:00
|
|
|
/* Maybe it can talk to us, though we can't talk to it.
|
|
|
|
* (Includes HNP test device.)
|
|
|
|
*/
|
2014-09-29 10:09:31 +08:00
|
|
|
if (IS_ENABLED(CONFIG_USB_OTG) && (udev->bus->b_hnp_enable
|
|
|
|
|| udev->bus->is_b_host)) {
|
2014-08-19 09:51:53 +08:00
|
|
|
err = usb_port_suspend(udev, PMSG_AUTO_SUSPEND);
|
|
|
|
if (err < 0)
|
|
|
|
dev_dbg(&udev->dev, "HNP fail, %d\n", err);
|
|
|
|
}
|
|
|
|
return -ENOTSUPP;
|
|
|
|
}
|
|
|
|
|
2012-07-19 18:39:13 +08:00
|
|
|
usb_detect_interface_quirks(udev);
|
|
|
|
|
|
|
|
return 0;
|
2007-08-01 11:34:05 +08:00
|
|
|
}
|
|
|
|
|
2012-02-04 06:11:55 +08:00
|
|
|
static void set_usb_port_removable(struct usb_device *udev)
|
|
|
|
{
|
|
|
|
struct usb_device *hdev = udev->parent;
|
|
|
|
struct usb_hub *hub;
|
|
|
|
u8 port = udev->portnum;
|
|
|
|
u16 wHubCharacteristics;
|
|
|
|
bool removable = true;
|
|
|
|
|
|
|
|
if (!hdev)
|
|
|
|
return;
|
|
|
|
|
2013-01-23 04:26:30 +08:00
|
|
|
hub = usb_hub_to_struct_hub(udev->parent);
|
2012-02-04 06:11:55 +08:00
|
|
|
|
2015-04-09 07:36:00 +08:00
|
|
|
/*
|
|
|
|
* If the platform firmware has provided information about a port,
|
|
|
|
* use that to determine whether it's removable.
|
|
|
|
*/
|
|
|
|
switch (hub->ports[udev->portnum - 1]->connect_type) {
|
|
|
|
case USB_PORT_CONNECT_TYPE_HOT_PLUG:
|
|
|
|
udev->removable = USB_DEVICE_REMOVABLE;
|
|
|
|
return;
|
|
|
|
case USB_PORT_CONNECT_TYPE_HARD_WIRED:
|
2015-04-09 07:36:01 +08:00
|
|
|
case USB_PORT_NOT_USED:
|
2015-04-09 07:36:00 +08:00
|
|
|
udev->removable = USB_DEVICE_FIXED;
|
|
|
|
return;
|
2015-04-09 07:36:01 +08:00
|
|
|
default:
|
|
|
|
break;
|
2015-04-09 07:36:00 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Otherwise, check whether the hub knows whether a port is removable
|
|
|
|
* or not
|
|
|
|
*/
|
2012-02-04 06:11:55 +08:00
|
|
|
wHubCharacteristics = le16_to_cpu(hub->descriptor->wHubCharacteristics);
|
|
|
|
|
|
|
|
if (!(wHubCharacteristics & HUB_CHAR_COMPOUND))
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (hub_is_superspeed(hdev)) {
|
2012-09-11 04:22:36 +08:00
|
|
|
if (le16_to_cpu(hub->descriptor->u.ss.DeviceRemovable)
|
|
|
|
& (1 << port))
|
2012-02-04 06:11:55 +08:00
|
|
|
removable = false;
|
|
|
|
} else {
|
|
|
|
if (hub->descriptor->u.hs.DeviceRemovable[port / 8] & (1 << (port % 8)))
|
|
|
|
removable = false;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (removable)
|
|
|
|
udev->removable = USB_DEVICE_REMOVABLE;
|
|
|
|
else
|
|
|
|
udev->removable = USB_DEVICE_FIXED;
|
2014-05-21 09:08:22 +08:00
|
|
|
|
2012-02-04 06:11:55 +08:00
|
|
|
}
|
2007-08-01 11:34:05 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* usb_new_device - perform initial device setup (usbcore-internal)
|
|
|
|
* @udev: newly addressed device (in ADDRESS state)
|
|
|
|
*
|
2009-12-09 04:50:41 +08:00
|
|
|
* This is called with devices which have been detected but not fully
|
|
|
|
* enumerated. The device descriptor is available, but not descriptors
|
2007-08-01 11:34:05 +08:00
|
|
|
* for any device configuration. The caller must have locked either
|
|
|
|
* the parent hub (if udev is a normal device) or else the
|
2016-02-04 06:35:23 +08:00
|
|
|
* usb_bus_idr_lock (if udev is a root hub). The parent's pointer to
|
2007-08-01 11:34:05 +08:00
|
|
|
* udev has already been installed, but udev is not yet visible through
|
|
|
|
* sysfs or other filesystem code.
|
|
|
|
*
|
|
|
|
* This call is synchronous, and may not be used in an interrupt context.
|
|
|
|
*
|
|
|
|
* Only the hub driver or root-hub registrar should ever call this.
|
2013-08-03 02:10:04 +08:00
|
|
|
*
|
|
|
|
* Return: Whether the device is configured properly or not. Zero if the
|
|
|
|
* interface was registered with the driver core; else a negative errno
|
|
|
|
* value.
|
|
|
|
*
|
2007-08-01 11:34:05 +08:00
|
|
|
*/
|
|
|
|
int usb_new_device(struct usb_device *udev)
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
|
2010-01-06 22:56:53 +08:00
|
|
|
if (udev->parent) {
|
|
|
|
/* Initialize non-root-hub device wakeup to disabled;
|
|
|
|
* device (un)configuration controls wakeup capable
|
|
|
|
* sysfs power/wakeup controls wakeup enabled/disabled
|
|
|
|
*/
|
|
|
|
device_init_wakeup(&udev->dev, 0);
|
|
|
|
}
|
|
|
|
|
2010-01-09 01:57:28 +08:00
|
|
|
/* Tell the runtime-PM framework the device is active */
|
|
|
|
pm_runtime_set_active(&udev->dev);
|
2010-11-16 04:57:58 +08:00
|
|
|
pm_runtime_get_noresume(&udev->dev);
|
2010-11-16 04:57:51 +08:00
|
|
|
pm_runtime_use_autosuspend(&udev->dev);
|
2010-01-09 01:57:28 +08:00
|
|
|
pm_runtime_enable(&udev->dev);
|
|
|
|
|
2010-11-16 04:57:58 +08:00
|
|
|
/* By default, forbid autosuspend for all devices. It will be
|
|
|
|
* allowed for hubs during binding.
|
|
|
|
*/
|
|
|
|
usb_disable_autosuspend(udev);
|
|
|
|
|
2009-12-09 04:50:41 +08:00
|
|
|
err = usb_enumerate_device(udev); /* Read descriptors */
|
2007-08-01 11:34:05 +08:00
|
|
|
if (err < 0)
|
|
|
|
goto fail;
|
2009-04-28 10:57:26 +08:00
|
|
|
dev_dbg(&udev->dev, "udev %d, busnum %d, minor = %d\n",
|
|
|
|
udev->devnum, udev->bus->busnum,
|
|
|
|
(((udev->bus->busnum-1) * 128) + (udev->devnum-1)));
|
2007-03-13 22:59:31 +08:00
|
|
|
/* export the usbdev device-node for libusb */
|
|
|
|
udev->dev.devt = MKDEV(USB_DEVICE_MAJOR,
|
|
|
|
(((udev->bus->busnum-1) * 128) + (udev->devnum-1)));
|
|
|
|
|
2008-11-14 04:08:30 +08:00
|
|
|
/* Tell the world! */
|
|
|
|
announce_device(udev);
|
2007-07-17 03:28:19 +08:00
|
|
|
|
2012-07-04 23:22:20 +08:00
|
|
|
if (udev->serial)
|
|
|
|
add_device_randomness(udev->serial, strlen(udev->serial));
|
|
|
|
if (udev->product)
|
|
|
|
add_device_randomness(udev->product, strlen(udev->product));
|
|
|
|
if (udev->manufacturer)
|
|
|
|
add_device_randomness(udev->manufacturer,
|
|
|
|
strlen(udev->manufacturer));
|
|
|
|
|
2010-02-09 02:18:16 +08:00
|
|
|
device_enable_async_suspend(&udev->dev);
|
2012-02-04 06:11:55 +08:00
|
|
|
|
2014-05-21 09:08:22 +08:00
|
|
|
/* check whether the hub or firmware marks this port as non-removable */
|
2012-02-04 06:11:55 +08:00
|
|
|
if (udev->parent)
|
|
|
|
set_usb_port_removable(udev);
|
|
|
|
|
2006-07-02 10:09:35 +08:00
|
|
|
/* Register the device. The device driver is responsible
|
2008-12-06 03:10:34 +08:00
|
|
|
* for configuring the device and invoking the add-device
|
|
|
|
* notifier chain (used by usbfs and possibly others).
|
2006-07-02 10:09:35 +08:00
|
|
|
*/
|
2007-03-13 22:59:31 +08:00
|
|
|
err = device_add(&udev->dev);
|
2005-04-17 06:20:36 +08:00
|
|
|
if (err) {
|
|
|
|
dev_err(&udev->dev, "can't device_add, error %d\n", err);
|
|
|
|
goto fail;
|
|
|
|
}
|
2005-11-18 06:10:32 +08:00
|
|
|
|
2013-01-20 01:53:33 +08:00
|
|
|
/* Create link files between child device and usb port device. */
|
|
|
|
if (udev->parent) {
|
2013-01-23 04:26:30 +08:00
|
|
|
struct usb_hub *hub = usb_hub_to_struct_hub(udev->parent);
|
2014-05-21 09:08:52 +08:00
|
|
|
int port1 = udev->portnum;
|
|
|
|
struct usb_port *port_dev = hub->ports[port1 - 1];
|
2013-01-20 01:53:33 +08:00
|
|
|
|
|
|
|
err = sysfs_create_link(&udev->dev.kobj,
|
|
|
|
&port_dev->dev.kobj, "port");
|
|
|
|
if (err)
|
|
|
|
goto fail;
|
|
|
|
|
|
|
|
err = sysfs_create_link(&port_dev->dev.kobj,
|
|
|
|
&udev->dev.kobj, "device");
|
|
|
|
if (err) {
|
|
|
|
sysfs_remove_link(&udev->dev.kobj, "port");
|
|
|
|
goto fail;
|
|
|
|
}
|
2013-01-23 04:26:29 +08:00
|
|
|
|
2014-05-21 09:08:52 +08:00
|
|
|
if (!test_and_set_bit(port1, hub->child_usage_bits))
|
|
|
|
pm_runtime_get_sync(&port_dev->dev);
|
2013-01-20 01:53:33 +08:00
|
|
|
}
|
|
|
|
|
2008-12-06 03:10:34 +08:00
|
|
|
(void) usb_create_ep_devs(&udev->dev, &udev->ep0, udev);
|
2010-11-16 04:57:58 +08:00
|
|
|
usb_mark_last_busy(udev);
|
|
|
|
pm_runtime_put_sync_autosuspend(&udev->dev);
|
2006-08-11 16:55:12 +08:00
|
|
|
return err;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
fail:
|
|
|
|
usb_set_device_state(udev, USB_STATE_NOTATTACHED);
|
2010-01-09 01:57:28 +08:00
|
|
|
pm_runtime_disable(&udev->dev);
|
|
|
|
pm_runtime_set_suspended(&udev->dev);
|
2007-08-01 11:34:05 +08:00
|
|
|
return err;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2007-08-01 11:34:06 +08:00
|
|
|
|
|
|
|
/**
|
2007-10-16 08:30:02 +08:00
|
|
|
* usb_deauthorize_device - deauthorize a device (usbcore-internal)
|
|
|
|
* @usb_dev: USB device
|
|
|
|
*
|
|
|
|
* Move the USB device to a very basic state where interfaces are disabled
|
|
|
|
* and the device is in fact unconfigured and unusable.
|
2007-08-01 11:34:06 +08:00
|
|
|
*
|
|
|
|
* We share a lock (that we have) with device_del(), so we need to
|
|
|
|
* defer its call.
|
2013-08-03 02:10:04 +08:00
|
|
|
*
|
|
|
|
* Return: 0.
|
2007-08-01 11:34:06 +08:00
|
|
|
*/
|
|
|
|
int usb_deauthorize_device(struct usb_device *usb_dev)
|
|
|
|
{
|
|
|
|
usb_lock_device(usb_dev);
|
|
|
|
if (usb_dev->authorized == 0)
|
|
|
|
goto out_unauthorized;
|
2009-12-09 04:54:44 +08:00
|
|
|
|
2007-08-01 11:34:06 +08:00
|
|
|
usb_dev->authorized = 0;
|
|
|
|
usb_set_configuration(usb_dev, -1);
|
2009-12-09 04:54:44 +08:00
|
|
|
|
2007-08-01 11:34:06 +08:00
|
|
|
out_unauthorized:
|
|
|
|
usb_unlock_device(usb_dev);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
int usb_authorize_device(struct usb_device *usb_dev)
|
|
|
|
{
|
|
|
|
int result = 0, c;
|
2009-12-09 04:54:44 +08:00
|
|
|
|
2007-08-01 11:34:06 +08:00
|
|
|
usb_lock_device(usb_dev);
|
|
|
|
if (usb_dev->authorized == 1)
|
|
|
|
goto out_authorized;
|
2009-12-09 04:54:44 +08:00
|
|
|
|
2007-08-01 11:34:06 +08:00
|
|
|
result = usb_autoresume_device(usb_dev);
|
|
|
|
if (result < 0) {
|
|
|
|
dev_err(&usb_dev->dev,
|
|
|
|
"can't autoresume for authorization: %d\n", result);
|
|
|
|
goto error_autoresume;
|
|
|
|
}
|
2014-10-09 21:47:54 +08:00
|
|
|
|
|
|
|
if (usb_dev->wusb) {
|
|
|
|
result = usb_get_device_descriptor(usb_dev, sizeof(usb_dev->descriptor));
|
|
|
|
if (result < 0) {
|
|
|
|
dev_err(&usb_dev->dev, "can't re-read device descriptor for "
|
|
|
|
"authorization: %d\n", result);
|
|
|
|
goto error_device_descriptor;
|
|
|
|
}
|
2007-08-01 11:34:06 +08:00
|
|
|
}
|
2009-12-09 04:54:44 +08:00
|
|
|
|
2007-08-01 11:34:06 +08:00
|
|
|
usb_dev->authorized = 1;
|
|
|
|
/* Choose and set the configuration. This registers the interfaces
|
|
|
|
* with the driver core and lets interface drivers bind to them.
|
|
|
|
*/
|
2007-08-03 12:44:27 +08:00
|
|
|
c = usb_choose_configuration(usb_dev);
|
2007-08-01 11:34:06 +08:00
|
|
|
if (c >= 0) {
|
|
|
|
result = usb_set_configuration(usb_dev, c);
|
|
|
|
if (result) {
|
|
|
|
dev_err(&usb_dev->dev,
|
|
|
|
"can't set config #%d, error %d\n", c, result);
|
|
|
|
/* This need not be fatal. The user can try to
|
|
|
|
* set other configurations. */
|
|
|
|
}
|
|
|
|
}
|
|
|
|
dev_info(&usb_dev->dev, "authorized to connect\n");
|
2009-12-09 04:54:44 +08:00
|
|
|
|
2007-08-01 11:34:06 +08:00
|
|
|
error_device_descriptor:
|
2009-12-09 04:54:44 +08:00
|
|
|
usb_autosuspend_device(usb_dev);
|
2007-08-01 11:34:06 +08:00
|
|
|
error_autoresume:
|
|
|
|
out_authorized:
|
2013-10-11 05:41:29 +08:00
|
|
|
usb_unlock_device(usb_dev); /* complements locktree */
|
2007-08-01 11:34:06 +08:00
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
2015-12-10 15:59:29 +08:00
|
|
|
/*
|
|
|
|
* Return 1 if port speed is SuperSpeedPlus, 0 otherwise
|
|
|
|
* check it from the link protocol field of the current speed ID attribute.
|
|
|
|
* current speed ID is got from ext port status request. Sublink speed attribute
|
|
|
|
* table is returned with the hub BOS SSP device capability descriptor
|
|
|
|
*/
|
|
|
|
static int port_speed_is_ssp(struct usb_device *hdev, int speed_id)
|
|
|
|
{
|
|
|
|
int ssa_count;
|
|
|
|
u32 ss_attr;
|
|
|
|
int i;
|
|
|
|
struct usb_ssp_cap_descriptor *ssp_cap = hdev->bos->ssp_cap;
|
|
|
|
|
|
|
|
if (!ssp_cap)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
ssa_count = le32_to_cpu(ssp_cap->bmAttributes) &
|
|
|
|
USB_SSP_SUBLINK_SPEED_ATTRIBS;
|
|
|
|
|
|
|
|
for (i = 0; i <= ssa_count; i++) {
|
|
|
|
ss_attr = le32_to_cpu(ssp_cap->bmSublinkSpeedAttr[i]);
|
|
|
|
if (speed_id == (ss_attr & USB_SSP_SUBLINK_SPEED_SSID))
|
|
|
|
return !!(ss_attr & USB_SSP_SUBLINK_SPEED_LP);
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
2007-08-01 11:34:06 +08:00
|
|
|
|
2006-08-26 10:35:29 +08:00
|
|
|
/* Returns 1 if @hub is a WUSB root hub, 0 otherwise */
|
|
|
|
static unsigned hub_is_wusb(struct usb_hub *hub)
|
|
|
|
{
|
|
|
|
struct usb_hcd *hcd;
|
|
|
|
if (hub->hdev->parent != NULL) /* not a root hub? */
|
|
|
|
return 0;
|
2015-12-23 21:26:51 +08:00
|
|
|
hcd = bus_to_hcd(hub->hdev->bus);
|
2006-08-26 10:35:29 +08:00
|
|
|
return hcd->wireless;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
#define PORT_RESET_TRIES 5
|
|
|
|
#define SET_ADDRESS_TRIES 2
|
|
|
|
#define GET_DESCRIPTOR_TRIES 2
|
|
|
|
#define SET_CONFIG_TRIES (2 * (use_both_schemes + 1))
|
2012-01-13 07:02:20 +08:00
|
|
|
#define USE_NEW_SCHEME(i) ((i) / 2 == (int)old_scheme_first)
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
#define HUB_ROOT_RESET_TIME 50 /* times are in msec */
|
|
|
|
#define HUB_SHORT_RESET_TIME 10
|
2011-09-14 07:41:11 +08:00
|
|
|
#define HUB_BH_RESET_TIME 50
|
2005-04-17 06:20:36 +08:00
|
|
|
#define HUB_LONG_RESET_TIME 200
|
2012-11-15 09:16:52 +08:00
|
|
|
#define HUB_RESET_TIMEOUT 800
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2013-12-06 09:07:27 +08:00
|
|
|
/*
|
|
|
|
* "New scheme" enumeration causes an extra state transition to be
|
|
|
|
* exposed to an xhci host and causes USB3 devices to receive control
|
|
|
|
* commands in the default state. This has been seen to cause
|
|
|
|
* enumeration failures, so disable this enumeration scheme for USB3
|
|
|
|
* devices.
|
|
|
|
*/
|
|
|
|
static bool use_new_scheme(struct usb_device *udev, int retry)
|
|
|
|
{
|
2015-12-10 15:59:25 +08:00
|
|
|
if (udev->speed >= USB_SPEED_SUPER)
|
2013-12-06 09:07:27 +08:00
|
|
|
return false;
|
|
|
|
|
|
|
|
return USE_NEW_SCHEME(retry);
|
|
|
|
}
|
|
|
|
|
2014-01-04 13:54:41 +08:00
|
|
|
/* Is a USB 3.0 port in the Inactive or Compliance Mode state?
|
2012-06-18 21:20:00 +08:00
|
|
|
* Port worm reset is required to recover
|
|
|
|
*/
|
2014-05-30 03:58:46 +08:00
|
|
|
static bool hub_port_warm_reset_required(struct usb_hub *hub, int port1,
|
|
|
|
u16 portstatus)
|
USB: When hot reset for USB3 fails, try warm reset.
When a hot reset (standard USB port reset) fails on a USB 3.0 port, the
host controller transitions to the "Error" state. It reports the port
link state as "Inactive", sets the link state change flag, and (if the
device disconnects) also reports the disconnect and connect change status.
It's also supposed to transition the link state to "RxDetect", but the NEC
µPD720200 xHCI host does not.
Unfortunately, Harald found that the combination of the NEC µPD720200 and
a LogiLink USB 3.0 to SATA adapter triggered this issue. The USB core
would reset the device, the port would go into this error state, and the
device would never be enumerated. This combination works under Windows,
but not under Linux.
When a hot reset fails on a USB 3.0 port, and the link state is reported
as Inactive, fall back to a warm port reset instead. Harald confirms that
with a warm port reset (along with all the change bits being correctly
cleared), the USB 3.0 device will successfully enumerate.
Harald also had to add two other patches ("xhci: Set change bit when warm
reset change is set." and "usbcore: refine warm reset logic") to make this
setup work. Since the warm reset refinement patch is not destined for the
stable kernels (it's too big), this patch should not be backported either.
This fixes https://bugzilla.kernel.org/show_bug.cgi?id=41752
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Harald Brennich <harald.brennich@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-15 05:24:52 +08:00
|
|
|
{
|
2014-05-30 03:58:46 +08:00
|
|
|
u16 link_state;
|
|
|
|
|
|
|
|
if (!hub_is_superspeed(hub->hdev))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (test_bit(port1, hub->warm_reset_bits))
|
|
|
|
return true;
|
|
|
|
|
|
|
|
link_state = portstatus & USB_PORT_STAT_LINK_STATE;
|
|
|
|
return link_state == USB_SS_PORT_LS_SS_INACTIVE
|
|
|
|
|| link_state == USB_SS_PORT_LS_COMP_MOD;
|
USB: When hot reset for USB3 fails, try warm reset.
When a hot reset (standard USB port reset) fails on a USB 3.0 port, the
host controller transitions to the "Error" state. It reports the port
link state as "Inactive", sets the link state change flag, and (if the
device disconnects) also reports the disconnect and connect change status.
It's also supposed to transition the link state to "RxDetect", but the NEC
µPD720200 xHCI host does not.
Unfortunately, Harald found that the combination of the NEC µPD720200 and
a LogiLink USB 3.0 to SATA adapter triggered this issue. The USB core
would reset the device, the port would go into this error state, and the
device would never be enumerated. This combination works under Windows,
but not under Linux.
When a hot reset fails on a USB 3.0 port, and the link state is reported
as Inactive, fall back to a warm port reset instead. Harald confirms that
with a warm port reset (along with all the change bits being correctly
cleared), the USB 3.0 device will successfully enumerate.
Harald also had to add two other patches ("xhci: Set change bit when warm
reset change is set." and "usbcore: refine warm reset logic") to make this
setup work. Since the warm reset refinement patch is not destined for the
stable kernels (it's too big), this patch should not be backported either.
This fixes https://bugzilla.kernel.org/show_bug.cgi?id=41752
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Harald Brennich <harald.brennich@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-15 05:24:52 +08:00
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
static int hub_port_wait_reset(struct usb_hub *hub, int port1,
|
2011-09-14 07:41:11 +08:00
|
|
|
struct usb_device *udev, unsigned int delay, bool warm)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
int delay_time, ret;
|
|
|
|
u16 portstatus;
|
|
|
|
u16 portchange;
|
2015-12-10 15:59:29 +08:00
|
|
|
u32 ext_portstatus = 0;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
for (delay_time = 0;
|
|
|
|
delay_time < HUB_RESET_TIMEOUT;
|
|
|
|
delay_time += delay) {
|
|
|
|
/* wait to give the device a chance to reset */
|
|
|
|
msleep(delay);
|
|
|
|
|
|
|
|
/* read and decode port status */
|
2015-12-10 15:59:29 +08:00
|
|
|
if (hub_is_superspeedplus(hub->hdev))
|
|
|
|
ret = hub_ext_port_status(hub, port1,
|
|
|
|
HUB_EXT_PORT_STATUS,
|
|
|
|
&portstatus, &portchange,
|
|
|
|
&ext_portstatus);
|
|
|
|
else
|
|
|
|
ret = hub_port_status(hub, port1, &portstatus,
|
|
|
|
&portchange);
|
2005-04-17 06:20:36 +08:00
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
2012-11-16 06:58:04 +08:00
|
|
|
/* The port state is unknown until the reset completes. */
|
2012-12-12 02:14:03 +08:00
|
|
|
if (!(portstatus & USB_PORT_STAT_RESET))
|
|
|
|
break;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/* switch to the long delay after two short delay failures */
|
|
|
|
if (delay_time >= 2 * HUB_SHORT_RESET_TIME)
|
|
|
|
delay = HUB_LONG_RESET_TIME;
|
|
|
|
|
2014-05-21 09:08:17 +08:00
|
|
|
dev_dbg(&hub->ports[port1 - 1]->dev,
|
|
|
|
"not %sreset yet, waiting %dms\n",
|
|
|
|
warm ? "warm " : "", delay);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2012-12-12 02:14:03 +08:00
|
|
|
if ((portstatus & USB_PORT_STAT_RESET))
|
|
|
|
return -EBUSY;
|
|
|
|
|
2014-05-30 03:58:46 +08:00
|
|
|
if (hub_port_warm_reset_required(hub, port1, portstatus))
|
2012-12-12 02:14:03 +08:00
|
|
|
return -ENOTCONN;
|
|
|
|
|
|
|
|
/* Device went away? */
|
|
|
|
if (!(portstatus & USB_PORT_STAT_CONNECTION))
|
|
|
|
return -ENOTCONN;
|
|
|
|
|
|
|
|
/* bomb out completely if the connection bounced. A USB 3.0
|
|
|
|
* connection may bounce if multiple warm resets were issued,
|
|
|
|
* but the device may have successfully re-connected. Ignore it.
|
|
|
|
*/
|
|
|
|
if (!hub_is_superspeed(hub->hdev) &&
|
|
|
|
(portchange & USB_PORT_STAT_C_CONNECTION))
|
|
|
|
return -ENOTCONN;
|
|
|
|
|
|
|
|
if (!(portstatus & USB_PORT_STAT_ENABLE))
|
|
|
|
return -EBUSY;
|
|
|
|
|
|
|
|
if (!udev)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (hub_is_wusb(hub))
|
|
|
|
udev->speed = USB_SPEED_WIRELESS;
|
2015-12-10 15:59:29 +08:00
|
|
|
else if (hub_is_superspeedplus(hub->hdev) &&
|
|
|
|
port_speed_is_ssp(hub->hdev, ext_portstatus &
|
|
|
|
USB_EXT_PORT_STAT_RX_SPEED_ID))
|
|
|
|
udev->speed = USB_SPEED_SUPER_PLUS;
|
2012-12-12 02:14:03 +08:00
|
|
|
else if (hub_is_superspeed(hub->hdev))
|
|
|
|
udev->speed = USB_SPEED_SUPER;
|
|
|
|
else if (portstatus & USB_PORT_STAT_HIGH_SPEED)
|
|
|
|
udev->speed = USB_SPEED_HIGH;
|
|
|
|
else if (portstatus & USB_PORT_STAT_LOW_SPEED)
|
|
|
|
udev->speed = USB_SPEED_LOW;
|
|
|
|
else
|
|
|
|
udev->speed = USB_SPEED_FULL;
|
|
|
|
return 0;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2011-09-14 07:41:11 +08:00
|
|
|
/* Handle port reset and port warm(BH) reset (for USB3 protocol ports) */
|
2005-04-17 06:20:36 +08:00
|
|
|
static int hub_port_reset(struct usb_hub *hub, int port1,
|
2011-09-14 07:41:11 +08:00
|
|
|
struct usb_device *udev, unsigned int delay, bool warm)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
int i, status;
|
USB: Rip out recursive call on warm port reset.
When a hot reset fails on a USB 3.0 port, the current port reset code
recursively calls hub_port_reset inside hub_port_wait_reset. This isn't
ideal, since we should avoid recursive calls in the kernel, and it also
doesn't allow us to issue multiple warm resets on reset failures.
Rip out the recursive call. Instead, add code to hub_port_reset to
issue a warm reset if the hot reset fails, and try multiple warm resets
before giving up on the port.
In hub_port_wait_reset, remove the recursive call and re-indent. The
code is basically the same, except:
1. It bails out early if the port has transitioned to Inactive or
Compliance Mode after the reset completed.
2. It doesn't consider a connect status change to be a failed reset. If
multiple warm resets needed to be issued, the connect status may have
changed, so we need to ignore that and look at the port link state
instead. hub_port_reset will now do that.
3. It unconditionally sets udev->speed on all types of successful
resets. The old recursive code would set the port speed when the second
hub_port_reset returned.
The old code did not handle connected devices needing a warm reset well.
There were only two situations that the old code handled correctly: an
empty port needing a warm reset, and a hot reset that migrated to a warm
reset.
When an empty port needed a warm reset, hub_port_reset was called with
the warm variable set. The code in hub_port_finish_reset would skip
telling the USB core and the xHC host that the device was reset, because
otherwise that would result in a NULL pointer dereference.
When a USB 3.0 device reset migrated to a warm reset, the recursive call
made the call stack look like this:
hub_port_reset(warm = false)
hub_wait_port_reset(warm = false)
hub_port_reset(warm = true)
hub_wait_port_reset(warm = true)
hub_port_finish_reset(warm = true)
(return up the call stack to the first wait)
hub_port_finish_reset(warm = false)
The old code didn't want to notify the USB core or the xHC host of device reset
twice, so it only did it in the second call to hub_port_finish_reset,
when warm was set to false. This was necessary because
before patch two ("USB: Ignore xHCI Reset Device status."), the USB core
would pay attention to the xHC Reset Device command error status, and
the second call would always fail.
Now that we no longer have the recursive call, and warm can change from
false to true in hub_port_reset, we need to have hub_port_finish_reset
unconditionally notify the USB core and the xHC of the device reset.
In hub_port_finish_reset, unconditionally clear the connect status
change (CSC) bit for USB 3.0 hubs when the port reset is done. If we
had to issue multiple warm resets for a device, that bit may have been
set if the device went into SS.Inactive and then was successfully warm
reset.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
2012-11-02 02:20:44 +08:00
|
|
|
u16 portchange, portstatus;
|
2014-05-21 09:08:17 +08:00
|
|
|
struct usb_port *port_dev = hub->ports[port1 - 1];
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2012-11-02 02:20:44 +08:00
|
|
|
if (!hub_is_superspeed(hub->hdev)) {
|
|
|
|
if (warm) {
|
2011-09-14 07:41:11 +08:00
|
|
|
dev_err(hub->intfdev, "only USB3 hub support "
|
|
|
|
"warm reset\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2012-11-02 02:20:44 +08:00
|
|
|
/* Block EHCI CF initialization during the port reset.
|
|
|
|
* Some companion controllers don't like it when they mix.
|
|
|
|
*/
|
|
|
|
down_read(&ehci_cf_port_reset_rwsem);
|
2012-11-02 02:20:44 +08:00
|
|
|
} else if (!warm) {
|
|
|
|
/*
|
|
|
|
* If the caller hasn't explicitly requested a warm reset,
|
|
|
|
* double check and see if one is needed.
|
|
|
|
*/
|
usb: core: Fix USB 3.0 devices lost in NOTATTACHED state after a hub port reset
Fix USB 3.0 devices lost in NOTATTACHED state after a hub port reset.
Dissolve the function hub_port_finish_reset() completely and divide the
actions to be taken into those which need to be done after each reset
attempt and those which need to be done after the full procedure is
complete, and place them in the appropriate places in hub_port_reset().
Also, remove an unneeded forward declaration of hub_port_reset().
Verbose Problem Description:
USB 3.0 devices may be "lost for good" during a hub port reset.
This makes Linux unable to boot from USB 3.0 devices in certain
constellations of host controllers and devices, because the USB device is
lost during initialization, preventing the rootfs from being mounted.
The underlying problem is that in the affected constellations, during the
processing inside hub_port_reset(), the hub link state goes from 0 to
SS.inactive after the initial reset, and back to 0 again only after the
following "warm" reset.
However, hub_port_finish_reset() is called after each reset attempt and
sets the state the connected USB device based on the "preliminary" status
of the hot reset to USB_STATE_NOTATTACHED due to SS.inactive, yet when
the following warm reset is complete and hub_port_finish_reset() is
called again, its call to set the device to USB_STATE_DEFAULT is blocked
by usb_set_device_state() which does not allow taking USB devices out of
USB_STATE_NOTATTACHED state.
Thanks to Alan Stern for guiding me to the proper solution and how to
submit it.
Link: http://lkml.kernel.org/r/trinity-25981484-72a9-4d46-bf17-9c1cf9301a31-1432073240136%20()%203capp-gmx-bs27
Signed-off-by: Robert Schlabbach <robert_s@gmx.net>
Cc: stable <stable@vger.kernel.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-05-26 06:27:30 +08:00
|
|
|
if (hub_port_status(hub, port1, &portstatus, &portchange) == 0)
|
|
|
|
if (hub_port_warm_reset_required(hub, port1,
|
|
|
|
portstatus))
|
|
|
|
warm = true;
|
2011-09-14 07:41:11 +08:00
|
|
|
}
|
2014-05-30 03:58:46 +08:00
|
|
|
clear_bit(port1, hub->warm_reset_bits);
|
2007-10-11 04:27:07 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/* Reset the port */
|
|
|
|
for (i = 0; i < PORT_RESET_TRIES; i++) {
|
2011-09-14 07:41:11 +08:00
|
|
|
status = set_port_feature(hub->hdev, port1, (warm ?
|
|
|
|
USB_PORT_FEAT_BH_PORT_RESET :
|
|
|
|
USB_PORT_FEAT_RESET));
|
2013-03-28 04:14:01 +08:00
|
|
|
if (status == -ENODEV) {
|
|
|
|
; /* The hub is gone */
|
|
|
|
} else if (status) {
|
2014-05-21 09:08:17 +08:00
|
|
|
dev_err(&port_dev->dev,
|
|
|
|
"cannot %sreset (err = %d)\n",
|
|
|
|
warm ? "warm " : "", status);
|
2011-09-14 07:41:11 +08:00
|
|
|
} else {
|
|
|
|
status = hub_port_wait_reset(hub, port1, udev, delay,
|
|
|
|
warm);
|
2013-03-28 04:14:01 +08:00
|
|
|
if (status && status != -ENOTCONN && status != -ENODEV)
|
2005-04-17 06:20:36 +08:00
|
|
|
dev_dbg(hub->intfdev,
|
|
|
|
"port_wait_reset: err = %d\n",
|
|
|
|
status);
|
|
|
|
}
|
|
|
|
|
USB: Rip out recursive call on warm port reset.
When a hot reset fails on a USB 3.0 port, the current port reset code
recursively calls hub_port_reset inside hub_port_wait_reset. This isn't
ideal, since we should avoid recursive calls in the kernel, and it also
doesn't allow us to issue multiple warm resets on reset failures.
Rip out the recursive call. Instead, add code to hub_port_reset to
issue a warm reset if the hot reset fails, and try multiple warm resets
before giving up on the port.
In hub_port_wait_reset, remove the recursive call and re-indent. The
code is basically the same, except:
1. It bails out early if the port has transitioned to Inactive or
Compliance Mode after the reset completed.
2. It doesn't consider a connect status change to be a failed reset. If
multiple warm resets needed to be issued, the connect status may have
changed, so we need to ignore that and look at the port link state
instead. hub_port_reset will now do that.
3. It unconditionally sets udev->speed on all types of successful
resets. The old recursive code would set the port speed when the second
hub_port_reset returned.
The old code did not handle connected devices needing a warm reset well.
There were only two situations that the old code handled correctly: an
empty port needing a warm reset, and a hot reset that migrated to a warm
reset.
When an empty port needed a warm reset, hub_port_reset was called with
the warm variable set. The code in hub_port_finish_reset would skip
telling the USB core and the xHC host that the device was reset, because
otherwise that would result in a NULL pointer dereference.
When a USB 3.0 device reset migrated to a warm reset, the recursive call
made the call stack look like this:
hub_port_reset(warm = false)
hub_wait_port_reset(warm = false)
hub_port_reset(warm = true)
hub_wait_port_reset(warm = true)
hub_port_finish_reset(warm = true)
(return up the call stack to the first wait)
hub_port_finish_reset(warm = false)
The old code didn't want to notify the USB core or the xHC host of device reset
twice, so it only did it in the second call to hub_port_finish_reset,
when warm was set to false. This was necessary because
before patch two ("USB: Ignore xHCI Reset Device status."), the USB core
would pay attention to the xHC Reset Device command error status, and
the second call would always fail.
Now that we no longer have the recursive call, and warm can change from
false to true in hub_port_reset, we need to have hub_port_finish_reset
unconditionally notify the USB core and the xHC of the device reset.
In hub_port_finish_reset, unconditionally clear the connect status
change (CSC) bit for USB 3.0 hubs when the port reset is done. If we
had to issue multiple warm resets for a device, that bit may have been
set if the device went into SS.Inactive and then was successfully warm
reset.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
2012-11-02 02:20:44 +08:00
|
|
|
/* Check for disconnect or reset */
|
2011-09-14 07:41:11 +08:00
|
|
|
if (status == 0 || status == -ENOTCONN || status == -ENODEV) {
|
usb: core: Fix USB 3.0 devices lost in NOTATTACHED state after a hub port reset
Fix USB 3.0 devices lost in NOTATTACHED state after a hub port reset.
Dissolve the function hub_port_finish_reset() completely and divide the
actions to be taken into those which need to be done after each reset
attempt and those which need to be done after the full procedure is
complete, and place them in the appropriate places in hub_port_reset().
Also, remove an unneeded forward declaration of hub_port_reset().
Verbose Problem Description:
USB 3.0 devices may be "lost for good" during a hub port reset.
This makes Linux unable to boot from USB 3.0 devices in certain
constellations of host controllers and devices, because the USB device is
lost during initialization, preventing the rootfs from being mounted.
The underlying problem is that in the affected constellations, during the
processing inside hub_port_reset(), the hub link state goes from 0 to
SS.inactive after the initial reset, and back to 0 again only after the
following "warm" reset.
However, hub_port_finish_reset() is called after each reset attempt and
sets the state the connected USB device based on the "preliminary" status
of the hot reset to USB_STATE_NOTATTACHED due to SS.inactive, yet when
the following warm reset is complete and hub_port_finish_reset() is
called again, its call to set the device to USB_STATE_DEFAULT is blocked
by usb_set_device_state() which does not allow taking USB devices out of
USB_STATE_NOTATTACHED state.
Thanks to Alan Stern for guiding me to the proper solution and how to
submit it.
Link: http://lkml.kernel.org/r/trinity-25981484-72a9-4d46-bf17-9c1cf9301a31-1432073240136%20()%203capp-gmx-bs27
Signed-off-by: Robert Schlabbach <robert_s@gmx.net>
Cc: stable <stable@vger.kernel.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-05-26 06:27:30 +08:00
|
|
|
usb_clear_port_feature(hub->hdev, port1,
|
|
|
|
USB_PORT_FEAT_C_RESET);
|
USB: Rip out recursive call on warm port reset.
When a hot reset fails on a USB 3.0 port, the current port reset code
recursively calls hub_port_reset inside hub_port_wait_reset. This isn't
ideal, since we should avoid recursive calls in the kernel, and it also
doesn't allow us to issue multiple warm resets on reset failures.
Rip out the recursive call. Instead, add code to hub_port_reset to
issue a warm reset if the hot reset fails, and try multiple warm resets
before giving up on the port.
In hub_port_wait_reset, remove the recursive call and re-indent. The
code is basically the same, except:
1. It bails out early if the port has transitioned to Inactive or
Compliance Mode after the reset completed.
2. It doesn't consider a connect status change to be a failed reset. If
multiple warm resets needed to be issued, the connect status may have
changed, so we need to ignore that and look at the port link state
instead. hub_port_reset will now do that.
3. It unconditionally sets udev->speed on all types of successful
resets. The old recursive code would set the port speed when the second
hub_port_reset returned.
The old code did not handle connected devices needing a warm reset well.
There were only two situations that the old code handled correctly: an
empty port needing a warm reset, and a hot reset that migrated to a warm
reset.
When an empty port needed a warm reset, hub_port_reset was called with
the warm variable set. The code in hub_port_finish_reset would skip
telling the USB core and the xHC host that the device was reset, because
otherwise that would result in a NULL pointer dereference.
When a USB 3.0 device reset migrated to a warm reset, the recursive call
made the call stack look like this:
hub_port_reset(warm = false)
hub_wait_port_reset(warm = false)
hub_port_reset(warm = true)
hub_wait_port_reset(warm = true)
hub_port_finish_reset(warm = true)
(return up the call stack to the first wait)
hub_port_finish_reset(warm = false)
The old code didn't want to notify the USB core or the xHC host of device reset
twice, so it only did it in the second call to hub_port_finish_reset,
when warm was set to false. This was necessary because
before patch two ("USB: Ignore xHCI Reset Device status."), the USB core
would pay attention to the xHC Reset Device command error status, and
the second call would always fail.
Now that we no longer have the recursive call, and warm can change from
false to true in hub_port_reset, we need to have hub_port_finish_reset
unconditionally notify the USB core and the xHC of the device reset.
In hub_port_finish_reset, unconditionally clear the connect status
change (CSC) bit for USB 3.0 hubs when the port reset is done. If we
had to issue multiple warm resets for a device, that bit may have been
set if the device went into SS.Inactive and then was successfully warm
reset.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
2012-11-02 02:20:44 +08:00
|
|
|
|
|
|
|
if (!hub_is_superspeed(hub->hdev))
|
|
|
|
goto done;
|
|
|
|
|
usb: core: Fix USB 3.0 devices lost in NOTATTACHED state after a hub port reset
Fix USB 3.0 devices lost in NOTATTACHED state after a hub port reset.
Dissolve the function hub_port_finish_reset() completely and divide the
actions to be taken into those which need to be done after each reset
attempt and those which need to be done after the full procedure is
complete, and place them in the appropriate places in hub_port_reset().
Also, remove an unneeded forward declaration of hub_port_reset().
Verbose Problem Description:
USB 3.0 devices may be "lost for good" during a hub port reset.
This makes Linux unable to boot from USB 3.0 devices in certain
constellations of host controllers and devices, because the USB device is
lost during initialization, preventing the rootfs from being mounted.
The underlying problem is that in the affected constellations, during the
processing inside hub_port_reset(), the hub link state goes from 0 to
SS.inactive after the initial reset, and back to 0 again only after the
following "warm" reset.
However, hub_port_finish_reset() is called after each reset attempt and
sets the state the connected USB device based on the "preliminary" status
of the hot reset to USB_STATE_NOTATTACHED due to SS.inactive, yet when
the following warm reset is complete and hub_port_finish_reset() is
called again, its call to set the device to USB_STATE_DEFAULT is blocked
by usb_set_device_state() which does not allow taking USB devices out of
USB_STATE_NOTATTACHED state.
Thanks to Alan Stern for guiding me to the proper solution and how to
submit it.
Link: http://lkml.kernel.org/r/trinity-25981484-72a9-4d46-bf17-9c1cf9301a31-1432073240136%20()%203capp-gmx-bs27
Signed-off-by: Robert Schlabbach <robert_s@gmx.net>
Cc: stable <stable@vger.kernel.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-05-26 06:27:30 +08:00
|
|
|
usb_clear_port_feature(hub->hdev, port1,
|
|
|
|
USB_PORT_FEAT_C_BH_PORT_RESET);
|
|
|
|
usb_clear_port_feature(hub->hdev, port1,
|
|
|
|
USB_PORT_FEAT_C_PORT_LINK_STATE);
|
|
|
|
usb_clear_port_feature(hub->hdev, port1,
|
|
|
|
USB_PORT_FEAT_C_CONNECTION);
|
|
|
|
|
USB: Rip out recursive call on warm port reset.
When a hot reset fails on a USB 3.0 port, the current port reset code
recursively calls hub_port_reset inside hub_port_wait_reset. This isn't
ideal, since we should avoid recursive calls in the kernel, and it also
doesn't allow us to issue multiple warm resets on reset failures.
Rip out the recursive call. Instead, add code to hub_port_reset to
issue a warm reset if the hot reset fails, and try multiple warm resets
before giving up on the port.
In hub_port_wait_reset, remove the recursive call and re-indent. The
code is basically the same, except:
1. It bails out early if the port has transitioned to Inactive or
Compliance Mode after the reset completed.
2. It doesn't consider a connect status change to be a failed reset. If
multiple warm resets needed to be issued, the connect status may have
changed, so we need to ignore that and look at the port link state
instead. hub_port_reset will now do that.
3. It unconditionally sets udev->speed on all types of successful
resets. The old recursive code would set the port speed when the second
hub_port_reset returned.
The old code did not handle connected devices needing a warm reset well.
There were only two situations that the old code handled correctly: an
empty port needing a warm reset, and a hot reset that migrated to a warm
reset.
When an empty port needed a warm reset, hub_port_reset was called with
the warm variable set. The code in hub_port_finish_reset would skip
telling the USB core and the xHC host that the device was reset, because
otherwise that would result in a NULL pointer dereference.
When a USB 3.0 device reset migrated to a warm reset, the recursive call
made the call stack look like this:
hub_port_reset(warm = false)
hub_wait_port_reset(warm = false)
hub_port_reset(warm = true)
hub_wait_port_reset(warm = true)
hub_port_finish_reset(warm = true)
(return up the call stack to the first wait)
hub_port_finish_reset(warm = false)
The old code didn't want to notify the USB core or the xHC host of device reset
twice, so it only did it in the second call to hub_port_finish_reset,
when warm was set to false. This was necessary because
before patch two ("USB: Ignore xHCI Reset Device status."), the USB core
would pay attention to the xHC Reset Device command error status, and
the second call would always fail.
Now that we no longer have the recursive call, and warm can change from
false to true in hub_port_reset, we need to have hub_port_finish_reset
unconditionally notify the USB core and the xHC of the device reset.
In hub_port_finish_reset, unconditionally clear the connect status
change (CSC) bit for USB 3.0 hubs when the port reset is done. If we
had to issue multiple warm resets for a device, that bit may have been
set if the device went into SS.Inactive and then was successfully warm
reset.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
2012-11-02 02:20:44 +08:00
|
|
|
/*
|
|
|
|
* If a USB 3.0 device migrates from reset to an error
|
|
|
|
* state, re-issue the warm reset.
|
|
|
|
*/
|
|
|
|
if (hub_port_status(hub, port1,
|
|
|
|
&portstatus, &portchange) < 0)
|
|
|
|
goto done;
|
|
|
|
|
2014-05-30 03:58:46 +08:00
|
|
|
if (!hub_port_warm_reset_required(hub, port1,
|
|
|
|
portstatus))
|
USB: Rip out recursive call on warm port reset.
When a hot reset fails on a USB 3.0 port, the current port reset code
recursively calls hub_port_reset inside hub_port_wait_reset. This isn't
ideal, since we should avoid recursive calls in the kernel, and it also
doesn't allow us to issue multiple warm resets on reset failures.
Rip out the recursive call. Instead, add code to hub_port_reset to
issue a warm reset if the hot reset fails, and try multiple warm resets
before giving up on the port.
In hub_port_wait_reset, remove the recursive call and re-indent. The
code is basically the same, except:
1. It bails out early if the port has transitioned to Inactive or
Compliance Mode after the reset completed.
2. It doesn't consider a connect status change to be a failed reset. If
multiple warm resets needed to be issued, the connect status may have
changed, so we need to ignore that and look at the port link state
instead. hub_port_reset will now do that.
3. It unconditionally sets udev->speed on all types of successful
resets. The old recursive code would set the port speed when the second
hub_port_reset returned.
The old code did not handle connected devices needing a warm reset well.
There were only two situations that the old code handled correctly: an
empty port needing a warm reset, and a hot reset that migrated to a warm
reset.
When an empty port needed a warm reset, hub_port_reset was called with
the warm variable set. The code in hub_port_finish_reset would skip
telling the USB core and the xHC host that the device was reset, because
otherwise that would result in a NULL pointer dereference.
When a USB 3.0 device reset migrated to a warm reset, the recursive call
made the call stack look like this:
hub_port_reset(warm = false)
hub_wait_port_reset(warm = false)
hub_port_reset(warm = true)
hub_wait_port_reset(warm = true)
hub_port_finish_reset(warm = true)
(return up the call stack to the first wait)
hub_port_finish_reset(warm = false)
The old code didn't want to notify the USB core or the xHC host of device reset
twice, so it only did it in the second call to hub_port_finish_reset,
when warm was set to false. This was necessary because
before patch two ("USB: Ignore xHCI Reset Device status."), the USB core
would pay attention to the xHC Reset Device command error status, and
the second call would always fail.
Now that we no longer have the recursive call, and warm can change from
false to true in hub_port_reset, we need to have hub_port_finish_reset
unconditionally notify the USB core and the xHC of the device reset.
In hub_port_finish_reset, unconditionally clear the connect status
change (CSC) bit for USB 3.0 hubs when the port reset is done. If we
had to issue multiple warm resets for a device, that bit may have been
set if the device went into SS.Inactive and then was successfully warm
reset.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
2012-11-02 02:20:44 +08:00
|
|
|
goto done;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If the port is in SS.Inactive or Compliance Mode, the
|
|
|
|
* hot or warm reset failed. Try another warm reset.
|
|
|
|
*/
|
|
|
|
if (!warm) {
|
2014-05-21 09:08:17 +08:00
|
|
|
dev_dbg(&port_dev->dev,
|
|
|
|
"hot reset failed, warm reset\n");
|
USB: Rip out recursive call on warm port reset.
When a hot reset fails on a USB 3.0 port, the current port reset code
recursively calls hub_port_reset inside hub_port_wait_reset. This isn't
ideal, since we should avoid recursive calls in the kernel, and it also
doesn't allow us to issue multiple warm resets on reset failures.
Rip out the recursive call. Instead, add code to hub_port_reset to
issue a warm reset if the hot reset fails, and try multiple warm resets
before giving up on the port.
In hub_port_wait_reset, remove the recursive call and re-indent. The
code is basically the same, except:
1. It bails out early if the port has transitioned to Inactive or
Compliance Mode after the reset completed.
2. It doesn't consider a connect status change to be a failed reset. If
multiple warm resets needed to be issued, the connect status may have
changed, so we need to ignore that and look at the port link state
instead. hub_port_reset will now do that.
3. It unconditionally sets udev->speed on all types of successful
resets. The old recursive code would set the port speed when the second
hub_port_reset returned.
The old code did not handle connected devices needing a warm reset well.
There were only two situations that the old code handled correctly: an
empty port needing a warm reset, and a hot reset that migrated to a warm
reset.
When an empty port needed a warm reset, hub_port_reset was called with
the warm variable set. The code in hub_port_finish_reset would skip
telling the USB core and the xHC host that the device was reset, because
otherwise that would result in a NULL pointer dereference.
When a USB 3.0 device reset migrated to a warm reset, the recursive call
made the call stack look like this:
hub_port_reset(warm = false)
hub_wait_port_reset(warm = false)
hub_port_reset(warm = true)
hub_wait_port_reset(warm = true)
hub_port_finish_reset(warm = true)
(return up the call stack to the first wait)
hub_port_finish_reset(warm = false)
The old code didn't want to notify the USB core or the xHC host of device reset
twice, so it only did it in the second call to hub_port_finish_reset,
when warm was set to false. This was necessary because
before patch two ("USB: Ignore xHCI Reset Device status."), the USB core
would pay attention to the xHC Reset Device command error status, and
the second call would always fail.
Now that we no longer have the recursive call, and warm can change from
false to true in hub_port_reset, we need to have hub_port_finish_reset
unconditionally notify the USB core and the xHC of the device reset.
In hub_port_finish_reset, unconditionally clear the connect status
change (CSC) bit for USB 3.0 hubs when the port reset is done. If we
had to issue multiple warm resets for a device, that bit may have been
set if the device went into SS.Inactive and then was successfully warm
reset.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
2012-11-02 02:20:44 +08:00
|
|
|
warm = true;
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2014-05-21 09:08:17 +08:00
|
|
|
dev_dbg(&port_dev->dev,
|
|
|
|
"not enabled, trying %sreset again...\n",
|
|
|
|
warm ? "warm " : "");
|
2005-04-17 06:20:36 +08:00
|
|
|
delay = HUB_LONG_RESET_TIME;
|
|
|
|
}
|
|
|
|
|
2014-05-21 09:08:17 +08:00
|
|
|
dev_err(&port_dev->dev, "Cannot enable. Maybe the USB cable is bad?\n");
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2011-09-14 07:41:11 +08:00
|
|
|
done:
|
usb: core: Fix USB 3.0 devices lost in NOTATTACHED state after a hub port reset
Fix USB 3.0 devices lost in NOTATTACHED state after a hub port reset.
Dissolve the function hub_port_finish_reset() completely and divide the
actions to be taken into those which need to be done after each reset
attempt and those which need to be done after the full procedure is
complete, and place them in the appropriate places in hub_port_reset().
Also, remove an unneeded forward declaration of hub_port_reset().
Verbose Problem Description:
USB 3.0 devices may be "lost for good" during a hub port reset.
This makes Linux unable to boot from USB 3.0 devices in certain
constellations of host controllers and devices, because the USB device is
lost during initialization, preventing the rootfs from being mounted.
The underlying problem is that in the affected constellations, during the
processing inside hub_port_reset(), the hub link state goes from 0 to
SS.inactive after the initial reset, and back to 0 again only after the
following "warm" reset.
However, hub_port_finish_reset() is called after each reset attempt and
sets the state the connected USB device based on the "preliminary" status
of the hot reset to USB_STATE_NOTATTACHED due to SS.inactive, yet when
the following warm reset is complete and hub_port_finish_reset() is
called again, its call to set the device to USB_STATE_DEFAULT is blocked
by usb_set_device_state() which does not allow taking USB devices out of
USB_STATE_NOTATTACHED state.
Thanks to Alan Stern for guiding me to the proper solution and how to
submit it.
Link: http://lkml.kernel.org/r/trinity-25981484-72a9-4d46-bf17-9c1cf9301a31-1432073240136%20()%203capp-gmx-bs27
Signed-off-by: Robert Schlabbach <robert_s@gmx.net>
Cc: stable <stable@vger.kernel.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-05-26 06:27:30 +08:00
|
|
|
if (status == 0) {
|
|
|
|
/* TRSTRCY = 10 ms; plus some extra */
|
|
|
|
msleep(10 + 40);
|
|
|
|
if (udev) {
|
|
|
|
struct usb_hcd *hcd = bus_to_hcd(udev->bus);
|
|
|
|
|
|
|
|
update_devnum(udev, 0);
|
|
|
|
/* The xHC may think the device is already reset,
|
|
|
|
* so ignore the status.
|
|
|
|
*/
|
|
|
|
if (hcd->driver->reset_device)
|
|
|
|
hcd->driver->reset_device(hcd, udev);
|
|
|
|
|
|
|
|
usb_set_device_state(udev, USB_STATE_DEFAULT);
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
if (udev)
|
|
|
|
usb_set_device_state(udev, USB_STATE_NOTATTACHED);
|
|
|
|
}
|
|
|
|
|
2012-11-02 02:20:44 +08:00
|
|
|
if (!hub_is_superspeed(hub->hdev))
|
2011-09-14 07:41:11 +08:00
|
|
|
up_read(&ehci_cf_port_reset_rwsem);
|
2011-04-27 18:07:54 +08:00
|
|
|
|
2011-09-14 07:41:11 +08:00
|
|
|
return status;
|
2011-04-27 18:07:54 +08:00
|
|
|
}
|
|
|
|
|
2011-04-27 18:07:43 +08:00
|
|
|
/* Check if a port is power on */
|
|
|
|
static int port_is_power_on(struct usb_hub *hub, unsigned portstatus)
|
|
|
|
{
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
if (hub_is_superspeed(hub->hdev)) {
|
|
|
|
if (portstatus & USB_SS_PORT_STAT_POWER)
|
|
|
|
ret = 1;
|
|
|
|
} else {
|
|
|
|
if (portstatus & USB_PORT_STAT_POWER)
|
|
|
|
ret = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2014-05-21 09:09:26 +08:00
|
|
|
static void usb_lock_port(struct usb_port *port_dev)
|
|
|
|
__acquires(&port_dev->status_lock)
|
|
|
|
{
|
|
|
|
mutex_lock(&port_dev->status_lock);
|
|
|
|
__acquire(&port_dev->status_lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void usb_unlock_port(struct usb_port *port_dev)
|
|
|
|
__releases(&port_dev->status_lock)
|
|
|
|
{
|
|
|
|
mutex_unlock(&port_dev->status_lock);
|
|
|
|
__release(&port_dev->status_lock);
|
|
|
|
}
|
|
|
|
|
2006-07-02 10:14:24 +08:00
|
|
|
#ifdef CONFIG_PM
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2011-04-27 18:07:43 +08:00
|
|
|
/* Check if a port is suspended(USB2.0 port) or in U3 state(USB3.0 port) */
|
|
|
|
static int port_is_suspended(struct usb_hub *hub, unsigned portstatus)
|
|
|
|
{
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
if (hub_is_superspeed(hub->hdev)) {
|
|
|
|
if ((portstatus & USB_PORT_STAT_LINK_STATE)
|
|
|
|
== USB_SS_PORT_LS_U3)
|
|
|
|
ret = 1;
|
|
|
|
} else {
|
|
|
|
if (portstatus & USB_PORT_STAT_SUSPEND)
|
|
|
|
ret = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
2008-04-28 23:06:11 +08:00
|
|
|
|
|
|
|
/* Determine whether the device on a port is ready for a normal resume,
|
|
|
|
* is ready for a reset-resume, or should be disconnected.
|
|
|
|
*/
|
|
|
|
static int check_port_resume_type(struct usb_device *udev,
|
|
|
|
struct usb_hub *hub, int port1,
|
2015-01-28 05:20:12 +08:00
|
|
|
int status, u16 portchange, u16 portstatus)
|
2008-04-28 23:06:11 +08:00
|
|
|
{
|
2014-05-21 09:08:17 +08:00
|
|
|
struct usb_port *port_dev = hub->ports[port1 - 1];
|
2015-01-28 05:20:12 +08:00
|
|
|
int retries = 3;
|
2014-05-21 09:08:17 +08:00
|
|
|
|
2015-01-28 05:20:12 +08:00
|
|
|
retry:
|
2014-05-30 03:58:46 +08:00
|
|
|
/* Is a warm reset needed to recover the connection? */
|
|
|
|
if (status == 0 && udev->reset_resume
|
|
|
|
&& hub_port_warm_reset_required(hub, port1, portstatus)) {
|
|
|
|
/* pass */;
|
|
|
|
}
|
2008-04-28 23:06:11 +08:00
|
|
|
/* Is the device still present? */
|
2014-05-30 03:58:46 +08:00
|
|
|
else if (status || port_is_suspended(hub, portstatus) ||
|
2015-01-28 05:20:12 +08:00
|
|
|
!port_is_power_on(hub, portstatus)) {
|
2008-04-28 23:06:11 +08:00
|
|
|
if (status >= 0)
|
|
|
|
status = -ENODEV;
|
2015-01-28 05:20:12 +08:00
|
|
|
} else if (!(portstatus & USB_PORT_STAT_CONNECTION)) {
|
|
|
|
if (retries--) {
|
|
|
|
usleep_range(200, 300);
|
|
|
|
status = hub_port_status(hub, port1, &portstatus,
|
|
|
|
&portchange);
|
|
|
|
goto retry;
|
|
|
|
}
|
|
|
|
status = -ENODEV;
|
2008-04-28 23:06:11 +08:00
|
|
|
}
|
|
|
|
|
2008-06-30 23:14:43 +08:00
|
|
|
/* Can't do a normal resume if the port isn't enabled,
|
|
|
|
* so try a reset-resume instead.
|
|
|
|
*/
|
|
|
|
else if (!(portstatus & USB_PORT_STAT_ENABLE) && !udev->reset_resume) {
|
|
|
|
if (udev->persist_enabled)
|
|
|
|
udev->reset_resume = 1;
|
|
|
|
else
|
|
|
|
status = -ENODEV;
|
|
|
|
}
|
2008-04-28 23:06:11 +08:00
|
|
|
|
|
|
|
if (status) {
|
2014-05-21 09:08:17 +08:00
|
|
|
dev_dbg(&port_dev->dev, "status %04x.%04x after resume, %d\n",
|
|
|
|
portchange, portstatus, status);
|
2008-04-28 23:06:11 +08:00
|
|
|
} else if (udev->reset_resume) {
|
|
|
|
|
|
|
|
/* Late port handoff can set status-change bits */
|
|
|
|
if (portchange & USB_PORT_STAT_C_CONNECTION)
|
2013-01-23 04:26:30 +08:00
|
|
|
usb_clear_port_feature(hub->hdev, port1,
|
2008-04-28 23:06:11 +08:00
|
|
|
USB_PORT_FEAT_C_CONNECTION);
|
|
|
|
if (portchange & USB_PORT_STAT_C_ENABLE)
|
2013-01-23 04:26:30 +08:00
|
|
|
usb_clear_port_feature(hub->hdev, port1,
|
2008-04-28 23:06:11 +08:00
|
|
|
USB_PORT_FEAT_C_ENABLE);
|
|
|
|
}
|
|
|
|
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
2012-06-26 03:08:08 +08:00
|
|
|
int usb_disable_ltm(struct usb_device *udev)
|
|
|
|
{
|
|
|
|
struct usb_hcd *hcd = bus_to_hcd(udev->bus);
|
|
|
|
|
|
|
|
/* Check if the roothub and device supports LTM. */
|
|
|
|
if (!usb_device_supports_ltm(hcd->self.root_hub) ||
|
|
|
|
!usb_device_supports_ltm(udev))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* Clear Feature LTM Enable can only be sent if the device is
|
|
|
|
* configured.
|
|
|
|
*/
|
|
|
|
if (!udev->actconfig)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
return usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
|
|
|
|
USB_REQ_CLEAR_FEATURE, USB_RECIP_DEVICE,
|
|
|
|
USB_DEVICE_LTM_ENABLE, 0, NULL, 0,
|
|
|
|
USB_CTRL_SET_TIMEOUT);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(usb_disable_ltm);
|
|
|
|
|
|
|
|
void usb_enable_ltm(struct usb_device *udev)
|
|
|
|
{
|
|
|
|
struct usb_hcd *hcd = bus_to_hcd(udev->bus);
|
|
|
|
|
|
|
|
/* Check if the roothub and device supports LTM. */
|
|
|
|
if (!usb_device_supports_ltm(hcd->self.root_hub) ||
|
|
|
|
!usb_device_supports_ltm(udev))
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* Set Feature LTM Enable can only be sent if the device is
|
|
|
|
* configured.
|
|
|
|
*/
|
|
|
|
if (!udev->actconfig)
|
|
|
|
return;
|
|
|
|
|
|
|
|
usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
|
|
|
|
USB_REQ_SET_FEATURE, USB_RECIP_DEVICE,
|
|
|
|
USB_DEVICE_LTM_ENABLE, 0, NULL, 0,
|
|
|
|
USB_CTRL_SET_TIMEOUT);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(usb_enable_ltm);
|
|
|
|
|
2013-01-24 10:31:28 +08:00
|
|
|
/*
|
2013-07-31 03:37:33 +08:00
|
|
|
* usb_enable_remote_wakeup - enable remote wakeup for a device
|
2013-01-24 10:31:28 +08:00
|
|
|
* @udev: target device
|
|
|
|
*
|
2013-07-31 03:37:33 +08:00
|
|
|
* For USB-2 devices: Set the device's remote wakeup feature.
|
|
|
|
*
|
|
|
|
* For USB-3 devices: Assume there's only one function on the device and
|
|
|
|
* enable remote wake for the first interface. FIXME if the interface
|
|
|
|
* association descriptor shows there's more than one function.
|
2013-01-24 10:31:28 +08:00
|
|
|
*/
|
2013-07-31 03:37:33 +08:00
|
|
|
static int usb_enable_remote_wakeup(struct usb_device *udev)
|
2013-01-24 10:31:28 +08:00
|
|
|
{
|
2013-07-31 03:37:33 +08:00
|
|
|
if (udev->speed < USB_SPEED_SUPER)
|
|
|
|
return usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
|
|
|
|
USB_REQ_SET_FEATURE, USB_RECIP_DEVICE,
|
|
|
|
USB_DEVICE_REMOTE_WAKEUP, 0, NULL, 0,
|
|
|
|
USB_CTRL_SET_TIMEOUT);
|
|
|
|
else
|
|
|
|
return usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
|
|
|
|
USB_REQ_SET_FEATURE, USB_RECIP_INTERFACE,
|
|
|
|
USB_INTRF_FUNC_SUSPEND,
|
|
|
|
USB_INTRF_FUNC_SUSPEND_RW |
|
|
|
|
USB_INTRF_FUNC_SUSPEND_LP,
|
|
|
|
NULL, 0, USB_CTRL_SET_TIMEOUT);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* usb_disable_remote_wakeup - disable remote wakeup for a device
|
|
|
|
* @udev: target device
|
|
|
|
*
|
|
|
|
* For USB-2 devices: Clear the device's remote wakeup feature.
|
|
|
|
*
|
|
|
|
* For USB-3 devices: Assume there's only one function on the device and
|
|
|
|
* disable remote wake for the first interface. FIXME if the interface
|
|
|
|
* association descriptor shows there's more than one function.
|
|
|
|
*/
|
|
|
|
static int usb_disable_remote_wakeup(struct usb_device *udev)
|
|
|
|
{
|
|
|
|
if (udev->speed < USB_SPEED_SUPER)
|
|
|
|
return usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
|
|
|
|
USB_REQ_CLEAR_FEATURE, USB_RECIP_DEVICE,
|
|
|
|
USB_DEVICE_REMOTE_WAKEUP, 0, NULL, 0,
|
|
|
|
USB_CTRL_SET_TIMEOUT);
|
|
|
|
else
|
|
|
|
return usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
|
2013-01-24 10:31:28 +08:00
|
|
|
USB_REQ_CLEAR_FEATURE, USB_RECIP_INTERFACE,
|
|
|
|
USB_INTRF_FUNC_SUSPEND, 0, NULL, 0,
|
|
|
|
USB_CTRL_SET_TIMEOUT);
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2013-07-12 02:58:04 +08:00
|
|
|
/* Count of wakeup-enabled devices at or below udev */
|
|
|
|
static unsigned wakeup_enabled_descendants(struct usb_device *udev)
|
|
|
|
{
|
|
|
|
struct usb_hub *hub = usb_hub_to_struct_hub(udev);
|
|
|
|
|
|
|
|
return udev->do_remote_wakeup +
|
|
|
|
(hub ? hub->wakeup_enabled_descendants : 0);
|
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
2007-05-31 03:35:16 +08:00
|
|
|
* usb_port_suspend - suspend a usb device's upstream port
|
|
|
|
* @udev: device that's no longer in active use, not a root hub
|
|
|
|
* Context: must be able to sleep; device not locked; pm locks held
|
|
|
|
*
|
|
|
|
* Suspends a USB device that isn't in active use, conserving power.
|
|
|
|
* Devices may wake out of a suspend, if anything important happens,
|
|
|
|
* using the remote wakeup mechanism. They may also be taken out of
|
|
|
|
* suspend by the host, using usb_port_resume(). It's also routine
|
|
|
|
* to disconnect devices while they are suspended.
|
|
|
|
*
|
|
|
|
* This only affects the USB hardware for a device; its interfaces
|
|
|
|
* (and, for hubs, child devices) must already have been suspended.
|
|
|
|
*
|
2005-04-17 06:20:36 +08:00
|
|
|
* Selective port suspend reduces power; most suspended devices draw
|
|
|
|
* less than 500 uA. It's also used in OTG, along with remote wakeup.
|
|
|
|
* All devices below the suspended port are also suspended.
|
|
|
|
*
|
|
|
|
* Devices leave suspend state when the host wakes them up. Some devices
|
|
|
|
* also support "remote wakeup", where the device can activate the USB
|
|
|
|
* tree above them to deliver data, such as a keypress or packet. In
|
|
|
|
* some cases, this wakes the USB host.
|
2007-05-31 03:35:16 +08:00
|
|
|
*
|
|
|
|
* Suspending OTG devices may trigger HNP, if that's been enabled
|
|
|
|
* between a pair of dual-role devices. That will change roles, such
|
|
|
|
* as from A-Host to A-Peripheral or from B-Host back to B-Peripheral.
|
|
|
|
*
|
|
|
|
* Devices on USB hub ports have only one "suspend" state, corresponding
|
|
|
|
* to ACPI D2, "may cause the device to lose some context".
|
|
|
|
* State transitions include:
|
|
|
|
*
|
|
|
|
* - suspend, resume ... when the VBUS power link stays live
|
|
|
|
* - suspend, disconnect ... VBUS lost
|
|
|
|
*
|
|
|
|
* Once VBUS drop breaks the circuit, the port it's using has to go through
|
|
|
|
* normal re-enumeration procedures, starting with enabling VBUS power.
|
|
|
|
* Other than re-initializing the hub (plug/unplug, except for root hubs),
|
2014-09-19 23:32:23 +08:00
|
|
|
* Linux (2.6) currently has NO mechanisms to initiate that: no hub_wq
|
2007-05-31 03:35:16 +08:00
|
|
|
* timer, no SRP, no requests through sysfs.
|
|
|
|
*
|
2013-07-12 02:58:04 +08:00
|
|
|
* If Runtime PM isn't enabled or used, non-SuperSpeed devices may not get
|
|
|
|
* suspended until their bus goes into global suspend (i.e., the root
|
2013-03-28 04:14:19 +08:00
|
|
|
* hub is suspended). Nevertheless, we change @udev->state to
|
|
|
|
* USB_STATE_SUSPENDED as this is the device's "logical" state. The actual
|
|
|
|
* upstream port setting is stored in @udev->port_is_suspended.
|
2007-05-31 03:35:16 +08:00
|
|
|
*
|
|
|
|
* Returns 0 on success, else negative errno.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
2008-11-26 05:39:18 +08:00
|
|
|
int usb_port_suspend(struct usb_device *udev, pm_message_t msg)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2013-01-23 04:26:30 +08:00
|
|
|
struct usb_hub *hub = usb_hub_to_struct_hub(udev->parent);
|
|
|
|
struct usb_port *port_dev = hub->ports[udev->portnum - 1];
|
2007-05-31 03:35:16 +08:00
|
|
|
int port1 = udev->portnum;
|
|
|
|
int status;
|
2013-03-28 04:14:19 +08:00
|
|
|
bool really_suspend = true;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2014-05-21 09:09:26 +08:00
|
|
|
usb_lock_port(port_dev);
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/* enable remote wakeup when appropriate; this lets the device
|
|
|
|
* wake up the upstream hub (including maybe the root hub).
|
|
|
|
*
|
|
|
|
* NOTE: OTG devices may issue remote wakeup (or SRP) even when
|
|
|
|
* we don't explicitly enable it here.
|
|
|
|
*/
|
2006-08-31 03:47:02 +08:00
|
|
|
if (udev->do_remote_wakeup) {
|
2013-07-31 03:37:33 +08:00
|
|
|
status = usb_enable_remote_wakeup(udev);
|
2009-10-19 19:19:41 +08:00
|
|
|
if (status) {
|
2007-05-31 03:35:16 +08:00
|
|
|
dev_dbg(&udev->dev, "won't remote wakeup, status %d\n",
|
|
|
|
status);
|
2009-10-19 19:19:41 +08:00
|
|
|
/* bail if autosuspend is requested */
|
2011-08-20 05:49:48 +08:00
|
|
|
if (PMSG_IS_AUTO(msg))
|
2013-07-31 03:39:02 +08:00
|
|
|
goto err_wakeup;
|
2009-10-19 19:19:41 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2011-09-24 05:19:52 +08:00
|
|
|
/* disable USB2 hardware LPM */
|
|
|
|
if (udev->usb2_hw_lpm_enabled == 1)
|
|
|
|
usb_set_usb2_hardware_lpm(udev, 0);
|
|
|
|
|
2012-06-26 03:08:08 +08:00
|
|
|
if (usb_disable_ltm(udev)) {
|
2013-07-31 03:39:02 +08:00
|
|
|
dev_err(&udev->dev, "Failed to disable LTM before suspend\n.");
|
|
|
|
status = -ENOMEM;
|
|
|
|
if (PMSG_IS_AUTO(msg))
|
|
|
|
goto err_ltm;
|
2012-06-26 03:08:08 +08:00
|
|
|
}
|
USB: Disable USB 3.0 LPM in critical sections.
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-05-03 05:25:52 +08:00
|
|
|
if (usb_unlocked_disable_lpm(udev)) {
|
2013-07-31 03:39:02 +08:00
|
|
|
dev_err(&udev->dev, "Failed to disable LPM before suspend\n.");
|
|
|
|
status = -ENOMEM;
|
|
|
|
if (PMSG_IS_AUTO(msg))
|
|
|
|
goto err_lpm3;
|
USB: Disable USB 3.0 LPM in critical sections.
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-05-03 05:25:52 +08:00
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/* see 7.1.7.6 */
|
2011-04-27 18:07:50 +08:00
|
|
|
if (hub_is_superspeed(hub->hdev))
|
2012-12-11 07:43:08 +08:00
|
|
|
status = hub_set_port_link_state(hub, port1, USB_SS_PORT_LS_U3);
|
2013-07-12 02:58:04 +08:00
|
|
|
|
2013-03-28 04:14:19 +08:00
|
|
|
/*
|
|
|
|
* For system suspend, we do not need to enable the suspend feature
|
|
|
|
* on individual USB-2 ports. The devices will automatically go
|
|
|
|
* into suspend a few ms after the root hub stops sending packets.
|
|
|
|
* The USB 2.0 spec calls this "global suspend".
|
2013-07-12 02:58:04 +08:00
|
|
|
*
|
|
|
|
* However, many USB hubs have a bug: They don't relay wakeup requests
|
|
|
|
* from a downstream port if the port's suspend feature isn't on.
|
|
|
|
* Therefore we will turn on the suspend feature if udev or any of its
|
|
|
|
* descendants is enabled for remote wakeup.
|
2013-03-28 04:14:19 +08:00
|
|
|
*/
|
2013-07-12 02:58:04 +08:00
|
|
|
else if (PMSG_IS_AUTO(msg) || wakeup_enabled_descendants(udev) > 0)
|
|
|
|
status = set_port_feature(hub->hdev, port1,
|
|
|
|
USB_PORT_FEAT_SUSPEND);
|
2013-03-28 04:14:19 +08:00
|
|
|
else {
|
|
|
|
really_suspend = false;
|
|
|
|
status = 0;
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
if (status) {
|
2014-05-21 09:08:17 +08:00
|
|
|
dev_dbg(&port_dev->dev, "can't suspend, status %d\n", status);
|
2011-06-16 04:29:16 +08:00
|
|
|
|
2013-07-31 03:39:02 +08:00
|
|
|
/* Try to enable USB3 LPM and LTM again */
|
|
|
|
usb_unlocked_enable_lpm(udev);
|
|
|
|
err_lpm3:
|
|
|
|
usb_enable_ltm(udev);
|
|
|
|
err_ltm:
|
2012-05-05 00:50:10 +08:00
|
|
|
/* Try to enable USB2 hardware LPM again */
|
|
|
|
if (udev->usb2_hw_lpm_capable == 1)
|
|
|
|
usb_set_usb2_hardware_lpm(udev, 1);
|
|
|
|
|
2013-07-31 03:39:02 +08:00
|
|
|
if (udev->do_remote_wakeup)
|
|
|
|
(void) usb_disable_remote_wakeup(udev);
|
|
|
|
err_wakeup:
|
USB: Disable USB 3.0 LPM in critical sections.
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-05-03 05:25:52 +08:00
|
|
|
|
2011-06-16 04:29:16 +08:00
|
|
|
/* System sleep transitions should never fail */
|
2011-08-20 05:49:48 +08:00
|
|
|
if (!PMSG_IS_AUTO(msg))
|
2011-06-16 04:29:16 +08:00
|
|
|
status = 0;
|
2005-04-17 06:20:36 +08:00
|
|
|
} else {
|
2011-09-28 03:54:22 +08:00
|
|
|
dev_dbg(&udev->dev, "usb %ssuspend, wakeup %d\n",
|
|
|
|
(PMSG_IS_AUTO(msg) ? "auto-" : ""),
|
|
|
|
udev->do_remote_wakeup);
|
2013-03-28 04:14:19 +08:00
|
|
|
if (really_suspend) {
|
|
|
|
udev->port_is_suspended = 1;
|
2013-07-12 02:58:04 +08:00
|
|
|
|
|
|
|
/* device has up to 10 msec to fully suspend */
|
2013-03-28 04:14:19 +08:00
|
|
|
msleep(10);
|
|
|
|
}
|
2013-07-12 02:58:04 +08:00
|
|
|
usb_set_device_state(udev, USB_STATE_SUSPENDED);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2013-01-23 04:26:30 +08:00
|
|
|
|
2014-05-21 09:08:52 +08:00
|
|
|
if (status == 0 && !udev->do_remote_wakeup && udev->persist_enabled
|
|
|
|
&& test_and_clear_bit(port1, hub->child_usage_bits))
|
2013-07-03 22:17:54 +08:00
|
|
|
pm_runtime_put_sync(&port_dev->dev);
|
2013-01-23 04:26:30 +08:00
|
|
|
|
2010-11-16 04:57:58 +08:00
|
|
|
usb_mark_last_busy(hub->hdev);
|
2014-05-21 09:09:26 +08:00
|
|
|
|
|
|
|
usb_unlock_port(port_dev);
|
2005-04-17 06:20:36 +08:00
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2005-09-14 10:57:27 +08:00
|
|
|
* If the USB "suspend" state is in use (rather than "global suspend"),
|
|
|
|
* many devices will be individually taken out of suspend state using
|
2007-05-31 03:38:58 +08:00
|
|
|
* special "resume" signaling. This routine kicks in shortly after
|
2005-04-17 06:20:36 +08:00
|
|
|
* hardware resume signaling is finished, either because of selective
|
|
|
|
* resume (by host) or remote wakeup (by device) ... now see what changed
|
|
|
|
* in the tree that's rooted at this device.
|
2007-05-31 03:38:58 +08:00
|
|
|
*
|
|
|
|
* If @udev->reset_resume is set then the device is reset before the
|
|
|
|
* status check is done.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
2006-07-02 10:07:21 +08:00
|
|
|
static int finish_port_resume(struct usb_device *udev)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2007-05-31 03:38:58 +08:00
|
|
|
int status = 0;
|
2012-11-29 22:05:57 +08:00
|
|
|
u16 devstatus = 0;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/* caller owns the udev device lock */
|
2008-12-15 15:32:01 +08:00
|
|
|
dev_dbg(&udev->dev, "%s\n",
|
|
|
|
udev->reset_resume ? "finish reset-resume" : "finish resume");
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/* usb ch9 identifies four variants of SUSPENDED, based on what
|
|
|
|
* state the device resumes to. Linux currently won't see the
|
|
|
|
* first two on the host side; they'd be inside hub_port_init()
|
2014-09-19 23:32:23 +08:00
|
|
|
* during many timeouts, but hub_wq can't suspend until later.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
|
|
|
usb_set_device_state(udev, udev->actconfig
|
|
|
|
? USB_STATE_CONFIGURED
|
|
|
|
: USB_STATE_ADDRESS);
|
|
|
|
|
2007-05-31 03:38:58 +08:00
|
|
|
/* 10.5.4.5 says not to reset a suspended port if the attached
|
|
|
|
* device is enabled for remote wakeup. Hence the reset
|
|
|
|
* operation is carried out here, after the port has been
|
|
|
|
* resumed.
|
|
|
|
*/
|
2014-03-18 22:39:05 +08:00
|
|
|
if (udev->reset_resume) {
|
|
|
|
/*
|
|
|
|
* If the device morphs or switches modes when it is reset,
|
|
|
|
* we don't want to perform a reset-resume. We'll fail the
|
|
|
|
* resume, which will cause a logical disconnect, and then
|
|
|
|
* the device will be rediscovered.
|
|
|
|
*/
|
2008-06-30 23:14:43 +08:00
|
|
|
retry_reset_resume:
|
2014-03-18 22:39:05 +08:00
|
|
|
if (udev->quirks & USB_QUIRK_RESET)
|
|
|
|
status = -ENODEV;
|
|
|
|
else
|
|
|
|
status = usb_reset_and_verify_device(udev);
|
|
|
|
}
|
2007-05-31 03:38:58 +08:00
|
|
|
|
2013-10-11 05:41:27 +08:00
|
|
|
/* 10.5.4.5 says be sure devices in the tree are still there.
|
|
|
|
* For now let's assume the device didn't go crazy on resume,
|
2005-04-17 06:20:36 +08:00
|
|
|
* and device drivers will know about any resume quirks.
|
|
|
|
*/
|
2007-05-31 03:38:58 +08:00
|
|
|
if (status == 0) {
|
2007-08-14 22:56:10 +08:00
|
|
|
devstatus = 0;
|
2007-05-31 03:38:58 +08:00
|
|
|
status = usb_get_status(udev, USB_RECIP_DEVICE, 0, &devstatus);
|
2008-06-30 23:14:43 +08:00
|
|
|
|
|
|
|
/* If a normal resume failed, try doing a reset-resume */
|
|
|
|
if (status && !udev->reset_resume && udev->persist_enabled) {
|
|
|
|
dev_dbg(&udev->dev, "retry with reset-resume\n");
|
|
|
|
udev->reset_resume = 1;
|
|
|
|
goto retry_reset_resume;
|
|
|
|
}
|
2007-05-31 03:38:58 +08:00
|
|
|
}
|
2006-06-20 03:12:38 +08:00
|
|
|
|
2007-05-31 03:35:16 +08:00
|
|
|
if (status) {
|
|
|
|
dev_dbg(&udev->dev, "gone after usb resume? status %d\n",
|
|
|
|
status);
|
2012-11-29 22:05:57 +08:00
|
|
|
/*
|
|
|
|
* There are a few quirky devices which violate the standard
|
|
|
|
* by claiming to have remote wakeup enabled after a reset,
|
|
|
|
* which crash if the feature is cleared, hence check for
|
|
|
|
* udev->reset_resume
|
|
|
|
*/
|
|
|
|
} else if (udev->actconfig && !udev->reset_resume) {
|
2013-07-31 03:37:33 +08:00
|
|
|
if (udev->speed < USB_SPEED_SUPER) {
|
2013-01-24 10:31:28 +08:00
|
|
|
if (devstatus & (1 << USB_DEVICE_REMOTE_WAKEUP))
|
2013-07-31 03:37:33 +08:00
|
|
|
status = usb_disable_remote_wakeup(udev);
|
2013-01-24 10:31:28 +08:00
|
|
|
} else {
|
|
|
|
status = usb_get_status(udev, USB_RECIP_INTERFACE, 0,
|
|
|
|
&devstatus);
|
|
|
|
if (!status && devstatus & (USB_INTRF_STAT_FUNC_RW_CAP
|
|
|
|
| USB_INTRF_STAT_FUNC_RW))
|
2013-07-31 03:37:33 +08:00
|
|
|
status = usb_disable_remote_wakeup(udev);
|
2005-11-22 00:58:07 +08:00
|
|
|
}
|
2013-01-24 10:31:28 +08:00
|
|
|
|
|
|
|
if (status)
|
|
|
|
dev_dbg(&udev->dev,
|
|
|
|
"disable remote wakeup, status %d\n",
|
|
|
|
status);
|
2005-04-17 06:20:36 +08:00
|
|
|
status = 0;
|
|
|
|
}
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
USB: Fix persist resume of some SS USB devices
Problem Summary: Problem has been observed generally with PM states
where VBUS goes off during suspend. There are some SS USB devices which
take longer time for link training compared to many others. Such
devices fail to reconnect with same old address which was associated
with it before suspend.
When system resumes, at some point of time (dpm_run_callback->
usb_dev_resume->usb_resume->usb_resume_both->usb_resume_device->
usb_port_resume) SW reads hub status. If device is present,
then it finishes port resume and re-enumerates device with same
address. If device is not present then, SW thinks that device was
removed during suspend and therefore does logical disconnection
and removes all the resource allocated for this device.
Now, if I put sufficient delay just before root hub status read in
usb_resume_device then, SW sees always that device is present. In normal
course(without any delay) SW sees that no device is present and then SW
removes all resource associated with the device at this port. In the
latter case, after sometime, device says that hey I am here, now host
enumerates it, but with new address.
Problem had been reproduced when I connect verbatim USB3.0 hard disc
with my STiH407 XHCI host running with 3.10 kernel.
I see that similar problem has been reported here.
https://bugzilla.kernel.org/show_bug.cgi?id=53211
Reading above it seems that bug was not in 3.6.6 and was present in 3.8
and again it was not present for some in 3.12.6, while it was present
for few others. I tested with 3.13-FC19 running at i686 desktop, problem
was still there. However, I was failed to reproduce it with 3.16-RC4
running at same i686 machine. I would say it is just a random
observation. Problem for few devices is always there, as I am unable to
find a proper fix for the issue.
So, now question is what should be the amount of delay so that host is
always able to recognize suspended device after resume.
XHCI specs 4.19.4 says that when Link training is successful, port sets
CSC bit to 1. So if SW reads port status before successful link
training, then it will not find device to be present. USB Analyzer log
with such buggy devices show that in some cases device switch on the
RX termination after long delay of host enabling the VBUS. In few other
cases it has been seen that device fails to negotiate link training in
first attempt. It has been reported till now that few devices take as
long as 2000 ms to train the link after host enabling its VBUS and
RX termination. This patch implements a 2000 ms timeout for CSC bit to set
ie for link training. If in a case link trains before timeout, loop will
exit earlier.
This patch implements above delay, but only for SS device and when
persist is enabled.
So, for the good device overhead is almost none. While for the bad
devices penalty could be the time which it take for link training.
But, If a device was connected before suspend, and was removed
while system was asleep, then the penalty would be the timeout ie
2000 ms.
Results:
Verbatim USB SS hard disk connected with STiH407 USB host running 3.10
Kernel resumes in 461 msecs without this patch, but hard disk is
assigned a new device address. Same system resumes in 790 msecs with
this patch, but with old device address.
Cc: <stable@vger.kernel.org>
Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-18 15:07:10 +08:00
|
|
|
/*
|
|
|
|
* There are some SS USB devices which take longer time for link training.
|
|
|
|
* XHCI specs 4.19.4 says that when Link training is successful, port
|
2015-12-03 03:55:07 +08:00
|
|
|
* sets CCS bit to 1. So if SW reads port status before successful link
|
USB: Fix persist resume of some SS USB devices
Problem Summary: Problem has been observed generally with PM states
where VBUS goes off during suspend. There are some SS USB devices which
take longer time for link training compared to many others. Such
devices fail to reconnect with same old address which was associated
with it before suspend.
When system resumes, at some point of time (dpm_run_callback->
usb_dev_resume->usb_resume->usb_resume_both->usb_resume_device->
usb_port_resume) SW reads hub status. If device is present,
then it finishes port resume and re-enumerates device with same
address. If device is not present then, SW thinks that device was
removed during suspend and therefore does logical disconnection
and removes all the resource allocated for this device.
Now, if I put sufficient delay just before root hub status read in
usb_resume_device then, SW sees always that device is present. In normal
course(without any delay) SW sees that no device is present and then SW
removes all resource associated with the device at this port. In the
latter case, after sometime, device says that hey I am here, now host
enumerates it, but with new address.
Problem had been reproduced when I connect verbatim USB3.0 hard disc
with my STiH407 XHCI host running with 3.10 kernel.
I see that similar problem has been reported here.
https://bugzilla.kernel.org/show_bug.cgi?id=53211
Reading above it seems that bug was not in 3.6.6 and was present in 3.8
and again it was not present for some in 3.12.6, while it was present
for few others. I tested with 3.13-FC19 running at i686 desktop, problem
was still there. However, I was failed to reproduce it with 3.16-RC4
running at same i686 machine. I would say it is just a random
observation. Problem for few devices is always there, as I am unable to
find a proper fix for the issue.
So, now question is what should be the amount of delay so that host is
always able to recognize suspended device after resume.
XHCI specs 4.19.4 says that when Link training is successful, port sets
CSC bit to 1. So if SW reads port status before successful link
training, then it will not find device to be present. USB Analyzer log
with such buggy devices show that in some cases device switch on the
RX termination after long delay of host enabling the VBUS. In few other
cases it has been seen that device fails to negotiate link training in
first attempt. It has been reported till now that few devices take as
long as 2000 ms to train the link after host enabling its VBUS and
RX termination. This patch implements a 2000 ms timeout for CSC bit to set
ie for link training. If in a case link trains before timeout, loop will
exit earlier.
This patch implements above delay, but only for SS device and when
persist is enabled.
So, for the good device overhead is almost none. While for the bad
devices penalty could be the time which it take for link training.
But, If a device was connected before suspend, and was removed
while system was asleep, then the penalty would be the timeout ie
2000 ms.
Results:
Verbatim USB SS hard disk connected with STiH407 USB host running 3.10
Kernel resumes in 461 msecs without this patch, but hard disk is
assigned a new device address. Same system resumes in 790 msecs with
this patch, but with old device address.
Cc: <stable@vger.kernel.org>
Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-18 15:07:10 +08:00
|
|
|
* training, then it will not find device to be present.
|
|
|
|
* USB Analyzer log with such buggy devices show that in some cases
|
|
|
|
* device switch on the RX termination after long delay of host enabling
|
|
|
|
* the VBUS. In few other cases it has been seen that device fails to
|
|
|
|
* negotiate link training in first attempt. It has been
|
|
|
|
* reported till now that few devices take as long as 2000 ms to train
|
|
|
|
* the link after host enabling its VBUS and termination. Following
|
|
|
|
* routine implements a 2000 ms timeout for link training. If in a case
|
|
|
|
* link trains before timeout, loop will exit earlier.
|
|
|
|
*
|
2015-12-03 03:55:07 +08:00
|
|
|
* There are also some 2.0 hard drive based devices and 3.0 thumb
|
|
|
|
* drives that, when plugged into a 2.0 only port, take a long
|
|
|
|
* time to set CCS after VBUS enable.
|
|
|
|
*
|
USB: Fix persist resume of some SS USB devices
Problem Summary: Problem has been observed generally with PM states
where VBUS goes off during suspend. There are some SS USB devices which
take longer time for link training compared to many others. Such
devices fail to reconnect with same old address which was associated
with it before suspend.
When system resumes, at some point of time (dpm_run_callback->
usb_dev_resume->usb_resume->usb_resume_both->usb_resume_device->
usb_port_resume) SW reads hub status. If device is present,
then it finishes port resume and re-enumerates device with same
address. If device is not present then, SW thinks that device was
removed during suspend and therefore does logical disconnection
and removes all the resource allocated for this device.
Now, if I put sufficient delay just before root hub status read in
usb_resume_device then, SW sees always that device is present. In normal
course(without any delay) SW sees that no device is present and then SW
removes all resource associated with the device at this port. In the
latter case, after sometime, device says that hey I am here, now host
enumerates it, but with new address.
Problem had been reproduced when I connect verbatim USB3.0 hard disc
with my STiH407 XHCI host running with 3.10 kernel.
I see that similar problem has been reported here.
https://bugzilla.kernel.org/show_bug.cgi?id=53211
Reading above it seems that bug was not in 3.6.6 and was present in 3.8
and again it was not present for some in 3.12.6, while it was present
for few others. I tested with 3.13-FC19 running at i686 desktop, problem
was still there. However, I was failed to reproduce it with 3.16-RC4
running at same i686 machine. I would say it is just a random
observation. Problem for few devices is always there, as I am unable to
find a proper fix for the issue.
So, now question is what should be the amount of delay so that host is
always able to recognize suspended device after resume.
XHCI specs 4.19.4 says that when Link training is successful, port sets
CSC bit to 1. So if SW reads port status before successful link
training, then it will not find device to be present. USB Analyzer log
with such buggy devices show that in some cases device switch on the
RX termination after long delay of host enabling the VBUS. In few other
cases it has been seen that device fails to negotiate link training in
first attempt. It has been reported till now that few devices take as
long as 2000 ms to train the link after host enabling its VBUS and
RX termination. This patch implements a 2000 ms timeout for CSC bit to set
ie for link training. If in a case link trains before timeout, loop will
exit earlier.
This patch implements above delay, but only for SS device and when
persist is enabled.
So, for the good device overhead is almost none. While for the bad
devices penalty could be the time which it take for link training.
But, If a device was connected before suspend, and was removed
while system was asleep, then the penalty would be the timeout ie
2000 ms.
Results:
Verbatim USB SS hard disk connected with STiH407 USB host running 3.10
Kernel resumes in 461 msecs without this patch, but hard disk is
assigned a new device address. Same system resumes in 790 msecs with
this patch, but with old device address.
Cc: <stable@vger.kernel.org>
Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-18 15:07:10 +08:00
|
|
|
* FIXME: If a device was connected before suspend, but was removed
|
|
|
|
* while system was asleep, then the loop in the following routine will
|
|
|
|
* only exit at timeout.
|
|
|
|
*
|
2015-12-03 03:55:07 +08:00
|
|
|
* This routine should only be called when persist is enabled.
|
USB: Fix persist resume of some SS USB devices
Problem Summary: Problem has been observed generally with PM states
where VBUS goes off during suspend. There are some SS USB devices which
take longer time for link training compared to many others. Such
devices fail to reconnect with same old address which was associated
with it before suspend.
When system resumes, at some point of time (dpm_run_callback->
usb_dev_resume->usb_resume->usb_resume_both->usb_resume_device->
usb_port_resume) SW reads hub status. If device is present,
then it finishes port resume and re-enumerates device with same
address. If device is not present then, SW thinks that device was
removed during suspend and therefore does logical disconnection
and removes all the resource allocated for this device.
Now, if I put sufficient delay just before root hub status read in
usb_resume_device then, SW sees always that device is present. In normal
course(without any delay) SW sees that no device is present and then SW
removes all resource associated with the device at this port. In the
latter case, after sometime, device says that hey I am here, now host
enumerates it, but with new address.
Problem had been reproduced when I connect verbatim USB3.0 hard disc
with my STiH407 XHCI host running with 3.10 kernel.
I see that similar problem has been reported here.
https://bugzilla.kernel.org/show_bug.cgi?id=53211
Reading above it seems that bug was not in 3.6.6 and was present in 3.8
and again it was not present for some in 3.12.6, while it was present
for few others. I tested with 3.13-FC19 running at i686 desktop, problem
was still there. However, I was failed to reproduce it with 3.16-RC4
running at same i686 machine. I would say it is just a random
observation. Problem for few devices is always there, as I am unable to
find a proper fix for the issue.
So, now question is what should be the amount of delay so that host is
always able to recognize suspended device after resume.
XHCI specs 4.19.4 says that when Link training is successful, port sets
CSC bit to 1. So if SW reads port status before successful link
training, then it will not find device to be present. USB Analyzer log
with such buggy devices show that in some cases device switch on the
RX termination after long delay of host enabling the VBUS. In few other
cases it has been seen that device fails to negotiate link training in
first attempt. It has been reported till now that few devices take as
long as 2000 ms to train the link after host enabling its VBUS and
RX termination. This patch implements a 2000 ms timeout for CSC bit to set
ie for link training. If in a case link trains before timeout, loop will
exit earlier.
This patch implements above delay, but only for SS device and when
persist is enabled.
So, for the good device overhead is almost none. While for the bad
devices penalty could be the time which it take for link training.
But, If a device was connected before suspend, and was removed
while system was asleep, then the penalty would be the timeout ie
2000 ms.
Results:
Verbatim USB SS hard disk connected with STiH407 USB host running 3.10
Kernel resumes in 461 msecs without this patch, but hard disk is
assigned a new device address. Same system resumes in 790 msecs with
this patch, but with old device address.
Cc: <stable@vger.kernel.org>
Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-18 15:07:10 +08:00
|
|
|
*/
|
2015-12-03 03:55:07 +08:00
|
|
|
static int wait_for_connected(struct usb_device *udev,
|
USB: Fix persist resume of some SS USB devices
Problem Summary: Problem has been observed generally with PM states
where VBUS goes off during suspend. There are some SS USB devices which
take longer time for link training compared to many others. Such
devices fail to reconnect with same old address which was associated
with it before suspend.
When system resumes, at some point of time (dpm_run_callback->
usb_dev_resume->usb_resume->usb_resume_both->usb_resume_device->
usb_port_resume) SW reads hub status. If device is present,
then it finishes port resume and re-enumerates device with same
address. If device is not present then, SW thinks that device was
removed during suspend and therefore does logical disconnection
and removes all the resource allocated for this device.
Now, if I put sufficient delay just before root hub status read in
usb_resume_device then, SW sees always that device is present. In normal
course(without any delay) SW sees that no device is present and then SW
removes all resource associated with the device at this port. In the
latter case, after sometime, device says that hey I am here, now host
enumerates it, but with new address.
Problem had been reproduced when I connect verbatim USB3.0 hard disc
with my STiH407 XHCI host running with 3.10 kernel.
I see that similar problem has been reported here.
https://bugzilla.kernel.org/show_bug.cgi?id=53211
Reading above it seems that bug was not in 3.6.6 and was present in 3.8
and again it was not present for some in 3.12.6, while it was present
for few others. I tested with 3.13-FC19 running at i686 desktop, problem
was still there. However, I was failed to reproduce it with 3.16-RC4
running at same i686 machine. I would say it is just a random
observation. Problem for few devices is always there, as I am unable to
find a proper fix for the issue.
So, now question is what should be the amount of delay so that host is
always able to recognize suspended device after resume.
XHCI specs 4.19.4 says that when Link training is successful, port sets
CSC bit to 1. So if SW reads port status before successful link
training, then it will not find device to be present. USB Analyzer log
with such buggy devices show that in some cases device switch on the
RX termination after long delay of host enabling the VBUS. In few other
cases it has been seen that device fails to negotiate link training in
first attempt. It has been reported till now that few devices take as
long as 2000 ms to train the link after host enabling its VBUS and
RX termination. This patch implements a 2000 ms timeout for CSC bit to set
ie for link training. If in a case link trains before timeout, loop will
exit earlier.
This patch implements above delay, but only for SS device and when
persist is enabled.
So, for the good device overhead is almost none. While for the bad
devices penalty could be the time which it take for link training.
But, If a device was connected before suspend, and was removed
while system was asleep, then the penalty would be the timeout ie
2000 ms.
Results:
Verbatim USB SS hard disk connected with STiH407 USB host running 3.10
Kernel resumes in 461 msecs without this patch, but hard disk is
assigned a new device address. Same system resumes in 790 msecs with
this patch, but with old device address.
Cc: <stable@vger.kernel.org>
Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-18 15:07:10 +08:00
|
|
|
struct usb_hub *hub, int *port1,
|
|
|
|
u16 *portchange, u16 *portstatus)
|
|
|
|
{
|
|
|
|
int status = 0, delay_ms = 0;
|
|
|
|
|
|
|
|
while (delay_ms < 2000) {
|
|
|
|
if (status || *portstatus & USB_PORT_STAT_CONNECTION)
|
|
|
|
break;
|
|
|
|
msleep(20);
|
|
|
|
delay_ms += 20;
|
|
|
|
status = hub_port_status(hub, *port1, portstatus, portchange);
|
|
|
|
}
|
2015-12-03 03:55:07 +08:00
|
|
|
dev_dbg(&udev->dev, "Waited %dms for CONNECT\n", delay_ms);
|
USB: Fix persist resume of some SS USB devices
Problem Summary: Problem has been observed generally with PM states
where VBUS goes off during suspend. There are some SS USB devices which
take longer time for link training compared to many others. Such
devices fail to reconnect with same old address which was associated
with it before suspend.
When system resumes, at some point of time (dpm_run_callback->
usb_dev_resume->usb_resume->usb_resume_both->usb_resume_device->
usb_port_resume) SW reads hub status. If device is present,
then it finishes port resume and re-enumerates device with same
address. If device is not present then, SW thinks that device was
removed during suspend and therefore does logical disconnection
and removes all the resource allocated for this device.
Now, if I put sufficient delay just before root hub status read in
usb_resume_device then, SW sees always that device is present. In normal
course(without any delay) SW sees that no device is present and then SW
removes all resource associated with the device at this port. In the
latter case, after sometime, device says that hey I am here, now host
enumerates it, but with new address.
Problem had been reproduced when I connect verbatim USB3.0 hard disc
with my STiH407 XHCI host running with 3.10 kernel.
I see that similar problem has been reported here.
https://bugzilla.kernel.org/show_bug.cgi?id=53211
Reading above it seems that bug was not in 3.6.6 and was present in 3.8
and again it was not present for some in 3.12.6, while it was present
for few others. I tested with 3.13-FC19 running at i686 desktop, problem
was still there. However, I was failed to reproduce it with 3.16-RC4
running at same i686 machine. I would say it is just a random
observation. Problem for few devices is always there, as I am unable to
find a proper fix for the issue.
So, now question is what should be the amount of delay so that host is
always able to recognize suspended device after resume.
XHCI specs 4.19.4 says that when Link training is successful, port sets
CSC bit to 1. So if SW reads port status before successful link
training, then it will not find device to be present. USB Analyzer log
with such buggy devices show that in some cases device switch on the
RX termination after long delay of host enabling the VBUS. In few other
cases it has been seen that device fails to negotiate link training in
first attempt. It has been reported till now that few devices take as
long as 2000 ms to train the link after host enabling its VBUS and
RX termination. This patch implements a 2000 ms timeout for CSC bit to set
ie for link training. If in a case link trains before timeout, loop will
exit earlier.
This patch implements above delay, but only for SS device and when
persist is enabled.
So, for the good device overhead is almost none. While for the bad
devices penalty could be the time which it take for link training.
But, If a device was connected before suspend, and was removed
while system was asleep, then the penalty would be the timeout ie
2000 ms.
Results:
Verbatim USB SS hard disk connected with STiH407 USB host running 3.10
Kernel resumes in 461 msecs without this patch, but hard disk is
assigned a new device address. Same system resumes in 790 msecs with
this patch, but with old device address.
Cc: <stable@vger.kernel.org>
Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-18 15:07:10 +08:00
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
2007-05-31 03:35:16 +08:00
|
|
|
/*
|
|
|
|
* usb_port_resume - re-activate a suspended usb device's upstream port
|
|
|
|
* @udev: device to re-activate, not a root hub
|
|
|
|
* Context: must be able to sleep; device not locked; pm locks held
|
|
|
|
*
|
|
|
|
* This will re-activate the suspended device, increasing power usage
|
|
|
|
* while letting drivers communicate again with its endpoints.
|
|
|
|
* USB resume explicitly guarantees that the power session between
|
|
|
|
* the host and the device is the same as it was when the device
|
|
|
|
* suspended.
|
|
|
|
*
|
2008-03-04 04:15:59 +08:00
|
|
|
* If @udev->reset_resume is set then this routine won't check that the
|
|
|
|
* port is still enabled. Furthermore, finish_port_resume() above will
|
2007-05-31 03:38:58 +08:00
|
|
|
* reset @udev. The end result is that a broken power session can be
|
|
|
|
* recovered and @udev will appear to persist across a loss of VBUS power.
|
|
|
|
*
|
|
|
|
* For example, if a host controller doesn't maintain VBUS suspend current
|
|
|
|
* during a system sleep or is reset when the system wakes up, all the USB
|
|
|
|
* power sessions below it will be broken. This is especially troublesome
|
|
|
|
* for mass-storage devices containing mounted filesystems, since the
|
|
|
|
* device will appear to have disconnected and all the memory mappings
|
|
|
|
* to it will be lost. Using the USB_PERSIST facility, the device can be
|
|
|
|
* made to appear as if it had not disconnected.
|
|
|
|
*
|
2008-06-18 22:00:29 +08:00
|
|
|
* This facility can be dangerous. Although usb_reset_and_verify_device() makes
|
2008-03-04 04:15:59 +08:00
|
|
|
* every effort to insure that the same device is present after the
|
2007-05-31 03:38:58 +08:00
|
|
|
* reset as before, it cannot provide a 100% guarantee. Furthermore it's
|
|
|
|
* quite possible for a device to remain unaltered but its media to be
|
|
|
|
* changed. If the user replaces a flash memory card while the system is
|
|
|
|
* asleep, he will have only himself to blame when the filesystem on the
|
|
|
|
* new card is corrupted and the system crashes.
|
|
|
|
*
|
2007-05-31 03:35:16 +08:00
|
|
|
* Returns 0 on success, else negative errno.
|
|
|
|
*/
|
2008-11-26 05:39:18 +08:00
|
|
|
int usb_port_resume(struct usb_device *udev, pm_message_t msg)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2013-01-23 04:26:30 +08:00
|
|
|
struct usb_hub *hub = usb_hub_to_struct_hub(udev->parent);
|
|
|
|
struct usb_port *port_dev = hub->ports[udev->portnum - 1];
|
2007-05-31 03:35:16 +08:00
|
|
|
int port1 = udev->portnum;
|
|
|
|
int status;
|
|
|
|
u16 portchange, portstatus;
|
2006-11-21 00:14:30 +08:00
|
|
|
|
2014-05-21 09:08:52 +08:00
|
|
|
if (!test_and_set_bit(port1, hub->child_usage_bits)) {
|
2013-01-23 04:26:30 +08:00
|
|
|
status = pm_runtime_get_sync(&port_dev->dev);
|
|
|
|
if (status < 0) {
|
|
|
|
dev_dbg(&udev->dev, "can't resume usb port, status %d\n",
|
|
|
|
status);
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-05-21 09:09:26 +08:00
|
|
|
usb_lock_port(port_dev);
|
|
|
|
|
2006-11-21 00:14:30 +08:00
|
|
|
/* Skip the initial Clear-Suspend step for a remote wakeup */
|
|
|
|
status = hub_port_status(hub, port1, &portstatus, &portchange);
|
2011-04-27 18:07:43 +08:00
|
|
|
if (status == 0 && !port_is_suspended(hub, portstatus))
|
2006-11-21 00:14:30 +08:00
|
|
|
goto SuspendCleared;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/* see 7.1.7.7; affects power usage, but not budgeting */
|
2011-04-27 18:07:50 +08:00
|
|
|
if (hub_is_superspeed(hub->hdev))
|
2012-12-11 07:43:08 +08:00
|
|
|
status = hub_set_port_link_state(hub, port1, USB_SS_PORT_LS_U0);
|
2011-04-27 18:07:50 +08:00
|
|
|
else
|
2013-01-23 04:26:30 +08:00
|
|
|
status = usb_clear_port_feature(hub->hdev,
|
2011-04-27 18:07:50 +08:00
|
|
|
port1, USB_PORT_FEAT_SUSPEND);
|
2005-04-17 06:20:36 +08:00
|
|
|
if (status) {
|
2014-05-21 09:08:17 +08:00
|
|
|
dev_dbg(&port_dev->dev, "can't resume, status %d\n", status);
|
2005-04-17 06:20:36 +08:00
|
|
|
} else {
|
2015-02-14 05:38:33 +08:00
|
|
|
/* drive resume for USB_RESUME_TIMEOUT msec */
|
2007-05-31 03:34:36 +08:00
|
|
|
dev_dbg(&udev->dev, "usb %sresume\n",
|
2011-08-20 05:49:48 +08:00
|
|
|
(PMSG_IS_AUTO(msg) ? "auto-" : ""));
|
2015-02-14 05:38:33 +08:00
|
|
|
msleep(USB_RESUME_TIMEOUT);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/* Virtual root hubs can trigger on GET_PORT_STATUS to
|
|
|
|
* stop resume signaling. Then finish the resume
|
|
|
|
* sequence.
|
|
|
|
*/
|
2006-11-21 00:14:30 +08:00
|
|
|
status = hub_port_status(hub, port1, &portstatus, &portchange);
|
2007-05-31 03:38:58 +08:00
|
|
|
|
2008-04-28 23:06:11 +08:00
|
|
|
/* TRSMRCY = 10 msec */
|
|
|
|
msleep(10);
|
|
|
|
}
|
|
|
|
|
2007-05-31 03:38:58 +08:00
|
|
|
SuspendCleared:
|
2008-04-28 23:06:11 +08:00
|
|
|
if (status == 0) {
|
2012-10-19 23:03:39 +08:00
|
|
|
udev->port_is_suspended = 0;
|
2011-04-27 18:07:50 +08:00
|
|
|
if (hub_is_superspeed(hub->hdev)) {
|
|
|
|
if (portchange & USB_PORT_STAT_C_LINK_STATE)
|
2013-01-23 04:26:30 +08:00
|
|
|
usb_clear_port_feature(hub->hdev, port1,
|
2011-04-27 18:07:50 +08:00
|
|
|
USB_PORT_FEAT_C_PORT_LINK_STATE);
|
|
|
|
} else {
|
|
|
|
if (portchange & USB_PORT_STAT_C_SUSPEND)
|
2013-01-23 04:26:30 +08:00
|
|
|
usb_clear_port_feature(hub->hdev, port1,
|
2011-04-27 18:07:50 +08:00
|
|
|
USB_PORT_FEAT_C_SUSPEND);
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2015-12-03 03:55:07 +08:00
|
|
|
if (udev->persist_enabled)
|
|
|
|
status = wait_for_connected(udev, hub, &port1, &portchange,
|
USB: Fix persist resume of some SS USB devices
Problem Summary: Problem has been observed generally with PM states
where VBUS goes off during suspend. There are some SS USB devices which
take longer time for link training compared to many others. Such
devices fail to reconnect with same old address which was associated
with it before suspend.
When system resumes, at some point of time (dpm_run_callback->
usb_dev_resume->usb_resume->usb_resume_both->usb_resume_device->
usb_port_resume) SW reads hub status. If device is present,
then it finishes port resume and re-enumerates device with same
address. If device is not present then, SW thinks that device was
removed during suspend and therefore does logical disconnection
and removes all the resource allocated for this device.
Now, if I put sufficient delay just before root hub status read in
usb_resume_device then, SW sees always that device is present. In normal
course(without any delay) SW sees that no device is present and then SW
removes all resource associated with the device at this port. In the
latter case, after sometime, device says that hey I am here, now host
enumerates it, but with new address.
Problem had been reproduced when I connect verbatim USB3.0 hard disc
with my STiH407 XHCI host running with 3.10 kernel.
I see that similar problem has been reported here.
https://bugzilla.kernel.org/show_bug.cgi?id=53211
Reading above it seems that bug was not in 3.6.6 and was present in 3.8
and again it was not present for some in 3.12.6, while it was present
for few others. I tested with 3.13-FC19 running at i686 desktop, problem
was still there. However, I was failed to reproduce it with 3.16-RC4
running at same i686 machine. I would say it is just a random
observation. Problem for few devices is always there, as I am unable to
find a proper fix for the issue.
So, now question is what should be the amount of delay so that host is
always able to recognize suspended device after resume.
XHCI specs 4.19.4 says that when Link training is successful, port sets
CSC bit to 1. So if SW reads port status before successful link
training, then it will not find device to be present. USB Analyzer log
with such buggy devices show that in some cases device switch on the
RX termination after long delay of host enabling the VBUS. In few other
cases it has been seen that device fails to negotiate link training in
first attempt. It has been reported till now that few devices take as
long as 2000 ms to train the link after host enabling its VBUS and
RX termination. This patch implements a 2000 ms timeout for CSC bit to set
ie for link training. If in a case link trains before timeout, loop will
exit earlier.
This patch implements above delay, but only for SS device and when
persist is enabled.
So, for the good device overhead is almost none. While for the bad
devices penalty could be the time which it take for link training.
But, If a device was connected before suspend, and was removed
while system was asleep, then the penalty would be the timeout ie
2000 ms.
Results:
Verbatim USB SS hard disk connected with STiH407 USB host running 3.10
Kernel resumes in 461 msecs without this patch, but hard disk is
assigned a new device address. Same system resumes in 790 msecs with
this patch, but with old device address.
Cc: <stable@vger.kernel.org>
Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-18 15:07:10 +08:00
|
|
|
&portstatus);
|
|
|
|
|
2008-04-28 23:06:11 +08:00
|
|
|
status = check_port_resume_type(udev,
|
|
|
|
hub, port1, status, portchange, portstatus);
|
2007-05-31 03:38:58 +08:00
|
|
|
if (status == 0)
|
|
|
|
status = finish_port_resume(udev);
|
|
|
|
if (status < 0) {
|
|
|
|
dev_dbg(&udev->dev, "can't resume, status %d\n", status);
|
|
|
|
hub_port_logical_disconnect(hub, port1);
|
2011-09-24 05:19:52 +08:00
|
|
|
} else {
|
|
|
|
/* Try to enable USB2 hardware LPM */
|
|
|
|
if (udev->usb2_hw_lpm_capable == 1)
|
|
|
|
usb_set_usb2_hardware_lpm(udev, 1);
|
USB: Disable USB 3.0 LPM in critical sections.
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-05-03 05:25:52 +08:00
|
|
|
|
2012-06-26 03:08:08 +08:00
|
|
|
/* Try to enable USB3 LTM and LPM */
|
|
|
|
usb_enable_ltm(udev);
|
USB: Disable USB 3.0 LPM in critical sections.
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-05-03 05:25:52 +08:00
|
|
|
usb_unlocked_enable_lpm(udev);
|
2007-05-31 03:38:58 +08:00
|
|
|
}
|
2011-09-24 05:19:52 +08:00
|
|
|
|
2014-05-21 09:09:26 +08:00
|
|
|
usb_unlock_port(port_dev);
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
2010-01-09 01:56:30 +08:00
|
|
|
int usb_remote_wakeup(struct usb_device *udev)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
int status = 0;
|
|
|
|
|
2014-05-21 09:09:26 +08:00
|
|
|
usb_lock_device(udev);
|
2005-04-17 06:20:36 +08:00
|
|
|
if (udev->state == USB_STATE_SUSPENDED) {
|
2006-08-31 03:47:02 +08:00
|
|
|
dev_dbg(&udev->dev, "usb %sresume\n", "wakeup-");
|
2010-01-09 01:57:28 +08:00
|
|
|
status = usb_autoresume_device(udev);
|
|
|
|
if (status == 0) {
|
|
|
|
/* Let the drivers do their thing, then... */
|
|
|
|
usb_autosuspend_device(udev);
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2014-05-21 09:09:26 +08:00
|
|
|
usb_unlock_device(udev);
|
2005-04-17 06:20:36 +08:00
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
2014-05-21 09:09:31 +08:00
|
|
|
/* Returns 1 if there was a remote wakeup and a connect status change. */
|
|
|
|
static int hub_handle_remote_wakeup(struct usb_hub *hub, unsigned int port,
|
|
|
|
u16 portstatus, u16 portchange)
|
|
|
|
__must_hold(&port_dev->status_lock)
|
|
|
|
{
|
|
|
|
struct usb_port *port_dev = hub->ports[port - 1];
|
|
|
|
struct usb_device *hdev;
|
|
|
|
struct usb_device *udev;
|
|
|
|
int connect_change = 0;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
hdev = hub->hdev;
|
|
|
|
udev = port_dev->child;
|
|
|
|
if (!hub_is_superspeed(hdev)) {
|
|
|
|
if (!(portchange & USB_PORT_STAT_C_SUSPEND))
|
|
|
|
return 0;
|
|
|
|
usb_clear_port_feature(hdev, port, USB_PORT_FEAT_C_SUSPEND);
|
|
|
|
} else {
|
|
|
|
if (!udev || udev->state != USB_STATE_SUSPENDED ||
|
|
|
|
(portstatus & USB_PORT_STAT_LINK_STATE) !=
|
|
|
|
USB_SS_PORT_LS_U0)
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (udev) {
|
|
|
|
/* TRSMRCY = 10 msec */
|
|
|
|
msleep(10);
|
|
|
|
|
|
|
|
usb_unlock_port(port_dev);
|
|
|
|
ret = usb_remote_wakeup(udev);
|
|
|
|
usb_lock_port(port_dev);
|
|
|
|
if (ret < 0)
|
|
|
|
connect_change = 1;
|
|
|
|
} else {
|
|
|
|
ret = -ENODEV;
|
|
|
|
hub_port_disable(hub, port, 1);
|
|
|
|
}
|
|
|
|
dev_dbg(&port_dev->dev, "resume, status %d\n", ret);
|
|
|
|
return connect_change;
|
|
|
|
}
|
|
|
|
|
USB: check port changes before hub runtime suspend for some bug device
The hub status endpoint has a long 'bInterval', which is 255ms
for FS/LS device and 256ms for HS device according to USB 2.0 spec,
so the device connection change may be reported later more than 255ms
via status pipe.
The connection change in hub may have been happened already on the
downstream ports, but no status URB completes when it is killed
in hub_suspend(auto), so the connection change may be missed by some
buggy hub devices, which won't generate remote wakeup signal after
their remote wakeup is enabled and they are put into suspend state.
The problem can be observed at least on the below Genesys Logic, Inc.
hub devices:
0x05e3,0x0606
0x05e3,0x0608
In theory, there is no way to fix the problem completely, but we
can make it less likely to occur by this patch.
This patch introduces one quirk of HUB_QUIRK_CHECK_PORTS_AUTOSUSPEND
to check ports' change during hub_suspend(auto) for the buggy
devices. If ports' change is found, terminate the auto suspend and
return to working state.
So for the buggy hubs, if the connection change happend before
the ports' check, it can be handled correctly. If it happens between
the ports' check and enabling remote wakeup/entering suspend, it
will be missed. Considered the interval is quite short, it is very
less likely to happen during the window.
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-24 11:59:24 +08:00
|
|
|
static int check_ports_changed(struct usb_hub *hub)
|
|
|
|
{
|
|
|
|
int port1;
|
|
|
|
|
|
|
|
for (port1 = 1; port1 <= hub->hdev->maxchild; ++port1) {
|
|
|
|
u16 portstatus, portchange;
|
|
|
|
int status;
|
|
|
|
|
|
|
|
status = hub_port_status(hub, port1, &portstatus, &portchange);
|
|
|
|
if (!status && portchange)
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2005-09-14 10:56:33 +08:00
|
|
|
static int hub_suspend(struct usb_interface *intf, pm_message_t msg)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2015-08-12 12:34:37 +08:00
|
|
|
struct usb_hub *hub = usb_get_intfdata(intf);
|
2005-04-17 06:20:36 +08:00
|
|
|
struct usb_device *hdev = hub->hdev;
|
|
|
|
unsigned port1;
|
USB/xHCI: Enable USB 3.0 hub remote wakeup.
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-01-07 02:34:31 +08:00
|
|
|
int status;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2013-07-12 02:58:04 +08:00
|
|
|
/*
|
|
|
|
* Warn if children aren't already suspended.
|
|
|
|
* Also, add up the number of wakeup-enabled descendants.
|
|
|
|
*/
|
|
|
|
hub->wakeup_enabled_descendants = 0;
|
2005-04-17 06:20:36 +08:00
|
|
|
for (port1 = 1; port1 <= hdev->maxchild; port1++) {
|
2014-05-21 09:08:17 +08:00
|
|
|
struct usb_port *port_dev = hub->ports[port1 - 1];
|
|
|
|
struct usb_device *udev = port_dev->child;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2007-09-10 23:34:26 +08:00
|
|
|
if (udev && udev->can_submit) {
|
2014-06-18 07:16:22 +08:00
|
|
|
dev_warn(&port_dev->dev, "device %s not suspended yet\n",
|
|
|
|
dev_name(&udev->dev));
|
2011-08-20 05:49:48 +08:00
|
|
|
if (PMSG_IS_AUTO(msg))
|
2011-06-16 04:29:16 +08:00
|
|
|
return -EBUSY;
|
2005-09-14 10:57:04 +08:00
|
|
|
}
|
2013-07-12 02:58:04 +08:00
|
|
|
if (udev)
|
|
|
|
hub->wakeup_enabled_descendants +=
|
|
|
|
wakeup_enabled_descendants(udev);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
USB: check port changes before hub runtime suspend for some bug device
The hub status endpoint has a long 'bInterval', which is 255ms
for FS/LS device and 256ms for HS device according to USB 2.0 spec,
so the device connection change may be reported later more than 255ms
via status pipe.
The connection change in hub may have been happened already on the
downstream ports, but no status URB completes when it is killed
in hub_suspend(auto), so the connection change may be missed by some
buggy hub devices, which won't generate remote wakeup signal after
their remote wakeup is enabled and they are put into suspend state.
The problem can be observed at least on the below Genesys Logic, Inc.
hub devices:
0x05e3,0x0606
0x05e3,0x0608
In theory, there is no way to fix the problem completely, but we
can make it less likely to occur by this patch.
This patch introduces one quirk of HUB_QUIRK_CHECK_PORTS_AUTOSUSPEND
to check ports' change during hub_suspend(auto) for the buggy
devices. If ports' change is found, terminate the auto suspend and
return to working state.
So for the buggy hubs, if the connection change happend before
the ports' check, it can be handled correctly. If it happens between
the ports' check and enabling remote wakeup/entering suspend, it
will be missed. Considered the interval is quite short, it is very
less likely to happen during the window.
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-24 11:59:24 +08:00
|
|
|
|
|
|
|
if (hdev->do_remote_wakeup && hub->quirk_check_port_auto_suspend) {
|
|
|
|
/* check if there are changes pending on hub ports */
|
|
|
|
if (check_ports_changed(hub)) {
|
|
|
|
if (PMSG_IS_AUTO(msg))
|
|
|
|
return -EBUSY;
|
|
|
|
pm_wakeup_event(&hdev->dev, 2000);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
USB/xHCI: Enable USB 3.0 hub remote wakeup.
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-01-07 02:34:31 +08:00
|
|
|
if (hub_is_superspeed(hdev) && hdev->do_remote_wakeup) {
|
|
|
|
/* Enable hub to send remote wakeup for all ports. */
|
|
|
|
for (port1 = 1; port1 <= hdev->maxchild; port1++) {
|
|
|
|
status = set_port_feature(hdev,
|
|
|
|
port1 |
|
|
|
|
USB_PORT_FEAT_REMOTE_WAKE_CONNECT |
|
|
|
|
USB_PORT_FEAT_REMOTE_WAKE_DISCONNECT |
|
|
|
|
USB_PORT_FEAT_REMOTE_WAKE_OVER_CURRENT,
|
|
|
|
USB_PORT_FEAT_REMOTE_WAKE_MASK);
|
|
|
|
}
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2008-03-04 08:08:34 +08:00
|
|
|
dev_dbg(&intf->dev, "%s\n", __func__);
|
2006-11-10 03:44:33 +08:00
|
|
|
|
2014-09-19 23:32:23 +08:00
|
|
|
/* stop hub_wq and related activity */
|
2008-04-28 23:07:31 +08:00
|
|
|
hub_quiesce(hub, HUB_SUSPEND);
|
2007-05-04 23:51:54 +08:00
|
|
|
return 0;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static int hub_resume(struct usb_interface *intf)
|
|
|
|
{
|
2008-03-04 04:15:51 +08:00
|
|
|
struct usb_hub *hub = usb_get_intfdata(intf);
|
2006-11-10 03:44:33 +08:00
|
|
|
|
2008-03-04 04:15:51 +08:00
|
|
|
dev_dbg(&intf->dev, "%s\n", __func__);
|
2008-04-28 23:07:17 +08:00
|
|
|
hub_activate(hub, HUB_RESUME);
|
2005-04-17 06:20:36 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2007-05-31 03:39:33 +08:00
|
|
|
static int hub_reset_resume(struct usb_interface *intf)
|
2007-05-31 03:38:16 +08:00
|
|
|
{
|
2007-05-31 03:39:33 +08:00
|
|
|
struct usb_hub *hub = usb_get_intfdata(intf);
|
2007-05-31 03:38:16 +08:00
|
|
|
|
2008-03-04 04:15:51 +08:00
|
|
|
dev_dbg(&intf->dev, "%s\n", __func__);
|
2008-04-28 23:07:17 +08:00
|
|
|
hub_activate(hub, HUB_RESET_RESUME);
|
2007-05-31 03:38:16 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2007-05-31 03:38:58 +08:00
|
|
|
/**
|
|
|
|
* usb_root_hub_lost_power - called by HCD if the root hub lost Vbus power
|
|
|
|
* @rhdev: struct usb_device for the root hub
|
|
|
|
*
|
|
|
|
* The USB host controller driver calls this function when its root hub
|
|
|
|
* is resumed and Vbus power has been interrupted or the controller
|
2008-03-04 04:15:59 +08:00
|
|
|
* has been reset. The routine marks @rhdev as having lost power.
|
|
|
|
* When the hub driver is resumed it will take notice and carry out
|
|
|
|
* power-session recovery for all the "USB-PERSIST"-enabled child devices;
|
|
|
|
* the others will be disconnected.
|
2007-05-31 03:38:58 +08:00
|
|
|
*/
|
|
|
|
void usb_root_hub_lost_power(struct usb_device *rhdev)
|
|
|
|
{
|
|
|
|
dev_warn(&rhdev->dev, "root hub lost power or was reset\n");
|
|
|
|
rhdev->reset_resume = 1;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(usb_root_hub_lost_power);
|
|
|
|
|
USB: Add support to enable/disable USB3 link states.
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-04-25 08:21:50 +08:00
|
|
|
static const char * const usb3_lpm_names[] = {
|
|
|
|
"U0",
|
|
|
|
"U1",
|
|
|
|
"U2",
|
|
|
|
"U3",
|
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Send a Set SEL control transfer to the device, prior to enabling
|
|
|
|
* device-initiated U1 or U2. This lets the device know the exit latencies from
|
|
|
|
* the time the device initiates a U1 or U2 exit, to the time it will receive a
|
|
|
|
* packet from the host.
|
|
|
|
*
|
|
|
|
* This function will fail if the SEL or PEL values for udev are greater than
|
|
|
|
* the maximum allowed values for the link state to be enabled.
|
|
|
|
*/
|
|
|
|
static int usb_req_set_sel(struct usb_device *udev, enum usb3_link_state state)
|
|
|
|
{
|
|
|
|
struct usb_set_sel_req *sel_values;
|
|
|
|
unsigned long long u1_sel;
|
|
|
|
unsigned long long u1_pel;
|
|
|
|
unsigned long long u2_sel;
|
|
|
|
unsigned long long u2_pel;
|
|
|
|
int ret;
|
|
|
|
|
2013-09-04 22:24:45 +08:00
|
|
|
if (udev->state != USB_STATE_CONFIGURED)
|
|
|
|
return 0;
|
|
|
|
|
USB: Add support to enable/disable USB3 link states.
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-04-25 08:21:50 +08:00
|
|
|
/* Convert SEL and PEL stored in ns to us */
|
|
|
|
u1_sel = DIV_ROUND_UP(udev->u1_params.sel, 1000);
|
|
|
|
u1_pel = DIV_ROUND_UP(udev->u1_params.pel, 1000);
|
|
|
|
u2_sel = DIV_ROUND_UP(udev->u2_params.sel, 1000);
|
|
|
|
u2_pel = DIV_ROUND_UP(udev->u2_params.pel, 1000);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Make sure that the calculated SEL and PEL values for the link
|
|
|
|
* state we're enabling aren't bigger than the max SEL/PEL
|
|
|
|
* value that will fit in the SET SEL control transfer.
|
|
|
|
* Otherwise the device would get an incorrect idea of the exit
|
|
|
|
* latency for the link state, and could start a device-initiated
|
|
|
|
* U1/U2 when the exit latencies are too high.
|
|
|
|
*/
|
|
|
|
if ((state == USB3_LPM_U1 &&
|
|
|
|
(u1_sel > USB3_LPM_MAX_U1_SEL_PEL ||
|
|
|
|
u1_pel > USB3_LPM_MAX_U1_SEL_PEL)) ||
|
|
|
|
(state == USB3_LPM_U2 &&
|
|
|
|
(u2_sel > USB3_LPM_MAX_U2_SEL_PEL ||
|
|
|
|
u2_pel > USB3_LPM_MAX_U2_SEL_PEL))) {
|
2012-10-06 01:30:35 +08:00
|
|
|
dev_dbg(&udev->dev, "Device-initiated %s disabled due to long SEL %llu us or PEL %llu us\n",
|
USB: Add support to enable/disable USB3 link states.
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-04-25 08:21:50 +08:00
|
|
|
usb3_lpm_names[state], u1_sel, u1_pel);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we're enabling device-initiated LPM for one link state,
|
|
|
|
* but the other link state has a too high SEL or PEL value,
|
|
|
|
* just set those values to the max in the Set SEL request.
|
|
|
|
*/
|
|
|
|
if (u1_sel > USB3_LPM_MAX_U1_SEL_PEL)
|
|
|
|
u1_sel = USB3_LPM_MAX_U1_SEL_PEL;
|
|
|
|
|
|
|
|
if (u1_pel > USB3_LPM_MAX_U1_SEL_PEL)
|
|
|
|
u1_pel = USB3_LPM_MAX_U1_SEL_PEL;
|
|
|
|
|
|
|
|
if (u2_sel > USB3_LPM_MAX_U2_SEL_PEL)
|
|
|
|
u2_sel = USB3_LPM_MAX_U2_SEL_PEL;
|
|
|
|
|
|
|
|
if (u2_pel > USB3_LPM_MAX_U2_SEL_PEL)
|
|
|
|
u2_pel = USB3_LPM_MAX_U2_SEL_PEL;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* usb_enable_lpm() can be called as part of a failed device reset,
|
|
|
|
* which may be initiated by an error path of a mass storage driver.
|
|
|
|
* Therefore, use GFP_NOIO.
|
|
|
|
*/
|
|
|
|
sel_values = kmalloc(sizeof *(sel_values), GFP_NOIO);
|
|
|
|
if (!sel_values)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
sel_values->u1_sel = u1_sel;
|
|
|
|
sel_values->u1_pel = u1_pel;
|
|
|
|
sel_values->u2_sel = cpu_to_le16(u2_sel);
|
|
|
|
sel_values->u2_pel = cpu_to_le16(u2_pel);
|
|
|
|
|
|
|
|
ret = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
|
|
|
|
USB_REQ_SET_SEL,
|
|
|
|
USB_RECIP_DEVICE,
|
|
|
|
0, 0,
|
|
|
|
sel_values, sizeof *(sel_values),
|
|
|
|
USB_CTRL_SET_TIMEOUT);
|
|
|
|
kfree(sel_values);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Enable or disable device-initiated U1 or U2 transitions.
|
|
|
|
*/
|
|
|
|
static int usb_set_device_initiated_lpm(struct usb_device *udev,
|
|
|
|
enum usb3_link_state state, bool enable)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
int feature;
|
|
|
|
|
|
|
|
switch (state) {
|
|
|
|
case USB3_LPM_U1:
|
|
|
|
feature = USB_DEVICE_U1_ENABLE;
|
|
|
|
break;
|
|
|
|
case USB3_LPM_U2:
|
|
|
|
feature = USB_DEVICE_U2_ENABLE;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
dev_warn(&udev->dev, "%s: Can't %s non-U1 or U2 state.\n",
|
|
|
|
__func__, enable ? "enable" : "disable");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (udev->state != USB_STATE_CONFIGURED) {
|
|
|
|
dev_dbg(&udev->dev, "%s: Can't %s %s state "
|
|
|
|
"for unconfigured device.\n",
|
|
|
|
__func__, enable ? "enable" : "disable",
|
|
|
|
usb3_lpm_names[state]);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (enable) {
|
|
|
|
/*
|
|
|
|
* Now send the control transfer to enable device-initiated LPM
|
|
|
|
* for either U1 or U2.
|
|
|
|
*/
|
|
|
|
ret = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
|
|
|
|
USB_REQ_SET_FEATURE,
|
|
|
|
USB_RECIP_DEVICE,
|
|
|
|
feature,
|
|
|
|
0, NULL, 0,
|
|
|
|
USB_CTRL_SET_TIMEOUT);
|
|
|
|
} else {
|
|
|
|
ret = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
|
|
|
|
USB_REQ_CLEAR_FEATURE,
|
|
|
|
USB_RECIP_DEVICE,
|
|
|
|
feature,
|
|
|
|
0, NULL, 0,
|
|
|
|
USB_CTRL_SET_TIMEOUT);
|
|
|
|
}
|
|
|
|
if (ret < 0) {
|
|
|
|
dev_warn(&udev->dev, "%s of device-initiated %s failed.\n",
|
|
|
|
enable ? "Enable" : "Disable",
|
|
|
|
usb3_lpm_names[state]);
|
|
|
|
return -EBUSY;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int usb_set_lpm_timeout(struct usb_device *udev,
|
|
|
|
enum usb3_link_state state, int timeout)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
int feature;
|
|
|
|
|
|
|
|
switch (state) {
|
|
|
|
case USB3_LPM_U1:
|
|
|
|
feature = USB_PORT_FEAT_U1_TIMEOUT;
|
|
|
|
break;
|
|
|
|
case USB3_LPM_U2:
|
|
|
|
feature = USB_PORT_FEAT_U2_TIMEOUT;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
dev_warn(&udev->dev, "%s: Can't set timeout for non-U1 or U2 state.\n",
|
|
|
|
__func__);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (state == USB3_LPM_U1 && timeout > USB3_LPM_U1_MAX_TIMEOUT &&
|
|
|
|
timeout != USB3_LPM_DEVICE_INITIATED) {
|
|
|
|
dev_warn(&udev->dev, "Failed to set %s timeout to 0x%x, "
|
|
|
|
"which is a reserved value.\n",
|
|
|
|
usb3_lpm_names[state], timeout);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = set_port_feature(udev->parent,
|
|
|
|
USB_PORT_LPM_TIMEOUT(timeout) | udev->portnum,
|
|
|
|
feature);
|
|
|
|
if (ret < 0) {
|
|
|
|
dev_warn(&udev->dev, "Failed to set %s timeout to 0x%x,"
|
|
|
|
"error code %i\n", usb3_lpm_names[state],
|
|
|
|
timeout, ret);
|
|
|
|
return -EBUSY;
|
|
|
|
}
|
|
|
|
if (state == USB3_LPM_U1)
|
|
|
|
udev->u1_params.timeout = timeout;
|
|
|
|
else
|
|
|
|
udev->u2_params.timeout = timeout;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Enable the hub-initiated U1/U2 idle timeouts, and enable device-initiated
|
|
|
|
* U1/U2 entry.
|
|
|
|
*
|
|
|
|
* We will attempt to enable U1 or U2, but there are no guarantees that the
|
|
|
|
* control transfers to set the hub timeout or enable device-initiated U1/U2
|
|
|
|
* will be successful.
|
|
|
|
*
|
|
|
|
* If we cannot set the parent hub U1/U2 timeout, we attempt to let the xHCI
|
|
|
|
* driver know about it. If that call fails, it should be harmless, and just
|
|
|
|
* take up more slightly more bus bandwidth for unnecessary U1/U2 exit latency.
|
|
|
|
*/
|
|
|
|
static void usb_enable_link_state(struct usb_hcd *hcd, struct usb_device *udev,
|
|
|
|
enum usb3_link_state state)
|
|
|
|
{
|
2012-10-06 01:32:07 +08:00
|
|
|
int timeout, ret;
|
2012-10-04 02:18:05 +08:00
|
|
|
__u8 u1_mel = udev->bos->ss_cap->bU1devExitLat;
|
|
|
|
__le16 u2_mel = udev->bos->ss_cap->bU2DevExitLat;
|
|
|
|
|
|
|
|
/* If the device says it doesn't have *any* exit latency to come out of
|
|
|
|
* U1 or U2, it's probably lying. Assume it doesn't implement that link
|
|
|
|
* state.
|
|
|
|
*/
|
|
|
|
if ((state == USB3_LPM_U1 && u1_mel == 0) ||
|
|
|
|
(state == USB3_LPM_U2 && u2_mel == 0))
|
|
|
|
return;
|
USB: Add support to enable/disable USB3 link states.
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-04-25 08:21:50 +08:00
|
|
|
|
2012-10-06 01:32:07 +08:00
|
|
|
/*
|
|
|
|
* First, let the device know about the exit latencies
|
|
|
|
* associated with the link state we're about to enable.
|
|
|
|
*/
|
|
|
|
ret = usb_req_set_sel(udev, state);
|
|
|
|
if (ret < 0) {
|
|
|
|
dev_warn(&udev->dev, "Set SEL for device-initiated %s failed.\n",
|
|
|
|
usb3_lpm_names[state]);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
USB: Add support to enable/disable USB3 link states.
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-04-25 08:21:50 +08:00
|
|
|
/* We allow the host controller to set the U1/U2 timeout internally
|
|
|
|
* first, so that it can change its schedule to account for the
|
|
|
|
* additional latency to send data to a device in a lower power
|
|
|
|
* link state.
|
|
|
|
*/
|
|
|
|
timeout = hcd->driver->enable_usb3_lpm_timeout(hcd, udev, state);
|
|
|
|
|
|
|
|
/* xHCI host controller doesn't want to enable this LPM state. */
|
|
|
|
if (timeout == 0)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (timeout < 0) {
|
|
|
|
dev_warn(&udev->dev, "Could not enable %s link state, "
|
|
|
|
"xHCI error %i.\n", usb3_lpm_names[state],
|
|
|
|
timeout);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2015-11-14 16:26:32 +08:00
|
|
|
if (usb_set_lpm_timeout(udev, state, timeout)) {
|
USB: Add support to enable/disable USB3 link states.
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-04-25 08:21:50 +08:00
|
|
|
/* If we can't set the parent hub U1/U2 timeout,
|
|
|
|
* device-initiated LPM won't be allowed either, so let the xHCI
|
|
|
|
* host know that this link state won't be enabled.
|
|
|
|
*/
|
|
|
|
hcd->driver->disable_usb3_lpm_timeout(hcd, udev, state);
|
2015-11-14 16:26:32 +08:00
|
|
|
} else {
|
|
|
|
/* Only a configured device will accept the Set Feature
|
|
|
|
* U1/U2_ENABLE
|
|
|
|
*/
|
|
|
|
if (udev->actconfig)
|
|
|
|
usb_set_device_initiated_lpm(udev, state, true);
|
|
|
|
|
|
|
|
/* As soon as usb_set_lpm_timeout(timeout) returns 0, the
|
|
|
|
* hub-initiated LPM is enabled. Thus, LPM is enabled no
|
|
|
|
* matter the result of usb_set_device_initiated_lpm().
|
|
|
|
* The only difference is whether device is able to initiate
|
|
|
|
* LPM.
|
|
|
|
*/
|
|
|
|
if (state == USB3_LPM_U1)
|
|
|
|
udev->usb3_lpm_u1_enabled = 1;
|
|
|
|
else if (state == USB3_LPM_U2)
|
|
|
|
udev->usb3_lpm_u2_enabled = 1;
|
|
|
|
}
|
USB: Add support to enable/disable USB3 link states.
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-04-25 08:21:50 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Disable the hub-initiated U1/U2 idle timeouts, and disable device-initiated
|
|
|
|
* U1/U2 entry.
|
|
|
|
*
|
|
|
|
* If this function returns -EBUSY, the parent hub will still allow U1/U2 entry.
|
|
|
|
* If zero is returned, the parent will not allow the link to go into U1/U2.
|
|
|
|
*
|
|
|
|
* If zero is returned, device-initiated U1/U2 entry may still be enabled, but
|
|
|
|
* it won't have an effect on the bus link state because the parent hub will
|
|
|
|
* still disallow device-initiated U1/U2 entry.
|
|
|
|
*
|
|
|
|
* If zero is returned, the xHCI host controller may still think U1/U2 entry is
|
|
|
|
* possible. The result will be slightly more bus bandwidth will be taken up
|
|
|
|
* (to account for U1/U2 exit latency), but it should be harmless.
|
|
|
|
*/
|
|
|
|
static int usb_disable_link_state(struct usb_hcd *hcd, struct usb_device *udev,
|
|
|
|
enum usb3_link_state state)
|
|
|
|
{
|
|
|
|
switch (state) {
|
|
|
|
case USB3_LPM_U1:
|
|
|
|
case USB3_LPM_U2:
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
dev_warn(&udev->dev, "%s: Can't disable non-U1 or U2 state.\n",
|
|
|
|
__func__);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (usb_set_lpm_timeout(udev, state, 0))
|
|
|
|
return -EBUSY;
|
|
|
|
|
|
|
|
usb_set_device_initiated_lpm(udev, state, false);
|
|
|
|
|
|
|
|
if (hcd->driver->disable_usb3_lpm_timeout(hcd, udev, state))
|
|
|
|
dev_warn(&udev->dev, "Could not disable xHCI %s timeout, "
|
|
|
|
"bus schedule bandwidth may be impacted.\n",
|
|
|
|
usb3_lpm_names[state]);
|
2015-11-14 16:26:32 +08:00
|
|
|
|
|
|
|
/* As soon as usb_set_lpm_timeout(0) return 0, hub initiated LPM
|
|
|
|
* is disabled. Hub will disallows link to enter U1/U2 as well,
|
|
|
|
* even device is initiating LPM. Hence LPM is disabled if hub LPM
|
|
|
|
* timeout set to 0, no matter device-initiated LPM is disabled or
|
|
|
|
* not.
|
|
|
|
*/
|
|
|
|
if (state == USB3_LPM_U1)
|
|
|
|
udev->usb3_lpm_u1_enabled = 0;
|
|
|
|
else if (state == USB3_LPM_U2)
|
|
|
|
udev->usb3_lpm_u2_enabled = 0;
|
|
|
|
|
USB: Add support to enable/disable USB3 link states.
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-04-25 08:21:50 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Disable hub-initiated and device-initiated U1 and U2 entry.
|
|
|
|
* Caller must own the bandwidth_mutex.
|
|
|
|
*
|
|
|
|
* This will call usb_enable_lpm() on failure, which will decrement
|
|
|
|
* lpm_disable_count, and will re-enable LPM if lpm_disable_count reaches zero.
|
|
|
|
*/
|
|
|
|
int usb_disable_lpm(struct usb_device *udev)
|
|
|
|
{
|
|
|
|
struct usb_hcd *hcd;
|
|
|
|
|
|
|
|
if (!udev || !udev->parent ||
|
2015-12-10 15:59:25 +08:00
|
|
|
udev->speed < USB_SPEED_SUPER ||
|
2014-07-04 22:01:27 +08:00
|
|
|
!udev->lpm_capable ||
|
|
|
|
udev->state < USB_STATE_DEFAULT)
|
USB: Add support to enable/disable USB3 link states.
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-04-25 08:21:50 +08:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
hcd = bus_to_hcd(udev->bus);
|
|
|
|
if (!hcd || !hcd->driver->disable_usb3_lpm_timeout)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
udev->lpm_disable_count++;
|
2012-05-23 01:54:34 +08:00
|
|
|
if ((udev->u1_params.timeout == 0 && udev->u2_params.timeout == 0))
|
USB: Add support to enable/disable USB3 link states.
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-04-25 08:21:50 +08:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* If LPM is enabled, attempt to disable it. */
|
|
|
|
if (usb_disable_link_state(hcd, udev, USB3_LPM_U1))
|
|
|
|
goto enable_lpm;
|
|
|
|
if (usb_disable_link_state(hcd, udev, USB3_LPM_U2))
|
|
|
|
goto enable_lpm;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
enable_lpm:
|
|
|
|
usb_enable_lpm(udev);
|
|
|
|
return -EBUSY;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(usb_disable_lpm);
|
|
|
|
|
|
|
|
/* Grab the bandwidth_mutex before calling usb_disable_lpm() */
|
|
|
|
int usb_unlocked_disable_lpm(struct usb_device *udev)
|
|
|
|
{
|
|
|
|
struct usb_hcd *hcd = bus_to_hcd(udev->bus);
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (!hcd)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
mutex_lock(hcd->bandwidth_mutex);
|
|
|
|
ret = usb_disable_lpm(udev);
|
|
|
|
mutex_unlock(hcd->bandwidth_mutex);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(usb_unlocked_disable_lpm);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Attempt to enable device-initiated and hub-initiated U1 and U2 entry. The
|
|
|
|
* xHCI host policy may prevent U1 or U2 from being enabled.
|
|
|
|
*
|
|
|
|
* Other callers may have disabled link PM, so U1 and U2 entry will be disabled
|
|
|
|
* until the lpm_disable_count drops to zero. Caller must own the
|
|
|
|
* bandwidth_mutex.
|
|
|
|
*/
|
|
|
|
void usb_enable_lpm(struct usb_device *udev)
|
|
|
|
{
|
|
|
|
struct usb_hcd *hcd;
|
2015-11-14 16:26:33 +08:00
|
|
|
struct usb_hub *hub;
|
|
|
|
struct usb_port *port_dev;
|
USB: Add support to enable/disable USB3 link states.
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-04-25 08:21:50 +08:00
|
|
|
|
|
|
|
if (!udev || !udev->parent ||
|
2015-12-10 15:59:25 +08:00
|
|
|
udev->speed < USB_SPEED_SUPER ||
|
2014-07-04 22:01:27 +08:00
|
|
|
!udev->lpm_capable ||
|
|
|
|
udev->state < USB_STATE_DEFAULT)
|
USB: Add support to enable/disable USB3 link states.
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-04-25 08:21:50 +08:00
|
|
|
return;
|
|
|
|
|
|
|
|
udev->lpm_disable_count--;
|
|
|
|
hcd = bus_to_hcd(udev->bus);
|
|
|
|
/* Double check that we can both enable and disable LPM.
|
|
|
|
* Device must be configured to accept set feature U1/U2 timeout.
|
|
|
|
*/
|
|
|
|
if (!hcd || !hcd->driver->enable_usb3_lpm_timeout ||
|
|
|
|
!hcd->driver->disable_usb3_lpm_timeout)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (udev->lpm_disable_count > 0)
|
|
|
|
return;
|
|
|
|
|
2015-11-14 16:26:33 +08:00
|
|
|
hub = usb_hub_to_struct_hub(udev->parent);
|
|
|
|
if (!hub)
|
|
|
|
return;
|
|
|
|
|
|
|
|
port_dev = hub->ports[udev->portnum - 1];
|
|
|
|
|
|
|
|
if (port_dev->usb3_lpm_u1_permit)
|
|
|
|
usb_enable_link_state(hcd, udev, USB3_LPM_U1);
|
|
|
|
|
|
|
|
if (port_dev->usb3_lpm_u2_permit)
|
|
|
|
usb_enable_link_state(hcd, udev, USB3_LPM_U2);
|
USB: Add support to enable/disable USB3 link states.
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-04-25 08:21:50 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(usb_enable_lpm);
|
|
|
|
|
|
|
|
/* Grab the bandwidth_mutex before calling usb_enable_lpm() */
|
|
|
|
void usb_unlocked_enable_lpm(struct usb_device *udev)
|
|
|
|
{
|
|
|
|
struct usb_hcd *hcd = bus_to_hcd(udev->bus);
|
|
|
|
|
|
|
|
if (!hcd)
|
|
|
|
return;
|
|
|
|
|
|
|
|
mutex_lock(hcd->bandwidth_mutex);
|
|
|
|
usb_enable_lpm(udev);
|
|
|
|
mutex_unlock(hcd->bandwidth_mutex);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(usb_unlocked_enable_lpm);
|
|
|
|
|
|
|
|
|
2006-07-02 10:14:24 +08:00
|
|
|
#else /* CONFIG_PM */
|
|
|
|
|
2007-05-31 03:38:16 +08:00
|
|
|
#define hub_suspend NULL
|
|
|
|
#define hub_resume NULL
|
|
|
|
#define hub_reset_resume NULL
|
USB: Add support to enable/disable USB3 link states.
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-04-25 08:21:50 +08:00
|
|
|
|
|
|
|
int usb_disable_lpm(struct usb_device *udev)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
2012-05-21 23:29:01 +08:00
|
|
|
EXPORT_SYMBOL_GPL(usb_disable_lpm);
|
USB: Add support to enable/disable USB3 link states.
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-04-25 08:21:50 +08:00
|
|
|
|
|
|
|
void usb_enable_lpm(struct usb_device *udev) { }
|
2012-05-21 23:29:01 +08:00
|
|
|
EXPORT_SYMBOL_GPL(usb_enable_lpm);
|
USB: Add support to enable/disable USB3 link states.
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-04-25 08:21:50 +08:00
|
|
|
|
|
|
|
int usb_unlocked_disable_lpm(struct usb_device *udev)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
2012-05-21 23:29:01 +08:00
|
|
|
EXPORT_SYMBOL_GPL(usb_unlocked_disable_lpm);
|
USB: Add support to enable/disable USB3 link states.
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-04-25 08:21:50 +08:00
|
|
|
|
|
|
|
void usb_unlocked_enable_lpm(struct usb_device *udev) { }
|
2012-05-21 23:29:01 +08:00
|
|
|
EXPORT_SYMBOL_GPL(usb_unlocked_enable_lpm);
|
2012-06-26 03:08:08 +08:00
|
|
|
|
|
|
|
int usb_disable_ltm(struct usb_device *udev)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(usb_disable_ltm);
|
|
|
|
|
|
|
|
void usb_enable_ltm(struct usb_device *udev) { }
|
|
|
|
EXPORT_SYMBOL_GPL(usb_enable_ltm);
|
2013-07-12 02:58:23 +08:00
|
|
|
|
2014-05-29 16:55:06 +08:00
|
|
|
static int hub_handle_remote_wakeup(struct usb_hub *hub, unsigned int port,
|
|
|
|
u16 portstatus, u16 portchange)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-07-12 02:58:23 +08:00
|
|
|
#endif /* CONFIG_PM */
|
2006-07-02 10:14:24 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/* USB 2.0 spec, 7.1.7.3 / fig 7-29:
|
|
|
|
*
|
|
|
|
* Between connect detection and reset signaling there must be a delay
|
|
|
|
* of 100ms at least for debounce and power-settling. The corresponding
|
|
|
|
* timer shall restart whenever the downstream port detects a disconnect.
|
2013-10-11 05:41:27 +08:00
|
|
|
*
|
2005-04-17 06:20:36 +08:00
|
|
|
* Apparently there are some bluetooth and irda-dongles and a number of
|
|
|
|
* low-speed devices for which this debounce period may last over a second.
|
|
|
|
* Not covered by the spec - but easy to deal with.
|
|
|
|
*
|
|
|
|
* This implementation uses a 1500ms total debounce timeout; if the
|
|
|
|
* connection isn't stable by then it returns -ETIMEDOUT. It checks
|
|
|
|
* every 25ms for transient disconnects. When the port status has been
|
|
|
|
* unchanged for 100ms it returns the port status.
|
|
|
|
*/
|
2013-01-23 04:26:30 +08:00
|
|
|
int hub_port_debounce(struct usb_hub *hub, int port1, bool must_be_connected)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
u16 portchange, portstatus;
|
|
|
|
unsigned connection = 0xffff;
|
2014-05-21 09:08:17 +08:00
|
|
|
int total_time, stable_time = 0;
|
|
|
|
struct usb_port *port_dev = hub->ports[port1 - 1];
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
for (total_time = 0; ; total_time += HUB_DEBOUNCE_STEP) {
|
|
|
|
ret = hub_port_status(hub, port1, &portstatus, &portchange);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
if (!(portchange & USB_PORT_STAT_C_CONNECTION) &&
|
|
|
|
(portstatus & USB_PORT_STAT_CONNECTION) == connection) {
|
2013-01-23 04:26:30 +08:00
|
|
|
if (!must_be_connected ||
|
|
|
|
(connection == USB_PORT_STAT_CONNECTION))
|
|
|
|
stable_time += HUB_DEBOUNCE_STEP;
|
2005-04-17 06:20:36 +08:00
|
|
|
if (stable_time >= HUB_DEBOUNCE_STABLE)
|
|
|
|
break;
|
|
|
|
} else {
|
|
|
|
stable_time = 0;
|
|
|
|
connection = portstatus & USB_PORT_STAT_CONNECTION;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (portchange & USB_PORT_STAT_C_CONNECTION) {
|
2013-01-23 04:26:30 +08:00
|
|
|
usb_clear_port_feature(hub->hdev, port1,
|
2005-04-17 06:20:36 +08:00
|
|
|
USB_PORT_FEAT_C_CONNECTION);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (total_time >= HUB_DEBOUNCE_TIMEOUT)
|
|
|
|
break;
|
|
|
|
msleep(HUB_DEBOUNCE_STEP);
|
|
|
|
}
|
|
|
|
|
2014-05-21 09:08:17 +08:00
|
|
|
dev_dbg(&port_dev->dev, "debounce total %dms stable %dms status 0x%x\n",
|
|
|
|
total_time, stable_time, portstatus);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
if (stable_time < HUB_DEBOUNCE_STABLE)
|
|
|
|
return -ETIMEDOUT;
|
|
|
|
return portstatus;
|
|
|
|
}
|
|
|
|
|
2008-04-09 04:24:46 +08:00
|
|
|
void usb_ep0_reinit(struct usb_device *udev)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2009-01-16 06:03:33 +08:00
|
|
|
usb_disable_endpoint(udev, 0 + USB_DIR_IN, true);
|
|
|
|
usb_disable_endpoint(udev, 0 + USB_DIR_OUT, true);
|
2009-01-01 00:31:33 +08:00
|
|
|
usb_enable_endpoint(udev, &udev->ep0, true);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2008-04-09 04:24:46 +08:00
|
|
|
EXPORT_SYMBOL_GPL(usb_ep0_reinit);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
#define usb_sndaddr0pipe() (PIPE_CONTROL << 30)
|
|
|
|
#define usb_rcvaddr0pipe() ((PIPE_CONTROL << 30) | USB_DIR_IN)
|
|
|
|
|
2007-07-31 05:08:43 +08:00
|
|
|
static int hub_set_address(struct usb_device *udev, int devnum)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
int retval;
|
2009-04-28 10:57:26 +08:00
|
|
|
struct usb_hcd *hcd = bus_to_hcd(udev->bus);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2009-04-28 10:57:26 +08:00
|
|
|
/*
|
|
|
|
* The host controller will choose the device address,
|
|
|
|
* instead of the core having chosen it earlier
|
|
|
|
*/
|
|
|
|
if (!hcd->driver->address_device && devnum <= 1)
|
2005-04-17 06:20:36 +08:00
|
|
|
return -EINVAL;
|
|
|
|
if (udev->state == USB_STATE_ADDRESS)
|
|
|
|
return 0;
|
|
|
|
if (udev->state != USB_STATE_DEFAULT)
|
|
|
|
return -EINVAL;
|
2010-10-14 22:22:51 +08:00
|
|
|
if (hcd->driver->address_device)
|
2009-04-28 10:57:26 +08:00
|
|
|
retval = hcd->driver->address_device(hcd, udev);
|
2010-10-14 22:22:51 +08:00
|
|
|
else
|
2009-04-28 10:57:26 +08:00
|
|
|
retval = usb_control_msg(udev, usb_sndaddr0pipe(),
|
|
|
|
USB_REQ_SET_ADDRESS, 0, devnum, 0,
|
|
|
|
NULL, 0, USB_CTRL_SET_TIMEOUT);
|
2005-04-17 06:20:36 +08:00
|
|
|
if (retval == 0) {
|
2011-02-22 22:53:41 +08:00
|
|
|
update_devnum(udev, devnum);
|
2008-04-09 04:24:46 +08:00
|
|
|
/* Device now using proper address. */
|
2005-04-17 06:20:36 +08:00
|
|
|
usb_set_device_state(udev, USB_STATE_ADDRESS);
|
2008-04-09 04:24:46 +08:00
|
|
|
usb_ep0_reinit(udev);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
return retval;
|
|
|
|
}
|
|
|
|
|
2013-09-30 22:26:31 +08:00
|
|
|
/*
|
|
|
|
* There are reports of USB 3.0 devices that say they support USB 2.0 Link PM
|
|
|
|
* when they're plugged into a USB 2.0 port, but they don't work when LPM is
|
|
|
|
* enabled.
|
|
|
|
*
|
|
|
|
* Only enable USB 2.0 Link PM if the port is internal (hardwired), or the
|
|
|
|
* device says it supports the new USB 2.0 Link PM errata by setting the BESL
|
|
|
|
* support bit in the BOS descriptor.
|
|
|
|
*/
|
|
|
|
static void hub_set_initial_usb2_lpm_policy(struct usb_device *udev)
|
|
|
|
{
|
2014-05-21 09:08:17 +08:00
|
|
|
struct usb_hub *hub = usb_hub_to_struct_hub(udev->parent);
|
|
|
|
int connect_type = USB_PORT_CONNECT_TYPE_UNKNOWN;
|
2013-09-30 22:26:31 +08:00
|
|
|
|
|
|
|
if (!udev->usb2_hw_lpm_capable)
|
|
|
|
return;
|
|
|
|
|
2014-05-21 09:08:17 +08:00
|
|
|
if (hub)
|
|
|
|
connect_type = hub->ports[udev->portnum - 1]->connect_type;
|
2013-09-30 22:26:31 +08:00
|
|
|
|
2014-02-27 21:23:55 +08:00
|
|
|
if ((udev->bos->ext_cap->bmAttributes & cpu_to_le32(USB_BESL_SUPPORT)) ||
|
2013-09-30 22:26:31 +08:00
|
|
|
connect_type == USB_PORT_CONNECT_TYPE_HARD_WIRED) {
|
|
|
|
udev->usb2_hw_lpm_allowed = 1;
|
|
|
|
usb_set_usb2_hardware_lpm(udev, 1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-12-06 09:07:27 +08:00
|
|
|
static int hub_enable_device(struct usb_device *udev)
|
|
|
|
{
|
|
|
|
struct usb_hcd *hcd = bus_to_hcd(udev->bus);
|
|
|
|
|
|
|
|
if (!hcd->driver->enable_device)
|
|
|
|
return 0;
|
|
|
|
if (udev->state == USB_STATE_ADDRESS)
|
|
|
|
return 0;
|
|
|
|
if (udev->state != USB_STATE_DEFAULT)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
return hcd->driver->enable_device(hcd, udev);
|
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/* Reset device, (re)assign address, get device descriptor.
|
|
|
|
* Device connection must be stable, no more debouncing needed.
|
|
|
|
* Returns device in USB_STATE_ADDRESS, except on error.
|
|
|
|
*
|
|
|
|
* If this is called for an already-existing device (as part of
|
2014-05-21 09:09:26 +08:00
|
|
|
* usb_reset_and_verify_device), the caller must own the device lock and
|
|
|
|
* the port lock. For a newly detected device that is not accessible
|
|
|
|
* through any global pointers, it's not necessary to lock the device,
|
|
|
|
* but it is still necessary to lock the port.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
|
|
|
static int
|
2015-08-19 11:36:58 +08:00
|
|
|
hub_port_init(struct usb_hub *hub, struct usb_device *udev, int port1,
|
2005-04-17 06:20:36 +08:00
|
|
|
int retry_counter)
|
|
|
|
{
|
|
|
|
struct usb_device *hdev = hub->hdev;
|
2009-04-28 10:54:26 +08:00
|
|
|
struct usb_hcd *hcd = bus_to_hcd(hdev->bus);
|
2016-02-17 18:52:43 +08:00
|
|
|
int retries, operations, retval, i;
|
2005-04-17 06:20:36 +08:00
|
|
|
unsigned delay = HUB_SHORT_RESET_TIME;
|
|
|
|
enum usb_device_speed oldspeed = udev->speed;
|
2011-08-30 23:11:19 +08:00
|
|
|
const char *speed;
|
2007-07-31 05:08:43 +08:00
|
|
|
int devnum = udev->devnum;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/* root hub ports have a slightly longer reset period
|
|
|
|
* (from USB 2.0 spec, section 7.1.7.5)
|
|
|
|
*/
|
|
|
|
if (!hdev->parent) {
|
|
|
|
delay = HUB_ROOT_RESET_TIME;
|
|
|
|
if (port1 == hdev->bus->otg_port)
|
|
|
|
hdev->bus->b_hnp_enable = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Some low speed devices have problems with the quick delay, so */
|
|
|
|
/* be a bit pessimistic with those devices. RHbug #23670 */
|
|
|
|
if (oldspeed == USB_SPEED_LOW)
|
|
|
|
delay = HUB_LONG_RESET_TIME;
|
|
|
|
|
2016-04-25 20:48:38 +08:00
|
|
|
mutex_lock(hcd->address0_mutex);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2011-02-12 03:33:10 +08:00
|
|
|
/* Reset the device; full speed may morph to high speed */
|
|
|
|
/* FIXME a USB 2.0 device may morph into SuperSpeed on reset. */
|
2011-09-14 07:41:11 +08:00
|
|
|
retval = hub_port_reset(hub, port1, udev, delay, false);
|
2011-02-12 03:33:10 +08:00
|
|
|
if (retval < 0) /* error or disconnect */
|
|
|
|
goto fail;
|
|
|
|
/* success, speed is known */
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
retval = -ENODEV;
|
|
|
|
|
2015-12-10 15:59:25 +08:00
|
|
|
/* Don't allow speed changes at reset, except usb 3.0 to faster */
|
|
|
|
if (oldspeed != USB_SPEED_UNKNOWN && oldspeed != udev->speed &&
|
|
|
|
!(oldspeed == USB_SPEED_SUPER && udev->speed > oldspeed)) {
|
2005-04-17 06:20:36 +08:00
|
|
|
dev_dbg(&udev->dev, "device reset changed speed!\n");
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
oldspeed = udev->speed;
|
2007-07-31 05:08:43 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/* USB 2.0 section 5.5.3 talks about ep0 maxpacket ...
|
|
|
|
* it's fixed size except for full speed devices.
|
2006-08-26 10:35:30 +08:00
|
|
|
* For Wireless USB devices, ep0 max packet is always 512 (tho
|
|
|
|
* reported as 0xff in the device descriptor). WUSB1.0[4.8.1].
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
|
|
|
switch (udev->speed) {
|
2015-12-10 15:59:25 +08:00
|
|
|
case USB_SPEED_SUPER_PLUS:
|
2009-04-28 10:54:10 +08:00
|
|
|
case USB_SPEED_SUPER:
|
2010-01-15 03:08:04 +08:00
|
|
|
case USB_SPEED_WIRELESS: /* fixed at 512 */
|
2009-02-12 06:11:36 +08:00
|
|
|
udev->ep0.desc.wMaxPacketSize = cpu_to_le16(512);
|
2006-08-26 10:35:30 +08:00
|
|
|
break;
|
2005-04-17 06:20:36 +08:00
|
|
|
case USB_SPEED_HIGH: /* fixed at 64 */
|
2009-02-12 06:11:36 +08:00
|
|
|
udev->ep0.desc.wMaxPacketSize = cpu_to_le16(64);
|
2005-04-17 06:20:36 +08:00
|
|
|
break;
|
|
|
|
case USB_SPEED_FULL: /* 8, 16, 32, or 64 */
|
|
|
|
/* to determine the ep0 maxpacket size, try to read
|
|
|
|
* the device descriptor to get bMaxPacketSize0 and
|
|
|
|
* then correct our initial guess.
|
|
|
|
*/
|
2009-02-12 06:11:36 +08:00
|
|
|
udev->ep0.desc.wMaxPacketSize = cpu_to_le16(64);
|
2005-04-17 06:20:36 +08:00
|
|
|
break;
|
|
|
|
case USB_SPEED_LOW: /* fixed at 8 */
|
2009-02-12 06:11:36 +08:00
|
|
|
udev->ep0.desc.wMaxPacketSize = cpu_to_le16(8);
|
2005-04-17 06:20:36 +08:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
goto fail;
|
|
|
|
}
|
2011-08-30 23:11:19 +08:00
|
|
|
|
|
|
|
if (udev->speed == USB_SPEED_WIRELESS)
|
|
|
|
speed = "variable speed Wireless";
|
|
|
|
else
|
|
|
|
speed = usb_speed_string(udev->speed);
|
|
|
|
|
2015-12-10 15:59:25 +08:00
|
|
|
if (udev->speed < USB_SPEED_SUPER)
|
2009-04-28 10:57:26 +08:00
|
|
|
dev_info(&udev->dev,
|
2011-08-30 23:11:19 +08:00
|
|
|
"%s %s USB device number %d using %s\n",
|
|
|
|
(udev->config) ? "reset" : "new", speed,
|
2011-02-22 22:53:41 +08:00
|
|
|
devnum, udev->bus->controller->driver->name);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/* Set up TT records, if needed */
|
|
|
|
if (hdev->tt) {
|
|
|
|
udev->tt = hdev->tt;
|
|
|
|
udev->ttport = hdev->ttport;
|
|
|
|
} else if (udev->speed != USB_SPEED_HIGH
|
|
|
|
&& hdev->speed == USB_SPEED_HIGH) {
|
2011-01-31 23:56:37 +08:00
|
|
|
if (!hub->tt.hub) {
|
|
|
|
dev_err(&udev->dev, "parent hub has no TT\n");
|
|
|
|
retval = -EINVAL;
|
|
|
|
goto fail;
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
udev->tt = &hub->tt;
|
|
|
|
udev->ttport = port1;
|
|
|
|
}
|
2013-10-11 05:41:27 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/* Why interleave GET_DESCRIPTOR and SET_ADDRESS this way?
|
|
|
|
* Because device hardware and firmware is sometimes buggy in
|
|
|
|
* this area, and this is how Linux has done it for ages.
|
|
|
|
* Change it cautiously.
|
|
|
|
*
|
2013-12-06 09:07:27 +08:00
|
|
|
* NOTE: If use_new_scheme() is true we will start by issuing
|
2005-04-17 06:20:36 +08:00
|
|
|
* a 64-byte GET_DESCRIPTOR request. This is what Windows does,
|
|
|
|
* so it may help with some non-standards-compliant devices.
|
|
|
|
* Otherwise we start with SET_ADDRESS and then try to read the
|
|
|
|
* first 8 bytes of the device descriptor to get the ep0 maxpacket
|
|
|
|
* value.
|
|
|
|
*/
|
2016-02-17 18:52:43 +08:00
|
|
|
for (retries = 0; retries < GET_DESCRIPTOR_TRIES; (++retries, msleep(100))) {
|
2013-12-06 09:07:27 +08:00
|
|
|
bool did_new_scheme = false;
|
|
|
|
|
|
|
|
if (use_new_scheme(udev, retry_counter)) {
|
2005-04-17 06:20:36 +08:00
|
|
|
struct usb_device_descriptor *buf;
|
|
|
|
int r = 0;
|
|
|
|
|
2013-12-06 09:07:27 +08:00
|
|
|
did_new_scheme = true;
|
|
|
|
retval = hub_enable_device(udev);
|
2014-02-27 17:57:10 +08:00
|
|
|
if (retval < 0) {
|
|
|
|
dev_err(&udev->dev,
|
|
|
|
"hub failed to enable device, error %d\n",
|
|
|
|
retval);
|
2013-12-06 09:07:27 +08:00
|
|
|
goto fail;
|
2014-02-27 17:57:10 +08:00
|
|
|
}
|
2013-12-06 09:07:27 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
#define GET_DESCRIPTOR_BUFSIZE 64
|
|
|
|
buf = kmalloc(GET_DESCRIPTOR_BUFSIZE, GFP_NOIO);
|
|
|
|
if (!buf) {
|
|
|
|
retval = -ENOMEM;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2007-05-11 22:19:04 +08:00
|
|
|
/* Retry on all errors; some devices are flakey.
|
|
|
|
* 255 is for WUSB devices, we actually need to use
|
|
|
|
* 512 (WUSB1.0[4.8.1]).
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
2016-02-17 18:52:43 +08:00
|
|
|
for (operations = 0; operations < 3; ++operations) {
|
2005-04-17 06:20:36 +08:00
|
|
|
buf->bMaxPacketSize0 = 0;
|
|
|
|
r = usb_control_msg(udev, usb_rcvaddr0pipe(),
|
|
|
|
USB_REQ_GET_DESCRIPTOR, USB_DIR_IN,
|
|
|
|
USB_DT_DEVICE << 8, 0,
|
|
|
|
buf, GET_DESCRIPTOR_BUFSIZE,
|
2008-10-10 22:24:45 +08:00
|
|
|
initial_descriptor_timeout);
|
2005-04-17 06:20:36 +08:00
|
|
|
switch (buf->bMaxPacketSize0) {
|
2006-08-26 10:35:30 +08:00
|
|
|
case 8: case 16: case 32: case 64: case 255:
|
2005-04-17 06:20:36 +08:00
|
|
|
if (buf->bDescriptorType ==
|
|
|
|
USB_DT_DEVICE) {
|
|
|
|
r = 0;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
/* FALL THROUGH */
|
|
|
|
default:
|
|
|
|
if (r == 0)
|
|
|
|
r = -EPROTO;
|
|
|
|
break;
|
|
|
|
}
|
2016-02-10 18:33:18 +08:00
|
|
|
/*
|
|
|
|
* Some devices time out if they are powered on
|
|
|
|
* when already connected. They need a second
|
|
|
|
* reset. But only on the first attempt,
|
|
|
|
* lest we get into a time out/reset loop
|
|
|
|
*/
|
2016-02-17 18:52:43 +08:00
|
|
|
if (r == 0 || (r == -ETIMEDOUT && retries == 0))
|
2005-04-17 06:20:36 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
udev->descriptor.bMaxPacketSize0 =
|
|
|
|
buf->bMaxPacketSize0;
|
|
|
|
kfree(buf);
|
|
|
|
|
2011-09-14 07:41:11 +08:00
|
|
|
retval = hub_port_reset(hub, port1, udev, delay, false);
|
2005-04-17 06:20:36 +08:00
|
|
|
if (retval < 0) /* error or disconnect */
|
|
|
|
goto fail;
|
|
|
|
if (oldspeed != udev->speed) {
|
|
|
|
dev_dbg(&udev->dev,
|
|
|
|
"device reset changed speed!\n");
|
|
|
|
retval = -ENODEV;
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
if (r) {
|
2013-03-28 04:14:01 +08:00
|
|
|
if (r != -ENODEV)
|
|
|
|
dev_err(&udev->dev, "device descriptor read/64, error %d\n",
|
|
|
|
r);
|
2005-04-17 06:20:36 +08:00
|
|
|
retval = -EMSGSIZE;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
#undef GET_DESCRIPTOR_BUFSIZE
|
|
|
|
}
|
|
|
|
|
2013-10-11 05:41:27 +08:00
|
|
|
/*
|
|
|
|
* If device is WUSB, we already assigned an
|
|
|
|
* unauthorized address in the Connect Ack sequence;
|
|
|
|
* authorization will assign the final address.
|
|
|
|
*/
|
2009-04-28 10:57:26 +08:00
|
|
|
if (udev->wusb == 0) {
|
2016-02-17 18:52:43 +08:00
|
|
|
for (operations = 0; operations < SET_ADDRESS_TRIES; ++operations) {
|
2008-04-09 04:24:46 +08:00
|
|
|
retval = hub_set_address(udev, devnum);
|
|
|
|
if (retval >= 0)
|
|
|
|
break;
|
|
|
|
msleep(200);
|
|
|
|
}
|
|
|
|
if (retval < 0) {
|
2013-03-28 04:14:01 +08:00
|
|
|
if (retval != -ENODEV)
|
|
|
|
dev_err(&udev->dev, "device not accepting address %d, error %d\n",
|
|
|
|
devnum, retval);
|
2008-04-09 04:24:46 +08:00
|
|
|
goto fail;
|
|
|
|
}
|
2015-12-10 15:59:25 +08:00
|
|
|
if (udev->speed >= USB_SPEED_SUPER) {
|
2009-04-28 10:57:26 +08:00
|
|
|
devnum = udev->devnum;
|
|
|
|
dev_info(&udev->dev,
|
2015-12-10 15:59:25 +08:00
|
|
|
"%s SuperSpeed%s USB device number %d using %s\n",
|
2009-04-28 10:57:26 +08:00
|
|
|
(udev->config) ? "reset" : "new",
|
2015-12-10 15:59:25 +08:00
|
|
|
(udev->speed == USB_SPEED_SUPER_PLUS) ? "Plus" : "",
|
2011-02-22 22:53:41 +08:00
|
|
|
devnum, udev->bus->controller->driver->name);
|
2009-04-28 10:57:26 +08:00
|
|
|
}
|
2008-04-09 04:24:46 +08:00
|
|
|
|
|
|
|
/* cope with hardware quirkiness:
|
|
|
|
* - let SET_ADDRESS settle, some device hardware wants it
|
|
|
|
* - read ep0 maxpacket even for high and low speed,
|
|
|
|
*/
|
|
|
|
msleep(10);
|
2013-12-06 09:07:27 +08:00
|
|
|
/* use_new_scheme() checks the speed which may have
|
|
|
|
* changed since the initial look so we cache the result
|
|
|
|
* in did_new_scheme
|
|
|
|
*/
|
|
|
|
if (did_new_scheme)
|
2005-04-17 06:20:36 +08:00
|
|
|
break;
|
2013-10-11 05:41:27 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
retval = usb_get_device_descriptor(udev, 8);
|
|
|
|
if (retval < 8) {
|
2013-03-28 04:14:01 +08:00
|
|
|
if (retval != -ENODEV)
|
|
|
|
dev_err(&udev->dev,
|
2008-12-15 15:32:01 +08:00
|
|
|
"device descriptor read/8, error %d\n",
|
|
|
|
retval);
|
2005-04-17 06:20:36 +08:00
|
|
|
if (retval >= 0)
|
|
|
|
retval = -EMSGSIZE;
|
|
|
|
} else {
|
|
|
|
retval = 0;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (retval)
|
|
|
|
goto fail;
|
|
|
|
|
2012-03-26 21:16:02 +08:00
|
|
|
/*
|
|
|
|
* Some superspeed devices have finished the link training process
|
|
|
|
* and attached to a superspeed hub port, but the device descriptor
|
|
|
|
* got from those devices show they aren't superspeed devices. Warm
|
|
|
|
* reset the port attached by the devices can fix them.
|
|
|
|
*/
|
2015-12-10 15:59:25 +08:00
|
|
|
if ((udev->speed >= USB_SPEED_SUPER) &&
|
2012-03-26 21:16:02 +08:00
|
|
|
(le16_to_cpu(udev->descriptor.bcdUSB) < 0x0300)) {
|
|
|
|
dev_err(&udev->dev, "got a wrong device descriptor, "
|
|
|
|
"warm reset device\n");
|
|
|
|
hub_port_reset(hub, port1, udev,
|
|
|
|
HUB_BH_RESET_TIME, true);
|
|
|
|
retval = -EINVAL;
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
2009-04-28 10:54:10 +08:00
|
|
|
if (udev->descriptor.bMaxPacketSize0 == 0xff ||
|
2015-12-10 15:59:25 +08:00
|
|
|
udev->speed >= USB_SPEED_SUPER)
|
2009-04-28 10:54:10 +08:00
|
|
|
i = 512;
|
|
|
|
else
|
|
|
|
i = udev->descriptor.bMaxPacketSize0;
|
2011-08-23 18:12:03 +08:00
|
|
|
if (usb_endpoint_maxp(&udev->ep0.desc) != i) {
|
2010-10-15 03:25:21 +08:00
|
|
|
if (udev->speed == USB_SPEED_LOW ||
|
2005-04-17 06:20:36 +08:00
|
|
|
!(i == 8 || i == 16 || i == 32 || i == 64)) {
|
2010-10-15 03:25:21 +08:00
|
|
|
dev_err(&udev->dev, "Invalid ep0 maxpacket: %d\n", i);
|
2005-04-17 06:20:36 +08:00
|
|
|
retval = -EMSGSIZE;
|
|
|
|
goto fail;
|
|
|
|
}
|
2010-10-15 03:25:21 +08:00
|
|
|
if (udev->speed == USB_SPEED_FULL)
|
|
|
|
dev_dbg(&udev->dev, "ep0 maxpacket = %d\n", i);
|
|
|
|
else
|
|
|
|
dev_warn(&udev->dev, "Using ep0 maxpacket: %d\n", i);
|
2005-04-17 06:20:36 +08:00
|
|
|
udev->ep0.desc.wMaxPacketSize = cpu_to_le16(i);
|
2008-04-09 04:24:46 +08:00
|
|
|
usb_ep0_reinit(udev);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2013-10-11 05:41:27 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
retval = usb_get_device_descriptor(udev, USB_DT_DEVICE_SIZE);
|
|
|
|
if (retval < (signed)sizeof(udev->descriptor)) {
|
2013-03-28 04:14:01 +08:00
|
|
|
if (retval != -ENODEV)
|
|
|
|
dev_err(&udev->dev, "device descriptor read/all, error %d\n",
|
|
|
|
retval);
|
2005-04-17 06:20:36 +08:00
|
|
|
if (retval >= 0)
|
|
|
|
retval = -ENOMSG;
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
2015-12-11 04:27:21 +08:00
|
|
|
usb_detect_quirks(udev);
|
|
|
|
|
2011-09-24 05:19:48 +08:00
|
|
|
if (udev->wusb == 0 && le16_to_cpu(udev->descriptor.bcdUSB) >= 0x0201) {
|
|
|
|
retval = usb_get_bos_descriptor(udev);
|
USB: Calculate USB 3.0 exit latencies for LPM.
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
2012-02-21 04:02:19 +08:00
|
|
|
if (!retval) {
|
2012-02-21 00:31:26 +08:00
|
|
|
udev->lpm_capable = usb_device_supports_lpm(udev);
|
USB: Calculate USB 3.0 exit latencies for LPM.
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
2012-02-21 04:02:19 +08:00
|
|
|
usb_set_lpm_parameters(udev);
|
|
|
|
}
|
2011-09-24 05:19:48 +08:00
|
|
|
}
|
2011-09-24 05:19:47 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
retval = 0;
|
2010-06-04 15:47:55 +08:00
|
|
|
/* notify HCD that we have a device connected and addressed */
|
|
|
|
if (hcd->driver->update_device)
|
|
|
|
hcd->driver->update_device(hcd, udev);
|
2013-09-30 22:26:31 +08:00
|
|
|
hub_set_initial_usb2_lpm_policy(udev);
|
2005-04-17 06:20:36 +08:00
|
|
|
fail:
|
2007-07-31 05:08:43 +08:00
|
|
|
if (retval) {
|
2005-04-17 06:20:36 +08:00
|
|
|
hub_port_disable(hub, port1, 0);
|
2011-02-22 22:53:41 +08:00
|
|
|
update_devnum(udev, devnum); /* for disconnect processing */
|
2007-07-31 05:08:43 +08:00
|
|
|
}
|
2016-04-25 20:48:38 +08:00
|
|
|
mutex_unlock(hcd->address0_mutex);
|
2005-04-17 06:20:36 +08:00
|
|
|
return retval;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2015-08-19 11:36:58 +08:00
|
|
|
check_highspeed(struct usb_hub *hub, struct usb_device *udev, int port1)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
struct usb_qualifier_descriptor *qual;
|
|
|
|
int status;
|
|
|
|
|
2014-08-25 23:51:26 +08:00
|
|
|
if (udev->quirks & USB_QUIRK_DEVICE_QUALIFIER)
|
|
|
|
return;
|
|
|
|
|
2015-08-19 11:36:58 +08:00
|
|
|
qual = kmalloc(sizeof *qual, GFP_KERNEL);
|
2005-04-17 06:20:36 +08:00
|
|
|
if (qual == NULL)
|
|
|
|
return;
|
|
|
|
|
2015-08-19 11:36:58 +08:00
|
|
|
status = usb_get_descriptor(udev, USB_DT_DEVICE_QUALIFIER, 0,
|
2005-04-17 06:20:36 +08:00
|
|
|
qual, sizeof *qual);
|
|
|
|
if (status == sizeof *qual) {
|
|
|
|
dev_info(&udev->dev, "not running at top speed; "
|
|
|
|
"connect to a high speed hub\n");
|
|
|
|
/* hub LEDs are probably harder to miss than syslog */
|
|
|
|
if (hub->has_indicators) {
|
|
|
|
hub->indicator[port1-1] = INDICATOR_GREEN_BLINK;
|
2014-02-02 11:16:46 +08:00
|
|
|
queue_delayed_work(system_power_efficient_wq,
|
|
|
|
&hub->leds, 0);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
}
|
2005-04-19 08:39:34 +08:00
|
|
|
kfree(qual);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static unsigned
|
2015-08-19 11:36:58 +08:00
|
|
|
hub_power_remaining(struct usb_hub *hub)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
struct usb_device *hdev = hub->hdev;
|
|
|
|
int remaining;
|
2005-11-24 01:03:12 +08:00
|
|
|
int port1;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2005-11-24 01:03:12 +08:00
|
|
|
if (!hub->limited_power)
|
2005-04-17 06:20:36 +08:00
|
|
|
return 0;
|
|
|
|
|
2005-11-24 01:03:12 +08:00
|
|
|
remaining = hdev->bus_mA - hub->descriptor->bHubContrCurrent;
|
|
|
|
for (port1 = 1; port1 <= hdev->maxchild; ++port1) {
|
2014-05-21 09:08:17 +08:00
|
|
|
struct usb_port *port_dev = hub->ports[port1 - 1];
|
|
|
|
struct usb_device *udev = port_dev->child;
|
|
|
|
unsigned unit_load;
|
|
|
|
int delta;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
if (!udev)
|
|
|
|
continue;
|
2012-12-18 22:25:47 +08:00
|
|
|
if (hub_is_superspeed(udev))
|
|
|
|
unit_load = 150;
|
|
|
|
else
|
|
|
|
unit_load = 100;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2012-12-18 22:25:47 +08:00
|
|
|
/*
|
|
|
|
* Unconfigured devices may not use more than one unit load,
|
|
|
|
* or 8mA for OTG ports
|
|
|
|
*/
|
2005-04-17 06:20:36 +08:00
|
|
|
if (udev->actconfig)
|
2012-12-18 22:25:46 +08:00
|
|
|
delta = usb_get_max_power(udev, udev->actconfig);
|
2005-11-24 01:03:12 +08:00
|
|
|
else if (port1 != udev->bus->otg_port || hdev->parent)
|
2012-12-18 22:25:47 +08:00
|
|
|
delta = unit_load;
|
2005-04-17 06:20:36 +08:00
|
|
|
else
|
2005-11-24 01:03:12 +08:00
|
|
|
delta = 8;
|
|
|
|
if (delta > hub->mA_per_port)
|
2014-05-21 09:08:17 +08:00
|
|
|
dev_warn(&port_dev->dev, "%dmA is over %umA budget!\n",
|
|
|
|
delta, hub->mA_per_port);
|
2005-04-17 06:20:36 +08:00
|
|
|
remaining -= delta;
|
|
|
|
}
|
|
|
|
if (remaining < 0) {
|
2005-11-24 01:03:12 +08:00
|
|
|
dev_warn(hub->intfdev, "%dmA over power budget!\n",
|
2013-10-11 05:41:27 +08:00
|
|
|
-remaining);
|
2005-04-17 06:20:36 +08:00
|
|
|
remaining = 0;
|
|
|
|
}
|
|
|
|
return remaining;
|
|
|
|
}
|
|
|
|
|
2014-05-21 09:09:15 +08:00
|
|
|
static void hub_port_connect(struct usb_hub *hub, int port1, u16 portstatus,
|
|
|
|
u16 portchange)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
int status, i;
|
2012-12-18 22:25:47 +08:00
|
|
|
unsigned unit_load;
|
2005-04-17 06:20:36 +08:00
|
|
|
struct usb_device *hdev = hub->hdev;
|
2007-11-22 04:28:14 +08:00
|
|
|
struct usb_hcd *hcd = bus_to_hcd(hdev->bus);
|
2014-05-21 09:08:17 +08:00
|
|
|
struct usb_port *port_dev = hub->ports[port1 - 1];
|
2014-05-21 09:09:15 +08:00
|
|
|
struct usb_device *udev = port_dev->child;
|
2014-07-14 21:39:49 +08:00
|
|
|
static int unreliable_port = -1;
|
2008-04-28 23:06:55 +08:00
|
|
|
|
2008-04-28 23:06:28 +08:00
|
|
|
/* Disconnect any existing devices under this port */
|
2012-11-09 09:44:43 +08:00
|
|
|
if (udev) {
|
2014-11-04 11:14:31 +08:00
|
|
|
if (hcd->usb_phy && !hdev->parent)
|
2014-09-25 03:05:50 +08:00
|
|
|
usb_phy_notify_disconnect(hcd->usb_phy, udev->speed);
|
2014-05-21 09:08:17 +08:00
|
|
|
usb_disconnect(&port_dev->child);
|
2012-11-09 09:44:43 +08:00
|
|
|
}
|
2008-04-28 23:06:28 +08:00
|
|
|
|
2009-10-28 03:20:13 +08:00
|
|
|
/* We can forget about a "removed" device when there's a physical
|
|
|
|
* disconnect or the connect status changes.
|
|
|
|
*/
|
|
|
|
if (!(portstatus & USB_PORT_STAT_CONNECTION) ||
|
|
|
|
(portchange & USB_PORT_STAT_C_CONNECTION))
|
|
|
|
clear_bit(port1, hub->removed_bits);
|
|
|
|
|
2008-09-23 02:43:08 +08:00
|
|
|
if (portchange & (USB_PORT_STAT_C_CONNECTION |
|
|
|
|
USB_PORT_STAT_C_ENABLE)) {
|
2013-01-23 04:26:30 +08:00
|
|
|
status = hub_port_debounce_be_stable(hub, port1);
|
2008-09-23 02:43:08 +08:00
|
|
|
if (status < 0) {
|
2014-07-14 21:39:49 +08:00
|
|
|
if (status != -ENODEV &&
|
|
|
|
port1 != unreliable_port &&
|
|
|
|
printk_ratelimit())
|
2014-08-19 23:37:55 +08:00
|
|
|
dev_err(&port_dev->dev, "connect-debounce failed\n");
|
2008-09-23 02:43:08 +08:00
|
|
|
portstatus &= ~USB_PORT_STAT_CONNECTION;
|
2014-07-14 21:39:49 +08:00
|
|
|
unreliable_port = port1;
|
2008-09-23 02:43:08 +08:00
|
|
|
} else {
|
|
|
|
portstatus = status;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-10-28 03:20:13 +08:00
|
|
|
/* Return now if debouncing failed or nothing is connected or
|
|
|
|
* the device was "removed".
|
|
|
|
*/
|
|
|
|
if (!(portstatus & USB_PORT_STAT_CONNECTION) ||
|
|
|
|
test_bit(port1, hub->removed_bits)) {
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2015-01-22 02:09:58 +08:00
|
|
|
/*
|
|
|
|
* maybe switch power back on (e.g. root hub was reset)
|
|
|
|
* but only if the port isn't owned by someone else.
|
|
|
|
*/
|
2014-05-21 09:08:12 +08:00
|
|
|
if (hub_is_port_power_switchable(hub)
|
2015-01-22 02:09:58 +08:00
|
|
|
&& !port_is_power_on(hub, portstatus)
|
|
|
|
&& !port_dev->port_owner)
|
2005-04-17 06:20:36 +08:00
|
|
|
set_port_feature(hdev, port1, USB_PORT_FEAT_POWER);
|
2008-09-23 02:43:08 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
if (portstatus & USB_PORT_STAT_ENABLE)
|
2013-10-11 05:41:27 +08:00
|
|
|
goto done;
|
2005-04-17 06:20:36 +08:00
|
|
|
return;
|
|
|
|
}
|
2012-12-18 22:25:47 +08:00
|
|
|
if (hub_is_superspeed(hub->hdev))
|
|
|
|
unit_load = 150;
|
|
|
|
else
|
|
|
|
unit_load = 100;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2013-03-28 04:14:01 +08:00
|
|
|
status = 0;
|
2005-04-17 06:20:36 +08:00
|
|
|
for (i = 0; i < SET_CONFIG_TRIES; i++) {
|
|
|
|
|
|
|
|
/* reallocate for each attempt, since references
|
|
|
|
* to the previous one can escape in various ways
|
|
|
|
*/
|
|
|
|
udev = usb_alloc_dev(hdev, hdev->bus, port1);
|
|
|
|
if (!udev) {
|
2014-05-21 09:08:17 +08:00
|
|
|
dev_err(&port_dev->dev,
|
|
|
|
"couldn't allocate usb_device\n");
|
2005-04-17 06:20:36 +08:00
|
|
|
goto done;
|
|
|
|
}
|
|
|
|
|
|
|
|
usb_set_device_state(udev, USB_STATE_POWERED);
|
2013-10-11 05:41:27 +08:00
|
|
|
udev->bus_mA = hub->mA_per_port;
|
2006-08-31 03:46:48 +08:00
|
|
|
udev->level = hdev->level + 1;
|
2008-04-09 04:24:46 +08:00
|
|
|
udev->wusb = hub_is_wusb(hub);
|
2005-11-24 01:03:12 +08:00
|
|
|
|
2015-12-10 15:59:25 +08:00
|
|
|
/* Devices connected to SuperSpeed hubs are USB 3.0 or later */
|
2010-12-07 13:00:19 +08:00
|
|
|
if (hub_is_superspeed(hub->hdev))
|
2009-04-28 10:54:26 +08:00
|
|
|
udev->speed = USB_SPEED_SUPER;
|
|
|
|
else
|
|
|
|
udev->speed = USB_SPEED_UNKNOWN;
|
|
|
|
|
2011-02-22 22:53:41 +08:00
|
|
|
choose_devnum(udev);
|
2010-10-14 22:22:51 +08:00
|
|
|
if (udev->devnum <= 0) {
|
|
|
|
status = -ENOTCONN; /* Don't retry */
|
|
|
|
goto loop;
|
2009-04-28 10:57:26 +08:00
|
|
|
}
|
|
|
|
|
2009-04-28 10:54:26 +08:00
|
|
|
/* reset (non-USB 3.0 devices) and get descriptor */
|
2014-05-21 09:09:26 +08:00
|
|
|
usb_lock_port(port_dev);
|
2005-04-17 06:20:36 +08:00
|
|
|
status = hub_port_init(hub, udev, port1, i);
|
2014-05-21 09:09:26 +08:00
|
|
|
usb_unlock_port(port_dev);
|
2005-04-17 06:20:36 +08:00
|
|
|
if (status < 0)
|
|
|
|
goto loop;
|
|
|
|
|
2010-07-22 06:05:01 +08:00
|
|
|
if (udev->quirks & USB_QUIRK_DELAY_INIT)
|
|
|
|
msleep(1000);
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/* consecutive bus-powered hubs aren't reliable; they can
|
|
|
|
* violate the voltage drop budget. if the new child has
|
|
|
|
* a "powered" LED, users should notice we didn't enable it
|
|
|
|
* (without reading syslog), even without per-port LEDs
|
|
|
|
* on the parent.
|
|
|
|
*/
|
|
|
|
if (udev->descriptor.bDeviceClass == USB_CLASS_HUB
|
2012-12-18 22:25:47 +08:00
|
|
|
&& udev->bus_mA <= unit_load) {
|
2005-04-17 06:20:36 +08:00
|
|
|
u16 devstat;
|
|
|
|
|
|
|
|
status = usb_get_status(udev, USB_RECIP_DEVICE, 0,
|
|
|
|
&devstat);
|
2013-07-31 03:35:40 +08:00
|
|
|
if (status) {
|
2005-04-17 06:20:36 +08:00
|
|
|
dev_dbg(&udev->dev, "get status %d ?\n", status);
|
|
|
|
goto loop_disable;
|
|
|
|
}
|
|
|
|
if ((devstat & (1 << USB_DEVICE_SELF_POWERED)) == 0) {
|
|
|
|
dev_err(&udev->dev,
|
|
|
|
"can't connect bus-powered hub "
|
|
|
|
"to this port\n");
|
|
|
|
if (hub->has_indicators) {
|
|
|
|
hub->indicator[port1-1] =
|
|
|
|
INDICATOR_AMBER_BLINK;
|
2014-02-02 11:16:46 +08:00
|
|
|
queue_delayed_work(
|
|
|
|
system_power_efficient_wq,
|
|
|
|
&hub->leds, 0);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
status = -ENOTCONN; /* Don't retry */
|
|
|
|
goto loop_disable;
|
|
|
|
}
|
|
|
|
}
|
2013-10-11 05:41:27 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/* check for devices running slower than they could */
|
|
|
|
if (le16_to_cpu(udev->descriptor.bcdUSB) >= 0x0200
|
|
|
|
&& udev->speed == USB_SPEED_FULL
|
|
|
|
&& highspeed_hubs != 0)
|
2015-08-19 11:36:58 +08:00
|
|
|
check_highspeed(hub, udev, port1);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2012-05-15 00:20:37 +08:00
|
|
|
/* Store the parent's children[] pointer. At this point
|
2005-04-17 06:20:36 +08:00
|
|
|
* udev becomes globally accessible, although presumably
|
|
|
|
* no one will look at it until hdev is unlocked.
|
|
|
|
*/
|
|
|
|
status = 0;
|
|
|
|
|
2014-05-21 09:08:28 +08:00
|
|
|
mutex_lock(&usb_port_peer_mutex);
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/* We mustn't add new devices if the parent hub has
|
|
|
|
* been disconnected; we would race with the
|
|
|
|
* recursively_mark_NOTATTACHED() routine.
|
|
|
|
*/
|
|
|
|
spin_lock_irq(&device_state_lock);
|
|
|
|
if (hdev->state == USB_STATE_NOTATTACHED)
|
|
|
|
status = -ENOTCONN;
|
|
|
|
else
|
2014-05-21 09:08:17 +08:00
|
|
|
port_dev->child = udev;
|
2005-04-17 06:20:36 +08:00
|
|
|
spin_unlock_irq(&device_state_lock);
|
2014-05-21 09:08:28 +08:00
|
|
|
mutex_unlock(&usb_port_peer_mutex);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/* Run it through the hoops (find a driver, etc) */
|
|
|
|
if (!status) {
|
|
|
|
status = usb_new_device(udev);
|
|
|
|
if (status) {
|
2014-05-21 09:08:28 +08:00
|
|
|
mutex_lock(&usb_port_peer_mutex);
|
2005-04-17 06:20:36 +08:00
|
|
|
spin_lock_irq(&device_state_lock);
|
2014-05-21 09:08:17 +08:00
|
|
|
port_dev->child = NULL;
|
2005-04-17 06:20:36 +08:00
|
|
|
spin_unlock_irq(&device_state_lock);
|
2014-05-21 09:08:28 +08:00
|
|
|
mutex_unlock(&usb_port_peer_mutex);
|
2014-10-17 19:43:02 +08:00
|
|
|
} else {
|
|
|
|
if (hcd->usb_phy && !hdev->parent)
|
|
|
|
usb_phy_notify_connect(hcd->usb_phy,
|
|
|
|
udev->speed);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (status)
|
|
|
|
goto loop_disable;
|
|
|
|
|
|
|
|
status = hub_power_remaining(hub);
|
|
|
|
if (status)
|
2014-05-21 09:08:17 +08:00
|
|
|
dev_dbg(hub->intfdev, "%dmA power budget left\n", status);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
loop_disable:
|
|
|
|
hub_port_disable(hub, port1, 1);
|
|
|
|
loop:
|
2008-04-09 04:24:46 +08:00
|
|
|
usb_ep0_reinit(udev);
|
2011-02-22 22:53:41 +08:00
|
|
|
release_devnum(udev);
|
2010-01-10 17:15:03 +08:00
|
|
|
hub_free_dev(udev);
|
2005-04-17 06:20:36 +08:00
|
|
|
usb_put_dev(udev);
|
2007-05-26 12:31:07 +08:00
|
|
|
if ((status == -ENOTCONN) || (status == -ENOTSUPP))
|
2005-04-17 06:20:36 +08:00
|
|
|
break;
|
|
|
|
}
|
2008-05-21 04:58:29 +08:00
|
|
|
if (hub->hdev->parent ||
|
|
|
|
!hcd->driver->port_handed_over ||
|
2013-03-28 04:14:01 +08:00
|
|
|
!(hcd->driver->port_handed_over)(hcd, port1)) {
|
|
|
|
if (status != -ENOTCONN && status != -ENODEV)
|
2014-05-21 09:08:17 +08:00
|
|
|
dev_err(&port_dev->dev,
|
|
|
|
"unable to enumerate USB device\n");
|
2013-03-28 04:14:01 +08:00
|
|
|
}
|
2013-10-11 05:41:27 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
done:
|
|
|
|
hub_port_disable(hub, port1, 1);
|
2007-11-22 04:28:14 +08:00
|
|
|
if (hcd->driver->relinquish_port && !hub->hdev->parent)
|
|
|
|
hcd->driver->relinquish_port(hcd, port1);
|
2014-05-21 09:09:15 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2014-05-21 09:09:15 +08:00
|
|
|
/* Handle physical or logical connection change events.
|
|
|
|
* This routine is called when:
|
|
|
|
* a port connection-change occurs;
|
|
|
|
* a port enable-change occurs (often caused by EMI);
|
|
|
|
* usb_reset_and_verify_device() encounters changed descriptors (as from
|
|
|
|
* a firmware download)
|
|
|
|
* caller already locked the hub
|
|
|
|
*/
|
|
|
|
static void hub_port_connect_change(struct usb_hub *hub, int port1,
|
|
|
|
u16 portstatus, u16 portchange)
|
2014-05-21 09:09:26 +08:00
|
|
|
__must_hold(&port_dev->status_lock)
|
2012-01-25 05:53:18 +08:00
|
|
|
{
|
2014-05-21 09:09:15 +08:00
|
|
|
struct usb_port *port_dev = hub->ports[port1 - 1];
|
|
|
|
struct usb_device *udev = port_dev->child;
|
|
|
|
int status = -ENODEV;
|
2012-01-25 05:53:18 +08:00
|
|
|
|
2014-05-21 09:09:15 +08:00
|
|
|
dev_dbg(&port_dev->dev, "status %04x, change %04x, %s\n", portstatus,
|
|
|
|
portchange, portspeed(hub, portstatus));
|
|
|
|
|
|
|
|
if (hub->has_indicators) {
|
|
|
|
set_port_led(hub, port1, HUB_LED_AUTO);
|
|
|
|
hub->indicator[port1-1] = INDICATOR_AUTO;
|
USB/xHCI: Support device-initiated USB 3.0 resume.
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-11-15 10:00:01 +08:00
|
|
|
}
|
|
|
|
|
2014-05-21 09:09:15 +08:00
|
|
|
#ifdef CONFIG_USB_OTG
|
|
|
|
/* during HNP, don't repeat the debounce */
|
|
|
|
if (hub->hdev->bus->is_b_host)
|
|
|
|
portchange &= ~(USB_PORT_STAT_C_CONNECTION |
|
|
|
|
USB_PORT_STAT_C_ENABLE);
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/* Try to resuscitate an existing device */
|
|
|
|
if ((portstatus & USB_PORT_STAT_CONNECTION) && udev &&
|
|
|
|
udev->state != USB_STATE_NOTATTACHED) {
|
|
|
|
if (portstatus & USB_PORT_STAT_ENABLE) {
|
|
|
|
status = 0; /* Nothing to do */
|
2014-11-30 06:47:05 +08:00
|
|
|
#ifdef CONFIG_PM
|
2014-05-21 09:09:15 +08:00
|
|
|
} else if (udev->state == USB_STATE_SUSPENDED &&
|
|
|
|
udev->persist_enabled) {
|
|
|
|
/* For a suspended device, treat this as a
|
|
|
|
* remote wakeup event.
|
|
|
|
*/
|
2014-05-21 09:09:26 +08:00
|
|
|
usb_unlock_port(port_dev);
|
2014-05-21 09:09:15 +08:00
|
|
|
status = usb_remote_wakeup(udev);
|
2014-05-21 09:09:26 +08:00
|
|
|
usb_lock_port(port_dev);
|
2014-05-21 09:09:15 +08:00
|
|
|
#endif
|
|
|
|
} else {
|
|
|
|
/* Don't resuscitate */;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
clear_bit(port1, hub->change_bits);
|
|
|
|
|
2014-05-21 09:09:26 +08:00
|
|
|
/* successfully revalidated the connection */
|
2014-05-21 09:09:15 +08:00
|
|
|
if (status == 0)
|
|
|
|
return;
|
|
|
|
|
2014-05-21 09:09:26 +08:00
|
|
|
usb_unlock_port(port_dev);
|
2014-05-21 09:09:15 +08:00
|
|
|
hub_port_connect(hub, port1, portstatus, portchange);
|
2014-05-21 09:09:26 +08:00
|
|
|
usb_lock_port(port_dev);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2014-05-21 09:09:15 +08:00
|
|
|
static void port_event(struct usb_hub *hub, int port1)
|
2014-05-21 09:09:26 +08:00
|
|
|
__must_hold(&port_dev->status_lock)
|
2014-05-21 09:09:15 +08:00
|
|
|
{
|
2015-01-26 23:30:39 +08:00
|
|
|
int connect_change;
|
2014-05-21 09:09:15 +08:00
|
|
|
struct usb_port *port_dev = hub->ports[port1 - 1];
|
|
|
|
struct usb_device *udev = port_dev->child;
|
|
|
|
struct usb_device *hdev = hub->hdev;
|
|
|
|
u16 portstatus, portchange;
|
|
|
|
|
|
|
|
connect_change = test_bit(port1, hub->change_bits);
|
|
|
|
clear_bit(port1, hub->event_bits);
|
|
|
|
clear_bit(port1, hub->wakeup_bits);
|
|
|
|
|
|
|
|
if (hub_port_status(hub, port1, &portstatus, &portchange) < 0)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (portchange & USB_PORT_STAT_C_CONNECTION) {
|
|
|
|
usb_clear_port_feature(hdev, port1, USB_PORT_FEAT_C_CONNECTION);
|
|
|
|
connect_change = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (portchange & USB_PORT_STAT_C_ENABLE) {
|
|
|
|
if (!connect_change)
|
|
|
|
dev_dbg(&port_dev->dev, "enable change, status %08x\n",
|
|
|
|
portstatus);
|
|
|
|
usb_clear_port_feature(hdev, port1, USB_PORT_FEAT_C_ENABLE);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* EM interference sometimes causes badly shielded USB devices
|
|
|
|
* to be shutdown by the hub, this hack enables them again.
|
|
|
|
* Works at least with mouse driver.
|
|
|
|
*/
|
|
|
|
if (!(portstatus & USB_PORT_STAT_ENABLE)
|
|
|
|
&& !connect_change && udev) {
|
|
|
|
dev_err(&port_dev->dev, "disabled by hub (EMI?), re-enabling...\n");
|
|
|
|
connect_change = 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (portchange & USB_PORT_STAT_C_OVERCURRENT) {
|
|
|
|
u16 status = 0, unused;
|
|
|
|
|
|
|
|
dev_dbg(&port_dev->dev, "over-current change\n");
|
|
|
|
usb_clear_port_feature(hdev, port1,
|
|
|
|
USB_PORT_FEAT_C_OVER_CURRENT);
|
|
|
|
msleep(100); /* Cool down */
|
|
|
|
hub_power_on(hub, true);
|
|
|
|
hub_port_status(hub, port1, &status, &unused);
|
|
|
|
if (status & USB_PORT_STAT_OVERCURRENT)
|
|
|
|
dev_err(&port_dev->dev, "over-current condition\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
if (portchange & USB_PORT_STAT_C_RESET) {
|
|
|
|
dev_dbg(&port_dev->dev, "reset change\n");
|
|
|
|
usb_clear_port_feature(hdev, port1, USB_PORT_FEAT_C_RESET);
|
|
|
|
}
|
|
|
|
if ((portchange & USB_PORT_STAT_C_BH_RESET)
|
|
|
|
&& hub_is_superspeed(hdev)) {
|
|
|
|
dev_dbg(&port_dev->dev, "warm reset change\n");
|
|
|
|
usb_clear_port_feature(hdev, port1,
|
|
|
|
USB_PORT_FEAT_C_BH_PORT_RESET);
|
|
|
|
}
|
|
|
|
if (portchange & USB_PORT_STAT_C_LINK_STATE) {
|
|
|
|
dev_dbg(&port_dev->dev, "link state change\n");
|
|
|
|
usb_clear_port_feature(hdev, port1,
|
|
|
|
USB_PORT_FEAT_C_PORT_LINK_STATE);
|
|
|
|
}
|
|
|
|
if (portchange & USB_PORT_STAT_C_CONFIG_ERROR) {
|
|
|
|
dev_warn(&port_dev->dev, "config error\n");
|
|
|
|
usb_clear_port_feature(hdev, port1,
|
|
|
|
USB_PORT_FEAT_C_PORT_CONFIG_ERROR);
|
|
|
|
}
|
|
|
|
|
2014-05-21 09:09:20 +08:00
|
|
|
/* skip port actions that require the port to be powered on */
|
|
|
|
if (!pm_runtime_active(&port_dev->dev))
|
|
|
|
return;
|
2012-01-25 05:53:18 +08:00
|
|
|
|
2014-05-21 09:09:15 +08:00
|
|
|
if (hub_handle_remote_wakeup(hub, port1, portstatus, portchange))
|
|
|
|
connect_change = 1;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Warm reset a USB3 protocol port if it's in
|
|
|
|
* SS.Inactive state.
|
|
|
|
*/
|
2014-05-30 03:58:46 +08:00
|
|
|
if (hub_port_warm_reset_required(hub, port1, portstatus)) {
|
2014-05-21 09:09:15 +08:00
|
|
|
dev_dbg(&port_dev->dev, "do warm reset\n");
|
|
|
|
if (!udev || !(portstatus & USB_PORT_STAT_CONNECTION)
|
|
|
|
|| udev->state == USB_STATE_NOTATTACHED) {
|
|
|
|
if (hub_port_reset(hub, port1, NULL,
|
|
|
|
HUB_BH_RESET_TIME, true) < 0)
|
|
|
|
hub_port_disable(hub, port1, 1);
|
2015-01-26 23:30:39 +08:00
|
|
|
} else {
|
|
|
|
usb_unlock_port(port_dev);
|
|
|
|
usb_lock_device(udev);
|
|
|
|
usb_reset_device(udev);
|
|
|
|
usb_unlock_device(udev);
|
|
|
|
usb_lock_port(port_dev);
|
|
|
|
connect_change = 0;
|
|
|
|
}
|
2012-01-25 05:53:18 +08:00
|
|
|
}
|
2014-05-21 09:09:15 +08:00
|
|
|
|
|
|
|
if (connect_change)
|
|
|
|
hub_port_connect_change(hub, port1, portstatus, portchange);
|
2012-01-25 05:53:18 +08:00
|
|
|
}
|
|
|
|
|
2014-09-19 23:32:21 +08:00
|
|
|
static void hub_event(struct work_struct *work)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
struct usb_device *hdev;
|
|
|
|
struct usb_interface *intf;
|
|
|
|
struct usb_hub *hub;
|
|
|
|
struct device *hub_dev;
|
|
|
|
u16 hubstatus;
|
|
|
|
u16 hubchange;
|
|
|
|
int i, ret;
|
|
|
|
|
2014-09-19 23:32:21 +08:00
|
|
|
hub = container_of(work, struct usb_hub, events);
|
2014-09-19 23:32:20 +08:00
|
|
|
hdev = hub->hdev;
|
|
|
|
hub_dev = hub->intfdev;
|
|
|
|
intf = to_usb_interface(hub_dev);
|
2014-09-19 23:32:21 +08:00
|
|
|
|
2014-09-19 23:32:20 +08:00
|
|
|
dev_dbg(hub_dev, "state %d ports %d chg %04x evt %04x\n",
|
|
|
|
hdev->state, hdev->maxchild,
|
|
|
|
/* NOTE: expects max 15 ports... */
|
|
|
|
(u16) hub->change_bits[0],
|
|
|
|
(u16) hub->event_bits[0]);
|
|
|
|
|
|
|
|
/* Lock the device, then check to see if we were
|
|
|
|
* disconnected while waiting for the lock to succeed. */
|
|
|
|
usb_lock_device(hdev);
|
|
|
|
if (unlikely(hub->disconnected))
|
2014-09-19 23:32:21 +08:00
|
|
|
goto out_hdev_lock;
|
2014-09-19 23:32:20 +08:00
|
|
|
|
|
|
|
/* If the hub has died, clean up after it */
|
|
|
|
if (hdev->state == USB_STATE_NOTATTACHED) {
|
|
|
|
hub->error = -ENODEV;
|
|
|
|
hub_quiesce(hub, HUB_DISCONNECT);
|
2014-09-19 23:32:21 +08:00
|
|
|
goto out_hdev_lock;
|
2014-09-19 23:32:20 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Autoresume */
|
|
|
|
ret = usb_autopm_get_interface(intf);
|
|
|
|
if (ret) {
|
|
|
|
dev_dbg(hub_dev, "Can't autoresume: %d\n", ret);
|
2014-09-19 23:32:21 +08:00
|
|
|
goto out_hdev_lock;
|
2014-09-19 23:32:20 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2014-09-19 23:32:20 +08:00
|
|
|
/* If this is an inactive hub, do nothing */
|
|
|
|
if (hub->quiescing)
|
|
|
|
goto out_autopm;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2014-09-19 23:32:20 +08:00
|
|
|
if (hub->error) {
|
|
|
|
dev_dbg(hub_dev, "resetting for error %d\n", hub->error);
|
|
|
|
|
|
|
|
ret = usb_reset_device(hdev);
|
2006-11-10 03:44:33 +08:00
|
|
|
if (ret) {
|
2014-09-19 23:32:20 +08:00
|
|
|
dev_dbg(hub_dev, "error resetting hub: %d\n", ret);
|
|
|
|
goto out_autopm;
|
2006-11-10 03:44:33 +08:00
|
|
|
}
|
2006-07-02 10:11:02 +08:00
|
|
|
|
2014-09-19 23:32:20 +08:00
|
|
|
hub->nerrors = 0;
|
|
|
|
hub->error = 0;
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2014-09-19 23:32:20 +08:00
|
|
|
/* deal with port status changes */
|
|
|
|
for (i = 1; i <= hdev->maxchild; i++) {
|
|
|
|
struct usb_port *port_dev = hub->ports[i - 1];
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2014-09-19 23:32:20 +08:00
|
|
|
if (test_bit(i, hub->event_bits)
|
|
|
|
|| test_bit(i, hub->change_bits)
|
|
|
|
|| test_bit(i, hub->wakeup_bits)) {
|
|
|
|
/*
|
|
|
|
* The get_noresume and barrier ensure that if
|
|
|
|
* the port was in the process of resuming, we
|
|
|
|
* flush that work and keep the port active for
|
|
|
|
* the duration of the port_event(). However,
|
|
|
|
* if the port is runtime pm suspended
|
|
|
|
* (powered-off), we leave it in that state, run
|
|
|
|
* an abbreviated port_event(), and move on.
|
|
|
|
*/
|
|
|
|
pm_runtime_get_noresume(&port_dev->dev);
|
|
|
|
pm_runtime_barrier(&port_dev->dev);
|
|
|
|
usb_lock_port(port_dev);
|
|
|
|
port_event(hub, i);
|
|
|
|
usb_unlock_port(port_dev);
|
|
|
|
pm_runtime_put_sync(&port_dev->dev);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2014-09-19 23:32:20 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2014-09-19 23:32:20 +08:00
|
|
|
/* deal with hub status changes */
|
|
|
|
if (test_and_clear_bit(0, hub->event_bits) == 0)
|
|
|
|
; /* do nothing */
|
|
|
|
else if (hub_hub_status(hub, &hubstatus, &hubchange) < 0)
|
|
|
|
dev_err(hub_dev, "get_hub_status failed\n");
|
|
|
|
else {
|
|
|
|
if (hubchange & HUB_CHANGE_LOCAL_POWER) {
|
|
|
|
dev_dbg(hub_dev, "power change\n");
|
|
|
|
clear_hub_feature(hdev, C_HUB_LOCAL_POWER);
|
|
|
|
if (hubstatus & HUB_STATUS_LOCAL_POWER)
|
|
|
|
/* FIXME: Is this always true? */
|
|
|
|
hub->limited_power = 1;
|
|
|
|
else
|
|
|
|
hub->limited_power = 0;
|
2014-05-21 09:09:15 +08:00
|
|
|
}
|
2014-09-19 23:32:20 +08:00
|
|
|
if (hubchange & HUB_CHANGE_OVERCURRENT) {
|
|
|
|
u16 status = 0;
|
|
|
|
u16 unused;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2014-09-19 23:32:20 +08:00
|
|
|
dev_dbg(hub_dev, "over-current change\n");
|
|
|
|
clear_hub_feature(hdev, C_HUB_OVER_CURRENT);
|
|
|
|
msleep(500); /* Cool down */
|
|
|
|
hub_power_on(hub, true);
|
|
|
|
hub_hub_status(hub, &status, &unused);
|
|
|
|
if (status & HUB_STATUS_OVERCURRENT)
|
|
|
|
dev_err(hub_dev, "over-current condition\n");
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2014-09-19 23:32:20 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2014-09-19 23:32:20 +08:00
|
|
|
out_autopm:
|
|
|
|
/* Balance the usb_autopm_get_interface() above */
|
|
|
|
usb_autopm_put_interface_no_suspend(intf);
|
2014-09-19 23:32:21 +08:00
|
|
|
out_hdev_lock:
|
2014-09-19 23:32:20 +08:00
|
|
|
usb_unlock_device(hdev);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2014-09-19 23:32:21 +08:00
|
|
|
/* Balance the stuff in kick_hub_wq() and allow autosuspend */
|
|
|
|
usb_autopm_put_interface(intf);
|
|
|
|
kref_put(&hub->kref, hub_release);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2010-01-10 22:34:53 +08:00
|
|
|
static const struct usb_device_id hub_id_table[] = {
|
USB: check port changes before hub runtime suspend for some bug device
The hub status endpoint has a long 'bInterval', which is 255ms
for FS/LS device and 256ms for HS device according to USB 2.0 spec,
so the device connection change may be reported later more than 255ms
via status pipe.
The connection change in hub may have been happened already on the
downstream ports, but no status URB completes when it is killed
in hub_suspend(auto), so the connection change may be missed by some
buggy hub devices, which won't generate remote wakeup signal after
their remote wakeup is enabled and they are put into suspend state.
The problem can be observed at least on the below Genesys Logic, Inc.
hub devices:
0x05e3,0x0606
0x05e3,0x0608
In theory, there is no way to fix the problem completely, but we
can make it less likely to occur by this patch.
This patch introduces one quirk of HUB_QUIRK_CHECK_PORTS_AUTOSUSPEND
to check ports' change during hub_suspend(auto) for the buggy
devices. If ports' change is found, terminate the auto suspend and
return to working state.
So for the buggy hubs, if the connection change happend before
the ports' check, it can be handled correctly. If it happens between
the ports' check and enabling remote wakeup/entering suspend, it
will be missed. Considered the interval is quite short, it is very
less likely to happen during the window.
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-24 11:59:24 +08:00
|
|
|
{ .match_flags = USB_DEVICE_ID_MATCH_VENDOR
|
2013-10-11 05:41:27 +08:00
|
|
|
| USB_DEVICE_ID_MATCH_INT_CLASS,
|
USB: check port changes before hub runtime suspend for some bug device
The hub status endpoint has a long 'bInterval', which is 255ms
for FS/LS device and 256ms for HS device according to USB 2.0 spec,
so the device connection change may be reported later more than 255ms
via status pipe.
The connection change in hub may have been happened already on the
downstream ports, but no status URB completes when it is killed
in hub_suspend(auto), so the connection change may be missed by some
buggy hub devices, which won't generate remote wakeup signal after
their remote wakeup is enabled and they are put into suspend state.
The problem can be observed at least on the below Genesys Logic, Inc.
hub devices:
0x05e3,0x0606
0x05e3,0x0608
In theory, there is no way to fix the problem completely, but we
can make it less likely to occur by this patch.
This patch introduces one quirk of HUB_QUIRK_CHECK_PORTS_AUTOSUSPEND
to check ports' change during hub_suspend(auto) for the buggy
devices. If ports' change is found, terminate the auto suspend and
return to working state.
So for the buggy hubs, if the connection change happend before
the ports' check, it can be handled correctly. If it happens between
the ports' check and enabling remote wakeup/entering suspend, it
will be missed. Considered the interval is quite short, it is very
less likely to happen during the window.
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-24 11:59:24 +08:00
|
|
|
.idVendor = USB_VENDOR_GENESYS_LOGIC,
|
|
|
|
.bInterfaceClass = USB_CLASS_HUB,
|
|
|
|
.driver_info = HUB_QUIRK_CHECK_PORT_AUTOSUSPEND},
|
2005-04-17 06:20:36 +08:00
|
|
|
{ .match_flags = USB_DEVICE_ID_MATCH_DEV_CLASS,
|
|
|
|
.bDeviceClass = USB_CLASS_HUB},
|
|
|
|
{ .match_flags = USB_DEVICE_ID_MATCH_INT_CLASS,
|
|
|
|
.bInterfaceClass = USB_CLASS_HUB},
|
|
|
|
{ } /* Terminating entry */
|
|
|
|
};
|
|
|
|
|
2015-08-19 11:36:58 +08:00
|
|
|
MODULE_DEVICE_TABLE(usb, hub_id_table);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
static struct usb_driver hub_driver = {
|
|
|
|
.name = "hub",
|
|
|
|
.probe = hub_probe,
|
|
|
|
.disconnect = hub_disconnect,
|
|
|
|
.suspend = hub_suspend,
|
|
|
|
.resume = hub_resume,
|
2007-05-31 03:38:16 +08:00
|
|
|
.reset_resume = hub_reset_resume,
|
2006-06-02 01:37:24 +08:00
|
|
|
.pre_reset = hub_pre_reset,
|
|
|
|
.post_reset = hub_post_reset,
|
2010-06-02 05:04:41 +08:00
|
|
|
.unlocked_ioctl = hub_ioctl,
|
2005-04-17 06:20:36 +08:00
|
|
|
.id_table = hub_id_table,
|
2006-11-10 03:44:33 +08:00
|
|
|
.supports_autosuspend = 1,
|
2005-04-17 06:20:36 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
int usb_hub_init(void)
|
|
|
|
{
|
|
|
|
if (usb_register(&hub_driver) < 0) {
|
|
|
|
printk(KERN_ERR "%s: can't register hub driver\n",
|
|
|
|
usbcore_name);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2014-09-19 23:32:21 +08:00
|
|
|
/*
|
|
|
|
* The workqueue needs to be freezable to avoid interfering with
|
|
|
|
* USB-PERSIST port handover. Otherwise it might see that a full-speed
|
|
|
|
* device was gone before the EHCI controller had handed its port
|
|
|
|
* over to the companion full-speed controller.
|
|
|
|
*/
|
2014-09-19 23:32:24 +08:00
|
|
|
hub_wq = alloc_workqueue("usb_hub_wq", WQ_FREEZABLE, 0);
|
2014-09-19 23:32:21 +08:00
|
|
|
if (hub_wq)
|
2005-04-17 06:20:36 +08:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* Fall through if kernel_thread failed */
|
|
|
|
usb_deregister(&hub_driver);
|
2014-09-19 23:32:21 +08:00
|
|
|
pr_err("%s: can't allocate workqueue for usb hub\n", usbcore_name);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
void usb_hub_cleanup(void)
|
|
|
|
{
|
2014-09-19 23:32:21 +08:00
|
|
|
destroy_workqueue(hub_wq);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Hub resources are freed for us by usb_deregister. It calls
|
|
|
|
* usb_driver_purge on every device which in turn calls that
|
|
|
|
* devices disconnect function if it is using this driver.
|
|
|
|
* The hub_disconnect function takes care of releasing the
|
|
|
|
* individual hub resources. -greg
|
|
|
|
*/
|
|
|
|
usb_deregister(&hub_driver);
|
|
|
|
} /* usb_hub_cleanup() */
|
|
|
|
|
2008-03-04 04:16:04 +08:00
|
|
|
static int descriptors_changed(struct usb_device *udev,
|
2013-08-30 02:45:48 +08:00
|
|
|
struct usb_device_descriptor *old_device_descriptor,
|
|
|
|
struct usb_host_bos *old_bos)
|
2008-03-04 04:16:04 +08:00
|
|
|
{
|
|
|
|
int changed = 0;
|
|
|
|
unsigned index;
|
|
|
|
unsigned serial_len = 0;
|
|
|
|
unsigned len;
|
|
|
|
unsigned old_length;
|
|
|
|
int length;
|
|
|
|
char *buf;
|
|
|
|
|
|
|
|
if (memcmp(&udev->descriptor, old_device_descriptor,
|
|
|
|
sizeof(*old_device_descriptor)) != 0)
|
|
|
|
return 1;
|
|
|
|
|
2013-08-30 02:45:48 +08:00
|
|
|
if ((old_bos && !udev->bos) || (!old_bos && udev->bos))
|
|
|
|
return 1;
|
|
|
|
if (udev->bos) {
|
2013-08-31 09:40:49 +08:00
|
|
|
len = le16_to_cpu(udev->bos->desc->wTotalLength);
|
|
|
|
if (len != le16_to_cpu(old_bos->desc->wTotalLength))
|
2013-08-30 02:45:48 +08:00
|
|
|
return 1;
|
2013-08-31 09:40:49 +08:00
|
|
|
if (memcmp(udev->bos->desc, old_bos->desc, len))
|
2013-08-30 02:45:48 +08:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2008-03-04 04:16:04 +08:00
|
|
|
/* Since the idVendor, idProduct, and bcdDevice values in the
|
|
|
|
* device descriptor haven't changed, we will assume the
|
|
|
|
* Manufacturer and Product strings haven't changed either.
|
|
|
|
* But the SerialNumber string could be different (e.g., a
|
|
|
|
* different flash card of the same brand).
|
|
|
|
*/
|
|
|
|
if (udev->serial)
|
|
|
|
serial_len = strlen(udev->serial) + 1;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2008-03-04 04:16:04 +08:00
|
|
|
len = serial_len;
|
2005-04-17 06:20:36 +08:00
|
|
|
for (index = 0; index < udev->descriptor.bNumConfigurations; index++) {
|
2008-03-04 04:16:04 +08:00
|
|
|
old_length = le16_to_cpu(udev->config[index].desc.wTotalLength);
|
|
|
|
len = max(len, old_length);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2008-03-04 04:16:04 +08:00
|
|
|
|
2008-01-10 17:31:48 +08:00
|
|
|
buf = kmalloc(len, GFP_NOIO);
|
2005-04-17 06:20:36 +08:00
|
|
|
if (buf == NULL) {
|
|
|
|
dev_err(&udev->dev, "no mem to re-read configs after reset\n");
|
|
|
|
/* assume the worst */
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
for (index = 0; index < udev->descriptor.bNumConfigurations; index++) {
|
2008-03-04 04:16:04 +08:00
|
|
|
old_length = le16_to_cpu(udev->config[index].desc.wTotalLength);
|
2005-04-17 06:20:36 +08:00
|
|
|
length = usb_get_descriptor(udev, USB_DT_CONFIG, index, buf,
|
|
|
|
old_length);
|
2008-03-04 04:16:04 +08:00
|
|
|
if (length != old_length) {
|
2005-04-17 06:20:36 +08:00
|
|
|
dev_dbg(&udev->dev, "config index %d, error %d\n",
|
|
|
|
index, length);
|
2008-03-04 04:16:04 +08:00
|
|
|
changed = 1;
|
2005-04-17 06:20:36 +08:00
|
|
|
break;
|
|
|
|
}
|
2015-08-19 11:36:58 +08:00
|
|
|
if (memcmp(buf, udev->rawdescriptors[index], old_length)
|
2005-04-17 06:20:36 +08:00
|
|
|
!= 0) {
|
|
|
|
dev_dbg(&udev->dev, "config index %d changed (#%d)\n",
|
2008-03-04 04:16:04 +08:00
|
|
|
index,
|
|
|
|
((struct usb_config_descriptor *) buf)->
|
|
|
|
bConfigurationValue);
|
|
|
|
changed = 1;
|
2005-04-17 06:20:36 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2008-03-04 04:16:04 +08:00
|
|
|
|
|
|
|
if (!changed && serial_len) {
|
|
|
|
length = usb_string(udev, udev->descriptor.iSerialNumber,
|
|
|
|
buf, serial_len);
|
|
|
|
if (length + 1 != serial_len) {
|
|
|
|
dev_dbg(&udev->dev, "serial string error %d\n",
|
|
|
|
length);
|
|
|
|
changed = 1;
|
|
|
|
} else if (memcmp(buf, udev->serial, length) != 0) {
|
|
|
|
dev_dbg(&udev->dev, "serial string changed\n");
|
|
|
|
changed = 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
kfree(buf);
|
2008-03-04 04:16:04 +08:00
|
|
|
return changed;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2008-06-18 22:00:29 +08:00
|
|
|
* usb_reset_and_verify_device - perform a USB port reset to reinitialize a device
|
2005-04-17 06:20:36 +08:00
|
|
|
* @udev: device to reset (not in SUSPENDED or NOTATTACHED state)
|
|
|
|
*
|
2006-06-02 01:33:42 +08:00
|
|
|
* WARNING - don't use this routine to reset a composite device
|
|
|
|
* (one with multiple interfaces owned by separate drivers)!
|
2008-06-18 22:00:29 +08:00
|
|
|
* Use usb_reset_device() instead.
|
2005-04-17 06:20:36 +08:00
|
|
|
*
|
|
|
|
* Do a port reset, reassign the device's address, and establish its
|
|
|
|
* former operating configuration. If the reset fails, or the device's
|
|
|
|
* descriptors change from their values before the reset, or the original
|
|
|
|
* configuration and altsettings cannot be restored, a flag will be set
|
2014-09-19 23:32:23 +08:00
|
|
|
* telling hub_wq to pretend the device has been disconnected and then
|
2005-04-17 06:20:36 +08:00
|
|
|
* re-connected. All drivers will be unbound, and the device will be
|
|
|
|
* re-enumerated and probed all over again.
|
|
|
|
*
|
2013-08-03 02:10:04 +08:00
|
|
|
* Return: 0 if the reset succeeded, -ENODEV if the device has been
|
2005-04-17 06:20:36 +08:00
|
|
|
* flagged for logical disconnection, or some other negative error code
|
|
|
|
* if the reset wasn't even attempted.
|
|
|
|
*
|
2013-08-03 02:10:04 +08:00
|
|
|
* Note:
|
2014-05-21 09:09:26 +08:00
|
|
|
* The caller must own the device lock and the port lock, the latter is
|
|
|
|
* taken by usb_reset_device(). For example, it's safe to use
|
|
|
|
* usb_reset_device() from a driver probe() routine after downloading
|
|
|
|
* new firmware. For calls that might not occur during probe(), drivers
|
|
|
|
* should lock the device using usb_lock_device_for_reset().
|
2007-05-04 23:53:03 +08:00
|
|
|
*
|
|
|
|
* Locking exception: This routine may also be called from within an
|
|
|
|
* autoresume handler. Such usage won't conflict with other tasks
|
|
|
|
* holding the device lock because these tasks should always call
|
2014-05-21 09:09:26 +08:00
|
|
|
* usb_autopm_resume_device(), thereby preventing any unwanted
|
|
|
|
* autoresume. The autoresume handler is expected to have already
|
|
|
|
* acquired the port lock before calling this routine.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
2008-06-18 22:00:29 +08:00
|
|
|
static int usb_reset_and_verify_device(struct usb_device *udev)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
struct usb_device *parent_hdev = udev->parent;
|
|
|
|
struct usb_hub *parent_hub;
|
USB: Check bandwidth when switching alt settings.
Make the USB core check the bandwidth when switching from one
interface alternate setting to another. Also check the bandwidth
when resetting a configuration (so that alt setting 0 is used). If
this check fails, the device's state is unchanged. If the device
refuses the new alt setting, re-instate the old alt setting in the
host controller hardware.
If a USB device doesn't have an alternate interface setting 0, install
the first alt setting in its descriptors when a new configuration is
requested, or the device is reset.
Add a mutex per root hub to protect bandwidth operations:
adding/reseting/changing configurations, and changing alternate interface
settings. We want to ensure that the xHCI host controller and the USB
device are set up for the same configurations and alternate settings.
There are two (possibly three) steps to do this:
1. The host controller needs to check that bandwidth is available for a
different setting, by issuing and waiting for a configure endpoint
command.
2. Once that returns successfully, a control message is sent to the
device.
3. If that fails, the host controller must be notified through another
configure endpoint command.
The mutex is used to make these three operations seem atomic, to prevent
another driver from using more bandwidth for a different device while
we're in the middle of these operations.
While we're touching the bandwidth code, rename usb_hcd_check_bandwidth()
to usb_hcd_alloc_bandwidth(). This function does more than just check
that the bandwidth change won't exceed the bus bandwidth; it actually
changes the bandwidth configuration in the xHCI host controller.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-04 01:44:36 +08:00
|
|
|
struct usb_hcd *hcd = bus_to_hcd(udev->bus);
|
2005-04-17 06:20:36 +08:00
|
|
|
struct usb_device_descriptor descriptor = udev->descriptor;
|
2013-08-30 02:45:48 +08:00
|
|
|
struct usb_host_bos *bos;
|
2013-11-08 23:37:26 +08:00
|
|
|
int i, j, ret = 0;
|
2005-11-24 01:09:52 +08:00
|
|
|
int port1 = udev->portnum;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
if (udev->state == USB_STATE_NOTATTACHED ||
|
|
|
|
udev->state == USB_STATE_SUSPENDED) {
|
|
|
|
dev_dbg(&udev->dev, "device reset not allowed in state %d\n",
|
|
|
|
udev->state);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2014-05-21 09:09:26 +08:00
|
|
|
if (!parent_hdev)
|
2005-04-17 06:20:36 +08:00
|
|
|
return -EISDIR;
|
2014-05-21 09:09:26 +08:00
|
|
|
|
2013-01-23 04:26:30 +08:00
|
|
|
parent_hub = usb_hub_to_struct_hub(parent_hdev);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2013-09-30 22:26:29 +08:00
|
|
|
/* Disable USB2 hardware LPM.
|
|
|
|
* It will be re-enabled by the enumeration process.
|
|
|
|
*/
|
|
|
|
if (udev->usb2_hw_lpm_enabled == 1)
|
|
|
|
usb_set_usb2_hardware_lpm(udev, 0);
|
|
|
|
|
2012-06-26 03:08:08 +08:00
|
|
|
/* Disable LPM and LTM while we reset the device and reinstall the alt
|
|
|
|
* settings. Device-initiated LPM settings, and system exit latency
|
|
|
|
* settings are cleared when the device is reset, so we have to set
|
|
|
|
* them up again.
|
2012-07-04 13:49:04 +08:00
|
|
|
*/
|
|
|
|
ret = usb_unlocked_disable_lpm(udev);
|
|
|
|
if (ret) {
|
|
|
|
dev_err(&udev->dev, "%s Failed to disable LPM\n.", __func__);
|
2015-12-01 16:54:59 +08:00
|
|
|
goto re_enumerate_no_bos;
|
2012-07-04 13:49:04 +08:00
|
|
|
}
|
2012-06-26 03:08:08 +08:00
|
|
|
ret = usb_disable_ltm(udev);
|
|
|
|
if (ret) {
|
|
|
|
dev_err(&udev->dev, "%s Failed to disable LTM\n.",
|
|
|
|
__func__);
|
2015-12-01 16:54:59 +08:00
|
|
|
goto re_enumerate_no_bos;
|
2012-06-26 03:08:08 +08:00
|
|
|
}
|
2012-07-04 13:49:04 +08:00
|
|
|
|
2015-12-01 16:54:59 +08:00
|
|
|
bos = udev->bos;
|
2016-02-21 06:19:34 +08:00
|
|
|
udev->bos = NULL;
|
2015-12-01 16:54:59 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
for (i = 0; i < SET_CONFIG_TRIES; ++i) {
|
|
|
|
|
|
|
|
/* ep0 maxpacket size may change; let the HCD know about it.
|
|
|
|
* Other endpoints will be handled by re-enumeration. */
|
2008-04-09 04:24:46 +08:00
|
|
|
usb_ep0_reinit(udev);
|
2005-04-17 06:20:36 +08:00
|
|
|
ret = hub_port_init(parent_hub, udev, port1, i);
|
2007-05-04 23:55:54 +08:00
|
|
|
if (ret >= 0 || ret == -ENOTCONN || ret == -ENODEV)
|
2005-04-17 06:20:36 +08:00
|
|
|
break;
|
|
|
|
}
|
2006-08-12 04:52:39 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
if (ret < 0)
|
|
|
|
goto re_enumerate;
|
2013-10-11 05:41:27 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/* Device might have changed firmware (DFU or similar) */
|
2013-08-30 02:45:48 +08:00
|
|
|
if (descriptors_changed(udev, &descriptor, bos)) {
|
2005-04-17 06:20:36 +08:00
|
|
|
dev_info(&udev->dev, "device firmware changed\n");
|
|
|
|
udev->descriptor = descriptor; /* for disconnect() calls */
|
|
|
|
goto re_enumerate;
|
2013-10-11 05:41:27 +08:00
|
|
|
}
|
2009-02-26 23:21:02 +08:00
|
|
|
|
|
|
|
/* Restore the device's previous configuration */
|
2005-04-17 06:20:36 +08:00
|
|
|
if (!udev->actconfig)
|
|
|
|
goto done;
|
USB: Check bandwidth when switching alt settings.
Make the USB core check the bandwidth when switching from one
interface alternate setting to another. Also check the bandwidth
when resetting a configuration (so that alt setting 0 is used). If
this check fails, the device's state is unchanged. If the device
refuses the new alt setting, re-instate the old alt setting in the
host controller hardware.
If a USB device doesn't have an alternate interface setting 0, install
the first alt setting in its descriptors when a new configuration is
requested, or the device is reset.
Add a mutex per root hub to protect bandwidth operations:
adding/reseting/changing configurations, and changing alternate interface
settings. We want to ensure that the xHCI host controller and the USB
device are set up for the same configurations and alternate settings.
There are two (possibly three) steps to do this:
1. The host controller needs to check that bandwidth is available for a
different setting, by issuing and waiting for a configure endpoint
command.
2. Once that returns successfully, a control message is sent to the
device.
3. If that fails, the host controller must be notified through another
configure endpoint command.
The mutex is used to make these three operations seem atomic, to prevent
another driver from using more bandwidth for a different device while
we're in the middle of these operations.
While we're touching the bandwidth code, rename usb_hcd_check_bandwidth()
to usb_hcd_alloc_bandwidth(). This function does more than just check
that the bandwidth change won't exceed the bus bandwidth; it actually
changes the bandwidth configuration in the xHCI host controller.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-04 01:44:36 +08:00
|
|
|
|
2010-10-15 23:55:24 +08:00
|
|
|
mutex_lock(hcd->bandwidth_mutex);
|
USB: Check bandwidth when switching alt settings.
Make the USB core check the bandwidth when switching from one
interface alternate setting to another. Also check the bandwidth
when resetting a configuration (so that alt setting 0 is used). If
this check fails, the device's state is unchanged. If the device
refuses the new alt setting, re-instate the old alt setting in the
host controller hardware.
If a USB device doesn't have an alternate interface setting 0, install
the first alt setting in its descriptors when a new configuration is
requested, or the device is reset.
Add a mutex per root hub to protect bandwidth operations:
adding/reseting/changing configurations, and changing alternate interface
settings. We want to ensure that the xHCI host controller and the USB
device are set up for the same configurations and alternate settings.
There are two (possibly three) steps to do this:
1. The host controller needs to check that bandwidth is available for a
different setting, by issuing and waiting for a configure endpoint
command.
2. Once that returns successfully, a control message is sent to the
device.
3. If that fails, the host controller must be notified through another
configure endpoint command.
The mutex is used to make these three operations seem atomic, to prevent
another driver from using more bandwidth for a different device while
we're in the middle of these operations.
While we're touching the bandwidth code, rename usb_hcd_check_bandwidth()
to usb_hcd_alloc_bandwidth(). This function does more than just check
that the bandwidth change won't exceed the bus bandwidth; it actually
changes the bandwidth configuration in the xHCI host controller.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-04 01:44:36 +08:00
|
|
|
ret = usb_hcd_alloc_bandwidth(udev, udev->actconfig, NULL, NULL);
|
|
|
|
if (ret < 0) {
|
|
|
|
dev_warn(&udev->dev,
|
|
|
|
"Busted HC? Not enough HCD resources for "
|
|
|
|
"old configuration.\n");
|
2010-10-15 23:55:24 +08:00
|
|
|
mutex_unlock(hcd->bandwidth_mutex);
|
USB: Check bandwidth when switching alt settings.
Make the USB core check the bandwidth when switching from one
interface alternate setting to another. Also check the bandwidth
when resetting a configuration (so that alt setting 0 is used). If
this check fails, the device's state is unchanged. If the device
refuses the new alt setting, re-instate the old alt setting in the
host controller hardware.
If a USB device doesn't have an alternate interface setting 0, install
the first alt setting in its descriptors when a new configuration is
requested, or the device is reset.
Add a mutex per root hub to protect bandwidth operations:
adding/reseting/changing configurations, and changing alternate interface
settings. We want to ensure that the xHCI host controller and the USB
device are set up for the same configurations and alternate settings.
There are two (possibly three) steps to do this:
1. The host controller needs to check that bandwidth is available for a
different setting, by issuing and waiting for a configure endpoint
command.
2. Once that returns successfully, a control message is sent to the
device.
3. If that fails, the host controller must be notified through another
configure endpoint command.
The mutex is used to make these three operations seem atomic, to prevent
another driver from using more bandwidth for a different device while
we're in the middle of these operations.
While we're touching the bandwidth code, rename usb_hcd_check_bandwidth()
to usb_hcd_alloc_bandwidth(). This function does more than just check
that the bandwidth change won't exceed the bus bandwidth; it actually
changes the bandwidth configuration in the xHCI host controller.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-04 01:44:36 +08:00
|
|
|
goto re_enumerate;
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
ret = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
|
|
|
|
USB_REQ_SET_CONFIGURATION, 0,
|
|
|
|
udev->actconfig->desc.bConfigurationValue, 0,
|
|
|
|
NULL, 0, USB_CTRL_SET_TIMEOUT);
|
|
|
|
if (ret < 0) {
|
|
|
|
dev_err(&udev->dev,
|
|
|
|
"can't restore configuration #%d (error=%d)\n",
|
|
|
|
udev->actconfig->desc.bConfigurationValue, ret);
|
2010-10-15 23:55:24 +08:00
|
|
|
mutex_unlock(hcd->bandwidth_mutex);
|
2005-04-17 06:20:36 +08:00
|
|
|
goto re_enumerate;
|
2013-10-11 05:41:27 +08:00
|
|
|
}
|
2010-10-15 23:55:24 +08:00
|
|
|
mutex_unlock(hcd->bandwidth_mutex);
|
2005-04-17 06:20:36 +08:00
|
|
|
usb_set_device_state(udev, USB_STATE_CONFIGURED);
|
|
|
|
|
2009-02-26 23:21:02 +08:00
|
|
|
/* Put interfaces back into the same altsettings as before.
|
|
|
|
* Don't bother to send the Set-Interface request for interfaces
|
|
|
|
* that were already in altsetting 0; besides being unnecessary,
|
|
|
|
* many devices can't handle it. Instead just reset the host-side
|
|
|
|
* endpoint state.
|
|
|
|
*/
|
2005-04-17 06:20:36 +08:00
|
|
|
for (i = 0; i < udev->actconfig->desc.bNumInterfaces; i++) {
|
USB: Check bandwidth when switching alt settings.
Make the USB core check the bandwidth when switching from one
interface alternate setting to another. Also check the bandwidth
when resetting a configuration (so that alt setting 0 is used). If
this check fails, the device's state is unchanged. If the device
refuses the new alt setting, re-instate the old alt setting in the
host controller hardware.
If a USB device doesn't have an alternate interface setting 0, install
the first alt setting in its descriptors when a new configuration is
requested, or the device is reset.
Add a mutex per root hub to protect bandwidth operations:
adding/reseting/changing configurations, and changing alternate interface
settings. We want to ensure that the xHCI host controller and the USB
device are set up for the same configurations and alternate settings.
There are two (possibly three) steps to do this:
1. The host controller needs to check that bandwidth is available for a
different setting, by issuing and waiting for a configure endpoint
command.
2. Once that returns successfully, a control message is sent to the
device.
3. If that fails, the host controller must be notified through another
configure endpoint command.
The mutex is used to make these three operations seem atomic, to prevent
another driver from using more bandwidth for a different device while
we're in the middle of these operations.
While we're touching the bandwidth code, rename usb_hcd_check_bandwidth()
to usb_hcd_alloc_bandwidth(). This function does more than just check
that the bandwidth change won't exceed the bus bandwidth; it actually
changes the bandwidth configuration in the xHCI host controller.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-04 01:44:36 +08:00
|
|
|
struct usb_host_config *config = udev->actconfig;
|
|
|
|
struct usb_interface *intf = config->interface[i];
|
2005-04-17 06:20:36 +08:00
|
|
|
struct usb_interface_descriptor *desc;
|
|
|
|
|
|
|
|
desc = &intf->cur_altsetting->desc;
|
2009-02-26 23:21:02 +08:00
|
|
|
if (desc->bAlternateSetting == 0) {
|
|
|
|
usb_disable_interface(udev, intf, true);
|
|
|
|
usb_enable_interface(udev, intf, true);
|
|
|
|
ret = 0;
|
|
|
|
} else {
|
USB: Fix duplicate sysfs problem after device reset.
Borislav Petkov reports issues with duplicate sysfs endpoint files after a
resume from a hibernate. It turns out that the code to support alternate
settings under xHCI has issues when a device with a non-default alternate
setting is reset during the hibernate:
[ 427.681810] Restarting tasks ...
[ 427.681995] hub 1-0:1.0: state 7 ports 6 chg 0004 evt 0000
[ 427.682019] usb usb3: usb resume
[ 427.682030] ohci_hcd 0000:00:12.0: wakeup root hub
[ 427.682191] hub 1-0:1.0: port 2, status 0501, change 0000, 480 Mb/s
[ 427.682205] usb 1-2: usb wakeup-resume
[ 427.682226] usb 1-2: finish reset-resume
[ 427.682886] done.
[ 427.734658] ehci_hcd 0000:00:12.2: port 2 high speed
[ 427.734663] ehci_hcd 0000:00:12.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
[ 427.746682] hub 3-0:1.0: hub_reset_resume
[ 427.746693] hub 3-0:1.0: trying to enable port power on non-switchable hub
[ 427.786715] usb 1-2: reset high speed USB device using ehci_hcd and address 2
[ 427.839653] ehci_hcd 0000:00:12.2: port 2 high speed
[ 427.839666] ehci_hcd 0000:00:12.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
[ 427.847717] ohci_hcd 0000:00:12.0: GetStatus roothub.portstatus [1] = 0x00010100 CSC PPS
[ 427.915497] hub 1-2:1.0: remove_intf_ep_devs: if: ffff88022f9e8800 ->ep_devs_created: 1
[ 427.915774] hub 1-2:1.0: remove_intf_ep_devs: bNumEndpoints: 1
[ 427.915934] hub 1-2:1.0: if: ffff88022f9e8800: endpoint devs removed.
[ 427.916158] hub 1-2:1.0: create_intf_ep_devs: if: ffff88022f9e8800 ->ep_devs_created: 0, ->unregistering: 0
[ 427.916434] hub 1-2:1.0: create_intf_ep_devs: bNumEndpoints: 1
[ 427.916609] ep_81: create, parent hub
[ 427.916632] ------------[ cut here ]------------
[ 427.916644] WARNING: at fs/sysfs/dir.c:477 sysfs_add_one+0x82/0x96()
[ 427.916649] Hardware name: System Product Name
[ 427.916653] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:12.2/usb1/1-2/1-2:1.0/ep_81'
[ 427.916658] Modules linked in: binfmt_misc kvm_amd kvm powernow_k8 cpufreq_ondemand cpufreq_powersave cpufreq_userspace freq_table cpufreq_conservative ipv6 vfat fat
+8250_pnp 8250 pcspkr ohci_hcd serial_core k10temp edac_core
[ 427.916694] Pid: 278, comm: khubd Not tainted 2.6.33-rc2-00187-g08d869a-dirty #13
[ 427.916699] Call Trace:
The problem is caused by a mismatch between the USB core's view of the
device state and the USB device and xHCI host's view of the device state.
After the device reset and re-configuration, the device and the xHCI host
think they are using alternate setting 0 of all interfaces. However, the
USB core keeps track of the old state, which may include non-zero
alternate settings. It uses intf->cur_altsetting to keep the endpoint
sysfs files for the old state across the reset.
The bandwidth allocation functions need to know what the xHCI host thinks
the current alternate settings are, so original patch set
intf->cur_altsetting to the alternate setting 0. This caused duplicate
endpoint files to be created.
The solution is to not set intf->cur_altsetting before calling
usb_set_interface() in usb_reset_and_verify_device(). Instead, we add a
new flag to struct usb_interface to tell usb_hcd_alloc_bandwidth() to use
alternate setting 0 as the currently installed alternate setting.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Borislav Petkov <petkovbb@googlemail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-07 02:16:51 +08:00
|
|
|
/* Let the bandwidth allocation function know that this
|
|
|
|
* device has been reset, and it will have to use
|
|
|
|
* alternate setting 0 as the current alternate setting.
|
USB: Check bandwidth when switching alt settings.
Make the USB core check the bandwidth when switching from one
interface alternate setting to another. Also check the bandwidth
when resetting a configuration (so that alt setting 0 is used). If
this check fails, the device's state is unchanged. If the device
refuses the new alt setting, re-instate the old alt setting in the
host controller hardware.
If a USB device doesn't have an alternate interface setting 0, install
the first alt setting in its descriptors when a new configuration is
requested, or the device is reset.
Add a mutex per root hub to protect bandwidth operations:
adding/reseting/changing configurations, and changing alternate interface
settings. We want to ensure that the xHCI host controller and the USB
device are set up for the same configurations and alternate settings.
There are two (possibly three) steps to do this:
1. The host controller needs to check that bandwidth is available for a
different setting, by issuing and waiting for a configure endpoint
command.
2. Once that returns successfully, a control message is sent to the
device.
3. If that fails, the host controller must be notified through another
configure endpoint command.
The mutex is used to make these three operations seem atomic, to prevent
another driver from using more bandwidth for a different device while
we're in the middle of these operations.
While we're touching the bandwidth code, rename usb_hcd_check_bandwidth()
to usb_hcd_alloc_bandwidth(). This function does more than just check
that the bandwidth change won't exceed the bus bandwidth; it actually
changes the bandwidth configuration in the xHCI host controller.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-04 01:44:36 +08:00
|
|
|
*/
|
USB: Fix duplicate sysfs problem after device reset.
Borislav Petkov reports issues with duplicate sysfs endpoint files after a
resume from a hibernate. It turns out that the code to support alternate
settings under xHCI has issues when a device with a non-default alternate
setting is reset during the hibernate:
[ 427.681810] Restarting tasks ...
[ 427.681995] hub 1-0:1.0: state 7 ports 6 chg 0004 evt 0000
[ 427.682019] usb usb3: usb resume
[ 427.682030] ohci_hcd 0000:00:12.0: wakeup root hub
[ 427.682191] hub 1-0:1.0: port 2, status 0501, change 0000, 480 Mb/s
[ 427.682205] usb 1-2: usb wakeup-resume
[ 427.682226] usb 1-2: finish reset-resume
[ 427.682886] done.
[ 427.734658] ehci_hcd 0000:00:12.2: port 2 high speed
[ 427.734663] ehci_hcd 0000:00:12.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
[ 427.746682] hub 3-0:1.0: hub_reset_resume
[ 427.746693] hub 3-0:1.0: trying to enable port power on non-switchable hub
[ 427.786715] usb 1-2: reset high speed USB device using ehci_hcd and address 2
[ 427.839653] ehci_hcd 0000:00:12.2: port 2 high speed
[ 427.839666] ehci_hcd 0000:00:12.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
[ 427.847717] ohci_hcd 0000:00:12.0: GetStatus roothub.portstatus [1] = 0x00010100 CSC PPS
[ 427.915497] hub 1-2:1.0: remove_intf_ep_devs: if: ffff88022f9e8800 ->ep_devs_created: 1
[ 427.915774] hub 1-2:1.0: remove_intf_ep_devs: bNumEndpoints: 1
[ 427.915934] hub 1-2:1.0: if: ffff88022f9e8800: endpoint devs removed.
[ 427.916158] hub 1-2:1.0: create_intf_ep_devs: if: ffff88022f9e8800 ->ep_devs_created: 0, ->unregistering: 0
[ 427.916434] hub 1-2:1.0: create_intf_ep_devs: bNumEndpoints: 1
[ 427.916609] ep_81: create, parent hub
[ 427.916632] ------------[ cut here ]------------
[ 427.916644] WARNING: at fs/sysfs/dir.c:477 sysfs_add_one+0x82/0x96()
[ 427.916649] Hardware name: System Product Name
[ 427.916653] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:12.2/usb1/1-2/1-2:1.0/ep_81'
[ 427.916658] Modules linked in: binfmt_misc kvm_amd kvm powernow_k8 cpufreq_ondemand cpufreq_powersave cpufreq_userspace freq_table cpufreq_conservative ipv6 vfat fat
+8250_pnp 8250 pcspkr ohci_hcd serial_core k10temp edac_core
[ 427.916694] Pid: 278, comm: khubd Not tainted 2.6.33-rc2-00187-g08d869a-dirty #13
[ 427.916699] Call Trace:
The problem is caused by a mismatch between the USB core's view of the
device state and the USB device and xHCI host's view of the device state.
After the device reset and re-configuration, the device and the xHCI host
think they are using alternate setting 0 of all interfaces. However, the
USB core keeps track of the old state, which may include non-zero
alternate settings. It uses intf->cur_altsetting to keep the endpoint
sysfs files for the old state across the reset.
The bandwidth allocation functions need to know what the xHCI host thinks
the current alternate settings are, so original patch set
intf->cur_altsetting to the alternate setting 0. This caused duplicate
endpoint files to be created.
The solution is to not set intf->cur_altsetting before calling
usb_set_interface() in usb_reset_and_verify_device(). Instead, we add a
new flag to struct usb_interface to tell usb_hcd_alloc_bandwidth() to use
alternate setting 0 as the currently installed alternate setting.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Borislav Petkov <petkovbb@googlemail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-07 02:16:51 +08:00
|
|
|
intf->resetting_device = 1;
|
2009-02-26 23:21:02 +08:00
|
|
|
ret = usb_set_interface(udev, desc->bInterfaceNumber,
|
|
|
|
desc->bAlternateSetting);
|
USB: Fix duplicate sysfs problem after device reset.
Borislav Petkov reports issues with duplicate sysfs endpoint files after a
resume from a hibernate. It turns out that the code to support alternate
settings under xHCI has issues when a device with a non-default alternate
setting is reset during the hibernate:
[ 427.681810] Restarting tasks ...
[ 427.681995] hub 1-0:1.0: state 7 ports 6 chg 0004 evt 0000
[ 427.682019] usb usb3: usb resume
[ 427.682030] ohci_hcd 0000:00:12.0: wakeup root hub
[ 427.682191] hub 1-0:1.0: port 2, status 0501, change 0000, 480 Mb/s
[ 427.682205] usb 1-2: usb wakeup-resume
[ 427.682226] usb 1-2: finish reset-resume
[ 427.682886] done.
[ 427.734658] ehci_hcd 0000:00:12.2: port 2 high speed
[ 427.734663] ehci_hcd 0000:00:12.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
[ 427.746682] hub 3-0:1.0: hub_reset_resume
[ 427.746693] hub 3-0:1.0: trying to enable port power on non-switchable hub
[ 427.786715] usb 1-2: reset high speed USB device using ehci_hcd and address 2
[ 427.839653] ehci_hcd 0000:00:12.2: port 2 high speed
[ 427.839666] ehci_hcd 0000:00:12.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
[ 427.847717] ohci_hcd 0000:00:12.0: GetStatus roothub.portstatus [1] = 0x00010100 CSC PPS
[ 427.915497] hub 1-2:1.0: remove_intf_ep_devs: if: ffff88022f9e8800 ->ep_devs_created: 1
[ 427.915774] hub 1-2:1.0: remove_intf_ep_devs: bNumEndpoints: 1
[ 427.915934] hub 1-2:1.0: if: ffff88022f9e8800: endpoint devs removed.
[ 427.916158] hub 1-2:1.0: create_intf_ep_devs: if: ffff88022f9e8800 ->ep_devs_created: 0, ->unregistering: 0
[ 427.916434] hub 1-2:1.0: create_intf_ep_devs: bNumEndpoints: 1
[ 427.916609] ep_81: create, parent hub
[ 427.916632] ------------[ cut here ]------------
[ 427.916644] WARNING: at fs/sysfs/dir.c:477 sysfs_add_one+0x82/0x96()
[ 427.916649] Hardware name: System Product Name
[ 427.916653] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:12.2/usb1/1-2/1-2:1.0/ep_81'
[ 427.916658] Modules linked in: binfmt_misc kvm_amd kvm powernow_k8 cpufreq_ondemand cpufreq_powersave cpufreq_userspace freq_table cpufreq_conservative ipv6 vfat fat
+8250_pnp 8250 pcspkr ohci_hcd serial_core k10temp edac_core
[ 427.916694] Pid: 278, comm: khubd Not tainted 2.6.33-rc2-00187-g08d869a-dirty #13
[ 427.916699] Call Trace:
The problem is caused by a mismatch between the USB core's view of the
device state and the USB device and xHCI host's view of the device state.
After the device reset and re-configuration, the device and the xHCI host
think they are using alternate setting 0 of all interfaces. However, the
USB core keeps track of the old state, which may include non-zero
alternate settings. It uses intf->cur_altsetting to keep the endpoint
sysfs files for the old state across the reset.
The bandwidth allocation functions need to know what the xHCI host thinks
the current alternate settings are, so original patch set
intf->cur_altsetting to the alternate setting 0. This caused duplicate
endpoint files to be created.
The solution is to not set intf->cur_altsetting before calling
usb_set_interface() in usb_reset_and_verify_device(). Instead, we add a
new flag to struct usb_interface to tell usb_hcd_alloc_bandwidth() to use
alternate setting 0 as the currently installed alternate setting.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Borislav Petkov <petkovbb@googlemail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-07 02:16:51 +08:00
|
|
|
intf->resetting_device = 0;
|
2009-02-26 23:21:02 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
if (ret < 0) {
|
|
|
|
dev_err(&udev->dev, "failed to restore interface %d "
|
|
|
|
"altsetting %d (error=%d)\n",
|
|
|
|
desc->bInterfaceNumber,
|
|
|
|
desc->bAlternateSetting,
|
|
|
|
ret);
|
|
|
|
goto re_enumerate;
|
|
|
|
}
|
2013-11-08 23:37:26 +08:00
|
|
|
/* Resetting also frees any allocated streams */
|
|
|
|
for (j = 0; j < intf->cur_altsetting->desc.bNumEndpoints; j++)
|
|
|
|
intf->cur_altsetting->endpoint[j].streams = 0;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
done:
|
2012-06-26 03:08:08 +08:00
|
|
|
/* Now that the alt settings are re-installed, enable LTM and LPM. */
|
usb: Don't enable USB 2.0 Link PM by default.
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 a558ccdcc71c7770c5e80c926a31cfe8a3892a09 "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
2013-09-30 22:26:28 +08:00
|
|
|
usb_set_usb2_hardware_lpm(udev, 1);
|
USB: Disable USB 3.0 LPM in critical sections.
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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-05-03 05:25:52 +08:00
|
|
|
usb_unlocked_enable_lpm(udev);
|
2012-06-26 03:08:08 +08:00
|
|
|
usb_enable_ltm(udev);
|
2016-02-21 06:19:34 +08:00
|
|
|
usb_release_bos_descriptor(udev);
|
|
|
|
udev->bos = bos;
|
2005-04-17 06:20:36 +08:00
|
|
|
return 0;
|
2013-10-11 05:41:27 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
re_enumerate:
|
2013-08-30 02:45:48 +08:00
|
|
|
usb_release_bos_descriptor(udev);
|
|
|
|
udev->bos = bos;
|
2015-12-01 16:54:59 +08:00
|
|
|
re_enumerate_no_bos:
|
|
|
|
/* LPM state doesn't matter when we're about to destroy the device. */
|
|
|
|
hub_port_logical_disconnect(parent_hub, port1);
|
2005-04-17 06:20:36 +08:00
|
|
|
return -ENODEV;
|
|
|
|
}
|
2006-06-02 01:33:42 +08:00
|
|
|
|
|
|
|
/**
|
2008-06-18 22:00:29 +08:00
|
|
|
* usb_reset_device - warn interface drivers and perform a USB port reset
|
2006-06-02 01:33:42 +08:00
|
|
|
* @udev: device to reset (not in SUSPENDED or NOTATTACHED state)
|
|
|
|
*
|
|
|
|
* Warns all drivers bound to registered interfaces (using their pre_reset
|
|
|
|
* method), performs the port reset, and then lets the drivers know that
|
|
|
|
* the reset is over (using their post_reset method).
|
|
|
|
*
|
2013-08-03 02:10:04 +08:00
|
|
|
* Return: The same as for usb_reset_and_verify_device().
|
2006-06-02 01:33:42 +08:00
|
|
|
*
|
2013-08-03 02:10:04 +08:00
|
|
|
* Note:
|
2006-06-02 01:33:42 +08:00
|
|
|
* The caller must own the device lock. For example, it's safe to use
|
|
|
|
* this from a driver probe() routine after downloading new firmware.
|
|
|
|
* For calls that might not occur during probe(), drivers should lock
|
|
|
|
* the device using usb_lock_device_for_reset().
|
2008-06-24 04:00:40 +08:00
|
|
|
*
|
|
|
|
* If an interface is currently being probed or disconnected, we assume
|
|
|
|
* its driver knows how to handle resets. For all other interfaces,
|
|
|
|
* if the driver doesn't have pre_reset and post_reset methods then
|
|
|
|
* we attempt to unbind it and rebind afterward.
|
2006-06-02 01:33:42 +08:00
|
|
|
*/
|
2008-06-18 22:00:29 +08:00
|
|
|
int usb_reset_device(struct usb_device *udev)
|
2006-06-02 01:33:42 +08:00
|
|
|
{
|
|
|
|
int ret;
|
2007-12-04 04:44:29 +08:00
|
|
|
int i;
|
2013-02-23 08:34:22 +08:00
|
|
|
unsigned int noio_flag;
|
2014-05-21 09:09:26 +08:00
|
|
|
struct usb_port *port_dev;
|
2006-06-02 01:33:42 +08:00
|
|
|
struct usb_host_config *config = udev->actconfig;
|
2014-05-21 09:09:26 +08:00
|
|
|
struct usb_hub *hub = usb_hub_to_struct_hub(udev->parent);
|
2006-06-02 01:33:42 +08:00
|
|
|
|
|
|
|
if (udev->state == USB_STATE_NOTATTACHED ||
|
|
|
|
udev->state == USB_STATE_SUSPENDED) {
|
|
|
|
dev_dbg(&udev->dev, "device reset not allowed in state %d\n",
|
|
|
|
udev->state);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2014-05-21 09:09:26 +08:00
|
|
|
if (!udev->parent) {
|
|
|
|
/* this requires hcd-specific logic; see ohci_restart() */
|
|
|
|
dev_dbg(&udev->dev, "%s for root hub!\n", __func__);
|
|
|
|
return -EISDIR;
|
|
|
|
}
|
|
|
|
|
|
|
|
port_dev = hub->ports[udev->portnum - 1];
|
|
|
|
|
2013-02-23 08:34:22 +08:00
|
|
|
/*
|
|
|
|
* Don't allocate memory with GFP_KERNEL in current
|
|
|
|
* context to avoid possible deadlock if usb mass
|
|
|
|
* storage interface or usbnet interface(iSCSI case)
|
|
|
|
* is included in current configuration. The easist
|
|
|
|
* approach is to do it for every device reset,
|
|
|
|
* because the device 'memalloc_noio' flag may have
|
|
|
|
* not been set before reseting the usb device.
|
|
|
|
*/
|
|
|
|
noio_flag = memalloc_noio_save();
|
|
|
|
|
2006-08-31 03:47:02 +08:00
|
|
|
/* Prevent autosuspend during the reset */
|
2006-11-21 00:38:46 +08:00
|
|
|
usb_autoresume_device(udev);
|
2006-08-31 03:47:02 +08:00
|
|
|
|
2006-06-02 01:33:42 +08:00
|
|
|
if (config) {
|
|
|
|
for (i = 0; i < config->desc.bNumInterfaces; ++i) {
|
2007-12-04 04:44:29 +08:00
|
|
|
struct usb_interface *cintf = config->interface[i];
|
|
|
|
struct usb_driver *drv;
|
2008-06-24 04:00:40 +08:00
|
|
|
int unbind = 0;
|
2007-12-04 04:44:29 +08:00
|
|
|
|
|
|
|
if (cintf->dev.driver) {
|
2006-06-02 01:33:42 +08:00
|
|
|
drv = to_usb_driver(cintf->dev.driver);
|
2008-06-24 04:00:40 +08:00
|
|
|
if (drv->pre_reset && drv->post_reset)
|
|
|
|
unbind = (drv->pre_reset)(cintf);
|
|
|
|
else if (cintf->condition ==
|
|
|
|
USB_INTERFACE_BOUND)
|
|
|
|
unbind = 1;
|
|
|
|
if (unbind)
|
|
|
|
usb_forced_unbind_intf(cintf);
|
2006-06-02 01:33:42 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-05-21 09:09:26 +08:00
|
|
|
usb_lock_port(port_dev);
|
2008-06-18 22:00:29 +08:00
|
|
|
ret = usb_reset_and_verify_device(udev);
|
2014-05-21 09:09:26 +08:00
|
|
|
usb_unlock_port(port_dev);
|
2006-06-02 01:33:42 +08:00
|
|
|
|
|
|
|
if (config) {
|
|
|
|
for (i = config->desc.bNumInterfaces - 1; i >= 0; --i) {
|
2007-12-04 04:44:29 +08:00
|
|
|
struct usb_interface *cintf = config->interface[i];
|
|
|
|
struct usb_driver *drv;
|
2008-06-24 04:00:40 +08:00
|
|
|
int rebind = cintf->needs_binding;
|
2007-12-04 04:44:29 +08:00
|
|
|
|
2008-06-24 04:00:40 +08:00
|
|
|
if (!rebind && cintf->dev.driver) {
|
2006-06-02 01:33:42 +08:00
|
|
|
drv = to_usb_driver(cintf->dev.driver);
|
|
|
|
if (drv->post_reset)
|
2008-06-24 04:00:40 +08:00
|
|
|
rebind = (drv->post_reset)(cintf);
|
|
|
|
else if (cintf->condition ==
|
|
|
|
USB_INTERFACE_BOUND)
|
|
|
|
rebind = 1;
|
2014-03-12 23:30:38 +08:00
|
|
|
if (rebind)
|
|
|
|
cintf->needs_binding = 1;
|
2006-06-02 01:33:42 +08:00
|
|
|
}
|
|
|
|
}
|
2014-03-12 23:30:38 +08:00
|
|
|
usb_unbind_and_rebind_marked_interfaces(udev);
|
2006-06-02 01:33:42 +08:00
|
|
|
}
|
|
|
|
|
2006-11-21 00:38:46 +08:00
|
|
|
usb_autosuspend_device(udev);
|
2013-02-23 08:34:22 +08:00
|
|
|
memalloc_noio_restore(noio_flag);
|
2006-06-02 01:33:42 +08:00
|
|
|
return ret;
|
|
|
|
}
|
2008-06-18 22:00:29 +08:00
|
|
|
EXPORT_SYMBOL_GPL(usb_reset_device);
|
2008-11-14 02:31:35 +08:00
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* usb_queue_reset_device - Reset a USB device from an atomic context
|
|
|
|
* @iface: USB interface belonging to the device to reset
|
|
|
|
*
|
|
|
|
* This function can be used to reset a USB device from an atomic
|
|
|
|
* context, where usb_reset_device() won't work (as it blocks).
|
|
|
|
*
|
|
|
|
* Doing a reset via this method is functionally equivalent to calling
|
|
|
|
* usb_reset_device(), except for the fact that it is delayed to a
|
|
|
|
* workqueue. This means that any drivers bound to other interfaces
|
|
|
|
* might be unbound, as well as users from usbfs in user space.
|
|
|
|
*
|
|
|
|
* Corner cases:
|
|
|
|
*
|
|
|
|
* - Scheduling two resets at the same time from two different drivers
|
|
|
|
* attached to two different interfaces of the same device is
|
|
|
|
* possible; depending on how the driver attached to each interface
|
|
|
|
* handles ->pre_reset(), the second reset might happen or not.
|
|
|
|
*
|
2015-01-22 03:02:43 +08:00
|
|
|
* - If the reset is delayed so long that the interface is unbound from
|
|
|
|
* its driver, the reset will be skipped.
|
2008-11-14 02:31:35 +08:00
|
|
|
*
|
2015-01-22 03:02:43 +08:00
|
|
|
* - This function can be called during .probe(). It can also be called
|
|
|
|
* during .disconnect(), but doing so is pointless because the reset
|
|
|
|
* will not occur. If you really want to reset the device during
|
|
|
|
* .disconnect(), call usb_reset_device() directly -- but watch out
|
|
|
|
* for nested unbinding issues!
|
2008-11-14 02:31:35 +08:00
|
|
|
*/
|
|
|
|
void usb_queue_reset_device(struct usb_interface *iface)
|
|
|
|
{
|
2015-01-22 03:02:43 +08:00
|
|
|
if (schedule_work(&iface->reset_ws))
|
|
|
|
usb_get_intf(iface);
|
2008-11-14 02:31:35 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(usb_queue_reset_device);
|
2012-09-05 13:44:32 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* usb_hub_find_child - Get the pointer of child device
|
|
|
|
* attached to the port which is specified by @port1.
|
|
|
|
* @hdev: USB device belonging to the usb hub
|
|
|
|
* @port1: port num to indicate which port the child device
|
|
|
|
* is attached to.
|
|
|
|
*
|
|
|
|
* USB drivers call this function to get hub's child device
|
|
|
|
* pointer.
|
|
|
|
*
|
2013-08-03 02:10:04 +08:00
|
|
|
* Return: %NULL if input param is invalid and
|
2012-09-05 13:44:32 +08:00
|
|
|
* child's usb_device pointer if non-NULL.
|
|
|
|
*/
|
|
|
|
struct usb_device *usb_hub_find_child(struct usb_device *hdev,
|
|
|
|
int port1)
|
|
|
|
{
|
2013-01-23 04:26:30 +08:00
|
|
|
struct usb_hub *hub = usb_hub_to_struct_hub(hdev);
|
2012-09-05 13:44:32 +08:00
|
|
|
|
|
|
|
if (port1 < 1 || port1 > hdev->maxchild)
|
|
|
|
return NULL;
|
|
|
|
return hub->ports[port1 - 1]->child;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(usb_hub_find_child);
|
2012-09-05 13:44:33 +08:00
|
|
|
|
2013-01-21 22:18:00 +08:00
|
|
|
void usb_hub_adjust_deviceremovable(struct usb_device *hdev,
|
|
|
|
struct usb_hub_descriptor *desc)
|
|
|
|
{
|
2014-05-21 09:08:17 +08:00
|
|
|
struct usb_hub *hub = usb_hub_to_struct_hub(hdev);
|
2013-01-21 22:18:00 +08:00
|
|
|
enum usb_port_connect_type connect_type;
|
|
|
|
int i;
|
|
|
|
|
2014-05-21 09:08:17 +08:00
|
|
|
if (!hub)
|
|
|
|
return;
|
|
|
|
|
2013-01-21 22:18:00 +08:00
|
|
|
if (!hub_is_superspeed(hdev)) {
|
|
|
|
for (i = 1; i <= hdev->maxchild; i++) {
|
2014-05-21 09:08:17 +08:00
|
|
|
struct usb_port *port_dev = hub->ports[i - 1];
|
2013-01-21 22:18:00 +08:00
|
|
|
|
2014-05-21 09:08:17 +08:00
|
|
|
connect_type = port_dev->connect_type;
|
2013-01-21 22:18:00 +08:00
|
|
|
if (connect_type == USB_PORT_CONNECT_TYPE_HARD_WIRED) {
|
|
|
|
u8 mask = 1 << (i%8);
|
|
|
|
|
|
|
|
if (!(desc->u.hs.DeviceRemovable[i/8] & mask)) {
|
2014-05-21 09:08:17 +08:00
|
|
|
dev_dbg(&port_dev->dev, "DeviceRemovable is changed to 1 according to platform information.\n");
|
2013-01-21 22:18:00 +08:00
|
|
|
desc->u.hs.DeviceRemovable[i/8] |= mask;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
u16 port_removable = le16_to_cpu(desc->u.ss.DeviceRemovable);
|
|
|
|
|
|
|
|
for (i = 1; i <= hdev->maxchild; i++) {
|
2014-05-21 09:08:17 +08:00
|
|
|
struct usb_port *port_dev = hub->ports[i - 1];
|
2013-01-21 22:18:00 +08:00
|
|
|
|
2014-05-21 09:08:17 +08:00
|
|
|
connect_type = port_dev->connect_type;
|
2013-01-21 22:18:00 +08:00
|
|
|
if (connect_type == USB_PORT_CONNECT_TYPE_HARD_WIRED) {
|
|
|
|
u16 mask = 1 << i;
|
|
|
|
|
|
|
|
if (!(port_removable & mask)) {
|
2014-05-21 09:08:17 +08:00
|
|
|
dev_dbg(&port_dev->dev, "DeviceRemovable is changed to 1 according to platform information.\n");
|
2013-01-21 22:18:00 +08:00
|
|
|
port_removable |= mask;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
desc->u.ss.DeviceRemovable = cpu_to_le16(port_removable);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-09-05 13:44:33 +08:00
|
|
|
#ifdef CONFIG_ACPI
|
|
|
|
/**
|
|
|
|
* usb_get_hub_port_acpi_handle - Get the usb port's acpi handle
|
|
|
|
* @hdev: USB device belonging to the usb hub
|
|
|
|
* @port1: port num of the port
|
|
|
|
*
|
2013-08-03 02:10:04 +08:00
|
|
|
* Return: Port's acpi handle if successful, %NULL if params are
|
|
|
|
* invalid.
|
2012-09-05 13:44:33 +08:00
|
|
|
*/
|
|
|
|
acpi_handle usb_get_hub_port_acpi_handle(struct usb_device *hdev,
|
|
|
|
int port1)
|
|
|
|
{
|
2013-01-23 04:26:30 +08:00
|
|
|
struct usb_hub *hub = usb_hub_to_struct_hub(hdev);
|
2012-09-05 13:44:33 +08:00
|
|
|
|
2013-06-18 22:28:48 +08:00
|
|
|
if (!hub)
|
|
|
|
return NULL;
|
|
|
|
|
2013-11-15 06:17:21 +08:00
|
|
|
return ACPI_HANDLE(&hub->ports[port1 - 1]->dev);
|
2012-09-05 13:44:33 +08:00
|
|
|
}
|
|
|
|
#endif
|