Message-ID: <0dfa99bf-7527-9dc3-201e-a482057fd51c@redhat.com>
Date:   Tue, 11 Jun 2019 10:27:41 -0600
From:   Al Stone <ahs3@...hat.com>
To:     Sudeep Holla <sudeep.holla@....com>
Cc:     linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] ACPI / processors: allow a processor device _UID to
 be a string

On 6/11/19 10:11 AM, Sudeep Holla wrote:
> On Tue, Jun 11, 2019 at 10:03:15AM -0600, Al Stone wrote:
>> 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.
>>
> 
> I hope no one is shipping such device yet or am I wrong ?
> We can ask them to fix as Linux simply can't boot on such system or
> even if it boots, it may have issues with acpi_processor drivers.

I don't think it's shipping, but even if it is, I'm going to have to
insist they fix their tables, just as a practical matter.  I need to
ask if it boots that other OS, too.

>> 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.
>>
> 
> Completely agreed. Even little more clarification on this is helpful.
> Thanks for volunteering :) to take up spec change, much appreciated.

No problem, and glad to do it.

-- 
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3@...hat.com
-----------------------------------

Powered by blists - more mailing lists