lkml.org 
[lkml]   [2022]   [Nov]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] firmware: arm_scmi: Resolve dependency with TEE subsystem
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

\
 
 \ /
  Last update: 2022-11-22 18:53    [W:0.110 / U:0.376 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site