From: sashiko-bot@kernel.org
To: "Shivendra Pratap" <shivendra.pratap@oss.qualcomm.com>
Cc: lee@kernel.org, mfd@lists.linux.dev, robh@kernel.org,
conor+dt@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v23 08/13] mfd: core: Add firmware-node support to MFD cells
Date: Tue, 14 Jul 2026 17:30:03 +0000 [thread overview]
Message-ID: <20260714173004.447F91F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260714-arm-psci-system_reset2-vendor-reboots-v23-8-e7453c548c21@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Strict enforcement of `named_fwnode` aborts the entire MFD probe if the node is missing.
--
--- Patch [8]: [PATCH v23 08/13] mfd: core: Add firmware-node support to MFD cells ---
commit c957d9fd3d002c62018221b0f97f57bad5c0b519
Author: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
mfd: core: Add firmware-node support to MFD cells
This commit extends struct mfd_cell with a named firmware-node field to allow
registering a child device using an explicit firmware node. It uses this as a
fallback when no firmware node is assigned by device tree, ACPI, or software
matching.
> diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
> index 7aa32b90cf1eb..ba9682ead2cad 100644
> --- a/drivers/mfd/mfd-core.c
> +++ b/drivers/mfd/mfd-core.c
[ ... ]
> @@ -224,6 +289,37 @@ static int mfd_add_device(struct device *parent, int id,
>
> mfd_acpi_add_device(cell, pdev);
>
> + /* named_fwnode is a fallback only when no OF/ACPI match and no swnode */
> + if (!pdev->dev.fwnode && !cell->swnode && cell->named_fwnode) {
> + struct device_node *named_np;
> +
> + fwnode = device_get_named_child_node(parent, cell->named_fwnode);
> + if (!fwnode) {
> + ret = -ENODEV;
> + goto fail_alias;
> + }
[Severity: High]
Will this strict enforcement cause the entire MFD parent probe to fail if an
optional child node is missing?
Unlike the permissive of_compatible match that merely warns and bypasses
missing nodes, returning -ENODEV here cascades up to mfd_add_devices(). This
causes a failure that unwinds all active child devices and blocks the parent
driver's probe.
Should a missing named firmware node be treated less strictly so it doesn't
disable unrelated MFD functions?
> +
> + named_np = to_of_node(fwnode);
> + if (named_np) {
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260714-arm-psci-system_reset2-vendor-reboots-v23-0-e7453c548c21@oss.qualcomm.com?part=8
next prev parent reply other threads:[~2026-07-14 17:30 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-14 17:16 [PATCH v23 00/13] Implement PSCI reboot mode driver for PSCI resets Shivendra Pratap
2026-07-14 17:16 ` [PATCH v23 01/13] power: reset: reboot-mode: Remove devres based allocations Shivendra Pratap
2026-07-14 17:29 ` sashiko-bot
2026-07-14 17:16 ` [PATCH v23 02/13] power: reset: reboot-mode: Support up to 3 magic values per mode Shivendra Pratap
2026-07-14 17:30 ` sashiko-bot
2026-07-14 17:16 ` [PATCH v23 03/13] power: reset: reboot-mode: Add support for predefined reboot modes Shivendra Pratap
2026-07-14 17:27 ` sashiko-bot
2026-07-14 17:16 ` [PATCH v23 04/13] firmware: psci: Introduce command-based resets Shivendra Pratap
2026-07-14 17:28 ` sashiko-bot
2026-07-14 17:16 ` [PATCH v23 05/13] mfd: psci-mfd: Add PSCI MFD driver for cpuidle-psci-domain cell Shivendra Pratap
2026-07-14 17:27 ` sashiko-bot
2026-07-14 17:16 ` [PATCH v23 06/13] dt-bindings: arm: Document reboot mode magic Shivendra Pratap
2026-07-14 17:33 ` sashiko-bot
2026-07-14 17:16 ` [PATCH v23 07/13] power: reset: Add psci-reboot-mode driver Shivendra Pratap
2026-07-14 17:30 ` sashiko-bot
2026-07-14 17:16 ` [PATCH v23 08/13] mfd: core: Add firmware-node support to MFD cells Shivendra Pratap
2026-07-14 17:30 ` sashiko-bot [this message]
2026-07-14 17:16 ` [PATCH v23 09/13] mfd: psci-mfd: Add psci-reboot-mode child cell Shivendra Pratap
2026-07-14 17:24 ` sashiko-bot
2026-07-14 17:16 ` [PATCH v23 10/13] arm64: dts: qcom: Add psci reboot-modes for kodiak boards Shivendra Pratap
2026-07-14 17:32 ` sashiko-bot
2026-07-14 17:16 ` [PATCH v23 11/13] arm64: dts: qcom: Add psci reboot-modes for lemans boards Shivendra Pratap
2026-07-14 17:32 ` sashiko-bot
2026-07-14 17:16 ` [PATCH v23 12/13] arm64: dts: qcom: Add psci reboot-modes for monaco boards Shivendra Pratap
2026-07-14 17:31 ` sashiko-bot
2026-07-14 17:16 ` [PATCH v23 13/13] arm64: dts: qcom: Add psci reboot-modes for talos boards Shivendra Pratap
2026-07-14 17:32 ` sashiko-bot
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=20260714173004.447F91F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=lee@kernel.org \
--cc=mfd@lists.linux.dev \
--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.