[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.22.394.2010281050200.183010@ramsan.of.borg>
Date: Wed, 28 Oct 2020 10:53:16 +0100 (CET)
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Viresh Kumar <viresh.kumar@...aro.org>
cc: Rafael Wysocki <rjw@...ysocki.net>,
Viresh Kumar <vireshk@...nel.org>, Nishanth Menon <nm@...com>,
Stephen Boyd <sboyd@...nel.org>, linux-pm@...r.kernel.org,
Vincent Guittot <vincent.guittot@...aro.org>,
Aisheng Dong <aisheng.dong@....com>,
linux-kernel@...r.kernel.org, linux-renesas-soc@...r.kernel.org
Subject: Re: [PATCH] opp: Don't always remove static OPPs in
_of_add_opp_table_v1()
Hi Viresh,
On Wed, 14 Oct 2020, Viresh Kumar wrote:
> The patch missed returning 0 early in case of success and hence the
> static OPPs got removed by mistake. Fix it.
>
> Fixes: 90d46d71cce2 ("opp: Handle multiple calls for same OPP table in _of_add_opp_table_v1()")
> Reported-by: Aisheng Dong <aisheng.dong@....com>
> Signed-off-by: Viresh Kumar <viresh.kumar@...aro.org>
This revives cpufreq on R-Car Gen2, and fixes a later s2ram regression
in commit dc279ac6e5b4e06e ("cpufreq: dt: Refactor initialization to
handle probe deferral properly"), where the PMIC is accessesed while
the I2C controller is still suspended.
Tested-by: Geert Uytterhoeven <geert+renesas@...der.be>
> --- a/drivers/opp/of.c
> +++ b/drivers/opp/of.c
> @@ -944,6 +944,8 @@ static int _of_add_opp_table_v1(struct device *dev, struct opp_table *opp_table)
> nr -= 2;
> }
>
> + return 0;
> +
> remove_static_opp:
> _opp_remove_all_static(opp_table);
>
> --
> 2.25.0.rc1.19.g042ed3e048af
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Powered by blists - more mailing lists