linux-kernel - RE: [PATCH v7 12/14] cpufreq: Add Kryo CPU scaling driver

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: <017601d3edb3$c0d96d40$428c47c0$@codeaurora.org>
Date:   Thu, 17 May 2018 10:50:34 +0300
From:   <ilialin@...eaurora.org>
To:     "'Viresh Kumar'" <viresh.kumar@...aro.org>,
        "'Amit Kucheria'" <amit.kucheria@...aro.org>
Cc:     "'Michael Turquette'" <mturquette@...libre.com>,
        <sboyd@...nel.org>, "'Rob Herring'" <robh@...nel.org>,
        "'Mark Rutland'" <mark.rutland@....com>, <nm@...com>,
        <lgirdwood@...il.com>, <broonie@...nel.org>,
        "'Andy Gross'" <andy.gross@...aro.org>,
        "'David Brown'" <david.brown@...aro.org>,
        <catalin.marinas@....com>, <will.deacon@....com>,
        "'Rafael J. Wysocki'" <rjw@...ysocki.net>,
        <linux-clk@...r.kernel.org>, <devicetree@...r.kernel.org>,
        "'LKML'" <linux-kernel@...r.kernel.org>,
        "'Linux PM list'" <linux-pm@...r.kernel.org>,
        <linux-arm-msm@...r.kernel.org>, <linux-soc@...r.kernel.org>,
        "'lakml'" <linux-arm-kernel@...ts.infradead.org>,
        "'Rajendra Nayak'" <rnayak@...eaurora.org>,
        <nicolas.dechesne@...aro.org>, <celster@...eaurora.org>,
        <tfinkel@...eaurora.org>
Subject: RE: [PATCH v7 12/14] cpufreq: Add Kryo CPU scaling driver



> -----Original Message-----
> From: Viresh Kumar <viresh.kumar@...aro.org>
> Sent: Wednesday, May 16, 2018 17:12
> To: Amit Kucheria <amit.kucheria@...aro.org>
> Cc: Ilia Lin <ilialin@...eaurora.org>; Michael Turquette
> <mturquette@...libre.com>; sboyd@...nel.org; Rob Herring
> <robh@...nel.org>; Mark Rutland <mark.rutland@....com>; nm@...com;
> lgirdwood@...il.com; broonie@...nel.org; Andy Gross
> <andy.gross@...aro.org>; David Brown <david.brown@...aro.org>;
> catalin.marinas@....com; will.deacon@....com; Rafael J. Wysocki
> <rjw@...ysocki.net>; linux-clk@...r.kernel.org;
> devicetree@...r.kernel.org; LKML <linux-kernel@...r.kernel.org>; Linux
> PM list <linux-pm@...r.kernel.org>; linux-arm-msm@...r.kernel.org; linux-
> soc@...r.kernel.org; lakml <linux-arm-kernel@...ts.infradead.org>;
> Rajendra Nayak <rnayak@...eaurora.org>; nicolas.dechesne@...aro.org;
> celster@...eaurora.org; tfinkel@...eaurora.org
> Subject: Re: [PATCH v7 12/14] cpufreq: Add Kryo CPU scaling driver
> 
> On 16-05-18, 16:12, Amit Kucheria wrote:
> > > +       ret = PTR_ERR_OR_ZERO(opp_temp =
> > > +
> dev_pm_opp_set_supported_hw(cpu_dev,&versions,1));
> > > +       if (0 > ret)
> >
> > Any particular reason to prefer this over (ret < 0) that is generally
> > used? I've seen it used to avoid the == vs. = typos, but not for other
> > comparisons.
> >
> > Suggest sticking to what is commonly used i.e. ret < 0.
> >
> > > +               goto free_opp;
> > > +
> > > +       cpu_dev = get_cpu_device(GOLD_LEAD);
> >
> > Error check cpu_dev here?
> >
> > > +       ret = PTR_ERR_OR_ZERO(opp_temp =
> > > +
> dev_pm_opp_set_supported_hw(cpu_dev,&versions,1));
> > > +       if (0 > ret)
> > > +               goto free_opp;
> 
> The goto here is wrong

If we are here, then the first dev_pm_opp_set_supported_hw() succeeded. And
should be deallocated before exit with error.

> 
> > > +
> > > +
> > > +       ret =
> PTR_ERR_OR_ZERO(platform_device_register_simple("cpufreq-dt",
> > > +                                                             -1,
> > > + NULL, 0));
> > > +
> > > +       if (0 == ret)
> > > +               return 0;
> > > +
> > > +free_opp:
> > > +       dev_pm_opp_put_supported_hw(opp_temp);
> >
> > This is not needed because dev_pm_opp_set_supported_hw will free
> > memory in case of failure. This call in only needed in case of a
> > successful get.
> 
> But this is still required for the case where platform device registration
fails.
> 
> --
> viresh