All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Shivendra Pratap" <shivendra.pratap@oss.qualcomm.com>
Cc: devicetree@vger.kernel.org, robh@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH v27 04/10] firmware: psci: Add support for PSCI auxiliary devices
Date: Thu, 29 Oct 2026 10:00:00 +0000	[thread overview]
Message-ID: <sashiko-outbox-189081@kernel.org> (raw)
In-Reply-To: <20261029-arm-psci-system_reset2-vendor-reboots-v27-4-fa4b3ff1359b@oss.qualcomm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] firmware: psci: premature fw_devlink consumer pickup in arm_psci_probe()
--

commit 693a73228dca9776538a9dc808fb4cd1f0b1d4d0
Author: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>

firmware: psci: Add support for PSCI auxiliary devices

This commit introduces a PSCI platform driver that binds to the "arm,psci-1.0"
device node and creates child devices on the auxiliary bus. It also converts
cpuidle-psci-domain from a platform driver into an auxiliary driver that binds
to the child device created by the PSCI provider.

> diff --git a/drivers/firmware/psci/psci-devices.c b/drivers/firmware/psci/psci-devices.c
> new file mode 100644
> index 0000000000000..d23befc490ed5
> --- /dev/null
> +++ b/drivers/firmware/psci/psci-devices.c

[ ... ]

> +static int arm_psci_probe(struct platform_device *pdev)
> +{
> +	const struct arm_psci_device_info *info;
> +	int auxdev_count = 0;
> +	int i, ret;
> +
> +	for (i = 0; i < ARRAY_SIZE(arm_psci_devices); i++) {
> +		info = &arm_psci_devices[i];
> +		ret = arm_psci_auxiliary_device_create(&pdev->dev, info);
> +		if (ret)
> +			dev_warn(&pdev->dev, "failed to create %s aux device: %d\n",
> +				 info->name, ret);
> +		else
> +			auxdev_count++;
> +	}
> +
> +	return auxdev_count ? 0 : -ENODEV;
> +}

[Severity: Medium]
Can returning 0 from arm_psci_probe() when psci_cpuidle_domain_probe() defers
(or probes asynchronously) cause fw_devlink to prematurely mark the child
power-domain device tree nodes as FWNODE_FLAG_NOT_DEVICE?

Previously, psci_cpuidle_domain_driver was the platform_driver for the
"arm,psci-1.0" platform device (where psci_fwnode->dev == &pdev->dev). When
psci_cpuidle_domain_probe() returned -EPROBE_DEFER, really_probe() did not
call device_links_driver_bound(&pdev->dev).

On platforms where a PSCI child power domain references an external parent
power domain (for example arch/arm64/boot/dts/qcom/agatti.dtsi and
arch/arm64/boot/dts/qcom/sm6375.dtsi, where cluster_pd has
power-domains = <&mpm> pointing to "qcom,mpm"), arm_psci_probe() and
psci_cpuidle_domain_probe() run during of_platform_default_populate_init() at
arch_initcall_sync, while qcom_mpm_driver (drivers/irqchip/irq-qcom-mpm.c) is
registered at device_initcall (or as a module).

When arm_psci_probe() -> arm_psci_auxiliary_device_create() ->
__auxiliary_device_add() -> device_add() runs, psci_cpuidle_domain_probe()
calls dt_idle_pd_init_topology() -> of_genpd_add_subdomain(), which returns
-EPROBE_DEFER because the mpm genpd provider is not registered yet.
psci_cpuidle_domain_probe() then unwinds:

drivers/cpuidle/cpuidle-psci-domain.c:psci_cpuidle_domain_probe() {
	...
	/* Link genpd masters/subdomains to model the CPU topology. */
	ret = dt_idle_pd_init_topology(np);
	if (ret)
		goto remove_pd;
	...
remove_pd:
	dt_idle_pd_remove_topology(np);
	psci_pd_remove();
exit:
	pr_err("failed to create CPU PM domains ret=%d\n", ret);
	return ret;
}

Here psci_pd_remove() -> of_genpd_del_provider() -> device_del(&gpd->dev)
resets child_fwnode->dev to NULL for all child power-domain nodes under the
PSCI node.

Because bus_probe_device(&auxdev->dev) does not propagate probe deferral to
device_add(&auxdev->dev), arm_psci_auxiliary_device_create() and
arm_psci_probe() still return 0. really_probe(&pdev->dev) then calls
driver_bound(&pdev->dev) -> device_links_driver_bound(&pdev->dev):

drivers/base/core.c:device_links_driver_bound() {
	...
	if (dev->fwnode && dev->fwnode->dev == dev) {
		fwnode_links_purge_suppliers(dev->fwnode);
		fw_devlink_pickup_dangling_consumers(dev);
	}
	...
}

Because child_fwnode->dev is NULL on the child power-domain nodes (which also
happens if psci-cpuidle-domain probes asynchronously),
__fw_devlink_pickup_dangling_consumers() sets FWNODE_FLAG_NOT_DEVICE on each
child power-domain fwnode and moves their consumer fwnode_links to the parent
PSCI platform device (&pdev->dev).

When the supplier device (mpm_pdev) is later added,
__fw_devlink_link_to_consumers(&mpm_pdev->dev) sees
get_dev_from_fwnode(cluster_pd_fwnode) == NULL, falls back to
fwnode_get_next_parent_dev(cluster_pd_fwnode) (&pdev->dev), and attempts to
create a DL_FLAG_SYNC_STATE_ONLY device link to &pdev->dev. Because
pdev->dev.links.status is already DL_DEV_DRIVER_BOUND, device_link_add() fails
and logs "Failed to create device link", leaving mpm_pdev without a
SYNC_STATE_ONLY link.

Furthermore, because FWNODE_FLAG_NOT_DEVICE is never cleared, even after
psci_cpuidle_domain_probe() succeeds on deferred probe retry and registers
genpd->dev via of_genpd_add_provider_simple(), fw_devlink_create_devlink()
keeps redirecting consumers of the child power-domain nodes to &pdev->dev:

drivers/base/core.c:fw_devlink_create_devlink() {
	...
	if (fwnode_test_flag(sup_handle, FWNODE_FLAG_NOT_DEVICE))
		sup_dev = fwnode_get_next_parent_dev(sup_handle);
	else
		sup_dev = get_dev_from_fwnode(sup_handle);
	...
}

Doesn't this leave the child genpd->dev devices without consumer device links
to hold off genpd_provider_sync_state()?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261029-arm-psci-system_reset2-vendor-reboots-v27-0-fa4b3ff1359b@oss.qualcomm.com?part=4

  reply	other threads:[~2026-10-29 10:00 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-29  9:00 [PATCH v27 00/10] Implement PSCI reboot mode driver for PSCI resets Shivendra Pratap
2026-10-29  9:00 ` [PATCH v27 01/10] power: reset: reboot-mode: Support up to 3 magic values per mode Shivendra Pratap
2026-10-29  9:00 ` [PATCH v27 02/10] power: reset: reboot-mode: Add support for predefined reboot modes Shivendra Pratap
2026-10-29  9:23   ` sashiko-bot
2026-10-29  9:00 ` [PATCH v27 03/10] firmware: psci: Introduce command-based resets Shivendra Pratap
2026-10-29  9:00 ` [PATCH v27 04/10] firmware: psci: Add support for PSCI auxiliary devices Shivendra Pratap
2026-10-29 10:00   ` sashiko-bot [this message]
2026-10-29  9:00 ` [PATCH v27 05/10] dt-bindings: arm: Document reboot mode magic Shivendra Pratap
2026-10-29  9:01 ` [PATCH v27 06/10] power: reset: Add psci-reboot-mode driver Shivendra Pratap
2026-10-29  9:01 ` [PATCH v27 07/10] arm64: dts: qcom: Add psci reboot-modes for kodiak boards Shivendra Pratap
2026-10-29 10:23   ` Abel Vesa
2026-10-29  9:01 ` [PATCH v27 08/10] arm64: dts: qcom: Add psci reboot-modes for lemans boards Shivendra Pratap
2026-10-29 10:23   ` Abel Vesa
2026-10-29  9:01 ` [PATCH v27 09/10] arm64: dts: qcom: Add psci reboot-modes for monaco boards Shivendra Pratap
2026-10-29 10:24   ` Abel Vesa
2026-10-29  9:01 ` [PATCH v27 10/10] arm64: dts: qcom: Add psci reboot-modes for talos boards Shivendra Pratap
2026-10-29 10:24   ` Abel Vesa

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=sashiko-outbox-189081@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=shivendra.pratap@oss.qualcomm.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.