drivers/cpufreq/amd-pstate.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
From: Mario Limonciello <mario.limonciello@amd.com>
To make it clearer that amd-pstate failing to setup is a problem
with the firmware, prefix several messages with FW_BUG.
Suggested-by: Paul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
---
drivers/cpufreq/amd-pstate.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
index 024d33d5e3670..0a9d6fe426d1c 100644
--- a/drivers/cpufreq/amd-pstate.c
+++ b/drivers/cpufreq/amd-pstate.c
@@ -931,13 +931,13 @@ static int amd_pstate_init_freq(struct amd_cpudata *cpudata)
* Check _CPC in ACPI table objects if any values are incorrect
*/
if (min_freq <= 0 || max_freq <= 0 || nominal_freq <= 0 || min_freq > max_freq) {
- pr_err("min_freq(%d) or max_freq(%d) or nominal_freq(%d) value is incorrect\n",
+ pr_err(FW_BUG "min_freq(%d) or max_freq(%d) or nominal_freq(%d) value is incorrect\n",
min_freq, max_freq, nominal_freq);
return -EINVAL;
}
if (lowest_nonlinear_freq <= min_freq || lowest_nonlinear_freq > nominal_freq) {
- pr_err("lowest_nonlinear_freq(%d) value is out of range [min_freq(%d), nominal_freq(%d)]\n",
+ pr_err(FW_BUG "lowest_nonlinear_freq(%d) value is out of range [min_freq(%d), nominal_freq(%d)]\n",
lowest_nonlinear_freq, min_freq, nominal_freq);
return -EINVAL;
}
@@ -1505,7 +1505,7 @@ static int amd_pstate_epp_cpu_init(struct cpufreq_policy *policy)
return 0;
free_cpudata1:
- pr_warn("Failed to initialize CPU %d: %d\n", policy->cpu, ret);
+ pr_warn(FW_BUG "Failed to initialize CPU %d: %d\n", policy->cpu, ret);
kfree(cpudata);
return ret;
}
--
2.43.0
On 3/21/2025 3:11 AM, Mario Limonciello wrote:
> From: Mario Limonciello <mario.limonciello@amd.com>
>
> To make it clearer that amd-pstate failing to setup is a problem
> with the firmware, prefix several messages with FW_BUG.
>
> Suggested-by: Paul Menzel <pmenzel@molgen.mpg.de>
> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
> ---
> drivers/cpufreq/amd-pstate.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
> index 024d33d5e3670..0a9d6fe426d1c 100644
> --- a/drivers/cpufreq/amd-pstate.c
> +++ b/drivers/cpufreq/amd-pstate.c
> @@ -931,13 +931,13 @@ static int amd_pstate_init_freq(struct amd_cpudata *cpudata)
> * Check _CPC in ACPI table objects if any values are incorrect
> */
> if (min_freq <= 0 || max_freq <= 0 || nominal_freq <= 0 || min_freq > max_freq) {
> - pr_err("min_freq(%d) or max_freq(%d) or nominal_freq(%d) value is incorrect\n",
> + pr_err(FW_BUG "min_freq(%d) or max_freq(%d) or nominal_freq(%d) value is incorrect\n",
> min_freq, max_freq, nominal_freq);
> return -EINVAL;
> }
>
> if (lowest_nonlinear_freq <= min_freq || lowest_nonlinear_freq > nominal_freq) {
> - pr_err("lowest_nonlinear_freq(%d) value is out of range [min_freq(%d), nominal_freq(%d)]\n",
> + pr_err(FW_BUG "lowest_nonlinear_freq(%d) value is out of range [min_freq(%d), nominal_freq(%d)]\n",
> lowest_nonlinear_freq, min_freq, nominal_freq);
> return -EINVAL;
> }
> @@ -1505,7 +1505,7 @@ static int amd_pstate_epp_cpu_init(struct cpufreq_policy *policy)
> return 0;
>
> free_cpudata1:
> - pr_warn("Failed to initialize CPU %d: %d\n", policy->cpu, ret);
> + pr_warn(FW_BUG "Failed to initialize CPU %d: %d\n", policy->cpu, ret);
Just thinking are we sure that we land here only through a firmware bug?
If not, we should probably use FW_WARN ?,
or
Should we add to the error message the specific firmware issue that might cause
each of the functions to fail (e.g. amd_pstate_init_perf(), amd_pstate_init_freq(),
etc).
Comments for the macros, for reference,
* FW_BUG
* Add this to a message where you are sure the firmware is buggy or behaves
* really stupid or out of spec. Be aware that the responsible BIOS developer
* should be able to fix this issue or at least get a concrete idea of the
* problem by reading your message without the need of looking at the kernel
* code.
*
* Use it for definite and high priority BIOS bugs.
*
* FW_WARN
* Use it for not that clear (e.g. could the kernel messed up things already?)
* and medium priority BIOS bugs.
> kfree(cpudata);
> return ret;
> }
On 3/28/2025 2:20 AM, Dhananjay Ugwekar wrote:
> On 3/21/2025 3:11 AM, Mario Limonciello wrote:
>> From: Mario Limonciello <mario.limonciello@amd.com>
>>
>> To make it clearer that amd-pstate failing to setup is a problem
>> with the firmware, prefix several messages with FW_BUG.
>>
>> Suggested-by: Paul Menzel <pmenzel@molgen.mpg.de>
>> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
>> ---
>> drivers/cpufreq/amd-pstate.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
>> index 024d33d5e3670..0a9d6fe426d1c 100644
>> --- a/drivers/cpufreq/amd-pstate.c
>> +++ b/drivers/cpufreq/amd-pstate.c
>> @@ -931,13 +931,13 @@ static int amd_pstate_init_freq(struct amd_cpudata *cpudata)
>> * Check _CPC in ACPI table objects if any values are incorrect
>> */
>> if (min_freq <= 0 || max_freq <= 0 || nominal_freq <= 0 || min_freq > max_freq) {
>> - pr_err("min_freq(%d) or max_freq(%d) or nominal_freq(%d) value is incorrect\n",
>> + pr_err(FW_BUG "min_freq(%d) or max_freq(%d) or nominal_freq(%d) value is incorrect\n",
>> min_freq, max_freq, nominal_freq);
>> return -EINVAL;
>> }
>>
>> if (lowest_nonlinear_freq <= min_freq || lowest_nonlinear_freq > nominal_freq) {
>> - pr_err("lowest_nonlinear_freq(%d) value is out of range [min_freq(%d), nominal_freq(%d)]\n",
>> + pr_err(FW_BUG "lowest_nonlinear_freq(%d) value is out of range [min_freq(%d), nominal_freq(%d)]\n",
>> lowest_nonlinear_freq, min_freq, nominal_freq);
>> return -EINVAL;
>> }
>> @@ -1505,7 +1505,7 @@ static int amd_pstate_epp_cpu_init(struct cpufreq_policy *policy)
>> return 0;
>>
>> free_cpudata1:
>> - pr_warn("Failed to initialize CPU %d: %d\n", policy->cpu, ret);
>> + pr_warn(FW_BUG "Failed to initialize CPU %d: %d\n", policy->cpu, ret);
>
> Just thinking are we sure that we land here only through a firmware bug?
>
> If not, we should probably use FW_WARN ?,
> or
> Should we add to the error message the specific firmware issue that might cause
> each of the functions to fail (e.g. amd_pstate_init_perf(), amd_pstate_init_freq(),
> etc).
I looked at the call paths and I'm not convinced that they will all be
firmware bugs. In any case I want to know whenever there is a failure
here so we can evaluate if it's a firmware bug or a software bug.
If it's a software bug we'll obviously work on it, and if it's a
firmware bug do our best to notify the firmware developer.
So I will abandon this patch, thanks for the great feedback.
>
> Comments for the macros, for reference,
>
> * FW_BUG
> * Add this to a message where you are sure the firmware is buggy or behaves
> * really stupid or out of spec. Be aware that the responsible BIOS developer
> * should be able to fix this issue or at least get a concrete idea of the
> * problem by reading your message without the need of looking at the kernel
> * code.
> *
> * Use it for definite and high priority BIOS bugs.
> *
> * FW_WARN
> * Use it for not that clear (e.g. could the kernel messed up things already?)
> * and medium priority BIOS bugs.
>
>> kfree(cpudata);
>> return ret;
>> }
>
© 2016 - 2025 Red Hat, Inc.