On Sun, 22 Nov 2015, Patrick Shirkey wrote: > > It _is_ possible to disable xHCI at the system level. By sending the > > proper command to the appropriate sysfs file, you can unbind the > > xhci-hcd driver from the xHCI controller. This will disable the > > controller, and so all further USB communications will run no faster > > than High Speed. (Or if your computer doesn't have an EHCI controller, > > you won't get any further USB communications at all.) > > > > Is there a method to determine if the system has multiple or single > controllers available? lspci will tell you. > Do you or anyone else here have a link to the sysfs command to unbind the > controller? If you provide the output from "lspci", I will tell you what command to use. > > Actually it's a little more complicated than that. Some systems have a > > software-settable switch that determines whether devices will connect > > to the xHCI or the EHCI controller. On such systems, Linux sets the > > switch to use xHCI, unless the kernel was built without xHCI support. > > Therefore, although it is possible to force the use of EHCI on such > > systems, in order to do so you have to rebuild the kernel. > > > > > In regards to the last item can you provide some more details on why the > software switch is only set if the kernel module is enable/disabled? > > I assume it has something to do with compiler flags and run time efficiency? No, it's simpler than that. If the kernel is built without support for xHCI, it would be foolish to connect devices to the xHCI controller -- then the system wouldn't be able to communicate with them! Conversely, if the kernel does have support for xHCI, we assume that the user will prefer xHCI over EHCI if the motherboard has xHCI. Therefore the switch does get set to connect devices to the xHCI controller. 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
