[PATCH v1] arm64: dts: qcom: monaco-evk: Add firmware-name to QUPv3 nodes

[PATCH v1] arm64: dts: qcom: monaco-evk: Add firmware-name to QUPv3 nodes

[Viken Dadhaniya]

Traditionally, firmware loading for Serial Engines (SE) in the QUP hardware
of Qualcomm SoCs has been managed by TrustZone (TZ). While this approach
ensures secure SE assignment and access control, it limits flexibility for
developers who need to enable various protocols on different SEs.

Add the firmware-name property to QUPv3 nodes in the device tree to enable
firmware loading from the Linux environment. Handle SE assignments and
access control permissions directly within Linux, removing the dependency
on TrustZone.

Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/monaco-evk.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/monaco-evk.dts b/arch/arm64/boot/dts/qcom/monaco-evk.dts
index e72cf6725a52..d566737ee012 100644
--- a/arch/arm64/boot/dts/qcom/monaco-evk.dts
+++ b/arch/arm64/boot/dts/qcom/monaco-evk.dts
@@ -401,10 +401,12 @@ &iris {
 };
 
 &qupv3_id_0 {
+	firmware-name = "qcom/qcs8300/qupv3fw.elf";
 	status = "okay";
 };
 
 &qupv3_id_1 {
+	firmware-name = "qcom/qcs8300/qupv3fw.elf";
 	status = "okay";
 };
 
-- 
2.34.1

Re: [PATCH v1] arm64: dts: qcom: monaco-evk: Add firmware-name to QUPv3 nodes

[Konrad Dybcio]

On 9/25/25 6:26 AM, Viken Dadhaniya wrote:
> Traditionally, firmware loading for Serial Engines (SE) in the QUP hardware
> of Qualcomm SoCs has been managed by TrustZone (TZ). While this approach
> ensures secure SE assignment and access control, it limits flexibility for
> developers who need to enable various protocols on different SEs.
> 
> Add the firmware-name property to QUPv3 nodes in the device tree to enable
> firmware loading from the Linux environment. Handle SE assignments and
> access control permissions directly within Linux, removing the dependency
> on TrustZone.
> 
> Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
> ---

Viken, you've posted a lot of patches like these lately for
specific boards.

Should we instead push this to the SoC DTSI, to limit the boilerplate?

If I recall correctly, you said these ELFs are not vendor-signed, so
it should be OK to have them be assigned globally

Konrad

Re: [PATCH v1] arm64: dts: qcom: monaco-evk: Add firmware-name to QUPv3 nodes

[Viken Dadhaniya]

On 9/25/2025 2:22 PM, Konrad Dybcio wrote:
> On 9/25/25 6:26 AM, Viken Dadhaniya wrote:
>> Traditionally, firmware loading for Serial Engines (SE) in the QUP hardware
>> of Qualcomm SoCs has been managed by TrustZone (TZ). While this approach
>> ensures secure SE assignment and access control, it limits flexibility for
>> developers who need to enable various protocols on different SEs.
>>
>> Add the firmware-name property to QUPv3 nodes in the device tree to enable
>> firmware loading from the Linux environment. Handle SE assignments and
>> access control permissions directly within Linux, removing the dependency
>> on TrustZone.
>>
>> Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
>> ---
> 
> Viken, you've posted a lot of patches like these lately for
> specific boards.
> 
> Should we instead push this to the SoC DTSI, to limit the boilerplate?

The firmware load from Linux feature is applicable only to devkit boards
(RB3 Gen2 and EVK), and therefore, it is being added exclusively to the
board-specific device tree files.

> 
> If I recall correctly, you said these ELFs are not vendor-signed, so
> it should be OK to have them be assigned globally
> 

This feature is intended solely for use with the development kit and is not
intended for commercialization. Therefore, vendor sign-off is currently not
applicable.

> Konrad

Re: [PATCH v1] arm64: dts: qcom: monaco-evk: Add firmware-name to QUPv3 nodes

[Konrad Dybcio]

On 9/26/25 8:43 AM, Viken Dadhaniya wrote:
> 
> 
> On 9/25/2025 2:22 PM, Konrad Dybcio wrote:
>> On 9/25/25 6:26 AM, Viken Dadhaniya wrote:
>>> Traditionally, firmware loading for Serial Engines (SE) in the QUP hardware
>>> of Qualcomm SoCs has been managed by TrustZone (TZ). While this approach
>>> ensures secure SE assignment and access control, it limits flexibility for
>>> developers who need to enable various protocols on different SEs.
>>>
>>> Add the firmware-name property to QUPv3 nodes in the device tree to enable
>>> firmware loading from the Linux environment. Handle SE assignments and
>>> access control permissions directly within Linux, removing the dependency
>>> on TrustZone.
>>>
>>> Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
>>> ---
>>
>> Viken, you've posted a lot of patches like these lately for
>> specific boards.
>>
>> Should we instead push this to the SoC DTSI, to limit the boilerplate?
> 
> The firmware load from Linux feature is applicable only to devkit boards
> (RB3 Gen2 and EVK), and therefore, it is being added exclusively to the
> board-specific device tree files.

Do we expect GENI_SE_INVALID_PROTO to ever show up on hardware that
can't make use of fw loading though?

>> If I recall correctly, you said these ELFs are not vendor-signed, so
>> it should be OK to have them be assigned globally
>>
> 
> This feature is intended solely for use with the development kit and is not
> intended for commercialization. Therefore, vendor sign-off is currently not
> applicable.

Well you conveniently never really mentioned this in the driver patchset..

Konrad

Re: [PATCH v1] arm64: dts: qcom: monaco-evk: Add firmware-name to QUPv3 nodes

[Viken Dadhaniya]

On 10/22/2025 10:30 PM, Konrad Dybcio wrote:
> On 9/26/25 8:43 AM, Viken Dadhaniya wrote:
>>
>>
>> On 9/25/2025 2:22 PM, Konrad Dybcio wrote:
>>> On 9/25/25 6:26 AM, Viken Dadhaniya wrote:
>>>> Traditionally, firmware loading for Serial Engines (SE) in the QUP hardware
>>>> of Qualcomm SoCs has been managed by TrustZone (TZ). While this approach
>>>> ensures secure SE assignment and access control, it limits flexibility for
>>>> developers who need to enable various protocols on different SEs.
>>>>
>>>> Add the firmware-name property to QUPv3 nodes in the device tree to enable
>>>> firmware loading from the Linux environment. Handle SE assignments and
>>>> access control permissions directly within Linux, removing the dependency
>>>> on TrustZone.
>>>>
>>>> Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
>>>> ---
>>>
>>> Viken, you've posted a lot of patches like these lately for
>>> specific boards.
>>>
>>> Should we instead push this to the SoC DTSI, to limit the boilerplate?
>>
>> The firmware load from Linux feature is applicable only to devkit boards
>> (RB3 Gen2 and EVK), and therefore, it is being added exclusively to the
>> board-specific device tree files.
> 
> Do we expect GENI_SE_INVALID_PROTO to ever show up on hardware that
> can't make use of fw loading though?

If TZ (TrustZone) does not load firmware for any SE, the SE protocol status will
remain GENI_SE_INVALID_PROTO. In such cases, Linux can load the firmware to
initialize the SE and set the required protocol.

> 
>>> If I recall correctly, you said these ELFs are not vendor-signed, so
>>> it should be OK to have them be assigned globally
>>>
>>
>> This feature is intended solely for use with the development kit and is not
>> intended for commercialization. Therefore, vendor sign-off is currently not
>> applicable.
> 
> Well you conveniently never really mentioned this in the driver patchset..
> 
> Konrad

Re: [PATCH v1] arm64: dts: qcom: monaco-evk: Add firmware-name to QUPv3 nodes

[Konrad Dybcio]

On 10/24/25 1:37 PM, Viken Dadhaniya wrote:
> 
> 
> On 10/22/2025 10:30 PM, Konrad Dybcio wrote:
>> On 9/26/25 8:43 AM, Viken Dadhaniya wrote:
>>>
>>>
>>> On 9/25/2025 2:22 PM, Konrad Dybcio wrote:
>>>> On 9/25/25 6:26 AM, Viken Dadhaniya wrote:
>>>>> Traditionally, firmware loading for Serial Engines (SE) in the QUP hardware
>>>>> of Qualcomm SoCs has been managed by TrustZone (TZ). While this approach
>>>>> ensures secure SE assignment and access control, it limits flexibility for
>>>>> developers who need to enable various protocols on different SEs.
>>>>>
>>>>> Add the firmware-name property to QUPv3 nodes in the device tree to enable
>>>>> firmware loading from the Linux environment. Handle SE assignments and
>>>>> access control permissions directly within Linux, removing the dependency
>>>>> on TrustZone.
>>>>>
>>>>> Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
>>>>> ---
>>>>
>>>> Viken, you've posted a lot of patches like these lately for
>>>> specific boards.
>>>>
>>>> Should we instead push this to the SoC DTSI, to limit the boilerplate?
>>>
>>> The firmware load from Linux feature is applicable only to devkit boards
>>> (RB3 Gen2 and EVK), and therefore, it is being added exclusively to the
>>> board-specific device tree files.
>>
>> Do we expect GENI_SE_INVALID_PROTO to ever show up on hardware that
>> can't make use of fw loading though?
> 
> If TZ (TrustZone) does not load firmware for any SE, the SE protocol status will
> remain GENI_SE_INVALID_PROTO. In such cases, Linux can load the firmware to
> initialize the SE and set the required protocol.

So.. where is the problem?

Konrad

Re: [PATCH v1] arm64: dts: qcom: monaco-evk: Add firmware-name to QUPv3 nodes

[Bjorn Andersson]

On Thu, 25 Sep 2025 09:56:05 +0530, Viken Dadhaniya wrote:
> Traditionally, firmware loading for Serial Engines (SE) in the QUP hardware
> of Qualcomm SoCs has been managed by TrustZone (TZ). While this approach
> ensures secure SE assignment and access control, it limits flexibility for
> developers who need to enable various protocols on different SEs.
> 
> Add the firmware-name property to QUPv3 nodes in the device tree to enable
> firmware loading from the Linux environment. Handle SE assignments and
> access control permissions directly within Linux, removing the dependency
> on TrustZone.
> 
> [...]

Applied, thanks!

[1/1] arm64: dts: qcom: monaco-evk: Add firmware-name to QUPv3 nodes
      commit: 30b5167b808c5a7eb8559bbd296fce14cb62e58d

Best regards,
-- 
Bjorn Andersson <andersson@kernel.org>