On Fri, 20 Dec 2013, Dan Williams wrote: > Both the suspected quirky Synopsys xHC [1] and the > port-pm-runtime-resume path need to issue warm resets to reliably bring > ports back to an operational state. Per Alan's observation this also > arranges for these warm resets to be queued asynchronously. Per my > previous testing I found cases where khubd takes actions on ports that > are known to still be in recovery (unintended disconnects). This set > mitigates those interactions by pushing resume operations into khubd > context by making khubd a workqueue. This really doesn't seem like a good solution. For one thing, it's two separate modifications: Changing khubd into a work queue, and pushing resume operations into khubd. There's no logical connection between these two things. The major point of this work is to run all port recovery operations in khubd, right? This will cause all such operations to be serialized, which will waste time in situations where we know multiple ports can be reset simultaneously. Also, it means that some resets -- those which would not normally be handled by khubd -- will have to be delayed until khubd gets around to them. Finally, it means that some resets (those which have to occur at times when khubd is frozen) will be completely impossible. What exactly is the problem you want to solve? Khubd taking inappropriate actions on ports that are known to be in recovery? Then why not simply improve the synchronization with khubd? Make it smart enough not to take those inappropriate actions. That shouldn't require such major changes. If you think that isn't feasible, please explain in detail why not. Also explain in detail what it is you want to achieve (as opposed to how your propose to achieve it, which we already can see in these patches). 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
