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

[Cristian Marussi]

On Tue, Nov 29, 2022 at 10:49:10AM +0000, Ludvig Pärsson wrote:
> 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,

Hi,

> 
> 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!
> 

Great, thanks for testing it.
I'll post shortly a cleaned up series aiming at the next release cycle.

Thanks,
Cristian