On Fri, 7 Feb 2014, Dan Williams wrote: > 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. Heh. Strictly speaking, we _never_ discover the entire hub topology. A new hub can be plugged in at any time. Of course, we don't care about new hubs being plugged in. It would be good enough to wait for only the hubs that were connected when the root hubs were registered. I doubt this would be worth the effort, though. > Other thoughts? None at the moment. Alan Stern -- 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
