Re: [PATCH 1/1] PCI/portdrv: Allow DPC if the OS controls AER natively.

[Bjorn Helgaas <helgaas@kernel.org>]

On Tue, Jan 23, 2024 at 04:18:34PM -0700, Matthew W Carlis wrote:
> Hello again! I'm glad that I'm not the only person with a little
> confusion about the FW ECN regarding DPC/EDR. I would argue that DPC
> wasn't tied to EDR & shouldn't have been because DPC was added in
> PCI Base Spec Rev 3.1 in 2014, but there wasn't an EDR ECN till
> ~2020. Anyway, that's the way it goes..

It does involve several different specs (PCIe Base for the DPC
hardware feature, ACPI for the OS/firmware EDR interface, PCI Firmware
for the EDR support and DPC ownership negotiation), so maybe that
helps explain the muddle.

> I don't want to burden the kernel with making some impossible boot
> time decision here. Perhaps most of the machines in the world using
> DPC will soon use EDR/SFI etc. My use cases are a bit out of the
> ordinary & the ACPI specifications don't seem to have given us a
> mechanism for the kernel to conclude it can use DPC without EDR
> support...

I don't know anything about SFI and I don't see any required
connection between DPC/EDR/SFI in the PCI Firmware spec.

The PCI Firmware spec requires ACPI OSes to support EDR if they want
to use DPC.  But I don't know that the firmware is required to
actually implement the EDR functionality.

Non-ACPI OSes are presumed to own DPC and all other PCIe hardware
features, and I don't think EDR would be in the picture since it's an
ACPI thing.

> Shall I submit a patch removing CONFIG_PCIE_EDR? Perhaps the
> exercise would inform me about whether its code should be in
> CONFIG_PCIE_DPC or CONFIG_ACPI.

That would be great!  I would say CONFIG_PCIE_EDR should go away and
edr.c should only be compiled if CONFIG_PCIE_DPC=y and CONFIG_ACPI=y.

Bjorn