linux-kernel - Re: [PATCH 3/5] regulator: dt-bindings: Add regulator-initial-mode support

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 for Android: free password hash cracker in your pocket

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

Message-ID: <54355FAF.6060708@collabora.co.uk>
Date:	Wed, 08 Oct 2014 18:00:47 +0200
From:	Javier Martinez Canillas <javier.martinez@...labora.co.uk>
To:	Mark Brown <broonie@...nel.org>
CC:	Doug Anderson <dianders@...omium.org>,
	Chanwoo Choi <cw00.choi@...sung.com>,
	Olof Johansson <olof@...om.net>,
	Chris Zhong <zyw@...k-chips.com>,
	Krzysztof Kozlowski <k.kozlowski@...sung.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 10/08/2014 04:34 PM, Mark Brown wrote:
> On Wed, Oct 08, 2014 at 03:44:05PM +0200, Javier Martinez Canillas wrote:
> 
>> +- 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.
> 
> ...and as previously and repeatedly discussed this still gives the user
> no way of telling if or how these modes might correspond to what the
> chip is capable of doing.  This really needs addressing rather than
> ignoring, for example by not trying to define the modes in generic
> bindings.
> 

Drivers could add custom per-device DT properties. That is how it was
solved in the ChromeOS kernel. There is a regulator-op-mode DT property
whose value is just a magic number with the value that has to be written
in the OPMODE field of the control register of each regulator and that
is made on the driver probe.

Another option is to not document the standard modes in the generic
regulator binding but instead on each device DT binding doc. That way
each device binding can define what are the semantics of the standard
modes and how correspond to the real modes in the chip.

That way the regulator-initial-mode could still be generic and parsed
by the core instead of each driver implementing their own custom parsing.

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/