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, 09 Oct 2014 10:45:55 +0200
From:	Krzysztof Kozlowski <k.kozlowski@...sung.com>
To:	Javier Martinez Canillas <javier.martinez@...labora.co.uk>
Cc:	Mark Brown <broonie@...nel.org>,
	Doug Anderson <dianders@...omium.org>,
	Chanwoo Choi <cw00.choi@...sung.com>,
	Olof Johansson <olof@...om.net>,
	Chris Zhong <zyw@...k-chips.com>,
	Abhilash Kesavan <kesavan.abhilash@...il.com>,
	linux-samsung-soc@...r.kernel.org, linux-kernel@...r.kernel.org,
	devicetree@...r.kernel.org
Subject: Re: [PATCH 3/5] regulator: dt-bindings: Add regulator-initial-mode
 support

On śro, 2014-10-08 at 15:44 +0200, Javier Martinez Canillas wrote:
> Regulators can run on different operating modes (opmodes). This allows
> systems to choose the most efficient opmode for each regulator. The
> regulator core defines a set of generic modes so each system can define
> the opmode in these generic terms and drivers are responsible to map the
> generic modes to the ones supported by each hardware according to their
> data-sheet.
> 
> Signed-off-by: Javier Martinez Canillas <javier.martinez@...labora.co.uk>
> ---
>  Documentation/devicetree/bindings/regulator/regulator.txt | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt b/Documentation/devicetree/bindings/regulator/regulator.txt
> index ccba90b..a9d6767 100644
> --- a/Documentation/devicetree/bindings/regulator/regulator.txt
> +++ b/Documentation/devicetree/bindings/regulator/regulator.txt
> @@ -23,6 +23,14 @@ Optional properties:
>    state among following defined suspend states:
>    <3>: PM_SUSPEND_MEM - Setup regulator according to regulator-state-mem
>    <4>: PM_SUSPEND_MAX - Setup regulator according to regulator-state-disk
> +- regulator-initial-mode: initial regulator operating mode. One of following:
> +	<1>: REGULATOR_MODE_FAST    - Regulator can handle fast changes.
> +	<2>: REGULATOR_MODE_NORMAL  - Normal regulator power supply mode.
> +	<4>: REGULATOR_MODE_IDLE    - Regulator runs in a more efficient mode.
> +	<8>: REGULATOR_MODE_STANDBY - Regulator runs in the most efficient mode.
> +  modes are defined in the dt-bindings/regulator/regulator.h header and can be
> +  used in device tree sources files. If no mode is defined, then the OS will not
> +  manage the operating mode and the HW default values will be used instead.
>  - regulator-state-mem sub-root node for Suspend-to-RAM mode
>    : suspend to memory, the device goes to sleep, but all data stored in memory,
>    only some external interrupt can wake the device.

I agree with the need and the idea of generic bindings for operating
modes for regulators. At least for Exynos-based boards the PMICs have
quite similar opmodes.

However the regulator mode from consumer.h (and in above doc) does not
match well with these opmodes. Example is yours patch 4/5:
 - idle ("more efficient mode") maps to "low power mode in suspend",
 - standby ("the most efficient mode") maps to "OFF in suspend".

Actually we are not enable "efficient modes" but we configure how the
regulator will behave when AP says - I'm suspending.


Another issue: is "initial_state" not doing all this already?

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/

Powered by blists - more mailing lists