From: Christian Loehle <christian.loehle@arm.com>
To: "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>,
Sumit Gupta <sumitg@nvidia.com>,
Sudeep Holla <sudeep.holla@arm.com>,
Ionela Voinescu <ionela.voinescu@arm.com>,
zhongqiu.han@oss.qualcomm.com
Subject: Re: [PATCH v7 15/20] ACPI: CPPC: Keep Performance Limited clearable on NVIDIA T41
Date: Thu, 17 Sep 2026 13:59:36 +0100 [thread overview]
Message-ID: <9ad67536-7b6e-4633-8cc7-52b0d68196fc@arm.com> (raw)
In-Reply-To: <20260916162805.1039247-16-christian.loehle@arm.com>
On 9/16/26 17:28, Christian Loehle wrote:
> From: Sumit Gupta <sumitg@nvidia.com>
>
> NVIDIA T41 firmware describes Performance Limited as a two-bit field at
> offset zero in a DWord SystemMemory access unit. Generic CPPC code must
> keep such a field read-only because preserving the remainder when clearing
> it requires a read-modify-write which cannot be interlocked with platform
> updates.
>
> The remaining bits of this access unit are unimplemented on T41: they read
> as zero, writes have no side effects, and no other register uses them. The
> Performance Limited register therefore owns the complete access unit, but
> shipped firmware does not describe that property accurately.
>
> Add a CPPC platform-quirk table keyed by the DSDT header and carry quirk
> behavior through explicit flags. Cache a successful table lookup, copy each
> GAS into the driver's private descriptor, and apply fixups before layout
> validation, mapping and overlap registration.
>
> Distinguish a genuine non-match from a table-header lookup failure in
> acpi_match_platform_list(). Propagate lookup errors from CPPC probe without
> caching them, so a transient mapping failure cannot disable the workaround
> for every later processor. Existing matcher callers still treat all
> negative results as no match.
>
> For the known T41 layout only, widen a two-bit Performance Limited field at
> offset zero to its 32-bit access width. Clearing both status bits can then
> be issued as one DWord write of zero without a stale read. Corrected
> firmware which reports the full width is unchanged. The workaround
> therefore lapses automatically when corrected firmware ships.
>
> Link: https://lore.kernel.org/lkml/d5f1ea9b-53b7-4db2-983a-b5be8e71a371@arm.com/
> Signed-off-by: Sumit Gupta <sumitg@nvidia.com>
> [ Rework quirk matching and fixup placement; propagate lookup failures
> without caching them. ]
> Signed-off-by: Christian Loehle <christian.loehle@arm.com>
> ---
> drivers/acpi/cppc_acpi.c | 72 ++++++++++++++++++++++++++++++++++++++++
> drivers/acpi/utils.c | 13 ++++++--
> 2 files changed, 82 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
> index 6d130381245e..0e218f2be0fe 100644
> --- a/drivers/acpi/cppc_acpi.c
> +++ b/drivers/acpi/cppc_acpi.c
> @@ -330,6 +330,68 @@ static unsigned int cpc_reg_access_width(const struct cpc_reg *reg)
> return reg->bit_width;
> }
>
> +enum cpc_platform_quirk {
> + CPC_QUIRK_PERF_LIMITED_OWNS_UNIT = BIT(0),
> +};
> +
> +static const struct acpi_platform_list cpc_platform_quirk_list[] = {
> + {
> + .oem_id = "NVIDIA",
> + .oem_table_id = "T41",
Sashiko:
"Will this quirk successfully match a standard ACPI table header?
The ACPI specification requires the OEM Table ID to be exactly 8 bytes long,
typically padded with trailing spaces by compliant firmware (e.g.,
"T41 ").
Looking at acpi_match_platform_list(), it compares the IDs using:
strncmp(plat->oem_table_id, hdr.oem_table_id, ACPI_OEM_TABLE_ID_SIZE)
Because "T41" is a null-terminated 3-character string, strncmp() will
compare the 4th character ('\0' from the quirk definition vs ' ' from the
ACPI table header) and immediately report a mismatch, causing the quirk to
silently fail on compliant firmware.
Should this be padded with spaces (e.g., "T41 ") to ensure it matches
the firmware's table correctly?"
non-padded "T41" matches exactly what Sumit proposed and was discussed in v6:
https://lore.kernel.org/lkml/55a5c9fa-cfd3-4000-b3cc-52c343841c9f@nvidia.com/
So once Sumit adds Tested-by: this should be fine.
>[snip]
next prev parent reply other threads:[~2026-09-17 12:59 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-16 16:27 [PATCH v7 0/20] ACPI: CPPC: Fix register access and lifetime bugs Christian Loehle
2026-09-16 16:27 ` [PATCH v7 01/20] ACPI: CPPC: Validate the _CPC package header Christian Loehle
2026-09-16 16:27 ` [PATCH v7 02/20] ACPI: CPPC: Validate _CPC entry and control semantics Christian Loehle
2026-09-17 10:26 ` Christian Loehle
2026-09-16 16:27 ` [PATCH v7 03/20] ACPI: CPPC: Propagate performance-control write errors Christian Loehle
2026-09-16 16:27 ` [PATCH v7 04/20] ACPI: CPPC: Serialize PCC single-register payload updates Christian Loehle
2026-09-16 16:27 ` [PATCH v7 05/20] ACPI: CPPC: Serialize PCC EPP " Christian Loehle
2026-09-16 16:27 ` [PATCH v7 06/20] ACPI: CPPC: Release CPC descriptors through kobject Christian Loehle
2026-09-16 16:27 ` [PATCH v7 07/20] ACPI: CPPC: Release PCC data after probe failures Christian Loehle
2026-09-16 16:27 ` [PATCH v7 08/20] ACPI: CPPC: Reject unsafe cross-CPU SystemMemory RMW Christian Loehle
2026-09-16 16:27 ` [PATCH v7 09/20] ACPI: CPPC: Reject direct reads of write-only controls Christian Loehle
2026-09-16 16:27 ` [PATCH v7 10/20] ACPI: CPPC: Validate and access PCC register layouts Christian Loehle
2026-09-16 16:27 ` [PATCH v7 11/20] ACPI: CPPC: Validate SystemIO " Christian Loehle
2026-09-16 16:27 ` [PATCH v7 12/20] ACPI: CPPC: Validate PCC overlaps across processors Christian Loehle
2026-09-16 16:27 ` [PATCH v7 13/20] ACPI: CPPC: Validate SystemIO " Christian Loehle
2026-09-16 16:27 ` [PATCH v7 14/20] ACPI: CPPC: Clear Performance Limited without a stale read Christian Loehle
2026-09-16 16:28 ` [PATCH v7 15/20] ACPI: CPPC: Keep Performance Limited clearable on NVIDIA T41 Christian Loehle
2026-09-17 12:59 ` Christian Loehle [this message]
2026-09-17 13:23 ` Rafael J. Wysocki (Intel)
2026-09-17 18:20 ` Sumit Gupta
2026-09-16 16:28 ` [PATCH v7 16/20] ACPI: CPPC: Validate FFH register fields before hardware access Christian Loehle
2026-09-16 16:28 ` [PATCH v7 17/20] ACPI: CPPC: Propagate errors from cross-CPU FFH calls Christian Loehle
2026-09-16 16:28 ` [PATCH v7 18/20] ACPI: CPPC: Accept requests to retain immutable autonomous selection Christian Loehle
2026-09-16 16:28 ` [PATCH v7 19/20] cpufreq: CPPC: Select the frequency-invariance callback per CPU Christian Loehle
2026-09-16 16:28 ` [PATCH v7 20/20] cpufreq: CPPC: Create the FIE worker before enabling PCC callbacks Christian Loehle
2026-09-17 18:30 ` [PATCH v7 0/20] ACPI: CPPC: Fix register access and lifetime bugs Sumit Gupta
2026-09-18 15:30 ` Rafael J. Wysocki (Intel)
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=9ad67536-7b6e-4633-8cc7-52b0d68196fc@arm.com \
--to=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=sudeep.holla@arm.com \
--cc=sumitg@nvidia.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
all inboxes | Powered by JetHome®