Re: [PATCH 2/4] ACPI: PCC: Preserve shared memory signature in OpRegion handler

From: lihuisong (C)

Date: Tue Jul 21 2026 - 07:44:17 EST



On 7/17/2026 4:10 PM, Sudeep Holla wrote:
ACPI 6.3 introduced PCC OperationRegions. Section 5.5.2.4.7.3,
"Declaring message fields within a PCC OperationRegion", states that,
for all PCC subspace types, the PCC Operation Region pertains to the
region of PCC subspace that succeeds the PCC signature.

The PCC address space handler currently copies the OperationRegion
buffer to and from the start of the PCC shared memory region. That can
overwrite or expose the signature at byte offset 0, and it also misses
the last 4 bytes of the actual PCC OperationRegion data.

Offset OperationRegion copies by the size of the signature and reject
regions that do not fit in the shared memory after that signature. AML
that sizes the PCC OperationRegion to include the signature is not
conforming to the PCC OperationRegion definition.

Cc: "Rafael J. Wysocki" <rafael@xxxxxxxxxx>
Fixes: 77e2a04745ff ("ACPI: PCC: Implement OperationRegion handler for the PCC Type 3 subtype")
Signed-off-by: Sudeep Holla <sudeep.holla@xxxxxxxxxx>
---
The below commit description said the PCC operationRegion contains the signature field.
"77e2a04745ff ("ACPI: PCC: Implement OperationRegion handler for the PCC Type 3 subtype")"
And I find that the definition of this OperationRegion in ACPI spec 6.3 is the same with spec 6.5 and 6.6.
That is, the original implementation already didn't comply with ACPI spec.

Patch 1/4 also requires the change of platform AML about PCC OperationRegion.
These modification may lead to the existed PCC OperationRegion method in some drivers doesn't work.
Because the platform AML still contains signature field in PCC OperationRegion method.
I don't know how many drivers in linux have used this method.
IMO, we at least need to reclarify this usage change and provide a new usage example in the commit log like the original commit did.

Anyway, this patch also makes the driver more compliant with the specifications.
So I agree.
Reviewed-by: Huisong Li <lihuisong@xxxxxxxxxx>