Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 22 Nov 2022 17:48:13 +0000
From:   Cristian Marussi <cristian.marussi@arm.com>
To:     Ludvig =?iso-8859-1?Q?P=E4rsson?= <Ludvig.Parsson@axis.com>
Cc:     "etienne.carriere@linaro.org" <etienne.carriere@linaro.org>,
        "sudeep.holla@arm.com" <sudeep.holla@arm.com>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        "jens.wiklander@linaro.org" <jens.wiklander@linaro.org>,
        "sumit.garg@linaro.org" <sumit.garg@linaro.org>,
        "vincent.guittot@linaro.org" <vincent.guittot@linaro.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] firmware: arm_scmi: Resolve dependency with TEE subsystem
Message-ID: <Y30LXW5Elcur5mlI@e120937-lin>
References: <20221111095313.2010815-1-sumit.garg@linaro.org>
 <20221111143800.k7xje6g23ujefnye@bogus>
 <CAFA6WYMdNjbMRZxt3iicmKOhQa3ax7_HYtqmNN9bmpndqT8e9A@mail.gmail.com>
 <20221114102650.qwkaxtnstujaiu6u@bogus>
 <CAN5uoS8SArNmaxwhJ=tRCPD8ue1D8VvQyLacDDS2sunfg4gLbw@mail.gmail.com>
 <b0bc03f9f2a5afbe3a77b81648a765348073cc36.camel@axis.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <b0bc03f9f2a5afbe3a77b81648a765348073cc36.camel@axis.com>
Precedence: bulk

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