On Mon, Jun 17, 2013 at 11:06:15AM -0400, Alan Stern wrote: > 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? Yes, that was the idea. > 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? The code needs to be changed because we don't want to keep adding new PCI IDs for all the new Intel hosts. Mathias also didn't like that we inefficiently walked the PCI bus, looking for the xHCI host in the EHCI resume routine, so he stored the xHCI pointer. Perhaps this would be more clear if these two goals were broken up into two patches? > 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? Not all ports may be exposed on the platform (because there are different skews). If we don't check which ports to switchover, some BIOSes freak out on either shutdown, or suspend. I don't remember which. So we need to pay attention to the port switchover masks. > Why is it necessary to search through all the PCI devices? Why is it > necessary to store any sort of list of switchable controllers? We don't know which host will resume from suspend first. Assume we have a broken BIOS that switches ports back to EHCI on resume. We don't want the USB core to notice EHCI connects and start servicing them before xHCI resumes. Therefore, we need to have both the xHCI and the EHCI resume functions attempt to switch the ports over to xHCI. That means for EHCI, we either need to search the PCI tree for the xHCI host on resume (because that's where the port switchover mechanism registers are), or we need to store the xHCI PCI host pointer somewhere. Mathias chose to store the pointer. > Why should hot-unplug be an issue? Or multiple xHCI controllers? This is not a problem right now, I'm perhaps being paranoid. :) For all current Intel systems, AFAIK, there will only be one xHCI host controller, and it will be a part of the PCH, so you won't see any PCI hot unplug events unless someone removes the entire PCH (which I don't know if we support?). Sarah Sharp -- 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
