linux-kernel - Re: [PATCH 11/13] gpio: Support for unified device properties interface

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1693047.RuqBhhrutB@vostro.rjw.lan>
Date:	Wed, 08 Oct 2014 02:09:26 +0200
From:	"Rafael J. Wysocki" <rjw@...ysocki.net>
To:	Alexandre Courbot <gnurou@...il.com>
Cc:	Mika Westerberg <mika.westerberg@...ux.intel.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linus Walleij <linus.walleij@...aro.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	Aaron Lu <aaron.lu@...el.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Bryan Wu <cooloney@...il.com>,
	Grant Likely <grant.likely@...aro.org>,
	Arnd Bergmann <arnd@...db.de>,
	Darren Hart <dvhart@...ux.intel.com>,
	Mark Rutland <mark.rutland@....com>
Subject: Re: [PATCH 11/13] gpio: Support for unified device properties interface

On Tuesday, October 07, 2014 07:52:02 PM Alexandre Courbot wrote:
> On Tue, Oct 7, 2014 at 7:40 PM, Mika Westerberg
> <mika.westerberg@...ux.intel.com> wrote:
> > On Tue, Oct 07, 2014 at 07:22:13PM +0900, Alexandre Courbot wrote:
> >> On Tue, Oct 7, 2014 at 9:18 AM, Rafael J. Wysocki <rjw@...ysocki.net> wrote:
> >> > From: Mika Westerberg <mika.westerberg@...ux.intel.com>
> >> >
> >> > 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]_get_named_gpiod_from_child() that takes a child firmware
> >> > node pointer as its second argument (the first one is the parent device
> >> > itself), finds the GPIO using whatever is the underlying firmware
> >> > method, and requests the GPIO properly.
> >> >
> >> > Signed-off-by: Mika Westerberg <mika.westerberg@...ux.intel.com>
> >> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> >>
> >> ...
> >>
> >> > +/* Child properties interface */
> >> > +struct gpio_desc *dev_get_named_gpiod_from_child(struct device *dev, void *child,
> >> > +                                                const char *propname, int index);
> >> > +struct gpio_desc *devm_get_named_gpiod_from_child(struct device *dev, void *child,
> >> > +                                                 const char *propname, int index);
> >>
> >> I see the reason for these functions and am not opposed to them.
> >> However, I wonder if we could not replace propname by a con_id that
> >> would be resolved to one of con_id-gpio for DT and whatever naming
> >> convention ACPI is using?
> >
> > The code in gpio-leds.c and gpio_keys_polled.c refers to "gpios" as the
> > property name. If we can change that somehow to work with con_id-gpio
> > instead without breaking things, then why not.
> >
> >> This would prevent users to name GPIOs outside of the conventions
> >> defined in the bindings and be generally safer. Is there a particular
> >> reason (used by some old code?) for the current direct property
> >> access? If not, maybe we could call a slightly-modified of_find_gpio()
> >> to resolve the GPIO property for DT, and the equivalent function for
> >> ACPI?
> >
> > Only reason I can think of is support for the existing properties that
> > are used directly. Drivers using gpiod_get() and friends do not need
> > dev_get_named_gpiod_from_child() anyway.
> 
> Right. Another thing is that the property handling code (active low
> only for now) is duplicated again, but that can be addressed
> separately.
> 
> I will have a look at gpio-leds and gpio_keys_polled to see if we
> cannot make this work at a higher level. It's easier to have the
> bindings respected if the code itself enforces them.

I'm wondering if that can be done after merging the current work?

We'll be able to use the drivers in question with our hardware in the
meantime then ...

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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/