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].


[1] 
https://lore.kernel.org/linux-remoteproc/[email protected]/T/#m688033ab79c63a8953e38f5575d1c0ff6b37b13a
[2] 
https://lore.kernel.org/linux-remoteproc/[email protected]/T/#t

> 
> Alex
> 
> 
> 
> 
> 
> 


Reply via email to