From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755220AbcFGM6i (ORCPT ); Tue, 7 Jun 2016 08:58:38 -0400 Received: from comal.ext.ti.com ([198.47.26.152]:39509 "EHLO comal.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754203AbcFGM6h (ORCPT ); Tue, 7 Jun 2016 08:58:37 -0400 Subject: Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux To: Lu Baolu , Jun Li , Peter Chen References: <1464831449-8973-1-git-send-email-baolu.lu@linux.intel.com> <1464831449-8973-3-git-send-email-baolu.lu@linux.intel.com> <20160603074113.GA30006@shlinux2> <5751AAEE.2090001@linux.intel.com> <20160604022838.GA26936@shlinux2> <5753CCFC.2060504@linux.intel.com> <20160606012557.GA16012@shlinux2> <5754E850.1020707@linux.intel.com> <57552006.7080108@ti.com> <5756999B.9020809@linux.intel.com> CC: "felipe.balbi@linux.intel.com" , Mathias Nyman , Greg Kroah-Hartman , Lee Jones , Heikki Krogerus , Liam Girdwood , Mark Brown , "linux-usb@vger.kernel.org" , "linux-kernel@vger.kernel.org" From: Roger Quadros Message-ID: <5756C4DB.1050400@ti.com> Date: Tue, 7 Jun 2016 15:58:03 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <5756999B.9020809@linux.intel.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/06/16 12:53, Lu Baolu wrote: > 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. We have a minimal dual-role state machine that just looks at ID pin and toggles the port role. How are you switching the port mux between host and peripheral? Only by sysfs or do you have a GPIO for ID pin as well? What happens to the gadget controller when the port is muxed to the host controller? Is it stopped or it continues to run? cheers, -roger