linux-kernel - Re: gpio-pxa: getting GPIOs by devicetree phandle broken

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: <87r3tz7bro.fsf@free.fr>
Date:	Mon, 09 Feb 2015 09:02:51 +0100
From:	Robert Jarzmik <robert.jarzmik@...e.fr>
To:	Alexandre Courbot <gnurou@...il.com>
Cc:	Tyler Hall <tylerwhall@...il.com>,
	"linux-gpio\@vger.kernel.org" <linux-gpio@...r.kernel.org>,
	"devicetree\@vger.kernel.org" <devicetree@...r.kernel.org>,
	Daniel Mack <zonque@...il.com>,
	Hans Holmberg <hans.holmberg@...el.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Howard Cochran <cochran@...mark.com>
Subject: Re: gpio-pxa: getting GPIOs by devicetree phandle broken

Alexandre Courbot <gnurou@...il.com> writes:

> Adding Robert who reported the same thing.
>
> On Sat, Feb 7, 2015 at 6:28 AM, Tyler Hall <tylerwhall@...il.com> wrote:
>> 1. Require child nodes in DT for each bank
>
> This would break DT compatibility.
Agreed.

>
>> 2. Refactor gpio-pxa to only register one gpiochip
>
> Sounds better, especially since this would reflect the hardware more
> accurately. One DT node should translate into one GPIO chip.
Could I know where "should translate into _one_ GPIO chip" comes from ? Is it a
specification, or is it a new rule we're creating ?

And if it's a new rule, I'd like to know what backs it up .

> problem is that I'm afraid several other drivers are doing the same
> thing and thus are now similarly broken.
That's also what I'm afraid of.

> The following is also likely to work as a workaround, but I would not
> go as far as saying this should be taken as a fix. Hans, since you
> wrote 7b8792b, could we have your input on this?
I was going to suggest the very same approach. If this one (or a similar one)
doesn't meet success, then my weekend of revert queries is not over ... and I
don't like reverts.

Cheers.

-- 
Robert
--
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/