On Wed, 21 Feb 2024 at 22:28, Marc Gonzalez mgonzalez@freebox.fr wrote:

On 21/02/2024 08:40, Sumit Garg wrote:

...

Hi Marc,

On Tue, 20 Feb 2024 at 22:59, Marc Gonzalez wrote:

...

Hello,

The driver code I'm working on hard-codes

#define TEE_SMC_FAST_CALL_VAL(func_num) \ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_SMC_32, \ ARM_SMCCC_OWNER_TRUSTED_OS, (func_num))

#define TEE_SMC_FUNCID_CALLS_UID 0xFF01 #define TEE_SMC_CALLS_UID \ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_SMC_32, \ ARM_SMCCC_OWNER_TRUSTED_OS_END, \ TEE_SMC_FUNCID_CALLS_UID)

arm_smccc_smc(TEE_SMC_CALLS_UID,
        0, 0, 0/*is_swap*/, 0, 0, 0, 0, &res);
dev_err(dev, "TEE UID %x %x %x %x\n", res.a0, res.a1, res.a2, res.a3);

but it seems I would be required to somehow use OPTEE_SMC_CALL_GET_OS_UUID

But it's not exported, and no code seems to use it...?

Can you describe your use-case to require direct OPTEE_SMC_CALL_GET_OS_UUID invocation?

Turns out the GET_OS_UUID call was just debug code to make sure we were getting the expected reply.

I have removed it from the production code. Below is the current code.

diff --git a/drivers/staging/media/meson/vdec/vdec_1.c b/drivers/staging/media/meson/vdec/vdec_1.c index 3fe2de0c9331f..120bb1847aa38 100644 --- a/drivers/staging/media/meson/vdec/vdec_1.c +++ b/drivers/staging/media/meson/vdec/vdec_1.c @@ -8,7 +8,10 @@ */

#include <linux/firmware.h> +#include <linux/delay.h> #include <linux/clk.h> +#include <linux/arm-smccc.h> +#include <soc/amlogic/socinfo.h>

#include "vdec_1.h" #include "vdec_helpers.h" @@ -22,6 +25,45 @@

#define MC_SIZE (4096 * 4)

+static int +vdec_1_load_firmware_optee(struct amvdec_session *sess) +{

•   struct amvdec_codec_ops *codec_ops = sess->fmt_out->codec_ops;
  

•   struct amvdec_core *core = sess->core;
  

•   struct device *dev = core->dev_dec;
  

•   struct arm_smccc_res res;
  

•   u32 pixfmt = sess->fmt_out->pixfmt;
  

•   int fw_id = -1;
  

+#define TEE_SMC_FAST_CALL_VAL(func_num) \

•   ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_SMC_32, ARM_SMCCC_OWNER_TRUSTED_OS, (func_num))
  

+#define TEE_SMC_FUNCID_LOAD_VIDEO_FW 15 +#define TEE_SMC_LOAD_VIDEO_FW TEE_SMC_FAST_CALL_VAL(TEE_SMC_FUNCID_LOAD_VIDEO_FW) +#define OPTEE_VDEC_LEGACY 0 +#define VIDEO_DEC_MPEG12 0 +#define VIDEO_DEC_H264 11

•   // Load wrong firmware, so that TA will reset hw component for us
  

•   arm_smccc_smc(TEE_SMC_LOAD_VIDEO_FW, 1, OPTEE_VDEC_LEGACY, 0, 0, 0, 0, 0, &res);
  

•   if (pixfmt == V4L2_PIX_FMT_H264)
  

•           fw_id = 11;
  

•   if (pixfmt == V4L2_PIX_FMT_MPEG1 || pixfmt == V4L2_PIX_FMT_MPEG2)
  

•           fw_id = 0;
  

•   arm_smccc_smc(TEE_SMC_LOAD_VIDEO_FW, fw_id, OPTEE_VDEC_LEGACY, 0, 0, 0, 0, 0, &res);
  

•   dev_info(dev, "Load firmware %d: ret=%d\n", fw_id, res.a0);
  

•   msleep(100);
  

•   if (codec_ops->load_extended_firmware)
  

•           codec_ops->load_extended_firmware(sess, 0, 0);
  

•   return 0;
  

+}

static int vdec_1_load_firmware(struct amvdec_session *sess, const char *fwname) { @@ -209,7 +251,11 @@ static int vdec_1_start(struct amvdec_session *sess)

    vdec_1_stbuf_power_up(sess);

•   ret = vdec_1_load_firmware(sess, sess->fmt_out->firmware_path);
  

•   if (meson_get_secure_boot_state() == 1)
  

•           ret = vdec_1_load_firmware_optee(sess);
  

•   else
  

•           ret = vdec_1_load_firmware(sess, sess->fmt_out->firmware_path);
  

•   if (ret)
            goto stop;
  
  

@@ -232,6 +278,13 @@ static int vdec_1_start(struct amvdec_session *sess) /* Let the firmware settle */ usleep_range(10, 20);

•   /*
  

•    * When running secure boot, it looks like the codec needs
  

•    * more time to settle (perhaps to authenticate the image?)
  

•    */
  

•   if (meson_get_secure_boot_state() == 1)
  

•           msleep(100);
  

•   return 0;
  
  

stop:

...

...

$ git grep OPTEE_SMC_CALL_GET_OS_UUID Documentation/tee/op-tee.rst:- OPTEE_SMC_CALL_GET_OS_UUID returns the particular OP-TEE implementation, used drivers/tee/optee/optee_smc.h:#define OPTEE_SMC_CALL_GET_OS_UUID \

How do I make calls to OP-TEE from driver code?

The TEE driver API documentation is here [1] and you can refer to the existing OP-TEE RNG driver here for reference.

[1] https://docs.kernel.org/driver-api/tee.html [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/driv...

Wow, this looks very different from our code.

Are we not supposed to call arm_smccc_smc() from driver code?

Yes, all OP-TEE invocations are abstracted out via the TEE bus driver framework. You can find other examples with a simple grep like:

$ git grep -nr "tee_bus_type"

Looks like no one else is calling arm_smccc_smc with an owner equal to ARM_SMCCC_OWNER_TRUSTED_OS...

BTW, looking at your use-case it sounds somewhat similar (load a firmware via OP-TEE) to this [1]. So you can take that as a reference for your driver development.

[1] https://lore.kernel.org/linux-arm-kernel/20240214172127.1022199-3-arnaud.pou...

-Sumit