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>
Per Alan:
"You mean from within hub_handle_remote_wakeup()? That routine will
never get called if CONFIG_PM_RUNTIME isn't enabled, because khubd
never sees wakeup requests if they arise during system suspend.
In fact, that routine ought to go inside the "#ifdef CONFIG_PM_RUNTIME"
portion of hub.c, along with the other suspend/resume code."
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
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>
In general we do not want khubd to act on port status changes that are
the result of in progress resets or USB runtime PM operations.
Specifically port power control testing has been able to trigger an
unintended disconnect in hub_port_connect_change(), paraphrasing:
if ((portstatus & USB_PORT_STAT_CONNECTION) && udev &&
udev->state != USB_STATE_NOTATTACHED) {
if (portstatus & USB_PORT_STAT_ENABLE) {
/* Nothing to do */
} else if (udev->state == USB_STATE_SUSPENDED &&
udev->persist_enabled) {
...
} else {
/* Don't resuscitate */;
}
}
...by falling to the "Don't resuscitate" path or missing
USB_PORT_STAT_CONNECTION because usb_port_resume() was in the middle of
modifying the port status.
So, we want a new lock to hold off khubd for a given port while the
child device is being suspended, resumed, or reset. The lock ordering
rules are now usb_lock_device() => usb_lock_port(). This is mandated by
the device core which may hold the device_lock on the usb_device before
invoking usb_port_{suspend|resume} which in turn take the status_lock on
the usb_port. We attempt to hold the status_lock for the duration of a
port_event() run, and drop/re-acquire it when needing to take the
device_lock. The lock is also dropped/re-acquired during
hub_port_reconnect().
This patch also deletes hub->busy_bits as all use cases are now covered
by port PM runtime synchronization or the port->status_lock and it
pushes down usb_device_lock() into usb_remote_wakeup().
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>
If a port is powered-off, or in the process of being powered-off, prevent
khubd from operating on it. Otherwise, the following sequence of events
leading to an unintended disconnect may occur:
Events:
(0) <set pm_qos_no_poweroff to '0' for port1>
(1) hub 2-2:1.0: hub_resume
(2) hub 2-2:1.0: port 1: status 0301 change 0000
(3) hub 2-2:1.0: state 7 ports 4 chg 0002 evt 0000
(4) hub 2-2:1.0: port 1, power off status 0000, change 0000, 12 Mb/s
(5) usb 2-2.1: USB disconnect, device number 5
Description:
(1) hub is resumed before sending a ClearPortFeature request
(2) hub_activate() notices the port is connected and sets
hub->change_bits for the port
(3) hub_events() starts, but at the same time the port suspends
(4) hub_connect_change() sees the disabled port and triggers disconnect
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>
In preparation for synchronizing port handling with pm_runtime
transitions refactor port handling into its own subroutine.
We expect that clearing some status flags will be required regardless of
the port state, so handle those first and group all non-trivial actions
at the bottom of the routine.
This also splits off the bottom half of hub_port_connect_change() into
hub_port_reconnect() in prepartion for introducing a port->status_lock.
hub_port_reconnect() will expect the port lock to not be held while
hub_port_connect_change() expects to enter with it held.
Other cleanups include:
1/ reflowing to 80 columns
2/ replacing redundant usages of 'hub->hdev' with 'hdev'
3/ consolidate clearing of ->change_bits() in hub_port_connect_change
4/ consolidate calls to usb_reset_device
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>
The port pm_runtime implementation unconditionally clears FEAT_C_ENABLE
after clearing PORT_POWER, but the bit is reserved on usb3 hub ports.
We expect khubd to be prevented from running because the port state is
not RPM_ACTIVE, so we need to clear any errors for usb2 ports.
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>
Three reasons:
1/ It's an invalid operation on usb3 ports
2/ There's no guarantee of when / if a usb2 port has entered an error
state relative to PORT_POWER request
3/ The port is active / powered at this point, so khubd will clear it as
a matter of course
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>
ClearPortFeature(PORT_POWER) on a usb3 port places the port in either a
DSPORT.Powered-off-detect / DSPORT.Powered-off-reset loop, or the
DSPORT.Powered-off state. There is no way to ensure that RX
terminations will persist in this state, so it is possible a device will
degrade to its usb2 connection. Prevent this by blocking power-off of a
usb3 port while its usb2 peer is active, and powering on a usb3 port
before its usb2 peer.
By default the latency between peer power-on events is 0. In order for
the device to not see usb2 active while usb3 is still powering up inject
the hub recommended power_on_good delay. In support of satisfying the
power_on_good delay outside of hub_power_on() refactor the places where
the delay is consumed to call a new hub_power_on_good_delay() helper.
Finally, because this introduces several new checks for whether a port
is_superspeed, cache that disctinction at port creation so that we don't
need to keep looking up the parent hub device.
Acked-by: Alan Stern <stern@rowland.harvard.edu>
[alan]: add a 'superspeed' flag to the port
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We want to manipulate ->did_runtime_put in usb_port_runtime_resume(),
but we don't want that to collide with other updates. Move usb_port
flags to new port-bitmap fields in usb_hub. "did_runtime_put" is renamed
"child_usage_bits" to reflect that it is strictly standing in for the
fact that usb_devices are not the device_model children of their parent
port.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ACPI identifies peer ports by setting their 'group_token' and
'group_position' _PLD data to the same value. If a platform has tier
mismatch [1] , ACPI can override the default (USB3 defined) peer port
association for internal hubs. External hubs follow the default peer
association scheme.
Location data is cached as an opaque cookie in usb_port_location data.
Note that we only consider the group_token and group_position attributes
from the _PLD data as ACPI specifies that group_token is a unique
identifier.
When we find port location data for a port then we assume that the
firmware will also describe its peer port. This allows the
implementation to only ever set the peer once. This leads to a question
about what happens when a pm runtime event occurs while the peer
associations are still resolving. Since we only ever set the peer
information once, a USB3 port needs to be prevented from suspending
while its ->peer pointer is NULL (implemented in a subsequent patch).
There is always the possibility that firmware mis-identifies the ports,
but there is not much the kernel can do in that case.
[1]: xhci 1.1 appendix D figure 131
[2]: acpi 5 section 6.1.8
[alan]: don't do default peering when acpi data present
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
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>
Given that root hub port peers are already established, external hub peer
ports can be determined by traversing the device topology:
1/ ascend to the parent hub and find the upstream port_dev
2/ walk ->peer to find the peer port
3/ descend to the peer hub via ->child
4/ find the port with the matching port id
Note that this assumes the port labeling scheme required by the
specification [1].
[1]: usb3 3.1 section 10.3.3
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>
Assume that the peer of a superspeed port is the port with the same id
on the shared_hcd root hub. This identification scheme is required of
external hubs by the USB3 spec [1]. However, for root hubs, tier mismatch
may be in effect [2]. Tier mismatch can only be enumerated via platform
firmware. For now, simply perform the nominal association.
A new lock 'usb_port_peer_mutex' is introduced to synchronize port
device add/remove with peer lookups. It protects peering against
changes to hcd->shared_hcd, hcd->self.root_hub, hdev->maxchild, and
port_dev->child pointers.
[1]: usb 3.1 section 10.3.3
[2]: xhci 1.1 appendix D
Cc: Alan Stern <stern@rowland.harvard.edu>
[alan: usb_port_peer_mutex locking scheme]
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>
Once usb-acpi has set the port's connect type the usb_device's
->removable attribute can be set in the standard location
set_usb_port_removable().
This also changes behavior in the case where the firmware says that the
port connect type is unknown. In that case just use the default setting
determined from the hub descriptor.
Note, we no longer pass udev->portnum to acpi_find_child_device() in the
root hub case since:
1/ the usb-core sets this to zero
2/ acpi always expects zero
...just pass zero.
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
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>
The current port name "portX" is ambiguous. Before adding more port
messages rename ports to "<hub-device-name>-portX"
This is an ABI change, but the suspicion is that it will go unnoticed as
the port power control implementation has been broken since its
introduction. If however, someone was relying on the old name we can
add sysfs links from the old name to the new name.
Additionally, it unifies/simplifies port dev_printk messages and modifies
instances of:
dev_XXX(hub->intfdev, ..."port %d"...
dev_XXX(&hdev->dev, ..."port%d"...
into:
dev_XXX(&port_dev->dev, ...
Now that the names are unique usb_port devices it would be nice if they
could be included in /sys/bus/usb. However, it turns out that this
breaks 'lsusb -t'. For now, create a dummy port driver so that print
messages are prefixed "usb 1-1-port3" rather than the
subsystem-ambiguous " 1-1-port3".
Finally, it corrects an odd usage of sscanf("port%d") in usb-acpi.c.
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
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>
A hub indicates whether it supports per-port power control via the
wHubCharacteristics field in its descriptor. If it is not supported
a hub will still emulate ClearPortPower(PORT_POWER) requests by
stopping the link state machine. However, since this does not save
power do not bother suspending.
This also consolidates support checks into a
hub_is_port_power_switchable() helper.
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>
The USB core doesn't properly handle mutual exclusion between
resetting a hub and changing the power states of the hub's ports. We
need to avoid sending port-power requests to the hub while it is being
reset, because such requests cannot succeed.
This patch fixes the problem by keeping track of when a reset is in
progress. At such times, attempts to suspend (power-off) a port will
fail immediately with -EBUSY, and calls to usb_port_runtime_resume()
will update the power_is_on flag and return immediately. When the
reset is complete, hub_activate() will automatically restore each port
to the proper power state.
Signed-off-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>
This patch creates a separate instance of the usb_address0 mutex for each USB
bus, and attaches it to the usb_bus device struct. This allows devices on
separate buses to be enumerated in parallel; saving time.
In the current code, there is a single, global instance of the usb_address0
mutex which is used for all devices on all buses. This isn't completely
necessary, as this mutex is only needed to prevent address0 collisions for
devices on the *same* bus (usb 2.0 spec, sec 4.6.1). This superfluous coverage
can cause additional delay in system resume on systems with multiple hosts
(up to several seconds depending on what devices are attached).
Signed-off-by: Todd Brandt <todd.e.brandt@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Since usb otg fsm implementation is not related to usb phy.
We move it from usb/phy/ to usb/common/, and rename it to
reflect its real meaning.
Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Since we have already removed the usage of CONFIG_USB_DEBUG, it is
meaningless that there is still a configuration entry for CONFIG_USB_DEBUG.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The code in hcd-pci.c that matches up EHCI controllers with their
companion UHCI or OHCI controllers assumes that the private drvdata
fields don't get set too early. However, it turns out that this field
gets set by usb_create_hcd(), before hcd-pci expects it, and this can
result in a crash when two controllers are probed in parallel (as can
happen when a new controller card is hotplugged).
The companions_rwsem lock was supposed to prevent this sort of thing,
but usb_create_hcd() is called outside the scope of the rwsem.
A simple solution is to check that the root-hub pointer has been
initialized as well as the drvdata field. This doesn't happen until
usb_add_hcd() is called; that call and the check are both protected by
the rwsem.
This patch should be applied to stable kernels from 3.10 onward.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Stefani Seibold <stefani@seibold.net>
Tested-by: Stefani Seibold <stefani@seibold.net>
CC: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
