Messages in this thread | | | Subject | Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux | From | Lu Baolu <> | Date | Tue, 7 Jun 2016 17:53:31 +0800 |
| |
Hi,
On 06/07/2016 11:03 AM, Jun Li wrote: > Hi Roger > >> >> For Mux devices implementing dual-role, the mux device driver _must_ use >> OTG/dual-role core API so that a common ABI is presented to user space for >> OTG/dual-role. > That's the only point we have concern, do dual role switch through > OTG/dual-role core, not do it by itself. > >> I haven't yet looked at the mux framework but if we take care of the above >> point then we are not introducing any redundancy. >> > Roger, actually this is my worry on OTG core: those dual role switch > users just tends to do it simply by itself(straightforward and easy), > not through the OTG core(some complicated in first look),
I'm sorry, but I'm really confused.
Why do we need to drop "straightforward and easy", but have to run an *unnecessary* OTG state machine? Don't you think that will (1) add *unnecessary* software complexity; (2) increase *unnecessary* memory footprint; and (3) increase the debugging efforts?
> this is just an example for us to convince people to select a better > way:)
Sure. Let's take my case for an example.
My system has a third-party port mux, which is not part any USB controllers. Also, my system doesn't have any DRD capable devices. I need a "straightforward and easy" driver for it. Otherwise, the system could not be waken up from system suspend.
But you said I must run an unnecessary OTG state machine, even thought it has nothing to do with my system, only because the two sides of my port mux device is a host and peripheral controller.
Why?
Best regards, Lu Baolu
| |