On Wed, Jun 12, 2013 at 07:11:22PM +0300, Mathias Nyman wrote: > Hi > > This is a proposal for simplifying the EHCI/xHCI portswitching > > It's a lot simpler than before. There's now only one funtion for enabling > xhci ports, > and we only once walk through pci devices to find Intel EHCI and xHCI > controllers > > In pci-quirks we set a flag if both intel xHCI and EHCI controllers are found, > and then call the usb_enable_intel_xhci_ports() function. > EHCI and xHCI resume functions call the same usb_enable_intel_xhci_ports(), > without > walking the pci devices. > > On the downside this uses global variables, one xhci pointer and one boolean > flag. > The xhci pointer is set only once in pci-quirk and it's assumed that xHCI > device is not removed, > so there's a possibility this pointer can go stale. > Also we can only handle one Intel xHCI host in the system. > > I'll gladly rework this to remove the global varaibles, but I could use some > input on what would be > the right way to do it. I can only come up with two options: > > 1. walk the pci devices every time in ECHI and xHCI resume functions and > search for a "companion" > controller. > > or > > 2. Save a pointer to a "companion" xHCI controller somewhere in EHCI > structures, and vice versa. > (or somehow re-use the hs_companion pointer in struct usb_bus). > Those pointers can only be set after hcd's are initialized, so we need to > walk the pci devices once in > pci-quirks, and once later when creating the hcd's to set the pointers
I think this approach is better, but I want Alan's opinion on it. Alan? Sarah Sharp > > Mathias Nyman (1): > Intel xhci: refactor EHCI/xHCI port switching > > drivers/usb/host/ehci-pci.c | 15 +---------- > drivers/usb/host/pci-quirks.c | 55 ++++++++++++++++++---------------------- > drivers/usb/host/pci-quirks.h | 3 +- > drivers/usb/host/xhci-pci.c | 5 ++- > 4 files changed, 30 insertions(+), 48 deletions(-) > > -- > 1.7.4.1 > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
