Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754110Ab2KIPDI (ORCPT ); Fri, 9 Nov 2012 10:03:08 -0500 Received: from mga02.intel.com ([134.134.136.20]:32034 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753527Ab2KIPDD (ORCPT ); Fri, 9 Nov 2012 10:03:03 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.80,746,1344236400"; d="scan'208";a="217307669" Message-ID: <509D1BC5.7020208@linux.intel.com> Date: Fri, 09 Nov 2012 17:05:41 +0200 From: Mathias Nyman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Grant Likely CC: Mika Westerberg , linux-kernel@vger.kernel.org, lenb@kernel.org, rafael.j.wysocki@intel.com, broonie@opensource.wolfsonmicro.com, linus.walleij@linaro.org, khali@linux-fr.org, ben-linux@fluff.org, w.sang@pengutronix.de, linux-acpi@vger.kernel.org Subject: Re: [PATCH 1/3] gpio / ACPI: add ACPI support References: <1351928793-14375-1-git-send-email-mika.westerberg@linux.intel.com> <1351928793-14375-2-git-send-email-mika.westerberg@linux.intel.com> <20121108193808.GB16012@intel.com> <509D0F1F.70001@linux.intel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3066 Lines: 80 On 11/09/2012 04:18 PM, Grant Likely wrote: > On Fri, Nov 9, 2012 at 2:11 PM, Mathias Nyman > wrote: >> On 11/08/2012 09:38 PM, Mika Westerberg wrote: >> ... >> >>>>> +#include >>>>> +#include >>>>> +#include >>>>> +#include >>>>> +#include >>>>> + >>>>> +static int acpi_gpiochip_find(struct gpio_chip *gc, void *data) >>>>> +{ >>>>> + acpi_handle handle = data; >>>>> + acpi_handle gc_handle; >>>>> + >>>>> + if (!gc->dev) >>>>> + return false; >>>>> + >>>>> + gc_handle = gc->dev->acpi_handle; >>>>> + if (!gc_handle) >>>>> + return false; >>>> >>>> >>>> This test is redundant with the next one... unless 'handle' is also NULL >>>> :-) >>>> >>>> Is it at all possible for multiple gpiochips to be used for a single >>>> ACPI gpio controller node? Such as if the gpio controller has multiple >>>> banks that should be controlled separately? If so then this won't be >>>> sufficient. I've got the same issue with DT support where the find >>>> function needs to also check if the pin is provided by that specific >>>> gpiochip. >>> >>> >>> AFAIK no but I'll let Mathias to answer that as he knows this better. >> >> >> I'm interpreting it the same way as Mika, max one actual controller per ACPI >> device node >> >> The path (called ResourceSource in ACPI5 specs) in GpioIO/GpioInt resources >> is a "string which uniquely identifies the GPIO controller referred to by >> this descriptor." The pin number is zero based controller relative. >> >> The ACPI device controller node includes all other resources needed by the >> controller driver (ioport/mem base, range, interrupt, and Hardware ID used >> to pair with a driver) >> >> Checked a board with two identical gpio controllers on it and it had two >> separate ACPI device node entries. (with only different io address base and >> interrupt resources) > > That's not really the situation that I'm thinking about. What I mean > is for a gpio controller that is more convenient for Linux to support > using multiple gpiochips (Linux internal detail), even though there it > is described with a single ACPI node. > Ok, now I get it. Yes, in case a driver uses several gpiochips internally for different banks of a controller then all would have the same acpi_handle. acpi_get_gpio() would use the gpiobase of the first gpiochip that matches the handle, even if it's the wrong one. I guess It's possible to write a driver like that. The only acpi enumerated driver with the acpi_handle set (soon coming to upstream) is not done like that. Do you think this is a case that should be solved now? or just expect acpi gpio device driver to not use several gpiochips in one driver? -Mathias -- 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/