[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdbO20No0A7ttS=kfMx9qE_MZoZzOtPObHefwnNbixpCeg@mail.gmail.com>
Date: Fri, 14 Nov 2014 10:19:47 +0100
From: Linus Walleij <linus.walleij@...aro.org>
To: Alexandre Courbot <gnurou@...il.com>
Cc: Benoit Parrot <bparrot@...com>,
"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
Pantelis Antoniou <panto@...oniou-consulting.com>,
Jiri Prchal <jiri.prchal@...ignal.cz>
Subject: Re: [RFC Patch] gpio: add GPIO hogging mechanism
On Wed, Oct 29, 2014 at 8:09 AM, Alexandre Courbot <gnurou@...il.com> wrote:
> On Wed, Oct 22, 2014 at 5:09 AM, Benoit Parrot <bparrot@...com> wrote:
> + line_b: line_b {
> + line_b {
> + gpios = <6 0>;
> + output-low;
> + line-name = "foo-bar-gpio";
> + };
> + };
>
(...)
>
> I wonder if such usage of child nodes could not interfere with GPIO
> drivers (existing or to be) that need to use child nodes for other
> purposes. Right now there is no way to distinguish a hog node from a
> node that serves another purpose, and that might become a problem in
> the future.
Yes, so I have suggested a hog-something; keyword in there.
As long as the children don't have any compatible-strings we can
decide pretty much how they should be handled internally.
Are there custom drivers with child nodes inside the main chip
today?
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/
Powered by blists - more mailing lists