linux-kernel - Re: [PATCH 1/4] dt-bindings: nvmem: new optional property write-protect-gpios

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-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 22 Nov 2019 13:10:28 +0000
From:   Peter Rosin <peda@...ntia.se>
To:     Linus Walleij <linus.walleij@...aro.org>,
        Khouloud Touil <ktouil@...libre.com>
CC:     Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        "baylibre-upstreaming@...ups.io" <baylibre-upstreaming@...ups.io>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>, linux-i2c <linux-i2c@...r.kernel.org>
Subject: Re: [PATCH 1/4] dt-bindings: nvmem: new optional property
 write-protect-gpios

On 2019-11-22 13:41, Linus Walleij wrote:
> Hi Khouloud,
> 
> thanks for your patch!
> 
> I just have a semantic comment:
> 
> On Wed, Nov 20, 2019 at 3:21 PM Khouloud Touil <ktouil@...libre.com> wrote:
> 
>> Instead of modifying all the memory drivers to check this pin, make
>> the NVMEM subsystem check if the write-protect GPIO being passed
>> through the nvmem_config or defined in the device tree and pull it
>> low whenever writing to the memory.
> 
> It is claimed that this should be pulled low to assert it so by
> definition it is active low.
> 
>> +  wp-gpios:
>> +    description:
>> +      GPIO to which the write-protect pin of the chip is connected.
>> +    maxItems: 1
> 
> Mandate that the flag in the second cell should be GPIO_ACTIVE_LOW

What if something along that way from CPU to chip inverts the signal such
that the signal is no longer active-low when viewed from the CPU, even if
it still is active low when looking at the chip only?

Yes, these things happen for all kinds of hysterical reasons...

Cheers,
Peter

> 
>>  patternProperties:
>>    "^.*@[0-9a-f]+$":
>>      type: object
>> @@ -66,6 +71,7 @@ examples:
>>        qfprom: eeprom@...000 {
>>            #address-cells = <1>;
>>            #size-cells = <1>;
>> +          wp-gpios = <&gpio1 3 0>;
> 
> #include <dt-bindings/gpio/gpio.h>
> wp-gpios = <&gpio1 3 GPIO_ACTIVE_LOW>;
> 
> This will in Linux have the semantic effect that you need to
> set the output high with gpio_set_val(d, 1) to assert it
> (drive it low) but that really doesn't matter to the device tree
> bindings, those are OS-agnostic: if the line is active low then
> it should use this flag.
> 
> It has the upside that the day you need a write-protect that
> is active high, it is simple to support that use case too.
> 
> Yours,
> Linus Walleij
>