Hi Alan, On Sat, Dec 21, 2013 at 9:34 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > 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. Well it does arrange to have port recovery to happen asynchronously, but its moot because I over looked the freeze case > 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? 1/ issue a warm reset to recover ports that have been pm runtime powered down. These ports on occasion come back in the SS.inactive state, at other times a standard reset resume of the usb_device is needed. The current power-up cross-fingers and hope for the port to reconnect does not cut it. 2/ issuing warm resets on hub_resume (since this is many ports at once, do it asynchronously), to address the issue reported against the Synopsys xHC by Julius and Vikas. 3/ Prevent khubd from acting on a powered off port. I'll put together a solid reproducer for this case to illustrate the issue, to date I have been chasing intermittent failures (disconnect at resume) that I can alleviate with poweroff bits [1] http://marc.info/?l=linux-usb&m=138511126310679&w=2 > 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. I did have a simpler approach in that earlier take. This one tries to incorporate the additional case of asynchronous warm reset of all ports when recover the hoot hub. I didn't want to have a warm resets triggered from two new places for what is essentially the same issue of reliably recovering a port power session. > 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). Yes, let's try to hash this out better. I'm hitting you with patches and we aren't even in agreement what the problem in question is... Let's just start with the simple scenrios of ports do not reconnect reliably in the Synopsys + Jetflash scenario, and in my port power testing (away from my test machine right otherwise I'd give more details). Do you at least agree with the premise that we should be issuing warm resets more aggressively? I'm proposing to do this unconditionally for port pm_runtime recovery and as an optional xHC quirk at hub_resume time. Or, do you want it to be more tightly defined than that? Are you thinking more along the lines of quirking each device that seems to need a warm reset when it's hub port re-powers? -- Dan -- 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
