Adding Thomas. On Sat, 2 Nov 2024, Florian Fainelli wrote: > On 11/2/2024 9:53 AM, Stefan Wahren wrote: > > > > I tested linux-next-20241101 with the Raspberry Pi 4 (8 GB RAM, > > arm64/defconfig) and during boot the driver pcie_bwctrl fails to probe. > > Since this driver is very new, I assume this never worked before: > > > > [ 6.843802] brcm-pcie fd500000.pcie: host bridge /scb/pcie@7d500000 > > ranges: > > [ 6.843851] brcm-pcie fd500000.pcie: No bus range found for > > /scb/pcie@7d500000, using [bus 00-ff] > > [ 6.843900] brcm-pcie fd500000.pcie: MEM > > 0x0600000000..0x0603ffffff -> 0x00f8000000 > > [ 6.843940] brcm-pcie fd500000.pcie: IB MEM > > 0x0000000000..0x00bfffffff -> 0x0400000000 > > [ 6.859915] vchiq: module is from the staging directory, the quality > > is unknown, you have been warned. > > [ 6.885670] brcm-pcie fd500000.pcie: PCI host bridge to bus 0000:00 > > [ 6.885704] pci_bus 0000:00: root bus resource [bus 00-ff] > > [ 6.885725] pci_bus 0000:00: root bus resource [mem > > 0x600000000-0x603ffffff] (bus address [0xf8000000-0xfbffffff]) > > [ 6.885823] pci 0000:00:00.0: [14e4:2711] type 01 class 0x060400 PCIe > > Root Port > > [ 6.885858] pci 0000:00:00.0: PCI bridge to [bus 01] > > [ 6.885876] pci 0000:00:00.0: bridge window [mem > > 0x600000000-0x6000fffff] > > [ 6.885954] pci 0000:00:00.0: PME# supported from D0 D3hot > > [ 6.909911] pci_bus 0000:01: supply vpcie3v3 not found, using dummy > > regulator > > [ 6.910159] pci_bus 0000:01: supply vpcie3v3aux not found, using > > dummy regulator > > [ 6.910251] pci_bus 0000:01: supply vpcie12v not found, using dummy > > regulator > > [ 6.922254] mmc1: new high speed SDIO card at address 0001 > > [ 7.013175] brcm-pcie fd500000.pcie: clkreq-mode set to default > > [ 7.015309] brcm-pcie fd500000.pcie: link up, 5.0 GT/s PCIe x1 (SSC) > > [ 7.015526] pci 0000:01:00.0: [1106:3483] type 00 class 0x0c0330 PCIe > > Endpoint > > [ 7.015626] pci 0000:01:00.0: BAR 0 [mem 0x00000000-0x00000fff 64bit] > > [ 7.015954] pci 0000:01:00.0: PME# supported from D0 D3hot > > [ 7.062153] pci 0000:00:00.0: bridge window [mem > > 0x600000000-0x6000fffff]: assigned > > [ 7.062191] pci 0000:01:00.0: BAR 0 [mem 0x600000000-0x600000fff > > 64bit]: assigned > > [ 7.062221] pci 0000:00:00.0: PCI bridge to [bus 01] > > [ 7.062237] pci 0000:00:00.0: bridge window [mem > > 0x600000000-0x6000fffff] > > [ 7.062255] pci_bus 0000:00: resource 4 [mem 0x600000000-0x603ffffff] > > [ 7.062269] pci_bus 0000:01: resource 1 [mem 0x600000000-0x6000fffff] > > [ 7.062590] pcieport 0000:00:00.0: enabling device (0000 -> 0002) > > [ 7.062812] pcieport 0000:00:00.0: PME: Signaling with IRQ 39 > > [ 7.072890] pcieport 0000:00:00.0: AER: enabled with IRQ 39 > > [ 7.091767] v3d fec00000.gpu: [drm] Using Transparent Hugepages > > [ 7.124274] genirq: Flags mismatch irq 39. 00002084 (PCIe bwctrl) vs. > > 00200084 (PCIe PME) > > [ 7.124391] pcie_bwctrl 0000:00:00.0:pcie010: probe with driver > > pcie_bwctrl failed with error -16 > > Yes this is a new failure for sure. So PME requests the interrupt line with > IRQF_TRIGGER_HIGH | IRQF_SHARED | IRQF_COND_ONESHOT whereas the bwctrl driver > does: IRQF_TRIGGER_HIGH | IRQF_SHARED | IRQF_ONESHOT. Reading through the > comment of IRQF_COND_ONESHOT, that does not seem to be an incompatible > configuration, but maybe it is an ordering issue here? Certainly looks ordering might explain the failure. pcie_pme_probe() only passes IRQF_SHARED flag though but I guess something within IRQ subsys adds the rest of the flags. > That is, bwctlr should claim the interrupt line first, and then PME > would too, and they would be OK with the flags? Also hotplug is sharing this same IRQ and is not providing IRQF_ONESHOT, that might not be problem on RPI but could be on some other machine. Perhaps both PME and hotplug should just add IRQF_ONESHOT flag so that the probe order doesn't matter. Or should IRQ subsystem not fail with this ordering of flags? Thomas? -- i.
