From: Andrew Jeffery <andrew@aj.id.au>
To: Linus Walleij <linus.walleij@linaro.org>,
Bartosz Golaszewski <bgolaszewski@baylibre.com>,
Michael Welling <mwelling@emacinc.com>
Cc: "linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
Jonathan Corbet <corbet@lwn.net>, Joel Stanley <joel@jms.id.au>,
Ryan Chen <ryan_chen@aspeedtech.com>,
Rob Herring <robh+dt@kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
Charles Keepax <ckeepax@opensource.wolfsonmicro.com>,
Laxman Dewangan <ldewangan@nvidia.com>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
patches@opensource.cirrus.com,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
OpenBMC Maillist <openbmc@lists.ozlabs.org>,
linux-aspeed@lists.ozlabs.org
Subject: Re: [RFC PATCH 1/5] gpio: gpiolib: Add core support for maintaining GPIO values on reset
Date: Fri, 20 Oct 2017 19:02:27 +1030 [thread overview]
Message-ID: <1508488347.24322.51.camel@aj.id.au> (raw)
In-Reply-To: <CACRpkdaW5jMEh_OR2oiy_Bc-6Cb+GM1Uap+1u2T2hw85CwBh3g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2088 bytes --]
On Fri, 2017-10-20 at 09:43 +0200, Linus Walleij wrote:
> On Fri, Oct 20, 2017 at 9:17 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> > > > On Fri, Oct 20, 2017 at 5:37 AM, Andrew Jeffery <andrew@aj.id.au> wrote:
> >
> > > GPIO state reset tolerance is implemented in gpiolib through the
> > > addition of a new pinconf parameter. With that, some renaming of helpers
> > > is done to clarify the scope of the already existing
> > > gpiochip_line_is_persistent(), as it's now ambiguous as to whether that
> > > means on suspend, reset or both.
> >
> > Isn't it most reasonable to say persistance covers both cases, reset
> > and/or sleep? This seems a bit like overdefined.
>
> I should also add: right now persistance is defined in negative terms,
> you can supply the flag "may lose value", which means the subsystem
> by default, and driver by default, will try to keep values persistent across
> sleep.
>
> Then it is possible to opt in for not doing so. (Usually to save power I
> think.)
>
> I think that especially for userspace use cases, saving power should
> not really be the concern, but correct me if I'm wrong. I am thinking
> of a box with a DC plug wired up to a factory line here.
>
> What we have in the Arizona driver is an opt-in where the DT can
> say "don't preserve the value this line during system sleep" i.e. "lay lose
> value" and we can extend that flag to mean "don't preserve this line
> during reset either" but by default assume that we should.
Yeah, the preserve polarity was another thing I debated given the
current example with the Arizona driver. Not preserving is the default
for the Aspeed hardware, so that ended up influencing my choice. Not
that implementation details should necessarily influence interface
design, but it was at least more than a coin toss.
I don't have anything specific against preserving by default, just my
gut instinct and the hardware went the other way. As long as we expose
the option to opt out, which the additions for the Arizona already do.
Cheers,
Andrew
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
next prev parent reply other threads:[~2017-10-20 8:32 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-20 3:37 [RFC PATCH 0/5] gpio: Expose reset tolerance capability Andrew Jeffery
2017-10-20 3:37 ` [RFC PATCH 1/5] gpio: gpiolib: Add core support for maintaining GPIO values on reset Andrew Jeffery
2017-10-20 7:17 ` Linus Walleij
2017-10-20 7:43 ` Linus Walleij
2017-10-20 8:32 ` Andrew Jeffery [this message]
2017-10-25 8:11 ` Charles Keepax
2017-10-26 0:00 ` Andrew Jeffery
2017-10-20 8:24 ` Andrew Jeffery
2017-10-20 3:37 ` [RFC PATCH 2/5] gpio: gpiolib: Add OF " Andrew Jeffery
[not found] ` <20171020033727.21557-3-andrew-zrmu5oMJ5Fs@public.gmane.org>
2017-10-20 7:18 ` Linus Walleij
2017-10-20 7:29 ` Andrew Jeffery
2017-10-20 3:37 ` [RFC PATCH 3/5] gpio: gpiolib: Add chardev " Andrew Jeffery
2017-10-20 7:27 ` Linus Walleij
2017-10-20 9:02 ` Andrew Jeffery
2017-10-25 8:14 ` Charles Keepax
2017-10-26 0:05 ` Andrew Jeffery
[not found] ` <1508976339.13477.5.camel-zrmu5oMJ5Fs@public.gmane.org>
2017-10-26 9:10 ` Charles Keepax
2017-10-31 9:59 ` Linus Walleij
2017-10-20 3:37 ` [RFC PATCH 4/5] gpio: gpiolib: Add sysfs " Andrew Jeffery
[not found] ` <20171020033727.21557-5-andrew-zrmu5oMJ5Fs@public.gmane.org>
2017-10-20 7:29 ` Linus Walleij
2017-10-20 7:40 ` Andrew Jeffery
2017-10-20 3:37 ` [RFC PATCH 5/5] gpio: aspeed: Add support for reset tolerance Andrew Jeffery
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=1508488347.24322.51.camel@aj.id.au \
--to=andrew@aj.id.au \
--cc=bgolaszewski@baylibre.com \
--cc=ckeepax@opensource.wolfsonmicro.com \
--cc=corbet@lwn.net \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=joel@jms.id.au \
--cc=ldewangan@nvidia.com \
--cc=linus.walleij@linaro.org \
--cc=linux-aspeed@lists.ozlabs.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mwelling@emacinc.com \
--cc=openbmc@lists.ozlabs.org \
--cc=patches@opensource.cirrus.com \
--cc=robh+dt@kernel.org \
--cc=ryan_chen@aspeedtech.com \
/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).