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
