[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AM4PR04MB2130809FDDC36F2C7F8C0F25895D0@AM4PR04MB2130.eurprd04.prod.outlook.com>
Date: Tue, 7 Jun 2016 03:03:58 +0000
From: Jun Li <jun.li@....com>
To: Roger Quadros <rogerq@...com>, Lu Baolu <baolu.lu@...ux.intel.com>,
"Peter Chen" <hzpeterchen@...il.com>
CC: "felipe.balbi@...ux.intel.com" <felipe.balbi@...ux.intel.com>,
"Mathias Nyman" <mathias.nyman@...el.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Lee Jones <lee.jones@...aro.org>,
"Heikki Krogerus" <heikki.krogerus@...ux.intel.com>,
Liam Girdwood <lgirdwood@...il.com>,
Mark Brown <broonie@...nel.org>,
"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux
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),
this is just an example for us to convince people to select a better
way:)
Li Jun
Powered by blists - more mailing lists