linux-kernel - Re: [PATCH 4/4] iio: hi8435: cleanup reset gpio

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 for Android: free password hash cracker in your pocket

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

Date:   Tue, 23 May 2017 11:18:26 +0300
From:   Nikita Yushchenko <nikita.yoush@...entembedded.com>
To:     Vladimir Barinov <vladimir.barinov@...entembedded.com>,
        Jonathan Cameron <jic23@...nel.org>,
        Hartmut Knaack <knaack.h@....de>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Peter Meerwald-Stadler <pmeerw@...erw.net>,
        Matt Ranostay <mranostay@...il.com>,
        Gregor Boirie <gregor.boirie@...rot.com>,
        Sanchayan Maity <maitysanchayan@...il.com>
Cc:     linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org,
        Jeff White <Jeff.White@....aero>,
        Chris Healy <Chris.Healy@....aero>
Subject: Re: [PATCH 4/4] iio: hi8435: cleanup reset gpio

>> Reset GPIO is active low.
>>
>> Currently driver uses gpiod_set_value(1) to clean reset, which depends
>> on device tree to contain GPIO_ACTIVE_HIGH - that does not match reality.
>>
>> This fixes driver to use _raw version of gpiod_set_value() to enforce
>> active-low semantics despite of what's written in device tree. Allowing
>> device tree to override that only opens possibility for errors and does
>> not add any value.
>>
>> Additionally, use _cansleep version to make things work with i2c-gpio
>> and other sleeping gpio drivers.
> 
> The reset gpio comes from platform hence it should be handled by DTS.
> 
> In driver the gpio should not be raw.
> 
> Even the hi8435 is active low but platform may invert signal (f.e. by
> adding trigger on the circuit path).

I see.  However - isn't this pure theoretic?  Does such case exist?

In vast majority of cases, GPIO polarity is chip-specific, not
chip-use-specific.  Thus this knowlege belongs to driver and not to
device tree describing particular chip usage.  Having this always
defined at usage side is IMO major source of errors.

In this particular case, we already have device trees in the wild with
polarity set to active_high.  If we now change that to require
active_low, we break existing setups.  Not sure this is acceptable.

I'm unsure what is good way forward here. I believe it is at gpiolib
level, which perhaps should change how "logical value" is defined, such
that knowledge of chip-specific information is not forced to chip usage
scope.

Nikita