Per Alan's request this is the second half of the series that addresses
the following disconnect scenarios when attempting to use port
power-off. Now that part1 is mostly acked, these 8 patches address
scenarios 2 and 3. Scenario one was addressed in part1 [1]
1/ Superspeed devices downgrade to their hispeed connection when
rx-detection fails on the superspeed pins. Address this by
preventing superspeed port poweroff/suspension until the peer port is
suspended, and powering on the superspeed port before the hispeed port
is resumed. This depends on the ability to identify peer ports.
2/ khubd prematurely disconnects ports that are in the process of being
resumed or reset. After this series khubd will ignore ports in the
pm-runtime-suspended or suspending state, or force active ports in the
resuming state (patch 4). While it is running it holds a new port
status lock to synchronize the port status changes of
usb_port_{suspend|resume} and usb_reset_and_verify_device() (patch 5).
3/ Superspeed devices fail to reconnect after a 2 second timeout This
event has two causes:
3.1/ Repeated {Set|Clear}PortFeature(PORT_POWER) toggles results in
the the device switching to its hispeed connection (due to
perceived instability of the superspeed connection). Address
this by arranging for the child device to be woken up
and complete a resume cycle when the parent port resumes (patch 6).
3.2/ Devices may require a warm reset when recovering the power
session. When the child device is woken up per above and the
port timed out on reconnect, force a warm-reset during the
child's reset-resume (patch 7).
Changes since v5 [2] are limited to context rebasing, and some small
changelog clarifications. However, this was after some additional
experimentation with an alternative warm-reset approach. The experiment
consisted of modifying patch 7 to always warm reset superspeed ports and
skip the initial connect-debounce-wait. That proved to be problematic
as it lead to cases where the core still needed to perform the connect
debounce after the warm reset. Also, external hubs in the test appeared
to react to "unnecessary" warm resets by degrading to their hispeed
connection. With the final update in part1, to observe the specified
hub power-on delay [3], this implementation passes an extended run of
port-power toggling without triggering a device disconnect.
[1] v6 part1: http://marc.info/?l=linux-usb&m=139362948508700&w=2
[2] v5: http://marc.info/?l=linux-usb&m=139362948508700&w=2
[3] observe power-on delay: http://marc.info/?l=linux-usb&m=139473814812129&w=2
---
[PATCH v6 part2 1/8] usb: don't clear FEAT_C_ENABLE on usb_port_runtime_resume failure
[PATCH v6 part2 2/8] usb: usb3 ports do not support FEAT_C_ENABLE
[PATCH v6 part2 3/8] usb: refactor port handling in hub_events()
[PATCH v6 part2 4/8] usb: synchronize port poweroff and khubd
[PATCH v6 part2 5/8] usb: introduce port status lock
[PATCH v6 part2 6/8] usb: resume (wakeup) child device when port is powered on
[PATCH v6 part2 7/8] usb: force warm reset to break link re-connect livelock
[PATCH v6 part2 8/8] usb: documentation for usb port power off mechanisms
Documentation/usb/power-management.txt | 242 ++++++++++++++++-
drivers/usb/core/hcd.c | 2 -
drivers/usb/core/hub.c | 487 ++++++++++++++++++-------------
drivers/usb/core/hub.h | 6 +-
drivers/usb/core/port.c | 32 ++-
drivers/usb/core/usb.h | 6 +
6 files changed, 550 insertions(+), 225 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
