On Fri, May 27, 2011 at 10:16:29AM -0700, Sarah Sharp wrote: > On Fri, May 27, 2011 at 09:15:13AM -0700, Sarah Sharp wrote: > > On Fri, May 27, 2011 at 11:40:50AM -0400, Alan Stern wrote: > > > On Fri, 27 May 2011, Sarah Sharp wrote: > > > > > > > We could just write all ones to the switchover ports, which avoids BIOS > > > > writers all together and assumes the non-working USB 2.0 device under > > > > xHCI is a rare case, which it should be. > > > > > > That's probably the best idea. For the rare case where somebody really > > > does want to connect a device to the EHCI controller, you could add a > > > "companion" sysfs attribute file to xhci-hcd for runtime control, like > > > ehci-hcd's "companion" attribute. > > > > And it should switch all the ports over to EHCI? Kind of harsh, but > > it's probably simplest. > > Where is the code that adds the EHCI companion sysfs attribute? Ok, I found it under ehci-hub.c. The problem is with the split roothubs. The companion file will show up under both the USB 2.0 xHCI roothub and the USB 3.0 xHCI roothub. Should the files control the individual parts of the port registers (i.e. the USB 2.0 roothub companion file controls the USB 2.0 data lines, and the USB 3.0 roothub companion file controls the SuperSpeed termination activation)? I think that would be far, far, too complicated to expect users to get the writing of two companion files right, because they really should switch on the SuperSpeed terminations before the switch the USB 2.0 data lines. I'm also really not keen on exposing this sysfs file. If the user has a non-suspended device under EHCI, and the port switchover happens fast enough that the device doesn't see a break in SOFs, then I'm not sure if there will be a connect change under xHCI. Or vice versa. I think we don't run into that situation at boot because the host drivers will load, halt & reset the hosts, and then reset any connected devices. I would have to check the port switchover scenarios that the BIOS guys came up with. I think we're opening up a can of worms here, and I don't think we should expose this file. Let's see if anyone does report issues with devices under xHCI before add this in. It's unlikely that anyone will have issues with internal USB devices because OEMs will use the non-switchable EHCI ports, and I bet OEMs will also expose at least one EHCI port externally. Even though we can allow the ports to be switched over, I don't think we necessarily should expose it. Heck, people without this Intel system are just SOL if their devices don't work under xHCI. Sarah Sharp -- 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
