If not, at least make the user know of potential deficiencies in the
table.
How ? What are your suggestions ? Does adding a warning or note that UID
is missing and offset is chosen help ?
I'd say so. I know now, but let's save others the potential hassle.
And having this debate again.
I am kind of fine with that.
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");
Level will probably never be PPTT_ABORT_PACKAGE, so.. you probably have
to have the warning higher up when it terminates the package search.
OTOH, just because this is set doesn't mean you get "nice" ids. I've had
complaints, because there is a firmware floating around which uses the
MPIDR value as the processor_id, so the cores come out with really weird
numbers too.
JFYI, we got this working now (PPTT has proper physical package ID):
root@(none)$ pwd
/sys/devices/system/cpu/cpu0/topology
root@(none)$ more package_cpus_list
0-63
root@(none)$ more physical_package_id
0
root@(none)$ cd ../../cpu64/topology
root@(none)$ more package_cpus_list
64-127
root@(none)$ more physical_package_id
1
root@(none)$
We'll share the FW tables when ready, so you can check what we have done.
BTW, I still think that we can look to add the warning message when
physical processor package id valid is not set
Cheers,
John
return ACPI_PTR_DIFF(cpu_node, table);
}
pr_warn_once("PPTT table found, but unable to locate core %d
(%d)\n",
Thanks,
John
.
