]> git.kernelconcepts.de Git - karo-tx-linux.git/commit
ACPI / PCI: Account for ARI in _PRT lookups
authorAlex Williamson <alex.williamson@redhat.com>
Tue, 26 May 2015 21:11:51 +0000 (15:11 -0600)
committerBjorn Helgaas <bhelgaas@google.com>
Sun, 31 May 2015 01:47:35 +0000 (20:47 -0500)
commit917bfd93d3c9c644743940deaf8fe0cff77947eb
tree15e0198c1a418778dd6f0d4453fd974dfbed5f08
parent19bdb6e4ec071bc49a9871b41e6a59a1657ed365
ACPI / PCI: Account for ARI in _PRT lookups

The PCIe specification, rev 3.0, section 2.2.8.1, contains the following
implementation note:

  Virtual Wire Mapping for INTx Interrupts From ARI Devices

  The implied Device Number for an ARI Device is 0.  When ARI-aware
  software (including BIOS and operating system) enables ARI Forwarding in
  the Downstream Port immediately above an ARI Device in order to access
  its Extended Functions, software must comprehend that the Downstream Port
  will use Device Number 0 for the virtual wire mappings of INTx interrupts
  coming from all Functions of the ARI Device.  If non-ARI-aware software
  attempts to determine the virtual wire mappings for Extended Functions,
  it can come up with incorrect mappings by examining the traditional
  Device Number field and finding it to be non-0.

We account for this in pci_swizzle_interrupt_pin(), but it looks like we
miss it here, looking for a _PRT entry with a slot matching the ARI device
slot number.  This can cause errors like:

  pcieport 0000:80:03.0: can't derive routing for PCI INT B
  sfc 0000:82:01.1: PCI INT B: no GSI

pci_dev.irq is then invalid, resulting in errors for drivers that attempt
to enable INTx on the device.  Fix by using slot 0 for ARI enabled devices.

Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Don Dutile <ddutile@redhat.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
drivers/acpi/pci_irq.c