Re: [PATCH v2] extcon: otg_gpio: add driver for USB OTG port controlled by GPIO(s)

[David Cohen <david.a.cohen@linux.intel.com>]

Adding Mika to CC list.

Br, David

On Mon, Mar 09, 2015 at 12:10:51PM -0700, David Cohen wrote:
> Hi Linus,
> 
> On Mon, Mar 09, 2015 at 11:16:08AM -0500, Felipe Balbi wrote:
> > On Sat, Mar 07, 2015 at 09:06:22PM +0100, Linus Walleij wrote:
> > > On Fri, Feb 20, 2015 at 8:17 PM, David Cohen
> > > <david.a.cohen@linux.intel.com> wrote:
> > > > On Fri, Feb 20, 2015 at 10:53:44AM +0100, Linus Walleij wrote:
> > > 
> > > >> I would put this adjacent to the phy driver somewhere in drivers/usb/*
> > > >> and make the actual USB-driver thing handle its GPIOs directly.
> > > >> But I guess David and Felipe have already discussed that as we're
> > > >> seeing this patch?
> > > >
> > > > - The mux functions would be controlled by a possible new pinctrl-gpio
> > > > driver (Linus, your input here would be nice :)
> > > 
> > > I don't understand what this means, does it mean a pin control function
> > > somewhere else controlled by a GPIO pin?
> > > 
> > > Or do you mean a new combined pin control and GPIO driver (we have
> > > plenty of these).
> > > 
> > > If you elaborate on what you need to do in that driver I might
> > > understand it better.
> 
> This is a "virtual" ACPI device. Long story short we've 3 GPIOs
> controlling the state of an USB OTG port. Neither of the hw components
> controlled by these GPIOs are connected to a bus.
> The ACPI table was implemented in such way that it considers this USB
> port as a single "device" giving all 3 GPIOs to it.
> 
> When upstreaming this driver, the feedback I got is to split this driver
> into simpler and more generic ones. FWIW ACPI tables are constructed
> considering a valid Linux API during its implementation and are quite
> difficult to change after product is released. The solution would be to
> use MFD subsystem: this driver would create simpler children platform
> devices.
> 
> But at least on ACPI case, GPIO API blocks the ability to create
> children platform devices that require GPIO as platform data, despite
> we've many drivers on upstream that expect this behavior: e.g. extcon-gpio.c
> 
> Are we considering those driver deprecated from the GPIO point of view?
> If yes, we need to provide an update for them (we can't let upstreamed
> drivers broken). If no, we need to provide a way to move forward the
> GPIO to children devices.
> 
> BR, David
> 
> > 
> > there's a discrete mux (not something integrated in the SoC) whose
> > select signal is tied to a GPIO (in some cases, more than one, but
> > usually people use 2-state muxes).
> > 
> > -- 
> > balbi
> 
>