From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>,
Herve Codina <herve.codina@bootlin.com>
Cc: Brendan Higgins <brendan.higgins@linux.dev>,
David Gow <david@davidgow.net>, Rae Moar <raemoar63@gmail.com>,
Daniel Scally <djrscally@gmail.com>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
Bartosz Golaszewski <brgl@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Danilo Krummrich <dakr@kernel.org>,
Linus Walleij <linusw@kernel.org>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
kunit-dev@googlegroups.com, linux-acpi@vger.kernel.org,
driver-core@lists.linux.dev, linux-gpio@vger.kernel.org
Subject: Re: [PATCH 2/5] software node: add fw_devlink support
Date: Mon, 29 Jun 2026 18:42:24 +0300 [thread overview]
Message-ID: <akKSYKH2vyXMVcox@ashevche-desk.local> (raw)
In-Reply-To: <20260629-swnode-fw-devlink-v1-2-b90058b41839@oss.qualcomm.com>
+Cc: Herve, to just ask the situation with one series that adds nice helper.
On Mon, Jun 29, 2026 at 12:52:07PM +0200, Bartosz Golaszewski wrote:
> Software nodes can be used to describe supplier-consumer relationships
> between devices they represent using reference property entries. Unlike
> for OF-nodes, driver core cannot yet use these references to create a
> probe order that avoids needless probe deferrals on missing providers.
>
> Implement software_node_add_links() modelled on of_fwnode_add_links().
> For every DEV_PROP_REF property we resolve each referenced supplier and
> create an fwnode link from the node to it. The driver core later promotes
> these to device links and defers the consumer until the suppliers are
> ready.
>
> There's no allowlist like the one DT needs - devicetree phandles appear
> in plenty of non-supplier contexts, but a software node only carries a
> reference property when its author explicitly points at another node, so
> we treat every reference as an intentional supplier dependency and link
> all of them. Graph "remote-endpoint" references are skipped for now: they
> go 2-ways between endpoint nodes and would create graph cycles without
> the port-parent lifting DT does via get_con_dev(). References to
> suppliers that aren't registered yet and self-references are ignored.
>
> fw_devlink resolves the supplier device through fwnode->dev but the core
> only records the owning device on the primary fwnode. When the software
> node is a device's secondary fwnode, mirror the device pointer onto it in
> software_node_notify() so the consumer can actually find the supplier
> instead of deferring forever.
>
> While at it: purge the fwnode links in software_node_release() now that
> software nodes can own them.
...
> +static int software_node_add_links(struct fwnode_handle *fwnode)
> +{
> + const struct software_node_ref_args *ref, *ref_array;
> + struct swnode *swnode = to_swnode(fwnode);
> + const struct property_entry *prop;
> + struct fwnode_handle *refnode;
> + unsigned int count, i;
'i' is local to the loop.
> + if (!swnode || !swnode->node->properties)
> + return 0;
> +
> + /*
> + * Unlike Device Tree, where phandles appear in many non-supplier
> + * contexts and a curated allowlist is required, a software node only
> + * carries a DEV_PROP_REF property when the author explicitly describes
> + * a reference to another node. Every such reference is therefore an
> + * intentional supplier dependency, so we create fwnode links for all
> + * of them.
> + */
> + for (prop = swnode->node->properties; prop->name; prop++) {
> + if (prop->type != DEV_PROP_REF || prop->is_inline)
> + continue;
> +
> + /*
> + * TODO: Graph "remote-endpoint" references go both ways
> + * between endpoint child nodes and would create endpoint
> + * cycles. Let's leave it out for now until we have potential
> + * users.
> + */
> + if (!strcmp(prop->name, "remote-endpoint"))
> + continue;
> +
> + ref_array = prop->pointer;
> + count = prop->length / sizeof(*ref_array);
Seems we are going to have more of a such, perhaps make a helper for counting
(which will do that division beneath).
> + for (i = 0; i < count; i++) {
for (unsigned int i = 0; i < count; i++) {
> +
Redundant blank line?
> + if (ref->swnode)
> + refnode = software_node_fwnode(ref->swnode);
> + else if (ref->fwnode)
> + refnode = ref->fwnode;
> + else
> + continue;
> +
> + /* Supplier not registered yet, or self-reference. */
> + if (!refnode || refnode == &swnode->fwnode)
> + continue;
> +
> + fwnode_link_add(&swnode->fwnode, refnode, 0);
> + }
> + }
> +
> + return 0;
> +}
...
> + /*
> + * When the software node is the device's secondary firmware node, the
> + * core only records the owning device on the primary fwnode (see
> + * device_add()). fw_devlink resolves a supplier device through
> + * fwnode->dev, so without this a consumer referencing the software
> + * node could never find the supplier device and would defer forever.
> + * Make fwnode.dev point to its owner in that case.
The below seems more balanced in terms of line lengths.
* When the software node is the device's secondary firmware node,
* the core only records the owning device on the primary fwnode
* (see device_add()). fw_devlink resolves a supplier device through
* fwnode->dev, so without this a consumer referencing the software
* node could never find the supplier device and would defer forever.
* Make fwnode.dev point to its owner in that case.
> + */
> + if (dev_fwnode(dev) != &swnode->fwnode && !swnode->fwnode.dev)
> + swnode->fwnode.dev = dev;
Doesn't Herve's patch(es) add some helpers for this?
https://lore.kernel.org/lkml/20260511155930.34604-2-herve.codina@bootlin.com/
Ah, still not applied :-( Perhaps it can be applied as just part that brings
fw_devlink_set_device()?
> + /*
> + * Drop the device pointer mirrored onto a secondary software node in
> + * software_node_notify(). For a primary software node the core owns
> + * fwnode->dev and clears it in device_del().
> + */
> + if (dev_fwnode(dev) != &swnode->fwnode && swnode->fwnode.dev == dev)
> + swnode->fwnode.dev = NULL;
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2026-06-29 15:42 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-29 10:52 [PATCH 0/5] software node: provide support for fw_devlink Bartosz Golaszewski
2026-06-29 10:52 ` [PATCH 1/5] kunit: provide a set of fwnode-oriented helpers Bartosz Golaszewski
2026-06-29 10:52 ` [PATCH 2/5] software node: add fw_devlink support Bartosz Golaszewski
2026-06-29 15:42 ` Andy Shevchenko [this message]
2026-06-30 6:16 ` Herve Codina
2026-07-06 11:34 ` Bartosz Golaszewski
2026-06-29 10:52 ` [PATCH 3/5] software node: add kunit tests for " Bartosz Golaszewski
2026-06-29 15:49 ` Andy Shevchenko
2026-07-06 11:42 ` Bartosz Golaszewski
2026-06-29 10:52 ` [PATCH 4/5] MAINTAINERS: add myself as reviewer of software node support Bartosz Golaszewski
2026-06-29 11:20 ` Andy Shevchenko
2026-06-29 10:52 ` [PATCH 5/5] gpio: kunit: add test cases verifying swnode devlink support Bartosz Golaszewski
2026-06-29 15:58 ` Andy Shevchenko
2026-07-06 12:32 ` Bartosz Golaszewski
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=akKSYKH2vyXMVcox@ashevche-desk.local \
--to=andriy.shevchenko@linux.intel.com \
--cc=bartosz.golaszewski@oss.qualcomm.com \
--cc=brendan.higgins@linux.dev \
--cc=brgl@kernel.org \
--cc=dakr@kernel.org \
--cc=david@davidgow.net \
--cc=djrscally@gmail.com \
--cc=dmitry.torokhov@gmail.com \
--cc=driver-core@lists.linux.dev \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=herve.codina@bootlin.com \
--cc=kunit-dev@googlegroups.com \
--cc=linusw@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=raemoar63@gmail.com \
--cc=rafael@kernel.org \
--cc=sakari.ailus@linux.intel.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.