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

Peter Chen
2016-06-06T07:08:31Z

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

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

The user may not know the detail, they will do role switch according to
sysfs documentation. Yes, in your role switch case, only port mux is enough,
but for others, it needs other operations.

I agree with Roger that the dual-role switch part in your code is better
to use OTG framework to reduce redundancy.

--

Best Regards,
Peter Chen