Hi Pierre, Thanks a lot for the report! On Wed, Feb 02, 2022 at 10:20:44AM +0000, bugzilla-daemon@xxxxxxxxxx wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=215560 > > Bug ID: 215560 > Summary: _PRS/_SRS methods should be optional > Product: Drivers > Version: 2.5 > Kernel Version: v5.17-rc2 > Hardware: All > OS: Linux > Tree: Mainline > Status: NEW > Severity: enhancement > Priority: P1 > Component: PCI > Assignee: drivers_pci@xxxxxxxxxxxxxxxxxxxx > Reporter: pierre.gondois@xxxxxxx > Regression: No > > The PCI legacy interrupts can be described with link devices, cf ACPI 6.4, > s6.2.13 "_PRT (PCI Routing Table)". > Link devices can have optional _SRS/_PRS methods to set the interrupt. Is this a direct quote? I don't see text similar to this in ACPI v6.4. I do see this in sec 6.2.13: There are two ways that _PRT can be used. Typically, the interrupt input that a given PCI interrupt is on is configurable. For example, a given PCI interrupt might be configured for either IRQ 10 or 11 on an 8259 interrupt controller. In this model, each interrupt is represented in the ACPI namespace as a PCI Interrupt Link Device. These objects have _PRS, _CRS, _SRS, and _DIS control methods to allocate the interrupt. Then, OSPM handles the interrupts not as interrupt inputs on the interrupt controller, but as PCI interrupt pins. The driver looks up the device’s pins in the _PRT to determine which device objects allocate the interrupts. To move the PCI interrupt to a different interrupt input on the interrupt controller, OSPM uses _PRS, _CRS, _SRS, and _DIS control methods for the PCI Interrupt Link Device. 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. For the first model (configurable inputs), it says "These objects have _PRS, _CRS, _SRS, and _DIS," which could be read as requiring those objects. For the second model (hardwired inputs), the interrupts are not configurable, and I don't think there would be any reason to have an interrupt link device at all. > In PCI Firmware Specification Revision 3.3, s4.3.2.1. "Resource Setting": > """ > A non-configurable device only specifies _CRS. However, if they are > configurable, devices include > _PRS to indicate the possible resource setting and _SRS to allow OSPM to > specify a new resource > allocation for the device. > """ My copy of the PCI Firmware spec r3.3 (dated Jan 20, 2021), sec 4.3.2.1 says: Host bridges resources programming is communicated to the operating system using ACPI methods _CRS, _SRS, and _PRS. _CRS indicates the current resource setting for the host bridge. This includes I/O space, memory space, and bus range assigned to the bridge by platform firmware. A non-configurable device only specifies _CRS. However, if they are configurable, devices include _PRS to indicate the possible resource setting and _SRS to allow OSPM to specify a new resource allocation for the device. So this is specifically talking about methods of a PCI host bridge (PNP0A03 or PNP0A08), not about methods of an interrupt link device (PNP0C0F). > However, _PRS/_SRS methods are checked in drivers/acpi/pci_link.c, and the > driver aborts if they are absent. > E.g.: When _PRS is missing: > ACPI: \_SB_.PCI0.LNKA: _CRS 36 not found in _PRS > ACPI: \_SB_.PCI0.LNKA: No IRQ available. Try pci=noacpi or acpi=off I assume this bug report is because something isn't working. Can you update the bugzilla with a note about what specifically isn't working and also attach a complete dmesg log and acpidump? Bjorn
