On Fri, Feb 7, 2014 at 7:17 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Fri, 7 Feb 2014, Dan Williams wrote: > >> >> + /* power on our usb3 peer before this usb2 port to prevent a usb3 >> >> + * device from degrading to its usb2 connection >> >> + */ >> >> + if (!hub_is_superspeed(hdev) && peer) >> >> + pm_runtime_get_sync(&peer->dev); >> >> + >> > >> > Have you considered what would happen if this runs before the ACPI data >> > causes the peers to be re-matched? >> >> If userspace is sets pm_qos_no_poweroff to 0 before we have figured >> out the peer then suspending this port may lead to a disconnect. > > What if userspace sets pm_qos_no_poweroff to 0 _after_ we have figured > out the peer and _before_ the ACPI data causes us to change the peer? You know, I believe these races would go away if we could delay port pm runtime activation until after the initial discovery of the entire hub topology. One potential way of solving this is to proceed with converting khubd to a workqueue. Then, we could use a properly placed drain_workqueue() to flush the chain of khubd discovery events to completion. Other thoughts? -- 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
