Messages in this thread | | | Date | Wed, 8 Jan 2020 12:19:01 +0530 | From | Viresh Kumar <> | Subject | Re: [PATCH 2/2] opp: quiet down WARN when no valid OPPs remain |
| |
On 07-01-20, 14:57, Michał Mirosław wrote: > On Tue, Jan 07, 2020 at 05:00:55PM +0530, Viresh Kumar wrote: > > On 07-01-20, 10:58, Michał Mirosław wrote: > > > On Tue, Jan 07, 2020 at 12:11:29PM +0530, Viresh Kumar wrote: > > > > On 03-01-20, 20:36, Michał Mirosław wrote: > > > > > Per CPU screenful of backtraces is not really that useful. Replace > > > > > WARN with a diagnostic discriminating common causes of empty OPP table. > > > > But why should a platform have an OPP table in DT where none of them works for > > > > it ? I added the warn intentionally here just for that case. > > > Hmm. I guess we can make it WARN_ON_ONCE instead of removing it > > I am not sure this will get triggered more than once normally anyway, isn't it ? > > It is triggered once per core.
What platform it is ? Maybe because cpufreq driver failed to initialize the policy for all CPUs and so this is getting repeated.
> > > , but I > > > don't think the backtrace is ever useful in this case. > > Hmm, I am less concerned about backtraces than highlighting problem in a serious > > way. The simple print messages are missed many times by people and probably > > that's why I used a WARN instead. > > > > > > Empty table can > > > be because eg. you run old DT on newer hardware version. > > > > Hmm, but then a big warning isn't that bad as we need to highlight the issue to > > everyone as cpufreq won't be working. isn't it ? > > A user normally can't do much about it. Rather this is a developer targeted > message. Maybe a rewording of the messages be better? Something to also > include consequences of the error?
I agree that a WARN may be a bit excessive here.
-- viresh
| |