On Fri, Nov 29, 2019 at 09:47:01AM +0100, Bartosz Golaszewski wrote: > czw., 28 lis 2019 o 14:45 Linus Walleij <linus.walleij@xxxxxxxxxx> napisał(a): > > > > On Tue, Nov 26, 2019 at 4:18 PM Khouloud Touil <ktouil@xxxxxxxxxxxx> 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
