On Sun, November 22, 2015 5:41 am, Alan Stern wrote: > 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. > Thank you again for this details response. It all makes perfect sense now. > 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? Do you or anyone else here have a link to the sysfs command to unbind the controller? > 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? -- Patrick Shirkey Boost Hardware Ltd -- 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
