On 9/2/2026 7:47 PM, Aaradhana Sahu wrote:
> The intended model is that the root PD is completely managed by
> qcom_q6v5_mpd, while the Text PD and WiFi User PDs are managed by ath12k.
> ...
> So, qcom,rproc in the ath12k DT is expected to point to the root PD.
Thank you, that settles both questions, and the shared firmware patch is
exactly the piece I was missing. I built the model you describe and ran it
on the board. It gets a good way in and then stops, and the last problem
does not look like something a board can fix, so I am reporting what I
found rather than guessing at it.
What I built, on 6.18.44 with backports 7.2:
- ath12k loads the shared read-only image itself, your patch [1] ported
to this tree (it predates the common/Wi-Fi 7 split, so the mapping
comes from power_up() rather than from rproc_info)
- the text PD node is gone from the DT
- the user PD nodes are gone from the DT, so qcom_q6v5_mpd does not
instantiate them
- qcom,rproc points at the root PD
Three things came up on the way. The first two are, I think, plain bugs;
I have patches for both and will send them separately if you agree.
1. ath12k subscribes to the SSR notifier by rproc->name
--------------------------------------------------
ath12k_ahb_register_rproc_notifier() does
qcom_register_ssr_notifier(ab_ahb->tgt_rproc->name, &ab_ahb->root_pd_nb);
but that lookup is keyed by the SSR name a driver passes to
qcom_add_ssr_subdev(), not by rproc->name. qcom_q6v5_mpd registers
"q6wcss" -- the same short name qcom_q6v5_wcss.c uses -- while rproc->name
is the DT node name, "d100000.remoteproc" here. So the notifier registers
against a name nothing signals:
remoteproc remoteproc0: remote processor d100000.remoteproc is now up
ath12k_ahb c000000.wifi: RootPD ready wait timed out
ath12k_ahb c000000.wifi: probe with driver ath12k_ahb failed: -110
Subscribing with "q6wcss" fixes it.
2. wifi0's memory-region[0] does not contain the images
---------------------------------------------------
ipq5332.dtsi points it at q6_ipq5332_data. The shared read-only image and
the user PD images link below that:
q6_fw3 (shared RO) 0x4aefd000 - 0x4b296000
q6_fw1 (pd1) 0x4b2a3000 - 0x4b55b000
q6_ipq5332_data 0x4bd00000 - 0x4ca00000
q6_region 0x4a900000 - 0x4ca00000
so qcom_mdt_load() refuses them:
ath12k_ahb c000000.wifi: segment outside memory range
ath12k_ahb c000000.wifi: failed to load shared firmware: -22
Pointing memory-region[0] at q6_region loads both. If ath12k is to own
these images, the region it loads them into has to be the one they are
linked for, and on this SoC that is the root PD's window.
3. The user PD nodes: removing them is what the model requires, and
also what breaks it
---------------------------------------------------------------
This is the one I cannot resolve from here.
Leaving pd-1/pd-2 in the DT does reproduce the IRQ conflict, exactly as
you said:
genirq: Flags mismatch irq 31. 00002001 (UserPD1-spawn)
vs. 00002001 (q6v5_wcss_userpd1_spawn-ack)
ath12k_ahb c000000.wifi: Request spawn irq failed: -16
Removing them clears that. But the root PD then stops during its own boot.
Its crash record says:
pd_stubs.c:137 Invalid user-pd CS load address 0x0
Thread name : sys_m_smsm Process name : kernel
PC : 0xc000ae58 SSR : 0x018f0027 BADVA : 0x00000000
and ath12k ends at "UserPD spawn wait timed out", probe -110.
The address it is missing comes from SMEM item 507, written by
qcom_q6v5_mpd's share_upd_bootinfo_to_q6() before the root PD is started:
list_for_each_entry(upd_rproc, &upd_rproc_list, node) {
upd_bootinfo.pid = upd_wcss->pd_asid + 1;
upd_bootinfo.bootaddr = rproc_get_boot_addr(upd_rproc, fw);
upd_bootinfo.data_size = qcom_mdt_get_size(fw);
}
upd_rproc_list holds the user PD rprocs qcom_q6v5_mpd created. With the
user PD nodes removed it is empty, so nothing is published and the root PD
faults on a zero address. With them present, remoteproc owns the spawn
interrupt. As it stands the two requirements exclude each other.
So my question is: in the intended model, who publishes the user PD boot
info to SMEM 507? Three shapes seem possible and I did not want to pick
one blind:
- ath12k writes it, since it owns the images and knows their addresses.
That would mean moving share_upd_bootinfo_to_q6() out of remoteproc,
or exporting it.
- qcom_q6v5_mpd keeps writing it, reading the user PD nodes for their
firmware-name but not creating rprocs for them. The nodes would stay
in the DT and describe the PDs without claiming them.
- Something else covers it that I have not found -- the shared firmware
patch does not touch SMEM 507, so if there is a companion change I
have missed it.
I do not think [1] alone is enough to boot this without one of those, but
I may well be reading the wrong tree; if this is fixed in ath12k-ng or in
a series I have not seen, that is a fine answer and I will go and read it.
For reference: reading the Q6's crash record needed a change of its own.
q6v5_fatal_interrupt() calls
qcom_smem_get(QCOM_SMEM_HOST_ANY, q6v5->crash_reason, &len);
and QCOM_SMEM_HOST_ANY is -1, so smem.c only searches the global
partition. On this part the record is in the WCSS private partition, host
1, and qcom_q6v5_mpd already defines WCSS_SMEM_HOST as 1 for it without
using it, because qcom_q6v5_init() has no way to pass a host through.
Until I read it from host 1 every one of these failures printed only
"fatal error without message". I am happy to send that as a patch too if
it is wanted.
Board is on a serial console with a recoverable second firmware bank, so I
can test whatever is useful.
[1]
https://lore.kernel.org/linux-wireless/[email protected]/
Regards,
Hideo Sumi
