linux-kernel - Re: [PATCH 2/2] gpio: of: Allow -gpio suffix for property names

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: <CACRpkdYtuQDFZxf5FhY4Dc9CQka=wMZwEETBks450zVK0rEL3w@mail.gmail.com>
Date:	Fri, 2 May 2014 15:22:58 -0700
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Stephen Warren <swarren@...dotorg.org>
Cc:	Thierry Reding <thierry.reding@...il.com>,
	Rob Herring <robherring2@...il.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Alexandre Courbot <gnurou@...il.com>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] gpio: of: Allow -gpio suffix for property names

On Fri, Apr 25, 2014 at 8:24 AM, Stephen Warren <swarren@...dotorg.org> wrote:
> On 04/24/2014 12:22 PM, Thierry Reding wrote:
> ...
>> The downside of not allowing the gpiod API to support the -gpio suffix
>> is that we'll never be able to convert drivers that use such a binding
>> and will forever have a hodgepodge of GPIO APIs that we need to support.
>
> Perhaps rather than making the existing gpiod API automatically search
> for both -gpios and -gpio, we could make a new API for the other suffix,
> so that driver indicate explicitly which property name they want. That
> way, someone can't accidentally write -gpio in the DT and have it still
> work. Or, add a parameter to the existing API, but that's probably a lot
> more churn.

Hm, that is possible, I just worry that this will lead the DT and ACPI
semantics to diverge even more, and the present patch make things
more coherent from the framework side of things instead of even more
elaborate per-HW-info-method :-/

Yours,
Linus Walleij
--
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/