From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754135AbbCBUVx (ORCPT ); Mon, 2 Mar 2015 15:21:53 -0500 Received: from bhuna.collabora.co.uk ([93.93.135.160]:33659 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751556AbbCBUVw (ORCPT ); Mon, 2 Mar 2015 15:21:52 -0500 Message-ID: <54F4C659.2080404@collabora.co.uk> Date: Mon, 02 Mar 2015 21:21:45 +0100 From: Javier Martinez Canillas User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.2.0 MIME-Version: 1.0 To: Mark Brown CC: Doug Anderson , milo.kim@ti.com, axel.lin@ingics.com, Dmitry Torokhov , olof@lixom.net, Paul Stewart , stable@vger.kernel.org, lgirdwood@gmail.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] regulator: core: Fix enable GPIO reference counting References: <1425066064-18920-1-git-send-email-dianders@chromium.org> <54F0DB23.3010203@collabora.co.uk> <20150302185713.GF21293@sirena.org.uk> In-Reply-To: <20150302185713.GF21293@sirena.org.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Mark, On 03/02/2015 07:57 PM, Mark Brown wrote: > On Fri, Feb 27, 2015 at 10:01:23PM +0100, Javier Martinez Canillas wrote: > >> I noticed the same problem in regulator_suspend_finish() when I was working >> on S2R for Exynos a couple of months ago and had patch [0] on my local tree >> but never found the time to do extensive testing so I never posted it. > > Please don't bury patches in the middle of mails where they're hard to > apply if they're useful. > Sorry, if my intention was you to apply the patch then I would had posted it properly. But what I wanted was to share that I had the same issue and my approach to see if that also fixed Doug's issue. Otherwise is hard to maintain a conversation across different threads. >> I see that the check is already in _regulator_enable() so another option >> is to call _regulator_enable() instead of _regulator_do_enable() in >> regulator_suspend_finish(). > > I'm not entirely sure what "the check" is? > The check I was referring to is _regulator_is_enabled() but now looking again I see that _regulator_enable() can't be used in regulator_suspend_finish() because that will increment the reference counting which is wrong. >> Trying to enable an already enabled regulator may cause issues so is >> better to skip enabling regulators that were not disabled before suspend. > >> mutex_lock(&rdev->mutex); >> if (rdev->use_count > 0 || rdev->constraints->always_on) { >> - error = _regulator_do_enable(rdev); >> - if (error) >> - ret = error; >> + if (!_regulator_is_enabled(rdev)) { >> + error = _regulator_do_enable(rdev); >> + if (error) >> + ret = error; >> + } > > This seems like a better fix or at least a better approach - essentially > the assumption in most of the code is that regulator enables are just > register writes so repeated updates don't have any effect. We may need Which doesn't seem to be the case for all regulators since at least I got failures when a FET in the tps65090 pmu was tried to be enabled twice. > a specific per client count here... I've not looked at the code and I Sorry, I'm not sure I understood what you meant. The suspend path: suspend_prepare() -> suspend_set_state() -> .set_suspend_* doesn't decrement use_count so is correct to call _regulator_do_enable() directly. The problem is the assumption that all regulators were either disabled on suspend or that enabling an enabled regulator is a no-op. I'll post as a proper patch so you can review it. Best regards, Javier