On 01/07/2012 09:06 AM, Sarah Sharp wrote:
> 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.
>
> Alan: there are three things I'm uncertain about here, and I would
> appreciate your input.
>
> First, should we follow what EHCI and xHCI do during bus suspend, by
> only enabling disconnect and overcurrent wake notifications for ports
> with a device connected to a USB 3.0 hub, and enabling connect and
> overcurrent wake notifications for ports without a connection? I've
> long wondered why xHCI can't just set all the wake-on bits for a port,
> rather than try to make the racy distinction between connected and
> unconnected ports.
>
> Second, what is the expected behavior of system suspend when
> CONFIG_USB_SUSPEND is turned off? It looks like in the current EHCI and
> xHCI code that the "wake on" bits are set in bus_suspend. Does that
> method get called if CONFIG_USB_SUSPEND is turned off? Is the intention
> that the system will resume if a new USB device is plugged in, even if
> CONFIG_USB_SUSPEND is off?
>
> I ask because it seems like hub_suspend is not going to be called for
> the USB 3.0 roothub if CONFIG_USB_SUSPEND is off. If I want to be sure
> the wake on bits are set for USB 3.0 ports (rather than relying on the
> new code in hub_suspend), I have to have duplicate code in xHCI's
> bus_suspend method to set those bits.
>
> Third, should we only set the wake on bits for USB 3.0 hubs during the
> hub initialization, or should we wait to do that in hub_suspend?
>
> Signed-off-by: Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx>
> Cc: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>
> ---
...
> @@ -883,6 +920,10 @@ int xhci_bus_suspend(struct usb_hcd *hcd)
> t2 |= PORT_LINK_STROBE | XDEV_U3;
> set_bit(port_index, &bus_state->bus_suspended);
> }
> + /* USB core sets remote wake mask for USB 3.0 hubs,
> + * including the USB 3.0 roothub, but only if CONFIG_USB_SUSPEND
> + * is enabled, so also enable remote wake here.
> + */
I think CONFIG_USB_SUSPEND is unrelated with hub_suspend, so perhaps you
can remove the code here.
Thanks,
Andiry
> if (hcd->self.root_hub->do_remote_wakeup) {
> if (t1 & PORT_CONNECT) {
> t2 |= PORT_WKOC_E | PORT_WKDISC_E;
> diff --git a/include/linux/usb/ch11.h b/include/linux/usb/ch11.h
> index 0b83acd..f1d26b6 100644
> --- a/include/linux/usb/ch11.h
> +++ b/include/linux/usb/ch11.h
> @@ -76,6 +76,11 @@
> #define USB_PORT_FEAT_C_BH_PORT_RESET 29
> #define USB_PORT_FEAT_FORCE_LINKPM_ACCEPT 30
>
> +/* USB 3.0 hub remote wake mask bits, see table 10-14 */
> +#define USB_PORT_FEAT_REMOTE_WAKE_CONNECT (1 << 8)
> +#define USB_PORT_FEAT_REMOTE_WAKE_DISCONNECT (1 << 9)
> +#define USB_PORT_FEAT_REMOTE_WAKE_OVER_CURRENT (1 << 10)
> +
> /*
> * Hub Status and Hub Change results
> * See USB 2.0 spec Table 11-19 and Table 11-20
--
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
