On Sun, 22 Dec 2013, Dan Williams wrote: > > 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. Okay, that's reasonable. If the port ends up in the wrong state after power-on, it obviously needs to be reset. In theory this could be true even during hub initialization. I don't know if that ends up being a problem in practice. But I suspect that moving the port power-on/off routines from hub.c to port.c, and elaborating them, would be a good step. > 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. Here you're referring specifically to resume of a _root_ hub, right? And not just any root hub, but specifically the Synopsys SuperSpeed root hub. The special quirk-like nature of this change strongly suggests that these warm resets should be issued by xhci-hcd rather than the hub driver. > 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 We may want to remove the busy_bits field from the usb_hub structure and replace it with an in-use counter in struct usb_port. That would allow greater flexibility; it particular, a port could be busy for more than one reason at a time (that is, the counter could assume values higher than 1). > > 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. We shouldn't need to do multiple warm resets of the same port. After the first reset, the port and child device ought to be in the correct states and therefore no further resets should be necessary. If we have to, we could add a flag to usb_port to indicate when this happens. > > 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 not enough of an expert on the peculiarities of USB-3 to answer that. If Sarah agrees it is necessary, or if people find it is necessary in practice... Either would be sufficient justification. > 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? I'm thinking that we shouldn't do resets merely because they _might_ be needed. Ideally we would be able to tell by looking at the port's state or the device's responses. If that doesn't work out then a per-device quirk may be necessary. It does seem strange that a bus-powered device would need some sort of special treatment following a port power-on. After all, what's the difference between a port power-off/power-on and unplugging/replugging the device? 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
