Hi Sathyanarayanan,

On Wed, 2020-04-22 at 15:48 -0700, Kuppuswamy, Sathyanarayanan wrote:

On 4/20/20 2:37 PM, Jon Derrick wrote:

quoted

Some platforms have a mix of ports whose capabilities can be negotiated
by _OSC, and some ports which are not described by ACPI and instead
managed by Native drivers. The existing Firmware-First HEST model can
incorrectly tag these Native, Non-ACPI ports as Firmware-First managed
ports by advertising the HEST Global Flag and matching the type and
class of the port (aer_hest_parse).

Is there a real use case for mixed mode (one host bridge in FF mode and
another in native)?

Intel's VMD exposes PCIe segments containing Root Ports and Bridges and
other DPC consumers. These extra PCIe domains aren't described by ACPI.
There have been a few versions where DPC won't bind due to platform's
HEST configuration.

quoted

If the port requests Native AER through the Host Bridge's capability
settings, the AER driver should honor those settings and allow the port
to bind. This patch changes the definition of Firmware-First to exclude
ports whose Host Bridges request Native AER.

Signed-off-by: Jon Derrick <redacted>
---
  drivers/pci/pcie/aer.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
index f4274d3..30fbd1f 100644
--- a/drivers/pci/pcie/aer.c
+++ b/drivers/pci/pcie/aer.c

@@ -314,6 +314,9 @@ int pcie_aer_get_firmware_first(struct pci_dev *dev)
  	if (pcie_ports_native)
  		return 0;
  
+	if (pci_find_host_bridge(dev->bus)->native_aer)
+		return 0;
+
  	if (!dev->__aer_firmware_first_valid)
  		aer_set_firmware_first(dev);
  	return dev->__aer_firmware_first;