Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753391AbbBYSX0 (ORCPT ); Wed, 25 Feb 2015 13:23:26 -0500 Received: from mga09.intel.com ([134.134.136.24]:43302 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752825AbbBYSXX (ORCPT ); Wed, 25 Feb 2015 13:23:23 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,646,1418112000"; d="scan'208";a="690705425" Date: Wed, 25 Feb 2015 10:25:02 -0800 From: David Cohen To: Alexandre Courbot Cc: "Rafael J. Wysocki" , Linus Walleij , Heikki Krogerus , "Rafael J. Wysocki" , Darren Hart , Arnd Bergmann , Andy Shevchenko , Mika Westerberg , "linux-gpio@vger.kernel.org" , "linux-kernel@vger.kernel.org" , ACPI Devel Maling List Subject: Re: [RFC PATCH] gpio: support for GPIO forwarding Message-ID: <20150225182502.GA7586@psi-dev26.jf.intel.com> References: <1418890998-23811-1-git-send-email-heikki.krogerus@linux.intel.com> <4078818.ecVtLF3hjd@vostro.rjw.lan> <20150224203459.GC13094@psi-dev26.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Content-Length: 2243 Lines: 50 On Wed, Feb 25, 2015 at 10:34:45AM +0900, Alexandre Courbot wrote: > On Wed, Feb 25, 2015 at 5:34 AM, David Cohen > wrote: > > Hi, > > > >> If we decide to go ahead with the solution proposed by this patch for > >> practical reasons (which are good reasons indeed), I still have one > >> problem with its current form. > >> > >> As the discussion highlighted, this is an ACPI problem, so I'd very > >> much like it to be confined to the ACPI GPIO code, to be enabled only > >> when ACPI is, and to use function names that start with acpi_gpio. The > >> current implementation leverages platform lookup, making said lookup > >> less efficient in the process and bringing confusion about its > >> purpose. Although the two processes are indeed similar, they are > >> separate things: one is a legitimate way to map GPIOs, the other is a > >> fixup for broken firmware. > >> > >> I suppose we all agree this is a hackish fix, so let's confine it as > >> much as we can. > > > > Are we considering MFD cases hackish as well? > > i.e. if we have a driver that needs to register children devices and this > > driver needs to pass GPIO to a child. > > In that case wouldn't the GPIO be best defined in the child node > itself, for the child device's driver to directly probe? In my case [1] I need 2 "virtual devices" (and more in future) to be part of an USB OTG port control. I call it virtual because they are too simple components connected to no bus and controlled by GPIOs: - a fixed regulator controlled by GPIO - a generic mux controlled by GPIO I'd need to request official ACPI HID for them in order to make them self-sufficient. I can go ahead with this approach, but we have many examples of drivers on upstream that are platform driver expecting to receive gpio via platform data (e.g. extcon-gpio). The ACPI table of some products on market were defined following this concept and won't change anymore. Br, David [1] https://lkml.org/lkml/2015/2/19/411 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/