On Wed, Jan 31, 2018 at 1:20 AM, Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> wrote:
> On Wednesday, January 31, 2018 6:52:19 AM CET Alex Hung wrote:
>> In recent Intel hardware the IRQs become non-configurable after BIOS
>> initializes them in PEI phase and _PRS objects are no longer included in
>> ASL.
>>
>> This is the same as "static (non-configurable) devices do not
>> specify a _PRS object" in ACPI spec. As a result, error messages
>> saying "ACPI Exception: AE_NOT_FOUND, Evaluating _PRS" are not
>> needed.
>
> That's questionable at best.
>
> The errors basically indicate that _PRT entries corresponding to these
> IRQs are messed up (because they should contain the value of 0 instead of
> a NamePath in the Source column), so we are now going to paper over bugs
> in ACPI tables as someone in the firmware land cannot be bothered with
> putting correct values into them. :-/
Rafael,
Thanks for quick reply and sharing the information
It seems static (non-configurable) devices on ACPI are discussed in
both _PRS and _PRT as below:
6.2.12 _PRS (Possible Resource Settings)
"... Static (non-configurable) devices do not specify a _PRS object... "
6.2.13 _PRT (PCI Routing Table)
"In the second model, the PCI interrupts are hardwired to specific
interrupt inputs on the interrupt controller and are not configurable.
In this case, the Source field in _PRT does not reference a device,
but instead contains the value zero, and the Source Index field
contains the global system interrupt to which the PCI interrupt is
hardwired."
My interpretation is the both are true from ACPI's perspective, and
both should be implemented by system firmware. On this particular
system I am debugging remotely, it does the _PRS part but not _PRT,
and I will follow up with firmware engineers.
On the other hand, it may not be unreasonable to remove AE_NOT_FOUND
as defined in 6.2.12 in ACPI spec. I also did a code trace and it
seems that the AE_NOT_FOUND in _PRS cannot be removed by a value of
zero in Source field in _PRT.
Finally, this seems to be a confusing topic in ACPI spec (to the
firmware engineers and I at least). If we can figure this out, we may
want to clarify the wording with ASWG.
>
>> Signed-off-by: Alex Hung <alex.hung@xxxxxxxxxxxxx>
>> ---
>> drivers/acpi/pci_link.c | 4 +---
>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
>> index 85ad679390e3..f98215971f30 100644
>> --- a/drivers/acpi/pci_link.c
>> +++ b/drivers/acpi/pci_link.c
>> @@ -172,10 +172,8 @@ static int acpi_pci_link_get_possible(struct acpi_pci_link *link)
>>
>> status = acpi_walk_resources(link->device->handle, METHOD_NAME__PRS,
>> acpi_pci_link_check_possible, link);
>> - if (ACPI_FAILURE(status)) {
>> - ACPI_EXCEPTION((AE_INFO, status, "Evaluating _PRS"));
>> + if (ACPI_FAILURE(status))
>> return -ENODEV;
>> - }
>>
>> ACPI_DEBUG_PRINT((ACPI_DB_INFO,
>> "Found %d possible IRQs\n",
>>
>
>
--
Cheers,
Alex Hung
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
