All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cristian Marussi <cristian.marussi@arm.com>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: Cristian Marussi <cristian.marussi@arm.com>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, arm-scmi@vger.kernel.org,
	sudeep.holla@arm.com, james.quinlan@broadcom.com,
	vincent.guittot@linaro.org, etienne.carriere@st.com,
	peng.fan@oss.nxp.com, michal.simek@amd.com,
	quic_sibis@quicinc.com, quic_nkela@quicinc.com, ptosi@google.com,
	dan.carpenter@linaro.org, souvik.chakravarty@arm.com
Subject: Re: [PATCH v3 0/9] Make SCMI transport as standalone drivers
Date: Tue, 6 Aug 2024 18:01:26 +0100	[thread overview]
Message-ID: <ZrJW2jFpNqJDXMTh@pluto> (raw)
In-Reply-To: <6c2b185e-42d4-408b-a7f5-972b2099067b@gmail.com>

On Tue, Aug 06, 2024 at 09:47:17AM -0700, Florian Fainelli wrote:
> On 7/30/24 06:33, Cristian Marussi wrote:
> > Hi all,
> > 
> > Till now the SCMI transport layer was being built embedded into in the core
> > SCMI stack.
> > 
> > Some of these transports, despite being currently part of the main SCMI
> > module, are indeed also registered with different subsystems like optee or
> > virtio, and actively probed also by those: this led to a few awkward and
> > convoluted tricks to properly handle such interactions at boot time in the
> > SCMI stack.
> > 
> > Moreover some partner expressed the desire to be able to fully modularize
> > the transports components.
> > 
> > This series aim to make all such transports as standalone drivers that can
> > be optionally loaded as modules.
> > 
> > In order to do this, at first some new mechanism is introduced to support
> > this new capability while maintaining, in parallel, the old legacy embedded
> > transports; then each transport, one by one, is transitioned to be a
> > standalone driver and finally the old legacy support for embedded transport
> > is removed.
> > 
> > Patch [1/9] is a fix around the chan_free method for OPTEE transport; it is
> > really unrelated to this series, but included to avoid conflicts.
> > 
> > Patch [2/9] is a mostly unrelated (but much needed) clean-up from Peng,
> > which I included in this series to avoid conflicts at merge.
> > 
> > Patch [3/9] simply collects the existing datagram manipulation helpers in a
> > pair of function pointers structures, in preparation for later reworks.
> > 
> > Patch [4/9] adds the bulk of the new logic to the core SCMI stack and then
> > each existing transport is transitioned to be a standalone driver in
> > patches 5,6,7,8 while shuffling around the compatibles. (no DT change is
> > needed of curse for backward compatibility)
> > While doing this I kept the module authorship in line with the main
> > author(S) as spitted out by git-blame.
> > 
> > Finally patch [9/9] removes all the legacy dead code from the core SCMI
> > stack.
> > 
> > No new symbol EXPORT has been added.
> > 
> > The new transport drivers have been tested, as built-in and LKM, as
> > follows:
> > 
> > - mailbox on JUNO
> > - virtio on emulation
> > - optee on QEMU/optee using Linaro setup
> > 
> > Exercised using the regular SCMI drivers stack and the SCMI ACS suite,
> > testing commands, replies, delayed responses and notification.
> > 
> > Multiple virtual SCMI instances support has been tested too.
> > 
> > SMC has NOT been tested/exercised at run-time, only compile-tested.
> > (due to lack of hardware)
> > 
> > Note that in this new setup, all the probe deferral and retries between the
> > SCMI core stack and the transports has been removed, since no more needed.
> > 
> > Moreover the new drivers have been tested also with a fully modularized
> > SCMI stack, i.e.:
> > 
> >    scmi-core.ko + scmi-module.ko + scmi_transport_*.ko [ + vendor modules ]
> > 
> > Based on v6.11-rc1
> > 
> > Any feedback, and especially testing (:D) is welcome.
> 
> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>

Thanks !
Cristian

      reply	other threads:[~2024-08-06 17:01 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-30 13:33 [PATCH v3 0/9] Make SCMI transport as standalone drivers Cristian Marussi
2024-07-30 13:33 ` [PATCH v3 1/9] firmware: arm_scmi: Fix double free in OPTEE transport Cristian Marussi
2024-07-30 14:37   ` Peng Fan
2024-07-30 13:33 ` [PATCH v3 2/9] firmware: arm_scmi: Introduce setup_shmem_iomap Cristian Marussi
2024-07-30 13:33 ` [PATCH v3 3/9] firmware: arm_scmi: Introduce packet handling helpers Cristian Marussi
2024-07-30 13:33 ` [PATCH v3 4/9] firmware: arm_scmi: Add support for standalone transport drivers Cristian Marussi
2024-07-30 13:33 ` [PATCH v3 5/9] firmware: arm_scmi: Make MBOX transport a standalone driver Cristian Marussi
2024-08-06 13:12   ` Sudeep Holla
2024-08-06 14:59     ` Cristian Marussi
2024-07-30 13:33 ` [PATCH v3 6/9] firmware: arm_scmi: Make SMC " Cristian Marussi
2024-08-01 18:46   ` Nikunj Kela
2024-08-01 19:21     ` Cristian Marussi
2024-07-30 13:33 ` [PATCH v3 7/9] firmware: arm_scmi: Make OPTEE " Cristian Marussi
2024-07-31  6:12   ` Krzysztof Kozlowski
2024-08-01 19:22     ` Cristian Marussi
2024-07-30 13:33 ` [PATCH v3 8/9] firmware: arm_scmi: Make VirtIO " Cristian Marussi
2024-07-31  6:11   ` Krzysztof Kozlowski
2024-08-01 19:25     ` Cristian Marussi
2024-07-30 13:33 ` [PATCH v3 9/9] firmware: arm_scmi: Remove legacy transport-layer code Cristian Marussi
2024-07-31 13:12 ` [PATCH v3 0/9] Make SCMI transport as standalone drivers Peng Fan
2024-08-01 18:41 ` Nikunj Kela
2024-08-06 16:47 ` Florian Fainelli
2024-08-06 17:01   ` Cristian Marussi [this message]

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=ZrJW2jFpNqJDXMTh@pluto \
    --to=cristian.marussi@arm.com \
    --cc=arm-scmi@vger.kernel.org \
    --cc=dan.carpenter@linaro.org \
    --cc=etienne.carriere@st.com \
    --cc=f.fainelli@gmail.com \
    --cc=james.quinlan@broadcom.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michal.simek@amd.com \
    --cc=peng.fan@oss.nxp.com \
    --cc=ptosi@google.com \
    --cc=quic_nkela@quicinc.com \
    --cc=quic_sibis@quicinc.com \
    --cc=souvik.chakravarty@arm.com \
    --cc=sudeep.holla@arm.com \
    --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.