Re: [PATCH v2 0/9] remoteproc: qcom_q6v5_wcss: add native ipq9574 support

["Alex G." <mr.nuke.me@gmail.com>]

On Wednesday, January 14, 2026 4:26:36 AM CST Konrad Dybcio wrote:
> On 1/14/26 4:54 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.
> 
> I wouldn't exactly call it an afterthought.. Image authentication (as in,
> verifying the signature of the ELF) has always been part of TZ, because
> doing so in a user-modifiable context would be absolutely nonsensical
> 
> qcom_scm_pas_auth_and_reset() which configures and powers up the rproc
> has been there for a really long time too (at least since the 2012 SoCs
> like MSM8974) and I would guesstimate it's been there for a reason - not
> all clocks can or should be accessible from the OS (from a SW standpoint
> it would be convenient to have a separate SECURE_CC block where all the
> clocks we shouldn't care about are moved, but the HW design makes more
> sense as-is, for the most part), plus there is additional access control
> hardware on the platform that must be configured from a secure context
> (by design) which I assume could be part of this sequence, based on
> the specifics of a given SoC

What was the original use case for the Q6 remoteproc? I see today's use case 
is as a conduit for ath11k firmware to control PCIe devices. Was that always 
the case? I imagine a more modern design would treat the remoteproc as 
untrusted by putting it under a bridge or IOMMU with more strict memory access 
control, so that firmware couldn't access OS memory.


> Konrad