Re: IPQ5332 multipd: missing text PD level and qcom,rproc ownership

[Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com>]

On 9/3/2026 12:54 AM, Hideo Sumi wrote:
> 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/20260811054316.518494-1-aaradhana.sahu@oss.qualcomm.com/
> 
> Regards,
> Hideo Sumi

Before we look into the SMEM handling, could you please confirm whether you are using the
latest ath.git ToT and whether the remoteproc v14 series is included?

Remoteproc series:
https://patchwork.kernel.org/project/linux-arm-msm/cover/20260803-rproc-v14-0-a1f87b0b0ad2@oss.qualcomm.com/

Could you also share the complete DT changes and the firmware version you are using?
It would help to know how many WiFi devices/User PDs are attached on your platform.

Once I have these details, I can check whether the issue is already addressed in the latest patches
or whether an additional change is needed.