[lkml]   [2022]   [Nov]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
SubjectRe: [PATCH] firmware: arm_scmi: Resolve dependency with TEE subsystem
Hi Sudeep,

On Fri, 11 Nov 2022 at 20:08, Sudeep Holla <> wrote:
> On Fri, Nov 11, 2022 at 03:23:13PM +0530, Sumit Garg wrote:
> > The OP-TEE SCMI transport channel is dependent on TEE subsystem to be
> > initialized first. But currently the Arm SCMI subsystem and TEE
> > subsystem are invoked on the same initcall level as subsystem_init().
> >
> > It is observed that the SCMI subsystem initcall is invoked prior to TEE
> > subsystem initcall. This leads to unwanted error messages regarding TEE
> > bus is not present yet. Although, -EPROBE_DEFER tries to workaround that
> > problem.
> >
> > Lets try to resolve inter subsystem dependency problem via shifting Arm
> > SCMI subsystem to subsystem_init_sync() initcall level.
> >
> I would avoid doing that. We already have some implicit dependency with
> subsys_initcall because this driver creates/registers bus and need to be
> done early.

Yeah but that should work fine with subsystem_init_sync() too unless
you have drivers being registered on the bus at subsystem_init_sync()
initcall which doesn't seem to be the case in mainline. Have a look at
usage of subsystem_init_sync() elsewhere to see its similar usage to
resolve dependencies among different subsystems.

However, if you are too skeptical regarding this change then we can
limit it to OP-TEE transport only as follows:

diff --git a/drivers/firmware/arm_scmi/driver.c
index f43e52541da4..19c1222b3dfc 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -2667,7 +2667,11 @@ static int __init scmi_driver_init(void)

return platform_driver_register(&scmi_driver);

static void __exit scmi_driver_exit(void)
> Now in order to solve the dependency between SCMI and TEE,
> both of which creates/registers bus and are at same subsys_initcall,
> we are relying on subsys_initcall_sync.


> Me and Ludvig discussed this in private and I suggested him to do something
> like below patch snippet. He mentioned he did post a patch on the list but
> I couldn't find it. For this the scmi node must be child node of OPTEE as
> it is providing the transport.

TBH, the first thought that came to mind after looking at SCMI OP-TEE
DT node was that why do we need it when those properties can be probed
from SCMI pseudo TA at runtime? Maybe I am missing something as I
wasn't involved in its review process.

The whole idea of TEE bus evolved from the idea that if the firmware
bits can be probed at runtime then we shouldn't use DT as a dumping
ground for those. I hope you remember discussions around discoverable
FF-A bus too.

However, the change below is simply an incorrect way to fix the actual
inter subsystem dependency problem via DT. How would this fix the
problem in the case OP-TEE driver registers on FF-A bus? There won't
be any DT node for OP-TEE in that case.


> @Ludvig, ?
> Regards,
> Sudeep
> --
> diff --git i/drivers/tee/optee/smc_abi.c w/drivers/tee/optee/smc_abi.c
> index a1c1fa1a9c28..839feca0def4 100644
> --- i/drivers/tee/optee/smc_abi.c
> +++ w/drivers/tee/optee/smc_abi.c
> @@ -1534,7 +1534,9 @@ static int optee_probe(struct platform_device *pdev)
> goto err_disable_shm_cache;
> pr_info("initialized driver\n");
> - return 0;
> +
> + /* Populate any dependent child node(if any) */
> + return devm_of_platform_populate(&pdev->dev);
> err_disable_shm_cache:
> if (!optee->rpc_param_count)

 \ /
  Last update: 2022-11-14 07:32    [W:0.117 / U:0.708 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site