linux-kernel - Re: [PATCH v3 06/12] power: pwrseq: simple: Add support for regulator and generic property

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: <575693DE.2010603@samsung.com>
Date:	Tue, 07 Jun 2016 11:29:02 +0200
From:	Krzysztof Kozlowski <k.kozlowski@...sung.com>
To:	Rob Herring <robh@...nel.org>
Cc:	hzpeterchen@...il.com, Ulf Hansson <ulf.hansson@...aro.org>,
	Sebastian Reichel <sre@...nel.org>,
	Dmitry Eremin-Solenikov <dbaryshkov@...il.com>,
	David Woodhouse <dwmw2@...radead.org>,
	Javier Martinez Canillas <javier@....samsung.com>,
	linux-kernel@...r.kernel.org, linux-mmc@...r.kernel.org,
	linux-pm@...r.kernel.or, Alan Stern <stern@...land.harvard.edu>,
	linux-usb@...r.kernel.org, Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Kukjin Kim <kgene@...nel.org>, devicetree@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	linux-samsung-soc@...r.kernel.org,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>
Subject: Re: [PATCH v3 06/12] power: pwrseq: simple: Add support for regulator
 and generic property

On 06/03/2016 04:02 AM, Rob Herring wrote:
>>  Optional properties:
>>  - reset-gpios : contains a list of GPIO specifiers. The reset GPIOs are asserted
>> @@ -16,6 +22,7 @@ Optional properties:
>>    See ../clocks/clock-bindings.txt for details.
>>  - clock-names : Must include the following entry:
>>    "ext_clock" (External clock provided to the card).
>> +- ext-supply : External regulator supply
> 
> What happens when there are 2 supplies?
> 
> I'd prefer the name not be genericish and use the real supply names. 
> Then the power seq code should just turn on all supplies it finds. If 
> the order or timing to turn on matters, then sorry, no generic sequence.

I think the generic part for regulators might be a problem. Regulator
API requires a name for the supply... it cannot get "something" or
"everything".

The driver could attach itself to any kind of node (where power-sequence
property exists) so the supply name depends on the bindings of device
(not bindings of power sequence driver).

The power sequence driver could however iterate over child properties
and get the names of all supplies. It is a little bit ugly...

Best regards,
Krzysztof