From: Jonathan Cameron <jonathan.cameron@huawei.com>
To: Sudeep Holla <sudeep.holla@arm.com>
Cc: Cristian Marussi <cristian.marussi@arm.com>,
<arm-scmi@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 3/8] firmware: arm_scmi: Convert OF-only paths to generic fwnode in SCMI core
Date: Mon, 20 Oct 2025 18:29:49 +0100 [thread overview]
Message-ID: <20251020182949.00002bbf@huawei.com> (raw)
In-Reply-To: <20251017-acpi_scmi_pcc-v1-3-0adbab7709d9@arm.com>
On Fri, 17 Oct 2025 14:23:46 +0100
Sudeep Holla <sudeep.holla@arm.com> wrote:
> Switch SCMI core plumbing from struct device_node* to struct
> fwnode_handle* so transports and core code work with both DT and
> ACPI firmware descriptions.
>
> This change:
> - Replaces of_* property lookups with fwnode_property_*() helpers.
> - Switches child enumeration to
> fwnode_for_each_available_child_node_scoped().
> - Plumbs fwnode through the SCMI device creation and channel setup
> paths and updates transport ->chan_available() signatures to take a
> fwnode.
> - Stores the per-protocol child fwnodes in info->active_protocols so
> the core can later locate the descriptor for a given protocol ID.
> - Update mailbox/optee/smc/virtio transports to accept fwnode and
> map to OF nodes where needed
>
> DT-only transports (mailbox/optee/smc) still parse DT properties by
> mapping the fwnode back to an OF node; on non-DT (e.g. ACPI) systems
> these transports will report no channel available.
>
> This refactor is a prerequisite for adding an ACPI-first transport like
> PCC and brings the SCMI core closer to DT/ACPI parity. This is a mechanical
> step towards firmware-node neutrality; DT users continue to work unchanged,
> and ACPI paths can be enabled on top.
>
> No functional change is expected on DT platforms; ACPI platforms can now
> discover and participate in SCMI where a suitable transport is present.
>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Hi Sudeep
A few comments inline. The reference counting on fwnodes gets a bit complex in
here so my review more or less skips that bit (it's end of day!)
> diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
> index bd56a877fdfc..bc5fea11b5db 100644
> --- a/drivers/firmware/arm_scmi/driver.c
> +++ b/drivers/firmware/arm_scmi/driver.c
> @@ -2820,7 +2820,7 @@ static int scmi_chan_destroy(int id, void *p, void *idr)
> struct scmi_info *info = handle_to_scmi_info(cinfo->handle);
> struct scmi_device *sdev = to_scmi_dev(cinfo->dev);
>
> - of_node_put(cinfo->dev->of_node);
> + fwnode_handle_put(dev_fwnode(cinfo->dev));
This may follow on from earlier thing about device_set_node().
I think this is freeing a reference that will never have been gotten if you
follow what I suggest there. Note that I'm fairly sure it was never
gotten for acpi anyway. However this might be a different fwnode, I'm lost
on that front.
> scmi_device_destroy(info->dev, id, sdev->name);
> cinfo->dev = NULL;
> }
> @@ -3118,8 +3119,8 @@ static const struct scmi_desc *scmi_transport_setup(struct device *dev)
> trans->desc.max_msg);
>
> /* System wide atomic threshold for atomic ops .. if any */
> - if (!of_property_read_u32(dev->of_node, "atomic-threshold-us",
> - &trans->desc.atomic_threshold))
> + if (!fwnode_property_read_u32(dev_fwnode(dev), "atomic-threshold-us",
device_property_read_u32() Same for all the other places where the fwnode
is simple dev_fwnode(dev) and there is a suitable helper.
> + &trans->desc.atomic_threshold))
> dev_info(dev,
> "SCMI System wide atomic threshold set to %u us\n",
> trans->desc.atomic_threshold);
> @@ -3262,10 +3262,10 @@ static int scmi_probe(struct platform_device *pdev)
>
> scmi_enable_matching_quirks(info);
>
> - for_each_available_child_of_node(np, child) {
> + fwnode_for_each_available_child_node_scoped(dev_fwnode(dev), child) {
I don't think there is an exit path in here, so this is functionally the same
as the non scoped version.
Also, if you are gong to use dev_fwnode use
device_for_each_child_node() and don't worry about the available.
I think the patch merged that made device_for_each_child_node() only
consider the available ones for all firmware types.
> u32 prot_id;
>
> - if (of_property_read_u32(child, "reg", &prot_id))
> + if (fwnode_property_read_u32(child, "reg", &prot_id))
> continue;
>
> if (!FIELD_FIT(MSG_PROTOCOL_ID_MASK, prot_id))
> @@ -3278,10 +3278,11 @@ static int scmi_probe(struct platform_device *pdev)
> }
>
> /*
> - * Save this valid DT protocol descriptor amongst
> + * Save this valid fwnode protocol descriptor amongst
> * @active_protocols for this SCMI instance/
> */
> - ret = idr_alloc(&info->active_protocols, child,
> + ret = idr_alloc(&info->active_protocols,
> + fwnode_handle_get(child),
This change is a little subtle to be buried in here and I'm fairly sure
it is an unintended functional change. If idr_alloc() fails the continue
and loop iterator magic, will drop the reference held by the loop but
not this one. So it will leak a reference.
If this does make sense, do it in a precursor patch before changing away
from of only.
> prot_id, prot_id + 1, GFP_KERNEL);
> if (ret != prot_id) {
> dev_err(dev, "SCMI protocol %d already activated. Skip\n",
> @@ -3289,7 +3290,6 @@ static int scmi_probe(struct platform_device *pdev)
> continue;
> }
>
> - of_node_get(child);
> scmi_create_protocol_devices(child, info, prot_id, NULL);
> }
>
next prev parent reply other threads:[~2025-10-20 17:29 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-17 13:23 [PATCH 0/8] firmware: arm_scmi: Refactoring and enablement of ACPI PCC transport Sudeep Holla
2025-10-17 13:23 ` [PATCH 1/8] firmware: arm_scmi: Set fwnode for the genrated SCMI platform device Sudeep Holla
2025-10-20 17:07 ` Jonathan Cameron
2025-10-21 9:03 ` Sudeep Holla
2025-10-17 13:23 ` [PATCH 2/8] firmware: arm_scmi: Extend transport driver macro to support ACPI Sudeep Holla
2025-10-20 17:11 ` Jonathan Cameron
2025-10-21 9:06 ` Sudeep Holla
2025-10-17 13:23 ` [PATCH 3/8] firmware: arm_scmi: Convert OF-only paths to generic fwnode in SCMI core Sudeep Holla
2025-10-20 17:29 ` Jonathan Cameron [this message]
2025-10-21 9:26 ` Sudeep Holla
2025-10-17 13:23 ` [PATCH 4/8] firmware: arm_scmi: Fall back to ACPI HID when "compatible" is absent Sudeep Holla
2025-10-17 13:23 ` [PATCH 5/8] firmware: arm_scmi: Pass protocol ID to chan_available() transport callback Sudeep Holla
2025-10-17 13:23 ` [PATCH 6/8] firmware: arm_scmi: Refactor protocol device creation logic Sudeep Holla
2025-10-17 13:23 ` [PATCH 7/8] firmware: arm_scmi: transport: Add ACPI PCC transport Sudeep Holla
2025-10-20 8:20 ` Dan Carpenter
2025-10-20 8:47 ` Sudeep Holla
2025-10-20 17:37 ` Jonathan Cameron
2025-10-21 9:30 ` Sudeep Holla
2025-10-17 13:23 ` [PATCH 8/8] firmware: arm_scmi: Initialise all protocol devices and transport channels Sudeep Holla
2025-11-05 11:49 ` [PATCH 0/8] firmware: arm_scmi: Refactoring and enablement of ACPI PCC transport Punit Agrawal
2025-11-26 14:31 ` Sudeep Holla
2025-12-03 11:04 ` Punit Agrawal
2025-12-03 15:21 ` Sudeep Holla
2025-12-04 18:25 ` Punit Agrawal
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=20251020182949.00002bbf@huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=arm-scmi@vger.kernel.org \
--cc=cristian.marussi@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=sudeep.holla@arm.com \
/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.