Re: [Bug 215560] New: _PRS/_SRS methods should be optional

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux