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