Received: by 10.223.185.116 with SMTP id b49csp4007855wrg; Mon, 19 Feb 2018 09:26:36 -0800 (PST) X-Google-Smtp-Source: AH8x227OuotyM0FRy13tzkVNcriqIaQOSSFbgKoGVPELX04gCEfaTQjSGTfBjX2d4jjtRE4VqRb7 X-Received: by 2002:a17:902:74c3:: with SMTP id f3-v6mr14928436plt.444.1519061196082; Mon, 19 Feb 2018 09:26:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519061196; cv=none; d=google.com; s=arc-20160816; b=c7V0IIpI/qATwi+2Y7JcPzjYyL9LltFKrQaLe2rGPmUvyl6SFvV1SPU2X/A4UleGM6 ouoAsKwUAoFnaj/bC1Wje+PxZSdPOw2JUmZqsofKM4APoq1v2CeSTmigz1vWOSkx8so9 BCoZHSOeLo7u75OZ964S3UAbozg/QFr8Lpapa3ZOj7T5Iu4TUNb1n14IVfZKYLMOtXqj qEeBPSL7mZhVtBDe4aJILWkCx2d4PSkFc4QcEsnps5IBjq9a6XDVSOLc1VZeXdf4iztc AFbiURjgdsGBqOj4OTMSoiA9XJVS7fRsR46uoI5fG4bFjjTF7ePq0CSDP0RxTcyacC0l TuRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:references :in-reply-to:organization:cc:from:date:content-transfer-encoding :mime-version:subject:to:arc-authentication-results; bh=brm+vkmb/7srjS39wlmOxGDOVbob/RTfYVOjjMcZ++8=; b=hQQpam5ePYFN+MBdhq3tHXt4n9gpFVmJ5oIJedkuNLuNe9G0aVlvAtKnmwC2yBUWb3 0kzVVJk9QP5y7g7pKZValD8kyAyIXZn+95pyun4PwAxeh37lHXfQiNM4HzOZHiWoNRcU ohjIaxoLE0INiys3isibliEj0Jn/VDX3DoLVOSc+Gkpe51DeoBMRWGDxhorNbvM1x/23 wu7dyKDAvPEq9dSXC403FyMQ2URJn/ViqxNf2HLtx1p0YUBy3vBL5XhQz2SEp6N+gaMi HLDcjsQOyrNxt+ioZpFN3yVLhrsZ9DiQmEMghTyD9RX4VOZX3MiCeFfW8LkrgWyMynJN 4Zyw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e3si5111637pgr.135.2018.02.19.09.26.20; Mon, 19 Feb 2018 09:26:36 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753295AbeBSRZb (ORCPT + 99 others); Mon, 19 Feb 2018 12:25:31 -0500 Received: from inca-roads.misterjones.org ([213.251.177.50]:32839 "EHLO inca-roads.misterjones.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753152AbeBSRZ3 (ORCPT ); Mon, 19 Feb 2018 12:25:29 -0500 Received: from www-data by cheepnis.misterjones.org with local (Exim 4.80) (envelope-from ) id 1enpBu-00089z-HZ; Mon, 19 Feb 2018 18:25:26 +0100 To: Florian Fainelli Subject: Re: [PATCH fixes v3] pinctrl: Really force states during suspend/resume X-PHP-Originating-Script: 0:main.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 19 Feb 2018 17:25:26 +0000 From: Marc Zyngier Cc: , , , , , , Heiko Stuebner Organization: Metropolis In-Reply-To: <20170301183257.6554-1-f.fainelli@gmail.com> References: <20170301183257.6554-1-f.fainelli@gmail.com> Message-ID: <83d6bd0da9254d868d3f713bd3bc282c@www.loen.fr> X-Sender: maz@misterjones.org User-Agent: Roundcube Webmail/0.7.2 X-SA-Exim-Connect-IP: X-SA-Exim-Rcpt-To: f.fainelli@gmail.com, linux-kernel@vger.kernel.org, linus.walleij@linaro.org, swarren@nvidia.com, andy.shevchenko@gmail.com, alcooperx@gmail.com, linux-gpio@vger.kernel.org, heiko@sntech.de X-SA-Exim-Mail-From: maz@misterjones.org X-SA-Exim-Scanned: No (on cheepnis.misterjones.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi all, On 2017-03-01 18:32, Florian Fainelli wrote: > In case a platform only defaults a "default" set of pins, but not a > "sleep" set of pins, and this particular platform suspends and > resumes > in a way that the pin states are not preserved by the hardware, when > we > resume, we would call pinctrl_single_resume() -> > pinctrl_force_default() > -> pinctrl_select_state() and the first thing we do is check that the > pins state is the same as before, and do nothing. > > In order to fix this, decouple the actual state change from > pinctrl_select_state() and move it pinctrl_commit_state(), while > keeping > the p->state == state check in pinctrl_select_state() not to change > the > caller assumptions. pinctrl_force_sleep() and pinctrl_force_default() > are updated to bypass the state check by calling > pinctrl_commit_state(). > > Fixes: 6e5e959dde0d ("pinctrl: API changes to support multiple states > per device") > Signed-off-by: Florian Fainelli > --- > Changes in v3: > > - move the state check to pinctrl_select_state > > Changes in v2: > > - rename __pinctrl_select_state to pinctrl_commit_state > > drivers/pinctrl/core.c | 24 +++++++++++++++++------- > 1 file changed, 17 insertions(+), 7 deletions(-) > > diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c > index fb38e208f32d..735d8f7f9d71 100644 > --- a/drivers/pinctrl/core.c > +++ b/drivers/pinctrl/core.c > @@ -992,19 +992,16 @@ struct pinctrl_state > *pinctrl_lookup_state(struct pinctrl *p, > EXPORT_SYMBOL_GPL(pinctrl_lookup_state); > > /** > - * pinctrl_select_state() - select/activate/program a pinctrl state > to HW > + * pinctrl_commit_state() - select/activate/program a pinctrl state > to HW > * @p: the pinctrl handle for the device that requests configuration > * @state: the state handle to select/activate/program > */ > -int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state > *state) > +static int pinctrl_commit_state(struct pinctrl *p, struct > pinctrl_state *state) > { > struct pinctrl_setting *setting, *setting2; > struct pinctrl_state *old_state = p->state; > int ret; > > - if (p->state == state) > - return 0; > - > if (p->state) { > /* > * For each pinmux setting in the old state, forget SW's record > @@ -1068,6 +1065,19 @@ int pinctrl_select_state(struct pinctrl *p, > struct pinctrl_state *state) > > return ret; > } > + > +/** > + * pinctrl_select_state() - select/activate/program a pinctrl state > to HW > + * @p: the pinctrl handle for the device that requests configuration > + * @state: the state handle to select/activate/program > + */ > +int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state > *state) > +{ > + if (p->state == state) > + return 0; > + > + return pinctrl_commit_state(p, state); > +} > EXPORT_SYMBOL_GPL(pinctrl_select_state); > > static void devm_pinctrl_release(struct device *dev, void *res) > @@ -1236,7 +1246,7 @@ void pinctrl_unregister_map(struct pinctrl_map > const *map) > int pinctrl_force_sleep(struct pinctrl_dev *pctldev) > { > if (!IS_ERR(pctldev->p) && !IS_ERR(pctldev->hog_sleep)) > - return pinctrl_select_state(pctldev->p, pctldev->hog_sleep); > + return pinctrl_commit_state(pctldev->p, pctldev->hog_sleep); > return 0; > } > EXPORT_SYMBOL_GPL(pinctrl_force_sleep); > @@ -1248,7 +1258,7 @@ EXPORT_SYMBOL_GPL(pinctrl_force_sleep); > int pinctrl_force_default(struct pinctrl_dev *pctldev) > { > if (!IS_ERR(pctldev->p) && !IS_ERR(pctldev->hog_default)) > - return pinctrl_select_state(pctldev->p, pctldev->hog_default); > + return pinctrl_commit_state(pctldev->p, pctldev->hog_default); > return 0; > } > EXPORT_SYMBOL_GPL(pinctrl_force_default); I don't often go back over a year worth of LKML, but since this patch recently landed in mainline as 981ed1bfbc6c, I though I'd use it as an anchor to report the following: It turns out that this patch completely breaks resume on my rk3399-based Chromebook. Most things are timing out, the box is unusable. And since this is my everyday tool, I'm mildly grumpy. Please don't break my toys! ;-) Reverting this patch on top of 4.16-rc2 makes me productive again... More seriously, I have no idea what's wrong here. It could be a SoC-related issue, hence Heiko on Cc. I'm happy to test any idea you could have. Thanks, M. -- Who you jivin' with that Cosmik Debris?