Re: [RFC PATCH] ACPI / processors: allow a processor device _UID to be a string

[Sudeep Holla <sudeep.holla@arm.com>]

On Mon, Jun 10, 2019 at 02:07:34PM -0600, Al Stone wrote:
> In the ACPI specification, section 6.1.12, a _UID may be either an
> integer or a string object.  Up until now, when defining processor
> Device()s in ACPI (_HID ACPI0007), only integers were allowed even
> though this ignored the specification.  As a practical matter, it
> was not an issue.
>
> Recently, some DSDTs have shown up that look like this:
>
>   Device (XX00)
>   {
> 	Name (_HID, "ACPI0007" /* Processor Device */)
>         Name (_UID, "XYZZY-XX00")
>         .....
>   }
>
> which is perfectly legal.  However, the kernel will report instead:
>

I am not sure how this can be perfectly legal from specification
perspective. It's legal with respect to AML namespace but then the
other condition of this matching with entries in static tables like
MADT is not possible where there are declared to be simple 4 byte
integer/word. Same is true for even ACPI0010, the processor container
objects which need to match entries in PPTT,

ACPI Processor UID(in MADT): The OS associates this GICC(applies even
for APIC and family) Structure with a processor device object in
the namespace when the _UID child object of the processor device
evaluates to a numeric value that matches the numeric value in this
field.

So for me that indicates it can't be string unless you have some ways to
match those _UID entries to ACPI Processor ID in MADT and PPTT.

Let me know if I am missing to consider something here.

--
Regards,
Sudeep