On Fri, May 27, 2011 at 02:15:02PM -0400, Alan Stern wrote: > 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. Ah, ok. I don't have a non-Intel EHCI system, so I don't even see the companion files because I don't have any companion controllers. :) > > 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. Ok, I think I was misremembering. There was some discussion of what needed to be done to switch the ports over in the BIOS if the user turned on xHCI, and I think the worry was that devices would see a partical SOF, if the BIOS had been using the EHCI host controller before switching it over to xHCI. So disregard my comments. > > 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. Yes, I think I want to hold off on the companion sysfs file. I think I will redo this patch to unconditionally switch all ports over, and we'll see if anyone complains. 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
