On Sat, Feb 10, 2018 at 09:08:42AM +0100, Rafael J. Wysocki wrote: > On Sat, Feb 10, 2018 at 2:05 AM, Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote: > > On Fri, Feb 09, 2018 at 02:56:43PM -0800, 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" does not need to > >> be in kernel messages all the time but only when debug is enabled. > > > > I agree and would even go further: _PRS is optional and I don't think > > there's a reason to log anything at all if it's absent. A log message > > like "failed to evaluate _PRS" makes people think something is wrong > > when in fact nothing is wrong. > > _PRS is required if the link object is pointed to by a _PRT entry. The closest thing I see with a quick look is ACPI 6.0, sec 6.2.13: These objects [PCI Interrupt Link Devices] have _PRS, _CRS, _SRS, and _DIS control methods to allocate the interrupt. I don't read that as a requirement for _PRS in particular; I read it as saying that the interrupt link devices use the normal device configuration method, i.e., _CRS is required and _PRS and _SRS are optional and needed for configurable devices but not for static ones. But this is just a drive-by comment and I'm really fine with whatever you decide to do. > > That leads to the mindset of treating a missing _PRS as an error when > > it's not. In fact, it looks like acpi_pci_link_add() *does* treat > > this as an error. If _PRS doesn't exist, it skips the _CRS > > evaluation. That seems wrong. > > I agree here. _CRS still should be evaluated if _PRS is not there in > general, but in some cases the lack of _PRS *is* an error.
