Hello, The freeze was a platform issue, it's fixed and things are working as expected. Using this patch from "Matthew W Carlis <mattc@xxxxxxxxxxxxxxx>", will this patch be merged in future ? https://patchwork.ozlabs.org/project/linux-pci/patch/20231223212235.34293-2-mattc@xxxxxxxxxxxxxxx/ diff --git a/drivers/pci/pcie/portdrv.c b/drivers/pci/pcie/portdrv.c index 14a4b89a3b83..8e023aa97672 100644 --- a/drivers/pci/pcie/portdrv.c +++ b/drivers/pci/pcie/portdrv.c @@ -257,12 +257,19 @@ static int get_port_device_capability(struct pci_dev *dev) } /* + * _OSC AER Control is required by the OS & requires OS to control AER, + * but _OSC DPC Control isn't required by the OS to control DPC; however + * it does require the OS to control DPC. _OSC DPC Control also requres + * _OSC EDR Control (Error Disconnect Recovery) (PCI Firmware - DPC ECN rev3.2) + * PCI_Express_Base 6.1, 6.2.11 Determination of DPC Control recommends + * platform fw or OS always link control of DPC to AER. + * * With dpc-native, allow Linux to use DPC even if it doesn't have * permission to use AER. */ if (pci_find_ext_capability(dev, PCI_EXT_CAP_ID_DPC) && - pci_aer_available() && - (pcie_ports_dpc_native || (services & PCIE_PORT_SERVICE_AER))) + pci_aer_available() && (pcie_ports_dpc_native || + (dev->aer_cap && host->native_aer))) services |= PCIE_PORT_SERVICE_DPC; if (pci_pcie_type(dev) == PCI_EXP_TYPE_DOWNSTREAM || On Mon, 7 Oct 2024 at 22:15, Maverickk 78 <maverickk1778@xxxxxxxxx> wrote: > > Very helpful! > > Yes, bios doesn't support hotplug or dpc. > > I used the patches listed in previous mail to enable both dpc & pciehp with command line Param "pcie_port=native" > > Hotplug works fine, but dpc trigger after hotplug causes complete freeze, I suspect platform issue, may be issue with backdoor mechanism of hotplug is causing it, will inspect and come back. > > > On Sat, 5 Oct 2024, 03:27 Bjorn Helgaas, <helgaas@xxxxxxxxxx> wrote: >> >> On Fri, Oct 04, 2024 at 11:50:28PM +0530, Maverickk 78 wrote: >> > The platform I am working on is rtl simulation of pcie switch(Gen6) >> > with a backdoor mechanism to trigger the HotPlug event. >> > >> > Tried following patches independently to have both hotplug and dpc >> > driver register and handle respective events. >> > >> > https://patchwork.ozlabs.org/project/linux-pci/patch/20231223212235.34293-2-mattc@xxxxxxxxxxxxxxx/ >> > https://patchwork.kernel.org/project/linux-pci/patch/20240108194642.30460-1-mattc@xxxxxxxxxxxxxxx/#25680870 >> > >> > Tried following >> > >> > - Trigger hot removal and add, the event is triggered and respective >> > msi in /proc/interrupt increments and kernel logs the event(dmesg) >> > - Trigger hot removal and add, the event is triggered and respective >> > msi in /proc/interrupt increments and kernel logs the event(dmesg) >> > - Trigger DPC using "DPC software trigger" in DPC control register >> > >> > The kernel hangs, the console is non-responsive. >> > >> > Can dpc and pciehp co-exist and handle the events? >> >> Yes, they're intended to coexist. Your platform firmware doesn't >> advertise support for it, though: >> >> [ 1.736168] acpi PNP0A08:00: _OSC: platform does not support [PCIeHotplug LTR DPC] >> >> I don't think there's a kernel parameter to force DPC usage if the >> platform doesn't advertise it. There should be a message like "DPC: >> enabled with IRQ X" if the dpc driver is active. >> >> Even if the dpc driver isn't active, I don't think the kernel should >> hang if you trigger DPC. Since this is a QEMU guest, you should be >> able to use a debugger to figure out why it's hung. >> >> Bjorn
