linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Rosin <peda@axentia.se>
To: Linus Walleij <linus.walleij@linaro.org>,
	Khouloud Touil <ktouil@baylibre.com>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
	"baylibre-upstreaming@groups.io" <baylibre-upstreaming@groups.io>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>,
	linux-i2c <linux-i2c@vger.kernel.org>
Subject: Re: [PATCH 1/4] dt-bindings: nvmem: new optional property write-protect-gpios
Date: Fri, 22 Nov 2019 13:10:28 +0000	[thread overview]
Message-ID: <40a0a19f-fe8f-a670-1a70-d8023acdbe65@axentia.se> (raw)
In-Reply-To: <CACRpkdaZrvPObjyN4kasARzKZ9=PiAcvTzXzWkmC7R+Ay5tU8w@mail.gmail.com>

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@baylibre.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@700000 {
>>            #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
> 


  parent reply	other threads:[~2019-11-22 13:10 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-20 14:20 [PATCH 0/4] at24: move write-protect pin handling to nvmem core Khouloud Touil
2019-11-20 14:20 ` [PATCH 1/4] dt-bindings: nvmem: new optional property write-protect-gpios Khouloud Touil
2019-11-22 12:41   ` Linus Walleij
2019-11-22 12:47     ` Bartosz Golaszewski
2019-11-22 12:53       ` Linus Walleij
2019-11-22 13:04         ` Bartosz Golaszewski
2019-11-22 13:46           ` Linus Walleij
     [not found]             ` <CALL1Z1xpcGyh_f3ooRT+gGApoAnS7YBMd2hUKqnt+pTcAFoeAg@mail.gmail.com>
2019-11-28 13:44               ` Linus Walleij
2019-11-29  8:47                 ` Bartosz Golaszewski
2019-12-04 15:14                   ` Rob Herring
2019-11-22 13:10     ` Peter Rosin [this message]
2019-11-20 14:20 ` [PATCH 2/4] nvmem: add support for the write-protect pin Khouloud Touil
2019-11-22 12:47   ` Linus Walleij
2019-11-20 14:20 ` [PATCH 3/4] dt-bindings: at24: remove the optional property write-protect-gpios Khouloud Touil
2019-12-04 15:22   ` Rob Herring
2019-11-20 14:20 ` [PATCH 4/4] eeprom: at24: remove the write-protect pin support Khouloud Touil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=40a0a19f-fe8f-a670-1a70-d8023acdbe65@axentia.se \
    --to=peda@axentia.se \
    --cc=baylibre-upstreaming@groups.io \
    --cc=bgolaszewski@baylibre.com \
    --cc=devicetree@vger.kernel.org \
    --cc=ktouil@baylibre.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=srinivas.kandagatla@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).