Re: [PATCH 0/8] remoteproc: qcom: Support the Nord HPASS ADSP cluster

[Konrad Dybcio]

On 8/15/26 3:25 PM, Shawn Guo wrote:
> The HPASS audio subsystem on the Qualcomm Nord SoC has three QDSP6
> instances, ADSP0/1/2. They are not independent: ADSP0 owns the resources
> the other two need (PLLs, AG_NOC, RSCp, CESTA, THROTTLE, QTMR) and
> initializes them as part of its own boot, so ADSP1/ADSP2 can only cold
> boot once ADSP0 is up. Their firmware also cannot tolerate one instance
> going down on its own -- stopping or restarting a single member leaves
> sysmon/glink_ssr notify requests to the siblings timing out, and the
> whole cluster unable to recover without manually stopping all three and
> restarting them in dependency order.
> 
> This series models that constraint. A new "qcom,cluster-root" phandle
> groups the instances; every member carries it, the resource-owning
> instance included, whose phandle references itself, so both cluster
> membership and root-ness are answerable from the node being probed alone.
> Instances without the property -- which is every PAS instance on every
> other SoC -- keep qcom_pas.cluster NULL and are completely unaffected.
> 
> Two invariants fall out of the hardware, and are implemented
> independently of each other:
> 
>  - Root-first bring-up. A dependent member's start blocks until the root
>    has booted.
> 
>  - Coupled, two-phase teardown. Stopping or crashing any member takes
>    the whole cluster down. Hardware testing showed that whichever
>    member's PAS/TZ power-off happens chronologically last always fails
>    its own graceful shutdown ack -- both the sysmon SSCTL QMI ack and
>    the SMEM-bit/IRQ ack -- regardless of whether that member is the
>    root. So phase 1 fans the stop out to every participant concurrently

What!? Is that intended by design? Sounds like a crazy DoS attack surface :/

Are we perhaps missing something to let the uncrashed DSPs keep running?

Konrad