From: Hans de Goede <johannes.goede@oss.qualcomm.com>
To: Bjorn Andersson <andersson@kernel.org>,
Cristian Marussi <cristian.marussi@arm.com>,
Sudeep Holla <sudeep.holla@kernel.org>
Cc: Hans de Goede <johannes.goede@oss.qualcomm.com>,
Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>,
Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>,
Frank.Li@kernel.org, arm-scmi@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-arm-msm@vger.kernel.org, imx@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: [PATCH v5 0/3] firmware: arm_scmi: fix module auto-loading
Date: Wed, 2 Sep 2026 20:08:41 +0200 [thread overview]
Message-ID: <20260902180844.41230-1-johannes.goede@oss.qualcomm.com> (raw)
Hi All,
Here is v5 of the patch series fixing arm_scmi module autoloading this
combines:
1. Patch 1/2 from Bjorn to add support for scmi bus modaliases to modpost:
https://lore.kernel.org/all/20260618-scmi-modalias-v2-1-8c7547c1be21@oss.qualcomm.com/
2. A new patch to always create devices for standard protocols, replacing
Cristian's patch to pre-register the standard protocol device-ids from v4.
1. is not enough by itself because driver module auto-loading requires
the devices to already be created for udev to get the necessary uevents
based on which udev auto-loads modules.
But SCMI devices are only created after their { protocol, name } device-id
has been registered which is done from scmi_driver_register(), creating
a circular dependency.
2. breaks the circular dependency by always creating devices for standard
protocols without relying on the requested-devices list. This creates
devices before the module with the driver is loaded, after which module
auto loading works the same as it does on any other bus.
I've tested this on a T14s Snapdragon laptop with Fedora's kernel config
where scmi_cpufreq is a module. With this series scmi_cpufreq correctly
autoloads even if it is not included in the initramfs.
Changes in v5:
- New patch: "firmware: arm_scmi: Fix scmi_protocol_table_register()
error handling"
- Replace "Pre-register protocol, name tupples for standard protocol" with
"Always create devices for standard protocols" pre-registering requires
scmi_protocol_device_request() to allow duplicate device-ids, but then if
the first driver of two with duplicate devce-ids gets unloaded device
creation for the second driver will fail. Allowing duplicates causes all
kinds of problems, so this new approach avoids this.
- Drop "Pre-register protocol, name tupples for IMX protocols" patch.
Shashiko rightfully turns out this will cause problems if other vendors
also use the same vendor protocol-id space values, e.g. 0x80, 0x81 are
likely to also be used by other vendors.
Changes in v4:
- Drop unused driver_data member from struct scmi_device_id (Uwe)
- Drop device-id/scmi.h include from mod_devicetable.h (Uwe)
- Add device-id/scmi.h to devicetable-offsets.c and file2alias.c (Uwe)
Changes in v3:
- v3 is the first series combining Bjorn and Christian's work see above.
Regards,
Hans
Bjorn Andersson (1):
module: add SCMI device table alias support
Hans de Goede (2):
firmware: arm_scmi: Fix scmi_protocol_table_register() error handling
firmware: arm_scmi: Always create devices for standard protocols
MAINTAINERS | 1 +
drivers/firmware/arm_scmi/bus.c | 97 +++++++++++++++++++++++--------
include/linux/device-id/scmi.h | 17 ++++++
include/linux/scmi_protocol.h | 6 +-
scripts/mod/devicetable-offsets.c | 5 ++
scripts/mod/file2alias.c | 12 ++++
6 files changed, 110 insertions(+), 28 deletions(-)
create mode 100644 include/linux/device-id/scmi.h
--
2.55.0
next reply other threads:[~2026-09-02 18:09 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-02 18:08 Hans de Goede [this message]
2026-09-02 18:08 ` [PATCH v5 1/3] module: add SCMI device table alias support Hans de Goede
2026-09-02 18:08 ` [PATCH v5 2/3] firmware: arm_scmi: Fix scmi_protocol_table_register() error handling Hans de Goede
2026-09-02 18:08 ` [PATCH v5 3/3] firmware: arm_scmi: Always create devices for standard protocols Hans de Goede
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=20260902180844.41230-1-johannes.goede@oss.qualcomm.com \
--to=johannes.goede@oss.qualcomm.com \
--cc=Frank.Li@kernel.org \
--cc=andersson@kernel.org \
--cc=arm-scmi@vger.kernel.org \
--cc=bjorn.andersson@oss.qualcomm.com \
--cc=cristian.marussi@arm.com \
--cc=daniel.lezcano@oss.qualcomm.com \
--cc=imx@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sudeep.holla@kernel.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;
as well as URLs for NNTP newsgroup(s).