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 1/8] firmware: arm_scmi: Set fwnode for the genrated SCMI platform device
Date: Mon, 20 Oct 2025 18:07:02 +0100 [thread overview]
Message-ID: <20251020180702.00005106@huawei.com> (raw)
In-Reply-To: <20251017-acpi_scmi_pcc-v1-1-0adbab7709d9@arm.com>
On Fri, 17 Oct 2025 14:23:44 +0100
Sudeep Holla <sudeep.holla@arm.com> wrote:
generated (in patch title).
> Add a call to device_set_node() in the SCMI probe helper to associate
> generated SCMI platform device with the firmware node of its supplier
> transport device.
>
> This complements device_set_of_node_from_dev() and ensures that
> firmware node information is propagated correctly for both Device Tree
> and non-DT (e.g. ACPI) based systems.
>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> drivers/firmware/arm_scmi/common.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/firmware/arm_scmi/common.h b/drivers/firmware/arm_scmi/common.h
> index 07b9e629276d..911941e6885d 100644
> --- a/drivers/firmware/arm_scmi/common.h
> +++ b/drivers/firmware/arm_scmi/common.h
> @@ -473,6 +473,7 @@ static int __tag##_probe(struct platform_device *pdev) \
> return -ENOMEM; \
> \
> device_set_of_node_from_dev(&spdev->dev, dev); \
> + device_set_node(&spdev->dev, dev_fwnode(dev)); \
device_set_node() is supposed to handle both dt and ACPI. So this surprised me
and I went digging.
dev_fnode for acpi is dev->fwnode, for of it is of_fwnode_handle(dev->of_node)
Which is dev->of_node->fwnode
So for acpi this is
device_set_node(&spdev->dev, dev->fwnode);
which is:
spdev->dev->fwnode = fwnode;
spdev->dev->of_node = NULL;
For dt
device_set_node(&spdev->dev, dev->of_node->fwnode);
which is
spdev->dev->fwnode = dev->of_node->fwnode;
spdev->dev->opf-node = dev->of_node; (via some container of magic)
The device_set_of_node_from_dev(&spdev->dev, dev)
is same as:
of_node_put(spdev->dev->of_node);
spdev->dev->of_node = of_node_get(dev->of_node);
spdev->dev->of_node_reused = true;
So subject to some reference counting that I don't think you need as the
spdev->dev parent is the dev here, the first call does nothing extra.
Maybe I missed something?
Jonathan
> \
> strans.supplier = dev; \
> memcpy(&strans.desc, &(__desc), sizeof(strans.desc)); \
>
next prev parent reply other threads:[~2025-10-20 17:07 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 [this message]
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
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=20251020180702.00005106@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.