On 23.11.2015 04:31, Alan Stern wrote:
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.
Port switching is done in xHCI PCI config space.
The current implementation is a pci hook in pci-quirks.c that once a Intel xHCI controller is found
will switch over the ports from EHCI to xHCI if:
a) there is also a Intel EHCI controller present
b) there is a driver available for the xHCI controller (xhci-hcd)
This is done before ehci-hcd and xhci-hcd are loaded, so they don't need to worry about
disappearing, or magically appearing ports.
I'm not sure how ehci-hcd will handle sudden new ports if we switch ports from xHCI to EHCI at xhci-hcd unbind.
Also, as Alan said, the other way around can cause issues. Switching a port to xHCI if it has a device working under
EHCI can cause corruption etc.
Trying to make a automatic runtime port switching based on ehci and xhci bind/unbind can become complicated
Maybe instead a manual crank to switch ports, but only when both xhci and ehci are unbound
-Mathias
--
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
