Messages in this thread | | | Date | Wed, 4 Dec 2019 09:14:24 -0600 | From | Rob Herring <> | Subject | Re: [PATCH 1/4] dt-bindings: nvmem: new optional property write-protect-gpios |
| |
On Fri, Nov 29, 2019 at 09:47:01AM +0100, Bartosz Golaszewski wrote: > czw., 28 lis 2019 o 14:45 Linus Walleij <linus.walleij@linaro.org> napisał(a): > > > > On Tue, Nov 26, 2019 at 4:18 PM Khouloud Touil <ktouil@baylibre.com> wrote: > > > > > [Me] > > >> 4. The code still need to be modified to set the value > > >> to "1" to assert the line since the gpiolib now handles > > >> the inversion semantics. > > > > > By saying "assert the wp" do you mean enable the write operation or > > > block it ? > > > > Yeah one more layer of confusion, sorry :/ > > > > By "asserting WP" I mean driving the line to a state where > > writing to the EEPROM is enabled, i.e. the default state is > > that the EEPROM is write protected and when you "assert" > > WP it becomes writable. > > > > If you feel the inverse semantics are more intuitive (such that > > WP comes up asserted and thus write protected), be my > > guest :D > > > > Ha! I've always assumed that "to assert the write-protect pin" means > to *protect* the EEPROM from writing. That's why it comes up as > asserted (logical '1' in the driver) and we need to deassert it (drive > it low, logical '0' in the driver) to enable writing. This is the > current behavior and I'd say in this case it's just a matter of very > explicit statement that this is how it works in the DT binding? > > Rob: any thoughts on this?
I agree with you. If it was called write-enable-gpios, then assert would be to enable writing.
Rob
| |