Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752919AbbBYBfJ (ORCPT ); Tue, 24 Feb 2015 20:35:09 -0500 Received: from mail-ig0-f180.google.com ([209.85.213.180]:55010 "EHLO mail-ig0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752290AbbBYBfF (ORCPT ); Tue, 24 Feb 2015 20:35:05 -0500 MIME-Version: 1.0 In-Reply-To: <20150224203459.GC13094@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> From: Alexandre Courbot Date: Wed, 25 Feb 2015 10:34:45 +0900 Message-ID: Subject: Re: [RFC PATCH] gpio: support for GPIO forwarding To: David Cohen 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 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1428 Lines: 31 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? -- 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/