On 1/10/2024 8:41 AM, Kuppuswamy Sathyanarayanan wrote:
> Since your kernel has EDR source support, why not enable
> the relevant config? or did I not understand the issue correctly?
As I had said we never intend to use EDR or firmware controlled DPC. Why should
I have to build in more code that I wouldn't use? I'm not sure that we're
both using the same lense to consider how & whether _OSC DPC Control supports
the old world of DPC. i.e OS never required firmware's permission to control
DPC & it was not tied to EDR. I wish I had been working in this area at the
time they were drafting the 2019 FW ECN then I might have known to try & influence
its details.
I think the first & primary problem for the kernel here is not treating root
ports & switch ports the same when deciding to use DPC. I would like to hear
from Bjorn first, but I guess I could be open to just relying on the cli
pcie_ports=dpc-native field if there is reason for the kernel to only support
the latest additions of the PCIe FW DPC ECN by default. In this case the patch
would look as the one in Bjorns response on Dec 28 2023 at 1:23PM, included
again below. We may find others who are using Root Port DPC now needing to
change their config to support EDR or use the cli pcie_ports=dpc-native as
a result however.
If this is the route that makes the most sense, I can update my patch & resubmit
as below if that is ok. Perhaps there might also be some docs/notes to be created
around all of this.
-Matt
diff --git a/drivers/pci/pcie/portdrv.c b/drivers/pci/pcie/portdrv.c
index 14a4b89a3b83..423dadd6727e 100644
--- a/drivers/pci/pcie/portdrv.c
+++ b/drivers/pci/pcie/portdrv.c
@@ -262,7 +262,7 @@ static int get_port_device_capability(struct pci_dev *dev)
*/
if (pci_find_ext_capability(dev, PCI_EXT_CAP_ID_DPC) &&
pci_aer_available() &&
- (pcie_ports_dpc_native || (services & PCIE_PORT_SERVICE_AER)))
+ (pcie_ports_dpc_native || host->native_dpc))
