linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: Florian Fainelli <florian.fainelli@broadcom.com>,
	 Thomas Gleixner <tglx@linutronix.de>
Cc: Stefan Wahren <wahrenst@gmx.net>,
	Bjorn Helgaas <bhelgaas@google.com>,
	 Jim Quinlan <jim2101024@gmail.com>,
	Lukas Wunner <lukas@wunner.de>,
	 linux-pci <linux-pci@vger.kernel.org>,
	 Linux ARM <linux-arm-kernel@lists.infradead.org>,
	 kernel-list@raspberrypi.com
Subject: Re: pcie_bwctrl fails to probe on Rpi 4 (linux-next-20241101)
Date: Mon, 4 Nov 2024 14:41:37 +0200 (EET)	[thread overview]
Message-ID: <85ebe4b7-b18d-e993-b298-a8b5240dee3c@linux.intel.com> (raw)
In-Reply-To: <26c4c8fd-6afd-44fe-83a9-adebc1a281bc@broadcom.com>

[-- Attachment #1: Type: text/plain, Size: 4294 bytes --]

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.

      parent reply	other threads:[~2024-11-04 12:44 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-02 16:53 pcie_bwctrl fails to probe on Rpi 4 (linux-next-20241101) Stefan Wahren
2024-11-02 17:37 ` Florian Fainelli
2024-11-02 20:22   ` Stefan Wahren
2024-11-04 12:41   ` Ilpo Järvinen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=85ebe4b7-b18d-e993-b298-a8b5240dee3c@linux.intel.com \
    --to=ilpo.jarvinen@linux.intel.com \
    --cc=bhelgaas@google.com \
    --cc=florian.fainelli@broadcom.com \
    --cc=jim2101024@gmail.com \
    --cc=kernel-list@raspberrypi.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=tglx@linutronix.de \
    --cc=wahrenst@gmx.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).