Hi Peter, On 06/03/2016 03:41 PM, Peter Chen wrote: > On Thu, Jun 02, 2016 at 09:37:24AM +0800, Lu Baolu wrote: >> > Several Intel platforms implement USB dual role by having completely >> > separate xHCI and dwc3 IPs in PCH or SOC silicons. These two IPs share >> > a single USB port. There is another external port mux which controls >> > where the data lines should go. While the USB controllers are part of >> > the silicon, the port mux design are platform specific. >> > >> > This patch adds the generic code to handle such multiple roles of a >> > usb port. It exports the necessary interfaces for other components to >> > register or unregister a usb mux device, and to control its role. >> > It registers the mux device with sysfs as well, so that users are able >> > to control the port role from user space. >> > >> > Some other archs (e.g. Renesas R-Car gen2 SoCs) need an external mux to >> > swap usb roles as well. This code could also be leveraged for those archs. >> > > Sorry to review this so late, It doesn't matter. Thanks for review. Comments are always welcome.:-) > from my point,it is a dual-role switch > driver too, No, it's not a dual-role switch driver, but a driver for USB port multiplexing. One example of port multiplexing can be found in several Intel SOC and PCH chips, inside of which, there are two independent USB controllers: host and device. They might share a single port and this port could be configured to route the line to one of these two controllers. This patch introduced a generic framework for port mux drivers. It aids the drivers to handle port mux by providing interfaces to 1) register/unregister a mux device; 2) lookup the mux device; and 3) switch the port. Port multiplexing isn't equal to USB dual role. There are other cases in today's systems. In several Intel PCH chips, there equips two USB host controllers: ehci and xhci. The xhci USB2 ports are multiplexed with ehci. This guarantees all USB ports work even running an old version of OS which lacks of USB3 support. In theory, we can create a driver for the port mux and switch the ports between xhci and ehci, but that's silly, isn't it? Why not always USB3?:-) Another case is xHCI debug capability. The xHCI host controller might equip a unit for system debugging (refer to 7.6 of xHCI spec). The debugging unit is independent of xhci host controller. But it shares its port with xhci. Software could switch the port between xhci and the debugging unit through the registers defined in xHCI spec. Best regards, Lu Baolu > we are reviewing USB OTG/dual-role framework [1], it is > not necessary to create another framework to do it. And USB OTG framework > has already tested at Renesas's platform [2]. > > [1] http://www.spinics.net/lists/linux-usb/msg140835.html > [2] http://www.spinics.net/lists/linux-usb/msg140827.html > > Peter > -- 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
