[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 at 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
>>
>>
>