On Sat, 21 Nov 2015, Patrick Shirkey wrote: > On Sat, November 21, 2015 9:35 am, Peter Stuge wrote: > > Patrick Shirkey wrote: > >> > You essentially have to educate yourself on silicon level (ie. what > >> > hardware IP is being used in which consumer products) to sustain a > >> > dependency on 127 possible devices per bus. > >> > > >> > I guess you'll find that there are only very few xHCI IPs out there, > >> > probably just three or four. I wouldn't be surprised if they all have > >> > the same, or similar, limitations. > >> > >> Is there anything I can do at the system level to avoid disabling xHCI > >> at > >> the BIOS level? > > > > Unfortunately not. The number of supported devices is now very much > > hardwired in the host controller hardware. Each connected device > > requires its own set of registers in xHCI, so when there is a limit > > it is a hard limit. > > > > > > That's a bit of a let down as it seems to make it even more difficult to > rely on USB for my specific use case in the future. > > In case anyone else comes across this thread do you mind giving a little > more detail on why xHCI overrides EHCI and why it is not possible to > disable or work around xHCI at the system level? xHCI is the controller technology that supports SuperSpeed (5 Gb/s), as used by many USB-3 devices. EHCI is the controller technology that supports High Speed (480 Mb/s), used by many USB-2 devices. (Note that xHCI also supports High Speed, as well as Full Speed (12 Mb/s) and Low Speed (1.5 Mb/s) which date back to USB-1.1.) If you disable your xHCI controller, USB connections will not be able to run at SuperSpeed. Depending on how the motherboard is designed, they may fall back to High Speed (using an on-board EHCI controller) or they may not work at all (if the motherboard doesn't have any other USB controllers). This should explain why xHCI overrides EHCI. If you have a SuperSpeed-capable device, you generally want it to run as fast as possible, which means it should connect to the xHCI controller and not to the EHCI controller. 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.) 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. 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
