linux-kernel - Re: [PATCH 2/2] opp: quiet down WARN when no valid OPPs remain

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200107113055.d4ebweisve73yf3m@vireshk-i7>
Date:   Tue, 7 Jan 2020 17:00:55 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Michał Mirosław <mirq-linux@...e.qmqm.pl>
Cc:     Nishanth Menon <nm@...com>, Stephen Boyd <sboyd@...nel.org>,
        linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] opp: quiet down WARN when no valid OPPs remain

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 ?

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

> This is why
> it's still communicated via dev_err().

-- 
viresh