On Sun, 22 Nov 2015, Peter Stuge wrote: > Patrick Shirkey wrote: > > > if the kernel does have support for xHCI, we assume that > > > the user will prefer xHCI over EHCI if the motherboard has xHCI. > > > > Obviously the solution above should suffice for my purposes but out > > of interest is it viable to make the switch accessible to run time > > configuration? > > I don't think it makes sense to expose the port routing to user > space, but I think it would make sense to route ports to the EHCI HC(s) > when xhci-hcd is unbound, and vice versa. > > I'm not sure what the best implementation for this would be. Would it > be possible for ehci-hcd to call into xhci-hcd code, even if xhci-hcd > is not currently bound anywhere? > > One possibility is to add code to both drivers which gets called on > unbind and which routes ports to the respective other controller type, > but that doesn't really seem like a great solution. It would be nicer > to have a single entry point for the (re)routing. > > Alan, what are your thoughts on that? In general it's best not to make things too complicated. Perhaps the switch could be changed at runtime, say whenever xhci-hcd binds to or unbinds from the motherboard's controller. But this could have undesirable consequences. For example, if xhci-hcd is a little slow to load (say because it's in a loadable module that takes some time to install), a USB-3 disk drive might start out connecting to the EHCI controller and being mounted. Then when the switch setting is changed, the disk would be forcibly disconnected from EHCI, which could mess up any writes that were in progress, not to mention causing a number of alarming messages to show up in the system log. I'd like to hear what Mathias says before making any definite suggestions. 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
