Re: [PATCH] firmware: arm_scmi: Resolve dependency with TEE subsystem

From: Ludvig Pärsson
Date: Tue Nov 29 2022 - 05:49:31 EST


On Tue, 2022-11-22 at 17:48 +0000, Cristian Marussi wrote:
> On Mon, Nov 14, 2022 at 01:47:25PM +0000, Ludvig Pärsson wrote:
> > On Mon, 2022-11-14 at 12:29 +0100, Etienne Carriere wrote:
> > > Hello all,
> > >
>
> Hi Ludvig,
>
> following up on the issues raised by this thread and a few proposals
> that
> were flying around (online and offline), in the past days I took the
> chance
> to have a go at a substantial rework of the init/probe sequences in
> the SCMI
> core to address the issue you faced with SCMI TEE transport while
> trying to
> untangle a bit the SCMI core startup sequences (... while also
> possibly not
> breaking it all :P...)
>
> In a nutshell, building on an idea from an offline chat with Etienne
> ad
> Sudeep, now the SCMI bus initialization is split on its own and
> initialized at
> subsys_initcall level, while the SCMI core stack, including the the
> SCMI TEE
> transport layer, is moved at module_init layer together with the SCMI
> driver users.
>
> This *should* theoretically solve your issue ... (and it seems like
> all the
> rest it's still working :P) ... so I was wondering if you can give a
> go
> at the following pachset on your setup:
>
> https://gitlab.arm.com/linux-arm/linux-cm/-/commits/scmi_rework_stack_init_draft/
>
> ... note that this is just a draft at the moment, which has undergone
> a
> reasonable amount of testing on mailbox/virtio transports only in
> both a
> SCMI builtin and/or modules scenario, but is no where ready for
> review.
>
> The top three patches are really what you need BUT these are probably
> tightly bound to that bunch of early fixes you can see in the
> branch...so in other words better if you pick the whole branch for
> testing :D
>
> Once you've confirmed me that this solves your issues I'll start the
> final cleanup for posting in the next cycle.
>
> Thanks,
> Cristian

Hi Cristian,

I tried my best to get the patchset to work somehow on my version of
the kernel, and it seems to be working great. I played around with some
things, for example changing order of some drivers that were on the
same init levels, and it still worked. Only tested with voltage domain
protocol and optee transport.

Thanks for your great work!

BR,
Ludvig