On Mon, Feb 12, 2018 at 9:51 AM, Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote: > On Sat, Feb 10, 2018 at 4:34 PM, Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote: >> 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. > > Well, that's slightly out of context. :-) > > First of all, Section 6.2.13 says this: "Typically, the interrupt > input that a given PCI interrupt is on is configurable. [...] In this > model, each interrupt is represented in the ACPI namespace as a PCI > Interrupt Link Device." Then, it says the above. > > Now, if _PRS is not present, the IRQ represented by the link object > cannot be configured, so in fact the underlying assumption doesn't > apply to it, strictly speaking. It follows from the last paragraph in > Section 6.2.13 that _PRT entries representing such IRQs should not > point to interrupt link device objects (there should be 0 in their > Source fields). > > Hence, if a _PRT entry points to an interrupt link device object in > the namespace, _PRS should be present under this object or at least it > is reasonable to expect that it will be present in there. > >> But this is just a drive-by comment and I'm really fine with whatever >> you decide to do. > > OK > > So I think that (a) the message should be printed using > acpi_handle_debug(), except that I would make it slightly more > neutral, something like "_PRS not present or invalid", and (b) 0 > should be returned instead of -ENODEV when _PRS evaluation doesn't > succeed. But then, of course, we may not want to evaluate _DIS on this link and I'm not quite sure if adding it to acpi_link_list makes sense then. -- 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
