On Fri, Feb 7, 2014 at 12:08 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > 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. Sometimes I feel like I'm talking to a mathematician ;-) > 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. Right, once one drain_workqueue() event has completed we assume that everything plugged in at hcd registration has had a chance to be discovered. At least this is the same guarantee that libsas makes, it has a similar problem determining when it has completed initial domain discovery / expander enumeration. For tier-mismatch we only care about internal hubs, barring some internal switching those should always be part of the initial scan. > >> Other thoughts? > > None at the moment. I don't think it's too much to add. I'll take a stab at it (after we settle on this current set) and if you think it's too onerous feel free to nak it. -- 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
