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.
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.)
6. Unplug the USB mouse. No disconnect event observed.
7. Disable port power off for the USB 2.0 port. Still no disconnect.
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.
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.
A bus powered USB 3.0 flash drive never connects when the port is
powered.
It's intermittent though, I can't reproduce it all the time, so it may
just be BIOS issues.
Sarah Sharp
root@maggie:/sys/bus/usb/devices# lsusb -t
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
|__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/8p, 480M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/9p, 480M
|__ Port 1: Dev 3, If 0, Class=HID, Driver=usbhid, 1.5M
|__ Port 8: Dev 2, If 0, Class='bInterfaceClass 0xe0 not yet handled', Driver=btusb, 12M
|__ Port 8: Dev 2, If 1, Class='bInterfaceClass 0xe0 not yet handled', Driver=btusb, 12M
root@maggie:/sys/bus/usb/devices# echo 0 > usb1/1-0\:1.0/port1/power/pm_qos_no_power_off
root@maggie:/sys/bus/usb/devices# cat usb1/1-0\:1.0/port1/power/runtime_status
active
root@maggie:/sys/bus/usb/devices# echo "1-1" > usb1/1-0\:1.0/port1/device/driver/unbind
root@maggie:/sys/bus/usb/devices# cat usb1/1-0\:1.0/port1/power/runtime_status
active
root@maggie:/sys/bus/usb/devices# echo "auto" > usb1/1-0\:1.0/port1/device/power/control
root@maggie:/sys/bus/usb/devices# cat usb1/1-0\:1.0/port1/power/runtime_status
suspended
root@maggie:/sys/bus/usb/devices# echo 1 > usb1/1-0\:1.0/port1/power/pm_qos_no_power_off
root@maggie:/sys/bus/usb/devices# lsusb
Bus 001 Device 003: ID 046d:c040 Logitech, Inc. Corded Tilt-Wheel Mouse
Bus 001 Device 002: ID 8087:07dc Intel Corp.
Bus 003 Device 002: ID 8087:8000 Intel Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
root@maggie:/sys/bus/usb/devices# cat usb2/2-0\:1.0/port1/power/pm_qos_no_power_off
1
root@maggie:/sys/bus/usb/devices# cat usb2/2-0\:1.0/port1/power/runtime_status
active
root@maggie:/sys/bus/usb/devices# lsusb -v -d 046d:c040
Bus 001 Device 003: ID 046d:c040 Logitech, Inc. Corded Tilt-Wheel Mouse
Couldn't open device, some information will be missing
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x046d Logitech, Inc.
idProduct 0xc040 Corded Tilt-Wheel Mouse
bcdDevice 24.30
iManufacturer 1
iProduct 2
iSerial 0
bNumConfigurations 1
Couldn't get configuration descriptor 0, some information will be missing
Couldn't get configuration descriptor 0, some information will be missing
root@maggie:/sys/bus/usb/devices# lsusb
Bus 001 Device 003: ID 046d:c040 Logitech, Inc. Corded Tilt-Wheel Mouse
Bus 001 Device 002: ID 8087:07dc Intel Corp.
Bus 003 Device 002: ID 8087:8000 Intel Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
