Hi Jan,
This handler is expected to ensure that the address is valid in the client translation regime. Per the porting guide, the handler is optional and depends on the software stack running on the platform.
If you can guarantee that the entrypoint address will always be valid in the client translation regime, then the handler need not be implemented e.g. a client always uses physical address for the entrypoint.
The Tegra handler can be enhanced to ensure that the client provided entrypoint address is a valid memory address, at the very least.
-Varun
-----Original Message----- From: Jan Kiszka jan.kiszka@web.de Sent: Saturday, September 26, 2020 6:22 AM To: tf-a@lists.trustedfirmware.org; Jeenu Viswambharan jeenu.viswambharan@arm.com; Peng Fan peng.fan@nxp.com; Varun Wadekar vwadekar@nvidia.com; Siva Durga Prasad Paladugu siva.durga.paladugu@xilinx.com; Jacky Bai ping.bai@nxp.com Subject: When to implement plat_sdei_validate_entry_point?
External email: Use caution opening links or attachments
Hi,
I'm adding basic SDEI support to the zynqmp platform (just private event 0 for now), and I'm wondering what to do with plat_sdei_validate_entry_point().
Looking around what other SDEI implementations did, neither tegra nor the recently added imx8mm implement this and rather rely on the empty stub from plat/common/aarch64/plat_common.c. As zynqmp also pulls in plat/arm/common/arm_common.c and doesn't find any arm_validate_ns_entrypoint, my search started.
Is there anything that makes the check for tegra and imx8mm unneeded? Or are they both broken and should better use plat_sdei_validate_entry_point from plat/arm/common/arm_common.c?
Thanks, Jan