Re: pcie_bwctrl fails to probe on Rpi 4 (linux-next-20241101)

[Florian Fainelli <florian.fainelli@broadcom.com>]

Hi Stefan,

On 11/2/2024 9:53 AM, Stefan Wahren wrote:
> Hi,
> 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? That is, bwctlr should claim the interrupt line first, and then 
PME would too, and they would be OK with the flags?
-- 
Florian