From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751810AbdJYIMR (ORCPT ); Wed, 25 Oct 2017 04:12:17 -0400 Received: from mx0a-001ae601.pphosted.com ([67.231.149.25]:54706 "EHLO mx0b-001ae601.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751529AbdJYIML (ORCPT ); Wed, 25 Oct 2017 04:12:11 -0400 Authentication-Results: ppops.net; spf=none smtp.mailfrom=ckeepax@opensource.cirrus.com Date: Wed, 25 Oct 2017 09:11:41 +0100 From: Charles Keepax To: Andrew Jeffery CC: Linus Walleij , Bartosz Golaszewski , Michael Welling , "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" , , "devicetree@vger.kernel.org" , OpenBMC Maillist , Subject: Re: [RFC PATCH 1/5] gpio: gpiolib: Add core support for maintaining GPIO values on reset Message-ID: <20171025081141.uczvbfstmt3jcisw@localhost.localdomain> References: <20171020033727.21557-1-andrew@aj.id.au> <20171020033727.21557-2-andrew@aj.id.au> <1508488347.24322.51.camel@aj.id.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1508488347.24322.51.camel@aj.id.au> User-Agent: NeoMutt/20170113 (1.7.2) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710250115 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 20, 2017 at 07:02:27PM +1030, Andrew Jeffery wrote: > 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 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. > > Seems reasonable to me to just expand the existing stuff to cover reset as well, I don't think that should cause any issues for the Arizona stuff. > > 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. > The way I think we ended up looking at this was when a user requests a GPIO the least surprising thing for them is the value maintains until they change it again. So it made sense to make the allowing the value to be dropped the opt in side. > 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 Thanks, Charles