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>] [day] [month] [year] [list]
Message-ID: <20200721082111.les32oe7hrfikeew@vireshk-mac-ubuntu>
Date:   Tue, 21 Jul 2020 13:51:11 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Stephen Boyd <sboyd@...nel.org>
Cc:     "Andrew-sh.Cheng" <andrew-sh.cheng@...iatek.com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Nishanth Menon <nm@...com>, Viresh Kumar <vireshk@...nel.org>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-mediatek@...ts.infradead.org, linux-pm@...r.kernel.org,
        srv_heupstream@...iatek.com
Subject: Re: opp: Modify opp API, dev_pm_opp_get_freq(), find freq in opp,
 even it is disabled

On 21-07-20, 01:15, Stephen Boyd wrote:
> Quoting Andrew-sh.Cheng (2020-07-20 01:55:26)
> > From: "Andrew-sh.Cheng" <andrew-sh.cheng@...iatek.com>
> > 
> > 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 <andrew-sh.cheng@...iatek.com>
> > ---
> >  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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ