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). > Also, it seems that my self-powered USB 3.0 Pluggable UAS dock can > "overcome" the port power off mechanism. When USB 2.0 power off is > enabled, the USB 3.0 peer port power off is disabled, and I connect it, > the device appears for a very brief amount of time before disconnecting. It appears on the USB2 interface or USB3? I'd like to see a log if you can grab it. > A bus powered USB 3.0 flash drive never connects when the port is > powered. ...USB3 port "powered off" you mean? > > It's intermittent though, I can't reproduce it all the time, so it may > just be BIOS issues. Not sure how the BIOS trips us up here unless it asynchronously disables the port after the poweroff request completes? -- 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
