On Tue, Jan 14, 2014 at 5:27 PM, Dan Williams <dan.j.williams@xxxxxxxxx> wrote: > On Tue, Jan 14, 2014 at 3:22 PM, Sarah Sharp > <sarah.a.sharp@xxxxxxxxxxxxxxx> wrote: >> On Tue, Jan 07, 2014 at 12:29:28PM -0800, Dan Williams wrote: >>> Alan, Sarah, >>> >>> This revision boils down the port power control fixes to the >>> bare minimum to get the implementation functional and reliable. >>> Data structure changes are constrained to struct usb_port and >>> gone are the clumsier attempts at wider reworks from v1 [1] and >>> v2 [2]. No device model changes to consider or changes to the >>> meaning of 'runtime_status' for port devices. Three disconnect >>> bugs are fixed: >>> >>> 1/ Superspeed devices downgrade to their hi-speed connection: fix this by >>> preventing superspeed poweroff until the peer port is suspended. See >>> patch 5. >> >> I've been testing these a bit, and run into some unexpected behavior. >> >> First, just checking: what do you expect to happen if a USB 2.0 port has >> port power off enabled, but its peer USB 3.0 port has power off >> disabled? I had expected that the port would remained powered on, but >> this does not seem to be what the code actually does. > > The implementation never expects a USB2 port to remain powered once > poweroff is enabled. Only USB3 if it it's peer is powered. > >> >> Say I have one xHCI host that registers bus 1 (USB 2.0) and bus 2 (USB >> 3.0). Port 1 on both buses are peer ports, and both ports have power >> off disabled. Then I do the following: >> >> 1. Plug in a USB mouse into the USB 2.0 port. >> 2. Enable port power off for the USB 2.0 port. >> 4. Enable suspend for the mouse. Port should be prevented from being >> powered off, since usbhid enables remote wakeup for the device, and >> the port's runtime_status does reflect that it's active. >> 3. Unbind usbhid. >> 5. Check that the USB 2.0 port's runtime_status is 'suspended' while the >> USB 3.0 port's runtime_status is 'active'. (Note, at this point, >> according to my assumption, the port should still be powered, but >> it's not.) > > Once usbhid is unbound it clears intf->needs_remote_wakeup so the port > is allowed to go to sleep. > >> 6. Unplug the USB mouse. No disconnect event observed. > > Ok, so far so good... > >> 7. Disable port power off for the USB 2.0 port. Still no disconnect. > > hmm... > >> 8. Run `sudo lsusb` and note that the mouse is still listed in lsusb >> output. Further, the sysfs directories are still there. The device >> remains even after running `sudo lsusb -v` (which should trigger a >> get port status for the roothub, where the disconnect should be >> noticed. >> >> A command line history of that procedure is attached. >> >> It seems like there needs to be a way to detect whether a USB device is >> really disconnected after the port is powered back on. ISTR asking >> Tianyu to fix this, but I'm not sure if it ever did get fixed. > > I believe we're just missing a kick of khubd after recovery has > completed like we have in the hub_resume() case. I'll take a look at > why this did not trigger in my tests (presumably another hub event ran > to flag the disconnect). > Acutally no. The device/port should be force resumed via port_dev_wake_child() which should trigger a hub_port_logical_disconnect() and kick khubd. I'll reproduce to see where the "disconnect" is. -- 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
