linux-kernel - Re: [PATCHv3 2/2] dt-bindings: regulator: Add regulator suspend state for PM state

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 PHC
Open Source and information security mailing list archives

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

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

Date:	Fri, 15 Aug 2014 21:15:58 +0900
From:	Chanwoo Choi <cwchoi00@...il.com>
To:	Mark Brown <broonie@...nel.org>
Cc:	Chanwoo Choi <cw00.choi@...sung.com>,
	Liam Girdwood <lgirdwood@...il.com>,
	Grant Likely <grant.likely@...aro.org>,
	Rob Herring <robh+dt@...nel.org>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	Krzysztof Kozłowski <k.kozlowski@...sung.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	devicetree <devicetree@...r.kernel.org>
Subject: Re: [PATCHv3 2/2] dt-bindings: regulator: Add regulator suspend state
 for PM state

Dear Mark,

On Fri, Aug 15, 2014 at 7:56 PM, Mark Brown <broonie@...nel.org> wrote:
> On Thu, Aug 14, 2014 at 09:40:14AM +0900, Chanwoo Choi wrote:
>
>> +- regulator-initial-state: initial state for suspend state, cnd set initial
>> +  state among following defined suspend states:
>> +  <2>: PM_SUSPEND_STANDBY - Setup regulator according to regulator-state-standby
>> +  <3>: PM_SUSPEND_MEM - Setup regulator according to regulator-state-mem
>> +  <4>: PM_SUSPEND_MAX - Setup regulator according to regulator-state-disk
>> +- regulator-state-standby sub-root node for Standby mode
>> +  : the device is in a power-saving state, but can also receive certain events,
>> +  specific behavior depends on the specific device.
>
> These are all Linux internal descriptions of the states but the device
> tree is supposed to be OS neutral.  For suspend to memory and suspend to
> disk that's probably adequately clear but _STANDBY is really unclear.
> I would suggest just dropping this without a clearer defintion, it's
> something that I'd expect to emerge organically from low power modes
> rather than having a specific definition anyway.

OK, I'll drop PM_SUSPEND_STANDBY mode on next patchset.

>
>> +- regulator-state-[standby/mem/disk] node has following common properties:
>> +     - regulator-volt: voltage consumers may set in suspend state.
>> +     - regulator-mode: voltage mode in suspend state, can set mode among
>> +     following defined regulator modes:
>> +     0x1: REGULATOR_MODE_FAST, Regulator can handle fast changes.
>> +     0x2: REGULATOR_MODE_NORMAL, Normal regulator power supply mode.
>> +     0x4: REGULATOR_MODE_IDLE, Regulator runs in a more efficient mode.
>> +     0x8: REGULATOR_MODE_STANDBY, Regulator runs in the most efficient mode.
>> +     - regulator-on-in-suspend: regulator should be on in suspend state.
>> +     - regulator-off-in-suspend: regulator should be off in suspend state.
>> +     If node don't include regulator-[on/off]-in-suspend, can't change
>> +     regulator state in suspend mode and only should sustain the regulator
>> +     state of normal state.
>
> Modes are a similarly problematic thing - their definition is really
> unclear even within Linux and we don't support them at all at present.
> I'd just drop them initially and then add them in as a part of adding
> mode support in general.

OK, I'll drop 'regulator-mode' property on next patchset.

Thanks for your review.

Best Regards,
Chanwoo Choi
--
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/