From: Cristian Marussi <cristian.marussi@arm.com>
To: linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, arm-scmi@vger.kernel.org
Cc: sudeep.holla@kernel.org, philip.radford@arm.com,
james.quinlan@broadcom.com, f.fainelli@gmail.com,
vincent.guittot@linaro.org, etienne.carriere@foss.st.com,
peng.fan@oss.nxp.com, michal.simek@amd.com,
gatien.chevallier@foss.st.com, u.kleine-koenig@baylibre.com,
dakr@kernel.org, Cristian Marussi <cristian.marussi@arm.com>
Subject: [PATCH v2 0/4] Rework SCMI transport drivers probing sequence
Date: Sun, 10 May 2026 17:05:23 +0100 [thread overview]
Message-ID: <20260510160527.3537474-1-cristian.marussi@arm.com> (raw)
Hi,
when the SCMI transports were split out into standalone drivers [1] the
probe sequence was laid out in such a way that:
- the transport drivers would have probed first, triggered by the firmware
driven discovery process (DT/ACPI)
- afterwards the control would have been passed to the core SCMI stack
driver via the creation of a dedicated device that would have inherited
the original firmware descriptor (since that same DT/ACPI node would
have been still needed by the SCMI core driver to be parsed)
The tricky part came around with some transport driver like virtio and
optee since they are, in turn, upfront dependent on an external distinct
kernel subsystem; IOW these have first to undergo their own subsystem
specific probe/initialization to become fully operational as transports:
this kind of initialization sequencing of course must deal with the
possibility of probe deferrals BUT at that time we avoided this by using
the trick in virtio/optee transports to register the next stage drivers
ONLY at the end of the subsystem specific probe routine, from within the
probe itself.
This register_while_probing behaviour is ugly and has 2 main issues:
- it is frowned upon and can lead to hangs in the driver core whenever
some core locking is changed as exposed in [2][3]
- it limits these transport drivers to a single instance probing since of
course you cannot register the same driver more than once
Note also that such dependencies are NOT explicitly represented in any way
within the firmware description tables: i.e. we cannot play the fw_devlink
card and enjoy correct sequencing out of the box.
With this series we remove the ugly register_while_probing trick and
introduce some basic mechanism to allow the probe to be deferred until the
underlying transport has probed and it is fully operational so as that can
be used as a supplier device. This is obtained by:
- moving the problematic platform driver registration away from the probe
into its own module_init/exit
- adding a few common well-known optional helpers that can be invoked
to retrieve the supplier reference, if ready, OR defer the probe when
neeeded.
Instead, we do NOT introduce in this series (as we attempted in the RFC)
a mechanism to support multiple instance probing also for optee and virtio
transports, because there is currently NO possible way to bind such probed
transport driver instances to the related SCMI instances, so that this
would narrow down the applicability of this multiple instance scenario to
the case in which each underlying SCMI server instance is setup in exactly
the same way. (same protocols for each instance node)
Based on v7.1-rc2
Tested on:
- an emulated environment against a mock SCMI Server (virtio)
- a QEMU based setup against SCP-based server running in OPTEE (optee)
- JUNO with the standard SCP reference firmware (mailbox)
- RADXA ROCK_5B with Rockchip fw (smc)
Thanks,
Cristian
[1]: https://lore.kernel.org/arm-scmi/20240812173340.3912830-1-cristian.marussi@arm.com/
[2]: https://lore.kernel.org/lkml/aaA6t-J2gRy3dE1_@pluto/
[3]: https://lore.kernel.org/all/ad9cglZCwtsVsGmq@monoceros/
---
v1 -> v2
- fixed __MUTEX_INITILIAZER() usage
- reworked supplier state machine
- introduce common transport_supplier logic
- get rid of init/cleanup wrappers
- use common generic supplier definitions in virtio/optee
- optee: use proper barrier on scmi_optee_agent
- virtio: fixed possible race between supplier made available
and scmi_dev made visible
- virtio: restored initial virtio_device_ready() logic
- virtio: issue a proper reset device on probe failure
Cristian Marussi (4):
firmware: arm_scmi: Add transport instance handles
firmware: arm_scmi: Add a generic transport supplier
firmware: arm_scmi: virtio: Rework transport probe sequence
firmware: arm_scmi: optee: Rework transport probe sequence
drivers/firmware/arm_scmi/common.h | 163 +++++++++++++++++-
drivers/firmware/arm_scmi/transports/optee.c | 46 +++--
drivers/firmware/arm_scmi/transports/virtio.c | 52 +++++-
3 files changed, 238 insertions(+), 23 deletions(-)
--
2.53.0
next reply other threads:[~2026-05-10 16:06 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-10 16:05 Cristian Marussi [this message]
2026-05-10 16:05 ` [PATCH v2 1/4] firmware: arm_scmi: Add transport instance handles Cristian Marussi
2026-05-10 16:05 ` [PATCH v2 2/4] firmware: arm_scmi: Add a generic transport supplier Cristian Marussi
2026-05-10 16:05 ` [PATCH v2 3/4] firmware: arm_scmi: virtio: Rework transport probe sequence Cristian Marussi
2026-05-10 16:05 ` [PATCH v2 4/4] firmware: arm_scmi: optee: " Cristian Marussi
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=20260510160527.3537474-1-cristian.marussi@arm.com \
--to=cristian.marussi@arm.com \
--cc=arm-scmi@vger.kernel.org \
--cc=dakr@kernel.org \
--cc=etienne.carriere@foss.st.com \
--cc=f.fainelli@gmail.com \
--cc=gatien.chevallier@foss.st.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=philip.radford@arm.com \
--cc=sudeep.holla@kernel.org \
--cc=u.kleine-koenig@baylibre.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox