linux-kernel - Re: [RESEND PATCH v2 3/3] ARM: dts: imx28-cfa10036: Fix the reset gpio signal polarity

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: <221a185c-19fc-cc89-49b1-aa77fb1f0e41@ysoft.com>
Date:   Tue, 9 Oct 2018 13:18:24 +0000
From:   Vokáč Michal <Michal.Vokac@...ft.com>
To:     Fabio Estevam <festevam@...il.com>
CC:     Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
        Shawn Guo <shawnguo@...nel.org>,
        Fabio Estevam <fabio.estevam@....com>,
        Rob Herring <robh+dt@...nel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        "linux-fbdev@...r.kernel.org" <linux-fbdev@...r.kernel.org>
Subject: Re: [RESEND PATCH v2 3/3] ARM: dts: imx28-cfa10036: Fix the reset
 gpio signal polarity

On 9.10.2018 14:36, Fabio Estevam wrote:
> Hi Michal,
> 
> On Tue, Oct 9, 2018 at 5:30 AM Vokáč Michal <Michal.Vokac@...ft.com> wrote:
> 
>> Sorry for the inconvenience :( Lesson learned..
>>
>> So in other words (no offense): broken drivers need to stay broken because
>> users may already get used to the broken behavior?
> 
> In order to keep the old dtb's working you could introduce a new
> property (like reset-gpio-active-low, for example).
> 
> Then the driver behavior can be made untouched for the old dtb's and
> only new dtb's with this new property would have the correct GPIO
> reset behavior.

Thank you very much Fabio!
I saw these xxx-active-low/high properties in many device tree
sources wondering why the heck people use them when they could
use GPIO_ACTIVE_LOW/HIGH. And this is the explanation.

And I feel like an idiot once again: git grep -l "reset-active-low"
first hit is:

  Documentation/devicetree/bindings/display/ssd1307fb.txt

Oooops.
The weird thing is that usage of reset-active-low is documented
in the example but it is not implemented.

So the patch no.2 should be reverted and patch no.3 not applied at all.

I will prepare a new patch utilizing the reset-active-low property.

Again, sorry for the troubles and thank you for your comments.
Michal