[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALHNRZ84s8rxQKWZeF-bfS31nK6ay4_MspmYa4+qapf9gtk+Fg@mail.gmail.com>
Date: Sun, 12 Oct 2025 21:32:34 -0500
From: Aaron Kling <webgeek1234@...il.com>
To: Viresh Kumar <viresh.kumar@...aro.org>
Cc: Krzysztof Kozlowski <krzk@...nel.org>, Rob Herring <robh@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
Thierry Reding <thierry.reding@...il.com>, Jonathan Hunter <jonathanh@...dia.com>,
"Rafael J. Wysocki" <rafael@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, linux-kernel@...r.kernel.org,
devicetree@...r.kernel.org, linux-tegra@...r.kernel.org,
linux-pm@...r.kernel.org
Subject: Re: [PATCH v2 1/8] cpufreq: tegra186: add OPP support and set bandwidth
On Tue, Sep 30, 2025 at 5:30 AM Viresh Kumar <viresh.kumar@...aro.org> wrote:
>
> On 09-09-25, 01:21, Aaron Kling via B4 Relay wrote:
> > +static int tegra_cpufreq_set_bw(struct cpufreq_policy *policy, unsigned long freq_khz)
> > +{
> > + struct tegra186_cpufreq_data *data = cpufreq_get_driver_data();
> > + struct dev_pm_opp *opp __free(put_opp);
>
> The usage here looks incorrect..
>
> > + struct device *dev;
> > + int ret;
> > +
> > + dev = get_cpu_device(policy->cpu);
> > + if (!dev)
> > + return -ENODEV;
>
> On failure, we would return from here with a garbage `opp` pointer, which the
> OPP core may try to free ?
>
> Moving the variable definition here would fix that.
If the var was NULL initialized, would the free handle that correctly?
Keeping the declarations at the start of the function reads better
imo.
Aaron
Powered by blists - more mailing lists