On Thursday, February 1, 2018 9:07:59 AM CET Alex Hung wrote: > On Wed, Jan 31, 2018 at 11:30 PM, Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote: > > On Thu, Feb 1, 2018 at 5:39 AM, Alex Hung <alex.hung@xxxxxxxxxxxxx> wrote: > >> 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. > > > > OK > > > >> 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. > > > > I'm not sure what you mean here. > > > > Do you mean that the code would mishandle 0 in the Source field of _PRT? > > I meant the AE_NOT_FOUND messages still pop up when SOURCE = 0. OK, so why does the firmware define the link objects in the namespace then? > Do you have other comments about this patch or concerns that I can work > with firmware engineers? It looks to me that there are some PCI interrupt link objects in the namespace without _PRS and which aren't pointed to by any _PRT entries. If so, what are they useful for then? We sure may ignore such things, but the patch makes us ignore cases that are outright invalid too AFAICS. Thanks, Rafael -- 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
