linux-kernel - Re: [PATCH 2/3] regulator: s2mps11: Add set_suspend

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:	Thu, 06 Mar 2014 15:42:22 +0100
From:	Krzysztof Kozlowski <k.kozlowski@...sung.com>
To:	Mark Brown <broonie@...nel.org>
Cc:	Sangbeom Kim <sbkim73@...sung.com>,
	Liam Girdwood <lgirdwood@...il.com>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	Lee Jones <lee.jones@...aro.org>, linux-kernel@...r.kernel.org,
	linux-samsung-soc@...r.kernel.org,
	Kyungmin Park <kyungmin.park@...sung.com>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
	Tomasz Figa <t.figa@...sung.com>,
	Yadwinder Singh Brar <yadi.brar@...sung.com>,
	Sachin Kamat <sachin.kamat@...aro.org>
Subject: Re: [PATCH 2/3] regulator: s2mps11: Add set_suspend_disable for S2MPS14

On Thu, 2014-03-06 at 17:38 +0800, Mark Brown wrote:
> On Wed, Mar 05, 2014 at 10:22:52AM +0100, Krzysztof Kozlowski wrote:
> 
> > +	ret = regmap_read(rdev->regmap, rdev->desc->enable_reg, &data);
> > +	if (ret < 0)
> > +		return ret;
> > +
> > +	/*
> > +	 * Don't enable suspend mode if regulator is already disabled because
> > +	 * this would effectively for a short time turn on the regulator after
> > +	 * resuming.
> > +	 */
> > +	if (!(data & rdev->desc->enable_mask))
> > +		return 0;
> > +
> > +	return regmap_update_bits(rdev->regmap, rdev->desc->enable_reg,
> > +			rdev->desc->enable_mask, S2MPS14_ENABLE_SUSPEND);
> > +}
> 
> What happens if the regulator gets enabled between this being called
> and the device suspending?  I'd expect this to be storing the state and
> then changing what gets written during enable and disable operations (if
> the hardware does what I think it does).

It seems that none of the regulators implementing set_suspend_disable()
work that way. They just write the suspend value to device. Of course
this is not an issue - the S2MPS14 may be the first :).

However in that case the driver won't be able later to change that value
back to "normal enable" (enable_mask). Consider such flow:
1. System is going to suspend.
2. Some regulator has "rstate->disabled" so set_suspend_disable() is
called on it.
3. The "suspend" value is written to the device for given regulator and
it is stored as "enable" value.
4. If regulator is enabled during here then the same "suspend" value
will be written.
5. System is suspended.
6. After resuming regulator_suspend_finish() calls
_regulator_do_enable() on the regulator... which will write the
"suspend" value because the driver cannot differentiate between this
enable and previous.

I assume that this may not be a problem because:
1. Regulator will be still turned on (the "suspend" value tells PMIC to
enable the regulator when SoC enables power).
2. The first disable of regulator may bring back "enable" value back to
normal mode.

Am I thinking here correctly? 

Best regards,
Krzysztof

--
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/