On Tuesday, January 13, 2026 11:42:45 PM CST Vignesh Viswanathan wrote: > On 1/14/2026 9:24 AM, Alex G. wrote: > > On Tuesday, January 13, 2026 8:28:11 AM CST Konrad Dybcio wrote: > >> On 1/9/26 5:33 AM, Alexandru Gagniuc wrote: > >>> Support loading remoteproc firmware on IPQ9574 with the qcom_q6v5_wcss > >>> driver. This firmware is usually used to run ath11k firmware and enable > >>> wifi with chips such as QCN5024. > >>> > >>> When submitting v1, I learned that the firmware can also be loaded by > >>> the trustzone firmware. Since TZ is not shipped with the kernel, it > >>> makes sense to have the option of a native init sequence, as not all > >>> devices come with the latest TZ firmware. > >>> > >>> Qualcomm tries to assure us that the TZ firmware will always do the > >>> right thing (TM), but I am not fully convinced > >> > >> Why else do you think it's there in the firmware? :( > > > > A more relevant question is, why do some contributors sincerely believe > > that the TZ initialization of Q6 firmware is not a good idea for their > > use case? > > > > To answer your question, I think the TZ initialization is an afterthought > > of the SoC design. I think it was only after ther the design stage that > > it was brought up that a remoteproc on AHB has out-of-band access to > > system memory, which poses security concerns to some customers. I think > > authentication was implemented in TZ to address that. I also think that > > in order to prevent clock glitching from bypassing such verification, > > they had to move the initialization sequence in TZ as well. > > Exactly, the TZ interface is present to address the security concerns. > Also, as I mentioned in [1], on some platforms, TZ might access protect the > clocks and registers which might prevent the remoteproc bringup and throw > an access violation. > > We can keep this support added for IPQ9574, as it is good to have, but can > we keep the default compatible in ipq9574 DTSI to use the TZ interface, > which has already picked up an R-b in this series [2].
I think that's an acceptable plan. For the TZ case, we'd have to keep the clock framework from disabling the "unused" remoteproc clocks. Do you think "protected-clocks" property is the right way to do it? Which series should add it? Alex > > [1] > https://lore.kernel.org/linux-remoteproc/21468f66-56df-43ea-99c2-7257d8d6bb > [email protected]/T/#m688033ab79c63a8953e38f5575d1c0ff6b37b13a [2] > https://lore.kernel.org/linux-remoteproc/20260113092021.1887980-1-varadaraj > [email protected]/T/#t > > Alex
