Linux Power Management development
 help / color / mirror / Atom feed
From: Sumit Gupta <sumitg@nvidia.com>
To: Christian Loehle <christian.loehle@arm.com>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	Viresh Kumar <viresh.kumar@linaro.org>
Cc: linux-pm@vger.kernel.org, linux-acpi@vger.kernel.org,
	linux-kernel@vger.kernel.org, Len Brown <lenb@kernel.org>,
	Jie Zhan <zhanjie9@hisilicon.com>,
	Lifeng Zheng <zhenglifeng1@huawei.com>,
	Pierre Gondois <pierre.gondois@arm.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Ionela Voinescu <ionela.voinescu@arm.com>,
	zhongqiu.han@oss.qualcomm.com, stable@vger.kernel.org
Subject: Re: [PATCHv2 1/3] ACPI: CPPC: Reject desired_perf reads on ACPI 6.6+
Date: Sat, 1 Aug 2026 02:22:55 +0530	[thread overview]
Message-ID: <3945845a-af6a-4d24-9821-a3925a030301@nvidia.com> (raw)
In-Reply-To: <20260729100245.2628302-2-christian.loehle@arm.com>


On 29/07/26 15:32, Christian Loehle wrote:
> External email: Use caution opening links or attachments
>
>
> When CPPC feedback counters cannot provide a usable sample, cppc-cpufreq
> calls cppc_get_desired_perf() because some platforms repurpose Desired
> Performance to report actual delivered performance.
>
> The fallback was added for platforms on which Desired Performance reflects
> delivered performance. ACPI 6.6 defines the register as write-only, so
> invoking that workaround on an ACPI 6.6 or later platform would require an
> invalid register read.
>
> Make cppc_get_desired_perf() return -EOPNOTSUPP in that case. Its caller
> already handles an error by using the cached desired-performance value.
> When checking the FADT minor revision, mask off its upper errata-generation
> bits and compare only the specification minor version.
>
> Fixes: c47195631960 ("cppc_cpufreq: Use desired perf if feedback ctrs are 0 or unchanged")
> Cc: stable@vger.kernel.org
> Signed-off-by: Christian Loehle <christian.loehle@arm.com>
> ---
>   drivers/acpi/cppc_acpi.c | 15 ++++++++++++++-
>   1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
> index 53d09ca98f06..6e5381f8de38 100644
> --- a/drivers/acpi/cppc_acpi.c
> +++ b/drivers/acpi/cppc_acpi.c
> @@ -1316,15 +1316,28 @@ static int cppc_set_reg_val(int cpu, enum cppc_regs reg_idx, u64 val)
>          return cpc_write(cpu, reg, val);
>   }
>
> +static bool cppc_desired_perf_readable(void)
> +{
> +       u8 minor_revision = acpi_gbl_FADT.minor_revision & 0x0f;
> +
> +       return acpi_gbl_FADT.header.revision < 6 ||
> +              (acpi_gbl_FADT.header.revision == 6 && minor_revision < 6);
> +}
> +

A platform whose _CPC follows ACPI 6.6 semantics but whose FADT still
reports 6.5 would pass this check as readable. If the register read
returns zero, cppc_cpufreq_get_rate() reports 0 kHz and policy online
fails with:
   cpufreq: cpufreq_policy_online: ->get() failed

Since the FADT version cannot be fully relied upon, would it make sense
to also harden the consumer? Although zero is valid Desired Performance
value, it is not usable as a frequency estimate.
So, cppc_cpufreq_get_rate() could fall back to the cached OSPM request:

   -    if (cppc_get_desired_perf(cpu, &delivered_perf))
   +    if (cppc_get_desired_perf(cpu, &delivered_perf) || !delivered_perf)
             delivered_perf = cpu_data->perf_ctrls.desired_perf;

Thanks,
Sumit


>   /**
>    * cppc_get_desired_perf - Get the desired performance register value.
>    * @cpunum: CPU from which to get desired performance.
>    * @desired_perf: Return address.
>    *
> - * Return: 0 for success, -EIO otherwise.
> + * Return: 0 for success, -EOPNOTSUPP for ACPI 6.6 or later, and a negative
> + * errno otherwise.
>    */
>   int cppc_get_desired_perf(int cpunum, u64 *desired_perf)
>   {
> +       /* ACPI 6.6 no longer specifies Desired Performance as readable. */
> +       if (!cppc_desired_perf_readable())
> +               return -EOPNOTSUPP;
> +
>          return cppc_get_reg_val(cpunum, DESIRED_PERF, desired_perf);
>   }
>   EXPORT_SYMBOL_GPL(cppc_get_desired_perf);
> --
> 2.34.1
>

  parent reply	other threads:[~2026-07-31 20:53 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-29 10:02 [PATCHv2 0/3] ACPI: CPPC: Avoid Desired Performance reads on ACPI 6.6+ Christian Loehle
2026-07-29 10:02 ` [PATCHv2 1/3] ACPI: CPPC: Reject desired_perf " Christian Loehle
2026-07-31 10:45   ` Zhongqiu Han
2026-08-03  9:12     ` Christian Loehle
2026-07-31 20:52   ` Sumit Gupta [this message]
2026-07-29 10:02 ` [PATCHv2 2/3] ACPI: CPPC: Skip desired_perf read in cppc_get_perf() Christian Loehle
2026-07-31 12:38   ` Zhongqiu Han
2026-07-29 10:02 ` [PATCHv2 3/3] ACPI: CPPC: Stop reading desired_perf " Christian Loehle
2026-07-31 13:19   ` Zhongqiu Han
2026-08-03 10:02 ` [PATCH v3 0/3] ACPI: CPPC: Avoid Desired Performance reads on ACPI 6.6+ Christian Loehle
2026-08-03 10:02   ` [PATCH v3 1/3] ACPI: CPPC: Reject desired_perf " Christian Loehle
2026-08-03 14:38     ` Rafael J. Wysocki (Intel)
2026-08-03 14:44       ` Christian Loehle
2026-08-03 10:02   ` [PATCH v3 2/3] ACPI: CPPC: Skip desired_perf read in cppc_get_perf() Christian Loehle
2026-08-03 14:43     ` Rafael J. Wysocki (Intel)
2026-08-03 10:02   ` [PATCH v3 3/3] ACPI: CPPC: Stop reading desired_perf " Christian Loehle
2026-08-03 13:07   ` [PATCH v3 0/3] ACPI: CPPC: Avoid Desired Performance reads on ACPI 6.6+ Sumit Gupta

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3945845a-af6a-4d24-9821-a3925a030301@nvidia.com \
    --to=sumitg@nvidia.com \
    --cc=christian.loehle@arm.com \
    --cc=ionela.voinescu@arm.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=pierre.gondois@arm.com \
    --cc=rafael@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=sudeep.holla@arm.com \
    --cc=viresh.kumar@linaro.org \
    --cc=zhanjie9@hisilicon.com \
    --cc=zhenglifeng1@huawei.com \
    --cc=zhongqiu.han@oss.qualcomm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox