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

[Qian Zhang]

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.

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.

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.

Thanks,
Qian

On Fri, May 15, 2026 at 8:22 PM Konrad Dybcio
<konrad.dybcio@xxxxxxxxxxxxxxxx> wrote:
>
> On 5/15/26 2:08 PM, Qian Zhang wrote:
> >
> >
> > On 5/15/2026 6:51 PM, Konrad Dybcio wrote:
> >> On 5/11/26 10:48 AM, Qian Zhang via B4 Relay wrote:
> >>> From: Qian Zhang <qian.zhang@xxxxxxxxxxxxxxxx>
> >>>
> >>> The QCNFA765 M.2 PCIe WLAN module requires GPIO56 (wlan_en) to be
> >>
> >> But isn't that just the wlan-en pin that the power sequencing driver
> >> takes?
> >>
> >> ref: drivers/power/sequencing/pwrseq-qcom-wcn.c
> >>
> >> Konrad
> > Thanks for the review.
> > It's not the same pin functionally, though they share the same name. There are two key differences:
> >
> >
> > Different power topology: The pwrseq-qcom-wcn.c driver targets WLAN
> > hips powered by an on-board PMU via the power sequencing framework. In our case (VENTUNO Q), the WLAN module has its own internal PMU, and wlan_en controls the power-on/off of that internal PMU — it is not part of the board-level power sequencing.
>
> I don't believe what you said about the pwrseq driver is true.
>
> > PCIe probe ordering: The WLAN module connects to the PCIe root complex through a PCIe bridge that does not currently support hotplug. If we were to use a similar node configuration as in pwrseq-qcom-wcn.c, there is no guarantee that the WLAN module would be powered on before the PCIe root complex probes, which would cause enumeration failure.
>
> What do you mean by "*currently* does not support hotplug"? Does that
> depend on some more code changes?
>
> Konrad