All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cristian Marussi <cristian.marussi@arm.com>
To: "Ludvig Pärsson" <Ludvig.Parsson@axis.com>
Cc: "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>,
	"etienne.carriere@linaro.org" <etienne.carriere@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>
Subject: Re: [PATCH] firmware: arm_scmi: Resolve dependency with TEE subsystem
Date: Tue, 29 Nov 2022 12:15:33 +0000	[thread overview]
Message-ID: <Y4X35fXiPHQ5b0cG@e120937-lin> (raw)
In-Reply-To: <0b24b15bfee6d97d23caf0225d264c14e0ed48f1.camel@axis.com>

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Cristian Marussi <cristian.marussi@arm.com>
To: "Ludvig Pärsson" <Ludvig.Parsson@axis.com>
Cc: "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>,
	"etienne.carriere@linaro.org" <etienne.carriere@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>
Subject: Re: [PATCH] firmware: arm_scmi: Resolve dependency with TEE subsystem
Date: Tue, 29 Nov 2022 12:15:33 +0000	[thread overview]
Message-ID: <Y4X35fXiPHQ5b0cG@e120937-lin> (raw)
In-Reply-To: <0b24b15bfee6d97d23caf0225d264c14e0ed48f1.camel@axis.com>

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

  reply	other threads:[~2022-11-29 12:16 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-11  9:53 [PATCH] firmware: arm_scmi: Resolve dependency with TEE subsystem Sumit Garg
2022-11-11  9:53 ` Sumit Garg
2022-11-11 14:38 ` Sudeep Holla
2022-11-11 14:38   ` Sudeep Holla
2022-11-11 15:00   ` Ludvig Pärsson
2022-11-11 15:00     ` Ludvig Pärsson
2022-11-11 15:13     ` Sudeep Holla
2022-11-11 15:13       ` Sudeep Holla
2022-11-14  6:31   ` Sumit Garg
2022-11-14  6:31     ` Sumit Garg
2022-11-14 10:26     ` Sudeep Holla
2022-11-14 10:26       ` Sudeep Holla
2022-11-14 11:29       ` Etienne Carriere
2022-11-14 11:29         ` Etienne Carriere
2022-11-14 13:47         ` Ludvig Pärsson
2022-11-14 13:47           ` Ludvig Pärsson
2022-11-22 17:48           ` Cristian Marussi
2022-11-22 17:48             ` Cristian Marussi
2022-11-29 10:49             ` Ludvig Pärsson
2022-11-29 10:49               ` Ludvig Pärsson
2022-11-29 12:15               ` Cristian Marussi [this message]
2022-11-29 12:15                 ` Cristian Marussi
2022-11-29 14:57                 ` Etienne Carriere
2022-11-29 14:57                   ` Etienne Carriere
2022-11-29 17:30                   ` Cristian Marussi
2022-11-29 17:30                     ` Cristian Marussi
2022-11-17  9:41         ` Sumit Garg
2022-11-17  9:41           ` Sumit Garg
2022-11-17 11:19           ` Sudeep Holla
2022-11-17 11:19             ` Sudeep Holla

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y4X35fXiPHQ5b0cG@e120937-lin \
    --to=cristian.marussi@arm.com \
    --cc=Ludvig.Parsson@axis.com \
    --cc=etienne.carriere@linaro.org \
    --cc=jens.wiklander@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sudeep.holla@arm.com \
    --cc=sumit.garg@linaro.org \
    --cc=vincent.guittot@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.