devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Charles Keepax <ckeepax@opensource.cirrus.com>
To: Andrew Jeffery <andrew@aj.id.au>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	Michael Welling <mwelling@emacinc.com>,
	"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 3/5] gpio: gpiolib: Add chardev support for maintaining GPIO values on reset
Date: Wed, 25 Oct 2017 09:14:54 +0100	[thread overview]
Message-ID: <20171025081454.4avrf57mf33khu7c@localhost.localdomain> (raw)
In-Reply-To: <1508490173.24322.53.camel@aj.id.au>

On Fri, Oct 20, 2017 at 07:32:53PM +1030, Andrew Jeffery wrote:
> On Fri, 2017-10-20 at 09:27 +0200, Linus Walleij wrote:
> > I don't see it as helpful to give userspace control over whether the line
> > is persistent or not. It is more reasonable to assume persistance for
> > userspace use cases, don't you think? Whether the system goes to sleep
> > or the gpiochip resets should not make a door suddenly close or the
> > lights in the christmas tree go out, right? I think if the gpiochip supports
> > persistance of any kind, we should try to use it and not have userspace
> > provide flags for that.
> 
> Right. I guess the counter argument to your examples is if the gpio is
> controlling any active process that we don't want to continue if we've
> lost the capacity to monitor some other inputs (some kind of dead-man's 
> switch). But maybe the argument is that should be implemented in the
> kernel anyway?
> 

To me it certainly feels like decisions like this should live in
the kernel, your talking about things that could cause very weird
hardware behaviour if set wrong, so it makes sense to me to have
that responsibility guarded in the kernel.

Thanks,
Charles

  reply	other threads:[~2017-10-25  8:14 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
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 [this message]
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=20171025081454.4avrf57mf33khu7c@localhost.localdomain \
    --to=ckeepax@opensource.cirrus.com \
    --cc=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).