From: "Alex G." <mr.nuke.me@gmail.com>
To: andersson@kernel.org, krzk+dt@kernel.org,
mturquette@baylibre.com, linux-remoteproc@vger.kernel.org,
Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Cc: mathieu.poirier@linaro.org, robh@kernel.org, conor+dt@kernel.org,
konradybcio@kernel.org, sboyd@kernel.org, p.zabel@pengutronix.de,
linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org
Subject: Re: [PATCH v2 0/9] remoteproc: qcom_q6v5_wcss: add native ipq9574 support
Date: Tue, 13 Jan 2026 21:54:00 -0600 [thread overview]
Message-ID: <4814455.tdWV9SEqCh@nukework.gtech> (raw)
In-Reply-To: <14283f23-31cc-4bf8-9762-f0348c30618d@oss.qualcomm.com>
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
next prev parent reply other threads:[~2026-01-14 3:54 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-09 4:33 [PATCH v2 0/9] remoteproc: qcom_q6v5_wcss: add native ipq9574 support Alexandru Gagniuc
2026-01-09 4:33 ` [PATCH v2 1/9] remoteproc: qcom_q6v5_wcss: drop unused clocks from q6v5 struct Alexandru Gagniuc
2026-01-09 8:31 ` Krzysztof Kozlowski
2026-01-13 14:27 ` Konrad Dybcio
2026-01-09 4:33 ` [PATCH v2 2/9] dt-bindings: remoteproc: qcom,ipq8074-wcss-pil: convert to DT schema Alexandru Gagniuc
2026-01-09 8:38 ` Krzysztof Kozlowski
2026-01-09 4:33 ` [PATCH v2 3/9] dt-bindings: clock: gcc-ipq9574: add wcss remoteproc clocks Alexandru Gagniuc
2026-01-09 8:39 ` Krzysztof Kozlowski
2026-01-09 4:33 ` [PATCH v2 4/9] dt-bindings: remoteproc: qcom: add IPQ9574 image loader Alexandru Gagniuc
2026-01-09 8:40 ` Krzysztof Kozlowski
2026-01-09 4:33 ` [PATCH v2 5/9] arm64: dts: qcom: ipq9574: add wcss remoteproc nodes Alexandru Gagniuc
2026-01-09 4:33 ` [PATCH v2 6/9] clk: qcom: gcc-ipq9574: add wcss remoteproc clocks Alexandru Gagniuc
2026-01-09 4:33 ` [PATCH v2 7/9] remoteproc: qcom_q6v5_wcss: support IPQ9574 Alexandru Gagniuc
2026-01-09 4:33 ` [PATCH v2 8/9] remoteproc: qcom_q6v5_wcss: support m3 firmware Alexandru Gagniuc
2026-01-09 4:33 ` [PATCH v2 9/9] remoteproc: qcom_q6v5_wcss: use bulk clk API for q6 clocks in QCS404 Alexandru Gagniuc
2026-01-09 8:29 ` [PATCH v2 0/9] remoteproc: qcom_q6v5_wcss: add native ipq9574 support Krzysztof Kozlowski
2026-01-09 8:30 ` Krzysztof Kozlowski
2026-01-12 15:17 ` Rob Herring
2026-01-13 14:28 ` Konrad Dybcio
2026-01-14 3:54 ` Alex G. [this message]
2026-01-14 5:42 ` Vignesh Viswanathan
2026-01-15 4:50 ` Alex G.
2026-01-14 10:26 ` Konrad Dybcio
2026-01-15 5:27 ` Alex G.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4814455.tdWV9SEqCh@nukework.gtech \
--to=mr.nuke.me@gmail.com \
--cc=andersson@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=konrad.dybcio@oss.qualcomm.com \
--cc=konradybcio@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=mathieu.poirier@linaro.org \
--cc=mturquette@baylibre.com \
--cc=p.zabel@pengutronix.de \
--cc=robh@kernel.org \
--cc=sboyd@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox