* [PATCH 2/4] opp: Track device's resources configuration status
2020-08-13 4:28 ` [PATCH V2 1/4] opp: Enable resources again if they were disabled earlier Viresh Kumar
@ 2020-08-13 4:28 ` Viresh Kumar
2020-08-15 8:03 ` Stephen Boyd
2020-08-13 4:29 ` [PATCH 3/4] opp: Reused enabled flag and remove regulator_enabled Viresh Kumar
` (3 subsequent siblings)
4 siblings, 1 reply; 20+ messages in thread
From: Viresh Kumar @ 2020-08-13 4:28 UTC (permalink / raw)
To: Viresh Kumar, Nishanth Menon, Stephen Boyd
Cc: Viresh Kumar, linux-pm, Vincent Guittot, Rafael Wysocki, mka,
sibis, linux-kernel
The OPP core needs to track if the resources of devices are enabled or
configured or not, as it disables the resources when target_freq is set
to 0.
Handle that with a separate variable to make it easy to maintain.
Also note that we will unconditionally call clk_set_rate() in the case
where the resources are getting enabled again. This shouldn't have any
side effects anyway.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
drivers/opp/core.c | 37 ++++++++++++++++++-------------------
drivers/opp/opp.h | 2 ++
2 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index 9668ea04cc80..e8882e7fd8a5 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -888,22 +888,18 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long target_freq)
}
if (unlikely(!target_freq)) {
+ ret = 0;
+
+ if (!opp_table->enabled)
+ goto put_opp_table;
+
/*
* Some drivers need to support cases where some platforms may
* have OPP table for the device, while others don't and
* opp_set_rate() just needs to behave like clk_set_rate().
*/
- if (!_get_opp_count(opp_table)) {
- ret = 0;
- goto put_opp_table;
- }
-
- if (!opp_table->required_opp_tables && !opp_table->regulators &&
- !opp_table->paths) {
- dev_err(dev, "target frequency can't be 0\n");
- ret = -EINVAL;
+ if (!_get_opp_count(opp_table))
goto put_opp_table;
- }
ret = _set_opp_bw(opp_table, NULL, dev, true);
if (ret)
@@ -915,6 +911,9 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long target_freq)
}
ret = _set_required_opps(dev, opp_table, NULL);
+ if (!ret)
+ opp_table->enabled = false;
+
goto put_opp_table;
}
@@ -933,14 +932,11 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long target_freq)
old_freq = clk_get_rate(clk);
/* Return early if nothing to do */
- if (old_freq == freq) {
- if (!opp_table->required_opp_tables && !opp_table->regulators &&
- !opp_table->paths) {
- dev_dbg(dev, "%s: old/new frequencies (%lu Hz) are same, nothing to do\n",
- __func__, freq);
- ret = 0;
- goto put_opp_table;
- }
+ if (opp_table->enabled && old_freq == freq) {
+ dev_dbg(dev, "%s: old/new frequencies (%lu Hz) are same, nothing to do\n",
+ __func__, freq);
+ ret = 0;
+ goto put_opp_table;
}
/*
@@ -1001,8 +997,11 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long target_freq)
dev_err(dev, "Failed to set required opps: %d\n", ret);
}
- if (!ret)
+ if (!ret) {
ret = _set_opp_bw(opp_table, opp, dev, false);
+ if (!ret)
+ opp_table->enabled = true;
+ }
put_opp:
dev_pm_opp_put(opp);
diff --git a/drivers/opp/opp.h b/drivers/opp/opp.h
index e51646ff279e..bd35802acc6e 100644
--- a/drivers/opp/opp.h
+++ b/drivers/opp/opp.h
@@ -152,6 +152,7 @@ enum opp_table_access {
* property).
* @paths: Interconnect path handles
* @path_count: Number of interconnect paths
+ * @enabled: Set to true if the device's resources are enabled/configured.
* @genpd_performance_state: Device's power domain support performance state.
* @is_genpd: Marks if the OPP table belongs to a genpd.
* @set_opp: Platform specific set_opp callback
@@ -198,6 +199,7 @@ struct opp_table {
bool regulator_enabled;
struct icc_path **paths;
unsigned int path_count;
+ bool enabled;
bool genpd_performance_state;
bool is_genpd;
--
2.14.1
^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [PATCH 2/4] opp: Track device's resources configuration status
2020-08-13 4:28 ` [PATCH 2/4] opp: Track device's resources configuration status Viresh Kumar
@ 2020-08-15 8:03 ` Stephen Boyd
2020-08-17 5:05 ` Viresh Kumar
0 siblings, 1 reply; 20+ messages in thread
From: Stephen Boyd @ 2020-08-15 8:03 UTC (permalink / raw)
To: Nishanth Menon, Viresh Kumar, Viresh Kumar
Cc: Viresh Kumar, linux-pm, Vincent Guittot, Rafael Wysocki, mka,
sibis, linux-kernel
Quoting Viresh Kumar (2020-08-12 21:28:59)
> The OPP core needs to track if the resources of devices are enabled or
> configured or not, as it disables the resources when target_freq is set
> to 0.
>
> Handle that with a separate variable to make it easy to maintain.
>
> Also note that we will unconditionally call clk_set_rate() in the case
> where the resources are getting enabled again. This shouldn't have any
> side effects anyway.
Any reason to want to do that? We'll have to grab the prepare lock in
the clk framework to figure out that there's nothing to do sometimes. If
anything, a comment may help to indicate that we call clk_set_rate()
again, but don't expect it to matter much.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 2/4] opp: Track device's resources configuration status
2020-08-15 8:03 ` Stephen Boyd
@ 2020-08-17 5:05 ` Viresh Kumar
0 siblings, 0 replies; 20+ messages in thread
From: Viresh Kumar @ 2020-08-17 5:05 UTC (permalink / raw)
To: Stephen Boyd
Cc: Nishanth Menon, Viresh Kumar, linux-pm, Vincent Guittot,
Rafael Wysocki, mka, sibis, linux-kernel
On 15-08-20, 01:03, Stephen Boyd wrote:
> Quoting Viresh Kumar (2020-08-12 21:28:59)
> > The OPP core needs to track if the resources of devices are enabled or
> > configured or not, as it disables the resources when target_freq is set
> > to 0.
> >
> > Handle that with a separate variable to make it easy to maintain.
> >
> > Also note that we will unconditionally call clk_set_rate() in the case
> > where the resources are getting enabled again. This shouldn't have any
> > side effects anyway.
>
> Any reason to want to do that?
To avoid more flags, code paths and simplicity of the code. And this
should normally happen in a corner case as well, like calling
set-rate(0) from suspend and then reinitializing things again in
resume.
> We'll have to grab the prepare lock in
> the clk framework to figure out that there's nothing to do sometimes. If
> anything, a comment may help to indicate that we call clk_set_rate()
> again, but don't expect it to matter much.
Ok.
--
viresh
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH 3/4] opp: Reused enabled flag and remove regulator_enabled
2020-08-13 4:28 ` [PATCH V2 1/4] opp: Enable resources again if they were disabled earlier Viresh Kumar
2020-08-13 4:28 ` [PATCH 2/4] opp: Track device's resources configuration status Viresh Kumar
@ 2020-08-13 4:29 ` Viresh Kumar
2020-08-15 7:55 ` Stephen Boyd
2020-08-18 7:10 ` Rajendra Nayak
2020-08-13 4:29 ` [PATCH 4/4] opp: Split out _opp_set_rate_zero() Viresh Kumar
` (2 subsequent siblings)
4 siblings, 2 replies; 20+ messages in thread
From: Viresh Kumar @ 2020-08-13 4:29 UTC (permalink / raw)
To: Viresh Kumar, Nishanth Menon, Stephen Boyd
Cc: Viresh Kumar, linux-pm, Vincent Guittot, Rafael Wysocki, mka,
sibis, linux-kernel
The common "enabled" flag can be used here instead of
"regulator_enabled" now.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
drivers/opp/core.c | 13 +++----------
drivers/opp/opp.h | 2 --
2 files changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index e8882e7fd8a5..5f5da257f58a 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -703,12 +703,10 @@ static int _generic_set_opp_regulator(struct opp_table *opp_table,
* Enable the regulator after setting its voltages, otherwise it breaks
* some boot-enabled regulators.
*/
- if (unlikely(!opp_table->regulator_enabled)) {
+ if (unlikely(!opp_table->enabled)) {
ret = regulator_enable(reg);
if (ret < 0)
dev_warn(dev, "Failed to enable regulator: %d", ret);
- else
- opp_table->regulator_enabled = true;
}
return 0;
@@ -905,10 +903,7 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long target_freq)
if (ret)
goto put_opp_table;
- if (opp_table->regulator_enabled) {
- regulator_disable(opp_table->regulators[0]);
- opp_table->regulator_enabled = false;
- }
+ regulator_disable(opp_table->regulators[0]);
ret = _set_required_opps(dev, opp_table, NULL);
if (!ret)
@@ -1795,11 +1790,9 @@ void dev_pm_opp_put_regulators(struct opp_table *opp_table)
/* Make sure there are no concurrent readers while updating opp_table */
WARN_ON(!list_empty(&opp_table->opp_list));
- if (opp_table->regulator_enabled) {
+ if (opp_table->enabled) {
for (i = opp_table->regulator_count - 1; i >= 0; i--)
regulator_disable(opp_table->regulators[i]);
-
- opp_table->regulator_enabled = false;
}
for (i = opp_table->regulator_count - 1; i >= 0; i--)
diff --git a/drivers/opp/opp.h b/drivers/opp/opp.h
index bd35802acc6e..0c3de3f6db5c 100644
--- a/drivers/opp/opp.h
+++ b/drivers/opp/opp.h
@@ -147,7 +147,6 @@ enum opp_table_access {
* @clk: Device's clock handle
* @regulators: Supply regulators
* @regulator_count: Number of power supply regulators. Its value can be -1
- * @regulator_enabled: Set to true if regulators were previously enabled.
* (uninitialized), 0 (no opp-microvolt property) or > 0 (has opp-microvolt
* property).
* @paths: Interconnect path handles
@@ -196,7 +195,6 @@ struct opp_table {
struct clk *clk;
struct regulator **regulators;
int regulator_count;
- bool regulator_enabled;
struct icc_path **paths;
unsigned int path_count;
bool enabled;
--
2.14.1
^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [PATCH 3/4] opp: Reused enabled flag and remove regulator_enabled
2020-08-13 4:29 ` [PATCH 3/4] opp: Reused enabled flag and remove regulator_enabled Viresh Kumar
@ 2020-08-15 7:55 ` Stephen Boyd
2020-08-20 7:19 ` Viresh Kumar
2020-08-18 7:10 ` Rajendra Nayak
1 sibling, 1 reply; 20+ messages in thread
From: Stephen Boyd @ 2020-08-15 7:55 UTC (permalink / raw)
To: Nishanth Menon, Viresh Kumar, Viresh Kumar
Cc: Viresh Kumar, linux-pm, Vincent Guittot, Rafael Wysocki, mka,
sibis, linux-kernel
Quoting Viresh Kumar (2020-08-12 21:29:00)
> The common "enabled" flag can be used here instead of
> "regulator_enabled" now.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Why not put this before the other patch? And mention that it will be
reused in another place soon? Then the previous patch won't look like
we're adding a variable to the struct when it is only used inside a
single function. Or at least squash it with the previous patch.
> ---
> drivers/opp/core.c | 13 +++----------
> drivers/opp/opp.h | 2 --
> 2 files changed, 3 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/opp/core.c b/drivers/opp/core.c
> index e8882e7fd8a5..5f5da257f58a 100644
> --- a/drivers/opp/core.c
> +++ b/drivers/opp/core.c
> @@ -703,12 +703,10 @@ static int _generic_set_opp_regulator(struct opp_table *opp_table,
> * Enable the regulator after setting its voltages, otherwise it breaks
> * some boot-enabled regulators.
> */
> - if (unlikely(!opp_table->regulator_enabled)) {
> + if (unlikely(!opp_table->enabled)) {
> ret = regulator_enable(reg);
> if (ret < 0)
> dev_warn(dev, "Failed to enable regulator: %d", ret);
> - else
> - opp_table->regulator_enabled = true;
A quick glance makes this look unsafe now because we're only checking
'enabled' and not actually setting it when this function is called. I
have to go back to the previous patch to understand where enabled is now
set to confirm that it is OK. If it was all one patch all the context
would be here.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 3/4] opp: Reused enabled flag and remove regulator_enabled
2020-08-15 7:55 ` Stephen Boyd
@ 2020-08-20 7:19 ` Viresh Kumar
0 siblings, 0 replies; 20+ messages in thread
From: Viresh Kumar @ 2020-08-20 7:19 UTC (permalink / raw)
To: Stephen Boyd
Cc: Nishanth Menon, Viresh Kumar, linux-pm, Vincent Guittot,
Rafael Wysocki, mka, sibis, linux-kernel
On 15-08-20, 00:55, Stephen Boyd wrote:
> Quoting Viresh Kumar (2020-08-12 21:29:00)
> > diff --git a/drivers/opp/core.c b/drivers/opp/core.c
> > index e8882e7fd8a5..5f5da257f58a 100644
> > --- a/drivers/opp/core.c
> > +++ b/drivers/opp/core.c
> > @@ -703,12 +703,10 @@ static int _generic_set_opp_regulator(struct opp_table *opp_table,
> > * Enable the regulator after setting its voltages, otherwise it breaks
> > * some boot-enabled regulators.
> > */
> > - if (unlikely(!opp_table->regulator_enabled)) {
> > + if (unlikely(!opp_table->enabled)) {
> > ret = regulator_enable(reg);
> > if (ret < 0)
> > dev_warn(dev, "Failed to enable regulator: %d", ret);
> > - else
> > - opp_table->regulator_enabled = true;
>
> A quick glance makes this look unsafe now because we're only checking
> 'enabled' and not actually setting it when this function is called. I
> have to go back to the previous patch to understand where enabled is now
> set to confirm that it is OK. If it was all one patch all the context
> would be here.
The only case where things can go crazy are the cases where (for
example) clk_set_rate() fails, or something like that which would be a
bug and it shouldn't bother in the normal working of this code.
--
viresh
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 3/4] opp: Reused enabled flag and remove regulator_enabled
2020-08-13 4:29 ` [PATCH 3/4] opp: Reused enabled flag and remove regulator_enabled Viresh Kumar
2020-08-15 7:55 ` Stephen Boyd
@ 2020-08-18 7:10 ` Rajendra Nayak
1 sibling, 0 replies; 20+ messages in thread
From: Rajendra Nayak @ 2020-08-18 7:10 UTC (permalink / raw)
To: Viresh Kumar, Viresh Kumar, Nishanth Menon, Stephen Boyd
Cc: linux-pm, Vincent Guittot, Rafael Wysocki, mka, sibis, linux-kernel
On 8/13/2020 9:59 AM, Viresh Kumar wrote:
> The common "enabled" flag can be used here instead of
> "regulator_enabled" now.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> drivers/opp/core.c | 13 +++----------
> drivers/opp/opp.h | 2 --
> 2 files changed, 3 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/opp/core.c b/drivers/opp/core.c
> index e8882e7fd8a5..5f5da257f58a 100644
> --- a/drivers/opp/core.c
> +++ b/drivers/opp/core.c
> @@ -703,12 +703,10 @@ static int _generic_set_opp_regulator(struct opp_table *opp_table,
> * Enable the regulator after setting its voltages, otherwise it breaks
> * some boot-enabled regulators.
> */
> - if (unlikely(!opp_table->regulator_enabled)) {
> + if (unlikely(!opp_table->enabled)) {
> ret = regulator_enable(reg);
> if (ret < 0)
> dev_warn(dev, "Failed to enable regulator: %d", ret);
> - else
> - opp_table->regulator_enabled = true;
> }
>
> return 0;
> @@ -905,10 +903,7 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long target_freq)
> if (ret)
> goto put_opp_table;
>
> - if (opp_table->regulator_enabled) {
> - regulator_disable(opp_table->regulators[0]);
> - opp_table->regulator_enabled = false;
> - }
> + regulator_disable(opp_table->regulators[0]);
unconditionally calling regulator_disable() here based on the common
'enabled' flag results in a crash on platforms without regulators
associated with the opp table.
>
> ret = _set_required_opps(dev, opp_table, NULL);
> if (!ret)
> @@ -1795,11 +1790,9 @@ void dev_pm_opp_put_regulators(struct opp_table *opp_table)
> /* Make sure there are no concurrent readers while updating opp_table */
> WARN_ON(!list_empty(&opp_table->opp_list));
>
> - if (opp_table->regulator_enabled) {
> + if (opp_table->enabled) {
> for (i = opp_table->regulator_count - 1; i >= 0; i--)
> regulator_disable(opp_table->regulators[i]);
> -
> - opp_table->regulator_enabled = false;
> }
>
> for (i = opp_table->regulator_count - 1; i >= 0; i--)
> diff --git a/drivers/opp/opp.h b/drivers/opp/opp.h
> index bd35802acc6e..0c3de3f6db5c 100644
> --- a/drivers/opp/opp.h
> +++ b/drivers/opp/opp.h
> @@ -147,7 +147,6 @@ enum opp_table_access {
> * @clk: Device's clock handle
> * @regulators: Supply regulators
> * @regulator_count: Number of power supply regulators. Its value can be -1
> - * @regulator_enabled: Set to true if regulators were previously enabled.
> * (uninitialized), 0 (no opp-microvolt property) or > 0 (has opp-microvolt
> * property).
> * @paths: Interconnect path handles
> @@ -196,7 +195,6 @@ struct opp_table {
> struct clk *clk;
> struct regulator **regulators;
> int regulator_count;
> - bool regulator_enabled;
> struct icc_path **paths;
> unsigned int path_count;
> bool enabled;
>
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH 4/4] opp: Split out _opp_set_rate_zero()
2020-08-13 4:28 ` [PATCH V2 1/4] opp: Enable resources again if they were disabled earlier Viresh Kumar
2020-08-13 4:28 ` [PATCH 2/4] opp: Track device's resources configuration status Viresh Kumar
2020-08-13 4:29 ` [PATCH 3/4] opp: Reused enabled flag and remove regulator_enabled Viresh Kumar
@ 2020-08-13 4:29 ` Viresh Kumar
2020-08-19 23:56 ` [PATCH V2 1/4] opp: Enable resources again if they were disabled earlier Sasha Levin
2020-08-26 13:54 ` Sasha Levin
4 siblings, 0 replies; 20+ messages in thread
From: Viresh Kumar @ 2020-08-13 4:29 UTC (permalink / raw)
To: Viresh Kumar, Nishanth Menon, Stephen Boyd
Cc: Viresh Kumar, linux-pm, Vincent Guittot, Rafael Wysocki, mka,
sibis, linux-kernel
Create separate routine _opp_set_rate_zero() to handle !target_freq
case.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
drivers/opp/core.c | 52 +++++++++++++++++++++++++++++-----------------------
1 file changed, 29 insertions(+), 23 deletions(-)
diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index 5f5da257f58a..e198b57efcf8 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -860,6 +860,34 @@ int dev_pm_opp_set_bw(struct device *dev, struct dev_pm_opp *opp)
}
EXPORT_SYMBOL_GPL(dev_pm_opp_set_bw);
+static int _opp_set_rate_zero(struct device *dev, struct opp_table *opp_table)
+{
+ int ret;
+
+ if (!opp_table->enabled)
+ return 0;
+
+ /*
+ * Some drivers need to support cases where some platforms may
+ * have OPP table for the device, while others don't and
+ * opp_set_rate() just needs to behave like clk_set_rate().
+ */
+ if (!_get_opp_count(opp_table))
+ return 0;
+
+ ret = _set_opp_bw(opp_table, NULL, dev, true);
+ if (ret)
+ return ret;
+
+ regulator_disable(opp_table->regulators[0]);
+
+ ret = _set_required_opps(dev, opp_table, NULL);
+ if (!ret)
+ opp_table->enabled = false;
+
+ return ret;
+}
+
/**
* dev_pm_opp_set_rate() - Configure new OPP based on frequency
* @dev: device for which we do this operation
@@ -886,29 +914,7 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long target_freq)
}
if (unlikely(!target_freq)) {
- ret = 0;
-
- if (!opp_table->enabled)
- goto put_opp_table;
-
- /*
- * Some drivers need to support cases where some platforms may
- * have OPP table for the device, while others don't and
- * opp_set_rate() just needs to behave like clk_set_rate().
- */
- if (!_get_opp_count(opp_table))
- goto put_opp_table;
-
- ret = _set_opp_bw(opp_table, NULL, dev, true);
- if (ret)
- goto put_opp_table;
-
- regulator_disable(opp_table->regulators[0]);
-
- ret = _set_required_opps(dev, opp_table, NULL);
- if (!ret)
- opp_table->enabled = false;
-
+ ret = _opp_set_rate_zero(dev, opp_table);
goto put_opp_table;
}
--
2.14.1
^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [PATCH V2 1/4] opp: Enable resources again if they were disabled earlier
2020-08-13 4:28 ` [PATCH V2 1/4] opp: Enable resources again if they were disabled earlier Viresh Kumar
` (2 preceding siblings ...)
2020-08-13 4:29 ` [PATCH 4/4] opp: Split out _opp_set_rate_zero() Viresh Kumar
@ 2020-08-19 23:56 ` Sasha Levin
2020-08-20 4:58 ` Viresh Kumar
2020-08-26 13:54 ` Sasha Levin
4 siblings, 1 reply; 20+ messages in thread
From: Sasha Levin @ 2020-08-19 23:56 UTC (permalink / raw)
To: Sasha Levin, Viresh Kumar, Rajendra Nayak, Viresh Kumar, Nishanth Menon
Cc: Viresh Kumar, linux-pm, stable
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2641 bytes --]
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: cd7ea582866f ("opp: Make dev_pm_opp_set_rate() handle freq = 0 to drop performance votes").
The bot has tested the following trees: v5.8.1, v5.7.15, v5.4.58.
v5.8.1: Build OK!
v5.7.15: Build failed! Errors:
drivers/opp/core.c:849:17: error: ‘struct opp_table’ has no member named ‘paths’
drivers/opp/core.c:849:17: error: ‘struct opp_table’ has no member named ‘paths’
drivers/opp/core.c:849:17: error: ‘struct opp_table’ has no member named ‘paths’
drivers/opp/core.c:849:17: error: 'struct opp_table' has no member named 'paths'
drivers/opp/core.c:849:17: error: ‘struct opp_table’ has no member named ‘paths’
drivers/opp/core.c:849:17: error: ‘struct opp_table’ has no member named ‘paths’
drivers/opp/core.c:849:17: error: 'struct opp_table' has no member named 'paths'
drivers/opp/core.c:849:17: error: 'struct opp_table' has no member named 'paths'
drivers/opp/core.c:849:17: error: ‘struct opp_table’ has no member named ‘paths’
drivers/opp/core.c:849:17: error: ‘struct opp_table’ has no member named ‘paths’
drivers/opp/core.c:849:17: error: 'struct opp_table' has no member named 'paths'
drivers/opp/core.c:849:17: error: 'struct opp_table' has no member named 'paths'
v5.4.58: Build failed! Errors:
drivers/opp/core.c:847:17: error: ‘struct opp_table’ has no member named ‘paths’
drivers/opp/core.c:847:17: error: 'struct opp_table' has no member named 'paths'
drivers/opp/core.c:847:17: error: ‘struct opp_table’ has no member named ‘paths’
drivers/opp/core.c:847:17: error: 'struct opp_table' has no member named 'paths'
drivers/opp/core.c:847:17: error: ‘struct opp_table’ has no member named ‘paths’
drivers/opp/core.c:847:17: error: ‘struct opp_table’ has no member named ‘paths’
drivers/opp/core.c:847:17: error: 'struct opp_table' has no member named 'paths'
drivers/opp/core.c:847:17: error: ‘struct opp_table’ has no member named ‘paths’
drivers/opp/core.c:847:17: error: ‘struct opp_table’ has no member named ‘paths’
drivers/opp/core.c:847:17: error: 'struct opp_table' has no member named 'paths'
drivers/opp/core.c:847:17: error: ‘struct opp_table’ has no member named ‘paths’
drivers/opp/core.c:847:17: error: 'struct opp_table' has no member named 'paths'
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks
Sasha
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH V2 1/4] opp: Enable resources again if they were disabled earlier
2020-08-19 23:56 ` [PATCH V2 1/4] opp: Enable resources again if they were disabled earlier Sasha Levin
@ 2020-08-20 4:58 ` Viresh Kumar
0 siblings, 0 replies; 20+ messages in thread
From: Viresh Kumar @ 2020-08-20 4:58 UTC (permalink / raw)
To: Sasha Levin
Cc: Rajendra Nayak, Viresh Kumar, Nishanth Menon, linux-pm, stable
On 19-08-20, 23:56, Sasha Levin wrote:
> Hi
>
> [This is an automated email]
>
> This commit has been processed because it contains a "Fixes:" tag
> fixing commit: cd7ea582866f ("opp: Make dev_pm_opp_set_rate() handle freq = 0 to drop performance votes").
>
> The bot has tested the following trees: v5.8.1, v5.7.15, v5.4.58.
>
> v5.8.1: Build OK!
> v5.7.15: Build failed! Errors:
> drivers/opp/core.c:849:17: error: ‘struct opp_table’ has no member named ‘paths’
> drivers/opp/core.c:849:17: error: ‘struct opp_table’ has no member named ‘paths’
> drivers/opp/core.c:849:17: error: ‘struct opp_table’ has no member named ‘paths’
> drivers/opp/core.c:849:17: error: 'struct opp_table' has no member named 'paths'
> drivers/opp/core.c:849:17: error: ‘struct opp_table’ has no member named ‘paths’
> drivers/opp/core.c:849:17: error: ‘struct opp_table’ has no member named ‘paths’
> drivers/opp/core.c:849:17: error: 'struct opp_table' has no member named 'paths'
> drivers/opp/core.c:849:17: error: 'struct opp_table' has no member named 'paths'
> drivers/opp/core.c:849:17: error: ‘struct opp_table’ has no member named ‘paths’
> drivers/opp/core.c:849:17: error: ‘struct opp_table’ has no member named ‘paths’
> drivers/opp/core.c:849:17: error: 'struct opp_table' has no member named 'paths'
> drivers/opp/core.c:849:17: error: 'struct opp_table' has no member named 'paths'
>
> v5.4.58: Build failed! Errors:
> drivers/opp/core.c:847:17: error: ‘struct opp_table’ has no member named ‘paths’
> drivers/opp/core.c:847:17: error: 'struct opp_table' has no member named 'paths'
> drivers/opp/core.c:847:17: error: ‘struct opp_table’ has no member named ‘paths’
> drivers/opp/core.c:847:17: error: 'struct opp_table' has no member named 'paths'
> drivers/opp/core.c:847:17: error: ‘struct opp_table’ has no member named ‘paths’
> drivers/opp/core.c:847:17: error: ‘struct opp_table’ has no member named ‘paths’
> drivers/opp/core.c:847:17: error: 'struct opp_table' has no member named 'paths'
> drivers/opp/core.c:847:17: error: ‘struct opp_table’ has no member named ‘paths’
> drivers/opp/core.c:847:17: error: ‘struct opp_table’ has no member named ‘paths’
> drivers/opp/core.c:847:17: error: 'struct opp_table' has no member named 'paths'
> drivers/opp/core.c:847:17: error: ‘struct opp_table’ has no member named ‘paths’
> drivers/opp/core.c:847:17: error: 'struct opp_table' has no member named 'paths'
>
>
> NOTE: The patch will not be queued to stable trees until it is upstream.
>
> How should we proceed with this patch?
We probably need to send different versions for those kernel versions.
--
viresh
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH V2 1/4] opp: Enable resources again if they were disabled earlier
2020-08-13 4:28 ` [PATCH V2 1/4] opp: Enable resources again if they were disabled earlier Viresh Kumar
` (3 preceding siblings ...)
2020-08-19 23:56 ` [PATCH V2 1/4] opp: Enable resources again if they were disabled earlier Sasha Levin
@ 2020-08-26 13:54 ` Sasha Levin
2020-08-27 4:32 ` Viresh Kumar
4 siblings, 1 reply; 20+ messages in thread
From: Sasha Levin @ 2020-08-26 13:54 UTC (permalink / raw)
To: Sasha Levin, Viresh Kumar, Rajendra Nayak, Viresh Kumar, Nishanth Menon
Cc: Viresh Kumar, linux-pm, stable
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2649 bytes --]
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: cd7ea582866f ("opp: Make dev_pm_opp_set_rate() handle freq = 0 to drop performance votes").
The bot has tested the following trees: v5.8.2, v5.7.16, v5.4.59.
v5.8.2: Build OK!
v5.7.16: Build failed! Errors:
drivers/opp/core.c:849:17: error: ‘struct opp_table’ has no member named ‘paths’
drivers/opp/core.c:849:17: error: ‘struct opp_table’ has no member named ‘paths’
drivers/opp/core.c:849:17: error: ‘struct opp_table’ has no member named ‘paths’
drivers/opp/core.c:849:17: error: ‘struct opp_table’ has no member named ‘paths’
drivers/opp/core.c:849:17: error: ‘struct opp_table’ has no member named ‘paths’
drivers/opp/core.c:849:17: error: 'struct opp_table' has no member named 'paths'
drivers/opp/core.c:849:17: error: 'struct opp_table' has no member named 'paths'
drivers/opp/core.c:849:17: error: ‘struct opp_table’ has no member named ‘paths’
drivers/opp/core.c:849:17: error: ‘struct opp_table’ has no member named ‘paths’
drivers/opp/core.c:849:17: error: 'struct opp_table' has no member named 'paths'
drivers/opp/core.c:849:17: error: 'struct opp_table' has no member named 'paths'
v5.4.59: Build failed! Errors:
drivers/opp/core.c:847:17: error: ‘struct opp_table’ has no member named ‘paths’
drivers/opp/core.c:847:17: error: ‘struct opp_table’ has no member named ‘paths’
drivers/opp/core.c:847:17: error: ‘struct opp_table’ has no member named ‘paths’
drivers/opp/core.c:847:17: error: ‘struct opp_table’ has no member named ‘paths’
drivers/opp/core.c:847:17: error: 'struct opp_table' has no member named 'paths'
drivers/opp/core.c:847:17: error: ‘struct opp_table’ has no member named ‘paths’
drivers/opp/core.c:847:17: error: ‘struct opp_table’ has no member named ‘paths’
drivers/opp/core.c:847:17: error: 'struct opp_table' has no member named 'paths'
drivers/opp/core.c:847:17: error: 'struct opp_table' has no member named 'paths'
drivers/opp/core.c:847:17: error: ‘struct opp_table’ has no member named ‘paths’
drivers/opp/core.c:847:17: error: ‘struct opp_table’ has no member named ‘paths’
drivers/opp/core.c:847:17: error: 'struct opp_table' has no member named 'paths'
drivers/opp/core.c:847:17: error: 'struct opp_table' has no member named 'paths'
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks
Sasha
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH V2 1/4] opp: Enable resources again if they were disabled earlier
2020-08-26 13:54 ` Sasha Levin
@ 2020-08-27 4:32 ` Viresh Kumar
0 siblings, 0 replies; 20+ messages in thread
From: Viresh Kumar @ 2020-08-27 4:32 UTC (permalink / raw)
To: Sasha Levin
Cc: Rajendra Nayak, Viresh Kumar, Nishanth Menon, linux-pm, stable
On 26-08-20, 13:54, Sasha Levin wrote:
> Hi
>
> [This is an automated email]
>
> This commit has been processed because it contains a "Fixes:" tag
> fixing commit: cd7ea582866f ("opp: Make dev_pm_opp_set_rate() handle freq = 0 to drop performance votes").
>
> The bot has tested the following trees: v5.8.2, v5.7.16, v5.4.59.
>
> v5.8.2: Build OK!
> v5.7.16: Build failed! Errors:
> drivers/opp/core.c:849:17: error: ‘struct opp_table’ has no member named ‘paths’
> drivers/opp/core.c:849:17: error: ‘struct opp_table’ has no member named ‘paths’
> drivers/opp/core.c:849:17: error: ‘struct opp_table’ has no member named ‘paths’
> drivers/opp/core.c:849:17: error: ‘struct opp_table’ has no member named ‘paths’
> drivers/opp/core.c:849:17: error: ‘struct opp_table’ has no member named ‘paths’
> drivers/opp/core.c:849:17: error: 'struct opp_table' has no member named 'paths'
> drivers/opp/core.c:849:17: error: 'struct opp_table' has no member named 'paths'
> drivers/opp/core.c:849:17: error: ‘struct opp_table’ has no member named ‘paths’
> drivers/opp/core.c:849:17: error: ‘struct opp_table’ has no member named ‘paths’
> drivers/opp/core.c:849:17: error: 'struct opp_table' has no member named 'paths'
> drivers/opp/core.c:849:17: error: 'struct opp_table' has no member named 'paths'
>
> v5.4.59: Build failed! Errors:
> drivers/opp/core.c:847:17: error: ‘struct opp_table’ has no member named ‘paths’
> drivers/opp/core.c:847:17: error: ‘struct opp_table’ has no member named ‘paths’
> drivers/opp/core.c:847:17: error: ‘struct opp_table’ has no member named ‘paths’
> drivers/opp/core.c:847:17: error: ‘struct opp_table’ has no member named ‘paths’
> drivers/opp/core.c:847:17: error: 'struct opp_table' has no member named 'paths'
> drivers/opp/core.c:847:17: error: ‘struct opp_table’ has no member named ‘paths’
> drivers/opp/core.c:847:17: error: ‘struct opp_table’ has no member named ‘paths’
> drivers/opp/core.c:847:17: error: 'struct opp_table' has no member named 'paths'
> drivers/opp/core.c:847:17: error: 'struct opp_table' has no member named 'paths'
> drivers/opp/core.c:847:17: error: ‘struct opp_table’ has no member named ‘paths’
> drivers/opp/core.c:847:17: error: ‘struct opp_table’ has no member named ‘paths’
> drivers/opp/core.c:847:17: error: 'struct opp_table' has no member named 'paths'
> drivers/opp/core.c:847:17: error: 'struct opp_table' has no member named 'paths'
>
>
> NOTE: The patch will not be queued to stable trees until it is upstream.
>
> How should we proceed with this patch?
I have already sent the right fix for stable.
https://lore.kernel.org/lkml/31f315cf2b0c4afd60b07b7121058dcaa6e4afa1.1598260882.git.viresh.kumar@linaro.org/
--
viresh
^ permalink raw reply [flat|nested] 20+ messages in thread