Thread (130 messages) 130 messages, 14 authors, 2014-10-07

Re: [RFC PATCH v2 07/16] gpio: Add support for unified device properties interface

From: Arnd Bergmann <arnd@arndb.de>
Date: 2014-09-23 15:46:17
Also in: linux-acpi, lkml

On Tuesday 23 September 2014 17:25:50 Linus Walleij wrote:
On Tue, Sep 16, 2014 at 1:52 PM, Mika Westerberg
[off-list ref] wrote:
quoted
Some drivers need to deal with only firmware representation of its
GPIOs. An example would be a GPIO button array driver where each button
is described as a separate firmware node in device tree. Typically these
child nodes do not have physical representation in the Linux device
model.

In order to help device drivers to handle such firmware child nodes we
add dev[m]_node_get_named_gpiod() that takes a firmware node pointer as
parameter, finds the GPIO using whatever is the underlying firmware
method, and requests the GPIO properly.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
I have a hard time figuring out if this is what we want for common
accessors between DT and ACPI.

Can I get some input from Grant, Arnd, Mark, Darren...?
I just took a brief look at this. My first impression is that the
fw_dev_node structure is weird when all callers just do (in patch 2)

+	struct fw_dev_node fdn = {
+		.of_node = dev->of_node,
+		.acpi_node = ACPI_COMPANION(dev),
+	};

I'd much rather see an interface that passes the 'struct device'
pointer down to dev_get_named_gpiod() and all other exported
functions, and then internally does the conversion at the point
where the access is done.

	Arnd
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help