Hi,
On 2/12/20 10:41 AM, John Garry wrote:
How about something like this:
--- a/drivers/acpi/pptt.c
+++ b/drivers/acpi/pptt.c
@@ -515,6 +515,8 @@ static int topology_get_acpi_cpu_tag(struct
acpi_table_header *table,
if (level == 0 || cpu_node->flags &
ACPI_PPTT_ACPI_PROCESSOR_ID_VALID)
return cpu_node->acpi_processor_id;
+ if (level == PPTT_ABORT_PACKAGE)
+ pr_warn_once("ACPI Processor ID valid not set for physical
package node, will use node table offset as substitute for UID\n");
Hi Jeremy,
To clarify my other email there, since I can't seem to type clearly..
Just note that find_acpi_cpu_topology_hetero_id() is also using a
PPTT_ABORT_PACKAGE termination.
OK, so I may need to check the flag == ACPI_PPTT_PHYSICAL_PACKAGE also.
Without a lot of thought, it probably sufficient to only check the flag.
The level is mostly noise, the ==0 check in there was to work around the
verbiage in the first PPTT revision.
BTW, Is the value returned by find_acpi_cpu_topology_hetero_id() also > exposed to userspace some way? Or any other PPTT offsets?
Not yet :)
return ACPI_PTR_DIFF(cpu_node, table);
}
pr_warn_once("PPTT table found, but unable to locate core %d
(%d)\n",
I'll validate Sudeep's suggestion to set the Processor ID valid flag and
appropriate processor id for the physical package cpu node with an
experimental firmware before sending any patch. There seems to be a bit
of doubt on your part regarding that.
Just pay attention to the definition of _UID/Acpi Processor UID, etc.
The MADT says that ACPI processor UID is matched with a processor
container with a matching numeric _UID. The processor container
definition says that the _UID must be unique in the processor container
hierarchy.
To me, this says that processor containers/ACPI processors UIDs must all
be unique. AKA, you can't have both a processor with _UID=1 and a socket
with _UID=1. Given that linux isn't matching the socket _UID, you can
create a PPTT+DSDT that does what you want but likely violates the spec.
