• Sarah Sharp's avatar
    USB/xHCI: Support device-initiated USB 3.0 resume. · 4ee823b8
    Sarah Sharp authored
    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: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
    4ee823b8
xhci-ring.c 112 KB