Re: [PATCH v3] arm64: dts: qcom: arduino-monza: add WLAN enable and rfkill GPIO

[Qian Zhang]

On Fri, May 22, 2026 at 6:47 PM Konrad Dybcio
<konrad.dybcio@xxxxxxxxxxxxxxxx> wrote:
>
> On 5/19/26 4:58 AM, Qian Zhang wrote:
> > You're right that GPIO 56 (wlan_en) is consumed by pwrseq-qcom-wcn
> > through the wcn6855-pmu node — apologies for the confusion in my
> > earlier reply.
> > Let me explain the hardware on this board, because it
> > differs slightly from the typical WCN6855 reference design and is the
> > source of a problem we're now stuck on.
>
> The wording, structure and magic characters within your reply make
> me think you're using a LLM to respond to me. I will not entertain
> this conversation further if that's the case.
>
> > Hardware
> >
> > The WLAN module fitted on Monaco-Monza is not a bare WCN6855 — it
> > contains an additional, module-internal PMU (PMCA6850) that gates
> > power to the WCN6855 die. So the signal chain is:
> >
> > SoC TLMM gpio56 (wlan_en) ──► PMCA6850 EN ──► WCN6855 rails ──► PCIe link up
> >
> > wlan_en is therefore the enable pin of PMCA6850, not of the
> > WCN6855 itself. From the host's point of view, asserting wlan_en
> > brings the module out of reset; the WCN6855 only becomes visible on
> > PCIe after PMCA6850 has finished its own ramp-up.
>
> The powerseq driver for WCN PMUs exists precisely to handle this setup.
>
> > Initially we reused the qcom,wcn6855-pmu compatible so that
> > pwrseq-qcom-wcn would drive wlan_en for us. But we hit a
> > resource-allocation issue this hardware behavior creates.
> >
> > The problem
> >
> > Because PMCA6850's enable is driven by pwrseq (which runs after the
> > PCI host bridge has scanned the bus), WCN6855 only appears on the bus
> >  ~10 s after PCIe enumeration has already finished, with no resources
> > reserved for it.
> >
> > Topology — WCN6855 sits behind a Pericom PI7C9X2G304 switch alongside
> >   a TI USB controller:
> >
> > pcie0 RC ── 00:00.0 ── 01:00.0 (switch UP)
> >                        ├── 02:01.0 (DN) ── 03:00.0  WCN6855  (BAR0 = 2
> > MB, appears late)
> >                        └── 02:02.0 (DN) ── 04:00.0  TUSB7340 (BAR0 =
> > 64K, BAR2 = 8K, present at boot)
> >
> > dmesg (kernel 6.8.0-1071-qcom):
> > [    5.545559] qcom-pcie 1c00000.pci: PCIe Gen.2 x1 link up
> > [    5.882178] pci 0000:00:00.0: bridge window [mem
> > 0x40400000-0x404fffff]: assigned
> > [    5.912197] pci 0000:02:01.0: PCI bridge to [bus 03]
> > [    5.917368] pci 0000:04:00.0: BAR 0 [mem 0x40400000-0x4040ffff
> > 64bit]: assigned
> > [    5.924919] pci 0000:04:00.0: BAR 2 [mem 0x40410000-0x40411fff
> > 64bit]: assigned
> > [   16.476921] pci 0000:03:00.0: [17cb:1103] type 00 class 0x028000
> > PCIe Endpoint
> > [   16.477176] pci 0000:03:00.0: BAR 0 [mem 0x00000000-0x001fffff 64bit]
> > [   16.516689] pcieport 0000:02:01.0: bridge window [mem size
> > 0x00200000]: can't assign; no space
> > [   16.516704] pcieport 0000:02:01.0: bridge window [mem size
> > 0x00200000]: failed to assign
> > [   16.516713] pci 0000:03:00.0: BAR 0 [mem size 0x00200000 64bit]:
> > can't assign; no space
> > [   16.516720] pci 0000:03:00.0: BAR 0 [mem size 0x00200000 64bit]:
> > failed to assign
> > [   18.093137] ath11k_pci 0000:03:00.0: Adding to iommu group 24
> > [   18.101694] ath11k_pci 0000:03:00.0: BAR 0 [??? 0x00000000 flags
> > 0x20000000]: can't assign; bogus alignment
> > [   18.101724] ath11k_pci 0000:03:00.0: failed to assign pci resource: -22
> > [   18.108613] ath11k_pci 0000:03:00.0: failed to claim device: -22
> > [   18.115481] ath11k_pci: probe of 0000:03:00.0 failed with error -22
> >
> > At the initial scan the PCI core sizes the root-port window to 1 MB
> > based only on the TI USB endpoint that is currently visible, and
> > gives the 02:01.0 downstream port no MMIO window at all. When
> > WCN6855 appears later it requires a 2 MB BAR0 and there is nowhere
> > to put it.
>
> This is a separate issue that needs fixing. I see Mani is already
> part of the thread, maybe he can take a peek
>
> Konrad


The PCI issue has been fixed by this patch,
https://lore.kernel.org/linux-pci/20260116192921.GA958817@bhelgaas/

I will revert to the powerseq approach.

Qian