On Tue, Jan 14, 2014 at 1:42 PM, Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx> wrote: > On Mon, Jan 13, 2014 at 08:57:38PM -0500, Alan Stern wrote: >> On Mon, 13 Jan 2014, Sarah Sharp wrote: >> >> > On Mon, Jan 13, 2014 at 02:56:57PM -0800, Sarah Sharp wrote: >> >> > > I haven't looked at this too closely, but what happens if: >> > > - the USB 2.0 roothub is registered >> > > - userspace immediately sets autosuspend_delay to zero and >> > > pm_qos_no_port_poweroff to zero >> > > - usb_acpi_find_device changes the connect_type to something other than >> > > unknown >> > > - before usb_acpi_check_port_peer() is called, the port is suspended >> > >> > Or that call finishes, but no peer port is set yet, because the USB 3.0 >> > roothub isn't registered yet. The USB 2.0 bus can be suspended before >> > the USB 3.0 bus has finished registering, as I've seen from this thread: >> > >> > http://marc.info/?l=linux-usb&m=138914518219334&w=2 >> >> It's always possible for xhci-hcd to prevent the USB-2 root hub from >> being suspended by calling pm_runtime_get_noresume. The corresponding >> _put can be done after the USB-3 root hub has been registered. > > Sure, it's on my todo list to fix that. I just wondered if there were > other race conditions present, given that I could find one off the top > of my head. At least as far as this patchset is concerned there is no race/requirement to hold off usb-2 root hub power management. The patchset expects usb2 ports to suspend independent of their peer usb3 port state, and forces usb3 ports to always resume before usb2 peers. > > What do you think about the rest of the patchset? > -- 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
