From: Sudeep Holla <sudeep.holla@kernel.org>
To: arm-scmi@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
kernel-team@meta.com
Cc: Cristian Marussi <cristian.marussi@arm.com>,
Breno Leitao <leitao@debian.org>,
Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
Subject: [PATCH v5 8/9] firmware: arm_scmi: Initialise known ACPI protocol devices and channels
Date: Tue, 15 Sep 2026 18:03:42 +0100 [thread overview]
Message-ID: <20260915-acpi_scmi_pcc-v5-8-298579e9f359@kernel.org> (raw)
In-Reply-To: <20260915-acpi_scmi_pcc-v5-0-298579e9f359@kernel.org>
Unlike Device Tree, the ACPI SCMI namespace device does not provide
child fwnodes to represent each protocol. Iterate over the non-BASE
entries in scmi_dsd_info_list to initialize their protocol devices and
transport channels. The BASE channel and device are handled by the
common setup path.
Let the transport channel-availability and SCMI protocol implementation
checks decide which of the known protocols are usable on the platform.
Reviewed-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
---
drivers/firmware/arm_scmi/driver.c | 66 +++++++++++++++++++++++++++-----------
1 file changed, 47 insertions(+), 19 deletions(-)
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index 616b57237559..c77f9534cda5 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -2873,7 +2873,7 @@ scmi_txrx_setup(struct scmi_info *info, struct fwnode_handle *fwnode,
*/
static int scmi_channels_setup(struct scmi_info *info)
{
- int ret;
+ int ret, idx;
struct fwnode_handle *fwnode = dev_fwnode(info->dev);
/* Initialize a common generic channel at first */
@@ -2881,21 +2881,34 @@ static int scmi_channels_setup(struct scmi_info *info)
if (ret)
return ret;
- fwnode_for_each_available_child_node_scoped(fwnode, child) {
- u32 prot_id;
+ if (!is_acpi_node(fwnode)) {
+ fwnode_for_each_available_child_node_scoped(fwnode, child) {
+ u32 prot_id;
+
+ if (fwnode_property_read_u32(child, "reg", &prot_id))
+ continue;
- if (fwnode_property_read_u32(child, "reg", &prot_id))
- continue;
+ if (!FIELD_FIT(MSG_PROTOCOL_ID_MASK, prot_id)) {
+ dev_err(info->dev,
+ "Out of range protocol %d\n", prot_id);
+ continue;
+ }
- if (!FIELD_FIT(MSG_PROTOCOL_ID_MASK, prot_id)) {
- dev_err(info->dev,
- "Out of range protocol %d\n", prot_id);
- continue;
+ ret = scmi_txrx_setup(info, child, prot_id);
+ if (ret)
+ return ret;
}
+ } else {
+ for (idx = 0; idx < ARRAY_SIZE(scmi_dsd_info_list); idx++) {
+ int prot_id = scmi_dsd_info_list[idx].protocol_id;
- ret = scmi_txrx_setup(info, child, prot_id);
- if (ret)
- return ret;
+ if (prot_id == SCMI_PROTOCOL_BASE)
+ continue;
+
+ ret = scmi_txrx_setup(info, fwnode, prot_id);
+ if (ret)
+ return ret;
+ }
}
return 0;
@@ -3245,7 +3258,7 @@ static void scmi_enable_matching_quirks(struct scmi_info *info)
}
static void scmi_device_check_create(struct fwnode_handle *fwnode, int prot_id,
- struct scmi_info *info)
+ struct scmi_info *info, bool report_missing)
{
int ret;
struct device *dev = info->dev;
@@ -3257,6 +3270,9 @@ static void scmi_device_check_create(struct fwnode_handle *fwnode, int prot_id,
}
if (!scmi_is_protocol_implemented(handle, prot_id)) {
+ if (!report_missing)
+ return;
+
dev_err(dev, "SCMI protocol %d not implemented\n", prot_id);
return;
}
@@ -3279,7 +3295,7 @@ static void scmi_device_check_create(struct fwnode_handle *fwnode, int prot_id,
static int scmi_probe(struct platform_device *pdev)
{
- int ret;
+ int ret, idx;
char *err_str = "probe failure\n";
struct scmi_handle *handle;
const struct scmi_desc *desc;
@@ -3400,13 +3416,25 @@ static int scmi_probe(struct platform_device *pdev)
scmi_enable_matching_quirks(info);
- fwnode_for_each_available_child_node(dev_fwnode(dev), child) {
- u32 prot_id;
+ if (!is_acpi_node(dev_fwnode(dev))) {
+ fwnode_for_each_available_child_node(dev_fwnode(dev), child) {
+ u32 prot_id;
- if (fwnode_property_read_u32(child, "reg", &prot_id))
- continue;
+ if (fwnode_property_read_u32(child, "reg", &prot_id))
+ continue;
- scmi_device_check_create(child, prot_id, info);
+ scmi_device_check_create(child, prot_id, info, true);
+ }
+ } else {
+ for (idx = 0; idx < ARRAY_SIZE(scmi_dsd_info_list); idx++) {
+ int prot_id = scmi_dsd_info_list[idx].protocol_id;
+
+ if (prot_id == SCMI_PROTOCOL_BASE)
+ continue;
+
+ scmi_device_check_create(dev_fwnode(dev), prot_id,
+ info, false);
+ }
}
return 0;
--
2.43.0
next prev parent reply other threads:[~2026-09-15 17:05 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-15 17:03 [PATCH v5 0/9] firmware: arm_scmi: Refactoring and enablement of ACPI PCC transport Sudeep Holla
2026-09-15 17:03 ` [PATCH v5 1/9] firmware: arm_scmi: Set generated device fwnode with platform helpers Sudeep Holla
2026-09-15 17:03 ` [PATCH v5 2/9] firmware: arm_scmi: Extend transport driver macro to support ACPI Sudeep Holla
2026-09-15 17:03 ` [PATCH v5 3/9] firmware: arm_scmi: Convert OF-only paths to generic fwnode in SCMI core Sudeep Holla
2026-09-15 17:03 ` [PATCH v5 4/9] firmware: arm_scmi: Fall back to ACPI HID when "compatible" is absent Sudeep Holla
2026-09-15 17:03 ` [PATCH v5 5/9] firmware: arm_scmi: Pass protocol ID to transport chan_available() Sudeep Holla
2026-09-15 17:03 ` [PATCH v5 6/9] firmware: arm_scmi: Refactor protocol device creation logic Sudeep Holla
2026-09-15 17:03 ` [PATCH v5 7/9] firmware: arm_scmi: Add ACPI PCC transport Sudeep Holla
2026-09-15 17:44 ` Sudeep Holla
2026-09-15 17:03 ` Sudeep Holla [this message]
2026-09-15 17:03 ` [PATCH v5 9/9] firmware: arm_scmi: Validate PCC shared memory signature Sudeep Holla
2026-09-18 16:53 ` [PATCH v5 0/9] firmware: arm_scmi: Refactoring and enablement of ACPI PCC transport 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=20260915-acpi_scmi_pcc-v5-8-298579e9f359@kernel.org \
--to=sudeep.holla@kernel.org \
--cc=arm-scmi@vger.kernel.org \
--cc=cristian.marussi@arm.com \
--cc=jonathan.cameron@oss.qualcomm.com \
--cc=kernel-team@meta.com \
--cc=leitao@debian.org \
--cc=linux-arm-kernel@lists.infradead.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