On Sun, 8 Jun 2014, Benjamin Herrenschmidt wrote: > Looking at the code a bit more ... that xhci_shutdown() worries me. > > It basically just whacks xhci_halt() and optionally reset() but nothing > is done that I can see to ensure that we aren't concurrently > doing things like queuing URBs, polling the root hub etc... > > That's definitely not clean and while it might work (most of the time > at least) on actual shutdown it's definitely not right for kexec I > reckon. Yes, it really was meant for actual system shutdown. > Now there's a separate discussion that we had a while ago and might > want to resume which is to say that kexec shouldn't be calling > shutdown() anyway, but instead remove() on all drivers which is > a much better code path for the purpose of leaving the device in > a state where a driver can reconnect to it. > > However, in the case of XHCI that leads to another issue described > here: > > http://marc.info/?l=linux-usb&m=139483181809062&w=2 > > For which there was little / no discussion at all... I suppose we could > do a quirk but I don't think the problem is fundamentally > specific to the TI chip, we should probably stop both root hubs > before we halt both HCDs. The issue described in that email seems valid to me. Maybe the patch should be resubmitted. Now that xhci-hcd has changed maintainership, the discussion might move forward. In any case, you certainly can try testing with that patch installed. After all, xhci-hcd should work properly after a rmmod/modprobe sequence, and this is pretty much the same thing. 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
