linux-kernel - Re: [PATCH] regulator: core: Fix enable GPIO reference counting

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 02 Mar 2015 21:21:45 +0100
From:	Javier Martinez Canillas <javier.martinez@...labora.co.uk>
To:	Mark Brown <broonie@...nel.org>
CC:	Doug Anderson <dianders@...omium.org>, milo.kim@...com,
	axel.lin@...ics.com, Dmitry Torokhov <dmitry.torokhov@...il.com>,
	olof@...om.net, Paul Stewart <pstew@...omium.org>,
	stable@...r.kernel.org, lgirdwood@...il.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] regulator: core: Fix enable GPIO reference counting

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/