[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5097AD9D.7060808@linux.intel.com>
Date: Mon, 05 Nov 2012 14:14:21 +0200
From: Mathias Nyman <mathias.nyman@...ux.intel.com>
To: Linus Walleij <linus.walleij@...aro.org>
CC: Mika Westerberg <mika.westerberg@...ux.intel.com>,
linux-kernel@...r.kernel.org, lenb@...nel.org,
rafael.j.wysocki@...el.com, broonie@...nsource.wolfsonmicro.com,
grant.likely@...retlab.ca, khali@...ux-fr.org, ben-linux@...ff.org,
w.sang@...gutronix.de, linux-acpi@...r.kernel.org
Subject: Re: [PATCH 1/3] gpio / ACPI: add ACPI support
On 11/05/2012 01:53 PM, Linus Walleij wrote:
> On Sat, Nov 3, 2012 at 8:46 AM, Mika Westerberg
> <mika.westerberg@...ux.intel.com> wrote:
>
>> +/**
>> + * acpi_get_gpio() - Translate ACPI GPIO pin to GPIO number usable with GPIO API
>> + * @path: ACPI GPIO controller full path name, (e.g. "\\_SB.GPO1")
>> + * @pin: ACPI GPIO pin number (0-based, controller-relative)
>> + *
>> + * Returns GPIO number to use with Linux generic GPIO API, or errno error value
>> + */
>
> So by just looking at that we can see that this is yet another
> instance of papering
> over the fact that the Linux GPIO numbers are global to the kernel and not
> per-chip, as would be preferred.
Yes, it is. ACPI5 GPIO resources are numbered per-chip. This is just a
way for device drivers to find the corresponding Linux GPIO.
per-chip based numbering sounds saner, but this deals with what we
currently have.
>
> Can you please contribute to the parallel discussion on how to get rid of
> the global GPIO numberspace, thread named:
> "How about a gpio_get(device *, char *) function?"
I'll take a look at it, (and see if I got anything of value to add)
-Mathias
--
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/
Powered by blists - more mailing lists