From: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
To: Linus Walleij <linusw@kernel.org>,
Bartosz Golaszewski <brgl@kernel.org>,
Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <skhan@linuxfoundation.org>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org,
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Subject: [PATCH v2] Documentation: gpio: update the preferred method for using software node lookup
Date: Fri, 03 Apr 2026 15:04:55 +0200 [thread overview]
Message-ID: <20260403-doc-gpio-swnodes-v2-1-c705f5897b80@oss.qualcomm.com> (raw)
In its current version, the manual for converting of board files from
using GPIO lookup tables to software nodes recommends leaving the
software nodes representing GPIO controllers as "free-floating", not
attached objects and relying on the matching of their names against the
GPIO controller's name. This is an abuse of the software node API and
makes it impossible to create fw_devlinks between GPIO suppliers and
consumers in this case. We want to remove this behavior from GPIOLIB and
to this end, work on converting all existing drivers to using "attached"
software nodes.
Except for a few corner-cases where board files define consumers
depending on GPIO controllers described in firmware - where we need to
reference a real firmware node from a software node - which requires a
more complex approach, most board files can easily be converted to using
propert firmware node lookup.
Update the documentation to recommend attaching the GPIO chip's software
nodes to the actual platform devices and show how to do it.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
Changes in v2:
- Use the new .swnode field of struct platform_device_info in examples
- Fix whitespaces
- Link to v1: https://patch.msgid.link/20260331-doc-gpio-swnodes-v1-1-3f84c268999b@oss.qualcomm.com
---
Documentation/driver-api/gpio/board.rst | 20 +++++++++++---
Documentation/driver-api/gpio/legacy-boards.rst | 36 ++++++++++++++++++-------
2 files changed, 44 insertions(+), 12 deletions(-)
diff --git a/Documentation/driver-api/gpio/board.rst b/Documentation/driver-api/gpio/board.rst
index 0993cac891fb5e4887a1aee6deae273197c6aae1..b306c21481d7c191201d81d228a290a908cc82ab 100644
--- a/Documentation/driver-api/gpio/board.rst
+++ b/Documentation/driver-api/gpio/board.rst
@@ -108,9 +108,8 @@ macro, which ties a software node representing the GPIO controller with
consumer device. It allows consumers to use regular gpiolib APIs, such as
gpiod_get(), gpiod_get_optional().
-The software node representing a GPIO controller need not be attached to the
-GPIO controller device. The only requirement is that the node must be
-registered and its name must match the GPIO controller's label.
+The software node representing a GPIO controller must be attached to the
+GPIO controller device - either as the primary or the secondary firmware node.
For example, here is how to describe a single GPIO-connected LED. This is an
alternative to using platform_data on legacy systems.
@@ -153,6 +152,21 @@ alternative to using platform_data on legacy systems.
};
software_node_register_node_group(swnodes);
+ /*
+ * 5. Attach the GPIO controller's software node to the device and
+ * register it.
+ */
+ static void gpio_foo_register(void)
+ {
+ struct platform_device_info pdev_info = {
+ .name = "gpio-foo",
+ .id = PLATFORM_DEVID_NONE,
+ .swnode = &gpio_controller_node
+ };
+
+ platform_device_register_full(&pdev_info);
+ }
+
// Then register a platform_device for "leds-gpio" and associate
// it with &led_device_swnode via .fwnode.
diff --git a/Documentation/driver-api/gpio/legacy-boards.rst b/Documentation/driver-api/gpio/legacy-boards.rst
index 46e3a26dba772e5e5117866b5d202e76c8e2adf2..a9d33bcbb176b5df99838bd03e43ec2ebf4d9db6 100644
--- a/Documentation/driver-api/gpio/legacy-boards.rst
+++ b/Documentation/driver-api/gpio/legacy-boards.rst
@@ -36,12 +36,10 @@ Requirements for GPIO Properties
When using software nodes to describe GPIO connections, the following
requirements must be met for the GPIO core to correctly resolve the reference:
-1. **The GPIO controller's software node "name" must match the controller's
- "label".** The gpiolib core uses this name to find the corresponding
- struct gpio_chip at runtime.
- This software node has to be registered, but need not be attached to the
- device representing the GPIO controller that is providing the GPIO in
- question. It may be left as a "free floating" node.
+1. **The GPIO controller's software node must be registered and attached to
+ the controller's ``struct device`` either as its primary or secondary
+ firmware node.** The gpiolib core uses the address of the firmware node to
+ find the corresponding ``struct gpio_chip`` at runtime.
2. **The GPIO property must be a reference.** The ``PROPERTY_ENTRY_GPIO()``
macro handles this as it is an alias for ``PROPERTY_ENTRY_REF()``.
@@ -121,13 +119,21 @@ A typical legacy board file might look like this:
/* Device registration */
static int __init myboard_init(void)
{
+ struct platform_device_info pdev_info = {
+ .name = MYBOARD_GPIO_CONTROLLER,
+ .id = PLATFORM_DEVID_NONE,
+ .swnode = &gpio_controller_node
+ };
+
gpiod_add_lookup_table(&myboard_leds_gpios);
gpiod_add_lookup_table(&myboard_buttons_gpios);
+ platform_device_register_full(&pdev_info);
platform_device_register_data(NULL, "leds-gpio", -1,
&myboard_leds_pdata, sizeof(myboard_leds_pdata));
platform_device_register_data(NULL, "gpio-keys", -1,
- &myboard_buttons_pdata, sizeof(myboard_buttons_pdata));
+ &myboard_buttons_pdata,
+ sizeof(myboard_buttons_pdata));
return 0;
}
@@ -141,8 +147,7 @@ Step 1: Define the GPIO Controller Node
***************************************
First, define a software node that represents the GPIO controller that the
-LEDs and buttons are connected to. The ``name`` of this node must match the
-name of the driver for the GPIO controller (e.g., "gpio-foo").
+LEDs and buttons are connected to. The ``name`` of this node is optional.
.. code-block:: c
@@ -257,6 +262,16 @@ software nodes using the ``fwnode`` field in struct platform_device_info.
if (error)
return error;
+ memset(&pdev_info, 0, sizeof(pdev_info));
+ pdev_info.name = MYBOARD_GPIO_CONTROLLER;
+ pdev_info.id = PLATFORM_DEVID_NONE;
+ pdev_info.swnode = &myboard_gpio_controller_node;
+ gpio_pdev = platform_device_register_full(&pdev_info);
+ if (IS_ERR(gpio_pdev)) {
+ error = PTR_ERR(gpio_pdev);
+ goto err_unregister_nodes;
+ }
+
memset(&pdev_info, 0, sizeof(pdev_info));
pdev_info.name = "leds-gpio";
pdev_info.id = PLATFORM_DEVID_NONE;
@@ -264,6 +279,7 @@ software nodes using the ``fwnode`` field in struct platform_device_info.
leds_pdev = platform_device_register_full(&pdev_info);
if (IS_ERR(leds_pdev)) {
error = PTR_ERR(leds_pdev);
+ platform_device_unregister(gpio_pdev);
goto err_unregister_nodes;
}
@@ -274,6 +290,7 @@ software nodes using the ``fwnode`` field in struct platform_device_info.
keys_pdev = platform_device_register_full(&pdev_info);
if (IS_ERR(keys_pdev)) {
error = PTR_ERR(keys_pdev);
+ platform_device_unregister(gpio_pdev);
platform_device_unregister(leds_pdev);
goto err_unregister_nodes;
}
@@ -289,6 +306,7 @@ software nodes using the ``fwnode`` field in struct platform_device_info.
{
platform_device_unregister(keys_pdev);
platform_device_unregister(leds_pdev);
+ platform_device_unregister(gpio_pdev);
software_node_unregister_node_group(myboard_swnodes);
}
---
base-commit: cc13002a9f984d37906e9476f3e532a8cdd126f5
change-id: 20260331-doc-gpio-swnodes-fc3ddf59b8dc
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
next reply other threads:[~2026-04-03 13:05 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-03 13:04 Bartosz Golaszewski [this message]
2026-04-07 10:03 ` [PATCH v2] Documentation: gpio: update the preferred method for using software node lookup Linus Walleij
2026-04-08 13:55 ` 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=20260403-doc-gpio-swnodes-v2-1-c705f5897b80@oss.qualcomm.com \
--to=bartosz.golaszewski@oss.qualcomm.com \
--cc=brgl@kernel.org \
--cc=corbet@lwn.net \
--cc=dmitry.torokhov@gmail.com \
--cc=linusw@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=skhan@linuxfoundation.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).