Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux

[Peter Chen]

On Sat, Jun 04, 2016 at 12:06:06AM +0800, Lu Baolu wrote:
> 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.
> 

For this case, I can't see it is different with dual-role switch. Your
case is just like Renesas case, which uses two different drivers between
peripheral and host[1].

> 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.
> 

Yes, above two are different with dual role switch. But in your code and
Kconfig, it seems this framework is dedicated for dual-role. Eg:

+menuconfig USB_PORTMUX
+       bool "USB dual role port MUX support"
+       help
+         Generic USB dual role port mux support.

I think a general dual role port mux is necessary, it can be used to
manage different dual-role switch method, eg
- ID pin
- External connector through GPIO
- SoC register
- sysfs
- type-C events

But this code is better co-work with OTG/Dual-role framework, we'd
better have only interface that the user can know which role for the
current port.

[1] https://lkml.org/lkml/2016/4/7/115
-- 

Best Regards,
Peter Chen