[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230818114452.66780-1-swapnil.sapkal@amd.com>
Date: Fri, 18 Aug 2023 11:44:50 +0000
From: Swapnil Sapkal <swapnil.sapkal@....com>
To: <ray.huang@....com>, <rafael@...nel.org>, <viresh.kumar@...aro.org>
CC: <linux-pm@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<gautham.shenoy@....com>, Swapnil Sapkal <swapnil.sapkal@....com>
Subject: [PATCH v1 0/2] amd-pstate-ut: Fix issues observed after loading amd-pstate-ut driver
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(-)
--
2.34.1
Powered by blists - more mailing lists