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

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

[Hideo Sumi]

Hi Manikanta, all,

I have been bringing up the WiFi subsystem on an IPQ5332 board using the
multipd remoteproc driver (qcom_q6v5_mpd) together with the ath12k AHB
backend, on 6.18.44. Two things came out of it that I could not settle
from the code alone. Both look structural rather than like mistakes on
my side, so I would rather report them than sit on them.

Caveat up front: I am running vendor (QSDK) Q6 firmware, as there is no
upstream firmware for this part. If either answer is "that is a
vendor-firmware-only concern", that is a perfectly good answer and I
will stop there.


1. The root PD does not boot without a text PD level, and the binding
   has no way to describe one
   ------------------------------------------------------------------

With the DT shaped as the binding describes -- a root PD with user PDs
pd-1/pd-2 directly underneath -- the root PD never reaches a usable
state:

  qcom-q6-mpd d100000.remoteproc: fatal error without message

No further diagnostics, and the user PDs never come up.

The vendor DT has a level between the root PD and the user PDs: a text
PD (compatible "qcom,ipq5332-mpd-upd-text") that owns a separate
firmware image, with the user PDs as its children rather than the
root's:

  q6v5_wcss             qcom,ipq5332-q6-mpd        q6_fw0.mdt
    text-pd             qcom,ipq5332-mpd-upd-text  q6_fw3.mdt
      pd1                                          q6_fw1.mdt
      pd2                                          q6_fw2.mdt

Once I added that level -- a text PD node with its own firmware-name,
the user PDs reparented under it, and a small driver change so that
q6_register_userpd() recurses and the PAS ID is derived from the node
-- the fatal error disappeared and the whole chain came up:

  remoteproc remoteproc2: powering up pd1
  remoteproc remoteproc1: powering up text-pd3
  remoteproc remoteproc0: powering up d100000.remoteproc
  remoteproc remoteproc0: remote processor d100000.remoteproc is now up
  remoteproc remoteproc1: remote processor text-pd3 is now up
  remoteproc remoteproc2: remote processor pd1 is now up

The ordering is the interesting part. "powering up" runs child to parent
as rproc_boot() recurses upward, and "is now up" comes back parent to
child as it unwinds -- which is exactly the parent-first dependency the
multipd model exists to express. The text PD simply was not one of the
levels it can express.

So: is the text PD level deliberately out of scope upstream -- because
upstream firmware for these parts is expected to be packaged without a
separate text image, say -- or is it a level that should exist and is
not there yet?

I ask because if it is the latter, the binding as posted cannot describe
this hardware at all, and that seems worth settling before it lands. I
have a working change against qcom_q6v5_mpd.c and would be glad to send
it as an RFC. I did not want to send it uninvited if the omission is
intentional.


2. The vendor DT and the ath12k AHB backend disagree about what
   qcom,rproc points at
   ------------------------------------------------------------------

This one I can describe precisely, but I cannot tell which side is
meant to be authoritative.

In ath12k's AHB backend, qcom,rproc is the *root* PD. ahb.c resolves the
phandle and boots it via a function named ath12k_ahb_boot_root_pd(),
waits for rootpd_ready, and then does the entire user PD lifecycle
itself: qcom_mdt_load() of amss_<n>.mdt into memory-region[0],
qcom_scm_pas_auth_and_reset() with a PAS ID it computes locally, and a
spawn via qcom_smem_state_update_bits(). It also requests the "spawn",
"ready" and "stop-ack" interrupts by name to drive that sequence.

In the vendor DT, qcom,rproc is the *user* PD:

  wifi@c0000000 {
      compatible = "qcom,cnss-qca5332", "qcom,ipq5332-wifi";
      qcom,rproc = <&remoteproc_pd1>;              /* the user PD */
      qcom,userpd-subsys-name = "q6v5_wcss_userpd1";
  };

There, remoteproc owns the user PD -- image, PAS, spawn and the same
three interrupts -- and the WiFi driver only attaches to it.

These are mutually exclusive, and on this board they collide. With
qcom_q6v5_mpd instantiating user PD rprocs as its binding describes, the
PD boots fine and then ath12k cannot have the interrupt it needs:

  remoteproc remoteproc2: remote processor pd1 is now up
  genirq: Flags mismatch irq 31. 00002001 (UserPD1-spawn)
          vs. 00002001 (q6v5_wcss_userpd1_spawn-ack)
  ath12k_ahb c000000.wifi: error -EBUSY: Request spawn irq failed: -16

Same interrupt, same flags, two requesters, neither wrong in isolation.

So which is the intended division of labour?

  - Are the pd-1/pd-2 nodes in the multipd binding meant for non-WiFi
    PDs only, with WiFi user PDs left entirely to ath12k -- so a board
    with only WiFi user PDs should describe none of them, and point
    qcom,rproc at the root PD?
  - Or is remoteproc meant to own them, as the vendor DT has it, and
    ath12k's AHB backend should attach rather than load and spawn when
    qcom,rproc resolves to a user PD?

I have deliberately not sent a patch for this one. Either answer implies
a behaviour change in a driver used by boards I cannot test, and
guessing at the ownership model and then changing ath12k for everyone is
not mine to do.

Happy to test patches, provide full boot logs, or run experiments on
this board -- it is on a serial console with a recoverable second
firmware bank, so I can iterate destructively without much risk.

Thanks for the series, and for reading this far.

Regards,
Hideo Sumi

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

[Aaradhana Sahu]

On 9/2/2026 9:43 AM, Hideo Sumi wrote:
> Hi Manikanta, all,
> 
> I have been bringing up the WiFi subsystem on an IPQ5332 board using the
> multipd remoteproc driver (qcom_q6v5_mpd) together with the ath12k AHB
> backend, on 6.18.44. Two things came out of it that I could not settle
> from the code alone. Both look structural rather than like mistakes on
> my side, so I would rather report them than sit on them.
> 
> Caveat up front: I am running vendor (QSDK) Q6 firmware, as there is no
> upstream firmware for this part. If either answer is "that is a
> vendor-firmware-only concern", that is a perfectly good answer and I
> will stop there.
> 
> 
> 1. The root PD does not boot without a text PD level, and the binding
>    has no way to describe one
>    ------------------------------------------------------------------
> 
> With the DT shaped as the binding describes -- a root PD with user PDs
> pd-1/pd-2 directly underneath -- the root PD never reaches a usable
> state:
> 
>   qcom-q6-mpd d100000.remoteproc: fatal error without message
> 
> No further diagnostics, and the user PDs never come up.
> 
> The vendor DT has a level between the root PD and the user PDs: a text
> PD (compatible "qcom,ipq5332-mpd-upd-text") that owns a separate
> firmware image, with the user PDs as its children rather than the
> root's:
> 
>   q6v5_wcss             qcom,ipq5332-q6-mpd        q6_fw0.mdt
>     text-pd             qcom,ipq5332-mpd-upd-text  q6_fw3.mdt
>       pd1                                          q6_fw1.mdt
>       pd2                                          q6_fw2.mdt
> 
> Once I added that level -- a text PD node with its own firmware-name,
> the user PDs reparented under it, and a small driver change so that
> q6_register_userpd() recurses and the PAS ID is derived from the node
> -- the fatal error disappeared and the whole chain came up:
> 
>   remoteproc remoteproc2: powering up pd1
>   remoteproc remoteproc1: powering up text-pd3
>   remoteproc remoteproc0: powering up d100000.remoteproc
>   remoteproc remoteproc0: remote processor d100000.remoteproc is now up
>   remoteproc remoteproc1: remote processor text-pd3 is now up
>   remoteproc remoteproc2: remote processor pd1 is now up
> 
> The ordering is the interesting part. "powering up" runs child to parent
> as rproc_boot() recurses upward, and "is now up" comes back parent to
> child as it unwinds -- which is exactly the parent-first dependency the
> multipd model exists to express. The text PD simply was not one of the
> levels it can express.
> 
> So: is the text PD level deliberately out of scope upstream -- because
> upstream firmware for these parts is expected to be packaged without a
> separate text image, say -- or is it a level that should exist and is
> not there yet?
> 
> I ask because if it is the latter, the binding as posted cannot describe
> this hardware at all, and that seems worth settling before it lands. I
> have a working change against qcom_q6v5_mpd.c and would be glad to send
> it as an RFC. I did not want to send it uninvited if the omission is
> intentional.
> 
> 
> 2. The vendor DT and the ath12k AHB backend disagree about what
>    qcom,rproc points at
>    ------------------------------------------------------------------
> 
> This one I can describe precisely, but I cannot tell which side is
> meant to be authoritative.
> 
> In ath12k's AHB backend, qcom,rproc is the *root* PD. ahb.c resolves the
> phandle and boots it via a function named ath12k_ahb_boot_root_pd(),
> waits for rootpd_ready, and then does the entire user PD lifecycle
> itself: qcom_mdt_load() of amss_<n>.mdt into memory-region[0],
> qcom_scm_pas_auth_and_reset() with a PAS ID it computes locally, and a
> spawn via qcom_smem_state_update_bits(). It also requests the "spawn",
> "ready" and "stop-ack" interrupts by name to drive that sequence.
> 
> In the vendor DT, qcom,rproc is the *user* PD:
> 
>   wifi@c0000000 {
>       compatible = "qcom,cnss-qca5332", "qcom,ipq5332-wifi";
>       qcom,rproc = <&remoteproc_pd1>;              /* the user PD */
>       qcom,userpd-subsys-name = "q6v5_wcss_userpd1";
>   };
> 
> There, remoteproc owns the user PD -- image, PAS, spawn and the same
> three interrupts -- and the WiFi driver only attaches to it.
> 
> These are mutually exclusive, and on this board they collide. With
> qcom_q6v5_mpd instantiating user PD rprocs as its binding describes, the
> PD boots fine and then ath12k cannot have the interrupt it needs:
> 
>   remoteproc remoteproc2: remote processor pd1 is now up
>   genirq: Flags mismatch irq 31. 00002001 (UserPD1-spawn)
>           vs. 00002001 (q6v5_wcss_userpd1_spawn-ack)
>   ath12k_ahb c000000.wifi: error -EBUSY: Request spawn irq failed: -16
> 
> Same interrupt, same flags, two requesters, neither wrong in isolation.
> 
> So which is the intended division of labour?
> 
>   - Are the pd-1/pd-2 nodes in the multipd binding meant for non-WiFi
>     PDs only, with WiFi user PDs left entirely to ath12k -- so a board
>     with only WiFi user PDs should describe none of them, and point
>     qcom,rproc at the root PD?
>   - Or is remoteproc meant to own them, as the vendor DT has it, and
>     ath12k's AHB backend should attach rather than load and spawn when
>     qcom,rproc resolves to a user PD?
> 
> I have deliberately not sent a patch for this one. Either answer implies
> a behaviour change in a driver used by boards I cannot test, and
> guessing at the ownership model and then changing ath12k for everyone is
> not mine to do.
> 
> Happy to test patches, provide full boot logs, or run experiments on
> this board -- it is on a serial console with a recoverable second
> firmware bank, so I can iterate destructively without much risk.
> 
> Thanks for the series, and for reading this far.
> 
> Regards,
> Hideo Sumi
> 

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.

ath12k will take complete ownership of the Text PD and User PDs. This includes
loading the Text PD/shared firmware and User PD firmware, as well as handling
the corresponding spawn/ready/stop-ack interrupts.

The shared firmware support is covered in this patch: https://patchwork.kernel.org/project/linux-wireless/patch/20260811054316.518494-1-aaradhana.sahu@oss.qualcomm.com/

So, qcom,rproc in the ath12k DT is expected to point to the root PD.
The WiFi User PDs should not be independently managed by qcom_q6v5_mpd, otherwise
both remoteproc and ath12k would try to manage the same User PD and interrupts, which
leads to the IRQ conflict you observed.

The Text PD is an additional level in the ath12k Multi-PD flow and is handled by ath12k
as part of the WiFi User PD lifecycle.

-- 
Aaradhana Sahu

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

[Hideo Sumi]

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

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

[Aaradhana Sahu]

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.

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

[Hideo Sumi]

On 9/3/2026, Aaradhana Sahu wrote:
> 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?

No on both counts, and thank you for the pointer -- I had not seen v14.
Let me be precise about the base so we compare like for like, and then
ask you the one question that would settle most of this.

This is an OpenWrt build, not ath.git ToT:

  - kernel 6.18.44
  - ath12k from the OpenWrt "backports-6.18.39" package
  - the multipd remoteproc support is the *old* series: Manikanta
    Mylavarapu's original multipd patches (Nov 2023) plus Ziyang Huang's
    "split q6_wcss to rootpd and userpd" fixes (Sep 2024), carried as
    OpenWrt target patches.

It does not include your v14 series. So it is very possible the issues I
raised are already addressed there, and I do not want to send you
chasing a three-year-old base.

The core of my first mail was a *text PD* level between the root PD and
the user PDs, which the vendor firmware for this part requires and which
the 2023/2024 series does not model, so I added it locally:

  q6v5_wcss   qcom,ipq5332-q6-mpd         q6_fw0.mdt   root PD
    text-pd   qcom,ipq5332-mpd-upd-text   q6_fw3.mdt   shared RO text
      pd1                                 q6_fw1.mdt   user PD
      pd2                                 q6_fw2.mdt   user PD

So the question that would settle it: does the v14 series introduce this
text-PD level (a shared read-only text image loaded between root and
user PDs)? If it does, my local patch is redundant and the right move is
simply to use v14 -- no need to debug the old base at all. You wrote the
series, so you can answer that far faster than I can by porting it.

I am glad to help validate v14 on this hardware if that is useful -- if
you can point me at the base it is meant to apply on (ath.git ToT plus
the series, or a branch), I will build it for IPQ5332 and report what
reproduces. I would just rather not promise a blind full rebase, since
2.4 GHz already works here on the old base and I do not want to trade a
working setup for guesswork. The OpenWrt device support proceeds on the
current base regardless; the upstream question is only about landing on
your track correctly.

The details you asked for, in any case:

Firmware version, from the Q6 error record:

  WLAN.WBE.1.3.2-00067-QCAHKSWPL_SILICONZ-1.128291.1.135427.1

Platform: Qualcomm IPQ5332 (Xiaomi BE3600 Pro). Two on-chip WiFi
devices, two user PDs, both attached to the single Q6 root PD via the
shared text PD:

  - wifi0 / pd1: on-chip QCA5332, 2.4 GHz, AHB
  - wifi1 / pd2: QCN6432, 5 GHz

The multipd DT (our downstream form on the old base):

  &q6v5_wcss {
      firmware-name = "ath12k/IPQ5332/hw1.0/q6_fw0.mdt",
                      "ath12k/IPQ5332/hw1.0/iu_fw.mdt",
                      "ath12k/QCN6432/hw1.0/iu_fw.mdt";
      status = "okay";

      text-pd3 {
          compatible = "qcom,ipq5332-mpd-upd-text";
          firmware-name = "ath12k/IPQ5332/hw1.0/q6_fw3.mdt";

          pd1 {  /* wifi0, 2.4 GHz */
              firmware-name = "ath12k/IPQ5332/hw1.0/q6_fw1.mdt";
              interrupts-extended =
                  <&wcss_smp2p_in 8 IRQ_TYPE_NONE>,
                  <&wcss_smp2p_in 9 IRQ_TYPE_NONE>,
                  <&wcss_smp2p_in 12 IRQ_TYPE_NONE>,
                  <&wcss_smp2p_in 11 IRQ_TYPE_NONE>;
              interrupt-names = "fatal", "ready",
                                "spawn-ack", "stop-ack";
              qcom,smem-states = <&wcss_smp2p_out 8>,
                                 <&wcss_smp2p_out 9>,
                                 <&wcss_smp2p_out 10>;
              qcom,smem-state-names = "shutdown", "stop", "spawn";
          };

          pd2 {  /* wifi1, 5 GHz */
              firmware-name = "ath12k/IPQ5332/hw1.0/q6_fw2.mdt";
              interrupts-extended =
                  <&wcss_smp2p_in 16 IRQ_TYPE_NONE>,
                  <&wcss_smp2p_in 17 IRQ_TYPE_NONE>,
                  <&wcss_smp2p_in 20 IRQ_TYPE_NONE>,
                  <&wcss_smp2p_in 19 IRQ_TYPE_NONE>;
              interrupt-names = "fatal", "ready",
                                "spawn-ack", "stop-ack";
              qcom,smem-states = <&wcss_smp2p_out 16>,
                                 <&wcss_smp2p_out 17>,
                                 <&wcss_smp2p_out 18>;
              qcom,smem-state-names = "shutdown", "stop", "spawn";
          };
      };
  };

  &wifi0 { qcom,rproc = <&wcss_upd1>; status = "okay"; };  /* pd1 */
  &wifi1 { qcom,rproc = <&wcss_upd2>; status = "okay"; };  /* pd2 */

Thanks,
Hideo