On Fri, Dec 13, 2013 at 10:15 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Fri, 13 Dec 2013, Dan Williams wrote: > >> > I'm actually leaning towards enabling the check for warm reset broadly. >> > It seems like it wouldn't hurt to issue a warm reset on the USB 3.0 >> > ports if they're in compliance, poll, or rx.detect. So, let's enable >> > this broadly in xhci_resume, mark the patch for stable, but ask for the >> > backport to be delayed until 3.13.3 is out, to allow for more testing. >> > If anyone complains of xHCI behavior changes, we'll change the code to >> > add a quirk. >> >> Is there a clean way to make this per-port rather than globally at >> xhci_resume()? I am looking to hook into this for port power recovery >> as Tianyu's testing encountered "warm reset required" conditions at >> runtime_resume. I'm still on the hunt for a solid reproducer, but it >> indicates this is a more general quirk with power session recovery. > > There's no reason you can't do per-port testing inside xhci_resume > (assuming you know what to test for) as well as putting a warm reset in > the port-power handler of xhci_hub_control. I'm just uneasy putting the recovery there as we lose the context of why the port was powered-on. For example we don't want to pre-empt/duplicate a reset in xhci_hub_control() that is already specified in hub_events(). > Of course, doing simultaneous warm resets on multiple ports will use > less time than resetting each port individually, in sequence. > For the hub resume case, yes. For pm_runtime_resume of an individual port I believe it needs to be synchronous. -- 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
