Thread (1 message) 1 message, 1 author, 2020-07-21

Re: opp: Modify opp API, dev_pm_opp_get_freq(), find freq in opp, even it is disabled

flat view

From: Viresh Kumar <viresh.kumar@linaro.org>
Date: 2020-07-21 08:21:20
Also in: linux-arm-kernel, linux-mediatek, lkml

On 21-07-20, 01:15, Stephen Boyd wrote:
Quoting Andrew-sh.Cheng (2020-07-20 01:55:26)
quoted
From: "Andrew-sh.Cheng" <redacted>

Modify dev_pm_opp_get_freq() to return freqeuncy
even this opp item is not available.
So that we can get the information of disable opp items.

Signed-off-by: Andrew-sh.Cheng <redacted>
---
 drivers/opp/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index eed42d6b2e6b..5213e0462382 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -118,7 +118,7 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_get_voltage);
  */
 unsigned long dev_pm_opp_get_freq(struct dev_pm_opp *opp)
 {
-       if (IS_ERR_OR_NULL(opp) || !opp->available) {
+       if (IS_ERR_OR_NULL(opp)) {
I wonder why we even have this check. Seems like the caller deserves an
oops in this case instead of a small pr_err().
I think the reason is same as to why multiple subsystems do similar checks.
While many of them don't do anything if they get a NULL pointer and simply
return, which is fine to support cases where NULL is passed.

But I do agree that maybe we may want to make sure opp-table or opp pointers
passed are all valid all the time and so just remove these checks and let them
crash.

-- 
viresh
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help