[lkml]   [2019]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH] ACPI / processors: allow a processor device _UID to be a string
On 6/11/19 6:53 AM, Sudeep Holla wrote:
> 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

Harumph. I think what we have here is a big mess in the spec, but
that is exactly why this is an RFC.

The MADT can have any of ~16 different subtables, as you note. Of
those, only these require a numeric _UID:

-- Type 0x0: Processor Local APIC
-- Type 0x4: Local APIC NMI [0]
-- Type 0x7: Processor Local SAPIC [1]
-- Type 0x9: Processor Local x2APIC
-- Type 0xa: Local x2APIC NMI [0]
-- Type 0xb: GICC

Note [0]: a value of !0x0 is also allowed, indicating all processors
[1]: this has two fields that could be interpreted as an ID when
used together

It does not appear that you could build a usable system without any
of these subtables -- but perhaps someone knows of incantations that
could -- which is why I thought a string _UID might be viable.

If we consider the PPTT too, then yeah, _UID must be an integer for
some devices.

Thanks for the feedback; it forced me to double-check my thinking about
the MADT. The root cause of the issue is not the kernel in this case,
but a lack of clarity in the spec -- or at least implied requirements
that probably need to be explicit. I'll send in a spec change.

Al Stone
Software Engineer
Red Hat, Inc.

 \ /
  Last update: 2019-06-11 18:05    [W:0.125 / U:1.496 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site