[PATCH] Revert "arm64: zynqmp: Add an OP-TEE node to the device tree"

[PATCH] Revert "arm64: zynqmp: Add an OP-TEE node to the device tree"

[Tomas Melin]

This reverts commit 06d22ed6b6635b17551f386b50bb5aaff9b75fbe.

OP-TEE logic in U-Boot automatically injects a reserved-memory
node along with optee firmware node to kernel device tree.
The injection logic is dependent on that there is no manually
defined optee node. Having the node in zynqmp.dtsi effectively
breaks OP-TEE's insertion of the reserved-memory node, causing
memory access violations during runtime.

Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
---
For further information about the U-Boot logic related
to this, see lib/optee/optee.c in U-Boot repository.
---
 arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
index 938b014ca9231d265314c0d6a934d0be706e420b..b55c6b2e8e0e10916fdfe762f9b6ae04f89a2cfc 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
+++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
@@ -192,11 +192,6 @@ psci {
 	};
 
 	firmware {
-		optee: optee  {
-			compatible = "linaro,optee-tz";
-			method = "smc";
-		};
-
 		zynqmp_firmware: zynqmp-firmware {
 			compatible = "xlnx,zynqmp-firmware";
 			#power-domain-cells = <1>;

---
base-commit: ac3fd01e4c1efce8f2c054cdeb2ddd2fc0fb150d
change-id: 20251125-revert-zynqmp-optee-a9d77159b243

Best regards,
-- 
Tomas Melin <tomas.melin@vaisala.com>

Re: [PATCH] Revert "arm64: zynqmp: Add an OP-TEE node to the device tree"

[Michal Simek]

On 11/25/25 08:53, Tomas Melin wrote:
> This reverts commit 06d22ed6b6635b17551f386b50bb5aaff9b75fbe.
> 
> OP-TEE logic in U-Boot automatically injects a reserved-memory
> node along with optee firmware node to kernel device tree.
> The injection logic is dependent on that there is no manually
> defined optee node. Having the node in zynqmp.dtsi effectively
> breaks OP-TEE's insertion of the reserved-memory node, causing
> memory access violations during runtime.
> 
> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> ---
> For further information about the U-Boot logic related
> to this, see lib/optee/optee.c in U-Boot repository.

What's the behavior with EDK2?

U-Boot also have optee driver. How is it probed when you remove this node?

Thanks,
Michal

Re: [PATCH] Revert "arm64: zynqmp: Add an OP-TEE node to the device tree"

[Tomas Melin]

Hi,

On 25/11/2025 12:30, Michal Simek wrote:
> 
> 
> On 11/25/25 08:53, Tomas Melin wrote:
>> This reverts commit 06d22ed6b6635b17551f386b50bb5aaff9b75fbe.
>>
>> OP-TEE logic in U-Boot automatically injects a reserved-memory
>> node along with optee firmware node to kernel device tree.
>> The injection logic is dependent on that there is no manually
>> defined optee node. Having the node in zynqmp.dtsi effectively
>> breaks OP-TEE's insertion of the reserved-memory node, causing
>> memory access violations during runtime.
>>
>> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
>> ---
>> For further information about the U-Boot logic related
>> to this, see lib/optee/optee.c in U-Boot repository.
> 
> What's the behavior with EDK2?
Sorry, I cannot comment on that.

> 
> U-Boot also have optee driver. How is it probed when you remove this node?
This is about the injection of the nodes to the kernel device tree. So
in the U-Boot side, optee driver can be enabled or not. This passing of
the optee nodes will happen outside of optee driver context (image-fdt).
The OP-TEE logic will not insert the required reserved memory regions
into the kernel side devicetree in case the node is already present and
that is a real problem.
If this change eventually is mapped from kernel to U-Boot side, OP-TEE
needs to be enabled by boards that use OP-TEE from U-Boot. But that
sounds logical and how it was before, why would OP-TEE be automatically
enabled.

Thanks,
Tomas


> 
> Thanks,
> Michal
> 
> 

Re: [PATCH] Revert "arm64: zynqmp: Add an OP-TEE node to the device tree"

[Tomas Melin]

Hi,

Is there some more specific information I can provide regarding this patch?

Thanks,
Tomas


On 25/11/2025 13:42, Tomas Melin wrote:
> Hi,
> 
> On 25/11/2025 12:30, Michal Simek wrote:
>>
>>
>> On 11/25/25 08:53, Tomas Melin wrote:
>>> This reverts commit 06d22ed6b6635b17551f386b50bb5aaff9b75fbe.
>>>
>>> OP-TEE logic in U-Boot automatically injects a reserved-memory
>>> node along with optee firmware node to kernel device tree.
>>> The injection logic is dependent on that there is no manually
>>> defined optee node. Having the node in zynqmp.dtsi effectively
>>> breaks OP-TEE's insertion of the reserved-memory node, causing
>>> memory access violations during runtime.
>>>
>>> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
>>> ---
>>> For further information about the U-Boot logic related
>>> to this, see lib/optee/optee.c in U-Boot repository.
>>
>> What's the behavior with EDK2?
> Sorry, I cannot comment on that.
> 
>>
>> U-Boot also have optee driver. How is it probed when you remove this node?
> This is about the injection of the nodes to the kernel device tree. So
> in the U-Boot side, optee driver can be enabled or not. This passing of
> the optee nodes will happen outside of optee driver context (image-fdt).
> The OP-TEE logic will not insert the required reserved memory regions
> into the kernel side devicetree in case the node is already present and
> that is a real problem.
> If this change eventually is mapped from kernel to U-Boot side, OP-TEE
> needs to be enabled by boards that use OP-TEE from U-Boot. But that
> sounds logical and how it was before, why would OP-TEE be automatically
> enabled.
> 
> Thanks,
> Tomas
> 
> 
>>
>> Thanks,
>> Michal
>>
>>
> 

Re: [PATCH] Revert "arm64: zynqmp: Add an OP-TEE node to the device tree"

[Michal Simek]

Hi,

On 12/12/25 13:09, Tomas Melin wrote:
> Hi,
> 
> Is there some more specific information I can provide regarding this patch?

I am trying to identify U-Boot code (2026.01-rc4) which does what you have 
described in the commit message but I can't find it out.
Can you please point me directly to file, line number where that described logic 
is skipped?

Thanks,
Michal

Re: [PATCH] Revert "arm64: zynqmp: Add an OP-TEE node to the device tree"

[Tomas Melin]

Hi,

On 15/12/2025 17:21, Michal Simek wrote:
> Hi,
> 
> On 12/12/25 13:09, Tomas Melin wrote:
>> Hi,
>>
>> Is there some more specific information I can provide regarding this patch?
> 
> I am trying to identify U-Boot code (2026.01-rc4) which does what you have 
> described in the commit message but I can't find it out.
> Can you please point me directly to file, line number where that described logic 
> is skipped?

Please check lib/optee/optee.c, in particular lines 128 ->
Target dt being linux kernel devicetree where the reserved-memory nodes
are automatically injected. When node is already there, it bails out early.

thanks,
Tomas


> 
> Thanks,
> Michal

Re: [PATCH] Revert "arm64: zynqmp: Add an OP-TEE node to the device tree"

[Michal Simek]

On 12/15/25 16:43, Tomas Melin wrote:
> Hi,
> 
> On 15/12/2025 17:21, Michal Simek wrote:
>> Hi,
>>
>> On 12/12/25 13:09, Tomas Melin wrote:
>>> Hi,
>>>
>>> Is there some more specific information I can provide regarding this patch?
>>
>> I am trying to identify U-Boot code (2026.01-rc4) which does what you have
>> described in the commit message but I can't find it out.
>> Can you please point me directly to file, line number where that described logic
>> is skipped?
> 
> Please check lib/optee/optee.c, in particular lines 128 ->
> Target dt being linux kernel devicetree where the reserved-memory nodes
> are automatically injected. When node is already there, it bails out early.

I don't really mind that's why applied.

Thanks,
Michal

Re: [PATCH] Revert "arm64: zynqmp: Add an OP-TEE node to the device tree"

[Tomas Melin]

On 15/12/2025 18:10, Michal Simek wrote:
>
>
> On 12/15/25 16:43, Tomas Melin wrote:
>> Hi,
>>
>> On 15/12/2025 17:21, Michal Simek wrote:
>>> Hi,
>>>
>>> On 12/12/25 13:09, Tomas Melin wrote:
>>>> Hi,
>>>>
>>>> Is there some more specific information I can provide regarding this patch?
>>>
>>> I am trying to identify U-Boot code (2026.01-rc4) which does what you have
>>> described in the commit message but I can't find it out.
>>> Can you please point me directly to file, line number where that described logic
>>> is skipped?
>>
>> Please check lib/optee/optee.c, in particular lines 128 ->
>> Target dt being linux kernel devicetree where the reserved-memory nodes
>> are automatically injected. When node is already there, it bails out early.
>
> I don't really mind that's why applied.
Sorry I didn't really understand, where is it applied?

BR,
Tomas

>
> Thanks,
> Michal
>
>

Re: [PATCH] Revert "arm64: zynqmp: Add an OP-TEE node to the device tree"

[Michal Simek]

On 12/16/25 08:00, Tomas Melin wrote:
> On 15/12/2025 18:10, Michal Simek wrote:
>>
>>
>> On 12/15/25 16:43, Tomas Melin wrote:
>>> Hi,
>>>
>>> On 15/12/2025 17:21, Michal Simek wrote:
>>>> Hi,
>>>>
>>>> On 12/12/25 13:09, Tomas Melin wrote:
>>>>> Hi,
>>>>>
>>>>> Is there some more specific information I can provide regarding this patch?
>>>>
>>>> I am trying to identify U-Boot code (2026.01-rc4) which does what you have
>>>> described in the commit message but I can't find it out.
>>>> Can you please point me directly to file, line number where that described logic
>>>> is skipped?
>>>
>>> Please check lib/optee/optee.c, in particular lines 128 ->
>>> Target dt being linux kernel devicetree where the reserved-memory nodes
>>> are automatically injected. When node is already there, it bails out early.
>>
>> I don't really mind that's why applied.
> Sorry I didn't really understand, where is it applied?

https://github.com/Xilinx/linux-xlnx/tree/zynqmp/dt

And it is from today also in linux-next
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/arch/arm64/boot/dts/xilinx/zynqmp.dtsi?h=next-20251216

At the end of cycle it will go via soc tree to Linus.

Thanks,
Michal