From: Linus Walleij <linus.walleij@linaro.org>
To: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Cc: Khouloud Touil <ktouil@baylibre.com>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
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 14:46:36 +0100 [thread overview]
Message-ID: <CACRpkdaPQKxfC66yhG=xdmCOGGd9PjDVCwZquKb+4HmuS_=kNA@mail.gmail.com> (raw)
In-Reply-To: <CAMpxmJU_0MzroyD_ZF5WOxpZz3dkADLOmW7aKpWdJ7GCvo-RnA@mail.gmail.com>
On Fri, Nov 22, 2019 at 2:04 PM Bartosz Golaszewski
<bgolaszewski@baylibre.com> wrote:
> > I would to like this:
> >
> > 1. Add a new generic property
> > writeprotect-gpios that mandates to use GPIO_ACTIVE_LOW
> > and use this in the new example
> >
> > 2. Deprecate wp-gpios in the binding, keep it around but deprecated.
>
> This is a pretty standard property though - for instance it is
> documented in the main mmc binding and doesn't mandate GPIO_ACTIVE_LOW
> either. I think this is because nobody says that the write-protect
> line must always be driver low to be asserted - this is highly
> implementation-specific.
The MMC case is actually especially convoluted. It has always
respected the GPIO_ACTIVE_LOW flag, and that is used if
present. At the same time it *also* supported a bool
wp-inverted flag, with the specified semantic that if both
were specified (ACTIVE_LOW and wp-inverted) the result
would be nothing as it is a double logical inversion.
So that is why the quirk looks like this:
/*
* Handle MMC "cd-inverted" and "wp-inverted" semantics.
*/
if (IS_ENABLED(CONFIG_MMC)) {
/*
* Active low is the default according to the
* SDHCI specification and the device tree
* bindings. However the code in the current
* kernel was written such that the phandle
* flags were always respected, and "cd-inverted"
* would invert the flag from the device phandle.
*/
if (!strcmp(propname, "cd-gpios")) {
if (of_property_read_bool(np, "cd-inverted"))
*flags ^= OF_GPIO_ACTIVE_LOW;
}
if (!strcmp(propname, "wp-gpios")) {
if (of_property_read_bool(np, "wp-inverted"))
*flags ^= OF_GPIO_ACTIVE_LOW;
}
}
Nevermind MMC though.
The current code for at24 has an ambiguousness issue: if
the gpios cell 2 is specified as GPIO_ACTIVE_LOW
(which is in some sense correct) then the effect will be
that it is driven high to assert the wp, which is ... rather
counterintuitive.
I could think of a compromise like this:
1. Keep "wp-gpios"
2. Add a quirk to gpiolib-of.c that will force that as active
low no matter what flag is specified to the GPIO descriptor.
3. If some other flag that GPIO_ACTIVE_LOW is specified,
print a warning and say the the (default) GPIO_ACTIVE_HIGH
i.e. 0 is gonna be ignored and we forced the line to be
active low.
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.
5. Hope that no system with an active high wp ever comes
into existence because then we are screwed and will have
to create a new binding and deprecate the old binding
anyway.
Yours,
Linus Walleij
next prev parent reply other threads:[~2019-11-22 13:46 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 [this message]
[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
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='CACRpkdaPQKxfC66yhG=xdmCOGGd9PjDVCwZquKb+4HmuS_=kNA@mail.gmail.com' \
--to=linus.walleij@linaro.org \
--cc=baylibre-upstreaming@groups.io \
--cc=bgolaszewski@baylibre.com \
--cc=devicetree@vger.kernel.org \
--cc=ktouil@baylibre.com \
--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).