On 11/09/2012 04:18 PM, Grant Likely wrote:
On Fri, Nov 9, 2012 at 2:11 PM, Mathias Nyman
<mathias.nyman@xxxxxxxxxxxxxxx> wrote:
On 11/08/2012 09:38 PM, Mika Westerberg wrote:
...
+#include<linux/errno.h>
+#include<linux/gpio.h>
+#include<linux/module.h>
+#include<linux/acpi_gpio.h>
+#include<linux/acpi.h>
+
+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-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
