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

[David Cohen]

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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/