Date   

[4.4.y-cip 15/15] cpufreq: cpufreq-dt: avoid uninitialized variable warnings:

Chen-Yu Tsai (Moxa) <wens@...>
 

From: Arnd Bergmann <arnd@arndb.de>

commit b331bc20d9281213f7fb67912638e0fb5baeb324 upstream.

gcc warns quite a bit about values returned from allocate_resources()
in cpufreq-dt.c:

cpufreq-dt.c: In function 'cpufreq_init':
cpufreq-dt.c:327:6: error: 'cpu_dev' may be used uninitialized in this fu=
nction [-Werror=3Dmaybe-uninitialized]
cpufreq-dt.c:197:17: note: 'cpu_dev' was declared here
cpufreq-dt.c:376:2: error: 'cpu_clk' may be used uninitialized in this fu=
nction [-Werror=3Dmaybe-uninitialized]
cpufreq-dt.c:199:14: note: 'cpu_clk' was declared here
cpufreq-dt.c: In function 'dt_cpufreq_probe':
cpufreq-dt.c:461:2: error: 'cpu_clk' may be used uninitialized in this fu=
nction [-Werror=3Dmaybe-uninitialized]
cpufreq-dt.c:447:14: note: 'cpu_clk' was declared here

The problem is that it's slightly hard for gcc to follow return
codes across PTR_ERR() calls.

This patch uses explicit assignments to the "ret" variable to make
it easier for gcc to verify that the code is actually correct,
without the need to add a bogus initialization.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Chen-Yu Tsai (Moxa) <wens@csie.org>
---
drivers/cpufreq/cpufreq-dt.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index 9bc37c437874a..0ca74d0700583 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -142,15 +142,16 @@ static int allocate_resources(int cpu, struct devic=
e **cdev,
=20
try_again:
cpu_reg =3D regulator_get_optional(cpu_dev, reg);
- if (IS_ERR(cpu_reg)) {
+ ret =3D PTR_ERR_OR_ZERO(cpu_reg);
+ if (ret) {
/*
* If cpu's regulator supply node is present, but regulator is
* not yet registered, we should try defering probe.
*/
- if (PTR_ERR(cpu_reg) =3D=3D -EPROBE_DEFER) {
+ if (ret =3D=3D -EPROBE_DEFER) {
dev_dbg(cpu_dev, "cpu%d regulator not ready, retry\n",
cpu);
- return -EPROBE_DEFER;
+ return ret;
}
=20
/* Try with "cpu-supply" */
@@ -159,18 +160,16 @@ try_again:
goto try_again;
}
=20
- dev_dbg(cpu_dev, "no regulator for cpu%d: %ld\n",
- cpu, PTR_ERR(cpu_reg));
+ dev_dbg(cpu_dev, "no regulator for cpu%d: %d\n", cpu, ret);
}
=20
cpu_clk =3D clk_get(cpu_dev, NULL);
- if (IS_ERR(cpu_clk)) {
+ ret =3D PTR_ERR_OR_ZERO(cpu_clk);
+ if (ret) {
/* put regulator */
if (!IS_ERR(cpu_reg))
regulator_put(cpu_reg);
=20
- ret =3D PTR_ERR(cpu_clk);
-
/*
* If cpu's clk node is present, but clock is not yet
* registered, we should try defering probe.
--=20
2.27.0.rc0


[4.4.y-cip 11/15] PM / OPP: Use snprintf() instead of sprintf()

Chen-Yu Tsai (Moxa) <wens@...>
 

From: Viresh Kumar <viresh.kumar@linaro.org>

commit 5ff24d601092b222340b28466e263b1c4559407e upstream.

sprintf() can access memory outside of the range of the character array,
and is risky in some situations. The driver specified prop_name string
can be longer than NAME_MAX here (only an attacker will do that though)
and so blindly copying it into the character array of size NAME_MAX
isn't safe. Instead we must use snprintf() here.

Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Chen-Yu Tsai (Moxa) <wens@csie.org>
---
drivers/base/power/opp/core.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.=
c
index 504a6d4e46723..1e0a2ddf73323 100644
--- a/drivers/base/power/opp/core.c
+++ b/drivers/base/power/opp/core.c
@@ -808,7 +808,8 @@ static int opp_parse_supplies(struct dev_pm_opp *opp,=
struct device *dev,
=20
/* Search for "opp-microvolt-<name>" */
if (dev_opp->prop_name) {
- sprintf(name, "opp-microvolt-%s", dev_opp->prop_name);
+ snprintf(name, sizeof(name), "opp-microvolt-%s",
+ dev_opp->prop_name);
prop =3D of_find_property(opp->np, name, NULL);
}
=20
@@ -855,7 +856,8 @@ static int opp_parse_supplies(struct dev_pm_opp *opp,=
struct device *dev,
/* Search for "opp-microamp-<name>" */
prop =3D NULL;
if (dev_opp->prop_name) {
- sprintf(name, "opp-microamp-%s", dev_opp->prop_name);
+ snprintf(name, sizeof(name), "opp-microamp-%s",
+ dev_opp->prop_name);
prop =3D of_find_property(opp->np, name, NULL);
}
=20
--=20
2.27.0.rc0


[4.4.y-cip 06/15] PM / OPP: Add missing doc comments

Chen-Yu Tsai (Moxa) <wens@...>
 

From: Viresh Kumar <viresh.kumar@linaro.org>

commit dc4e7b1fa20a840d2317fcfdaa1064fc09d2afcb upstream.

Few doc-style comments were missing, add them. Rearrange another one to
match the sequence within the structure.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Chen-Yu Tsai (Moxa) <wens@csie.org>
---
drivers/base/power/opp/opp.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/base/power/opp/opp.h b/drivers/base/power/opp/opp.h
index a6bd8d2c2b47f..b8880c7f8be1c 100644
--- a/drivers/base/power/opp/opp.h
+++ b/drivers/base/power/opp/opp.h
@@ -51,8 +51,8 @@ extern struct mutex dev_opp_list_lock;
* are protected by the dev_opp_list_lock for integrity.
* IMPORTANT: the opp nodes should be maintained in increasing
* order.
- * @dynamic: not-created from static DT entries.
* @available: true/false - marks if this OPP as available or not
+ * @dynamic: not-created from static DT entries.
* @turbo: true if turbo (boost) OPP
* @suspend: true if suspend OPP
* @rate: Frequency in hertz
@@ -126,7 +126,9 @@ struct device_list_opp {
* @dev_list: list of devices that share these OPPs
* @opp_list: list of opps
* @np: struct device_node pointer for opp's DT node.
+ * @clock_latency_ns_max: Max clock latency in nanoseconds.
* @shared_opp: OPP is shared between multiple devices.
+ * @suspend_opp: Pointer to OPP to be used during device suspend.
* @dentry: debugfs dentry pointer of the real device directory (not lin=
ks).
* @dentry_name: Name of the real dentry.
*
--=20
2.27.0.rc0


[4.4.y-cip 09/15] PM / OPP: Fix parsing of opp-microvolt and opp-microamp properties

Chen-Yu Tsai (Moxa) <wens@...>
 

From: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

commit fd8d8e63467c922be9ae4452cca2980d473477d9 upstream.

Commit 01fb4d3c39d3 ("PM / OPP: Parse 'opp-<prop>-<name>'
bindings") broke support for parsing standard opp-microvolt and
opp-microamp properties. Fix it by setting 'name' string to
proper value for !prop cases.

Fixes: 01fb4d3c39d3 ("PM / OPP: Parse 'opp-<prop>-<name> 'bindings")
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Chen-Yu Tsai (Moxa) <wens@csie.org>
---
drivers/base/power/opp/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.=
c
index 408fee4cb72df..504a6d4e46723 100644
--- a/drivers/base/power/opp/core.c
+++ b/drivers/base/power/opp/core.c
@@ -814,7 +814,7 @@ static int opp_parse_supplies(struct dev_pm_opp *opp,=
struct device *dev,
=20
if (!prop) {
/* Search for "opp-microvolt" */
- name[13] =3D '\0';
+ sprintf(name, "opp-microvolt");
prop =3D of_find_property(opp->np, name, NULL);
=20
/* Missing property isn't a problem, but an invalid entry is */
@@ -861,7 +861,7 @@ static int opp_parse_supplies(struct dev_pm_opp *opp,=
struct device *dev,
=20
if (!prop) {
/* Search for "opp-microamp" */
- name[12] =3D '\0';
+ sprintf(name, "opp-microamp");
prop =3D of_find_property(opp->np, name, NULL);
}
=20
--=20
2.27.0.rc0


[4.4.y-cip 05/15] PM / OPP: Rename OPP nodes as opp@<opp-hz>

Chen-Yu Tsai (Moxa) <wens@...>
 

From: Viresh Kumar <viresh.kumar@linaro.org>

commit 754dcf35f34698661801ae1d391efa02affe83a7 upstream.

It would be better to name OPP nodes as opp@<opp-hz> as that will ensure
that multiple DT nodes don't contain the same frequency. Of course we
expect the writer to name the node with its opp-hz frequency and not any
other frequency.

And that will let the compile error out if multiple nodes are using the
same opp-hz frequency.

Suggested-by: Stephen Boyd <sboyd@codeaurora.org>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Chen-Yu Tsai (Moxa) <wens@csie.org>
---
Documentation/devicetree/bindings/opp/opp.txt | 38 +++++++++----------
1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentatio=
n/devicetree/bindings/opp/opp.txt
index 24eac9a977494..601256fe8c0dd 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -177,20 +177,20 @@ Example 1: Single cluster Dual-core ARM cortex A9, =
switch DVFS states together.
compatible =3D "operating-points-v2";
opp-shared;
=20
- opp00 {
+ opp@1000000000 {
opp-hz =3D /bits/ 64 <1000000000>;
opp-microvolt =3D <970000 975000 985000>;
opp-microamp =3D <70000>;
clock-latency-ns =3D <300000>;
opp-suspend;
};
- opp01 {
+ opp@1100000000 {
opp-hz =3D /bits/ 64 <1100000000>;
opp-microvolt =3D <980000 1000000 1010000>;
opp-microamp =3D <80000>;
clock-latency-ns =3D <310000>;
};
- opp02 {
+ opp@1200000000 {
opp-hz =3D /bits/ 64 <1200000000>;
opp-microvolt =3D <1025000>;
clock-latency-ns =3D <290000>;
@@ -256,20 +256,20 @@ independently.
* independently.
*/
=20
- opp00 {
+ opp@1000000000 {
opp-hz =3D /bits/ 64 <1000000000>;
opp-microvolt =3D <970000 975000 985000>;
opp-microamp =3D <70000>;
clock-latency-ns =3D <300000>;
opp-suspend;
};
- opp01 {
+ opp@1100000000 {
opp-hz =3D /bits/ 64 <1100000000>;
opp-microvolt =3D <980000 1000000 1010000>;
opp-microamp =3D <80000>;
clock-latency-ns =3D <310000>;
};
- opp02 {
+ opp@1200000000 {
opp-hz =3D /bits/ 64 <1200000000>;
opp-microvolt =3D <1025000>;
opp-microamp =3D <90000;
@@ -332,20 +332,20 @@ DVFS state together.
compatible =3D "operating-points-v2";
opp-shared;
=20
- opp00 {
+ opp@1000000000 {
opp-hz =3D /bits/ 64 <1000000000>;
opp-microvolt =3D <970000 975000 985000>;
opp-microamp =3D <70000>;
clock-latency-ns =3D <300000>;
opp-suspend;
};
- opp01 {
+ opp@1100000000 {
opp-hz =3D /bits/ 64 <1100000000>;
opp-microvolt =3D <980000 1000000 1010000>;
opp-microamp =3D <80000>;
clock-latency-ns =3D <310000>;
};
- opp02 {
+ opp@1200000000 {
opp-hz =3D /bits/ 64 <1200000000>;
opp-microvolt =3D <1025000>;
opp-microamp =3D <90000>;
@@ -358,20 +358,20 @@ DVFS state together.
compatible =3D "operating-points-v2";
opp-shared;
=20
- opp10 {
+ opp@1300000000 {
opp-hz =3D /bits/ 64 <1300000000>;
opp-microvolt =3D <1045000 1050000 1055000>;
opp-microamp =3D <95000>;
clock-latency-ns =3D <400000>;
opp-suspend;
};
- opp11 {
+ opp@1400000000 {
opp-hz =3D /bits/ 64 <1400000000>;
opp-microvolt =3D <1075000>;
opp-microamp =3D <100000>;
clock-latency-ns =3D <400000>;
};
- opp12 {
+ opp@1500000000 {
opp-hz =3D /bits/ 64 <1500000000>;
opp-microvolt =3D <1010000 1100000 1110000>;
opp-microamp =3D <95000>;
@@ -398,7 +398,7 @@ Example 4: Handling multiple regulators
compatible =3D "operating-points-v2";
opp-shared;
=20
- opp00 {
+ opp@1000000000 {
opp-hz =3D /bits/ 64 <1000000000>;
opp-microvolt =3D <970000>, /* Supply 0 */
<960000>, /* Supply 1 */
@@ -411,7 +411,7 @@ Example 4: Handling multiple regulators
=20
/* OR */
=20
- opp00 {
+ opp@1000000000 {
opp-hz =3D /bits/ 64 <1000000000>;
opp-microvolt =3D <970000 975000 985000>, /* Supply 0 */
<960000 965000 975000>, /* Supply 1 */
@@ -424,7 +424,7 @@ Example 4: Handling multiple regulators
=20
/* OR */
=20
- opp00 {
+ opp@1000000000 {
opp-hz =3D /bits/ 64 <1000000000>;
opp-microvolt =3D <970000 975000 985000>, /* Supply 0 */
<960000 965000 975000>, /* Supply 1 */
@@ -456,7 +456,7 @@ Example 5: opp-supported-hw
status =3D "okay";
opp-shared;
=20
- opp00 {
+ opp@600000000 {
/*
* Supports all substrate and process versions for 0xF
* cuts, i.e. only first four cuts.
@@ -467,7 +467,7 @@ Example 5: opp-supported-hw
...
};
=20
- opp01 {
+ opp@800000000 {
/*
* Supports:
* - cuts: only one, 6th cut (represented by 6th bit).
@@ -499,7 +499,7 @@ Example 6: opp-microvolt-<name>, opp-microamp-<name>:
compatible =3D "operating-points-v2";
opp-shared;
=20
- opp00 {
+ opp@1000000000 {
opp-hz =3D /bits/ 64 <1000000000>;
opp-microvolt-slow =3D <900000 915000 925000>;
opp-microvolt-fast =3D <970000 975000 985000>;
@@ -507,7 +507,7 @@ Example 6: opp-microvolt-<name>, opp-microamp-<name>:
opp-microamp-fast =3D <71000>;
};
=20
- opp01 {
+ opp@1200000000 {
opp-hz =3D /bits/ 64 <1200000000>;
opp-microvolt-slow =3D <900000 915000 925000>, /* Supply vcc0 */
<910000 925000 935000>; /* Supply vcc1 */
--=20
2.27.0.rc0


[4.4.y-cip 04/15] PM / OPP: Remove 'operating-points-names' binding

Chen-Yu Tsai (Moxa) <wens@...>
 

From: Viresh Kumar <viresh.kumar@linaro.org>

commit af87a39a5f7cf6ef252b1aec3e2e6508a40e51f1 upstream.

These aren't used until now by any DT files and wouldn't be used now as
we have a better scheme in place now, i.e. opp-property-<name>
properties.

Remove the (useless) binding without breaking ABI.

Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Chen-Yu Tsai (Moxa) <wens@csie.org>
---
Documentation/devicetree/bindings/opp/opp.txt | 62 +------------------
1 file changed, 2 insertions(+), 60 deletions(-)

diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentatio=
n/devicetree/bindings/opp/opp.txt
index a3e7f0d5e1fb4..24eac9a977494 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -45,21 +45,10 @@ Devices supporting OPPs must set their "operating-poi=
nts-v2" property with
phandle to a OPP table in their DT node. The OPP core will use this phan=
dle to
find the operating points for the device.
=20
-Devices may want to choose OPP tables at runtime and so can provide a li=
st of
-phandles here. But only *one* of them should be chosen at runtime. This =
must be
-accompanied by a corresponding "operating-points-names" property, to uni=
quely
-identify the OPP tables.
-
If required, this can be extended for SoC vendor specfic bindings. Such =
bindings
should be documented as Documentation/devicetree/bindings/power/<vendor>=
-opp.txt
and should have a compatible description like: "operating-points-v2-<ven=
dor>".
=20
-Optional properties:
-- operating-points-names: Names of OPP tables (required if multiple OPP
- tables are present), to uniquely identify them. The same list must be =
present
- for all the CPUs which are sharing clock/voltage rails and hence the O=
PP
- tables.
-
* OPP Table Node
=20
This describes the OPPs belonging to a device. This node can have follow=
ing
@@ -448,54 +437,7 @@ Example 4: Handling multiple regulators
};
};
=20
-Example 5: Multiple OPP tables
-
-/ {
- cpus {
- cpu@0 {
- compatible =3D "arm,cortex-a7";
- ...
-
- cpu-supply =3D <&cpu_supply>
- operating-points-v2 =3D <&cpu0_opp_table_slow>, <&cpu0_opp_table_fast=
;
- operating-points-names =3D "slow", "fast";
- };
- };
-
- cpu0_opp_table_slow: opp_table_slow {
- compatible =3D "operating-points-v2";
- status =3D "okay";
- opp-shared;
-
- opp00 {
- opp-hz =3D /bits/ 64 <600000000>;
- ...
- };
-
- opp01 {
- opp-hz =3D /bits/ 64 <800000000>;
- ...
- };
- };
-
- cpu0_opp_table_fast: opp_table_fast {
- compatible =3D "operating-points-v2";
- status =3D "okay";
- opp-shared;
-
- opp10 {
- opp-hz =3D /bits/ 64 <1000000000>;
- ...
- };
-
- opp11 {
- opp-hz =3D /bits/ 64 <1100000000>;
- ...
- };
- };
-};
-
-Example 6: opp-supported-hw
+Example 5: opp-supported-hw
(example: three level hierarchy of versions: cuts, substrate and process=
)
=20
/ {
@@ -540,7 +482,7 @@ Example 6: opp-supported-hw
};
};
=20
-Example 7: opp-microvolt-<name>, opp-microamp-<name>:
+Example 6: opp-microvolt-<name>, opp-microamp-<name>:
(example: device with two possible microvolt ranges: slow and fast)
=20
/ {
--=20
2.27.0.rc0


Re: [PATCH v2 v4.4.y-cip] ARM: dts: iwg20d-q7-common: Add LCD support

Pavel Machek
 

Hi!

The iwg20d comes with a 7" capacitive touch screen, therefore
add support for it.
Thanks, applied, I'll run tests on it and push the result.

Best regards,
Pavel

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


Re: [PATCH RESEND 4.4.y-cip 08/15] PM / OPP: Parse 'opp-<prop>-<name>' bindings

Chen-Yu Tsai (Moxa) <wens@...>
 

On Thu, Jun 4, 2020 at 5:03 PM Pavel Machek <pavel@denx.de> wrote:

Hi!

/* TODO: Support multiple regulators */
-static int opp_parse_supplies(struct dev_pm_opp *opp, struct device *dev)
+static int opp_parse_supplies(struct dev_pm_opp *opp, struct device *dev,
+ struct device_opp *dev_opp)
{
u32 microvolt[3] = {0};
u32 val;
int count, ret;
+ struct property *prop = NULL;
+ char name[NAME_MAX];
+
+ /* Search for "opp-microvolt-<name>" */
+ if (dev_opp->prop_name) {
+ sprintf(name, "opp-microvolt-%s", dev_opp->prop_name);
+ prop = of_find_property(opp->np, name, NULL);
+ }
+
+ if (!prop) {
+ /* Search for "opp-microvolt" */
+ name[13] = '\0';
+ prop = of_find_property(opp->np, name, NULL);
If in !dev_opp->prop_name, it will pass uninitialized buffer to
of_find_property.
This is fixed in the next patch. But I wonder if we should merge them
into one for -cip... Unlike mainline, we already know about the
bug. No need to prepare trap for people doing bisect.
That is a good argument. I suppose we just need to make sure the end
result records both upstream commits, and that all of our automated
tools can handle that.

ChenYu


Re: [PATCH RESEND 4.4.y-cip 08/15] PM / OPP: Parse 'opp-<prop>-<name>' bindings

Pavel Machek
 

Hi!

/* TODO: Support multiple regulators */
-static int opp_parse_supplies(struct dev_pm_opp *opp, struct device *dev)
+static int opp_parse_supplies(struct dev_pm_opp *opp, struct device *dev,
+ struct device_opp *dev_opp)
{
u32 microvolt[3] = {0};
u32 val;
int count, ret;
+ struct property *prop = NULL;
+ char name[NAME_MAX];
+
+ /* Search for "opp-microvolt-<name>" */
+ if (dev_opp->prop_name) {
+ sprintf(name, "opp-microvolt-%s", dev_opp->prop_name);
+ prop = of_find_property(opp->np, name, NULL);
+ }
+
+ if (!prop) {
+ /* Search for "opp-microvolt" */
+ name[13] = '\0';
+ prop = of_find_property(opp->np, name, NULL);
If in !dev_opp->prop_name, it will pass uninitialized buffer to
of_find_property.
This is fixed in the next patch. But I wonder if we should merge them
into one for -cip... Unlike mainline, we already know about the
bug. No need to prepare trap for people doing bisect.

Best regards,
Pavel

--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH RESEND 4.4.y-cip 03/15] PM / OPP: Add {opp-microvolt|opp-microamp}-<name> binding

Chen-Yu Tsai (Moxa) <wens@...>
 

On Thu, Jun 4, 2020 at 4:46 PM Pavel Machek <pavel@denx.de> wrote:

Hi!

From: Viresh Kumar <viresh.kumar@linaro.org>

commit ffdb8cc7a27c89175e541e68e2a73f1f63ab8c6b upstream.

Depending on the version of hardware or its properties, which are only
known at runtime, various properties of the OPP can change. For example,
an OPP with frequency 1.2 GHz, may have different voltage/current
requirements based on the version of the hardware it is running on.

In order to not replicate the same OPP tables for varying values of all
such fields, this commit introduces the concept of opp-property-<name>.
The <name> can be chosen by the platform at runtime, and OPPs will be
initialized depending on that name string. Currently support is extended
for the following properties:
- opp-microvolt-<name>
- opp-microamp-<name>
That's really quite "interesting" design. I wondered if devicetree
people are okay with that.

If the name string isn't provided by the platform, or if it is provided
but doesn't match the properties present in the OPP node, we will fall
back to the original properties without the -<name> string, if they are
available.

Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Chen-Yu Tsai (Moxa) <wens@csie.org>
But, interestingly, their review tag is missing...?

As this is mainline, I don't think we need to do anything here. I
wonder how this kind of "wildcard" property names will play with new
yml format or automatic device tree checks.
The new bindings format can take regex for node names and property
names, so that itself shouldn't be an issue. The name itself is
likely hardware specific so there's not much the automatic checker
can do either.

ChenYu


Best regards,
Pavel

+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -100,6 +100,14 @@ Optional properties:
Entries for multiple regulators must be present in the same order as
regulators are specified in device's DT node.

+- opp-microvolt-<name>: Named opp-microvolt property. This is exactly similar to
+ the above opp-microvolt property, but allows multiple voltage ranges to be
+ provided for the same OPP. At runtime, the platform can pick a <name> and
+ matching opp-microvolt-<name> property will be enabled for all OPPs. If the
+ platform doesn't pick a specific <name> or the <name> doesn't match with any
+ opp-microvolt-<name> properties, then opp-microvolt property shall be used, if
+ present.
+
- opp-microamp: The maximum current drawn by the device in microamperes
considering system specific parameters (such as transients, process, aging,
maximum operating temperature range etc.) as necessary. This may be used to
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH RESEND 4.4.y-cip 08/15] PM / OPP: Parse 'opp-<prop>-<name>' bindings

Pavel Machek
 

Hi!

This is not right.

/* TODO: Support multiple regulators */
-static int opp_parse_supplies(struct dev_pm_opp *opp, struct device *dev)
+static int opp_parse_supplies(struct dev_pm_opp *opp, struct device *dev,
+ struct device_opp *dev_opp)
{
u32 microvolt[3] = {0};
u32 val;
int count, ret;
+ struct property *prop = NULL;
+ char name[NAME_MAX];
+
+ /* Search for "opp-microvolt-<name>" */
+ if (dev_opp->prop_name) {
+ sprintf(name, "opp-microvolt-%s", dev_opp->prop_name);
+ prop = of_find_property(opp->np, name, NULL);
+ }
+
+ if (!prop) {
+ /* Search for "opp-microvolt" */
+ name[13] = '\0';
+ prop = of_find_property(opp->np, name, NULL);
If in !dev_opp->prop_name, it will pass uninitialized buffer to
of_find_property.

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH RESEND 4.4.y-cip 03/15] PM / OPP: Add {opp-microvolt|opp-microamp}-<name> binding

Pavel Machek
 

Hi!

From: Viresh Kumar <viresh.kumar@linaro.org>

commit ffdb8cc7a27c89175e541e68e2a73f1f63ab8c6b upstream.

Depending on the version of hardware or its properties, which are only
known at runtime, various properties of the OPP can change. For example,
an OPP with frequency 1.2 GHz, may have different voltage/current
requirements based on the version of the hardware it is running on.

In order to not replicate the same OPP tables for varying values of all
such fields, this commit introduces the concept of opp-property-<name>.
The <name> can be chosen by the platform at runtime, and OPPs will be
initialized depending on that name string. Currently support is extended
for the following properties:
- opp-microvolt-<name>
- opp-microamp-<name>
That's really quite "interesting" design. I wondered if devicetree
people are okay with that.

If the name string isn't provided by the platform, or if it is provided
but doesn't match the properties present in the OPP node, we will fall
back to the original properties without the -<name> string, if they are
available.

Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Chen-Yu Tsai (Moxa) <wens@csie.org>
But, interestingly, their review tag is missing...?

As this is mainline, I don't think we need to do anything here. I
wonder how this kind of "wildcard" property names will play with new
yml format or automatic device tree checks.

Best regards,
Pavel

+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -100,6 +100,14 @@ Optional properties:
Entries for multiple regulators must be present in the same order as
regulators are specified in device's DT node.

+- opp-microvolt-<name>: Named opp-microvolt property. This is exactly similar to
+ the above opp-microvolt property, but allows multiple voltage ranges to be
+ provided for the same OPP. At runtime, the platform can pick a <name> and
+ matching opp-microvolt-<name> property will be enabled for all OPPs. If the
+ platform doesn't pick a specific <name> or the <name> doesn't match with any
+ opp-microvolt-<name> properties, then opp-microvolt property shall be used, if
+ present.
+
- opp-microamp: The maximum current drawn by the device in microamperes
considering system specific parameters (such as transients, process, aging,
maximum operating temperature range etc.) as necessary. This may be used to
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH v2 v4.4.y-cip] ARM: dts: iwg20d-q7-common: Add LCD support

Pavel Machek
 

Hi!

The iwg20d comes with a 7" capacitive touch screen, therefore
add support for it.
Looks good to me this patch.
BTW, when you confirmed this patch, did you update the kernel config?
If we need to add drivers, please tell us what kernel config you
used.
I don't see anything wrong, either.

SIMPLE_PANEL is not enabled in
4.4.y-cip/arm/renesas_shmobile_defconfig , and it seems to be driver
relevant to this panel.

Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


Re: CIP IRC weekly meeting today

masashi.kudo@cybertrust.co.jp <masashi.kudo@...>
 

Hi, Suzuki-san,

Noted. See you next week.

Best regards,
--
M. Kudo

-----Original Message-----
From: akihiro27.suzuki@toshiba.co.jp <akihiro27.suzuki@toshiba.co.jp>
Sent: Thursday, June 4, 2020 3:58 PM
To: 工藤 雅司(CTJ OSS事業推進室) <masashi.kudo@cybertrust.co.jp>
Cc: cip-dev@lists.cip-project.org
Subject: RE: CIP IRC weekly meeting today

Hi Kudo-san,

Sorry, I got a plan today. So I'll be absent today's IRC meeting.
SW Updates WG doesn't have any updates since last week.

Best regards,
Suzuki

-----Original Message-----
From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On Behalf Of masashi.kudo@cybertrust.co.jp
Sent: Thursday, June 4, 2020 11:39 AM
To: cip-dev@lists.cip-project.org
Subject: [cip-dev] CIP IRC weekly meeting today

Hi all,

Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.

*Please note that the IRC meeting was rescheduled to UTC (GMT) 09:00 starting from the first week of Apr. according to TSC meeting*
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2020&month=6&day=4&hour=9&min=0&sec=0&p1=224&p2=179&p3=136&p4=37&p5=241&p6=248

USWest USEast UK DE TW JP
02:00 05:00 10:00 11:00 17:00 18:00

Channel:
* irc:chat.freenode.net:6667/cip

Last meeting minutes:
https://irclogs.baserock.org/meetings/cip/2020/05/cip.2020-05-28-09.00.log.html

Agenda:

* Action item
1. Combine root filesystem with kselftest binary - iwamatsu
2. Strengthen sustainable process to backport patches from Mainline/LTS - Kernel Team
3. Upload a guideline for reference hardware platform addition - masashi910
4. Post LTP results to KernelCI - patersonc
5. Ask board owners to review reference platform configs to optimize backporting - masashi910
6. Check CVE and Patch: NFS client (CVE-2020-10742) - Pavel-san
7. Check CVE and Patch, Bluetooth BAIS attack (CVE-2020-10135) - Iwamatsu-san

* Kernel maintenance updates
* Kernel testing
* Software update
* CIP Security
* AOB

The meeting will take 30 min, although it can be extended to an hour if it makes sense and those involved in the topics can stay. Otherwise, the topic will be taken offline or in the next meeting.

Best regards,
--
M. Kudo
Cybertrust Japan Co., Ltd.


Re: CIP IRC weekly meeting today

Akihiro Suzuki
 

Hi Kudo-san,

Sorry, I got a plan today. So I'll be absent today's IRC meeting.
SW Updates WG doesn't have any updates since last week.

Best regards,
Suzuki

-----Original Message-----
From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On Behalf Of masashi.kudo@cybertrust.co.jp
Sent: Thursday, June 4, 2020 11:39 AM
To: cip-dev@lists.cip-project.org
Subject: [cip-dev] CIP IRC weekly meeting today

Hi all,

Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.

*Please note that the IRC meeting was rescheduled to UTC (GMT) 09:00 starting from the first week of Apr. according to TSC meeting*
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2020&month=6&day=4&hour=9&min=0&sec=0&p1=224&p2=179&p3=136&p4=37&p5=241&p6=248

USWest USEast UK DE TW JP
02:00 05:00 10:00 11:00 17:00 18:00

Channel:
* irc:chat.freenode.net:6667/cip

Last meeting minutes:
https://irclogs.baserock.org/meetings/cip/2020/05/cip.2020-05-28-09.00.log.html

Agenda:

* Action item
1. Combine root filesystem with kselftest binary - iwamatsu
2. Strengthen sustainable process to backport patches from Mainline/LTS - Kernel Team
3. Upload a guideline for reference hardware platform addition - masashi910
4. Post LTP results to KernelCI - patersonc
5. Ask board owners to review reference platform configs to optimize backporting - masashi910
6. Check CVE and Patch: NFS client (CVE-2020-10742) - Pavel-san
7. Check CVE and Patch, Bluetooth BAIS attack (CVE-2020-10135) - Iwamatsu-san

* Kernel maintenance updates
* Kernel testing
* Software update
* CIP Security
* AOB

The meeting will take 30 min, although it can be extended to an hour if it makes sense and those involved in the topics can stay. Otherwise, the topic will be taken offline or in the next meeting.

Best regards,
--
M. Kudo
Cybertrust Japan Co., Ltd.


Re: [PATCH RESEND 4.4.y-cip 00/15] PM / OPP v2 & cpufreq backports part 1

Nobuhiro Iwamatsu
 

Hi Wens,

Thanks for your patch!

-----Original Message-----
From: Chen-Yu Tsai (Moxa) [mailto:wens@csie.org]
Sent: Thursday, June 4, 2020 1:18 PM
To: iwamatsu nobuhiro(岩松 信洋 □SWC◯ACT) <nobuhiro1.iwamatsu@toshiba.co.jp>; pavel@denx.de
Cc: cip-dev@lists.cip-project.org; JohnsonCH.Chen@moxa.com
Subject: [PATCH RESEND 4.4.y-cip 00/15] PM / OPP v2 & cpufreq backports part 1

Hi everyone,

This is part 1 of MOXA's PM / OPP / cpufreq backport series. The whole
series aims to backport patches related to PM / OPPv2 and cpufreq
which were included in the v4.4 kernel from TI's SDK. The end goal is
to include cpufreq-ti and convert am33xx to using it and OPPv2.

Part 1 here includes patches from the v4.5 cycle, listed in topological
order:

deaa51465105 PM / OPP: Add debugfs support
1c4d12de2719 PM / OPP: Add "opp-supported-hw" binding
ffdb8cc7a27c PM / OPP: Add {opp-microvolt|opp-microamp}-<name> binding
af87a39a5f7c PM / OPP: Remove 'operating-points-names' binding
754dcf35f346 PM / OPP: Rename OPP nodes as opp@<opp-hz>
dc4e7b1fa20a PM / OPP: Add missing doc comments
7de36b0aa51a PM / OPP: Parse 'opp-supported-hw' binding
01fb4d3c39d3 PM / OPP: Parse 'opp-<prop>-<name>' bindings
fd8d8e63467c PM / OPP: Fix parsing of opp-microvolt and opp-microamp properties
d9de19b1cc01 PM / OPP: Set cpu_dev->id in cpumask first
5ff24d601092 PM / OPP: Use snprintf() instead of sprintf()
3be3f8f36e73 devicetree: bindings: Add optional dynamic-power-coefficient property
f8fa8ae06b8c cpufreq-dt: Supply power coefficient when registering cooling devices
929ca89c305a cpufreq-dt: fix handling regulator_get_voltage() result
b331bc20d928 cpufreq: cpufreq-dt: avoid uninitialized variable warnings:

Of these,

dc4e7b1fa20a PM / OPP: Add missing doc comments

was identified as a patch dependency, but otherwise serves no purpose. And

d9de19b1cc01 PM / OPP: Set cpu_dev->id in cpumask first

was found while looking through git logs. Last,

3be3f8f36e73 devicetree: bindings: Add optional dynamic-power-coefficient property

is related to

f8fa8ae06b8c cpufreq-dt: Supply power coefficient when registering cooling devices

All other patches were included from TI's SDK.

The patches apply cleanly on top of linux-4.4.y-cip. Please have a look.
I have nothing to point out other than the comment on "PM / OPP: Set cpu_dev->id in cpumask first".


Regards
ChenYu
Best regards,
Nobuhiro


Andrzej Hajda (1):
cpufreq-dt: fix handling regulator_get_voltage() result

Arnd Bergmann (1):
cpufreq: cpufreq-dt: avoid uninitialized variable warnings:

Bartlomiej Zolnierkiewicz (1):
PM / OPP: Fix parsing of opp-microvolt and opp-microamp properties

Pi-Cheng Chen (1):
PM / OPP: Set cpu_dev->id in cpumask first

Punit Agrawal (2):
devicetree: bindings: Add optional dynamic-power-coefficient property
cpufreq-dt: Supply power coefficient when registering cooling devices

Viresh Kumar (9):
PM / OPP: Add debugfs support
PM / OPP: Add "opp-supported-hw" binding
PM / OPP: Add {opp-microvolt|opp-microamp}-<name> binding
PM / OPP: Remove 'operating-points-names' binding
PM / OPP: Rename OPP nodes as opp@<opp-hz>
PM / OPP: Add missing doc comments
PM / OPP: Parse 'opp-supported-hw' binding
PM / OPP: Parse 'opp-<prop>-<name>' bindings
PM / OPP: Use snprintf() instead of sprintf()

.../devicetree/bindings/arm/cpus.txt | 17 +
Documentation/devicetree/bindings/opp/opp.txt | 132 +++++--
drivers/base/power/opp/Makefile | 1 +
drivers/base/power/opp/core.c | 336 +++++++++++++++++-
drivers/base/power/opp/cpu.c | 3 +-
drivers/base/power/opp/debugfs.c | 219 ++++++++++++
drivers/base/power/opp/opp.h | 53 ++-
drivers/cpufreq/cpufreq-dt.c | 29 +-
include/linux/pm_opp.h | 22 ++
9 files changed, 742 insertions(+), 70 deletions(-)
create mode 100644 drivers/base/power/opp/debugfs.c

--
2.27.0.rc0


Re: [PATCH RESEND 4.4.y-cip 10/15] PM / OPP: Set cpu_dev->id in cpumask first

Chen-Yu Tsai (Moxa) <wens@...>
 

On Thu, Jun 4, 2020 at 2:43 PM <nobuhiro1.iwamatsu@toshiba.co.jp> wrote:

Hi,

-----Original Message-----
From: Chen-Yu Tsai (Moxa) [mailto:wens@csie.org]
Sent: Thursday, June 4, 2020 1:18 PM
To: iwamatsu nobuhiro(岩松 信洋 □SWC◯ACT) <nobuhiro1.iwamatsu@toshiba.co.jp>; pavel@denx.de
Cc: cip-dev@lists.cip-project.org; JohnsonCH.Chen@moxa.com
Subject: [PATCH RESEND 4.4.y-cip 10/15] PM / OPP: Set cpu_dev->id in cpumask first

From: Pi-Cheng Chen <pi-cheng.chen@linaro.org>

Set cpu_dev->id in cpumask first when setting up cpumask for CPUs that
share the same OPP table. This might be helpful when handling cpumask
without the original CPU bitfield set.

Signed-off-by: Pi-Cheng Chen <pi-cheng.chen@linaro.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
You forgot adding your signed-off-by tag and upstream commit id.
Oops...

FWIW, this is commit d9de19b1cc013433ad293365b5b3902ec73dfd60 upstream.

Signed-off-by: Chen-Yu Tsai (Moxa) <wens@csie.org>

Will resend after a round of reviews.

ChenYu


Best regards,
Nobuhiro

---
drivers/base/power/opp/cpu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/base/power/opp/cpu.c b/drivers/base/power/opp/cpu.c
index 1a2e8f260b060..a0db8b3575f38 100644
--- a/drivers/base/power/opp/cpu.c
+++ b/drivers/base/power/opp/cpu.c
@@ -218,7 +218,6 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_of_cpumask_add_table);
/*
* Works only for OPP v2 bindings.
*
- * cpumask should be already set to mask of cpu_dev->id.
* Returns -ENOENT if operating-points-v2 bindings aren't supported.
*/
int dev_pm_opp_of_get_sharing_cpus(struct device *cpu_dev, cpumask_var_t cpumask)
@@ -234,6 +233,8 @@ int dev_pm_opp_of_get_sharing_cpus(struct device *cpu_dev, cpumask_var_t cpumask
return -ENOENT;
}

+ cpumask_set_cpu(cpu_dev->id, cpumask);
+
/* OPPs are shared ? */
if (!of_property_read_bool(np, "opp-shared"))
goto put_cpu_node;
--
2.27.0.rc0


Re: [PATCH RESEND 4.4.y-cip 10/15] PM / OPP: Set cpu_dev->id in cpumask first

Nobuhiro Iwamatsu
 

Hi,

-----Original Message-----
From: Chen-Yu Tsai (Moxa) [mailto:wens@csie.org]
Sent: Thursday, June 4, 2020 1:18 PM
To: iwamatsu nobuhiro(岩松 信洋 □SWC◯ACT) <nobuhiro1.iwamatsu@toshiba.co.jp>; pavel@denx.de
Cc: cip-dev@lists.cip-project.org; JohnsonCH.Chen@moxa.com
Subject: [PATCH RESEND 4.4.y-cip 10/15] PM / OPP: Set cpu_dev->id in cpumask first

From: Pi-Cheng Chen <pi-cheng.chen@linaro.org>

Set cpu_dev->id in cpumask first when setting up cpumask for CPUs that
share the same OPP table. This might be helpful when handling cpumask
without the original CPU bitfield set.

Signed-off-by: Pi-Cheng Chen <pi-cheng.chen@linaro.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
You forgot adding your signed-off-by tag and upstream commit id.

Best regards,
Nobuhiro

---
drivers/base/power/opp/cpu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/base/power/opp/cpu.c b/drivers/base/power/opp/cpu.c
index 1a2e8f260b060..a0db8b3575f38 100644
--- a/drivers/base/power/opp/cpu.c
+++ b/drivers/base/power/opp/cpu.c
@@ -218,7 +218,6 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_of_cpumask_add_table);
/*
* Works only for OPP v2 bindings.
*
- * cpumask should be already set to mask of cpu_dev->id.
* Returns -ENOENT if operating-points-v2 bindings aren't supported.
*/
int dev_pm_opp_of_get_sharing_cpus(struct device *cpu_dev, cpumask_var_t cpumask)
@@ -234,6 +233,8 @@ int dev_pm_opp_of_get_sharing_cpus(struct device *cpu_dev, cpumask_var_t cpumask
return -ENOENT;
}

+ cpumask_set_cpu(cpu_dev->id, cpumask);
+
/* OPPs are shared ? */
if (!of_property_read_bool(np, "opp-shared"))
goto put_cpu_node;
--
2.27.0.rc0


[PATCH RESEND 4.4.y-cip 15/15] cpufreq: cpufreq-dt: avoid uninitialized variable warnings:

Chen-Yu Tsai (Moxa) <wens@...>
 

From: Arnd Bergmann <arnd@arndb.de>

commit b331bc20d9281213f7fb67912638e0fb5baeb324 upstream.

gcc warns quite a bit about values returned from allocate_resources()
in cpufreq-dt.c:

cpufreq-dt.c: In function 'cpufreq_init':
cpufreq-dt.c:327:6: error: 'cpu_dev' may be used uninitialized in this fu=
nction [-Werror=3Dmaybe-uninitialized]
cpufreq-dt.c:197:17: note: 'cpu_dev' was declared here
cpufreq-dt.c:376:2: error: 'cpu_clk' may be used uninitialized in this fu=
nction [-Werror=3Dmaybe-uninitialized]
cpufreq-dt.c:199:14: note: 'cpu_clk' was declared here
cpufreq-dt.c: In function 'dt_cpufreq_probe':
cpufreq-dt.c:461:2: error: 'cpu_clk' may be used uninitialized in this fu=
nction [-Werror=3Dmaybe-uninitialized]
cpufreq-dt.c:447:14: note: 'cpu_clk' was declared here

The problem is that it's slightly hard for gcc to follow return
codes across PTR_ERR() calls.

This patch uses explicit assignments to the "ret" variable to make
it easier for gcc to verify that the code is actually correct,
without the need to add a bogus initialization.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Chen-Yu Tsai (Moxa) <wens@csie.org>
---
drivers/cpufreq/cpufreq-dt.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index 9bc37c437874a..0ca74d0700583 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -142,15 +142,16 @@ static int allocate_resources(int cpu, struct devic=
e **cdev,
=20
try_again:
cpu_reg =3D regulator_get_optional(cpu_dev, reg);
- if (IS_ERR(cpu_reg)) {
+ ret =3D PTR_ERR_OR_ZERO(cpu_reg);
+ if (ret) {
/*
* If cpu's regulator supply node is present, but regulator is
* not yet registered, we should try defering probe.
*/
- if (PTR_ERR(cpu_reg) =3D=3D -EPROBE_DEFER) {
+ if (ret =3D=3D -EPROBE_DEFER) {
dev_dbg(cpu_dev, "cpu%d regulator not ready, retry\n",
cpu);
- return -EPROBE_DEFER;
+ return ret;
}
=20
/* Try with "cpu-supply" */
@@ -159,18 +160,16 @@ try_again:
goto try_again;
}
=20
- dev_dbg(cpu_dev, "no regulator for cpu%d: %ld\n",
- cpu, PTR_ERR(cpu_reg));
+ dev_dbg(cpu_dev, "no regulator for cpu%d: %d\n", cpu, ret);
}
=20
cpu_clk =3D clk_get(cpu_dev, NULL);
- if (IS_ERR(cpu_clk)) {
+ ret =3D PTR_ERR_OR_ZERO(cpu_clk);
+ if (ret) {
/* put regulator */
if (!IS_ERR(cpu_reg))
regulator_put(cpu_reg);
=20
- ret =3D PTR_ERR(cpu_clk);
-
/*
* If cpu's clk node is present, but clock is not yet
* registered, we should try defering probe.
--=20
2.27.0.rc0


[PATCH RESEND 4.4.y-cip 08/15] PM / OPP: Parse 'opp-<prop>-<name>' bindings

Chen-Yu Tsai (Moxa) <wens@...>
 

From: Viresh Kumar <viresh.kumar@linaro.org>

commit 01fb4d3c39d35b725441e8a9a26b3f3ad67793ed upstream.

OPP bindings (for few properties) allow a platform to choose a
value/range among a set of available options. The options are present as
opp-<prop>-<name>, where the platform needs to supply the <name> string.

The OPP properties which allow such an option are: opp-microvolt and
opp-microamp.

Add support to the OPP-core to parse these bindings, by introducing
dev_pm_opp_{set|put}_prop_name() APIs.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Tested-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Chen-Yu Tsai (Moxa) <wens@csie.org>
---
drivers/base/power/opp/core.c | 165 ++++++++++++++++++++++++++++++----
drivers/base/power/opp/opp.h | 2 +
include/linux/pm_opp.h | 9 ++
3 files changed, 161 insertions(+), 15 deletions(-)

diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.=
c
index a73433c3cbe45..408fee4cb72df 100644
--- a/drivers/base/power/opp/core.c
+++ b/drivers/base/power/opp/core.c
@@ -562,6 +562,9 @@ static void _remove_device_opp(struct device_opp *dev=
_opp)
if (dev_opp->supported_hw)
return;
=20
+ if (dev_opp->prop_name)
+ return;
+
list_dev =3D list_first_entry(&dev_opp->dev_list, struct device_list_op=
p,
node);
=20
@@ -794,35 +797,48 @@ unlock:
}
=20
/* TODO: Support multiple regulators */
-static int opp_parse_supplies(struct dev_pm_opp *opp, struct device *dev=
)
+static int opp_parse_supplies(struct dev_pm_opp *opp, struct device *dev=
,
+ struct device_opp *dev_opp)
{
u32 microvolt[3] =3D {0};
u32 val;
int count, ret;
+ struct property *prop =3D NULL;
+ char name[NAME_MAX];
+
+ /* Search for "opp-microvolt-<name>" */
+ if (dev_opp->prop_name) {
+ sprintf(name, "opp-microvolt-%s", dev_opp->prop_name);
+ prop =3D of_find_property(opp->np, name, NULL);
+ }
+
+ if (!prop) {
+ /* Search for "opp-microvolt" */
+ name[13] =3D '\0';
+ prop =3D of_find_property(opp->np, name, NULL);
=20
- /* Missing property isn't a problem, but an invalid entry is */
- if (!of_find_property(opp->np, "opp-microvolt", NULL))
- return 0;
+ /* Missing property isn't a problem, but an invalid entry is */
+ if (!prop)
+ return 0;
+ }
=20
- count =3D of_property_count_u32_elems(opp->np, "opp-microvolt");
+ count =3D of_property_count_u32_elems(opp->np, name);
if (count < 0) {
- dev_err(dev, "%s: Invalid opp-microvolt property (%d)\n",
- __func__, count);
+ dev_err(dev, "%s: Invalid %s property (%d)\n",
+ __func__, name, count);
return count;
}
=20
/* There can be one or three elements here */
if (count !=3D 1 && count !=3D 3) {
- dev_err(dev, "%s: Invalid number of elements in opp-microvolt property=
(%d)\n",
- __func__, count);
+ dev_err(dev, "%s: Invalid number of elements in %s property (%d)\n",
+ __func__, name, count);
return -EINVAL;
}
=20
- ret =3D of_property_read_u32_array(opp->np, "opp-microvolt", microvolt,
- count);
+ ret =3D of_property_read_u32_array(opp->np, name, microvolt, count);
if (ret) {
- dev_err(dev, "%s: error parsing opp-microvolt: %d\n", __func__,
- ret);
+ dev_err(dev, "%s: error parsing %s: %d\n", __func__, name, ret);
return -EINVAL;
}
=20
@@ -836,7 +852,20 @@ static int opp_parse_supplies(struct dev_pm_opp *opp=
, struct device *dev)
opp->u_volt_max =3D microvolt[2];
}
=20
- if (!of_property_read_u32(opp->np, "opp-microamp", &val))
+ /* Search for "opp-microamp-<name>" */
+ prop =3D NULL;
+ if (dev_opp->prop_name) {
+ sprintf(name, "opp-microamp-%s", dev_opp->prop_name);
+ prop =3D of_find_property(opp->np, name, NULL);
+ }
+
+ if (!prop) {
+ /* Search for "opp-microamp" */
+ name[12] =3D '\0';
+ prop =3D of_find_property(opp->np, name, NULL);
+ }
+
+ if (prop && !of_property_read_u32(opp->np, name, &val))
opp->u_amp =3D val;
=20
return 0;
@@ -954,6 +983,112 @@ unlock:
}
EXPORT_SYMBOL_GPL(dev_pm_opp_put_supported_hw);
=20
+/**
+ * dev_pm_opp_set_prop_name() - Set prop-extn name
+ * @dev: Device for which the regulator has to be set.
+ * @name: name to postfix to properties.
+ *
+ * This is required only for the V2 bindings, and it enables a platform =
to
+ * specify the extn to be used for certain property names. The propertie=
s to
+ * which the extension will apply are opp-microvolt and opp-microamp. OP=
P core
+ * should postfix the property name with -<name> while looking for them.
+ *
+ * Locking: The internal device_opp and opp structures are RCU protected=
.
+ * Hence this function internally uses RCU updater strategy with mutex l=
ocks
+ * to keep the integrity of the internal data structures. Callers should=
ensure
+ * that this function is *NOT* called under RCU protection or in context=
s where
+ * mutex cannot be locked.
+ */
+int dev_pm_opp_set_prop_name(struct device *dev, const char *name)
+{
+ struct device_opp *dev_opp;
+ int ret =3D 0;
+
+ /* Hold our list modification lock here */
+ mutex_lock(&dev_opp_list_lock);
+
+ dev_opp =3D _add_device_opp(dev);
+ if (!dev_opp) {
+ ret =3D -ENOMEM;
+ goto unlock;
+ }
+
+ /* Make sure there are no concurrent readers while updating dev_opp */
+ WARN_ON(!list_empty(&dev_opp->opp_list));
+
+ /* Do we already have a prop-name associated with dev_opp? */
+ if (dev_opp->prop_name) {
+ dev_err(dev, "%s: Already have prop-name %s\n", __func__,
+ dev_opp->prop_name);
+ ret =3D -EBUSY;
+ goto err;
+ }
+
+ dev_opp->prop_name =3D kstrdup(name, GFP_KERNEL);
+ if (!dev_opp->prop_name) {
+ ret =3D -ENOMEM;
+ goto err;
+ }
+
+ mutex_unlock(&dev_opp_list_lock);
+ return 0;
+
+err:
+ _remove_device_opp(dev_opp);
+unlock:
+ mutex_unlock(&dev_opp_list_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(dev_pm_opp_set_prop_name);
+
+/**
+ * dev_pm_opp_put_prop_name() - Releases resources blocked for prop-name
+ * @dev: Device for which the regulator has to be set.
+ *
+ * This is required only for the V2 bindings, and is called for a matchi=
ng
+ * dev_pm_opp_set_prop_name(). Until this is called, the device_opp stru=
cture
+ * will not be freed.
+ *
+ * Locking: The internal device_opp and opp structures are RCU protected=
.
+ * Hence this function internally uses RCU updater strategy with mutex l=
ocks
+ * to keep the integrity of the internal data structures. Callers should=
ensure
+ * that this function is *NOT* called under RCU protection or in context=
s where
+ * mutex cannot be locked.
+ */
+void dev_pm_opp_put_prop_name(struct device *dev)
+{
+ struct device_opp *dev_opp;
+
+ /* Hold our list modification lock here */
+ mutex_lock(&dev_opp_list_lock);
+
+ /* Check for existing list for 'dev' first */
+ dev_opp =3D _find_device_opp(dev);
+ if (IS_ERR(dev_opp)) {
+ dev_err(dev, "Failed to find dev_opp: %ld\n", PTR_ERR(dev_opp));
+ goto unlock;
+ }
+
+ /* Make sure there are no concurrent readers while updating dev_opp */
+ WARN_ON(!list_empty(&dev_opp->opp_list));
+
+ if (!dev_opp->prop_name) {
+ dev_err(dev, "%s: Doesn't have a prop-name\n", __func__);
+ goto unlock;
+ }
+
+ kfree(dev_opp->prop_name);
+ dev_opp->prop_name =3D NULL;
+
+ /* Try freeing device_opp if this was the last blocking resource */
+ _remove_device_opp(dev_opp);
+
+unlock:
+ mutex_unlock(&dev_opp_list_lock);
+}
+EXPORT_SYMBOL_GPL(dev_pm_opp_put_prop_name);
+
static bool _opp_is_supported(struct device *dev, struct device_opp *dev=
_opp,
struct device_node *np)
{
@@ -1048,7 +1183,7 @@ static int _opp_add_static_v2(struct device *dev, s=
truct device_node *np)
if (!of_property_read_u32(np, "clock-latency-ns", &val))
new_opp->clock_latency_ns =3D val;
=20
- ret =3D opp_parse_supplies(new_opp, dev);
+ ret =3D opp_parse_supplies(new_opp, dev, dev_opp);
if (ret)
goto free_opp;
=20
diff --git a/drivers/base/power/opp/opp.h b/drivers/base/power/opp/opp.h
index 70f4564a6ab9d..690638ef36ee5 100644
--- a/drivers/base/power/opp/opp.h
+++ b/drivers/base/power/opp/opp.h
@@ -131,6 +131,7 @@ struct device_list_opp {
* @suspend_opp: Pointer to OPP to be used during device suspend.
* @supported_hw: Array of version number to support.
* @supported_hw_count: Number of elements in supported_hw array.
+ * @prop_name: A name to postfix to many DT properties, while parsing th=
em.
* @dentry: debugfs dentry pointer of the real device directory (not lin=
ks).
* @dentry_name: Name of the real dentry.
*
@@ -157,6 +158,7 @@ struct device_opp {
=20
unsigned int *supported_hw;
unsigned int supported_hw_count;
+ const char *prop_name;
=20
#ifdef CONFIG_DEBUG_FS
struct dentry *dentry;
diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
index 3a85110242f00..95403d2ccaf56 100644
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm_opp.h
@@ -58,6 +58,8 @@ struct srcu_notifier_head *dev_pm_opp_get_notifier(stru=
ct device *dev);
int dev_pm_opp_set_supported_hw(struct device *dev, const u32 *versions,
unsigned int count);
void dev_pm_opp_put_supported_hw(struct device *dev);
+int dev_pm_opp_set_prop_name(struct device *dev, const char *name);
+void dev_pm_opp_put_prop_name(struct device *dev);
#else
static inline unsigned long dev_pm_opp_get_voltage(struct dev_pm_opp *op=
p)
{
@@ -142,6 +144,13 @@ static inline int dev_pm_opp_set_supported_hw(struct=
device *dev,
=20
static inline void dev_pm_opp_put_supported_hw(struct device *dev) {}
=20
+static inline int dev_pm_opp_set_prop_name(struct device *dev, const cha=
r *name)
+{
+ return -EINVAL;
+}
+
+static inline void dev_pm_opp_put_prop_name(struct device *dev) {}
+
#endif /* CONFIG_PM_OPP */
=20
#if defined(CONFIG_PM_OPP) && defined(CONFIG_OF)
--=20
2.27.0.rc0

2121 - 2140 of 6828