2017-11-03 16:18:41 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
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)
|
|
|
|
*
|
2016-10-29 05:16:36 +08:00
|
|
|
* Released under the GPLv2 only.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/errno.h>
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/moduleparam.h>
|
|
|
|
#include <linux/completion.h>
|
2017-02-03 03:43:54 +08:00
|
|
|
#include <linux/sched/mm.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <linux/list.h>
|
|
|
|
#include <linux/slab.h>
|
2019-12-05 08:52:47 +08:00
|
|
|
#include <linux/kcov.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#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>
|
2024-03-25 17:15:12 +08:00
|
|
|
#include <linux/usb/onboard_dev.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>
|
2018-09-21 01:17:54 +08:00
|
|
|
#include <linux/kobject.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2021-03-11 11:42:44 +08:00
|
|
|
#include <linux/bitfield.h>
|
2016-12-25 03:46:01 +08:00
|
|
|
#include <linux/uaccess.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <asm/byteorder.h>
|
|
|
|
|
2013-01-11 20:10:38 +08:00
|
|
|
#include "hub.h"
|
2023-12-13 11:10:09 +08:00
|
|
|
#include "phy.h"
|
2020-06-18 17:43:00 +08:00
|
|
|
#include "otg_productlist.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
|
USB: hub: Fix the broken detection of USB3 device in SMSC hub
Renesas R-Car H3ULCB + Kingfisher Infotainment Board is either not able
to detect the USB3.0 mass storage devices or is detecting those as
USB2.0 high speed devices.
The explanation given by Renesas is that, due to a HW issue, the XHCI
driver does not wake up after going to sleep on connecting a USB3.0
device.
In order to mitigate that, disable the auto-suspend feature
specifically for SMSC hubs from hub_probe() function, as a quirk.
Renesas Kingfisher Infotainment Board has two USB3.0 ports (CN2) which
are connected via USB5534B 4-port SuperSpeed/Hi-Speed, low-power,
configurable hub controller.
[1] SanDisk USB 3.0 device detected as USB-2.0 before the patch
[ 74.036390] usb 5-1.1: new high-speed USB device number 4 using xhci-hcd
[ 74.061598] usb 5-1.1: New USB device found, idVendor=0781, idProduct=5581, bcdDevice= 1.00
[ 74.069976] usb 5-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 74.077303] usb 5-1.1: Product: Ultra
[ 74.080980] usb 5-1.1: Manufacturer: SanDisk
[ 74.085263] usb 5-1.1: SerialNumber: 4C530001110208116550
[2] SanDisk USB 3.0 device detected as USB-3.0 after the patch
[ 34.565078] usb 6-1.1: new SuperSpeed Gen 1 USB device number 3 using xhci-hcd
[ 34.588719] usb 6-1.1: New USB device found, idVendor=0781, idProduct=5581, bcdDevice= 1.00
[ 34.597098] usb 6-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 34.604430] usb 6-1.1: Product: Ultra
[ 34.608110] usb 6-1.1: Manufacturer: SanDisk
[ 34.612397] usb 6-1.1: SerialNumber: 4C530001110208116550
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Hardik Gajjar <hgajjar@de.adit-jv.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/1580989763-32291-1-git-send-email-hgajjar@de.adit-jv.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-02-06 19:49:23 +08:00
|
|
|
#define USB_VENDOR_SMSC 0x0424
|
2020-05-15 06:02:46 +08:00
|
|
|
#define USB_PRODUCT_USB5534B 0x5534
|
2021-06-14 23:55:23 +08:00
|
|
|
#define USB_VENDOR_CYPRESS 0x04b4
|
|
|
|
#define USB_PRODUCT_CY7C65632 0x6570
|
2022-12-19 20:47:59 +08:00
|
|
|
#define USB_VENDOR_TEXAS_INSTRUMENTS 0x0451
|
|
|
|
#define USB_PRODUCT_TUSB8041_USB3 0x8140
|
|
|
|
#define USB_PRODUCT_TUSB8041_USB2 0x8142
|
2023-12-06 02:18:29 +08:00
|
|
|
#define USB_VENDOR_MICROCHIP 0x0424
|
|
|
|
#define USB_PRODUCT_USB4913 0x4913
|
|
|
|
#define USB_PRODUCT_USB4914 0x4914
|
|
|
|
#define USB_PRODUCT_USB4915 0x4915
|
2023-12-06 02:18:28 +08:00
|
|
|
#define HUB_QUIRK_CHECK_PORT_AUTOSUSPEND BIT(0)
|
|
|
|
#define HUB_QUIRK_DISABLE_AUTOSUSPEND BIT(1)
|
2023-12-06 02:18:29 +08:00
|
|
|
#define HUB_QUIRK_REDUCE_FRAME_INTR_BINTERVAL BIT(2)
|
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
|
|
|
|
2017-12-14 15:50:39 +08:00
|
|
|
#define USB_TP_TRANSMISSION_DELAY 40 /* ns */
|
|
|
|
#define USB_TP_TRANSMISSION_DELAY_MAX 65535 /* ns */
|
2021-07-15 23:01:21 +08:00
|
|
|
#define USB_PING_RESPONSE_TIME 400 /* ns */
|
2023-12-06 02:18:29 +08:00
|
|
|
#define USB_REDUCE_FRAME_INTR_BINTERVAL 9
|
2017-12-14 15:50:39 +08:00
|
|
|
|
usb: new quirk to reduce the SET_ADDRESS request timeout
This patch introduces a new USB quirk,
USB_QUIRK_SHORT_SET_ADDRESS_REQ_TIMEOUT, which modifies the timeout value
for the SET_ADDRESS request. The standard timeout for USB request/command
is 5000 ms, as recommended in the USB 3.2 specification (section 9.2.6.1).
However, certain scenarios, such as connecting devices through an APTIV
hub, can lead to timeout errors when the device enumerates as full speed
initially and later switches to high speed during chirp negotiation.
In such cases, USB analyzer logs reveal that the bus suspends for
5 seconds due to incorrect chirp parsing and resumes only after two
consecutive timeout errors trigger a hub driver reset.
Packet(54) Dir(?) Full Speed J(997.100 us) Idle( 2.850 us)
_______| Time Stamp(28 . 105 910 682)
_______|_____________________________________________________________Ch0
Packet(55) Dir(?) Full Speed J(997.118 us) Idle( 2.850 us)
_______| Time Stamp(28 . 106 910 632)
_______|_____________________________________________________________Ch0
Packet(56) Dir(?) Full Speed J(399.650 us) Idle(222.582 us)
_______| Time Stamp(28 . 107 910 600)
_______|_____________________________________________________________Ch0
Packet(57) Dir Chirp J( 23.955 ms) Idle(115.169 ms)
_______| Time Stamp(28 . 108 532 832)
_______|_____________________________________________________________Ch0
Packet(58) Dir(?) Full Speed J (Suspend)( 5.347 sec) Idle( 5.366 us)
_______| Time Stamp(28 . 247 657 600)
_______|_____________________________________________________________Ch0
This 5-second delay in device enumeration is undesirable, particularly
in automotive applications where quick enumeration is crucial
(ideally within 3 seconds).
The newly introduced quirks provide the flexibility to align with a
3-second time limit, as required in specific contexts like automotive
applications.
By reducing the SET_ADDRESS request timeout to 500 ms, the
system can respond more swiftly to errors, initiate rapid recovery, and
ensure efficient device enumeration. This change is vital for scenarios
where rapid smartphone enumeration and screen projection are essential.
To use the quirk, please write "vendor_id:product_id:p" to
/sys/bus/usb/drivers/hub/module/parameter/quirks
For example,
echo "0x2c48:0x0132:p" > /sys/bus/usb/drivers/hub/module/parameters/quirks"
Signed-off-by: Hardik Gajjar <hgajjar@de.adit-jv.com>
Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20231027152029.104363-2-hgajjar@de.adit-jv.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-10-27 23:20:29 +08:00
|
|
|
/*
|
|
|
|
* The SET_ADDRESS request timeout will be 500 ms when
|
|
|
|
* USB_QUIRK_SHORT_SET_ADDRESS_REQ_TIMEOUT quirk flag is set.
|
|
|
|
*/
|
|
|
|
#define USB_SHORT_SET_ADDRESS_REQ_TIMEOUT 500 /* ms */
|
|
|
|
|
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");
|
|
|
|
|
2020-04-26 17:41:47 +08:00
|
|
|
static bool use_both_schemes = true;
|
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
|
|
|
|
|
2008-06-18 22:00:29 +08:00
|
|
|
static int usb_reset_and_verify_device(struct usb_device *udev);
|
2016-12-14 22:37:30 +08:00
|
|
|
static int hub_port_disable(struct usb_hub *hub, int port1, int set_state);
|
2019-02-01 20:52:31 +08:00
|
|
|
static bool hub_port_warm_reset_required(struct usb_hub *hub, int port1,
|
|
|
|
u16 portstatus);
|
2008-06-18 22:00:29 +08:00
|
|
|
|
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;
|
|
|
|
|
2023-08-30 18:04:18 +08:00
|
|
|
/* Skip if the device BOS descriptor couldn't be read */
|
|
|
|
if (!udev->bos)
|
|
|
|
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
|
|
|
/*
|
2021-07-15 23:01:21 +08:00
|
|
|
* Set the Maximum Exit Latency (MEL) for the host to wakup up the path from
|
|
|
|
* U1/U2, send a PING to the device and receive a PING_RESPONSE.
|
|
|
|
* See USB 3.1 section C.1.5.2
|
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
|
|
|
*/
|
|
|
|
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;
|
|
|
|
|
|
|
|
/*
|
2021-07-15 23:01:21 +08:00
|
|
|
* tMEL1. time to transition path from host to device into U0.
|
|
|
|
* MEL for parent already contains the delay up to parent, so only add
|
|
|
|
* the exit latency for the last link (pick the slower exit latency),
|
|
|
|
* and the hub header decode latency. See USB 3.1 section C 2.2.1
|
|
|
|
* Store MEL in nanoseconds
|
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
|
|
|
*/
|
|
|
|
total_mel = hub_lpm_params->mel +
|
2021-07-15 23:01:21 +08:00
|
|
|
max(udev_exit_latency, hub_exit_latency) * 1000 +
|
|
|
|
hub->descriptor->u.ss.bHubHdrDecLat * 100;
|
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
|
|
|
|
|
|
|
/*
|
2021-07-15 23:01:21 +08:00
|
|
|
* tMEL2. Time to submit PING packet. Sum of tTPTransmissionDelay for
|
|
|
|
* each link + wHubDelay for each hub. Add only for last link.
|
|
|
|
* tMEL4, the time for PING_RESPONSE to traverse upstream is similar.
|
|
|
|
* Multiply by 2 to include it as well.
|
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
|
|
|
*/
|
2021-07-15 23:01:21 +08:00
|
|
|
total_mel += (__le16_to_cpu(hub->descriptor->u.ss.wHubDelay) +
|
|
|
|
USB_TP_TRANSMISSION_DELAY) * 2;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* tMEL3, tPingResponse. Time taken by device to generate PING_RESPONSE
|
|
|
|
* after receiving PING. Also add 2100ns as stated in USB 3.1 C 1.5.2.4
|
|
|
|
* to cover the delay if the PING_RESPONSE is queued behind a Max Packet
|
|
|
|
* Size DP.
|
|
|
|
* Note these delays should be added only once for the entire path, so
|
|
|
|
* add them to the MEL of the device connected to the roothub.
|
|
|
|
*/
|
|
|
|
if (!hub->hdev->parent)
|
|
|
|
total_mel += USB_PING_RESPONSE_TIME + 2100;
|
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
|
|
|
|
|
|
|
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;
|
|
|
|
|
2023-08-30 18:04:18 +08:00
|
|
|
/* Skip if the device BOS descriptor couldn't be read */
|
|
|
|
if (!udev->bos)
|
|
|
|
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 */
|
2017-05-11 00:18:28 +08:00
|
|
|
static int get_hub_descriptor(struct usb_device *hdev,
|
|
|
|
struct usb_hub_descriptor *desc)
|
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,
|
2017-05-11 00:18:28 +08:00
|
|
|
dtype << 8, 0, desc, size,
|
2005-04-17 06:20:36 +08:00
|
|
|
USB_CTRL_GET_TIMEOUT);
|
2017-05-11 00:18:27 +08:00
|
|
|
if (hub_is_superspeed(hdev)) {
|
|
|
|
if (ret == size)
|
|
|
|
return ret;
|
2017-05-11 00:18:28 +08:00
|
|
|
} else if (ret >= USB_DT_HUB_NONVAR_SIZE + 2) {
|
|
|
|
/* Make sure we have the DeviceRemovable field. */
|
|
|
|
size = USB_DT_HUB_NONVAR_SIZE + desc->bNbrPorts / 8 + 1;
|
|
|
|
if (ret < size)
|
|
|
|
return -EMSGSIZE;
|
2005-04-17 06:20:36 +08:00
|
|
|
return ret;
|
2017-05-11 00:18:27 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* USB 2.0 spec Section 11.24.2.1
|
|
|
|
*/
|
|
|
|
static int clear_hub_feature(struct usb_device *hdev, int feature)
|
|
|
|
{
|
2020-09-23 21:43:35 +08:00
|
|
|
return usb_control_msg(hdev, usb_sndctrlpipe(hdev, 0),
|
|
|
|
USB_REQ_CLEAR_FEATURE, USB_RT_HUB, feature, 0, NULL, 0, 1000);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 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
|
|
|
{
|
2020-09-23 21:43:35 +08:00
|
|
|
return usb_control_msg(hdev, usb_sndctrlpipe(hdev, 0),
|
|
|
|
USB_REQ_CLEAR_FEATURE, USB_RT_PORT, feature, port1,
|
|
|
|
NULL, 0, 1000);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* USB 2.0 spec Section 11.24.2.13
|
|
|
|
*/
|
|
|
|
static int set_port_feature(struct usb_device *hdev, int port1, int feature)
|
|
|
|
{
|
2020-09-23 21:43:35 +08:00
|
|
|
return usb_control_msg(hdev, usb_sndctrlpipe(hdev, 0),
|
|
|
|
USB_REQ_SET_FEATURE, USB_RT_PORT, feature, port1,
|
|
|
|
NULL, 0, 1000);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
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);
|
2023-12-13 11:10:09 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* There is no need to lock status_mutex here, because status_mutex
|
|
|
|
* protects hub->status, and the phy driver only checks the port
|
|
|
|
* status without changing the status.
|
|
|
|
*/
|
|
|
|
if (!ret) {
|
|
|
|
struct usb_device *hdev = hub->hdev;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Only roothub will be notified of connection changes,
|
|
|
|
* since the USB PHY only cares about changes at the next
|
|
|
|
* level.
|
|
|
|
*/
|
|
|
|
if (is_root_hub(hdev)) {
|
|
|
|
struct usb_hcd *hcd = bus_to_hcd(hdev->bus);
|
|
|
|
bool connect;
|
|
|
|
bool connect_change;
|
|
|
|
|
|
|
|
connect_change = *change & USB_PORT_STAT_C_CONNECTION;
|
|
|
|
connect = *status & USB_PORT_STAT_CONNECTION;
|
|
|
|
if (connect_change && connect)
|
|
|
|
usb_phy_roothub_notify_connect(hcd->phy_roothub, port1 - 1);
|
|
|
|
else if (connect_change)
|
|
|
|
usb_phy_roothub_notify_disconnect(hcd->phy_roothub, port1 - 1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-03-04 04:15:43 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2022-06-07 19:45:22 +08:00
|
|
|
int usb_hub_port_status(struct usb_hub *hub, int port1,
|
2015-12-10 15:59:29 +08:00
|
|
|
u16 *status, u16 *change)
|
|
|
|
{
|
|
|
|
return hub_ext_port_status(hub, port1, HUB_PORT_STATUS,
|
|
|
|
status, change, NULL);
|
|
|
|
}
|
|
|
|
|
2019-01-08 23:45:22 +08:00
|
|
|
static void hub_resubmit_irq_urb(struct usb_hub *hub)
|
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
int status;
|
|
|
|
|
|
|
|
spin_lock_irqsave(&hub->irq_urb_lock, flags);
|
|
|
|
|
|
|
|
if (hub->quiescing) {
|
|
|
|
spin_unlock_irqrestore(&hub->irq_urb_lock, flags);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
status = usb_submit_urb(hub->urb, GFP_ATOMIC);
|
|
|
|
if (status && status != -ENODEV && status != -EPERM &&
|
|
|
|
status != -ESHUTDOWN) {
|
|
|
|
dev_err(hub->intfdev, "resubmit --> %d\n", status);
|
|
|
|
mod_timer(&hub->irq_urb_retry, jiffies + HZ);
|
|
|
|
}
|
|
|
|
|
|
|
|
spin_unlock_irqrestore(&hub->irq_urb_lock, flags);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void hub_retry_irq_urb(struct timer_list *t)
|
|
|
|
{
|
|
|
|
struct usb_hub *hub = from_timer(hub, t, irq_urb_retry);
|
|
|
|
|
|
|
|
hub_resubmit_irq_urb(hub);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
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);
|
2024-03-16 01:04:50 +08:00
|
|
|
hub_get(hub);
|
2014-09-19 23:32:21 +08:00
|
|
|
|
|
|
|
if (queue_work(hub_wq, &hub->events))
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* the work has already been scheduled */
|
|
|
|
usb_autopm_put_interface_async(intf);
|
2024-03-16 01:04:50 +08:00
|
|
|
hub_put(hub);
|
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;
|
2018-04-21 02:08:21 +08:00
|
|
|
struct usb_port *port_dev;
|
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 (!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) {
|
2018-04-21 02:08:21 +08:00
|
|
|
port_dev = hub->ports[portnum - 1];
|
|
|
|
if (port_dev && port_dev->child)
|
|
|
|
pm_wakeup_event(&port_dev->child->dev, 0);
|
|
|
|
|
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
|
|
|
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;
|
2020-08-24 06:36:59 +08:00
|
|
|
fallthrough;
|
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:
|
2019-01-08 23:45:22 +08:00
|
|
|
hub_resubmit_irq_urb(hub);
|
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) {
|
2020-09-23 21:43:35 +08:00
|
|
|
int status = usb_control_msg(hdev, usb_sndctrlpipe(hdev, 0),
|
|
|
|
HUB_CLEAR_TT_BUFFER, USB_RT_PORT,
|
|
|
|
devinfo ^ 0x8000, tt, NULL, 0, 1000);
|
2013-06-28 07:10:20 +08:00
|
|
|
if (status)
|
|
|
|
return status;
|
|
|
|
}
|
2020-09-23 21:43:35 +08:00
|
|
|
return usb_control_msg(hdev, usb_sndctrlpipe(hdev, 0),
|
|
|
|
HUB_CLEAR_TT_BUFFER, USB_RT_PORT, devinfo,
|
|
|
|
tt, NULL, 0, 1000);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
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);
|
2019-06-03 18:53:43 +08:00
|
|
|
clear->devinfo |= ((u16)udev->devaddr) << 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);
|
|
|
|
}
|
|
|
|
|
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;
|
2020-02-27 01:50:35 +08:00
|
|
|
int ret;
|
2009-10-28 03:20:13 +08:00
|
|
|
|
|
|
|
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);
|
|
|
|
|
2020-02-27 01:50:35 +08:00
|
|
|
ret = usb_autopm_get_interface(intf);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
2009-10-28 03:20:13 +08:00
|
|
|
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) {
|
2016-08-05 23:51:30 +08:00
|
|
|
device_lock(&hdev->dev);
|
2015-12-17 02:32:38 +08:00
|
|
|
|
|
|
|
/* 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
|
|
|
}
|
2024-03-16 01:04:50 +08:00
|
|
|
hub_get(hub);
|
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)) {
|
2020-09-23 21:43:35 +08:00
|
|
|
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)
|
2012-02-18 13:32:27 +08:00
|
|
|
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) {
|
2017-12-06 14:22:05 +08:00
|
|
|
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");
|
2010-12-24 03:12:42 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
hub_power_on(hub, true);
|
2008-09-23 02:44:26 +08:00
|
|
|
} else {
|
|
|
|
hub_power_on(hub, true);
|
|
|
|
}
|
usb: hub: Add delay for SuperSpeed hub resume to let links transit to U0
When a new USB device gets plugged to nested hubs, the affected hub,
which connects to usb 2-1.4-port2, doesn't report there's any change,
hence the nested hubs go back to runtime suspend like nothing happened:
[ 281.032951] usb usb2: usb wakeup-resume
[ 281.032959] usb usb2: usb auto-resume
[ 281.032974] hub 2-0:1.0: hub_resume
[ 281.033011] usb usb2-port1: status 0263 change 0000
[ 281.033077] hub 2-0:1.0: state 7 ports 4 chg 0000 evt 0000
[ 281.049797] usb 2-1: usb wakeup-resume
[ 281.069800] usb 2-1: Waited 0ms for CONNECT
[ 281.069810] usb 2-1: finish resume
[ 281.070026] hub 2-1:1.0: hub_resume
[ 281.070250] usb 2-1-port4: status 0203 change 0000
[ 281.070272] usb usb2-port1: resume, status 0
[ 281.070282] hub 2-1:1.0: state 7 ports 4 chg 0010 evt 0000
[ 281.089813] usb 2-1.4: usb wakeup-resume
[ 281.109792] usb 2-1.4: Waited 0ms for CONNECT
[ 281.109801] usb 2-1.4: finish resume
[ 281.109991] hub 2-1.4:1.0: hub_resume
[ 281.110147] usb 2-1.4-port2: status 0263 change 0000
[ 281.110234] usb 2-1-port4: resume, status 0
[ 281.110239] usb 2-1-port4: status 0203, change 0000, 10.0 Gb/s
[ 281.110266] hub 2-1.4:1.0: state 7 ports 4 chg 0000 evt 0000
[ 281.110426] hub 2-1.4:1.0: hub_suspend
[ 281.110565] usb 2-1.4: usb auto-suspend, wakeup 1
[ 281.130998] hub 2-1:1.0: hub_suspend
[ 281.137788] usb 2-1: usb auto-suspend, wakeup 1
[ 281.142935] hub 2-0:1.0: state 7 ports 4 chg 0000 evt 0000
[ 281.177828] usb 2-1: usb wakeup-resume
[ 281.197839] usb 2-1: Waited 0ms for CONNECT
[ 281.197850] usb 2-1: finish resume
[ 281.197984] hub 2-1:1.0: hub_resume
[ 281.198203] usb 2-1-port4: status 0203 change 0000
[ 281.198228] usb usb2-port1: resume, status 0
[ 281.198237] hub 2-1:1.0: state 7 ports 4 chg 0010 evt 0000
[ 281.217835] usb 2-1.4: usb wakeup-resume
[ 281.237834] usb 2-1.4: Waited 0ms for CONNECT
[ 281.237845] usb 2-1.4: finish resume
[ 281.237990] hub 2-1.4:1.0: hub_resume
[ 281.238067] usb 2-1.4-port2: status 0263 change 0000
[ 281.238148] usb 2-1-port4: resume, status 0
[ 281.238152] usb 2-1-port4: status 0203, change 0000, 10.0 Gb/s
[ 281.238166] hub 2-1.4:1.0: state 7 ports 4 chg 0000 evt 0000
[ 281.238385] hub 2-1.4:1.0: hub_suspend
[ 281.238523] usb 2-1.4: usb auto-suspend, wakeup 1
[ 281.258076] hub 2-1:1.0: hub_suspend
[ 281.265744] usb 2-1: usb auto-suspend, wakeup 1
[ 281.285976] hub 2-0:1.0: hub_suspend
[ 281.285988] usb usb2: bus auto-suspend, wakeup 1
USB 3.2 spec, 9.2.5.4 "Changing Function Suspend State" says that "If
the link is in a non-U0 state, then the device must transition the link
to U0 prior to sending the remote wake message", but the hub only
transits the link to U0 after signaling remote wakeup.
So be more forgiving and use a 20ms delay to let the link transit to U0
for remote wakeup.
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Link: https://lore.kernel.org/r/20211215120108.336597-1-kai.heng.feng@canonical.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-15 20:01:06 +08:00
|
|
|
/* Give some time on remote wakeup to let links to transit to U0 */
|
|
|
|
} else if (hub_is_superspeed(hub->hdev))
|
|
|
|
msleep(20);
|
|
|
|
|
2008-09-23 02:44:26 +08:00
|
|
|
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;
|
2022-06-07 19:45:22 +08:00
|
|
|
status = usb_hub_port_status(hub, port1, &portstatus, &portchange);
|
2017-03-21 02:16:11 +08:00
|
|
|
if (status)
|
|
|
|
goto abort;
|
|
|
|
|
2008-04-28 23:06:42 +08:00
|
|
|
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
|
|
|
}
|
|
|
|
|
2019-02-01 20:52:31 +08:00
|
|
|
/* Make sure a warm-reset request is handled by port_event */
|
|
|
|
if (type == HUB_RESUME &&
|
|
|
|
hub_port_warm_reset_required(hub, port1, portstatus))
|
|
|
|
set_bit(port1, hub->event_bits);
|
|
|
|
|
2018-11-28 21:55:21 +08:00
|
|
|
/*
|
|
|
|
* Add debounce if USB3 link is in polling/link training state.
|
|
|
|
* Link will automatically transition to Enabled state after
|
|
|
|
* link training completes.
|
|
|
|
*/
|
|
|
|
if (hub_is_superspeed(hdev) &&
|
|
|
|
((portstatus & USB_PORT_STAT_LINK_STATE) ==
|
|
|
|
USB_SS_PORT_LS_POLLING))
|
|
|
|
need_debounce_delay = true;
|
|
|
|
|
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
|
2018-07-20 03:39:37 +08:00
|
|
|
* check for a new connection or over current condition.
|
|
|
|
* Based on USB2.0 Spec Section 11.12.5,
|
|
|
|
* C_PORT_OVER_CURRENT could be set while
|
|
|
|
* PORT_OVER_CURRENT is not. So check for any of them.
|
2008-04-28 23:06:42 +08:00
|
|
|
*/
|
2014-01-08 14:45:42 +08:00
|
|
|
if (udev || (portstatus & USB_PORT_STAT_CONNECTION) ||
|
2020-01-09 13:14:48 +08:00
|
|
|
(portchange & USB_PORT_STAT_C_CONNECTION) ||
|
2018-07-20 03:39:37 +08:00
|
|
|
(portstatus & USB_PORT_STAT_OVERCURRENT) ||
|
|
|
|
(portchange & USB_PORT_STAT_C_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))
|
2022-01-02 03:52:14 +08:00
|
|
|
set_bit(port1, hub->event_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
|
2020-04-23 04:09:51 +08:00
|
|
|
/* Don't set the change_bits when the device
|
|
|
|
* was powered off.
|
|
|
|
*/
|
|
|
|
if (test_bit(port1, hub->power_bits))
|
|
|
|
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));
|
2016-08-05 23:51:30 +08:00
|
|
|
device_unlock(&hdev->dev);
|
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);
|
2017-03-21 02:16:11 +08:00
|
|
|
abort:
|
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));
|
2016-08-05 23:51:30 +08:00
|
|
|
device_unlock(&hdev->dev);
|
2016-08-05 23:49:45 +08:00
|
|
|
}
|
2015-12-17 02:32:38 +08:00
|
|
|
|
2024-03-16 01:04:50 +08:00
|
|
|
hub_put(hub);
|
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;
|
2019-01-08 23:45:22 +08:00
|
|
|
unsigned long flags;
|
2008-04-28 23:07:31 +08:00
|
|
|
int i;
|
|
|
|
|
2014-09-19 23:32:23 +08:00
|
|
|
/* hub_wq and related activity won't re-trigger */
|
2019-01-08 23:45:22 +08:00
|
|
|
spin_lock_irqsave(&hub->irq_urb_lock, flags);
|
2008-04-28 23:07:31 +08:00
|
|
|
hub->quiescing = 1;
|
2019-01-08 23:45:22 +08:00
|
|
|
spin_unlock_irqrestore(&hub->irq_urb_lock, flags);
|
2008-04-28 23:07:31 +08:00
|
|
|
|
|
|
|
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 */
|
2019-01-08 23:45:22 +08:00
|
|
|
del_timer_sync(&hub->irq_urb_retry);
|
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
|
|
|
|
2017-05-11 00:18:28 +08:00
|
|
|
hub->descriptor = kzalloc(sizeof(*hub->descriptor), GFP_KERNEL);
|
2005-04-17 06:20:36 +08:00
|
|
|
if (!hub->descriptor) {
|
|
|
|
ret = -ENOMEM;
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Request the entire hub descriptor.
|
|
|
|
* hub->descriptor can handle USB_MAXCHILDREN ports,
|
2017-05-11 00:18:27 +08:00
|
|
|
* but a (non-SS) hub can/will return fewer bytes here.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
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;
|
2017-05-11 00:18:29 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
maxchild = USB_MAXCHILDREN;
|
|
|
|
if (hub_is_superspeed(hdev))
|
|
|
|
maxchild = min_t(unsigned, maxchild, USB_SS_MAXPORTS);
|
|
|
|
|
|
|
|
if (hub->descriptor->bNbrPorts > maxchild) {
|
2005-04-17 06:20:36 +08:00
|
|
|
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
|
|
|
}
|
|
|
|
|
2017-12-14 15:50:39 +08:00
|
|
|
/*
|
|
|
|
* Accumulate wHubDelay + 40ns for every hub in the tree of devices.
|
|
|
|
* The resulting value will be used for SetIsochDelay() request.
|
|
|
|
*/
|
|
|
|
if (hub_is_superspeed(hdev) || hub_is_superspeedplus(hdev)) {
|
|
|
|
u32 delay = __le16_to_cpu(hub->descriptor->u.ss.wHubDelay);
|
|
|
|
|
|
|
|
if (hdev->parent)
|
|
|
|
delay += hdev->parent->hub_delay;
|
|
|
|
|
|
|
|
delay += USB_TP_TRANSMISSION_DELAY;
|
|
|
|
hdev->hub_delay = min_t(u32, delay, USB_TP_TRANSMISSION_DELAY_MAX);
|
|
|
|
}
|
|
|
|
|
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
|
|
|
|
treewide: kzalloc() -> kcalloc()
The kzalloc() function has a 2-factor argument form, kcalloc(). This
patch replaces cases of:
kzalloc(a * b, gfp)
with:
kcalloc(a * b, gfp)
as well as handling cases of:
kzalloc(a * b * c, gfp)
with:
kzalloc(array3_size(a, b, c), gfp)
as it's slightly less ugly than:
kzalloc_array(array_size(a, b), c, gfp)
This does, however, attempt to ignore constant size factors like:
kzalloc(4 * 1024, gfp)
though any constants defined via macros get caught up in the conversion.
Any factors with a sizeof() of "unsigned char", "char", and "u8" were
dropped, since they're redundant.
The Coccinelle script used for this was:
// Fix redundant parens around sizeof().
@@
type TYPE;
expression THING, E;
@@
(
kzalloc(
- (sizeof(TYPE)) * E
+ sizeof(TYPE) * E
, ...)
|
kzalloc(
- (sizeof(THING)) * E
+ sizeof(THING) * E
, ...)
)
// Drop single-byte sizes and redundant parens.
@@
expression COUNT;
typedef u8;
typedef __u8;
@@
(
kzalloc(
- sizeof(u8) * (COUNT)
+ COUNT
, ...)
|
kzalloc(
- sizeof(__u8) * (COUNT)
+ COUNT
, ...)
|
kzalloc(
- sizeof(char) * (COUNT)
+ COUNT
, ...)
|
kzalloc(
- sizeof(unsigned char) * (COUNT)
+ COUNT
, ...)
|
kzalloc(
- sizeof(u8) * COUNT
+ COUNT
, ...)
|
kzalloc(
- sizeof(__u8) * COUNT
+ COUNT
, ...)
|
kzalloc(
- sizeof(char) * COUNT
+ COUNT
, ...)
|
kzalloc(
- sizeof(unsigned char) * COUNT
+ COUNT
, ...)
)
// 2-factor product with sizeof(type/expression) and identifier or constant.
@@
type TYPE;
expression THING;
identifier COUNT_ID;
constant COUNT_CONST;
@@
(
- kzalloc
+ kcalloc
(
- sizeof(TYPE) * (COUNT_ID)
+ COUNT_ID, sizeof(TYPE)
, ...)
|
- kzalloc
+ kcalloc
(
- sizeof(TYPE) * COUNT_ID
+ COUNT_ID, sizeof(TYPE)
, ...)
|
- kzalloc
+ kcalloc
(
- sizeof(TYPE) * (COUNT_CONST)
+ COUNT_CONST, sizeof(TYPE)
, ...)
|
- kzalloc
+ kcalloc
(
- sizeof(TYPE) * COUNT_CONST
+ COUNT_CONST, sizeof(TYPE)
, ...)
|
- kzalloc
+ kcalloc
(
- sizeof(THING) * (COUNT_ID)
+ COUNT_ID, sizeof(THING)
, ...)
|
- kzalloc
+ kcalloc
(
- sizeof(THING) * COUNT_ID
+ COUNT_ID, sizeof(THING)
, ...)
|
- kzalloc
+ kcalloc
(
- sizeof(THING) * (COUNT_CONST)
+ COUNT_CONST, sizeof(THING)
, ...)
|
- kzalloc
+ kcalloc
(
- sizeof(THING) * COUNT_CONST
+ COUNT_CONST, sizeof(THING)
, ...)
)
// 2-factor product, only identifiers.
@@
identifier SIZE, COUNT;
@@
- kzalloc
+ kcalloc
(
- SIZE * COUNT
+ COUNT, SIZE
, ...)
// 3-factor product with 1 sizeof(type) or sizeof(expression), with
// redundant parens removed.
@@
expression THING;
identifier STRIDE, COUNT;
type TYPE;
@@
(
kzalloc(
- sizeof(TYPE) * (COUNT) * (STRIDE)
+ array3_size(COUNT, STRIDE, sizeof(TYPE))
, ...)
|
kzalloc(
- sizeof(TYPE) * (COUNT) * STRIDE
+ array3_size(COUNT, STRIDE, sizeof(TYPE))
, ...)
|
kzalloc(
- sizeof(TYPE) * COUNT * (STRIDE)
+ array3_size(COUNT, STRIDE, sizeof(TYPE))
, ...)
|
kzalloc(
- sizeof(TYPE) * COUNT * STRIDE
+ array3_size(COUNT, STRIDE, sizeof(TYPE))
, ...)
|
kzalloc(
- sizeof(THING) * (COUNT) * (STRIDE)
+ array3_size(COUNT, STRIDE, sizeof(THING))
, ...)
|
kzalloc(
- sizeof(THING) * (COUNT) * STRIDE
+ array3_size(COUNT, STRIDE, sizeof(THING))
, ...)
|
kzalloc(
- sizeof(THING) * COUNT * (STRIDE)
+ array3_size(COUNT, STRIDE, sizeof(THING))
, ...)
|
kzalloc(
- sizeof(THING) * COUNT * STRIDE
+ array3_size(COUNT, STRIDE, sizeof(THING))
, ...)
)
// 3-factor product with 2 sizeof(variable), with redundant parens removed.
@@
expression THING1, THING2;
identifier COUNT;
type TYPE1, TYPE2;
@@
(
kzalloc(
- sizeof(TYPE1) * sizeof(TYPE2) * COUNT
+ array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2))
, ...)
|
kzalloc(
- sizeof(TYPE1) * sizeof(THING2) * (COUNT)
+ array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2))
, ...)
|
kzalloc(
- sizeof(THING1) * sizeof(THING2) * COUNT
+ array3_size(COUNT, sizeof(THING1), sizeof(THING2))
, ...)
|
kzalloc(
- sizeof(THING1) * sizeof(THING2) * (COUNT)
+ array3_size(COUNT, sizeof(THING1), sizeof(THING2))
, ...)
|
kzalloc(
- sizeof(TYPE1) * sizeof(THING2) * COUNT
+ array3_size(COUNT, sizeof(TYPE1), sizeof(THING2))
, ...)
|
kzalloc(
- sizeof(TYPE1) * sizeof(THING2) * (COUNT)
+ array3_size(COUNT, sizeof(TYPE1), sizeof(THING2))
, ...)
)
// 3-factor product, only identifiers, with redundant parens removed.
@@
identifier STRIDE, SIZE, COUNT;
@@
(
kzalloc(
- (COUNT) * STRIDE * SIZE
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kzalloc(
- COUNT * (STRIDE) * SIZE
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kzalloc(
- COUNT * STRIDE * (SIZE)
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kzalloc(
- (COUNT) * (STRIDE) * SIZE
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kzalloc(
- COUNT * (STRIDE) * (SIZE)
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kzalloc(
- (COUNT) * STRIDE * (SIZE)
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kzalloc(
- (COUNT) * (STRIDE) * (SIZE)
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kzalloc(
- COUNT * STRIDE * SIZE
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
)
// Any remaining multi-factor products, first at least 3-factor products,
// when they're not all constants...
@@
expression E1, E2, E3;
constant C1, C2, C3;
@@
(
kzalloc(C1 * C2 * C3, ...)
|
kzalloc(
- (E1) * E2 * E3
+ array3_size(E1, E2, E3)
, ...)
|
kzalloc(
- (E1) * (E2) * E3
+ array3_size(E1, E2, E3)
, ...)
|
kzalloc(
- (E1) * (E2) * (E3)
+ array3_size(E1, E2, E3)
, ...)
|
kzalloc(
- E1 * E2 * E3
+ array3_size(E1, E2, E3)
, ...)
)
// And then all remaining 2 factors products when they're not all constants,
// keeping sizeof() as the second factor argument.
@@
expression THING, E1, E2;
type TYPE;
constant C1, C2, C3;
@@
(
kzalloc(sizeof(THING) * C2, ...)
|
kzalloc(sizeof(TYPE) * C2, ...)
|
kzalloc(C1 * C2 * C3, ...)
|
kzalloc(C1 * C2, ...)
|
- kzalloc
+ kcalloc
(
- sizeof(TYPE) * (E2)
+ E2, sizeof(TYPE)
, ...)
|
- kzalloc
+ kcalloc
(
- sizeof(TYPE) * E2
+ E2, sizeof(TYPE)
, ...)
|
- kzalloc
+ kcalloc
(
- sizeof(THING) * (E2)
+ E2, sizeof(THING)
, ...)
|
- kzalloc
+ kcalloc
(
- sizeof(THING) * E2
+ E2, sizeof(THING)
, ...)
|
- kzalloc
+ kcalloc
(
- (E1) * E2
+ E1, E2
, ...)
|
- kzalloc
+ kcalloc
(
- (E1) * (E2)
+ E1, E2
, ...)
|
- kzalloc
+ kcalloc
(
- E1 * E2
+ E1, E2
, ...)
)
Signed-off-by: Kees Cook <keescook@chromium.org>
2018-06-13 05:03:40 +08:00
|
|
|
hub->ports = kcalloc(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).
|
|
|
|
*/
|
2017-11-02 16:57:40 +08:00
|
|
|
ret = usb_get_std_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);
|
2022-03-17 11:55:11 +08:00
|
|
|
maxp = usb_maxpacket(hdev, pipe);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
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);
|
|
|
|
}
|
|
|
|
|
2024-03-16 01:04:50 +08:00
|
|
|
void hub_get(struct usb_hub *hub)
|
|
|
|
{
|
|
|
|
kref_get(&hub->kref);
|
|
|
|
}
|
|
|
|
|
|
|
|
void hub_put(struct usb_hub *hub)
|
|
|
|
{
|
|
|
|
kref_put(&hub->kref, hub_release);
|
|
|
|
}
|
|
|
|
|
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);
|
USB: hub: Fix the broken detection of USB3 device in SMSC hub
Renesas R-Car H3ULCB + Kingfisher Infotainment Board is either not able
to detect the USB3.0 mass storage devices or is detecting those as
USB2.0 high speed devices.
The explanation given by Renesas is that, due to a HW issue, the XHCI
driver does not wake up after going to sleep on connecting a USB3.0
device.
In order to mitigate that, disable the auto-suspend feature
specifically for SMSC hubs from hub_probe() function, as a quirk.
Renesas Kingfisher Infotainment Board has two USB3.0 ports (CN2) which
are connected via USB5534B 4-port SuperSpeed/Hi-Speed, low-power,
configurable hub controller.
[1] SanDisk USB 3.0 device detected as USB-2.0 before the patch
[ 74.036390] usb 5-1.1: new high-speed USB device number 4 using xhci-hcd
[ 74.061598] usb 5-1.1: New USB device found, idVendor=0781, idProduct=5581, bcdDevice= 1.00
[ 74.069976] usb 5-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 74.077303] usb 5-1.1: Product: Ultra
[ 74.080980] usb 5-1.1: Manufacturer: SanDisk
[ 74.085263] usb 5-1.1: SerialNumber: 4C530001110208116550
[2] SanDisk USB 3.0 device detected as USB-3.0 after the patch
[ 34.565078] usb 6-1.1: new SuperSpeed Gen 1 USB device number 3 using xhci-hcd
[ 34.588719] usb 6-1.1: New USB device found, idVendor=0781, idProduct=5581, bcdDevice= 1.00
[ 34.597098] usb 6-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 34.604430] usb 6-1.1: Product: Ultra
[ 34.608110] usb 6-1.1: Manufacturer: SanDisk
[ 34.612397] usb 6-1.1: SerialNumber: 4C530001110208116550
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Hardik Gajjar <hgajjar@de.adit-jv.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/1580989763-32291-1-git-send-email-hgajjar@de.adit-jv.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-02-06 19:49:23 +08:00
|
|
|
|
|
|
|
if (hub->quirk_disable_autosuspend)
|
|
|
|
usb_autopm_put_interface(intf);
|
|
|
|
|
2024-03-25 17:15:12 +08:00
|
|
|
onboard_dev_destroy_pdevs(&hub->onboard_devs);
|
2022-07-01 03:35:30 +08:00
|
|
|
|
2024-03-16 01:04:50 +08:00
|
|
|
hub_put(hub);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2017-06-25 16:08:14 +08:00
|
|
|
static bool hub_descriptor_is_sane(struct usb_host_interface *desc)
|
|
|
|
{
|
|
|
|
/* 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)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
/* Multiple endpoints? What kind of mutant ninja-hub is this? */
|
|
|
|
if (desc->desc.bNumEndpoints != 1)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
/* If the first endpoint is not interrupt IN, we'd better punt! */
|
|
|
|
if (!usb_endpoint_is_int_in(&desc->endpoint[0].desc))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
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_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;
|
|
|
|
}
|
|
|
|
|
2020-06-18 17:42:54 +08:00
|
|
|
#ifdef CONFIG_USB_OTG_DISABLE_EXTERNAL_HUB
|
2006-04-03 02:18:09 +08:00
|
|
|
if (hdev->parent) {
|
|
|
|
dev_warn(&intf->dev, "ignoring external hub\n");
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2017-06-25 16:08:14 +08:00
|
|
|
if (!hub_descriptor_is_sane(desc)) {
|
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;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* 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);
|
2016-08-26 01:38:59 +08:00
|
|
|
if (!hub)
|
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);
|
2024-03-25 17:15:12 +08:00
|
|
|
INIT_LIST_HEAD(&hub->onboard_devs);
|
2019-01-08 23:45:22 +08:00
|
|
|
spin_lock_init(&hub->irq_urb_lock);
|
|
|
|
timer_setup(&hub->irq_urb_retry, hub_retry_irq_urb, 0);
|
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;
|
|
|
|
|
USB: hub: Fix the broken detection of USB3 device in SMSC hub
Renesas R-Car H3ULCB + Kingfisher Infotainment Board is either not able
to detect the USB3.0 mass storage devices or is detecting those as
USB2.0 high speed devices.
The explanation given by Renesas is that, due to a HW issue, the XHCI
driver does not wake up after going to sleep on connecting a USB3.0
device.
In order to mitigate that, disable the auto-suspend feature
specifically for SMSC hubs from hub_probe() function, as a quirk.
Renesas Kingfisher Infotainment Board has two USB3.0 ports (CN2) which
are connected via USB5534B 4-port SuperSpeed/Hi-Speed, low-power,
configurable hub controller.
[1] SanDisk USB 3.0 device detected as USB-2.0 before the patch
[ 74.036390] usb 5-1.1: new high-speed USB device number 4 using xhci-hcd
[ 74.061598] usb 5-1.1: New USB device found, idVendor=0781, idProduct=5581, bcdDevice= 1.00
[ 74.069976] usb 5-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 74.077303] usb 5-1.1: Product: Ultra
[ 74.080980] usb 5-1.1: Manufacturer: SanDisk
[ 74.085263] usb 5-1.1: SerialNumber: 4C530001110208116550
[2] SanDisk USB 3.0 device detected as USB-3.0 after the patch
[ 34.565078] usb 6-1.1: new SuperSpeed Gen 1 USB device number 3 using xhci-hcd
[ 34.588719] usb 6-1.1: New USB device found, idVendor=0781, idProduct=5581, bcdDevice= 1.00
[ 34.597098] usb 6-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 34.604430] usb 6-1.1: Product: Ultra
[ 34.608110] usb 6-1.1: Manufacturer: SanDisk
[ 34.612397] usb 6-1.1: SerialNumber: 4C530001110208116550
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Hardik Gajjar <hgajjar@de.adit-jv.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/1580989763-32291-1-git-send-email-hgajjar@de.adit-jv.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-02-06 19:49:23 +08:00
|
|
|
if (id->driver_info & HUB_QUIRK_DISABLE_AUTOSUSPEND) {
|
|
|
|
hub->quirk_disable_autosuspend = 1;
|
2020-02-27 01:50:34 +08:00
|
|
|
usb_autopm_get_interface_no_resume(intf);
|
USB: hub: Fix the broken detection of USB3 device in SMSC hub
Renesas R-Car H3ULCB + Kingfisher Infotainment Board is either not able
to detect the USB3.0 mass storage devices or is detecting those as
USB2.0 high speed devices.
The explanation given by Renesas is that, due to a HW issue, the XHCI
driver does not wake up after going to sleep on connecting a USB3.0
device.
In order to mitigate that, disable the auto-suspend feature
specifically for SMSC hubs from hub_probe() function, as a quirk.
Renesas Kingfisher Infotainment Board has two USB3.0 ports (CN2) which
are connected via USB5534B 4-port SuperSpeed/Hi-Speed, low-power,
configurable hub controller.
[1] SanDisk USB 3.0 device detected as USB-2.0 before the patch
[ 74.036390] usb 5-1.1: new high-speed USB device number 4 using xhci-hcd
[ 74.061598] usb 5-1.1: New USB device found, idVendor=0781, idProduct=5581, bcdDevice= 1.00
[ 74.069976] usb 5-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 74.077303] usb 5-1.1: Product: Ultra
[ 74.080980] usb 5-1.1: Manufacturer: SanDisk
[ 74.085263] usb 5-1.1: SerialNumber: 4C530001110208116550
[2] SanDisk USB 3.0 device detected as USB-3.0 after the patch
[ 34.565078] usb 6-1.1: new SuperSpeed Gen 1 USB device number 3 using xhci-hcd
[ 34.588719] usb 6-1.1: New USB device found, idVendor=0781, idProduct=5581, bcdDevice= 1.00
[ 34.597098] usb 6-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 34.604430] usb 6-1.1: Product: Ultra
[ 34.608110] usb 6-1.1: Manufacturer: SanDisk
[ 34.612397] usb 6-1.1: SerialNumber: 4C530001110208116550
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Hardik Gajjar <hgajjar@de.adit-jv.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/1580989763-32291-1-git-send-email-hgajjar@de.adit-jv.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-02-06 19:49:23 +08:00
|
|
|
}
|
|
|
|
|
2023-12-06 02:18:29 +08:00
|
|
|
if ((id->driver_info & HUB_QUIRK_REDUCE_FRAME_INTR_BINTERVAL) &&
|
|
|
|
desc->endpoint[0].desc.bInterval > USB_REDUCE_FRAME_INTR_BINTERVAL) {
|
|
|
|
desc->endpoint[0].desc.bInterval =
|
|
|
|
USB_REDUCE_FRAME_INTR_BINTERVAL;
|
|
|
|
/* Tell the HCD about the interrupt ep's new bInterval */
|
|
|
|
usb_set_interface(hdev, 0, 0);
|
|
|
|
}
|
|
|
|
|
2022-07-01 03:35:30 +08:00
|
|
|
if (hub_configure(hub, &desc->endpoint[0].desc) >= 0) {
|
2024-03-25 17:15:12 +08:00
|
|
|
onboard_dev_create_pdevs(hdev, &hub->onboard_devs);
|
2022-07-01 03:35:30 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
return 0;
|
2022-07-01 03:35:30 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
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
|
|
|
}
|
|
|
|
|
2023-06-08 09:59:12 +08:00
|
|
|
static void update_port_device_state(struct usb_device *udev)
|
|
|
|
{
|
|
|
|
struct usb_hub *hub;
|
|
|
|
struct usb_port *port_dev;
|
|
|
|
|
|
|
|
if (udev->parent) {
|
|
|
|
hub = usb_hub_to_struct_hub(udev->parent);
|
2024-01-10 17:58:14 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The Link Layer Validation System Driver (lvstest)
|
|
|
|
* has a test step to unbind the hub before running the
|
|
|
|
* rest of the procedure. This triggers hub_disconnect
|
|
|
|
* which will set the hub's maxchild to 0, further
|
|
|
|
* resulting in usb_hub_to_struct_hub returning NULL.
|
|
|
|
*/
|
|
|
|
if (hub) {
|
|
|
|
port_dev = hub->ports[udev->portnum - 1];
|
|
|
|
WRITE_ONCE(port_dev->state, udev->state);
|
|
|
|
sysfs_notify_dirent(port_dev->state_kn);
|
|
|
|
}
|
2023-06-08 09:59:12 +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;
|
2023-06-08 09:59:12 +08:00
|
|
|
update_port_device_state(udev);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* 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;
|
2023-06-08 09:59:12 +08:00
|
|
|
update_port_device_state(udev);
|
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.
|
|
|
|
*
|
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);
|
2023-08-09 08:44:18 +08:00
|
|
|
|
|
|
|
/* Try to allocate the next devnum beginning at bus->devnum_next. */
|
2024-05-04 17:47:05 +08:00
|
|
|
devnum = find_next_zero_bit(bus->devmap, 128, bus->devnum_next);
|
2023-08-09 08:44:18 +08:00
|
|
|
if (devnum >= 128)
|
2024-05-04 17:47:05 +08:00
|
|
|
devnum = find_next_zero_bit(bus->devmap, 128, 1);
|
2023-08-09 08:44:18 +08:00
|
|
|
bus->devnum_next = (devnum >= 127 ? 1 : devnum + 1);
|
2005-04-17 06:20:36 +08:00
|
|
|
if (devnum < 128) {
|
2024-05-04 17:47:05 +08:00
|
|
|
set_bit(devnum, bus->devmap);
|
2005-04-17 06:20:36 +08:00
|
|
|
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) {
|
2024-05-04 17:47:05 +08:00
|
|
|
clear_bit(udev->devnum, udev->bus->devmap);
|
2005-04-17 06:20:36 +08:00
|
|
|
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
|
|
|
{
|
2023-08-09 08:44:18 +08:00
|
|
|
udev->devnum = devnum;
|
2019-06-03 18:53:43 +08:00
|
|
|
if (!udev->devaddr)
|
|
|
|
udev->devaddr = (u8)devnum;
|
2008-04-09 04:24:46 +08:00
|
|
|
}
|
|
|
|
|
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
|
2020-10-19 18:06:41 +08:00
|
|
|
*
|
|
|
|
* Context: task context, might sleep
|
2005-04-17 06:20:36 +08:00
|
|
|
*
|
|
|
|
* 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
|
|
|
|
2017-03-21 05:30:50 +08:00
|
|
|
/*
|
|
|
|
* Ensure that the pm runtime code knows that the USB device
|
|
|
|
* is in the process of being disconnected.
|
|
|
|
*/
|
|
|
|
pm_runtime_barrier(&udev->dev);
|
|
|
|
|
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);
|
2023-10-11 18:58:25 +08:00
|
|
|
|
|
|
|
typec_deattach(port_dev->connector, &udev->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)
|
|
|
|
{
|
2018-03-25 01:40:27 +08:00
|
|
|
u16 bcdDevice = le16_to_cpu(udev->descriptor.bcdDevice);
|
|
|
|
|
|
|
|
dev_info(&udev->dev,
|
|
|
|
"New USB device found, idVendor=%04x, idProduct=%04x, bcdDevice=%2x.%02x\n",
|
2007-11-27 14:11:55 +08:00
|
|
|
le16_to_cpu(udev->descriptor.idVendor),
|
2018-03-25 01:40:27 +08:00
|
|
|
le16_to_cpu(udev->descriptor.idProduct),
|
|
|
|
bcdDevice >> 8, bcdDevice & 0xff);
|
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),
|
2018-12-06 04:19:59 +08:00
|
|
|
USB_DT_OTG, (void **) &desc, sizeof(*desc));
|
2015-08-31 16:20:49 +08:00
|
|
|
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;
|
2020-09-23 21:43:35 +08:00
|
|
|
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) {
|
2015-08-31 16:20:49 +08:00
|
|
|
/*
|
|
|
|
* 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)) {
|
2024-01-22 23:35:32 +08:00
|
|
|
/*
|
|
|
|
* We are operating on a legacy OTP device
|
|
|
|
* These should be told that they are operating
|
|
|
|
* on the wrong port if we have another port that does
|
|
|
|
* support HNP
|
|
|
|
*/
|
|
|
|
if (bus->otg_port != 0) {
|
|
|
|
/* 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)
|
|
|
|
*
|
2023-02-01 04:49:04 +08:00
|
|
|
* This is only called by usb_new_device() -- all comments that apply there
|
|
|
|
* apply here wrt to environment.
|
2007-08-01 11:34:05 +08:00
|
|
|
*
|
|
|
|
* 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;
|
|
|
|
|
2020-06-18 17:43:00 +08:00
|
|
|
if (IS_ENABLED(CONFIG_USB_OTG_PRODUCTLIST) && 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;
|
|
|
|
|
2021-05-25 01:18:11 +08:00
|
|
|
dev_set_removable(&udev->dev, DEVICE_REMOVABLE_UNKNOWN);
|
|
|
|
|
2012-02-04 06:11:55 +08:00
|
|
|
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:
|
2021-05-25 01:18:11 +08:00
|
|
|
dev_set_removable(&udev->dev, DEVICE_REMOVABLE);
|
2015-04-09 07:36:00 +08:00
|
|
|
return;
|
|
|
|
case USB_PORT_CONNECT_TYPE_HARD_WIRED:
|
2015-04-09 07:36:01 +08:00
|
|
|
case USB_PORT_NOT_USED:
|
2021-05-25 01:18:11 +08:00
|
|
|
dev_set_removable(&udev->dev, DEVICE_FIXED);
|
2015-04-09 07:36:00 +08:00
|
|
|
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)
|
2021-05-25 01:18:11 +08:00
|
|
|
dev_set_removable(&udev->dev, DEVICE_REMOVABLE);
|
2012-02-04 06:11:55 +08:00
|
|
|
else
|
2021-05-25 01:18:11 +08:00
|
|
|
dev_set_removable(&udev->dev, 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 */
|
2021-05-25 01:18:11 +08:00
|
|
|
set_usb_port_removable(udev);
|
2012-02-04 06:11:55 +08:00
|
|
|
|
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);
|
2023-10-11 18:58:25 +08:00
|
|
|
|
|
|
|
typec_attach(port_dev->connector, &udev->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
|
|
|
|
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
|
|
|
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2021-03-11 11:42:44 +08:00
|
|
|
/**
|
|
|
|
* get_port_ssp_rate - Match the extended port status to SSP rate
|
|
|
|
* @hdev: The hub device
|
|
|
|
* @ext_portstatus: extended port status
|
|
|
|
*
|
|
|
|
* Match the extended port status speed id to the SuperSpeed Plus sublink speed
|
|
|
|
* capability attributes. Base on the number of connected lanes and speed,
|
|
|
|
* return the corresponding enum usb_ssp_rate.
|
|
|
|
*/
|
|
|
|
static enum usb_ssp_rate get_port_ssp_rate(struct usb_device *hdev,
|
|
|
|
u32 ext_portstatus)
|
|
|
|
{
|
2023-08-30 18:04:18 +08:00
|
|
|
struct usb_ssp_cap_descriptor *ssp_cap;
|
2021-03-11 11:42:44 +08:00
|
|
|
u32 attr;
|
|
|
|
u8 speed_id;
|
|
|
|
u8 ssac;
|
|
|
|
u8 lanes;
|
|
|
|
int i;
|
|
|
|
|
2023-08-30 18:04:18 +08:00
|
|
|
if (!hdev->bos)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
ssp_cap = hdev->bos->ssp_cap;
|
2021-03-11 11:42:44 +08:00
|
|
|
if (!ssp_cap)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
speed_id = ext_portstatus & USB_EXT_PORT_STAT_RX_SPEED_ID;
|
|
|
|
lanes = USB_EXT_PORT_RX_LANES(ext_portstatus) + 1;
|
|
|
|
|
|
|
|
ssac = le32_to_cpu(ssp_cap->bmAttributes) &
|
|
|
|
USB_SSP_SUBLINK_SPEED_ATTRIBS;
|
|
|
|
|
|
|
|
for (i = 0; i <= ssac; i++) {
|
|
|
|
u8 ssid;
|
|
|
|
|
|
|
|
attr = le32_to_cpu(ssp_cap->bmSublinkSpeedAttr[i]);
|
|
|
|
ssid = FIELD_GET(USB_SSP_SUBLINK_SPEED_SSID, attr);
|
|
|
|
if (speed_id == ssid) {
|
|
|
|
u16 mantissa;
|
|
|
|
u8 lse;
|
|
|
|
u8 type;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Note: currently asymmetric lane types are only
|
|
|
|
* applicable for SSIC operate in SuperSpeed protocol
|
|
|
|
*/
|
|
|
|
type = FIELD_GET(USB_SSP_SUBLINK_SPEED_ST, attr);
|
|
|
|
if (type == USB_SSP_SUBLINK_SPEED_ST_ASYM_RX ||
|
|
|
|
type == USB_SSP_SUBLINK_SPEED_ST_ASYM_TX)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
if (FIELD_GET(USB_SSP_SUBLINK_SPEED_LP, attr) !=
|
|
|
|
USB_SSP_SUBLINK_SPEED_LP_SSP)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
lse = FIELD_GET(USB_SSP_SUBLINK_SPEED_LSE, attr);
|
|
|
|
mantissa = FIELD_GET(USB_SSP_SUBLINK_SPEED_LSM, attr);
|
|
|
|
|
|
|
|
/* Convert to Gbps */
|
|
|
|
for (; lse < USB_SSP_SUBLINK_SPEED_LSE_GBPS; lse++)
|
|
|
|
mantissa /= 1000;
|
|
|
|
|
|
|
|
if (mantissa >= 10 && lanes == 1)
|
|
|
|
return USB_SSP_GEN_2x1;
|
|
|
|
|
|
|
|
if (mantissa >= 10 && lanes == 2)
|
|
|
|
return USB_SSP_GEN_2x2;
|
|
|
|
|
|
|
|
if (mantissa >= 5 && lanes == 2)
|
|
|
|
return USB_SSP_GEN_1x2;
|
|
|
|
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
out:
|
|
|
|
return USB_SSP_GEN_UNKNOWN;
|
|
|
|
}
|
|
|
|
|
2020-09-28 23:22:17 +08:00
|
|
|
#ifdef CONFIG_USB_FEW_INIT_RETRIES
|
|
|
|
#define PORT_RESET_TRIES 2
|
|
|
|
#define SET_ADDRESS_TRIES 1
|
|
|
|
#define GET_DESCRIPTOR_TRIES 1
|
|
|
|
#define GET_MAXPACKET0_TRIES 1
|
|
|
|
#define PORT_INIT_TRIES 4
|
|
|
|
|
|
|
|
#else
|
2005-04-17 06:20:36 +08:00
|
|
|
#define PORT_RESET_TRIES 5
|
|
|
|
#define SET_ADDRESS_TRIES 2
|
|
|
|
#define GET_DESCRIPTOR_TRIES 2
|
2020-09-28 23:22:17 +08:00
|
|
|
#define GET_MAXPACKET0_TRIES 3
|
2020-09-28 23:20:50 +08:00
|
|
|
#define PORT_INIT_TRIES 4
|
2020-09-28 23:22:17 +08:00
|
|
|
#endif /* CONFIG_USB_FEW_INIT_RETRIES */
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2021-12-10 19:16:53 +08:00
|
|
|
#define DETECT_DISCONNECT_TRIES 5
|
|
|
|
|
2017-08-16 19:23:25 +08:00
|
|
|
#define HUB_ROOT_RESET_TIME 60 /* times are in msec */
|
2005-04-17 06:20:36 +08:00
|
|
|
#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
|
|
|
|
2018-05-28 14:32:18 +08:00
|
|
|
static bool use_new_scheme(struct usb_device *udev, int retry,
|
|
|
|
struct usb_port *port_dev)
|
2013-12-06 09:07:27 +08:00
|
|
|
{
|
2018-05-28 14:32:18 +08:00
|
|
|
int old_scheme_first_port =
|
2020-09-28 23:20:50 +08:00
|
|
|
(port_dev->quirks & USB_PORT_QUIRK_OLD_SCHEME) ||
|
|
|
|
old_scheme_first;
|
2018-05-28 14:32:18 +08:00
|
|
|
|
2020-09-28 23:20:50 +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.
|
|
|
|
*/
|
2015-12-10 15:59:25 +08:00
|
|
|
if (udev->speed >= USB_SPEED_SUPER)
|
2013-12-06 09:07:27 +08:00
|
|
|
return false;
|
|
|
|
|
2020-09-28 23:20:50 +08:00
|
|
|
/*
|
|
|
|
* If use_both_schemes is set, use the first scheme (whichever
|
|
|
|
* it is) for the larger half of the retries, then use the other
|
|
|
|
* scheme. Otherwise, use the first scheme for all the retries.
|
|
|
|
*/
|
|
|
|
if (use_both_schemes && retry >= (PORT_INIT_TRIES + 1) / 2)
|
|
|
|
return old_scheme_first_port; /* Second half */
|
|
|
|
return !old_scheme_first_port; /* First half or all */
|
2013-12-06 09:07:27 +08:00
|
|
|
}
|
|
|
|
|
2014-01-04 13:54:41 +08:00
|
|
|
/* Is a USB 3.0 port in the Inactive or Compliance Mode state?
|
2019-06-20 13:58:23 +08:00
|
|
|
* Port warm reset is required to recover
|
2012-06-18 21:20:00 +08:00
|
|
|
*/
|
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
|
2022-06-07 19:45:22 +08:00
|
|
|
ret = usb_hub_port_status(hub, port1, &portstatus,
|
2015-12-10 15:59:29 +08:00
|
|
|
&portchange);
|
2005-04-17 06:20:36 +08:00
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
2016-12-02 05:49:59 +08:00
|
|
|
/*
|
|
|
|
* The port state is unknown until the reset completes.
|
|
|
|
*
|
|
|
|
* On top of that, some chips may require additional time
|
|
|
|
* to re-establish a connection after the reset is complete,
|
|
|
|
* so also wait for the connection to be re-established.
|
|
|
|
*/
|
|
|
|
if (!(portstatus & USB_PORT_STAT_RESET) &&
|
|
|
|
(portstatus & USB_PORT_STAT_CONNECTION))
|
2012-12-12 02:14:03 +08:00
|
|
|
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;
|
|
|
|
|
2017-10-17 21:07:33 +08:00
|
|
|
/* Retry if connect change is set but status is still connected.
|
|
|
|
* A USB 3.0 connection may bounce if multiple warm resets were issued,
|
2012-12-12 02:14:03 +08:00
|
|
|
* but the device may have successfully re-connected. Ignore it.
|
|
|
|
*/
|
|
|
|
if (!hub_is_superspeed(hub->hdev) &&
|
2017-10-17 21:07:33 +08:00
|
|
|
(portchange & USB_PORT_STAT_C_CONNECTION)) {
|
|
|
|
usb_clear_port_feature(hub->hdev, port1,
|
|
|
|
USB_PORT_FEAT_C_CONNECTION);
|
|
|
|
return -EAGAIN;
|
|
|
|
}
|
2012-12-12 02:14:03 +08:00
|
|
|
|
|
|
|
if (!(portstatus & USB_PORT_STAT_ENABLE))
|
|
|
|
return -EBUSY;
|
|
|
|
|
|
|
|
if (!udev)
|
|
|
|
return 0;
|
|
|
|
|
2018-04-20 00:05:51 +08:00
|
|
|
if (hub_is_superspeedplus(hub->hdev)) {
|
|
|
|
/* extended portstatus Rx and Tx lane count are zero based */
|
|
|
|
udev->rx_lanes = USB_EXT_PORT_RX_LANES(ext_portstatus) + 1;
|
|
|
|
udev->tx_lanes = USB_EXT_PORT_TX_LANES(ext_portstatus) + 1;
|
2021-03-11 11:42:44 +08:00
|
|
|
udev->ssp_rate = get_port_ssp_rate(hub->hdev, ext_portstatus);
|
2018-04-20 00:05:51 +08:00
|
|
|
} else {
|
|
|
|
udev->rx_lanes = 1;
|
|
|
|
udev->tx_lanes = 1;
|
2021-03-11 11:42:44 +08:00
|
|
|
udev->ssp_rate = USB_SSP_GEN_UNKNOWN;
|
2018-04-20 00:05:51 +08:00
|
|
|
}
|
2023-08-09 08:44:18 +08:00
|
|
|
if (udev->ssp_rate != USB_SSP_GEN_UNKNOWN)
|
2015-12-10 15:59:29 +08:00
|
|
|
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];
|
2018-10-19 16:14:50 +08:00
|
|
|
int reset_recovery_time;
|
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.
|
|
|
|
*/
|
2022-06-07 19:45:22 +08:00
|
|
|
if (usb_hub_port_status(hub, port1, &portstatus,
|
|
|
|
&portchange) == 0)
|
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_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: core: Bail out when port is stuck in reset loop
Unplugging USB device may cause an incorrect warm reset loop and the
port can no longer be used:
[ 143.039019] xhci_hcd 0000:00:14.0: Port change event, 2-3, id 19, portsc: 0x4202c0
[ 143.039025] xhci_hcd 0000:00:14.0: handle_port_status: starting usb2 port polling.
[ 143.039051] hub 2-0:1.0: state 7 ports 10 chg 0000 evt 0008
[ 143.039058] xhci_hcd 0000:00:14.0: Get port status 2-3 read: 0x4202c0, return 0x4102c0
[ 143.039092] xhci_hcd 0000:00:14.0: clear port3 connect change, portsc: 0x4002c0
[ 143.039096] usb usb2-port3: link state change
[ 143.039099] xhci_hcd 0000:00:14.0: clear port3 link state change, portsc: 0x2c0
[ 143.039101] usb usb2-port3: do warm reset
[ 143.096736] xhci_hcd 0000:00:14.0: Get port status 2-3 read: 0x2b0, return 0x2b0
[ 143.096751] usb usb2-port3: not warm reset yet, waiting 50ms
[ 143.131500] xhci_hcd 0000:00:14.0: Can't queue urb, port error, link inactive
[ 143.138260] xhci_hcd 0000:00:14.0: Port change event, 2-3, id 19, portsc: 0x2802a0
[ 143.138263] xhci_hcd 0000:00:14.0: handle_port_status: starting usb2 port polling.
[ 143.160756] xhci_hcd 0000:00:14.0: Get port status 2-3 read: 0x2802a0, return 0x3002a0
[ 143.160798] usb usb2-port3: not warm reset yet, waiting 200ms
The port status is PP=1, CCS=0, PED=0, PLS=Inactive, which is Error
state per "USB3 Root Hub Port State Machine". It's reasonable to perform
warm reset several times, but if the port is still not enabled after
many attempts, consider it's gone and treat it as disconnected.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Link: https://lore.kernel.org/r/20220120070518.1643873-1-kai.heng.feng@canonical.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-01-20 15:05:16 +08:00
|
|
|
/*
|
|
|
|
* Check for disconnect or reset, and bail out after several
|
|
|
|
* reset attempts to avoid warm reset loop.
|
|
|
|
*/
|
|
|
|
if (status == 0 || status == -ENOTCONN || status == -ENODEV ||
|
|
|
|
(status == -EBUSY && i == PORT_RESET_TRIES - 1)) {
|
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);
|
2018-11-13 21:40:34 +08:00
|
|
|
|
|
|
|
if (udev)
|
|
|
|
usb_clear_port_feature(hub->hdev, port1,
|
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_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.
|
|
|
|
*/
|
2022-06-07 19:45:22 +08:00
|
|
|
if (usb_hub_port_status(hub, port1,
|
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
|
|
|
&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) {
|
2018-05-28 14:32:19 +08:00
|
|
|
if (port_dev->quirks & USB_PORT_QUIRK_FAST_ENUM)
|
|
|
|
usleep_range(10000, 12000);
|
2018-10-19 16:14:50 +08:00
|
|
|
else {
|
|
|
|
/* TRSTRCY = 10 ms; plus some extra */
|
|
|
|
reset_recovery_time = 10 + 40;
|
|
|
|
|
|
|
|
/* Hub needs extra delay after resetting its port. */
|
|
|
|
if (hub->hdev->quirks & USB_QUIRK_HUB_SLOW_RESET)
|
|
|
|
reset_recovery_time += 100;
|
|
|
|
|
|
|
|
msleep(reset_recovery_time);
|
|
|
|
}
|
2018-05-28 14:32:19 +08:00
|
|
|
|
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 (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
|
|
|
}
|
|
|
|
|
2022-11-07 15:27:54 +08:00
|
|
|
/*
|
|
|
|
* hub_port_stop_enumerate - stop USB enumeration or ignore port events
|
|
|
|
* @hub: target hub
|
|
|
|
* @port1: port num of the port
|
|
|
|
* @retries: port retries number of hub_port_init()
|
|
|
|
*
|
|
|
|
* Return:
|
|
|
|
* true: ignore port actions/events or give up connection attempts.
|
|
|
|
* false: keep original behavior.
|
|
|
|
*
|
|
|
|
* This function will be based on retries to check whether the port which is
|
|
|
|
* marked with early_stop attribute would stop enumeration or ignore events.
|
|
|
|
*
|
|
|
|
* Note:
|
|
|
|
* This function didn't change anything if early_stop is not set, and it will
|
|
|
|
* prevent all connection attempts when early_stop is set and the attempts of
|
|
|
|
* the port are more than 1.
|
|
|
|
*/
|
|
|
|
static bool hub_port_stop_enumerate(struct usb_hub *hub, int port1, int retries)
|
|
|
|
{
|
|
|
|
struct usb_port *port_dev = hub->ports[port1 - 1];
|
|
|
|
|
|
|
|
if (port_dev->early_stop) {
|
|
|
|
if (port_dev->ignore_event)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We want unsuccessful attempts to fail quickly.
|
|
|
|
* Since some devices may need one failure during
|
|
|
|
* port initialization, we allow two tries but no
|
|
|
|
* more.
|
|
|
|
*/
|
|
|
|
if (retries < 2)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
port_dev->ignore_event = 1;
|
|
|
|
} else
|
|
|
|
port_dev->ignore_event = 0;
|
|
|
|
|
|
|
|
return port_dev->ignore_event;
|
|
|
|
}
|
|
|
|
|
2011-04-27 18:07:43 +08:00
|
|
|
/* Check if a port is power on */
|
2022-06-07 19:45:22 +08:00
|
|
|
int usb_port_is_power_on(struct usb_hub *hub, unsigned int portstatus)
|
2011-04-27 18:07:43 +08:00
|
|
|
{
|
|
|
|
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) ||
|
2022-06-07 19:45:22 +08:00
|
|
|
!usb_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);
|
2022-06-07 19:45:22 +08:00
|
|
|
status = usb_hub_port_status(hub, port1, &portstatus,
|
2015-01-28 05:20:12 +08:00
|
|
|
&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);
|
2020-04-23 04:09:51 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Whatever made this reset-resume necessary may have
|
|
|
|
* turned on the port1 bit in hub->change_bits. But after
|
|
|
|
* a successful reset-resume we want the bit to be clear;
|
|
|
|
* if it was on it would indicate that something happened
|
|
|
|
* following the reset-resume.
|
|
|
|
*/
|
|
|
|
clear_bit(port1, hub->change_bits);
|
2008-04-28 23:06:11 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
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;
|
|
|
|
|
2020-09-23 21:43:35 +08:00
|
|
|
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);
|
2012-06-26 03:08:08 +08:00
|
|
|
}
|
|
|
|
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;
|
|
|
|
|
2020-09-23 21:43:35 +08:00
|
|
|
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);
|
2012-06-26 03:08:08 +08:00
|
|
|
}
|
|
|
|
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)
|
2020-09-23 21:43:35 +08:00
|
|
|
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);
|
2013-07-31 03:37:33 +08:00
|
|
|
else
|
2020-09-23 21:43:35 +08:00
|
|
|
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);
|
2013-07-31 03:37:33 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 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)
|
2020-09-23 21:43:35 +08:00
|
|
|
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);
|
2013-07-31 03:37:33 +08:00
|
|
|
else
|
2020-09-23 21:43:35 +08:00
|
|
|
return usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
|
|
|
|
USB_REQ_SET_FEATURE, USB_RECIP_INTERFACE,
|
|
|
|
USB_INTRF_FUNC_SUSPEND, 0, NULL, 0,
|
|
|
|
USB_CTRL_SET_TIMEOUT);
|
2013-01-24 10:31:28 +08:00
|
|
|
}
|
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 */
|
2019-04-18 08:13:53 +08:00
|
|
|
unsigned usb_wakeup_enabled_descendants(struct usb_device *udev)
|
2013-07-12 02:58:04 +08:00
|
|
|
{
|
|
|
|
struct usb_hub *hub = usb_hub_to_struct_hub(udev);
|
|
|
|
|
|
|
|
return udev->do_remote_wakeup +
|
|
|
|
(hub ? hub->wakeup_enabled_descendants : 0);
|
|
|
|
}
|
2019-04-18 08:13:53 +08:00
|
|
|
EXPORT_SYMBOL_GPL(usb_wakeup_enabled_descendants);
|
2013-07-12 02:58:04 +08:00
|
|
|
|
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 */
|
2019-01-12 03:54:25 +08:00
|
|
|
usb_disable_usb2_hardware_lpm(udev);
|
2011-09-24 05:19:52 +08:00
|
|
|
|
2012-06-26 03:08:08 +08:00
|
|
|
if (usb_disable_ltm(udev)) {
|
2017-12-06 14:22:05 +08:00
|
|
|
dev_err(&udev->dev, "Failed to disable LTM before suspend\n");
|
2013-07-31 03:39:02 +08:00
|
|
|
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
|
|
|
|
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
|
|
|
*/
|
2019-04-18 08:13:53 +08:00
|
|
|
else if (PMSG_IS_AUTO(msg) || usb_wakeup_enabled_descendants(udev) > 0)
|
2013-07-12 02:58:04 +08:00
|
|
|
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) {
|
2021-05-14 12:54:04 +08:00
|
|
|
/* Check if the port has been suspended for the timeout case
|
|
|
|
* to prevent the suspended port from incorrect handling.
|
|
|
|
*/
|
|
|
|
if (status == -ETIMEDOUT) {
|
|
|
|
int ret;
|
|
|
|
u16 portstatus, portchange;
|
|
|
|
|
|
|
|
portstatus = portchange = 0;
|
2022-06-07 19:45:22 +08:00
|
|
|
ret = usb_hub_port_status(hub, port1, &portstatus,
|
2021-05-14 12:54:04 +08:00
|
|
|
&portchange);
|
|
|
|
|
|
|
|
dev_dbg(&port_dev->dev,
|
|
|
|
"suspend timeout, status %04x\n", portstatus);
|
|
|
|
|
|
|
|
if (ret == 0 && port_is_suspended(hub, portstatus)) {
|
|
|
|
status = 0;
|
|
|
|
goto suspend_done;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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
|
|
|
|
2017-06-15 16:55:41 +08:00
|
|
|
/* Try to enable USB3 LTM again */
|
2013-07-31 03:39:02 +08:00
|
|
|
usb_enable_ltm(udev);
|
|
|
|
err_ltm:
|
2012-05-05 00:50:10 +08:00
|
|
|
/* Try to enable USB2 hardware LPM again */
|
2019-01-12 03:54:25 +08:00
|
|
|
usb_enable_usb2_hardware_lpm(udev);
|
2012-05-05 00:50:10 +08:00
|
|
|
|
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 {
|
2021-05-14 12:54:04 +08:00
|
|
|
suspend_done:
|
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;
|
2017-11-02 16:57:40 +08:00
|
|
|
status = usb_get_std_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 {
|
2017-11-02 16:57:40 +08:00
|
|
|
status = usb_get_std_status(udev, USB_RECIP_INTERFACE, 0,
|
2013-01-24 10:31:28 +08:00
|
|
|
&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,
|
2021-12-10 22:20:28 +08:00
|
|
|
struct usb_hub *hub, int port1,
|
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
|
|
|
u16 *portchange, u16 *portstatus)
|
|
|
|
{
|
|
|
|
int status = 0, delay_ms = 0;
|
|
|
|
|
|
|
|
while (delay_ms < 2000) {
|
|
|
|
if (status || *portstatus & USB_PORT_STAT_CONNECTION)
|
|
|
|
break;
|
2022-06-07 19:45:22 +08:00
|
|
|
if (!usb_port_is_power_on(hub, *portstatus)) {
|
2018-04-14 01:42:31 +08:00
|
|
|
status = -ENODEV;
|
|
|
|
break;
|
|
|
|
}
|
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
|
|
|
msleep(20);
|
|
|
|
delay_ms += 20;
|
2022-06-07 19:45:22 +08:00
|
|
|
status = usb_hub_port_status(hub, port1, portstatus, 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
|
|
|
}
|
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)) {
|
2021-04-08 21:08:31 +08:00
|
|
|
status = pm_runtime_resume_and_get(&port_dev->dev);
|
2013-01-23 04:26:30 +08:00
|
|
|
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 */
|
2022-06-07 19:45:22 +08:00
|
|
|
status = usb_hub_port_status(hub, port1, &portstatus, &portchange);
|
2018-04-21 02:08:21 +08:00
|
|
|
if (status == 0 && !port_is_suspended(hub, portstatus)) {
|
|
|
|
if (portchange & USB_PORT_STAT_C_SUSPEND)
|
|
|
|
pm_wakeup_event(&udev->dev, 0);
|
2006-11-21 00:14:30 +08:00
|
|
|
goto SuspendCleared;
|
2018-04-21 02:08:21 +08:00
|
|
|
}
|
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.
|
|
|
|
*/
|
2022-06-07 19:45:22 +08:00
|
|
|
status = usb_hub_port_status(hub, port1, &portstatus, &portchange);
|
2008-04-28 23:06:11 +08:00
|
|
|
}
|
|
|
|
|
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);
|
|
|
|
}
|
2021-05-12 10:07:38 +08:00
|
|
|
|
|
|
|
/* TRSMRCY = 10 msec */
|
|
|
|
msleep(10);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2015-12-03 03:55:07 +08:00
|
|
|
if (udev->persist_enabled)
|
2021-12-10 22:20:28 +08:00
|
|
|
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 */
|
2019-01-12 03:54:25 +08:00
|
|
|
usb_enable_usb2_hardware_lpm(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
|
|
|
|
2017-06-15 16:55:41 +08:00
|
|
|
/* Try to enable USB3 LTM */
|
2012-06-26 03:08:08 +08:00
|
|
|
usb_enable_ltm(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;
|
2019-06-20 15:56:04 +08:00
|
|
|
u16 link_state;
|
2014-05-21 09:09:31 +08:00
|
|
|
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 {
|
2019-06-20 15:56:04 +08:00
|
|
|
link_state = portstatus & USB_PORT_STAT_LINK_STATE;
|
2014-05-21 09:09:31 +08:00
|
|
|
if (!udev || udev->state != USB_STATE_SUSPENDED ||
|
2019-06-20 15:56:04 +08:00
|
|
|
(link_state != USB_SS_PORT_LS_U0 &&
|
|
|
|
link_state != USB_SS_PORT_LS_U1 &&
|
|
|
|
link_state != USB_SS_PORT_LS_U2))
|
2014-05-21 09:09:31 +08:00
|
|
|
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;
|
|
|
|
|
2022-06-07 19:45:22 +08:00
|
|
|
status = usb_hub_port_status(hub, port1, &portstatus, &portchange);
|
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 (!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;
|
|
|
|
|
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 +=
|
2019-04-18 08:13:53 +08:00
|
|
|
usb_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++) {
|
2019-03-28 03:40:34 +08:00
|
|
|
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);
|
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
|
|
|
}
|
|
|
|
}
|
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
|
|
|
}
|
|
|
|
|
2018-06-09 04:59:37 +08:00
|
|
|
/* Report wakeup requests from the ports of a resuming root hub */
|
|
|
|
static void report_wakeup_requests(struct usb_hub *hub)
|
|
|
|
{
|
|
|
|
struct usb_device *hdev = hub->hdev;
|
|
|
|
struct usb_device *udev;
|
|
|
|
struct usb_hcd *hcd;
|
|
|
|
unsigned long resuming_ports;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (hdev->parent)
|
|
|
|
return; /* Not a root hub */
|
|
|
|
|
|
|
|
hcd = bus_to_hcd(hdev->bus);
|
|
|
|
if (hcd->driver->get_resuming_ports) {
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The get_resuming_ports() method returns a bitmap (origin 0)
|
|
|
|
* of ports which have started wakeup signaling but have not
|
|
|
|
* yet finished resuming. During system resume we will
|
|
|
|
* resume all the enabled ports, regardless of any wakeup
|
|
|
|
* signals, which means the wakeup requests would be lost.
|
|
|
|
* To prevent this, report them to the PM core here.
|
|
|
|
*/
|
|
|
|
resuming_ports = hcd->driver->get_resuming_ports(hcd);
|
|
|
|
for (i = 0; i < hdev->maxchild; ++i) {
|
|
|
|
if (test_bit(i, &resuming_ports)) {
|
|
|
|
udev = hub->ports[i]->child;
|
|
|
|
if (udev)
|
|
|
|
pm_wakeup_event(&udev->dev, 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);
|
2018-06-09 04:59:37 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* This should be called only for system resume, not runtime resume.
|
|
|
|
* We can't tell the difference here, so some wakeup requests will be
|
|
|
|
* reported at the wrong time or more than once. This shouldn't
|
|
|
|
* matter much, so long as they do get reported.
|
|
|
|
*/
|
|
|
|
report_wakeup_requests(hub);
|
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)
|
|
|
|
{
|
2018-03-22 23:18:32 +08:00
|
|
|
dev_notice(&rhdev->dev, "root hub lost power or was reset\n");
|
2007-05-31 03:38:58 +08:00
|
|
|
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.
|
|
|
|
*/
|
2022-05-07 00:18:07 +08:00
|
|
|
static int usb_req_set_sel(struct usb_device *udev)
|
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
|
|
|
{
|
|
|
|
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;
|
|
|
|
|
2022-05-07 00:18:07 +08:00
|
|
|
if (!udev->parent || udev->speed < USB_SPEED_SUPER || !udev->lpm_capable)
|
2013-09-04 22:24:45 +08:00
|
|
|
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.
|
|
|
|
*/
|
2022-05-07 00:18:07 +08:00
|
|
|
if (u1_sel > USB3_LPM_MAX_U1_SEL_PEL ||
|
|
|
|
u1_pel > USB3_LPM_MAX_U1_SEL_PEL ||
|
|
|
|
u2_sel > USB3_LPM_MAX_U2_SEL_PEL ||
|
|
|
|
u2_pel > USB3_LPM_MAX_U2_SEL_PEL) {
|
|
|
|
dev_dbg(&udev->dev, "Device-initiated U1/U2 disabled due to long SEL or PEL\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
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 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);
|
2022-05-07 00:18:07 +08:00
|
|
|
|
|
|
|
if (ret > 0)
|
|
|
|
udev->lpm_devinit_allow = 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
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2021-07-15 23:01:22 +08:00
|
|
|
/*
|
|
|
|
* Don't allow device intiated U1/U2 if the system exit latency + one bus
|
|
|
|
* interval is greater than the minimum service interval of any active
|
|
|
|
* periodic endpoint. See USB 3.2 section 9.4.9
|
|
|
|
*/
|
|
|
|
static bool usb_device_may_initiate_lpm(struct usb_device *udev,
|
|
|
|
enum usb3_link_state state)
|
|
|
|
{
|
|
|
|
unsigned int sel; /* us */
|
|
|
|
int i, j;
|
|
|
|
|
2022-05-07 00:18:07 +08:00
|
|
|
if (!udev->lpm_devinit_allow)
|
|
|
|
return false;
|
|
|
|
|
2021-07-15 23:01:22 +08:00
|
|
|
if (state == USB3_LPM_U1)
|
|
|
|
sel = DIV_ROUND_UP(udev->u1_params.sel, 1000);
|
|
|
|
else if (state == USB3_LPM_U2)
|
|
|
|
sel = DIV_ROUND_UP(udev->u2_params.sel, 1000);
|
|
|
|
else
|
|
|
|
return false;
|
|
|
|
|
|
|
|
for (i = 0; i < udev->actconfig->desc.bNumInterfaces; i++) {
|
|
|
|
struct usb_interface *intf;
|
|
|
|
struct usb_endpoint_descriptor *desc;
|
|
|
|
unsigned int interval;
|
|
|
|
|
|
|
|
intf = udev->actconfig->interface[i];
|
|
|
|
if (!intf)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
for (j = 0; j < intf->cur_altsetting->desc.bNumEndpoints; j++) {
|
|
|
|
desc = &intf->cur_altsetting->endpoint[j].desc;
|
|
|
|
|
|
|
|
if (usb_endpoint_xfer_int(desc) ||
|
|
|
|
usb_endpoint_xfer_isoc(desc)) {
|
|
|
|
interval = (1 << (desc->bInterval - 1)) * 125;
|
|
|
|
if (sel + 125 > interval)
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
/*
|
|
|
|
* 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.
|
|
|
|
*
|
2019-05-15 05:38:38 +08:00
|
|
|
* If the control transfer to enable device-initiated U1/U2 entry fails, then
|
|
|
|
* hub-initiated U1/U2 will be disabled.
|
|
|
|
*
|
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 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)
|
|
|
|
{
|
2022-05-07 00:18:07 +08:00
|
|
|
int timeout;
|
2023-08-30 18:04:18 +08:00
|
|
|
__u8 u1_mel;
|
|
|
|
__le16 u2_mel;
|
|
|
|
|
|
|
|
/* Skip if the device BOS descriptor couldn't be read */
|
|
|
|
if (!udev->bos)
|
|
|
|
return;
|
|
|
|
|
|
|
|
u1_mel = udev->bos->ss_cap->bU1devExitLat;
|
|
|
|
u2_mel = udev->bos->ss_cap->bU2DevExitLat;
|
2012-10-04 02:18:05 +08:00
|
|
|
|
|
|
|
/* 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
|
|
|
|
|
|
|
/* 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);
|
2019-05-15 05:38:38 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Only a configured device will accept the Set Feature
|
|
|
|
* U1/U2_ENABLE
|
|
|
|
*/
|
|
|
|
if (udev->actconfig &&
|
2021-07-15 23:01:22 +08:00
|
|
|
usb_device_may_initiate_lpm(udev, state)) {
|
|
|
|
if (usb_set_device_initiated_lpm(udev, state, true)) {
|
|
|
|
/*
|
|
|
|
* Request to enable device initiated U1/U2 failed,
|
|
|
|
* better to turn off lpm in this case.
|
|
|
|
*/
|
|
|
|
usb_set_lpm_timeout(udev, state, 0);
|
|
|
|
hcd->driver->disable_usb3_lpm_timeout(hcd, udev, state);
|
|
|
|
return;
|
|
|
|
}
|
2015-11-14 16:26:32 +08:00
|
|
|
}
|
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
|
|
|
|
2021-07-15 23:01:22 +08:00
|
|
|
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 ||
|
2019-05-15 05:38:31 +08:00
|
|
|
udev->state < USB_STATE_CONFIGURED)
|
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 ||
|
2019-05-15 05:38:31 +08:00
|
|
|
udev->state < USB_STATE_CONFIGURED)
|
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);
|
|
|
|
|
2016-11-17 17:14:14 +08:00
|
|
|
/* usb3 devices use U3 for disabled, make sure remote wakeup is disabled */
|
|
|
|
static void hub_usb3_port_prepare_disable(struct usb_hub *hub,
|
|
|
|
struct usb_port *port_dev)
|
|
|
|
{
|
|
|
|
struct usb_device *udev = port_dev->child;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (udev && udev->port_is_suspended && udev->do_remote_wakeup) {
|
|
|
|
ret = hub_set_port_link_state(hub, port_dev->portnum,
|
|
|
|
USB_SS_PORT_LS_U0);
|
|
|
|
if (!ret) {
|
|
|
|
msleep(USB_RESUME_TIMEOUT);
|
|
|
|
ret = usb_disable_remote_wakeup(udev);
|
|
|
|
}
|
|
|
|
if (ret)
|
|
|
|
dev_warn(&udev->dev,
|
|
|
|
"Port disable: can't disable remote wake\n");
|
|
|
|
udev->do_remote_wakeup = 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
|
|
|
|
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
|
|
|
|
2016-11-17 17:14:14 +08:00
|
|
|
static inline void hub_usb3_port_prepare_disable(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
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2022-05-07 00:18:07 +08:00
|
|
|
static int usb_req_set_sel(struct usb_device *udev)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-07-12 02:58:23 +08:00
|
|
|
#endif /* CONFIG_PM */
|
2006-07-02 10:14:24 +08:00
|
|
|
|
2016-12-14 22:37:30 +08:00
|
|
|
/*
|
|
|
|
* USB-3 does not have a similar link state as USB-2 that will avoid negotiating
|
|
|
|
* a connection with a plugged-in cable but will signal the host when the cable
|
|
|
|
* is unplugged. Disable remote wake and set link state to U3 for USB-3 devices
|
|
|
|
*/
|
|
|
|
static int hub_port_disable(struct usb_hub *hub, int port1, int set_state)
|
|
|
|
{
|
|
|
|
struct usb_port *port_dev = hub->ports[port1 - 1];
|
|
|
|
struct usb_device *hdev = hub->hdev;
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
if (!hub->error) {
|
|
|
|
if (hub_is_superspeed(hub->hdev)) {
|
|
|
|
hub_usb3_port_prepare_disable(hub, port_dev);
|
|
|
|
ret = hub_set_port_link_state(hub, port_dev->portnum,
|
|
|
|
USB_SS_PORT_LS_U3);
|
|
|
|
} else {
|
|
|
|
ret = usb_clear_port_feature(hdev, port1,
|
|
|
|
USB_PORT_FEAT_ENABLE);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (port_dev->child && set_state)
|
|
|
|
usb_set_device_state(port_dev->child, USB_STATE_NOTATTACHED);
|
|
|
|
if (ret && ret != -ENODEV)
|
|
|
|
dev_err(&port_dev->dev, "cannot disable (err = %d)\n", ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2017-10-18 15:15:01 +08:00
|
|
|
/*
|
|
|
|
* usb_port_disable - disable a usb device's upstream port
|
|
|
|
* @udev: device to disable
|
|
|
|
* Context: @udev locked, must be able to sleep.
|
|
|
|
*
|
|
|
|
* Disables a USB device that isn't in active use.
|
|
|
|
*/
|
|
|
|
int usb_port_disable(struct usb_device *udev)
|
|
|
|
{
|
|
|
|
struct usb_hub *hub = usb_hub_to_struct_hub(udev->parent);
|
|
|
|
|
|
|
|
return hub_port_disable(hub, udev->portnum, 0);
|
|
|
|
}
|
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) {
|
2022-06-07 19:45:22 +08:00
|
|
|
ret = usb_hub_port_status(hub, port1, &portstatus, &portchange);
|
2005-04-17 06:20:36 +08:00
|
|
|
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;
|
usb: new quirk to reduce the SET_ADDRESS request timeout
This patch introduces a new USB quirk,
USB_QUIRK_SHORT_SET_ADDRESS_REQ_TIMEOUT, which modifies the timeout value
for the SET_ADDRESS request. The standard timeout for USB request/command
is 5000 ms, as recommended in the USB 3.2 specification (section 9.2.6.1).
However, certain scenarios, such as connecting devices through an APTIV
hub, can lead to timeout errors when the device enumerates as full speed
initially and later switches to high speed during chirp negotiation.
In such cases, USB analyzer logs reveal that the bus suspends for
5 seconds due to incorrect chirp parsing and resumes only after two
consecutive timeout errors trigger a hub driver reset.
Packet(54) Dir(?) Full Speed J(997.100 us) Idle( 2.850 us)
_______| Time Stamp(28 . 105 910 682)
_______|_____________________________________________________________Ch0
Packet(55) Dir(?) Full Speed J(997.118 us) Idle( 2.850 us)
_______| Time Stamp(28 . 106 910 632)
_______|_____________________________________________________________Ch0
Packet(56) Dir(?) Full Speed J(399.650 us) Idle(222.582 us)
_______| Time Stamp(28 . 107 910 600)
_______|_____________________________________________________________Ch0
Packet(57) Dir Chirp J( 23.955 ms) Idle(115.169 ms)
_______| Time Stamp(28 . 108 532 832)
_______|_____________________________________________________________Ch0
Packet(58) Dir(?) Full Speed J (Suspend)( 5.347 sec) Idle( 5.366 us)
_______| Time Stamp(28 . 247 657 600)
_______|_____________________________________________________________Ch0
This 5-second delay in device enumeration is undesirable, particularly
in automotive applications where quick enumeration is crucial
(ideally within 3 seconds).
The newly introduced quirks provide the flexibility to align with a
3-second time limit, as required in specific contexts like automotive
applications.
By reducing the SET_ADDRESS request timeout to 500 ms, the
system can respond more swiftly to errors, initiate rapid recovery, and
ensure efficient device enumeration. This change is vital for scenarios
where rapid smartphone enumeration and screen projection are essential.
To use the quirk, please write "vendor_id:product_id:p" to
/sys/bus/usb/drivers/hub/module/parameter/quirks
For example,
echo "0x2c48:0x0132:p" > /sys/bus/usb/drivers/hub/module/parameters/quirks"
Signed-off-by: Hardik Gajjar <hgajjar@de.adit-jv.com>
Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20231027152029.104363-2-hgajjar@de.adit-jv.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-10-27 23:20:29 +08:00
|
|
|
unsigned int timeout_ms = USB_CTRL_SET_TIMEOUT;
|
2009-04-28 10:57:26 +08:00
|
|
|
struct usb_hcd *hcd = bus_to_hcd(udev->bus);
|
usb: new quirk to reduce the SET_ADDRESS request timeout
This patch introduces a new USB quirk,
USB_QUIRK_SHORT_SET_ADDRESS_REQ_TIMEOUT, which modifies the timeout value
for the SET_ADDRESS request. The standard timeout for USB request/command
is 5000 ms, as recommended in the USB 3.2 specification (section 9.2.6.1).
However, certain scenarios, such as connecting devices through an APTIV
hub, can lead to timeout errors when the device enumerates as full speed
initially and later switches to high speed during chirp negotiation.
In such cases, USB analyzer logs reveal that the bus suspends for
5 seconds due to incorrect chirp parsing and resumes only after two
consecutive timeout errors trigger a hub driver reset.
Packet(54) Dir(?) Full Speed J(997.100 us) Idle( 2.850 us)
_______| Time Stamp(28 . 105 910 682)
_______|_____________________________________________________________Ch0
Packet(55) Dir(?) Full Speed J(997.118 us) Idle( 2.850 us)
_______| Time Stamp(28 . 106 910 632)
_______|_____________________________________________________________Ch0
Packet(56) Dir(?) Full Speed J(399.650 us) Idle(222.582 us)
_______| Time Stamp(28 . 107 910 600)
_______|_____________________________________________________________Ch0
Packet(57) Dir Chirp J( 23.955 ms) Idle(115.169 ms)
_______| Time Stamp(28 . 108 532 832)
_______|_____________________________________________________________Ch0
Packet(58) Dir(?) Full Speed J (Suspend)( 5.347 sec) Idle( 5.366 us)
_______| Time Stamp(28 . 247 657 600)
_______|_____________________________________________________________Ch0
This 5-second delay in device enumeration is undesirable, particularly
in automotive applications where quick enumeration is crucial
(ideally within 3 seconds).
The newly introduced quirks provide the flexibility to align with a
3-second time limit, as required in specific contexts like automotive
applications.
By reducing the SET_ADDRESS request timeout to 500 ms, the
system can respond more swiftly to errors, initiate rapid recovery, and
ensure efficient device enumeration. This change is vital for scenarios
where rapid smartphone enumeration and screen projection are essential.
To use the quirk, please write "vendor_id:product_id:p" to
/sys/bus/usb/drivers/hub/module/parameter/quirks
For example,
echo "0x2c48:0x0132:p" > /sys/bus/usb/drivers/hub/module/parameters/quirks"
Signed-off-by: Hardik Gajjar <hgajjar@de.adit-jv.com>
Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20231027152029.104363-2-hgajjar@de.adit-jv.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-10-27 23:20:29 +08:00
|
|
|
struct usb_hub *hub = usb_hub_to_struct_hub(udev->parent);
|
|
|
|
|
|
|
|
if (hub->hdev->quirks & USB_QUIRK_SHORT_SET_ADDRESS_REQ_TIMEOUT)
|
|
|
|
timeout_ms = USB_SHORT_SET_ADDRESS_REQ_TIMEOUT;
|
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)
|
usb: new quirk to reduce the SET_ADDRESS request timeout
This patch introduces a new USB quirk,
USB_QUIRK_SHORT_SET_ADDRESS_REQ_TIMEOUT, which modifies the timeout value
for the SET_ADDRESS request. The standard timeout for USB request/command
is 5000 ms, as recommended in the USB 3.2 specification (section 9.2.6.1).
However, certain scenarios, such as connecting devices through an APTIV
hub, can lead to timeout errors when the device enumerates as full speed
initially and later switches to high speed during chirp negotiation.
In such cases, USB analyzer logs reveal that the bus suspends for
5 seconds due to incorrect chirp parsing and resumes only after two
consecutive timeout errors trigger a hub driver reset.
Packet(54) Dir(?) Full Speed J(997.100 us) Idle( 2.850 us)
_______| Time Stamp(28 . 105 910 682)
_______|_____________________________________________________________Ch0
Packet(55) Dir(?) Full Speed J(997.118 us) Idle( 2.850 us)
_______| Time Stamp(28 . 106 910 632)
_______|_____________________________________________________________Ch0
Packet(56) Dir(?) Full Speed J(399.650 us) Idle(222.582 us)
_______| Time Stamp(28 . 107 910 600)
_______|_____________________________________________________________Ch0
Packet(57) Dir Chirp J( 23.955 ms) Idle(115.169 ms)
_______| Time Stamp(28 . 108 532 832)
_______|_____________________________________________________________Ch0
Packet(58) Dir(?) Full Speed J (Suspend)( 5.347 sec) Idle( 5.366 us)
_______| Time Stamp(28 . 247 657 600)
_______|_____________________________________________________________Ch0
This 5-second delay in device enumeration is undesirable, particularly
in automotive applications where quick enumeration is crucial
(ideally within 3 seconds).
The newly introduced quirks provide the flexibility to align with a
3-second time limit, as required in specific contexts like automotive
applications.
By reducing the SET_ADDRESS request timeout to 500 ms, the
system can respond more swiftly to errors, initiate rapid recovery, and
ensure efficient device enumeration. This change is vital for scenarios
where rapid smartphone enumeration and screen projection are essential.
To use the quirk, please write "vendor_id:product_id:p" to
/sys/bus/usb/drivers/hub/module/parameter/quirks
For example,
echo "0x2c48:0x0132:p" > /sys/bus/usb/drivers/hub/module/parameters/quirks"
Signed-off-by: Hardik Gajjar <hgajjar@de.adit-jv.com>
Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20231027152029.104363-2-hgajjar@de.adit-jv.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-10-27 23:20:29 +08:00
|
|
|
retval = hcd->driver->address_device(hcd, udev, timeout_ms);
|
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,
|
usb: new quirk to reduce the SET_ADDRESS request timeout
This patch introduces a new USB quirk,
USB_QUIRK_SHORT_SET_ADDRESS_REQ_TIMEOUT, which modifies the timeout value
for the SET_ADDRESS request. The standard timeout for USB request/command
is 5000 ms, as recommended in the USB 3.2 specification (section 9.2.6.1).
However, certain scenarios, such as connecting devices through an APTIV
hub, can lead to timeout errors when the device enumerates as full speed
initially and later switches to high speed during chirp negotiation.
In such cases, USB analyzer logs reveal that the bus suspends for
5 seconds due to incorrect chirp parsing and resumes only after two
consecutive timeout errors trigger a hub driver reset.
Packet(54) Dir(?) Full Speed J(997.100 us) Idle( 2.850 us)
_______| Time Stamp(28 . 105 910 682)
_______|_____________________________________________________________Ch0
Packet(55) Dir(?) Full Speed J(997.118 us) Idle( 2.850 us)
_______| Time Stamp(28 . 106 910 632)
_______|_____________________________________________________________Ch0
Packet(56) Dir(?) Full Speed J(399.650 us) Idle(222.582 us)
_______| Time Stamp(28 . 107 910 600)
_______|_____________________________________________________________Ch0
Packet(57) Dir Chirp J( 23.955 ms) Idle(115.169 ms)
_______| Time Stamp(28 . 108 532 832)
_______|_____________________________________________________________Ch0
Packet(58) Dir(?) Full Speed J (Suspend)( 5.347 sec) Idle( 5.366 us)
_______| Time Stamp(28 . 247 657 600)
_______|_____________________________________________________________Ch0
This 5-second delay in device enumeration is undesirable, particularly
in automotive applications where quick enumeration is crucial
(ideally within 3 seconds).
The newly introduced quirks provide the flexibility to align with a
3-second time limit, as required in specific contexts like automotive
applications.
By reducing the SET_ADDRESS request timeout to 500 ms, the
system can respond more swiftly to errors, initiate rapid recovery, and
ensure efficient device enumeration. This change is vital for scenarios
where rapid smartphone enumeration and screen projection are essential.
To use the quirk, please write "vendor_id:product_id:p" to
/sys/bus/usb/drivers/hub/module/parameter/quirks
For example,
echo "0x2c48:0x0132:p" > /sys/bus/usb/drivers/hub/module/parameters/quirks"
Signed-off-by: Hardik Gajjar <hgajjar@de.adit-jv.com>
Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20231027152029.104363-2-hgajjar@de.adit-jv.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-10-27 23:20:29 +08:00
|
|
|
NULL, 0, timeout_ms);
|
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
|
|
|
|
2017-03-09 02:19:36 +08:00
|
|
|
if (!udev->usb2_hw_lpm_capable || !udev->bos)
|
2013-09-30 22:26:31 +08:00
|
|
|
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;
|
2019-01-12 03:54:24 +08:00
|
|
|
usb_enable_usb2_hardware_lpm(udev);
|
2013-09-30 22:26:31 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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);
|
|
|
|
}
|
|
|
|
|
USB: core: Unite old scheme and new scheme descriptor reads
In preparation for reworking the usb_get_device_descriptor() routine,
it is desirable to unite the two different code paths responsible for
initially determining endpoint 0's maximum packet size in a newly
discovered USB device. Making this determination presents a
chicken-and-egg sort of problem, in that the only way to learn the
maxpacket value is to get it from the device descriptor retrieved from
the device, but communicating with the device to retrieve a descriptor
requires us to know beforehand the ep0 maxpacket size.
In practice this problem is solved in two different ways, referred to
in hub.c as the "old scheme" and the "new scheme". The old scheme
(which is the approach recommended by the USB-2 spec) involves asking
the device to send just the first eight bytes of its device
descriptor. Such a transfer uses packets containing no more than
eight bytes each, and every USB device must have an ep0 maxpacket size
>= 8, so this should succeed. Since the bMaxPacketSize0 field of the
device descriptor lies within the first eight bytes, this is all we
need.
The new scheme is an imitation of the technique used in an early
Windows USB implementation, giving it the happy advantage of working
with a wide variety of devices (some of them at the time would not
work with the old scheme, although that's probably less true now). It
involves making an initial guess of the ep0 maxpacket size, asking the
device to send up to 64 bytes worth of its device descriptor (which is
only 18 bytes long), and then resetting the device to clear any error
condition that might have resulted from the guess being wrong. The
initial guess is determined by the connection speed; it should be
correct in all cases other than full speed, for which the allowed
values are 8, 16, 32, and 64 (in this case the initial guess is 64).
The reason for this patch is that the old- and new-scheme parts of
hub_port_init() use different code paths, one involving
usb_get_device_descriptor() and one not, for their initial reads of
the device descriptor. Since these reads have essentially the same
purpose and are made under essentially the same circumstances, this is
illogical. It makes more sense to have both of them use a common
subroutine.
This subroutine does basically what the new scheme's code did, because
that approach is more general than the one used by the old scheme. It
only needs to know how many bytes to transfer and whether or not it is
being called for the first iteration of a retry loop (in case of
certain time-out errors). There are two main differences from the
former code:
We initialize the bDescriptorType field of the transfer buffer
to 0 before performing the transfer, to avoid possibly
accessing an uninitialized value afterward.
We read the device descriptor into a temporary buffer rather
than storing it directly into udev->descriptor, which the old
scheme implementation used to do.
Since the whole point of this first read of the device descriptor is
to determine the bMaxPacketSize0 value, that is what the new routine
returns (or an error code). The value is stored in a local variable
rather than in udev->descriptor. As a side effect, this necessitates
moving a section of code that checks the bcdUSB field for SuperSpeed
devices until after the full device descriptor has been retrieved.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Oliver Neukum <oneukum@suse.com>
Link: https://lore.kernel.org/r/495cb5d4-f956-4f4a-a875-1e67e9489510@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-05 03:10:59 +08:00
|
|
|
/*
|
|
|
|
* Get the bMaxPacketSize0 value during initialization by reading the
|
|
|
|
* device's device descriptor. Since we don't already know this value,
|
|
|
|
* the transfer is unsafe and it ignores I/O errors, only testing for
|
|
|
|
* reasonable received values.
|
|
|
|
*
|
|
|
|
* For "old scheme" initialization, size will be 8 so we read just the
|
|
|
|
* start of the device descriptor, which should work okay regardless of
|
|
|
|
* the actual bMaxPacketSize0 value. For "new scheme" initialization,
|
|
|
|
* size will be 64 (and buf will point to a sufficiently large buffer),
|
|
|
|
* which might not be kosher according to the USB spec but it's what
|
|
|
|
* Windows does and what many devices expect.
|
|
|
|
*
|
|
|
|
* Returns: bMaxPacketSize0 or a negative error code.
|
|
|
|
*/
|
|
|
|
static int get_bMaxPacketSize0(struct usb_device *udev,
|
|
|
|
struct usb_device_descriptor *buf, int size, bool first_time)
|
|
|
|
{
|
|
|
|
int i, rc;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Retry on all errors; some devices are flakey.
|
|
|
|
* 255 is for WUSB devices, we actually need to use
|
|
|
|
* 512 (WUSB1.0[4.8.1]).
|
|
|
|
*/
|
|
|
|
for (i = 0; i < GET_MAXPACKET0_TRIES; ++i) {
|
|
|
|
/* Start with invalid values in case the transfer fails */
|
|
|
|
buf->bDescriptorType = buf->bMaxPacketSize0 = 0;
|
|
|
|
rc = usb_control_msg(udev, usb_rcvaddr0pipe(),
|
|
|
|
USB_REQ_GET_DESCRIPTOR, USB_DIR_IN,
|
|
|
|
USB_DT_DEVICE << 8, 0,
|
|
|
|
buf, size,
|
|
|
|
initial_descriptor_timeout);
|
|
|
|
switch (buf->bMaxPacketSize0) {
|
2023-08-12 01:38:46 +08:00
|
|
|
case 8: case 16: case 32: case 64: case 9:
|
USB: core: Unite old scheme and new scheme descriptor reads
In preparation for reworking the usb_get_device_descriptor() routine,
it is desirable to unite the two different code paths responsible for
initially determining endpoint 0's maximum packet size in a newly
discovered USB device. Making this determination presents a
chicken-and-egg sort of problem, in that the only way to learn the
maxpacket value is to get it from the device descriptor retrieved from
the device, but communicating with the device to retrieve a descriptor
requires us to know beforehand the ep0 maxpacket size.
In practice this problem is solved in two different ways, referred to
in hub.c as the "old scheme" and the "new scheme". The old scheme
(which is the approach recommended by the USB-2 spec) involves asking
the device to send just the first eight bytes of its device
descriptor. Such a transfer uses packets containing no more than
eight bytes each, and every USB device must have an ep0 maxpacket size
>= 8, so this should succeed. Since the bMaxPacketSize0 field of the
device descriptor lies within the first eight bytes, this is all we
need.
The new scheme is an imitation of the technique used in an early
Windows USB implementation, giving it the happy advantage of working
with a wide variety of devices (some of them at the time would not
work with the old scheme, although that's probably less true now). It
involves making an initial guess of the ep0 maxpacket size, asking the
device to send up to 64 bytes worth of its device descriptor (which is
only 18 bytes long), and then resetting the device to clear any error
condition that might have resulted from the guess being wrong. The
initial guess is determined by the connection speed; it should be
correct in all cases other than full speed, for which the allowed
values are 8, 16, 32, and 64 (in this case the initial guess is 64).
The reason for this patch is that the old- and new-scheme parts of
hub_port_init() use different code paths, one involving
usb_get_device_descriptor() and one not, for their initial reads of
the device descriptor. Since these reads have essentially the same
purpose and are made under essentially the same circumstances, this is
illogical. It makes more sense to have both of them use a common
subroutine.
This subroutine does basically what the new scheme's code did, because
that approach is more general than the one used by the old scheme. It
only needs to know how many bytes to transfer and whether or not it is
being called for the first iteration of a retry loop (in case of
certain time-out errors). There are two main differences from the
former code:
We initialize the bDescriptorType field of the transfer buffer
to 0 before performing the transfer, to avoid possibly
accessing an uninitialized value afterward.
We read the device descriptor into a temporary buffer rather
than storing it directly into udev->descriptor, which the old
scheme implementation used to do.
Since the whole point of this first read of the device descriptor is
to determine the bMaxPacketSize0 value, that is what the new routine
returns (or an error code). The value is stored in a local variable
rather than in udev->descriptor. As a side effect, this necessitates
moving a section of code that checks the bcdUSB field for SuperSpeed
devices until after the full device descriptor has been retrieved.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Oliver Neukum <oneukum@suse.com>
Link: https://lore.kernel.org/r/495cb5d4-f956-4f4a-a875-1e67e9489510@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-05 03:10:59 +08:00
|
|
|
if (buf->bDescriptorType == USB_DT_DEVICE) {
|
|
|
|
rc = buf->bMaxPacketSize0;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
fallthrough;
|
|
|
|
default:
|
|
|
|
if (rc >= 0)
|
|
|
|
rc = -EPROTO;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Some devices time out if they are powered on
|
|
|
|
* when already connected. They need a second
|
|
|
|
* reset, so return early. But only on the first
|
|
|
|
* attempt, lest we get into a time-out/reset loop.
|
|
|
|
*/
|
|
|
|
if (rc > 0 || (rc == -ETIMEDOUT && first_time &&
|
|
|
|
udev->speed > USB_SPEED_FULL))
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
|
|
|
#define GET_DESCRIPTOR_BUFSIZE 64
|
|
|
|
|
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.
|
USB: core: Fix race by not overwriting udev->descriptor in hub_port_init()
Syzbot reported an out-of-bounds read in sysfs.c:read_descriptors():
BUG: KASAN: slab-out-of-bounds in read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883
Read of size 8 at addr ffff88801e78b8c8 by task udevd/5011
CPU: 0 PID: 5011 Comm: udevd Not tainted 6.4.0-rc6-syzkaller-00195-g40f71e7cd3c6 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106
print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351
print_report mm/kasan/report.c:462 [inline]
kasan_report+0x11c/0x130 mm/kasan/report.c:572
read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883
...
Allocated by task 758:
...
__do_kmalloc_node mm/slab_common.c:966 [inline]
__kmalloc+0x5e/0x190 mm/slab_common.c:979
kmalloc include/linux/slab.h:563 [inline]
kzalloc include/linux/slab.h:680 [inline]
usb_get_configuration+0x1f7/0x5170 drivers/usb/core/config.c:887
usb_enumerate_device drivers/usb/core/hub.c:2407 [inline]
usb_new_device+0x12b0/0x19d0 drivers/usb/core/hub.c:2545
As analyzed by Khazhy Kumykov, the cause of this bug is a race between
read_descriptors() and hub_port_init(): The first routine uses a field
in udev->descriptor, not expecting it to change, while the second
overwrites it.
Prior to commit 45bf39f8df7f ("USB: core: Don't hold device lock while
reading the "descriptors" sysfs file") this race couldn't occur,
because the routines were mutually exclusive thanks to the device
locking. Removing that locking from read_descriptors() exposed it to
the race.
The best way to fix the bug is to keep hub_port_init() from changing
udev->descriptor once udev has been initialized and registered.
Drivers expect the descriptors stored in the kernel to be immutable;
we should not undermine this expectation. In fact, this change should
have been made long ago.
So now hub_port_init() will take an additional argument, specifying a
buffer in which to store the device descriptor it reads. (If udev has
not yet been initialized, the buffer pointer will be NULL and then
hub_port_init() will store the device descriptor in udev as before.)
This eliminates the data race responsible for the out-of-bounds read.
The changes to hub_port_init() appear more extensive than they really
are, because of indentation changes resulting from an attempt to avoid
writing to other parts of the usb_device structure after it has been
initialized. Similar changes should be made to the code that reads
the BOS descriptor, but that can be handled in a separate patch later
on. This patch is sufficient to fix the bug found by syzbot.
Reported-and-tested-by: syzbot+18996170f8096c6174d0@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/linux-usb/000000000000c0ffe505fe86c9ca@google.com/#r
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Khazhy Kumykov <khazhy@google.com>
Fixes: 45bf39f8df7f ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/b958b47a-9a46-4c22-a9f9-e42e42c31251@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-05 03:14:14 +08:00
|
|
|
*
|
|
|
|
* For a newly detected device, @dev_descr must be NULL. The device
|
|
|
|
* descriptor retrieved from the device will then be stored in
|
|
|
|
* @udev->descriptor. For an already existing device, @dev_descr
|
|
|
|
* must be non-NULL. The device descriptor will be stored there,
|
|
|
|
* not in @udev->descriptor, because descriptors for registered
|
|
|
|
* devices are meant to be immutable.
|
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,
|
USB: core: Fix race by not overwriting udev->descriptor in hub_port_init()
Syzbot reported an out-of-bounds read in sysfs.c:read_descriptors():
BUG: KASAN: slab-out-of-bounds in read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883
Read of size 8 at addr ffff88801e78b8c8 by task udevd/5011
CPU: 0 PID: 5011 Comm: udevd Not tainted 6.4.0-rc6-syzkaller-00195-g40f71e7cd3c6 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106
print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351
print_report mm/kasan/report.c:462 [inline]
kasan_report+0x11c/0x130 mm/kasan/report.c:572
read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883
...
Allocated by task 758:
...
__do_kmalloc_node mm/slab_common.c:966 [inline]
__kmalloc+0x5e/0x190 mm/slab_common.c:979
kmalloc include/linux/slab.h:563 [inline]
kzalloc include/linux/slab.h:680 [inline]
usb_get_configuration+0x1f7/0x5170 drivers/usb/core/config.c:887
usb_enumerate_device drivers/usb/core/hub.c:2407 [inline]
usb_new_device+0x12b0/0x19d0 drivers/usb/core/hub.c:2545
As analyzed by Khazhy Kumykov, the cause of this bug is a race between
read_descriptors() and hub_port_init(): The first routine uses a field
in udev->descriptor, not expecting it to change, while the second
overwrites it.
Prior to commit 45bf39f8df7f ("USB: core: Don't hold device lock while
reading the "descriptors" sysfs file") this race couldn't occur,
because the routines were mutually exclusive thanks to the device
locking. Removing that locking from read_descriptors() exposed it to
the race.
The best way to fix the bug is to keep hub_port_init() from changing
udev->descriptor once udev has been initialized and registered.
Drivers expect the descriptors stored in the kernel to be immutable;
we should not undermine this expectation. In fact, this change should
have been made long ago.
So now hub_port_init() will take an additional argument, specifying a
buffer in which to store the device descriptor it reads. (If udev has
not yet been initialized, the buffer pointer will be NULL and then
hub_port_init() will store the device descriptor in udev as before.)
This eliminates the data race responsible for the out-of-bounds read.
The changes to hub_port_init() appear more extensive than they really
are, because of indentation changes resulting from an attempt to avoid
writing to other parts of the usb_device structure after it has been
initialized. Similar changes should be made to the code that reads
the BOS descriptor, but that can be handled in a separate patch later
on. This patch is sufficient to fix the bug found by syzbot.
Reported-and-tested-by: syzbot+18996170f8096c6174d0@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/linux-usb/000000000000c0ffe505fe86c9ca@google.com/#r
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Khazhy Kumykov <khazhy@google.com>
Fixes: 45bf39f8df7f ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/b958b47a-9a46-4c22-a9f9-e42e42c31251@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-05 03:14:14 +08:00
|
|
|
int retry_counter, struct usb_device_descriptor *dev_descr)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
struct usb_device *hdev = hub->hdev;
|
2009-04-28 10:54:26 +08:00
|
|
|
struct usb_hcd *hcd = bus_to_hcd(hdev->bus);
|
2018-05-28 14:32:18 +08:00
|
|
|
struct usb_port *port_dev = hub->ports[port1 - 1];
|
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;
|
2017-07-19 14:40:53 +08:00
|
|
|
const char *driver_name;
|
2020-09-28 23:20:50 +08:00
|
|
|
bool do_new_scheme;
|
USB: core: Fix race by not overwriting udev->descriptor in hub_port_init()
Syzbot reported an out-of-bounds read in sysfs.c:read_descriptors():
BUG: KASAN: slab-out-of-bounds in read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883
Read of size 8 at addr ffff88801e78b8c8 by task udevd/5011
CPU: 0 PID: 5011 Comm: udevd Not tainted 6.4.0-rc6-syzkaller-00195-g40f71e7cd3c6 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106
print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351
print_report mm/kasan/report.c:462 [inline]
kasan_report+0x11c/0x130 mm/kasan/report.c:572
read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883
...
Allocated by task 758:
...
__do_kmalloc_node mm/slab_common.c:966 [inline]
__kmalloc+0x5e/0x190 mm/slab_common.c:979
kmalloc include/linux/slab.h:563 [inline]
kzalloc include/linux/slab.h:680 [inline]
usb_get_configuration+0x1f7/0x5170 drivers/usb/core/config.c:887
usb_enumerate_device drivers/usb/core/hub.c:2407 [inline]
usb_new_device+0x12b0/0x19d0 drivers/usb/core/hub.c:2545
As analyzed by Khazhy Kumykov, the cause of this bug is a race between
read_descriptors() and hub_port_init(): The first routine uses a field
in udev->descriptor, not expecting it to change, while the second
overwrites it.
Prior to commit 45bf39f8df7f ("USB: core: Don't hold device lock while
reading the "descriptors" sysfs file") this race couldn't occur,
because the routines were mutually exclusive thanks to the device
locking. Removing that locking from read_descriptors() exposed it to
the race.
The best way to fix the bug is to keep hub_port_init() from changing
udev->descriptor once udev has been initialized and registered.
Drivers expect the descriptors stored in the kernel to be immutable;
we should not undermine this expectation. In fact, this change should
have been made long ago.
So now hub_port_init() will take an additional argument, specifying a
buffer in which to store the device descriptor it reads. (If udev has
not yet been initialized, the buffer pointer will be NULL and then
hub_port_init() will store the device descriptor in udev as before.)
This eliminates the data race responsible for the out-of-bounds read.
The changes to hub_port_init() appear more extensive than they really
are, because of indentation changes resulting from an attempt to avoid
writing to other parts of the usb_device structure after it has been
initialized. Similar changes should be made to the code that reads
the BOS descriptor, but that can be handled in a separate patch later
on. This patch is sufficient to fix the bug found by syzbot.
Reported-and-tested-by: syzbot+18996170f8096c6174d0@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/linux-usb/000000000000c0ffe505fe86c9ca@google.com/#r
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Khazhy Kumykov <khazhy@google.com>
Fixes: 45bf39f8df7f ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/b958b47a-9a46-4c22-a9f9-e42e42c31251@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-05 03:14:14 +08:00
|
|
|
const bool initial = !dev_descr;
|
USB: core: Unite old scheme and new scheme descriptor reads
In preparation for reworking the usb_get_device_descriptor() routine,
it is desirable to unite the two different code paths responsible for
initially determining endpoint 0's maximum packet size in a newly
discovered USB device. Making this determination presents a
chicken-and-egg sort of problem, in that the only way to learn the
maxpacket value is to get it from the device descriptor retrieved from
the device, but communicating with the device to retrieve a descriptor
requires us to know beforehand the ep0 maxpacket size.
In practice this problem is solved in two different ways, referred to
in hub.c as the "old scheme" and the "new scheme". The old scheme
(which is the approach recommended by the USB-2 spec) involves asking
the device to send just the first eight bytes of its device
descriptor. Such a transfer uses packets containing no more than
eight bytes each, and every USB device must have an ep0 maxpacket size
>= 8, so this should succeed. Since the bMaxPacketSize0 field of the
device descriptor lies within the first eight bytes, this is all we
need.
The new scheme is an imitation of the technique used in an early
Windows USB implementation, giving it the happy advantage of working
with a wide variety of devices (some of them at the time would not
work with the old scheme, although that's probably less true now). It
involves making an initial guess of the ep0 maxpacket size, asking the
device to send up to 64 bytes worth of its device descriptor (which is
only 18 bytes long), and then resetting the device to clear any error
condition that might have resulted from the guess being wrong. The
initial guess is determined by the connection speed; it should be
correct in all cases other than full speed, for which the allowed
values are 8, 16, 32, and 64 (in this case the initial guess is 64).
The reason for this patch is that the old- and new-scheme parts of
hub_port_init() use different code paths, one involving
usb_get_device_descriptor() and one not, for their initial reads of
the device descriptor. Since these reads have essentially the same
purpose and are made under essentially the same circumstances, this is
illogical. It makes more sense to have both of them use a common
subroutine.
This subroutine does basically what the new scheme's code did, because
that approach is more general than the one used by the old scheme. It
only needs to know how many bytes to transfer and whether or not it is
being called for the first iteration of a retry loop (in case of
certain time-out errors). There are two main differences from the
former code:
We initialize the bDescriptorType field of the transfer buffer
to 0 before performing the transfer, to avoid possibly
accessing an uninitialized value afterward.
We read the device descriptor into a temporary buffer rather
than storing it directly into udev->descriptor, which the old
scheme implementation used to do.
Since the whole point of this first read of the device descriptor is
to determine the bMaxPacketSize0 value, that is what the new routine
returns (or an error code). The value is stored in a local variable
rather than in udev->descriptor. As a side effect, this necessitates
moving a section of code that checks the bcdUSB field for SuperSpeed
devices until after the full device descriptor has been retrieved.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Oliver Neukum <oneukum@suse.com>
Link: https://lore.kernel.org/r/495cb5d4-f956-4f4a-a875-1e67e9489510@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-05 03:10:59 +08:00
|
|
|
int maxp0;
|
2023-08-05 03:12:21 +08:00
|
|
|
struct usb_device_descriptor *buf, *descr;
|
USB: core: Unite old scheme and new scheme descriptor reads
In preparation for reworking the usb_get_device_descriptor() routine,
it is desirable to unite the two different code paths responsible for
initially determining endpoint 0's maximum packet size in a newly
discovered USB device. Making this determination presents a
chicken-and-egg sort of problem, in that the only way to learn the
maxpacket value is to get it from the device descriptor retrieved from
the device, but communicating with the device to retrieve a descriptor
requires us to know beforehand the ep0 maxpacket size.
In practice this problem is solved in two different ways, referred to
in hub.c as the "old scheme" and the "new scheme". The old scheme
(which is the approach recommended by the USB-2 spec) involves asking
the device to send just the first eight bytes of its device
descriptor. Such a transfer uses packets containing no more than
eight bytes each, and every USB device must have an ep0 maxpacket size
>= 8, so this should succeed. Since the bMaxPacketSize0 field of the
device descriptor lies within the first eight bytes, this is all we
need.
The new scheme is an imitation of the technique used in an early
Windows USB implementation, giving it the happy advantage of working
with a wide variety of devices (some of them at the time would not
work with the old scheme, although that's probably less true now). It
involves making an initial guess of the ep0 maxpacket size, asking the
device to send up to 64 bytes worth of its device descriptor (which is
only 18 bytes long), and then resetting the device to clear any error
condition that might have resulted from the guess being wrong. The
initial guess is determined by the connection speed; it should be
correct in all cases other than full speed, for which the allowed
values are 8, 16, 32, and 64 (in this case the initial guess is 64).
The reason for this patch is that the old- and new-scheme parts of
hub_port_init() use different code paths, one involving
usb_get_device_descriptor() and one not, for their initial reads of
the device descriptor. Since these reads have essentially the same
purpose and are made under essentially the same circumstances, this is
illogical. It makes more sense to have both of them use a common
subroutine.
This subroutine does basically what the new scheme's code did, because
that approach is more general than the one used by the old scheme. It
only needs to know how many bytes to transfer and whether or not it is
being called for the first iteration of a retry loop (in case of
certain time-out errors). There are two main differences from the
former code:
We initialize the bDescriptorType field of the transfer buffer
to 0 before performing the transfer, to avoid possibly
accessing an uninitialized value afterward.
We read the device descriptor into a temporary buffer rather
than storing it directly into udev->descriptor, which the old
scheme implementation used to do.
Since the whole point of this first read of the device descriptor is
to determine the bMaxPacketSize0 value, that is what the new routine
returns (or an error code). The value is stored in a local variable
rather than in udev->descriptor. As a side effect, this necessitates
moving a section of code that checks the bcdUSB field for SuperSpeed
devices until after the full device descriptor has been retrieved.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Oliver Neukum <oneukum@suse.com>
Link: https://lore.kernel.org/r/495cb5d4-f956-4f4a-a875-1e67e9489510@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-05 03:10:59 +08:00
|
|
|
|
|
|
|
buf = kmalloc(GET_DESCRIPTOR_BUFSIZE, GFP_NOIO);
|
|
|
|
if (!buf)
|
|
|
|
return -ENOMEM;
|
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;
|
|
|
|
|
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
|
|
|
|
USB: core: Fix race by not overwriting udev->descriptor in hub_port_init()
Syzbot reported an out-of-bounds read in sysfs.c:read_descriptors():
BUG: KASAN: slab-out-of-bounds in read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883
Read of size 8 at addr ffff88801e78b8c8 by task udevd/5011
CPU: 0 PID: 5011 Comm: udevd Not tainted 6.4.0-rc6-syzkaller-00195-g40f71e7cd3c6 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106
print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351
print_report mm/kasan/report.c:462 [inline]
kasan_report+0x11c/0x130 mm/kasan/report.c:572
read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883
...
Allocated by task 758:
...
__do_kmalloc_node mm/slab_common.c:966 [inline]
__kmalloc+0x5e/0x190 mm/slab_common.c:979
kmalloc include/linux/slab.h:563 [inline]
kzalloc include/linux/slab.h:680 [inline]
usb_get_configuration+0x1f7/0x5170 drivers/usb/core/config.c:887
usb_enumerate_device drivers/usb/core/hub.c:2407 [inline]
usb_new_device+0x12b0/0x19d0 drivers/usb/core/hub.c:2545
As analyzed by Khazhy Kumykov, the cause of this bug is a race between
read_descriptors() and hub_port_init(): The first routine uses a field
in udev->descriptor, not expecting it to change, while the second
overwrites it.
Prior to commit 45bf39f8df7f ("USB: core: Don't hold device lock while
reading the "descriptors" sysfs file") this race couldn't occur,
because the routines were mutually exclusive thanks to the device
locking. Removing that locking from read_descriptors() exposed it to
the race.
The best way to fix the bug is to keep hub_port_init() from changing
udev->descriptor once udev has been initialized and registered.
Drivers expect the descriptors stored in the kernel to be immutable;
we should not undermine this expectation. In fact, this change should
have been made long ago.
So now hub_port_init() will take an additional argument, specifying a
buffer in which to store the device descriptor it reads. (If udev has
not yet been initialized, the buffer pointer will be NULL and then
hub_port_init() will store the device descriptor in udev as before.)
This eliminates the data race responsible for the out-of-bounds read.
The changes to hub_port_init() appear more extensive than they really
are, because of indentation changes resulting from an attempt to avoid
writing to other parts of the usb_device structure after it has been
initialized. Similar changes should be made to the code that reads
the BOS descriptor, but that can be handled in a separate patch later
on. This patch is sufficient to fix the bug found by syzbot.
Reported-and-tested-by: syzbot+18996170f8096c6174d0@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/linux-usb/000000000000c0ffe505fe86c9ca@google.com/#r
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Khazhy Kumykov <khazhy@google.com>
Fixes: 45bf39f8df7f ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/b958b47a-9a46-4c22-a9f9-e42e42c31251@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-05 03:14:14 +08:00
|
|
|
if (initial) {
|
|
|
|
/* USB 2.0 section 5.5.3 talks about ep0 maxpacket ...
|
|
|
|
* it's fixed size except for full speed devices.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
USB: core: Fix race by not overwriting udev->descriptor in hub_port_init()
Syzbot reported an out-of-bounds read in sysfs.c:read_descriptors():
BUG: KASAN: slab-out-of-bounds in read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883
Read of size 8 at addr ffff88801e78b8c8 by task udevd/5011
CPU: 0 PID: 5011 Comm: udevd Not tainted 6.4.0-rc6-syzkaller-00195-g40f71e7cd3c6 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106
print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351
print_report mm/kasan/report.c:462 [inline]
kasan_report+0x11c/0x130 mm/kasan/report.c:572
read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883
...
Allocated by task 758:
...
__do_kmalloc_node mm/slab_common.c:966 [inline]
__kmalloc+0x5e/0x190 mm/slab_common.c:979
kmalloc include/linux/slab.h:563 [inline]
kzalloc include/linux/slab.h:680 [inline]
usb_get_configuration+0x1f7/0x5170 drivers/usb/core/config.c:887
usb_enumerate_device drivers/usb/core/hub.c:2407 [inline]
usb_new_device+0x12b0/0x19d0 drivers/usb/core/hub.c:2545
As analyzed by Khazhy Kumykov, the cause of this bug is a race between
read_descriptors() and hub_port_init(): The first routine uses a field
in udev->descriptor, not expecting it to change, while the second
overwrites it.
Prior to commit 45bf39f8df7f ("USB: core: Don't hold device lock while
reading the "descriptors" sysfs file") this race couldn't occur,
because the routines were mutually exclusive thanks to the device
locking. Removing that locking from read_descriptors() exposed it to
the race.
The best way to fix the bug is to keep hub_port_init() from changing
udev->descriptor once udev has been initialized and registered.
Drivers expect the descriptors stored in the kernel to be immutable;
we should not undermine this expectation. In fact, this change should
have been made long ago.
So now hub_port_init() will take an additional argument, specifying a
buffer in which to store the device descriptor it reads. (If udev has
not yet been initialized, the buffer pointer will be NULL and then
hub_port_init() will store the device descriptor in udev as before.)
This eliminates the data race responsible for the out-of-bounds read.
The changes to hub_port_init() appear more extensive than they really
are, because of indentation changes resulting from an attempt to avoid
writing to other parts of the usb_device structure after it has been
initialized. Similar changes should be made to the code that reads
the BOS descriptor, but that can be handled in a separate patch later
on. This patch is sufficient to fix the bug found by syzbot.
Reported-and-tested-by: syzbot+18996170f8096c6174d0@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/linux-usb/000000000000c0ffe505fe86c9ca@google.com/#r
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Khazhy Kumykov <khazhy@google.com>
Fixes: 45bf39f8df7f ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/b958b47a-9a46-4c22-a9f9-e42e42c31251@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-05 03:14:14 +08:00
|
|
|
switch (udev->speed) {
|
|
|
|
case USB_SPEED_SUPER_PLUS:
|
|
|
|
case USB_SPEED_SUPER:
|
|
|
|
udev->ep0.desc.wMaxPacketSize = cpu_to_le16(512);
|
|
|
|
break;
|
|
|
|
case USB_SPEED_HIGH: /* fixed at 64 */
|
|
|
|
udev->ep0.desc.wMaxPacketSize = cpu_to_le16(64);
|
|
|
|
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.
|
|
|
|
*/
|
|
|
|
udev->ep0.desc.wMaxPacketSize = cpu_to_le16(64);
|
|
|
|
break;
|
|
|
|
case USB_SPEED_LOW: /* fixed at 8 */
|
|
|
|
udev->ep0.desc.wMaxPacketSize = cpu_to_le16(8);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
goto fail;
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2011-08-30 23:11:19 +08:00
|
|
|
|
2023-08-09 08:44:18 +08:00
|
|
|
speed = usb_speed_string(udev->speed);
|
2011-08-30 23:11:19 +08:00
|
|
|
|
2017-07-19 14:40:53 +08:00
|
|
|
/*
|
|
|
|
* The controller driver may be NULL if the controller device
|
|
|
|
* is the middle device between platform device and roothub.
|
|
|
|
* This middle device may not need a device driver due to
|
|
|
|
* all hardware control can be at platform device driver, this
|
|
|
|
* platform device is usually a dual-role USB controller device.
|
|
|
|
*/
|
|
|
|
if (udev->bus->controller->driver)
|
|
|
|
driver_name = udev->bus->controller->driver->name;
|
|
|
|
else
|
|
|
|
driver_name = udev->bus->sysdev->driver->name;
|
|
|
|
|
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",
|
USB: core: Fix race by not overwriting udev->descriptor in hub_port_init()
Syzbot reported an out-of-bounds read in sysfs.c:read_descriptors():
BUG: KASAN: slab-out-of-bounds in read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883
Read of size 8 at addr ffff88801e78b8c8 by task udevd/5011
CPU: 0 PID: 5011 Comm: udevd Not tainted 6.4.0-rc6-syzkaller-00195-g40f71e7cd3c6 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106
print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351
print_report mm/kasan/report.c:462 [inline]
kasan_report+0x11c/0x130 mm/kasan/report.c:572
read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883
...
Allocated by task 758:
...
__do_kmalloc_node mm/slab_common.c:966 [inline]
__kmalloc+0x5e/0x190 mm/slab_common.c:979
kmalloc include/linux/slab.h:563 [inline]
kzalloc include/linux/slab.h:680 [inline]
usb_get_configuration+0x1f7/0x5170 drivers/usb/core/config.c:887
usb_enumerate_device drivers/usb/core/hub.c:2407 [inline]
usb_new_device+0x12b0/0x19d0 drivers/usb/core/hub.c:2545
As analyzed by Khazhy Kumykov, the cause of this bug is a race between
read_descriptors() and hub_port_init(): The first routine uses a field
in udev->descriptor, not expecting it to change, while the second
overwrites it.
Prior to commit 45bf39f8df7f ("USB: core: Don't hold device lock while
reading the "descriptors" sysfs file") this race couldn't occur,
because the routines were mutually exclusive thanks to the device
locking. Removing that locking from read_descriptors() exposed it to
the race.
The best way to fix the bug is to keep hub_port_init() from changing
udev->descriptor once udev has been initialized and registered.
Drivers expect the descriptors stored in the kernel to be immutable;
we should not undermine this expectation. In fact, this change should
have been made long ago.
So now hub_port_init() will take an additional argument, specifying a
buffer in which to store the device descriptor it reads. (If udev has
not yet been initialized, the buffer pointer will be NULL and then
hub_port_init() will store the device descriptor in udev as before.)
This eliminates the data race responsible for the out-of-bounds read.
The changes to hub_port_init() appear more extensive than they really
are, because of indentation changes resulting from an attempt to avoid
writing to other parts of the usb_device structure after it has been
initialized. Similar changes should be made to the code that reads
the BOS descriptor, but that can be handled in a separate patch later
on. This patch is sufficient to fix the bug found by syzbot.
Reported-and-tested-by: syzbot+18996170f8096c6174d0@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/linux-usb/000000000000c0ffe505fe86c9ca@google.com/#r
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Khazhy Kumykov <khazhy@google.com>
Fixes: 45bf39f8df7f ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/b958b47a-9a46-4c22-a9f9-e42e42c31251@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-05 03:14:14 +08:00
|
|
|
(initial ? "new" : "reset"), speed,
|
2017-07-19 14:40:53 +08:00
|
|
|
devnum, driver_name);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
USB: core: Fix race by not overwriting udev->descriptor in hub_port_init()
Syzbot reported an out-of-bounds read in sysfs.c:read_descriptors():
BUG: KASAN: slab-out-of-bounds in read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883
Read of size 8 at addr ffff88801e78b8c8 by task udevd/5011
CPU: 0 PID: 5011 Comm: udevd Not tainted 6.4.0-rc6-syzkaller-00195-g40f71e7cd3c6 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106
print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351
print_report mm/kasan/report.c:462 [inline]
kasan_report+0x11c/0x130 mm/kasan/report.c:572
read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883
...
Allocated by task 758:
...
__do_kmalloc_node mm/slab_common.c:966 [inline]
__kmalloc+0x5e/0x190 mm/slab_common.c:979
kmalloc include/linux/slab.h:563 [inline]
kzalloc include/linux/slab.h:680 [inline]
usb_get_configuration+0x1f7/0x5170 drivers/usb/core/config.c:887
usb_enumerate_device drivers/usb/core/hub.c:2407 [inline]
usb_new_device+0x12b0/0x19d0 drivers/usb/core/hub.c:2545
As analyzed by Khazhy Kumykov, the cause of this bug is a race between
read_descriptors() and hub_port_init(): The first routine uses a field
in udev->descriptor, not expecting it to change, while the second
overwrites it.
Prior to commit 45bf39f8df7f ("USB: core: Don't hold device lock while
reading the "descriptors" sysfs file") this race couldn't occur,
because the routines were mutually exclusive thanks to the device
locking. Removing that locking from read_descriptors() exposed it to
the race.
The best way to fix the bug is to keep hub_port_init() from changing
udev->descriptor once udev has been initialized and registered.
Drivers expect the descriptors stored in the kernel to be immutable;
we should not undermine this expectation. In fact, this change should
have been made long ago.
So now hub_port_init() will take an additional argument, specifying a
buffer in which to store the device descriptor it reads. (If udev has
not yet been initialized, the buffer pointer will be NULL and then
hub_port_init() will store the device descriptor in udev as before.)
This eliminates the data race responsible for the out-of-bounds read.
The changes to hub_port_init() appear more extensive than they really
are, because of indentation changes resulting from an attempt to avoid
writing to other parts of the usb_device structure after it has been
initialized. Similar changes should be made to the code that reads
the BOS descriptor, but that can be handled in a separate patch later
on. This patch is sufficient to fix the bug found by syzbot.
Reported-and-tested-by: syzbot+18996170f8096c6174d0@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/linux-usb/000000000000c0ffe505fe86c9ca@google.com/#r
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Khazhy Kumykov <khazhy@google.com>
Fixes: 45bf39f8df7f ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/b958b47a-9a46-4c22-a9f9-e42e42c31251@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-05 03:14:14 +08:00
|
|
|
if (initial) {
|
|
|
|
/* 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) {
|
|
|
|
if (!hub->tt.hub) {
|
|
|
|
dev_err(&udev->dev, "parent hub has no TT\n");
|
|
|
|
retval = -EINVAL;
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
udev->tt = &hub->tt;
|
|
|
|
udev->ttport = port1;
|
2011-01-31 23:56:37 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
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.
|
|
|
|
*/
|
2020-09-28 23:20:50 +08:00
|
|
|
do_new_scheme = use_new_scheme(udev, retry_counter, port_dev);
|
2013-12-06 09:07:27 +08:00
|
|
|
|
2020-09-28 23:20:50 +08:00
|
|
|
for (retries = 0; retries < GET_DESCRIPTOR_TRIES; (++retries, msleep(100))) {
|
2022-11-07 15:27:54 +08:00
|
|
|
if (hub_port_stop_enumerate(hub, port1, retries)) {
|
|
|
|
retval = -ENODEV;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2020-09-28 23:20:50 +08:00
|
|
|
if (do_new_scheme) {
|
2013-12-06 09:07:27 +08:00
|
|
|
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
|
|
|
|
USB: core: Unite old scheme and new scheme descriptor reads
In preparation for reworking the usb_get_device_descriptor() routine,
it is desirable to unite the two different code paths responsible for
initially determining endpoint 0's maximum packet size in a newly
discovered USB device. Making this determination presents a
chicken-and-egg sort of problem, in that the only way to learn the
maxpacket value is to get it from the device descriptor retrieved from
the device, but communicating with the device to retrieve a descriptor
requires us to know beforehand the ep0 maxpacket size.
In practice this problem is solved in two different ways, referred to
in hub.c as the "old scheme" and the "new scheme". The old scheme
(which is the approach recommended by the USB-2 spec) involves asking
the device to send just the first eight bytes of its device
descriptor. Such a transfer uses packets containing no more than
eight bytes each, and every USB device must have an ep0 maxpacket size
>= 8, so this should succeed. Since the bMaxPacketSize0 field of the
device descriptor lies within the first eight bytes, this is all we
need.
The new scheme is an imitation of the technique used in an early
Windows USB implementation, giving it the happy advantage of working
with a wide variety of devices (some of them at the time would not
work with the old scheme, although that's probably less true now). It
involves making an initial guess of the ep0 maxpacket size, asking the
device to send up to 64 bytes worth of its device descriptor (which is
only 18 bytes long), and then resetting the device to clear any error
condition that might have resulted from the guess being wrong. The
initial guess is determined by the connection speed; it should be
correct in all cases other than full speed, for which the allowed
values are 8, 16, 32, and 64 (in this case the initial guess is 64).
The reason for this patch is that the old- and new-scheme parts of
hub_port_init() use different code paths, one involving
usb_get_device_descriptor() and one not, for their initial reads of
the device descriptor. Since these reads have essentially the same
purpose and are made under essentially the same circumstances, this is
illogical. It makes more sense to have both of them use a common
subroutine.
This subroutine does basically what the new scheme's code did, because
that approach is more general than the one used by the old scheme. It
only needs to know how many bytes to transfer and whether or not it is
being called for the first iteration of a retry loop (in case of
certain time-out errors). There are two main differences from the
former code:
We initialize the bDescriptorType field of the transfer buffer
to 0 before performing the transfer, to avoid possibly
accessing an uninitialized value afterward.
We read the device descriptor into a temporary buffer rather
than storing it directly into udev->descriptor, which the old
scheme implementation used to do.
Since the whole point of this first read of the device descriptor is
to determine the bMaxPacketSize0 value, that is what the new routine
returns (or an error code). The value is stored in a local variable
rather than in udev->descriptor. As a side effect, this necessitates
moving a section of code that checks the bcdUSB field for SuperSpeed
devices until after the full device descriptor has been retrieved.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Oliver Neukum <oneukum@suse.com>
Link: https://lore.kernel.org/r/495cb5d4-f956-4f4a-a875-1e67e9489510@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-05 03:10:59 +08:00
|
|
|
maxp0 = get_bMaxPacketSize0(udev, buf,
|
|
|
|
GET_DESCRIPTOR_BUFSIZE, retries == 0);
|
USB: core: Fix race by not overwriting udev->descriptor in hub_port_init()
Syzbot reported an out-of-bounds read in sysfs.c:read_descriptors():
BUG: KASAN: slab-out-of-bounds in read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883
Read of size 8 at addr ffff88801e78b8c8 by task udevd/5011
CPU: 0 PID: 5011 Comm: udevd Not tainted 6.4.0-rc6-syzkaller-00195-g40f71e7cd3c6 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106
print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351
print_report mm/kasan/report.c:462 [inline]
kasan_report+0x11c/0x130 mm/kasan/report.c:572
read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883
...
Allocated by task 758:
...
__do_kmalloc_node mm/slab_common.c:966 [inline]
__kmalloc+0x5e/0x190 mm/slab_common.c:979
kmalloc include/linux/slab.h:563 [inline]
kzalloc include/linux/slab.h:680 [inline]
usb_get_configuration+0x1f7/0x5170 drivers/usb/core/config.c:887
usb_enumerate_device drivers/usb/core/hub.c:2407 [inline]
usb_new_device+0x12b0/0x19d0 drivers/usb/core/hub.c:2545
As analyzed by Khazhy Kumykov, the cause of this bug is a race between
read_descriptors() and hub_port_init(): The first routine uses a field
in udev->descriptor, not expecting it to change, while the second
overwrites it.
Prior to commit 45bf39f8df7f ("USB: core: Don't hold device lock while
reading the "descriptors" sysfs file") this race couldn't occur,
because the routines were mutually exclusive thanks to the device
locking. Removing that locking from read_descriptors() exposed it to
the race.
The best way to fix the bug is to keep hub_port_init() from changing
udev->descriptor once udev has been initialized and registered.
Drivers expect the descriptors stored in the kernel to be immutable;
we should not undermine this expectation. In fact, this change should
have been made long ago.
So now hub_port_init() will take an additional argument, specifying a
buffer in which to store the device descriptor it reads. (If udev has
not yet been initialized, the buffer pointer will be NULL and then
hub_port_init() will store the device descriptor in udev as before.)
This eliminates the data race responsible for the out-of-bounds read.
The changes to hub_port_init() appear more extensive than they really
are, because of indentation changes resulting from an attempt to avoid
writing to other parts of the usb_device structure after it has been
initialized. Similar changes should be made to the code that reads
the BOS descriptor, but that can be handled in a separate patch later
on. This patch is sufficient to fix the bug found by syzbot.
Reported-and-tested-by: syzbot+18996170f8096c6174d0@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/linux-usb/000000000000c0ffe505fe86c9ca@google.com/#r
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Khazhy Kumykov <khazhy@google.com>
Fixes: 45bf39f8df7f ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/b958b47a-9a46-4c22-a9f9-e42e42c31251@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-05 03:14:14 +08:00
|
|
|
if (maxp0 > 0 && !initial &&
|
|
|
|
maxp0 != udev->descriptor.bMaxPacketSize0) {
|
|
|
|
dev_err(&udev->dev, "device reset changed ep0 maxpacket size!\n");
|
|
|
|
retval = -ENODEV;
|
|
|
|
goto fail;
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
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;
|
|
|
|
}
|
USB: core: Unite old scheme and new scheme descriptor reads
In preparation for reworking the usb_get_device_descriptor() routine,
it is desirable to unite the two different code paths responsible for
initially determining endpoint 0's maximum packet size in a newly
discovered USB device. Making this determination presents a
chicken-and-egg sort of problem, in that the only way to learn the
maxpacket value is to get it from the device descriptor retrieved from
the device, but communicating with the device to retrieve a descriptor
requires us to know beforehand the ep0 maxpacket size.
In practice this problem is solved in two different ways, referred to
in hub.c as the "old scheme" and the "new scheme". The old scheme
(which is the approach recommended by the USB-2 spec) involves asking
the device to send just the first eight bytes of its device
descriptor. Such a transfer uses packets containing no more than
eight bytes each, and every USB device must have an ep0 maxpacket size
>= 8, so this should succeed. Since the bMaxPacketSize0 field of the
device descriptor lies within the first eight bytes, this is all we
need.
The new scheme is an imitation of the technique used in an early
Windows USB implementation, giving it the happy advantage of working
with a wide variety of devices (some of them at the time would not
work with the old scheme, although that's probably less true now). It
involves making an initial guess of the ep0 maxpacket size, asking the
device to send up to 64 bytes worth of its device descriptor (which is
only 18 bytes long), and then resetting the device to clear any error
condition that might have resulted from the guess being wrong. The
initial guess is determined by the connection speed; it should be
correct in all cases other than full speed, for which the allowed
values are 8, 16, 32, and 64 (in this case the initial guess is 64).
The reason for this patch is that the old- and new-scheme parts of
hub_port_init() use different code paths, one involving
usb_get_device_descriptor() and one not, for their initial reads of
the device descriptor. Since these reads have essentially the same
purpose and are made under essentially the same circumstances, this is
illogical. It makes more sense to have both of them use a common
subroutine.
This subroutine does basically what the new scheme's code did, because
that approach is more general than the one used by the old scheme. It
only needs to know how many bytes to transfer and whether or not it is
being called for the first iteration of a retry loop (in case of
certain time-out errors). There are two main differences from the
former code:
We initialize the bDescriptorType field of the transfer buffer
to 0 before performing the transfer, to avoid possibly
accessing an uninitialized value afterward.
We read the device descriptor into a temporary buffer rather
than storing it directly into udev->descriptor, which the old
scheme implementation used to do.
Since the whole point of this first read of the device descriptor is
to determine the bMaxPacketSize0 value, that is what the new routine
returns (or an error code). The value is stored in a local variable
rather than in udev->descriptor. As a side effect, this necessitates
moving a section of code that checks the bcdUSB field for SuperSpeed
devices until after the full device descriptor has been retrieved.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Oliver Neukum <oneukum@suse.com>
Link: https://lore.kernel.org/r/495cb5d4-f956-4f4a-a875-1e67e9489510@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-05 03:10:59 +08:00
|
|
|
if (maxp0 < 0) {
|
|
|
|
if (maxp0 != -ENODEV)
|
2013-03-28 04:14:01 +08:00
|
|
|
dev_err(&udev->dev, "device descriptor read/64, error %d\n",
|
USB: core: Unite old scheme and new scheme descriptor reads
In preparation for reworking the usb_get_device_descriptor() routine,
it is desirable to unite the two different code paths responsible for
initially determining endpoint 0's maximum packet size in a newly
discovered USB device. Making this determination presents a
chicken-and-egg sort of problem, in that the only way to learn the
maxpacket value is to get it from the device descriptor retrieved from
the device, but communicating with the device to retrieve a descriptor
requires us to know beforehand the ep0 maxpacket size.
In practice this problem is solved in two different ways, referred to
in hub.c as the "old scheme" and the "new scheme". The old scheme
(which is the approach recommended by the USB-2 spec) involves asking
the device to send just the first eight bytes of its device
descriptor. Such a transfer uses packets containing no more than
eight bytes each, and every USB device must have an ep0 maxpacket size
>= 8, so this should succeed. Since the bMaxPacketSize0 field of the
device descriptor lies within the first eight bytes, this is all we
need.
The new scheme is an imitation of the technique used in an early
Windows USB implementation, giving it the happy advantage of working
with a wide variety of devices (some of them at the time would not
work with the old scheme, although that's probably less true now). It
involves making an initial guess of the ep0 maxpacket size, asking the
device to send up to 64 bytes worth of its device descriptor (which is
only 18 bytes long), and then resetting the device to clear any error
condition that might have resulted from the guess being wrong. The
initial guess is determined by the connection speed; it should be
correct in all cases other than full speed, for which the allowed
values are 8, 16, 32, and 64 (in this case the initial guess is 64).
The reason for this patch is that the old- and new-scheme parts of
hub_port_init() use different code paths, one involving
usb_get_device_descriptor() and one not, for their initial reads of
the device descriptor. Since these reads have essentially the same
purpose and are made under essentially the same circumstances, this is
illogical. It makes more sense to have both of them use a common
subroutine.
This subroutine does basically what the new scheme's code did, because
that approach is more general than the one used by the old scheme. It
only needs to know how many bytes to transfer and whether or not it is
being called for the first iteration of a retry loop (in case of
certain time-out errors). There are two main differences from the
former code:
We initialize the bDescriptorType field of the transfer buffer
to 0 before performing the transfer, to avoid possibly
accessing an uninitialized value afterward.
We read the device descriptor into a temporary buffer rather
than storing it directly into udev->descriptor, which the old
scheme implementation used to do.
Since the whole point of this first read of the device descriptor is
to determine the bMaxPacketSize0 value, that is what the new routine
returns (or an error code). The value is stored in a local variable
rather than in udev->descriptor. As a side effect, this necessitates
moving a section of code that checks the bcdUSB field for SuperSpeed
devices until after the full device descriptor has been retrieved.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Oliver Neukum <oneukum@suse.com>
Link: https://lore.kernel.org/r/495cb5d4-f956-4f4a-a875-1e67e9489510@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-05 03:10:59 +08:00
|
|
|
maxp0);
|
|
|
|
retval = maxp0;
|
2005-04-17 06:20:36 +08:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-08-09 08:44:18 +08:00
|
|
|
for (operations = 0; operations < SET_ADDRESS_TRIES; ++operations) {
|
|
|
|
retval = hub_set_address(udev, devnum);
|
|
|
|
if (retval >= 0)
|
|
|
|
break;
|
|
|
|
msleep(200);
|
|
|
|
}
|
|
|
|
if (retval < 0) {
|
|
|
|
if (retval != -ENODEV)
|
|
|
|
dev_err(&udev->dev, "device not accepting address %d, error %d\n",
|
|
|
|
devnum, retval);
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
if (udev->speed >= USB_SPEED_SUPER) {
|
|
|
|
devnum = udev->devnum;
|
|
|
|
dev_info(&udev->dev,
|
|
|
|
"%s SuperSpeed%s%s USB device number %d using %s\n",
|
|
|
|
(udev->config) ? "reset" : "new",
|
|
|
|
(udev->speed == USB_SPEED_SUPER_PLUS) ?
|
|
|
|
" Plus" : "",
|
|
|
|
(udev->ssp_rate == USB_SSP_GEN_2x2) ?
|
|
|
|
" Gen 2x2" :
|
|
|
|
(udev->ssp_rate == USB_SSP_GEN_2x1) ?
|
|
|
|
" Gen 2x1" :
|
|
|
|
(udev->ssp_rate == USB_SSP_GEN_1x2) ?
|
|
|
|
" Gen 1x2" : "",
|
|
|
|
devnum, driver_name);
|
|
|
|
}
|
|
|
|
|
2013-10-11 05:41:27 +08:00
|
|
|
/*
|
2023-08-09 08:44:18 +08:00
|
|
|
* cope with hardware quirkiness:
|
|
|
|
* - let SET_ADDRESS settle, some device hardware wants it
|
|
|
|
* - read ep0 maxpacket even for high and low speed,
|
2013-10-11 05:41:27 +08:00
|
|
|
*/
|
2023-08-09 08:44:18 +08:00
|
|
|
msleep(10);
|
2008-04-09 04:24:46 +08:00
|
|
|
|
2023-08-09 08:44:18 +08:00
|
|
|
if (do_new_scheme)
|
|
|
|
break;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
USB: core: Unite old scheme and new scheme descriptor reads
In preparation for reworking the usb_get_device_descriptor() routine,
it is desirable to unite the two different code paths responsible for
initially determining endpoint 0's maximum packet size in a newly
discovered USB device. Making this determination presents a
chicken-and-egg sort of problem, in that the only way to learn the
maxpacket value is to get it from the device descriptor retrieved from
the device, but communicating with the device to retrieve a descriptor
requires us to know beforehand the ep0 maxpacket size.
In practice this problem is solved in two different ways, referred to
in hub.c as the "old scheme" and the "new scheme". The old scheme
(which is the approach recommended by the USB-2 spec) involves asking
the device to send just the first eight bytes of its device
descriptor. Such a transfer uses packets containing no more than
eight bytes each, and every USB device must have an ep0 maxpacket size
>= 8, so this should succeed. Since the bMaxPacketSize0 field of the
device descriptor lies within the first eight bytes, this is all we
need.
The new scheme is an imitation of the technique used in an early
Windows USB implementation, giving it the happy advantage of working
with a wide variety of devices (some of them at the time would not
work with the old scheme, although that's probably less true now). It
involves making an initial guess of the ep0 maxpacket size, asking the
device to send up to 64 bytes worth of its device descriptor (which is
only 18 bytes long), and then resetting the device to clear any error
condition that might have resulted from the guess being wrong. The
initial guess is determined by the connection speed; it should be
correct in all cases other than full speed, for which the allowed
values are 8, 16, 32, and 64 (in this case the initial guess is 64).
The reason for this patch is that the old- and new-scheme parts of
hub_port_init() use different code paths, one involving
usb_get_device_descriptor() and one not, for their initial reads of
the device descriptor. Since these reads have essentially the same
purpose and are made under essentially the same circumstances, this is
illogical. It makes more sense to have both of them use a common
subroutine.
This subroutine does basically what the new scheme's code did, because
that approach is more general than the one used by the old scheme. It
only needs to know how many bytes to transfer and whether or not it is
being called for the first iteration of a retry loop (in case of
certain time-out errors). There are two main differences from the
former code:
We initialize the bDescriptorType field of the transfer buffer
to 0 before performing the transfer, to avoid possibly
accessing an uninitialized value afterward.
We read the device descriptor into a temporary buffer rather
than storing it directly into udev->descriptor, which the old
scheme implementation used to do.
Since the whole point of this first read of the device descriptor is
to determine the bMaxPacketSize0 value, that is what the new routine
returns (or an error code). The value is stored in a local variable
rather than in udev->descriptor. As a side effect, this necessitates
moving a section of code that checks the bcdUSB field for SuperSpeed
devices until after the full device descriptor has been retrieved.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Oliver Neukum <oneukum@suse.com>
Link: https://lore.kernel.org/r/495cb5d4-f956-4f4a-a875-1e67e9489510@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-05 03:10:59 +08:00
|
|
|
maxp0 = get_bMaxPacketSize0(udev, buf, 8, retries == 0);
|
|
|
|
if (maxp0 < 0) {
|
|
|
|
retval = maxp0;
|
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
|
|
|
} else {
|
2017-12-14 15:50:39 +08:00
|
|
|
u32 delay;
|
|
|
|
|
USB: core: Fix race by not overwriting udev->descriptor in hub_port_init()
Syzbot reported an out-of-bounds read in sysfs.c:read_descriptors():
BUG: KASAN: slab-out-of-bounds in read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883
Read of size 8 at addr ffff88801e78b8c8 by task udevd/5011
CPU: 0 PID: 5011 Comm: udevd Not tainted 6.4.0-rc6-syzkaller-00195-g40f71e7cd3c6 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106
print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351
print_report mm/kasan/report.c:462 [inline]
kasan_report+0x11c/0x130 mm/kasan/report.c:572
read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883
...
Allocated by task 758:
...
__do_kmalloc_node mm/slab_common.c:966 [inline]
__kmalloc+0x5e/0x190 mm/slab_common.c:979
kmalloc include/linux/slab.h:563 [inline]
kzalloc include/linux/slab.h:680 [inline]
usb_get_configuration+0x1f7/0x5170 drivers/usb/core/config.c:887
usb_enumerate_device drivers/usb/core/hub.c:2407 [inline]
usb_new_device+0x12b0/0x19d0 drivers/usb/core/hub.c:2545
As analyzed by Khazhy Kumykov, the cause of this bug is a race between
read_descriptors() and hub_port_init(): The first routine uses a field
in udev->descriptor, not expecting it to change, while the second
overwrites it.
Prior to commit 45bf39f8df7f ("USB: core: Don't hold device lock while
reading the "descriptors" sysfs file") this race couldn't occur,
because the routines were mutually exclusive thanks to the device
locking. Removing that locking from read_descriptors() exposed it to
the race.
The best way to fix the bug is to keep hub_port_init() from changing
udev->descriptor once udev has been initialized and registered.
Drivers expect the descriptors stored in the kernel to be immutable;
we should not undermine this expectation. In fact, this change should
have been made long ago.
So now hub_port_init() will take an additional argument, specifying a
buffer in which to store the device descriptor it reads. (If udev has
not yet been initialized, the buffer pointer will be NULL and then
hub_port_init() will store the device descriptor in udev as before.)
This eliminates the data race responsible for the out-of-bounds read.
The changes to hub_port_init() appear more extensive than they really
are, because of indentation changes resulting from an attempt to avoid
writing to other parts of the usb_device structure after it has been
initialized. Similar changes should be made to the code that reads
the BOS descriptor, but that can be handled in a separate patch later
on. This patch is sufficient to fix the bug found by syzbot.
Reported-and-tested-by: syzbot+18996170f8096c6174d0@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/linux-usb/000000000000c0ffe505fe86c9ca@google.com/#r
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Khazhy Kumykov <khazhy@google.com>
Fixes: 45bf39f8df7f ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/b958b47a-9a46-4c22-a9f9-e42e42c31251@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-05 03:14:14 +08:00
|
|
|
if (!initial && maxp0 != udev->descriptor.bMaxPacketSize0) {
|
|
|
|
dev_err(&udev->dev, "device reset changed ep0 maxpacket size!\n");
|
|
|
|
retval = -ENODEV;
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
2017-12-14 15:50:39 +08:00
|
|
|
delay = udev->parent->hub_delay;
|
|
|
|
udev->hub_delay = min_t(u32, delay,
|
|
|
|
USB_TP_TRANSMISSION_DELAY_MAX);
|
|
|
|
retval = usb_set_isoch_delay(udev);
|
|
|
|
if (retval) {
|
|
|
|
dev_dbg(&udev->dev,
|
|
|
|
"Failed set isoch delay, error %d\n",
|
|
|
|
retval);
|
|
|
|
retval = 0;
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (retval)
|
|
|
|
goto fail;
|
|
|
|
|
2023-08-12 01:38:46 +08:00
|
|
|
/*
|
|
|
|
* Check the ep0 maxpacket guess and correct it if necessary.
|
|
|
|
* maxp0 is the value stored in the device descriptor;
|
|
|
|
* i is the value it encodes (logarithmic for SuperSpeed or greater).
|
|
|
|
*/
|
|
|
|
i = maxp0;
|
|
|
|
if (udev->speed >= USB_SPEED_SUPER) {
|
|
|
|
if (maxp0 <= 16)
|
|
|
|
i = 1 << maxp0;
|
|
|
|
else
|
|
|
|
i = 0; /* Invalid */
|
|
|
|
}
|
|
|
|
if (usb_endpoint_maxp(&udev->ep0.desc) == i) {
|
|
|
|
; /* Initial ep0 maxpacket guess is right */
|
2024-04-30 22:33:48 +08:00
|
|
|
} else if (((udev->speed == USB_SPEED_FULL ||
|
2023-08-12 01:38:46 +08:00
|
|
|
udev->speed == USB_SPEED_HIGH) &&
|
2024-04-30 22:33:48 +08:00
|
|
|
(i == 8 || i == 16 || i == 32 || i == 64)) ||
|
|
|
|
(udev->speed >= USB_SPEED_SUPER && i > 0)) {
|
2023-08-12 01:38:46 +08:00
|
|
|
/* Initial guess is wrong; use the descriptor's value */
|
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);
|
2023-08-12 01:38:46 +08:00
|
|
|
} else {
|
|
|
|
/* Initial guess is wrong and descriptor's value is invalid */
|
|
|
|
dev_err(&udev->dev, "Invalid ep0 maxpacket: %d\n", maxp0);
|
|
|
|
retval = -EMSGSIZE;
|
|
|
|
goto fail;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2013-10-11 05:41:27 +08:00
|
|
|
|
2023-08-05 03:12:21 +08:00
|
|
|
descr = usb_get_device_descriptor(udev);
|
|
|
|
if (IS_ERR(descr)) {
|
|
|
|
retval = PTR_ERR(descr);
|
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
|
|
|
goto fail;
|
|
|
|
}
|
USB: core: Fix race by not overwriting udev->descriptor in hub_port_init()
Syzbot reported an out-of-bounds read in sysfs.c:read_descriptors():
BUG: KASAN: slab-out-of-bounds in read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883
Read of size 8 at addr ffff88801e78b8c8 by task udevd/5011
CPU: 0 PID: 5011 Comm: udevd Not tainted 6.4.0-rc6-syzkaller-00195-g40f71e7cd3c6 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106
print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351
print_report mm/kasan/report.c:462 [inline]
kasan_report+0x11c/0x130 mm/kasan/report.c:572
read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883
...
Allocated by task 758:
...
__do_kmalloc_node mm/slab_common.c:966 [inline]
__kmalloc+0x5e/0x190 mm/slab_common.c:979
kmalloc include/linux/slab.h:563 [inline]
kzalloc include/linux/slab.h:680 [inline]
usb_get_configuration+0x1f7/0x5170 drivers/usb/core/config.c:887
usb_enumerate_device drivers/usb/core/hub.c:2407 [inline]
usb_new_device+0x12b0/0x19d0 drivers/usb/core/hub.c:2545
As analyzed by Khazhy Kumykov, the cause of this bug is a race between
read_descriptors() and hub_port_init(): The first routine uses a field
in udev->descriptor, not expecting it to change, while the second
overwrites it.
Prior to commit 45bf39f8df7f ("USB: core: Don't hold device lock while
reading the "descriptors" sysfs file") this race couldn't occur,
because the routines were mutually exclusive thanks to the device
locking. Removing that locking from read_descriptors() exposed it to
the race.
The best way to fix the bug is to keep hub_port_init() from changing
udev->descriptor once udev has been initialized and registered.
Drivers expect the descriptors stored in the kernel to be immutable;
we should not undermine this expectation. In fact, this change should
have been made long ago.
So now hub_port_init() will take an additional argument, specifying a
buffer in which to store the device descriptor it reads. (If udev has
not yet been initialized, the buffer pointer will be NULL and then
hub_port_init() will store the device descriptor in udev as before.)
This eliminates the data race responsible for the out-of-bounds read.
The changes to hub_port_init() appear more extensive than they really
are, because of indentation changes resulting from an attempt to avoid
writing to other parts of the usb_device structure after it has been
initialized. Similar changes should be made to the code that reads
the BOS descriptor, but that can be handled in a separate patch later
on. This patch is sufficient to fix the bug found by syzbot.
Reported-and-tested-by: syzbot+18996170f8096c6174d0@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/linux-usb/000000000000c0ffe505fe86c9ca@google.com/#r
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Khazhy Kumykov <khazhy@google.com>
Fixes: 45bf39f8df7f ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/b958b47a-9a46-4c22-a9f9-e42e42c31251@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-05 03:14:14 +08:00
|
|
|
if (initial)
|
|
|
|
udev->descriptor = *descr;
|
|
|
|
else
|
|
|
|
*dev_descr = *descr;
|
2023-08-05 03:12:21 +08:00
|
|
|
kfree(descr);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
USB: core: Unite old scheme and new scheme descriptor reads
In preparation for reworking the usb_get_device_descriptor() routine,
it is desirable to unite the two different code paths responsible for
initially determining endpoint 0's maximum packet size in a newly
discovered USB device. Making this determination presents a
chicken-and-egg sort of problem, in that the only way to learn the
maxpacket value is to get it from the device descriptor retrieved from
the device, but communicating with the device to retrieve a descriptor
requires us to know beforehand the ep0 maxpacket size.
In practice this problem is solved in two different ways, referred to
in hub.c as the "old scheme" and the "new scheme". The old scheme
(which is the approach recommended by the USB-2 spec) involves asking
the device to send just the first eight bytes of its device
descriptor. Such a transfer uses packets containing no more than
eight bytes each, and every USB device must have an ep0 maxpacket size
>= 8, so this should succeed. Since the bMaxPacketSize0 field of the
device descriptor lies within the first eight bytes, this is all we
need.
The new scheme is an imitation of the technique used in an early
Windows USB implementation, giving it the happy advantage of working
with a wide variety of devices (some of them at the time would not
work with the old scheme, although that's probably less true now). It
involves making an initial guess of the ep0 maxpacket size, asking the
device to send up to 64 bytes worth of its device descriptor (which is
only 18 bytes long), and then resetting the device to clear any error
condition that might have resulted from the guess being wrong. The
initial guess is determined by the connection speed; it should be
correct in all cases other than full speed, for which the allowed
values are 8, 16, 32, and 64 (in this case the initial guess is 64).
The reason for this patch is that the old- and new-scheme parts of
hub_port_init() use different code paths, one involving
usb_get_device_descriptor() and one not, for their initial reads of
the device descriptor. Since these reads have essentially the same
purpose and are made under essentially the same circumstances, this is
illogical. It makes more sense to have both of them use a common
subroutine.
This subroutine does basically what the new scheme's code did, because
that approach is more general than the one used by the old scheme. It
only needs to know how many bytes to transfer and whether or not it is
being called for the first iteration of a retry loop (in case of
certain time-out errors). There are two main differences from the
former code:
We initialize the bDescriptorType field of the transfer buffer
to 0 before performing the transfer, to avoid possibly
accessing an uninitialized value afterward.
We read the device descriptor into a temporary buffer rather
than storing it directly into udev->descriptor, which the old
scheme implementation used to do.
Since the whole point of this first read of the device descriptor is
to determine the bMaxPacketSize0 value, that is what the new routine
returns (or an error code). The value is stored in a local variable
rather than in udev->descriptor. As a side effect, this necessitates
moving a section of code that checks the bcdUSB field for SuperSpeed
devices until after the full device descriptor has been retrieved.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Oliver Neukum <oneukum@suse.com>
Link: https://lore.kernel.org/r/495cb5d4-f956-4f4a-a875-1e67e9489510@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-05 03:10:59 +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.
|
|
|
|
*/
|
|
|
|
if ((udev->speed >= USB_SPEED_SUPER) &&
|
|
|
|
(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;
|
|
|
|
}
|
|
|
|
|
2015-12-11 04:27:21 +08:00
|
|
|
usb_detect_quirks(udev);
|
|
|
|
|
2023-08-09 08:44:18 +08:00
|
|
|
if (le16_to_cpu(udev->descriptor.bcdUSB) >= 0x0201) {
|
2011-09-24 05:19:48 +08:00
|
|
|
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);
|
2022-02-16 17:51:51 +08:00
|
|
|
udev->lpm_disable_count = 1;
|
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);
|
2022-05-07 00:18:07 +08:00
|
|
|
usb_req_set_sel(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
|
|
|
}
|
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
|
|
|
}
|
USB: core: Unite old scheme and new scheme descriptor reads
In preparation for reworking the usb_get_device_descriptor() routine,
it is desirable to unite the two different code paths responsible for
initially determining endpoint 0's maximum packet size in a newly
discovered USB device. Making this determination presents a
chicken-and-egg sort of problem, in that the only way to learn the
maxpacket value is to get it from the device descriptor retrieved from
the device, but communicating with the device to retrieve a descriptor
requires us to know beforehand the ep0 maxpacket size.
In practice this problem is solved in two different ways, referred to
in hub.c as the "old scheme" and the "new scheme". The old scheme
(which is the approach recommended by the USB-2 spec) involves asking
the device to send just the first eight bytes of its device
descriptor. Such a transfer uses packets containing no more than
eight bytes each, and every USB device must have an ep0 maxpacket size
>= 8, so this should succeed. Since the bMaxPacketSize0 field of the
device descriptor lies within the first eight bytes, this is all we
need.
The new scheme is an imitation of the technique used in an early
Windows USB implementation, giving it the happy advantage of working
with a wide variety of devices (some of them at the time would not
work with the old scheme, although that's probably less true now). It
involves making an initial guess of the ep0 maxpacket size, asking the
device to send up to 64 bytes worth of its device descriptor (which is
only 18 bytes long), and then resetting the device to clear any error
condition that might have resulted from the guess being wrong. The
initial guess is determined by the connection speed; it should be
correct in all cases other than full speed, for which the allowed
values are 8, 16, 32, and 64 (in this case the initial guess is 64).
The reason for this patch is that the old- and new-scheme parts of
hub_port_init() use different code paths, one involving
usb_get_device_descriptor() and one not, for their initial reads of
the device descriptor. Since these reads have essentially the same
purpose and are made under essentially the same circumstances, this is
illogical. It makes more sense to have both of them use a common
subroutine.
This subroutine does basically what the new scheme's code did, because
that approach is more general than the one used by the old scheme. It
only needs to know how many bytes to transfer and whether or not it is
being called for the first iteration of a retry loop (in case of
certain time-out errors). There are two main differences from the
former code:
We initialize the bDescriptorType field of the transfer buffer
to 0 before performing the transfer, to avoid possibly
accessing an uninitialized value afterward.
We read the device descriptor into a temporary buffer rather
than storing it directly into udev->descriptor, which the old
scheme implementation used to do.
Since the whole point of this first read of the device descriptor is
to determine the bMaxPacketSize0 value, that is what the new routine
returns (or an error code). The value is stored in a local variable
rather than in udev->descriptor. As a side effect, this necessitates
moving a section of code that checks the bcdUSB field for SuperSpeed
devices until after the full device descriptor has been retrieved.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Oliver Neukum <oneukum@suse.com>
Link: https://lore.kernel.org/r/495cb5d4-f956-4f4a-a875-1e67e9489510@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-05 03:10:59 +08:00
|
|
|
kfree(buf);
|
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;
|
|
|
|
}
|
|
|
|
|
2019-10-09 12:46:47 +08:00
|
|
|
|
|
|
|
static int descriptors_changed(struct usb_device *udev,
|
2023-08-05 03:12:21 +08:00
|
|
|
struct usb_device_descriptor *new_device_descriptor,
|
2019-10-09 12:46:47 +08:00
|
|
|
struct usb_host_bos *old_bos)
|
|
|
|
{
|
|
|
|
int changed = 0;
|
|
|
|
unsigned index;
|
|
|
|
unsigned serial_len = 0;
|
|
|
|
unsigned len;
|
|
|
|
unsigned old_length;
|
|
|
|
int length;
|
|
|
|
char *buf;
|
|
|
|
|
2023-08-05 03:12:21 +08:00
|
|
|
if (memcmp(&udev->descriptor, new_device_descriptor,
|
|
|
|
sizeof(*new_device_descriptor)) != 0)
|
2019-10-09 12:46:47 +08:00
|
|
|
return 1;
|
|
|
|
|
|
|
|
if ((old_bos && !udev->bos) || (!old_bos && udev->bos))
|
|
|
|
return 1;
|
|
|
|
if (udev->bos) {
|
|
|
|
len = le16_to_cpu(udev->bos->desc->wTotalLength);
|
|
|
|
if (len != le16_to_cpu(old_bos->desc->wTotalLength))
|
|
|
|
return 1;
|
|
|
|
if (memcmp(udev->bos->desc, old_bos->desc, len))
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* 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;
|
|
|
|
|
|
|
|
len = serial_len;
|
|
|
|
for (index = 0; index < udev->descriptor.bNumConfigurations; index++) {
|
|
|
|
old_length = le16_to_cpu(udev->config[index].desc.wTotalLength);
|
|
|
|
len = max(len, old_length);
|
|
|
|
}
|
|
|
|
|
|
|
|
buf = kmalloc(len, GFP_NOIO);
|
|
|
|
if (!buf)
|
|
|
|
/* assume the worst */
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
for (index = 0; index < udev->descriptor.bNumConfigurations; index++) {
|
|
|
|
old_length = le16_to_cpu(udev->config[index].desc.wTotalLength);
|
|
|
|
length = usb_get_descriptor(udev, USB_DT_CONFIG, index, buf,
|
|
|
|
old_length);
|
|
|
|
if (length != old_length) {
|
|
|
|
dev_dbg(&udev->dev, "config index %d, error %d\n",
|
|
|
|
index, length);
|
|
|
|
changed = 1;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (memcmp(buf, udev->rawdescriptors[index], old_length)
|
|
|
|
!= 0) {
|
|
|
|
dev_dbg(&udev->dev, "config index %d changed (#%d)\n",
|
|
|
|
index,
|
|
|
|
((struct usb_config_descriptor *) buf)->
|
|
|
|
bConfigurationValue);
|
|
|
|
changed = 1;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
kfree(buf);
|
|
|
|
return changed;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
{
|
2017-08-01 22:41:56 +08:00
|
|
|
int status = -ENODEV;
|
|
|
|
int 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;
|
2021-11-23 18:16:56 +08:00
|
|
|
bool retry_locked;
|
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)
|
2022-06-07 19:45:22 +08:00
|
|
|
&& !usb_port_is_power_on(hub, portstatus)
|
2015-01-22 02:09:58 +08:00
|
|
|
&& !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;
|
2021-11-16 06:16:30 +08:00
|
|
|
|
2020-09-28 23:20:50 +08:00
|
|
|
for (i = 0; i < PORT_INIT_TRIES; i++) {
|
2022-11-07 15:27:54 +08:00
|
|
|
if (hub_port_stop_enumerate(hub, port1, i)) {
|
|
|
|
status = -ENODEV;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2021-11-23 18:16:56 +08:00
|
|
|
usb_lock_port(port_dev);
|
|
|
|
mutex_lock(hcd->address0_mutex);
|
|
|
|
retry_locked = true;
|
2005-04-17 06:20:36 +08:00
|
|
|
/* 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");
|
2021-11-23 18:16:56 +08:00
|
|
|
mutex_unlock(hcd->address0_mutex);
|
|
|
|
usb_unlock_port(port_dev);
|
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;
|
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 */
|
USB: core: Fix race by not overwriting udev->descriptor in hub_port_init()
Syzbot reported an out-of-bounds read in sysfs.c:read_descriptors():
BUG: KASAN: slab-out-of-bounds in read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883
Read of size 8 at addr ffff88801e78b8c8 by task udevd/5011
CPU: 0 PID: 5011 Comm: udevd Not tainted 6.4.0-rc6-syzkaller-00195-g40f71e7cd3c6 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106
print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351
print_report mm/kasan/report.c:462 [inline]
kasan_report+0x11c/0x130 mm/kasan/report.c:572
read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883
...
Allocated by task 758:
...
__do_kmalloc_node mm/slab_common.c:966 [inline]
__kmalloc+0x5e/0x190 mm/slab_common.c:979
kmalloc include/linux/slab.h:563 [inline]
kzalloc include/linux/slab.h:680 [inline]
usb_get_configuration+0x1f7/0x5170 drivers/usb/core/config.c:887
usb_enumerate_device drivers/usb/core/hub.c:2407 [inline]
usb_new_device+0x12b0/0x19d0 drivers/usb/core/hub.c:2545
As analyzed by Khazhy Kumykov, the cause of this bug is a race between
read_descriptors() and hub_port_init(): The first routine uses a field
in udev->descriptor, not expecting it to change, while the second
overwrites it.
Prior to commit 45bf39f8df7f ("USB: core: Don't hold device lock while
reading the "descriptors" sysfs file") this race couldn't occur,
because the routines were mutually exclusive thanks to the device
locking. Removing that locking from read_descriptors() exposed it to
the race.
The best way to fix the bug is to keep hub_port_init() from changing
udev->descriptor once udev has been initialized and registered.
Drivers expect the descriptors stored in the kernel to be immutable;
we should not undermine this expectation. In fact, this change should
have been made long ago.
So now hub_port_init() will take an additional argument, specifying a
buffer in which to store the device descriptor it reads. (If udev has
not yet been initialized, the buffer pointer will be NULL and then
hub_port_init() will store the device descriptor in udev as before.)
This eliminates the data race responsible for the out-of-bounds read.
The changes to hub_port_init() appear more extensive than they really
are, because of indentation changes resulting from an attempt to avoid
writing to other parts of the usb_device structure after it has been
initialized. Similar changes should be made to the code that reads
the BOS descriptor, but that can be handled in a separate patch later
on. This patch is sufficient to fix the bug found by syzbot.
Reported-and-tested-by: syzbot+18996170f8096c6174d0@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/linux-usb/000000000000c0ffe505fe86c9ca@google.com/#r
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Khazhy Kumykov <khazhy@google.com>
Fixes: 45bf39f8df7f ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/b958b47a-9a46-4c22-a9f9-e42e42c31251@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-05 03:14:14 +08:00
|
|
|
status = hub_port_init(hub, udev, port1, i, NULL);
|
2005-04-17 06:20:36 +08:00
|
|
|
if (status < 0)
|
|
|
|
goto loop;
|
|
|
|
|
2021-11-16 06:16:30 +08:00
|
|
|
mutex_unlock(hcd->address0_mutex);
|
2021-11-23 18:16:56 +08:00
|
|
|
usb_unlock_port(port_dev);
|
|
|
|
retry_locked = false;
|
2021-11-16 06:16:30 +08:00
|
|
|
|
2010-07-22 06:05:01 +08:00
|
|
|
if (udev->quirks & USB_QUIRK_DELAY_INIT)
|
2017-09-05 16:40:56 +08:00
|
|
|
msleep(2000);
|
2010-07-22 06:05:01 +08:00
|
|
|
|
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;
|
|
|
|
|
2017-11-02 16:57:40 +08:00
|
|
|
status = usb_get_std_status(udev, USB_RECIP_DEVICE, 0,
|
2005-04-17 06:20:36 +08:00
|
|
|
&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);
|
2021-11-23 18:16:56 +08:00
|
|
|
if (retry_locked) {
|
|
|
|
mutex_unlock(hcd->address0_mutex);
|
|
|
|
usb_unlock_port(port_dev);
|
|
|
|
}
|
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;
|
2017-11-09 20:16:46 +08:00
|
|
|
|
|
|
|
/* When halfway through our retry count, power-cycle the port */
|
2020-09-28 23:20:50 +08:00
|
|
|
if (i == (PORT_INIT_TRIES - 1) / 2) {
|
2017-11-09 20:16:46 +08:00
|
|
|
dev_info(&port_dev->dev, "attempt power cycle\n");
|
|
|
|
usb_hub_set_port_power(hdev, hub, port1, false);
|
|
|
|
msleep(2 * hub_power_on_good_delay(hub));
|
|
|
|
usb_hub_set_port_power(hdev, hub, port1, true);
|
|
|
|
msleep(hub_power_on_good_delay(hub));
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
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);
|
2017-08-01 22:41:56 +08:00
|
|
|
if (hcd->driver->relinquish_port && !hub->hdev->parent) {
|
|
|
|
if (status != -ENOTCONN && status != -ENODEV)
|
|
|
|
hcd->driver->relinquish_port(hcd, port1);
|
|
|
|
}
|
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;
|
2023-08-05 03:12:21 +08:00
|
|
|
struct usb_device_descriptor *descr;
|
2014-05-21 09:09:15 +08:00
|
|
|
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) {
|
2019-10-09 12:46:47 +08:00
|
|
|
/*
|
|
|
|
* USB-3 connections are initialized automatically by
|
|
|
|
* the hostcontroller hardware. Therefore check for
|
|
|
|
* changed device descriptors before resuscitating the
|
|
|
|
* device.
|
|
|
|
*/
|
2023-08-05 03:12:21 +08:00
|
|
|
descr = usb_get_device_descriptor(udev);
|
|
|
|
if (IS_ERR(descr)) {
|
2019-10-09 12:46:47 +08:00
|
|
|
dev_dbg(&udev->dev,
|
2023-08-05 03:12:21 +08:00
|
|
|
"can't read device descriptor %ld\n",
|
|
|
|
PTR_ERR(descr));
|
2019-10-09 12:46:47 +08:00
|
|
|
} else {
|
2023-08-05 03:12:21 +08:00
|
|
|
if (descriptors_changed(udev, descr,
|
2019-10-09 12:46:47 +08:00
|
|
|
udev->bos)) {
|
|
|
|
dev_dbg(&udev->dev,
|
|
|
|
"device descriptor has changed\n");
|
|
|
|
} else {
|
|
|
|
status = 0; /* Nothing to do */
|
|
|
|
}
|
2023-08-05 03:12:21 +08:00
|
|
|
kfree(descr);
|
2019-10-09 12:46:47 +08:00
|
|
|
}
|
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
|
|
|
}
|
|
|
|
|
2018-09-21 01:17:54 +08:00
|
|
|
/* Handle notifying userspace about hub over-current events */
|
|
|
|
static void port_over_current_notify(struct usb_port *port_dev)
|
|
|
|
{
|
2022-05-12 23:37:14 +08:00
|
|
|
char *envp[3] = { NULL, NULL, NULL };
|
2018-09-21 01:17:54 +08:00
|
|
|
struct device *hub_dev;
|
|
|
|
char *port_dev_path;
|
|
|
|
|
|
|
|
sysfs_notify(&port_dev->dev.kobj, NULL, "over_current_count");
|
|
|
|
|
|
|
|
hub_dev = port_dev->dev.parent;
|
|
|
|
|
|
|
|
if (!hub_dev)
|
|
|
|
return;
|
|
|
|
|
|
|
|
port_dev_path = kobject_get_path(&port_dev->dev.kobj, GFP_KERNEL);
|
|
|
|
if (!port_dev_path)
|
|
|
|
return;
|
|
|
|
|
|
|
|
envp[0] = kasprintf(GFP_KERNEL, "OVER_CURRENT_PORT=%s", port_dev_path);
|
|
|
|
if (!envp[0])
|
2022-05-12 23:37:14 +08:00
|
|
|
goto exit;
|
2018-09-21 01:17:54 +08:00
|
|
|
|
|
|
|
envp[1] = kasprintf(GFP_KERNEL, "OVER_CURRENT_COUNT=%u",
|
|
|
|
port_dev->over_current_count);
|
|
|
|
if (!envp[1])
|
|
|
|
goto exit;
|
|
|
|
|
|
|
|
kobject_uevent_env(&hub_dev->kobj, KOBJ_CHANGE, envp);
|
|
|
|
|
|
|
|
exit:
|
2022-05-12 23:37:14 +08:00
|
|
|
kfree(envp[1]);
|
2018-09-21 01:17:54 +08:00
|
|
|
kfree(envp[0]);
|
2018-10-03 17:59:57 +08:00
|
|
|
kfree(port_dev_path);
|
2018-09-21 01:17:54 +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;
|
2021-12-10 19:16:53 +08:00
|
|
|
int i = 0;
|
2014-05-21 09:09:15 +08:00
|
|
|
|
|
|
|
connect_change = test_bit(port1, hub->change_bits);
|
|
|
|
clear_bit(port1, hub->event_bits);
|
|
|
|
clear_bit(port1, hub->wakeup_bits);
|
|
|
|
|
2022-06-07 19:45:22 +08:00
|
|
|
if (usb_hub_port_status(hub, port1, &portstatus, &portchange) < 0)
|
2014-05-21 09:09:15 +08:00
|
|
|
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;
|
2018-03-20 18:17:13 +08:00
|
|
|
port_dev->over_current_count++;
|
2018-09-21 01:17:54 +08:00
|
|
|
port_over_current_notify(port_dev);
|
2014-05-21 09:09:15 +08:00
|
|
|
|
2018-03-20 18:17:13 +08:00
|
|
|
dev_dbg(&port_dev->dev, "over-current change #%u\n",
|
|
|
|
port_dev->over_current_count);
|
2014-05-21 09:09:15 +08:00
|
|
|
usb_clear_port_feature(hdev, port1,
|
|
|
|
USB_PORT_FEAT_C_OVER_CURRENT);
|
|
|
|
msleep(100); /* Cool down */
|
|
|
|
hub_power_on(hub, true);
|
2022-06-07 19:45:22 +08:00
|
|
|
usb_hub_port_status(hub, port1, &status, &unused);
|
2014-05-21 09:09:15 +08:00
|
|
|
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
|
|
|
|
2022-11-07 15:27:54 +08:00
|
|
|
/* skip port actions if ignore_event and early_stop are true */
|
|
|
|
if (port_dev->ignore_event && port_dev->early_stop)
|
|
|
|
return;
|
|
|
|
|
2014-05-21 09:09:15 +08:00
|
|
|
if (hub_handle_remote_wakeup(hub, port1, portstatus, portchange))
|
|
|
|
connect_change = 1;
|
|
|
|
|
|
|
|
/*
|
2021-12-10 19:16:53 +08:00
|
|
|
* Avoid trying to recover a USB3 SS.Inactive port with a warm reset if
|
|
|
|
* the device was disconnected. A 12ms disconnect detect timer in
|
|
|
|
* SS.Inactive state transitions the port to RxDetect automatically.
|
|
|
|
* SS.Inactive link error state is common during device disconnect.
|
2014-05-21 09:09:15 +08:00
|
|
|
*/
|
2021-12-10 19:16:53 +08:00
|
|
|
while (hub_port_warm_reset_required(hub, port1, portstatus)) {
|
|
|
|
if ((i++ < DETECT_DISCONNECT_TRIES) && udev) {
|
|
|
|
u16 unused;
|
|
|
|
|
|
|
|
msleep(20);
|
2022-06-07 19:45:22 +08:00
|
|
|
usb_hub_port_status(hub, port1, &portstatus, &unused);
|
2021-12-10 19:16:53 +08:00
|
|
|
dev_dbg(&port_dev->dev, "Wait for inactive link disconnect detect\n");
|
|
|
|
continue;
|
|
|
|
} else if (!udev || !(portstatus & USB_PORT_STAT_CONNECTION)
|
2014-05-21 09:09:15 +08:00
|
|
|
|| udev->state == USB_STATE_NOTATTACHED) {
|
2021-12-10 19:16:53 +08:00
|
|
|
dev_dbg(&port_dev->dev, "do warm reset, port only\n");
|
2014-05-21 09:09:15 +08:00
|
|
|
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 {
|
2021-12-10 19:16:53 +08:00
|
|
|
dev_dbg(&port_dev->dev, "do warm reset, full device\n");
|
2015-01-26 23:30:39 +08:00
|
|
|
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;
|
|
|
|
}
|
2021-12-10 19:16:53 +08:00
|
|
|
break;
|
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
|
|
|
|
2019-12-05 08:52:47 +08:00
|
|
|
kcov_remote_start_usb((u64)hdev->bus->busnum);
|
|
|
|
|
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);
|
2024-03-16 01:04:50 +08:00
|
|
|
hub_put(hub);
|
2019-12-05 08:52:47 +08:00
|
|
|
|
|
|
|
kcov_remote_stop();
|
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[] = {
|
2020-05-15 06:02:46 +08:00
|
|
|
{ .match_flags = USB_DEVICE_ID_MATCH_VENDOR
|
|
|
|
| USB_DEVICE_ID_MATCH_PRODUCT
|
|
|
|
| USB_DEVICE_ID_MATCH_INT_CLASS,
|
USB: hub: Fix the broken detection of USB3 device in SMSC hub
Renesas R-Car H3ULCB + Kingfisher Infotainment Board is either not able
to detect the USB3.0 mass storage devices or is detecting those as
USB2.0 high speed devices.
The explanation given by Renesas is that, due to a HW issue, the XHCI
driver does not wake up after going to sleep on connecting a USB3.0
device.
In order to mitigate that, disable the auto-suspend feature
specifically for SMSC hubs from hub_probe() function, as a quirk.
Renesas Kingfisher Infotainment Board has two USB3.0 ports (CN2) which
are connected via USB5534B 4-port SuperSpeed/Hi-Speed, low-power,
configurable hub controller.
[1] SanDisk USB 3.0 device detected as USB-2.0 before the patch
[ 74.036390] usb 5-1.1: new high-speed USB device number 4 using xhci-hcd
[ 74.061598] usb 5-1.1: New USB device found, idVendor=0781, idProduct=5581, bcdDevice= 1.00
[ 74.069976] usb 5-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 74.077303] usb 5-1.1: Product: Ultra
[ 74.080980] usb 5-1.1: Manufacturer: SanDisk
[ 74.085263] usb 5-1.1: SerialNumber: 4C530001110208116550
[2] SanDisk USB 3.0 device detected as USB-3.0 after the patch
[ 34.565078] usb 6-1.1: new SuperSpeed Gen 1 USB device number 3 using xhci-hcd
[ 34.588719] usb 6-1.1: New USB device found, idVendor=0781, idProduct=5581, bcdDevice= 1.00
[ 34.597098] usb 6-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 34.604430] usb 6-1.1: Product: Ultra
[ 34.608110] usb 6-1.1: Manufacturer: SanDisk
[ 34.612397] usb 6-1.1: SerialNumber: 4C530001110208116550
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Hardik Gajjar <hgajjar@de.adit-jv.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/1580989763-32291-1-git-send-email-hgajjar@de.adit-jv.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-02-06 19:49:23 +08:00
|
|
|
.idVendor = USB_VENDOR_SMSC,
|
2020-05-15 06:02:46 +08:00
|
|
|
.idProduct = USB_PRODUCT_USB5534B,
|
USB: hub: Fix the broken detection of USB3 device in SMSC hub
Renesas R-Car H3ULCB + Kingfisher Infotainment Board is either not able
to detect the USB3.0 mass storage devices or is detecting those as
USB2.0 high speed devices.
The explanation given by Renesas is that, due to a HW issue, the XHCI
driver does not wake up after going to sleep on connecting a USB3.0
device.
In order to mitigate that, disable the auto-suspend feature
specifically for SMSC hubs from hub_probe() function, as a quirk.
Renesas Kingfisher Infotainment Board has two USB3.0 ports (CN2) which
are connected via USB5534B 4-port SuperSpeed/Hi-Speed, low-power,
configurable hub controller.
[1] SanDisk USB 3.0 device detected as USB-2.0 before the patch
[ 74.036390] usb 5-1.1: new high-speed USB device number 4 using xhci-hcd
[ 74.061598] usb 5-1.1: New USB device found, idVendor=0781, idProduct=5581, bcdDevice= 1.00
[ 74.069976] usb 5-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 74.077303] usb 5-1.1: Product: Ultra
[ 74.080980] usb 5-1.1: Manufacturer: SanDisk
[ 74.085263] usb 5-1.1: SerialNumber: 4C530001110208116550
[2] SanDisk USB 3.0 device detected as USB-3.0 after the patch
[ 34.565078] usb 6-1.1: new SuperSpeed Gen 1 USB device number 3 using xhci-hcd
[ 34.588719] usb 6-1.1: New USB device found, idVendor=0781, idProduct=5581, bcdDevice= 1.00
[ 34.597098] usb 6-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 34.604430] usb 6-1.1: Product: Ultra
[ 34.608110] usb 6-1.1: Manufacturer: SanDisk
[ 34.612397] usb 6-1.1: SerialNumber: 4C530001110208116550
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Hardik Gajjar <hgajjar@de.adit-jv.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/1580989763-32291-1-git-send-email-hgajjar@de.adit-jv.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-02-06 19:49:23 +08:00
|
|
|
.bInterfaceClass = USB_CLASS_HUB,
|
|
|
|
.driver_info = HUB_QUIRK_DISABLE_AUTOSUSPEND},
|
2021-06-14 23:55:23 +08:00
|
|
|
{ .match_flags = USB_DEVICE_ID_MATCH_VENDOR
|
|
|
|
| USB_DEVICE_ID_MATCH_PRODUCT,
|
|
|
|
.idVendor = USB_VENDOR_CYPRESS,
|
|
|
|
.idProduct = USB_PRODUCT_CY7C65632,
|
|
|
|
.driver_info = HUB_QUIRK_DISABLE_AUTOSUSPEND},
|
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},
|
2022-12-19 20:47:59 +08:00
|
|
|
{ .match_flags = USB_DEVICE_ID_MATCH_VENDOR
|
|
|
|
| USB_DEVICE_ID_MATCH_PRODUCT,
|
|
|
|
.idVendor = USB_VENDOR_TEXAS_INSTRUMENTS,
|
|
|
|
.idProduct = USB_PRODUCT_TUSB8041_USB2,
|
|
|
|
.driver_info = HUB_QUIRK_DISABLE_AUTOSUSPEND},
|
|
|
|
{ .match_flags = USB_DEVICE_ID_MATCH_VENDOR
|
|
|
|
| USB_DEVICE_ID_MATCH_PRODUCT,
|
|
|
|
.idVendor = USB_VENDOR_TEXAS_INSTRUMENTS,
|
|
|
|
.idProduct = USB_PRODUCT_TUSB8041_USB3,
|
|
|
|
.driver_info = HUB_QUIRK_DISABLE_AUTOSUSPEND},
|
2023-12-06 02:18:29 +08:00
|
|
|
{ .match_flags = USB_DEVICE_ID_MATCH_VENDOR
|
|
|
|
| USB_DEVICE_ID_MATCH_PRODUCT,
|
|
|
|
.idVendor = USB_VENDOR_MICROCHIP,
|
|
|
|
.idProduct = USB_PRODUCT_USB4913,
|
|
|
|
.driver_info = HUB_QUIRK_REDUCE_FRAME_INTR_BINTERVAL},
|
|
|
|
{ .match_flags = USB_DEVICE_ID_MATCH_VENDOR
|
|
|
|
| USB_DEVICE_ID_MATCH_PRODUCT,
|
|
|
|
.idVendor = USB_VENDOR_MICROCHIP,
|
|
|
|
.idProduct = USB_PRODUCT_USB4914,
|
|
|
|
.driver_info = HUB_QUIRK_REDUCE_FRAME_INTR_BINTERVAL},
|
|
|
|
{ .match_flags = USB_DEVICE_ID_MATCH_VENDOR
|
|
|
|
| USB_DEVICE_ID_MATCH_PRODUCT,
|
|
|
|
.idVendor = USB_VENDOR_MICROCHIP,
|
|
|
|
.idProduct = USB_PRODUCT_USB4915,
|
|
|
|
.driver_info = HUB_QUIRK_REDUCE_FRAME_INTR_BINTERVAL},
|
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-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);
|
USB: core: Fix race by not overwriting udev->descriptor in hub_port_init()
Syzbot reported an out-of-bounds read in sysfs.c:read_descriptors():
BUG: KASAN: slab-out-of-bounds in read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883
Read of size 8 at addr ffff88801e78b8c8 by task udevd/5011
CPU: 0 PID: 5011 Comm: udevd Not tainted 6.4.0-rc6-syzkaller-00195-g40f71e7cd3c6 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106
print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351
print_report mm/kasan/report.c:462 [inline]
kasan_report+0x11c/0x130 mm/kasan/report.c:572
read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883
...
Allocated by task 758:
...
__do_kmalloc_node mm/slab_common.c:966 [inline]
__kmalloc+0x5e/0x190 mm/slab_common.c:979
kmalloc include/linux/slab.h:563 [inline]
kzalloc include/linux/slab.h:680 [inline]
usb_get_configuration+0x1f7/0x5170 drivers/usb/core/config.c:887
usb_enumerate_device drivers/usb/core/hub.c:2407 [inline]
usb_new_device+0x12b0/0x19d0 drivers/usb/core/hub.c:2545
As analyzed by Khazhy Kumykov, the cause of this bug is a race between
read_descriptors() and hub_port_init(): The first routine uses a field
in udev->descriptor, not expecting it to change, while the second
overwrites it.
Prior to commit 45bf39f8df7f ("USB: core: Don't hold device lock while
reading the "descriptors" sysfs file") this race couldn't occur,
because the routines were mutually exclusive thanks to the device
locking. Removing that locking from read_descriptors() exposed it to
the race.
The best way to fix the bug is to keep hub_port_init() from changing
udev->descriptor once udev has been initialized and registered.
Drivers expect the descriptors stored in the kernel to be immutable;
we should not undermine this expectation. In fact, this change should
have been made long ago.
So now hub_port_init() will take an additional argument, specifying a
buffer in which to store the device descriptor it reads. (If udev has
not yet been initialized, the buffer pointer will be NULL and then
hub_port_init() will store the device descriptor in udev as before.)
This eliminates the data race responsible for the out-of-bounds read.
The changes to hub_port_init() appear more extensive than they really
are, because of indentation changes resulting from an attempt to avoid
writing to other parts of the usb_device structure after it has been
initialized. Similar changes should be made to the code that reads
the BOS descriptor, but that can be handled in a separate patch later
on. This patch is sufficient to fix the bug found by syzbot.
Reported-and-tested-by: syzbot+18996170f8096c6174d0@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/linux-usb/000000000000c0ffe505fe86c9ca@google.com/#r
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Khazhy Kumykov <khazhy@google.com>
Fixes: 45bf39f8df7f ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/b958b47a-9a46-4c22-a9f9-e42e42c31251@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-05 03:14:14 +08:00
|
|
|
struct usb_device_descriptor 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.
|
|
|
|
*/
|
2019-01-12 03:54:25 +08:00
|
|
|
usb_disable_usb2_hardware_lpm(udev);
|
2013-09-30 22:26:29 +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
|
|
|
|
2021-11-16 06:16:30 +08:00
|
|
|
mutex_lock(hcd->address0_mutex);
|
|
|
|
|
2020-09-28 23:20:50 +08:00
|
|
|
for (i = 0; i < PORT_INIT_TRIES; ++i) {
|
2022-11-07 15:27:54 +08:00
|
|
|
if (hub_port_stop_enumerate(parent_hub, port1, i)) {
|
|
|
|
ret = -ENODEV;
|
|
|
|
break;
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/* 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);
|
USB: core: Fix race by not overwriting udev->descriptor in hub_port_init()
Syzbot reported an out-of-bounds read in sysfs.c:read_descriptors():
BUG: KASAN: slab-out-of-bounds in read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883
Read of size 8 at addr ffff88801e78b8c8 by task udevd/5011
CPU: 0 PID: 5011 Comm: udevd Not tainted 6.4.0-rc6-syzkaller-00195-g40f71e7cd3c6 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106
print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351
print_report mm/kasan/report.c:462 [inline]
kasan_report+0x11c/0x130 mm/kasan/report.c:572
read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883
...
Allocated by task 758:
...
__do_kmalloc_node mm/slab_common.c:966 [inline]
__kmalloc+0x5e/0x190 mm/slab_common.c:979
kmalloc include/linux/slab.h:563 [inline]
kzalloc include/linux/slab.h:680 [inline]
usb_get_configuration+0x1f7/0x5170 drivers/usb/core/config.c:887
usb_enumerate_device drivers/usb/core/hub.c:2407 [inline]
usb_new_device+0x12b0/0x19d0 drivers/usb/core/hub.c:2545
As analyzed by Khazhy Kumykov, the cause of this bug is a race between
read_descriptors() and hub_port_init(): The first routine uses a field
in udev->descriptor, not expecting it to change, while the second
overwrites it.
Prior to commit 45bf39f8df7f ("USB: core: Don't hold device lock while
reading the "descriptors" sysfs file") this race couldn't occur,
because the routines were mutually exclusive thanks to the device
locking. Removing that locking from read_descriptors() exposed it to
the race.
The best way to fix the bug is to keep hub_port_init() from changing
udev->descriptor once udev has been initialized and registered.
Drivers expect the descriptors stored in the kernel to be immutable;
we should not undermine this expectation. In fact, this change should
have been made long ago.
So now hub_port_init() will take an additional argument, specifying a
buffer in which to store the device descriptor it reads. (If udev has
not yet been initialized, the buffer pointer will be NULL and then
hub_port_init() will store the device descriptor in udev as before.)
This eliminates the data race responsible for the out-of-bounds read.
The changes to hub_port_init() appear more extensive than they really
are, because of indentation changes resulting from an attempt to avoid
writing to other parts of the usb_device structure after it has been
initialized. Similar changes should be made to the code that reads
the BOS descriptor, but that can be handled in a separate patch later
on. This patch is sufficient to fix the bug found by syzbot.
Reported-and-tested-by: syzbot+18996170f8096c6174d0@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/linux-usb/000000000000c0ffe505fe86c9ca@google.com/#r
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Khazhy Kumykov <khazhy@google.com>
Fixes: 45bf39f8df7f ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/b958b47a-9a46-4c22-a9f9-e42e42c31251@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-05 03:14:14 +08:00
|
|
|
ret = hub_port_init(parent_hub, udev, port1, i, &descriptor);
|
2007-05-04 23:55:54 +08:00
|
|
|
if (ret >= 0 || ret == -ENOTCONN || ret == -ENODEV)
|
2005-04-17 06:20:36 +08:00
|
|
|
break;
|
|
|
|
}
|
2021-11-16 06:16:30 +08:00
|
|
|
mutex_unlock(hcd->address0_mutex);
|
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");
|
|
|
|
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. */
|
2019-01-12 03:54:24 +08:00
|
|
|
usb_enable_usb2_hardware_lpm(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);
|
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
|
|
|
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
|
usb: Allow USB device to be warm reset in suspended state
On Dell WD15 dock, sometimes USB ethernet cannot be detected after plugging
cable to the ethernet port, the hub and roothub get runtime resumed and
runtime suspended immediately:
...
[ 433.315169] xhci_hcd 0000:3a:00.0: hcd_pci_runtime_resume: 0
[ 433.315204] usb usb4: usb auto-resume
[ 433.315226] hub 4-0:1.0: hub_resume
[ 433.315239] xhci_hcd 0000:3a:00.0: Get port status 4-1 read: 0x10202e2, return 0x10343
[ 433.315264] usb usb4-port1: status 0343 change 0001
[ 433.315279] xhci_hcd 0000:3a:00.0: clear port1 connect change, portsc: 0x10002e2
[ 433.315293] xhci_hcd 0000:3a:00.0: Get port status 4-2 read: 0x2a0, return 0x2a0
[ 433.317012] xhci_hcd 0000:3a:00.0: xhci_hub_status_data: stopping port polling.
[ 433.422282] xhci_hcd 0000:3a:00.0: Get port status 4-1 read: 0x10002e2, return 0x343
[ 433.422307] usb usb4-port1: do warm reset
[ 433.422311] usb 4-1: device reset not allowed in state 8
[ 433.422339] hub 4-0:1.0: state 7 ports 2 chg 0002 evt 0000
[ 433.422346] xhci_hcd 0000:3a:00.0: Get port status 4-1 read: 0x10002e2, return 0x343
[ 433.422356] usb usb4-port1: do warm reset
[ 433.422358] usb 4-1: device reset not allowed in state 8
[ 433.422428] xhci_hcd 0000:3a:00.0: set port remote wake mask, actual port 0 status = 0xf0002e2
[ 433.422455] xhci_hcd 0000:3a:00.0: set port remote wake mask, actual port 1 status = 0xe0002a0
[ 433.422465] hub 4-0:1.0: hub_suspend
[ 433.422475] usb usb4: bus auto-suspend, wakeup 1
[ 433.426161] xhci_hcd 0000:3a:00.0: xhci_hub_status_data: stopping port polling.
[ 433.466209] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
[ 433.510204] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
[ 433.554051] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
[ 433.598235] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
[ 433.642154] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
[ 433.686204] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
[ 433.730205] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
[ 433.774203] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
[ 433.818207] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
[ 433.862040] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
[ 433.862053] xhci_hcd 0000:3a:00.0: xhci_hub_status_data: stopping port polling.
[ 433.862077] xhci_hcd 0000:3a:00.0: xhci_suspend: stopping port polling.
[ 433.862096] xhci_hcd 0000:3a:00.0: // Setting command ring address to 0x8578fc001
[ 433.862312] xhci_hcd 0000:3a:00.0: hcd_pci_runtime_suspend: 0
[ 433.862445] xhci_hcd 0000:3a:00.0: PME# enabled
[ 433.902376] xhci_hcd 0000:3a:00.0: restoring config space at offset 0xc (was 0x0, writing 0x20)
[ 433.902395] xhci_hcd 0000:3a:00.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100403)
[ 433.902490] xhci_hcd 0000:3a:00.0: PME# disabled
[ 433.902504] xhci_hcd 0000:3a:00.0: enabling bus mastering
[ 433.902547] xhci_hcd 0000:3a:00.0: // Setting command ring address to 0x8578fc001
[ 433.902649] pcieport 0000:00:1b.0: PME: Spurious native interrupt!
[ 433.902839] xhci_hcd 0000:3a:00.0: Port change event, 4-1, id 3, portsc: 0xb0202e2
[ 433.902842] xhci_hcd 0000:3a:00.0: resume root hub
[ 433.902845] xhci_hcd 0000:3a:00.0: handle_port_status: starting port polling.
[ 433.902877] xhci_hcd 0000:3a:00.0: xhci_resume: starting port polling.
[ 433.902889] xhci_hcd 0000:3a:00.0: xhci_hub_status_data: stopping port polling.
[ 433.902891] xhci_hcd 0000:3a:00.0: hcd_pci_runtime_resume: 0
[ 433.902919] usb usb4: usb wakeup-resume
[ 433.902942] usb usb4: usb auto-resume
[ 433.902966] hub 4-0:1.0: hub_resume
...
As Mathias pointed out, the hub enters Cold Attach Status state and
requires a warm reset. However usb_reset_device() bails out early when
the device is in suspended state, as its callers port_event() and
hub_event() don't always resume the device.
Since there's nothing wrong to reset a suspended device, allow
usb_reset_device() to do so to solve the issue.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20191106062710.29880-1-kai.heng.feng@canonical.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-11-06 14:27:10 +08:00
|
|
|
* @udev: device to reset (not in NOTATTACHED state)
|
2006-06-02 01:33:42 +08:00
|
|
|
*
|
|
|
|
* 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().
|
2022-08-27 03:31:32 +08:00
|
|
|
* However, if a reset is already in progress (for instance, if a
|
2022-09-01 22:36:34 +08:00
|
|
|
* driver doesn't have pre_reset() or post_reset() callbacks, and while
|
2022-08-27 03:31:32 +08:00
|
|
|
* being unbound or re-bound during the ongoing reset its disconnect()
|
|
|
|
* or probe() routine tries to perform a second, nested reset), the
|
|
|
|
* routine returns -EINPROGRESS.
|
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
|
|
|
|
usb: Allow USB device to be warm reset in suspended state
On Dell WD15 dock, sometimes USB ethernet cannot be detected after plugging
cable to the ethernet port, the hub and roothub get runtime resumed and
runtime suspended immediately:
...
[ 433.315169] xhci_hcd 0000:3a:00.0: hcd_pci_runtime_resume: 0
[ 433.315204] usb usb4: usb auto-resume
[ 433.315226] hub 4-0:1.0: hub_resume
[ 433.315239] xhci_hcd 0000:3a:00.0: Get port status 4-1 read: 0x10202e2, return 0x10343
[ 433.315264] usb usb4-port1: status 0343 change 0001
[ 433.315279] xhci_hcd 0000:3a:00.0: clear port1 connect change, portsc: 0x10002e2
[ 433.315293] xhci_hcd 0000:3a:00.0: Get port status 4-2 read: 0x2a0, return 0x2a0
[ 433.317012] xhci_hcd 0000:3a:00.0: xhci_hub_status_data: stopping port polling.
[ 433.422282] xhci_hcd 0000:3a:00.0: Get port status 4-1 read: 0x10002e2, return 0x343
[ 433.422307] usb usb4-port1: do warm reset
[ 433.422311] usb 4-1: device reset not allowed in state 8
[ 433.422339] hub 4-0:1.0: state 7 ports 2 chg 0002 evt 0000
[ 433.422346] xhci_hcd 0000:3a:00.0: Get port status 4-1 read: 0x10002e2, return 0x343
[ 433.422356] usb usb4-port1: do warm reset
[ 433.422358] usb 4-1: device reset not allowed in state 8
[ 433.422428] xhci_hcd 0000:3a:00.0: set port remote wake mask, actual port 0 status = 0xf0002e2
[ 433.422455] xhci_hcd 0000:3a:00.0: set port remote wake mask, actual port 1 status = 0xe0002a0
[ 433.422465] hub 4-0:1.0: hub_suspend
[ 433.422475] usb usb4: bus auto-suspend, wakeup 1
[ 433.426161] xhci_hcd 0000:3a:00.0: xhci_hub_status_data: stopping port polling.
[ 433.466209] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
[ 433.510204] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
[ 433.554051] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
[ 433.598235] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
[ 433.642154] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
[ 433.686204] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
[ 433.730205] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
[ 433.774203] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
[ 433.818207] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
[ 433.862040] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting
[ 433.862053] xhci_hcd 0000:3a:00.0: xhci_hub_status_data: stopping port polling.
[ 433.862077] xhci_hcd 0000:3a:00.0: xhci_suspend: stopping port polling.
[ 433.862096] xhci_hcd 0000:3a:00.0: // Setting command ring address to 0x8578fc001
[ 433.862312] xhci_hcd 0000:3a:00.0: hcd_pci_runtime_suspend: 0
[ 433.862445] xhci_hcd 0000:3a:00.0: PME# enabled
[ 433.902376] xhci_hcd 0000:3a:00.0: restoring config space at offset 0xc (was 0x0, writing 0x20)
[ 433.902395] xhci_hcd 0000:3a:00.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100403)
[ 433.902490] xhci_hcd 0000:3a:00.0: PME# disabled
[ 433.902504] xhci_hcd 0000:3a:00.0: enabling bus mastering
[ 433.902547] xhci_hcd 0000:3a:00.0: // Setting command ring address to 0x8578fc001
[ 433.902649] pcieport 0000:00:1b.0: PME: Spurious native interrupt!
[ 433.902839] xhci_hcd 0000:3a:00.0: Port change event, 4-1, id 3, portsc: 0xb0202e2
[ 433.902842] xhci_hcd 0000:3a:00.0: resume root hub
[ 433.902845] xhci_hcd 0000:3a:00.0: handle_port_status: starting port polling.
[ 433.902877] xhci_hcd 0000:3a:00.0: xhci_resume: starting port polling.
[ 433.902889] xhci_hcd 0000:3a:00.0: xhci_hub_status_data: stopping port polling.
[ 433.902891] xhci_hcd 0000:3a:00.0: hcd_pci_runtime_resume: 0
[ 433.902919] usb usb4: usb wakeup-resume
[ 433.902942] usb usb4: usb auto-resume
[ 433.902966] hub 4-0:1.0: hub_resume
...
As Mathias pointed out, the hub enters Cold Attach Status state and
requires a warm reset. However usb_reset_device() bails out early when
the device is in suspended state, as its callers port_event() and
hub_event() don't always resume the device.
Since there's nothing wrong to reset a suspended device, allow
usb_reset_device() to do so to solve the issue.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20191106062710.29880-1-kai.heng.feng@canonical.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-11-06 14:27:10 +08:00
|
|
|
if (udev->state == USB_STATE_NOTATTACHED) {
|
2006-06-02 01:33:42 +08:00
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2022-08-27 03:31:32 +08:00
|
|
|
if (udev->reset_in_progress)
|
|
|
|
return -EINPROGRESS;
|
|
|
|
udev->reset_in_progress = 1;
|
|
|
|
|
2014-05-21 09:09:26 +08:00
|
|
|
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
|
|
|
}
|
|
|
|
}
|
USB: core: Don't unbind interfaces following device reset failure
The SCSI core does not like to have devices or hosts unregistered
while error recovery is in progress. Trying to do so can lead to
self-deadlock: Part of the removal code tries to obtain a lock already
held by the error handler.
This can cause problems for the usb-storage and uas drivers, because
their error handler routines perform a USB reset, and if the reset
fails then the USB core automatically goes on to unbind all drivers
from the device's interfaces -- all while still in the context of the
SCSI error handler.
As it turns out, practically all the scenarios leading to a USB reset
failure end up causing a device disconnect (the main error pathway in
usb_reset_and_verify_device(), at the end of the routine, calls
hub_port_logical_disconnect() before returning). As a result, the
hub_wq thread will soon become aware of the problem and will unbind
all the device's drivers in its own context, not in the
error-handler's context.
This means that usb_reset_device() does not need to call
usb_unbind_and_rebind_marked_interfaces() in cases where
usb_reset_and_verify_device() has returned an error, because hub_wq
will take care of everything anyway.
This particular problem was observed in somewhat artificial
circumstances, by using usbfs to tell a hub to power-down a port
connected to a USB-3 mass storage device using the UAS protocol. With
the port turned off, the currently executing command timed out and the
error handler started running. The USB reset naturally failed,
because the hub port was off, and the error handler deadlocked as
described above. Not carrying out the call to
usb_unbind_and_rebind_marked_interfaces() fixes this issue.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Kento Kobayashi <Kento.A.Kobayashi@sony.com>
Tested-by: Kento Kobayashi <Kento.A.Kobayashi@sony.com>
CC: Bart Van Assche <bvanassche@acm.org>
CC: Martin K. Petersen <martin.petersen@oracle.com>
CC: Jacky Cao <Jacky.Cao@sony.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-04-16 22:50:01 +08:00
|
|
|
|
|
|
|
/* If the reset failed, hub_wq will unbind drivers later */
|
|
|
|
if (ret == 0)
|
|
|
|
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);
|
2022-08-27 03:31:32 +08:00
|
|
|
udev->reset_in_progress = 0;
|
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
|