On Mon, 17 Jun 2013, Sarah Sharp wrote: > > We should be able to handle hotplug if at all possible. I know the > > quirk handling issues around PCI hotplug aren't all worked out (or at > > least they were not a year or so ago), so maybe there's really nothing > > you can/need to do here. > > Ok, I'll work with Mathias, and we'll figure out how to handle hot plug. > If you have any good suggestions, let me know. Sarah, can you go over the issues involved? I'm not entirely clear on all of this. For example, given an xHCI controller with switchable ports, you can't easily tell which EHCI controller those ports are connected to, right? And in fact, you don't even really care. Correct me if I'm wrong here. The original idea was to switch everything over to xHCI during some early stage (like when the xHCI controller is first passed to the pci-quirks.c code) and switch back to EHCI at shutdown. As a refinement, you want to switch over to xHCI again following system resume, in case the BIOS messed things up. Is there anything else? Why does the old code need to be changed? The only problem I see is that it may be a little too elaborate. For example, why bother trying to do the switch when the EHCI controller resumes? Won't everything work okay if you wait until the xHCI controller resumes? Why does the code check so hard to see whether or not there are any switchable ports? Why not just always try to set the switch on any Intel controller? Why is it necessary to search through all the PCI devices? Why is it necessary to store any sort of list of switchable controllers? Why should hot-unplug be an issue? Or multiple xHCI controllers? 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
