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, and believe there is
justification for a native remoteproc loader. Besides, this series
has improvements to the existing code.

Changes since v1:
 - Improve bindings following review feedback
 - disable clocks on init failures in q6v7_wcss_reset()
 - review-suggetsed readability improvements of qcom_q6v5_wcss

Alexandru Gagniuc (9):
  remoteproc: qcom_q6v5_wcss: drop unused clocks from q6v5 struct
  dt-bindings: remoteproc: qcom,ipq8074-wcss-pil: convert to DT schema
  dt-bindings: clock: gcc-ipq9574: add wcss remoteproc clocks
  dt-bindings: remoteproc: qcom: add IPQ9574 image loader
  arm64: dts: qcom: ipq9574: add wcss remoteproc nodes
  clk: qcom: gcc-ipq9574: add wcss remoteproc clocks
  remoteproc: qcom_q6v5_wcss: support IPQ9574
  remoteproc: qcom_q6v5_wcss: support m3 firmware
  remoteproc: qcom_q6v5_wcss: use bulk clk API for q6 clocks in QCS404

 .../remoteproc/qcom,ipq8074-wcss-pil.yaml     | 268 ++++++++++++
 .../bindings/remoteproc/qcom,q6v5.txt         | 102 -----
 arch/arm64/boot/dts/qcom/ipq9574.dtsi         | 101 +++++
 drivers/clk/qcom/gcc-ipq9574.c                | 378 +++++++++++++++++
 drivers/remoteproc/qcom_q6v5_wcss.c           | 398 ++++++++++++++----
 include/dt-bindings/clock/qcom,ipq9574-gcc.h  |  22 +
 6 files changed, 1082 insertions(+), 187 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/remoteproc/qcom,ipq8074-wcss-pil.yaml
 delete mode 100644 Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt

--
2.45.1

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? :(

Konrad

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.

Alex

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

Konrad

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

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/21468f66-56df-43ea-99c2-7257d8d6bb7c@oss.qualcomm.com/T/#m688033ab79c63a8953e38f5575d1c0ff6b37b13a
[2] https://lore.kernel.org/linux-remoteproc/20260113092021.1887980-1-varadarajan.narayanan@oss.qualcomm.com/T/#t

> 
> Alex
> 
> 
> 
> 
> 
>

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
> 7c@oss.qualcomm.com/T/#m688033ab79c63a8953e38f5575d1c0ff6b37b13a [2]
> https://lore.kernel.org/linux-remoteproc/20260113092021.1887980-1-varadaraj
> an.narayanan@oss.qualcomm.com/T/#t
> > Alex

On Thu, 08 Jan 2026 22:33:35 -0600, 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, and believe there is
> justification for a native remoteproc loader. Besides, this series
> has improvements to the existing code.
> 
> Changes since v1:
>  - Improve bindings following review feedback
>  - disable clocks on init failures in q6v7_wcss_reset()
>  - review-suggetsed readability improvements of qcom_q6v5_wcss
> 
> Alexandru Gagniuc (9):
>   remoteproc: qcom_q6v5_wcss: drop unused clocks from q6v5 struct
>   dt-bindings: remoteproc: qcom,ipq8074-wcss-pil: convert to DT schema
>   dt-bindings: clock: gcc-ipq9574: add wcss remoteproc clocks
>   dt-bindings: remoteproc: qcom: add IPQ9574 image loader
>   arm64: dts: qcom: ipq9574: add wcss remoteproc nodes
>   clk: qcom: gcc-ipq9574: add wcss remoteproc clocks
>   remoteproc: qcom_q6v5_wcss: support IPQ9574
>   remoteproc: qcom_q6v5_wcss: support m3 firmware
>   remoteproc: qcom_q6v5_wcss: use bulk clk API for q6 clocks in QCS404
> 
>  .../remoteproc/qcom,ipq8074-wcss-pil.yaml     | 268 ++++++++++++
>  .../bindings/remoteproc/qcom,q6v5.txt         | 102 -----
>  arch/arm64/boot/dts/qcom/ipq9574.dtsi         | 101 +++++
>  drivers/clk/qcom/gcc-ipq9574.c                | 378 +++++++++++++++++
>  drivers/remoteproc/qcom_q6v5_wcss.c           | 398 ++++++++++++++----
>  include/dt-bindings/clock/qcom,ipq9574-gcc.h  |  22 +
>  6 files changed, 1082 insertions(+), 187 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/remoteproc/qcom,ipq8074-wcss-pil.yaml
>  delete mode 100644 Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt
> 
> --
> 2.45.1
> 
> 
> 


My bot found new DTB warnings on the .dts files added or changed in this
series.

Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.

If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:

  pip3 install dtschema --upgrade


This patch series was applied (using b4) to base:
 Base: attempting to guess base-commit...
 Base: tags/v6.19-rc2-7-ge190ecec2fdf (exact match)
 Base: tags/v6.19-rc2-7-ge190ecec2fdf (use --merge-base to override)

If this is not the correct base, please add 'base-commit' tag
(or use b4 which does this automatically)

New warnings running 'make CHECK_DTBS=y for arch/arm64/boot/dts/qcom/' for 20260109043352.3072933-1-mr.nuke.me@gmail.com:

arch/arm64/boot/dts/qcom/ipq9574-rdp454.dtb: smp2p-wcss (qcom,smp2p): master-kernel: 'qcom,smp2p-feature-ssr-ack' does not match any of the regexes: '^pinctrl-[0-9]+$'
	from schema $id: http://devicetree.org/schemas/soc/qcom/qcom,smp2p.yaml
arch/arm64/boot/dts/qcom/ipq9574-rdp433.dtb: smp2p-wcss (qcom,smp2p): master-kernel: 'qcom,smp2p-feature-ssr-ack' does not match any of the regexes: '^pinctrl-[0-9]+$'
	from schema $id: http://devicetree.org/schemas/soc/qcom/qcom,smp2p.yaml
arch/arm64/boot/dts/qcom/ipq9574-rdp453.dtb: smp2p-wcss (qcom,smp2p): master-kernel: 'qcom,smp2p-feature-ssr-ack' does not match any of the regexes: '^pinctrl-[0-9]+$'
	from schema $id: http://devicetree.org/schemas/soc/qcom/qcom,smp2p.yaml
arch/arm64/boot/dts/qcom/ipq9574-rdp449.dtb: smp2p-wcss (qcom,smp2p): master-kernel: 'qcom,smp2p-feature-ssr-ack' does not match any of the regexes: '^pinctrl-[0-9]+$'
	from schema $id: http://devicetree.org/schemas/soc/qcom/qcom,smp2p.yaml
arch/arm64/boot/dts/qcom/ipq9574-rdp418.dtb: smp2p-wcss (qcom,smp2p): master-kernel: 'qcom,smp2p-feature-ssr-ack' does not match any of the regexes: '^pinctrl-[0-9]+$'
	from schema $id: http://devicetree.org/schemas/soc/qcom/qcom,smp2p.yaml

On Thu, Jan 08, 2026 at 10:33:35PM -0600, 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, and believe there is
> justification for a native remoteproc loader. Besides, this series
> has improvements to the existing code.
> 
> Changes since v1:
>  - Improve bindings following review feedback

This is not specific enough.

With such vague changelog you could at least make it easy for us to
compare with older version, but not:

$ b4 diff '20260109043352.3072933-1-mr.nuke.me@gmail.com'
Grabbing thread from lore.kernel.org/all/20260109043352.3072933-1-mr.nuke.me@gmail.com/t.mbox.gz
Checking for older revisions
Grabbing search results from lore.kernel.org
Nothing matching that query.
---
Analyzing 10 messages in the thread
Could not find lower series to compare against.


Best regards,
Krzysztof

On 09/01/2026 09:29, Krzysztof Kozlowski wrote:
> On Thu, Jan 08, 2026 at 10:33:35PM -0600, 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, and believe there is
>> justification for a native remoteproc loader. Besides, this series
>> has improvements to the existing code.
>>
>> Changes since v1:
>>  - Improve bindings following review feedback
> 
> This is not specific enough.

I saw now detailed changelogs in individual patches, so it's fine.

> 
> With such vague changelog you could at least make it easy for us to
> compare with older version, but not:
> 
> $ b4 diff '20260109043352.3072933-1-mr.nuke.me@gmail.com'
> Grabbing thread from lore.kernel.org/all/20260109043352.3072933-1-mr.nuke.me@gmail.com/t.mbox.gz
> Checking for older revisions
> Grabbing search results from lore.kernel.org
> Nothing matching that query.
> ---
> Analyzing 10 messages in the thread
> Could not find lower series to compare against.



Best regards,
Krzysztof