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;
MIME-Version: 1.0
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> <Y30LXW5Elcur5mlI@e120937-lin>
 <0b24b15bfee6d97d23caf0225d264c14e0ed48f1.camel@axis.com> <Y4X35fXiPHQ5b0cG@e120937-lin>
In-Reply-To: <Y4X35fXiPHQ5b0cG@e120937-lin>
From:   Etienne Carriere <etienne.carriere@linaro.org>
Date:   Tue, 29 Nov 2022 15:57:50 +0100
Message-ID: <CAN5uoS8pFOLqZ3Jd7rHCisUcJvVkfWQqnOE=DUGyC3EURGLsFg@mail.gmail.com>
Subject: Re: [PATCH] firmware: arm_scmi: Resolve dependency with TEE subsystem
To:     Cristian Marussi <cristian.marussi@arm.com>
Cc:     =?UTF-8?Q?Ludvig_P=C3=A4rsson?= <Ludvig.Parsson@axis.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>,
        "sudeep.holla@arm.com" <sudeep.holla@arm.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hi Cristian, Ludvig,

For info, I've tested your patches Cristian on my setup.
they did the job for probing optee transport at module initcall level.

br,
etienne

On Tue, 29 Nov 2022 at 13:15, Cristian Marussi <cristian.marussi@arm.com> w=
rote:
>
> On Tue, Nov 29, 2022 at 10:49:10AM +0000, Ludvig P=C3=A4rsson 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=C3=A4rsson 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