[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAJZ5v0hH1iJ-QT+Sm32ESy_JstD+1TF=wV3FW7rnkCAiDjEeig@mail.gmail.com>
Date: Tue, 22 Aug 2023 22:24:25 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Swapnil Sapkal <swapnil.sapkal@....com>
Cc: ray.huang@....com, rafael@...nel.org, viresh.kumar@...aro.org,
linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
gautham.shenoy@....com
Subject: Re: [PATCH v1 0/2] amd-pstate-ut: Fix issues observed after loading
amd-pstate-ut driver
On Fri, Aug 18, 2023 at 1:45 PM Swapnil Sapkal <swapnil.sapkal@....com> wrote:
>
> This series fixes amd-pstate-ut which is currently failing for two
> reasons:
>
> 1) The code for amd-pstate-ut was written when CONFIG_X86_AMD_PSTATE
> was tristate config and amd_pstate can be built as module. In
> current implementation the driver is built-in and previous module
> parameters are removed. But amd-pstate-ut still try to read old module
> parameters. Therefore, test fails. First patch fixes this issue by
> removing those module parameter references.
>
> 2) In amd_pstate_ut_check_perf() and amd_pstate_ut_check_freq()
> functions, cpufreq_cpu_get() is called to get policy of the
> cpu and mark it as busy. In these functions cpufreq_cpu_put()
> should be used to release the policy. As cpufreq_cpu_put()
> is not used to release the policy, any other entity trying to
> access the policy is blocked indefinitely. One such scenario
> occurs when mode of amd-pstate is changed. Second patch fixes this
> by calling cpufreq_cpu_put() wherever necessary.
>
> Swapnil Sapkal (2):
> amd-pstate-ut: Remove module parameter access from amd-pstate-ut
> amd-pstate-ut: Fix kernel panic due to loading amd-pstate-ut driver
>
> drivers/cpufreq/amd-pstate-ut.c | 46 +++++++++++++--------------------
> 1 file changed, 18 insertions(+), 28 deletions(-)
>
> --
Both patches applied as 6.6 material with subjects adjusted to the
usual cpufreq patch naming pattern and some changelog edits.
Thanks!
Powered by blists - more mailing lists