From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752524AbdJTIcr (ORCPT ); Fri, 20 Oct 2017 04:32:47 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:52013 "EHLO out4-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752202AbdJTIch (ORCPT ); Fri, 20 Oct 2017 04:32:37 -0400 X-ME-Sender: Message-ID: <1508488347.24322.51.camel@aj.id.au> Subject: Re: [RFC PATCH 1/5] gpio: gpiolib: Add core support for maintaining GPIO values on reset From: Andrew Jeffery To: Linus Walleij , Bartosz Golaszewski , Michael Welling Cc: "linux-gpio@vger.kernel.org" , Jonathan Corbet , Joel Stanley , Ryan Chen , Rob Herring , Frank Rowand , Charles Keepax , Laxman Dewangan , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , patches@opensource.cirrus.com, "devicetree@vger.kernel.org" , OpenBMC Maillist , linux-aspeed@lists.ozlabs.org Date: Fri, 20 Oct 2017 19:02:27 +1030 In-Reply-To: References: <20171020033727.21557-1-andrew@aj.id.au> <20171020033727.21557-2-andrew@aj.id.au> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-ZSkrhS+dG0skM+wwegTq" X-Mailer: Evolution 3.22.6-1ubuntu1 Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-ZSkrhS+dG0skM+wwegTq Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2017-10-20 at 09:43 +0200, Linus Walleij wrote: > On Fri, Oct 20, 2017 at 9:17 AM, Linus Walleij = wrote: > > > > On Fri, Oct 20, 2017 at 5:37 AM, Andrew Jeffery w= rote: > >=20 > > > GPIO state reset tolerance is implemented in gpiolib through the > > > addition of a new pinconf parameter. With that, some renaming of help= ers > > > is done to clarify the scope of the already existing > > > gpiochip_line_is_persistent(), as it's now ambiguous as to whether th= at > > > means on suspend, reset or both. > >=20 > > Isn't it most reasonable to say persistance covers both cases, reset > > and/or sleep? This seems a bit like overdefined. >=20 > 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 acr= oss > sleep. >=20 > Then it is possible to opt in for not doing so. (Usually to save power I > think.) >=20 > 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. >=20 > What we have in the Arizona driver is an opt-in where the DT can > say "don't preserve the value=C2=A0=C2=A0this 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 --=-ZSkrhS+dG0skM+wwegTq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQIcBAABCgAGBQJZ6bSbAAoJEJ0dnzgO5LT5UUEP/RfdSznqJGJ+zlAtZ58qjsct qRHU+r+//EDTqrv6ukCG5cY1R7invTIfP4e0+ajMz7hJ9DUhifWsc2L5efUkIMpR mctcseROL77TI0uGtpPuW5G9xxCmxYpbE/woOtNdtQlGLgIQ+DawO+W8zvWBhsut EjhVAEfQyvrK5q7b5D45OkH2J9ejO/k0GxpNZs66FGxgC41O6AGj4ZfUBSgBdyqm HNjH9uLyfs4JR9bXptsdGTTCJAxog02UWLmROpGfiwz0ZwN6cdnJSl4dcu1Swn8D 4o+UPAg4j1bqHiV7dWIitJEM+cn9c0Ybpt1VPS1/WF6aGggubws89e9MnrNimrVS k7qS3A7WRQJ3MPlBAwNLwfjPa+eBDBw5t8wZSDXSvXp37+mwHDgQotA9jZAR4Jqj BdUAxHAy5yBIgopwo+G0XdHt/izkGGnoZBDToNBO67kD8Ct1lEDAjHn0ljal1k3l heRjmkN2PiJ55d9QjF7qe/GbT6DZST5QiC1lOdSlg5f9G9Gm4KiyfSmkxneKYHTF aERByeN/doqdYPtQ7LxlpBgN7bql9UBCn2I8PZimU1+zZu75no1F5eH8IFOV7vpJ JWbHgg7JspuZY98pQMoFV6ASbJmTiQiWYMimm4ybXSb4Btdhgx0EJDOGaBi0r9ls BzTFqMLL678jOVu0EkNA =4duz -----END PGP SIGNATURE----- --=-ZSkrhS+dG0skM+wwegTq--