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-next>] [day] [month] [year] [list]
Date:	Fri, 11 Sep 2015 17:31:57 +0530
From:	Viresh Kumar <viresh.kumar@...aro.org>
To:	Rafael Wysocki <rjw@...ysocki.net>, nm@...com, sboyd@...eaurora.org
Cc:	linaro-kernel@...ts.linaro.org, linux-pm@...r.kernel.org,
	rob.herring@...aro.org, lee.jones@...aro.org,
	Viresh Kumar <viresh.kumar@...aro.org>,
	Mark Brown <broonie@...nel.org>, devicetree@...r.kernel.org,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	linux-kernel@...r.kernel.org (open list),
	Mark Rutland <mark.rutland@....com>,
	Pawel Moll <pawel.moll@....com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	Rob Herring <robh+dt@...nel.org>
Subject: [PATCH 01/16] PM / OPP: Add 'supply-names' binding

Regulators already have stable DT bindings, wherein the consumer (of
supplies) will have following for each regulator/supply.

<name>-supply: <phandle to the regulator node>;

Current OPP bindings extend above, by transforming it into a list of
phandles. But we missed the <name> string, which is used to identify the
regulator.

And looking from regulators perspective, having two different ways of
specifying regulators doesn't seem like a step forward, it also means we
have to update every single device binding. And things will become
complex.

Another way to support multiple regulators per device (in OPP V2
bindings) is to leave regulator consumer bindings as is, and create a
'supply-names' property in the opp-table node, which will contain a list
of strings. The names in this list shall match 'name' from the
'<name>-supply' strings present in the device node.

The strings in this list also specify the order in which values must be
present in 'opp-microvolt' and 'opp-microamp' properties.

Cc: Mark Brown <broonie@...nel.org>
Cc: devicetree@...r.kernel.org
Signed-off-by: Viresh Kumar <viresh.kumar@...aro.org>
---
 Documentation/devicetree/bindings/opp/opp.txt | 26 +++++++++++++++++++-------
 1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
index 0cb44dc21f97..8759bc4783ed 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -69,6 +69,13 @@ This describes the OPPs belonging to a device. This node can have following
 - compatible: Allow OPPs to express their compatibility. It should be:
   "operating-points-v2".
 
+- supply-names: This is a required property, only if multiple supplies are
+  available for the device. Otherwise it is optional.
+
+  This list is used to pass names of all the device supplies. The order of names
+  present here is important, as that should match the order in which values are
+  present in 'opp-microvolt' and 'opp-microamp' properties.
+
 - OPP nodes: One or more OPP nodes describing voltage-current-frequency
   combinations. Their name isn't significant but their phandle can be used to
   reference an OPP.
@@ -97,8 +104,8 @@ properties.
   Single entry is for target voltage and three entries are for <target min max>
   voltages.
 
-  Entries for multiple regulators must be present in the same order as
-  regulators are specified in device's DT node.
+  Entries for multiple regulators must be present in the same order as their
+  names are present in 'supply-names' property of the opp-table.
 
 - opp-microamp: The maximum current drawn by the device in microamperes
   considering system specific parameters (such as transients, process, aging,
@@ -107,10 +114,12 @@ properties.
 
   Should only be set if opp-microvolt is set for the OPP.
 
-  Entries for multiple regulators must be present in the same order as
-  regulators are specified in device's DT node. If this property isn't required
-  for few regulators, then this should be marked as zero for them. If it isn't
-  required for any regulator, then this property need not be present.
+  Entries for multiple regulators must be present in the same order as their
+  names are present in 'supply-names' property of the opp-table.
+
+  If this property isn't required for few regulators, then this should be marked
+  as zero for them. If it isn't required for any regulator, then this property
+  need not be present.
 
 - clock-latency-ns: Specifies the maximum possible transition latency (in
   nanoseconds) for switching to this OPP from any other OPP.
@@ -369,13 +378,16 @@ Example 4: Handling multiple regulators
 			compatible = "arm,cortex-a7";
 			...
 
-			cpu-supply = <&cpu_supply0>, <&cpu_supply1>, <&cpu_supply2>;
+			vcc0-supply = <&cpu_supply0>;
+			vcc1-supply = <&cpu_supply1>;
+			vcc2-supply = <&cpu_supply2>;
 			operating-points-v2 = <&cpu0_opp_table>;
 		};
 	};
 
 	cpu0_opp_table: opp_table0 {
 		compatible = "operating-points-v2";
+		supply-names = "vcc0", "vcc1", "vcc2";
 		opp-shared;
 
 		opp00 {
-- 
2.4.0

--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ