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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150316164647.GB17923@psi-dev26.jf.intel.com>
Date:	Mon, 16 Mar 2015 09:46:47 -0700
From:	David Cohen <david.a.cohen@...ux.intel.com>
To:	Felipe Balbi <balbi@...com>,
	Linus Walleij <linus.walleij@...aro.org>
Cc:	Robert Baldyga <r.baldyga@...sung.com>,
	Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
	MyungJoo Ham <myungjoo.ham@...sung.com>,
	Chanwoo Choi <cw00.choi@...sung.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	baolu.lu@...ux.intel.com, mika.westerberg@...ux.intel.com
Subject: Re: [PATCH v2] extcon: otg_gpio: add driver for USB OTG port
 controlled by GPIO(s)

On Mon, Mar 16, 2015 at 09:46:00AM -0700, David Cohen wrote:
> Adding Mika to CC list.

Grrr :(
Adding for real now.

> 
> 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@...ux.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
> > 
> > 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/