On Fri, 27 May 2011, Sarah Sharp wrote: > > 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. Not if you register it under the PCI device, like ehci-hcd does, rather than the root hubs. > 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. Besides, that doesn't make sense. Clearly the switch affects where the D+ and D- wires go. It may affect the SSRX+/- and SSTX+/- wires or it may not, but the kernel doesn't get to make that choice. > 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 Why would the device not see a break in SOFs? Neither controller will send SOF packets out through a port that isn't connected and enabled. > there will be a connect change under xHCI. Or vice versa. I think we There ought to be a connect change. After all, the wires weren't connected before and now they are. > 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. The best way to get a definitive answer may be to try it yourself. :-) > 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. Okay, if you don't want to implement it, that's a valid decision. You can always add it in later if people want it. 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
