Hi Peter, On 06/06/2016 09:25 AM, Peter Chen wrote: > On Sun, Jun 05, 2016 at 02:55:56PM +0800, Lu Baolu wrote: >> Hi Peter, >> >> On 06/04/2016 10:28 AM, Peter Chen wrote: >>> On Sat, Jun 04, 2016 at 12:06:06AM +0800, Lu Baolu wrote: >>>>> 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. >> Port mux is part of dual role switch, but not the whole thing. >> >> Dual role switch includes at least below things: >> - ID or type-C event detection >> - port mux >> - VBUS management >> - start/stop host/device controllers >> >> An OTG/Dual-role framework can be used to keep all these >> things run together with an internal state machine. But it's >> not duplicated with a generic framework for port mux and >> the port mux drivers. > You have admitted port mux is one of the ports of dual-role switch, > Then, how they can co-work with each other? If can't, the dual-role > switch framework needs another input events management for switching. My point is we need a generic framework for the port mux devices, just like we have that for PHY and regulator. OTG framework manages the port mux devices through the common interfaces provided by the port mux framework. If we integrate the port mux device support into OTG itself, this will force every use case of port mux to rely on the big OTG framework, although what it needs is only a single driver. That causes unnecessary software complexity. > >>> Your >>> case is just like Renesas case, which uses two different drivers between >>> peripheral and host[1]. >> In my case, the port mux devices are physical devices and they >> can be controlled through GPIO pins or device registers. They >> are independent of both peripheral and host controllers. >> > Yes, it is the same. GPIO pin or device registers is like ID pin > event. > <snip> >> 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. >> OTG/Dual-role framework and portmux framework are not overlapped. >> The sysfs interface shouldn't be overlapped as well. Say, I have a port >> mux device and I have a driver for it. I am able to read the status of my >> port mux device through sysfs. This is not part of OTG/Dual-role as far >> as I can see. >> > Then how the user wants to switch the role through the mux driver's > sysfs or dual-role switch sysfs? > It depends. If you have an OTG/DRD capable controllers, you need to do this through OTG sysfs; otherwise you only need to switch the port. Best regards, Lu Baolu -- 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
