linux-kernel - Re: [PATCH part2 5/6] regulator: max14577: Implement SUSPEND mode for MAX77836 LDO-s

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]

Message-ID: <20140501181908.GS3245@sirena.org.uk>
Date:	Thu, 1 May 2014 11:19:08 -0700
From:	Mark Brown <broonie@...nel.org>
To:	Krzysztof Kozlowski <k.kozlowski@...sung.com>
Cc:	Samuel Ortiz <sameo@...ux.intel.com>,
	Lee Jones <lee.jones@...aro.org>,
	Dmitry Eremin-Solenikov <dbaryshkov@...il.com>,
	David Woodhouse <dwmw2@...radead.org>,
	Liam Girdwood <lgirdwood@...il.com>,
	linux-kernel@...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>,
	Anton Vorontsov <anton@...msg.org>
Subject: Re: [PATCH part2 5/6] regulator: max14577: Implement SUSPEND mode
 for MAX77836 LDO-s

On Wed, Apr 23, 2014 at 04:50:39PM +0200, Krzysztof Kozlowski wrote:

> This patch adds support for mode REGULATOR_MODE_STANDBY (and NORMAL) to
> LDO regulators by implementing the set_mode() and get_mode() operations.
> However the necessary regulator constraints (valid modes) are not parsed
> by of_regulator_match() so the driver adds them manually to the
> regulator init_data.

No, that's not the idea here.  The reason that the modes need to be
explicitly enabled is that there's an element of board design in
determining if a given mode can satisfy the required current demand for
the board with sufficient quality (usually the lower power modes have
both a lower maximum current and poorer regulation accuracy especially
as the current rises).  Doing it unconditionally isn't in general
reliable.

The reason that the modes aren't supported by DT is that defining a
binding is hard - it's not clear what exactly a "mode" means since it's
basically a Linux internal thing.  We probably need to explicitly add
definitions of the modes to the bindings for individual devices
unfortunately (ie, saying "mode X maps to Y in the datasheet", possibly
using the datasheet modes in the binding for ease of use and having that
translation in the driver).

Ideally we'd be able to have the automatic mode setting working for
devices but in practice nobody wants to publish the numbers and working
out how much the board needs can also be hard so that isn't really
practical.

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)