From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964846AbbCPQpB (ORCPT ); Mon, 16 Mar 2015 12:45:01 -0400 Received: from mga09.intel.com ([134.134.136.24]:46628 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933230AbbCPQo5 (ORCPT ); Mon, 16 Mar 2015 12:44:57 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,410,1422950400"; d="scan'208";a="680853988" Date: Mon, 16 Mar 2015 09:46:47 -0700 From: David Cohen To: Felipe Balbi , Linus Walleij Cc: Robert Baldyga , Heikki Krogerus , MyungJoo Ham , Chanwoo Choi , "linux-kernel@vger.kernel.org" , "linux-usb@vger.kernel.org" , baolu.lu@linux.intel.com, mika.westerberg@linux.intel.com Subject: Re: [PATCH v2] extcon: otg_gpio: add driver for USB OTG port controlled by GPIO(s) Message-ID: <20150316164647.GB17923@psi-dev26.jf.intel.com> References: <1419288217-19262-1-git-send-email-david.a.cohen@linux.intel.com> <1424375984-26241-1-git-send-email-david.a.cohen@linux.intel.com> <54E6D721.9070107@samsung.com> <20150220191700.GB15303@psi-dev26.jf.intel.com> <20150309161608.GF3739@saruman.tx.rr.com> <20150309191051.GA5425@psi-dev26.jf.intel.com> <20150316164600.GA17923@psi-dev26.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150316164600.GA17923@psi-dev26.jf.intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > > > > 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 > > > >