From: Sakari Ailus <sakari.ailus@linux.intel.com>
To: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Daniel Scally <djrscally@gmail.com>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Danilo Krummrich <dakr@kernel.org>,
Philipp Zabel <p.zabel@pengutronix.de>,
Krzysztof Kozlowski <krzk@kernel.org>,
linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-acpi@vger.kernel.org,
Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Subject: Re: [PATCH v2 3/9] software node: allow referencing firmware nodes
Date: Fri, 24 Oct 2025 18:17:23 +0300 [thread overview]
Message-ID: <aPuYg0ws8Q2sp7Wv@kekkonen.localdomain> (raw)
In-Reply-To: <20251022-reset-gpios-swnodes-v2-3-69088530291b@linaro.org>
Hi Bartosz,
On Wed, Oct 22, 2025 at 03:41:02PM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
> At the moment software nodes can only reference other software nodes.
> This is a limitation for devices created, for instance, on the auxiliary
> bus with a dynamic software node attached which cannot reference devices
> the firmware node of which is "real" (as an OF node or otherwise).
That's not entirely true: you can add a software node as a secondary to an
existing OF or ACPI fwnode. This has not been used widely and it's not very
convenient to set up.
Additional properties in ACPI or OF nodes will still need the secondary
node, after these patches.
>
> Make it possible for a software node to reference all firmware nodes in
> addition to static software nodes. To that end: use a union of different
> pointers in struct software_node_ref_args and add an enum indicating
> what kind of reference given instance of it is. Rework the helper macros
> and deprecate the existing ones whose names don't indicate the reference
> type.
>
> Software node graphs remain the same, as in: the remote endpoints still
> have to be software nodes.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> ---
> drivers/base/swnode.c | 14 ++++++++++----
> include/linux/property.h | 40 +++++++++++++++++++++++++++++++++-------
> 2 files changed, 43 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
> index b7c3926b67be72671ba4e4c442b3acca80688cf7..d08b914c07691336540cdf1dfbd77a697e7b4521 100644
> --- a/drivers/base/swnode.c
> +++ b/drivers/base/swnode.c
> @@ -535,9 +535,12 @@ software_node_get_reference_args(const struct fwnode_handle *fwnode,
> ref_array = prop->pointer;
> ref = &ref_array[index];
>
> - refnode = software_node_fwnode(ref->node);
> - if (!refnode)
> - return -ENOENT;
> + if (ref->swnode)
> + refnode = software_node_fwnode(ref->swnode);
> + else if (ref->fwnode)
> + refnode = ref->fwnode;
> + else
> + return -EINVAL;
>
> if (nargs_prop) {
> error = fwnode_property_read_u32(refnode, nargs_prop,
> @@ -634,7 +637,10 @@ software_node_graph_get_remote_endpoint(const struct fwnode_handle *fwnode)
>
> ref = prop->pointer;
>
> - return software_node_get(software_node_fwnode(ref[0].node));
> + if (!ref->swnode)
> + return NULL;
> +
> + return software_node_get(software_node_fwnode(ref[0].swnode));
> }
>
> static struct fwnode_handle *
> diff --git a/include/linux/property.h b/include/linux/property.h
> index 50b26589dd70d1756f3b8644255c24a011e2617c..52e784a3dfd4c93cee8b35e1cef5e0600639ecc5 100644
> --- a/include/linux/property.h
> +++ b/include/linux/property.h
> @@ -355,23 +355,37 @@ struct software_node;
>
> /**
> * struct software_node_ref_args - Reference property with additional arguments
> - * @node: Reference to a software node
> + * @swnode: Reference to a software node
> + * @fwnode: Alternative reference to a firmware node handle
> * @nargs: Number of elements in @args array
> * @args: Integer arguments
> */
> struct software_node_ref_args {
> - const struct software_node *node;
> + const struct software_node *swnode;
> + struct fwnode_handle *fwnode;
> unsigned int nargs;
> u64 args[NR_FWNODE_REFERENCE_ARGS];
> };
>
> -#define SOFTWARE_NODE_REFERENCE(_ref_, ...) \
> +#define __SOFTWARE_NODE_REF(_ref, _type, _node, ...) \
> (const struct software_node_ref_args) { \
> - .node = _ref_, \
> + ._node = _ref, \
> .nargs = COUNT_ARGS(__VA_ARGS__), \
> .args = { __VA_ARGS__ }, \
> }
>
> +#define SOFTWARE_NODE_REF_SWNODE(_ref, ...) \
> + __SOFTWARE_NODE_REF(_ref, SOFTWARE_NODE_REF_SWNODE, \
> + swnode, __VA_ARGS__)
> +
> +#define SOFTWARE_NODE_REF_FWNODE(_ref, ...) \
> + __SOFTWARE_NODE_REF(_ref, SOFTWARE_NODE_REF_FWNODE, \
> + fwnode, __VA_ARGS__)
> +
> +/* DEPRECATED, use SOFTWARE_NODE_REF_SWNODE() instead. */
> +#define SOFTWARE_NODE_REFERENCE(_ref, ...) \
> + SOFTWARE_NODE_REF_SWNODE(_ref, __VA_ARGS__)
> +
> /**
> * struct property_entry - "Built-in" device property representation.
> * @name: Name of the property.
> @@ -463,14 +477,26 @@ struct property_entry {
> #define PROPERTY_ENTRY_STRING(_name_, _val_) \
> __PROPERTY_ENTRY_ELEMENT(_name_, str, STRING, _val_)
>
> -#define PROPERTY_ENTRY_REF(_name_, _ref_, ...) \
> +#define __PROPERTY_ENTRY_REF(_type, _name, _ref, ...) \
> (struct property_entry) { \
> - .name = _name_, \
> + .name = _name, \
> .length = sizeof(struct software_node_ref_args), \
> .type = DEV_PROP_REF, \
> - { .pointer = &SOFTWARE_NODE_REFERENCE(_ref_, ##__VA_ARGS__), }, \
> + { .pointer = &_type(_ref, ##__VA_ARGS__), }, \
> }
>
> +#define PROPERTY_ENTRY_REF_SWNODE(_name, _ref, ...) \
> + __PROPERTY_ENTRY_REF(SOFTWARE_NODE_REF_SWNODE, \
> + _name, _ref, __VA_ARGS__)
> +
> +#define PROPERTY_ENTRY_REF_FWNODE(_name, _ref, ...) \
> + __PROPERTY_ENTRY_REF(SOFTWARE_NODE_REF_FWNODE, \
> + _name, _ref, __VA_ARGS__)
> +
> +/* DEPRECATED, use PROPERTY_ENTRY_REF_SWNODE() instead. */
> +#define PROPERTY_ENTRY_REF(_name, _ref, ...) \
> + PROPERTY_ENTRY_REF_SWNODE(_name, _ref, __VA_ARGS__)
> +
> #define PROPERTY_ENTRY_BOOL(_name_) \
> (struct property_entry) { \
> .name = _name_, \
>
--
Regards,
Sakari Ailus
next prev parent reply other threads:[~2025-10-24 15:17 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-22 13:40 [PATCH v2 0/9] reset: rework reset-gpios handling Bartosz Golaszewski
2025-10-22 13:41 ` [PATCH v2 1/9] software node: read the reference args via the fwnode API Bartosz Golaszewski
2025-10-22 13:41 ` [PATCH v2 2/9] software node: increase the reference of the swnode by its fwnode Bartosz Golaszewski
2025-10-22 13:41 ` [PATCH v2 3/9] software node: allow referencing firmware nodes Bartosz Golaszewski
2025-10-22 18:59 ` Andy Shevchenko
2025-10-24 7:06 ` Bartosz Golaszewski
2025-10-24 15:17 ` Sakari Ailus [this message]
2025-10-24 15:27 ` Bartosz Golaszewski
2025-10-22 13:41 ` [PATCH v2 4/9] gpio: swnode: don't use the swnode's name as the key for GPIO lookup Bartosz Golaszewski
2025-10-22 18:44 ` Andy Shevchenko
2025-10-24 7:17 ` Bartosz Golaszewski
2025-10-22 13:41 ` [PATCH v2 5/9] gpio: swnode: update the property definitions Bartosz Golaszewski
2025-10-22 13:41 ` [PATCH v2 6/9] reset: order includes alphabetically in reset/core.c Bartosz Golaszewski
2025-10-22 13:41 ` [PATCH v2 7/9] reset: make the provider of reset-gpios the parent of the reset device Bartosz Golaszewski
2025-10-22 14:45 ` Philipp Zabel
2025-10-22 14:52 ` Bartosz Golaszewski
2025-10-22 13:41 ` [PATCH v2 8/9] reset: gpio: convert the driver to using the auxiliary bus Bartosz Golaszewski
2025-10-22 18:38 ` Andy Shevchenko
2025-10-22 13:41 ` [PATCH v2 9/9] reset: gpio: use software nodes to setup the GPIO lookup Bartosz Golaszewski
2025-10-22 14:45 ` Philipp Zabel
2025-10-23 12:20 ` [PATCH v2 0/9] reset: rework reset-gpios handling Linus Walleij
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=aPuYg0ws8Q2sp7Wv@kekkonen.localdomain \
--to=sakari.ailus@linux.intel.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bartosz.golaszewski@linaro.org \
--cc=brgl@bgdev.pl \
--cc=dakr@kernel.org \
--cc=djrscally@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=krzk@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=rafael@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®