When a software-node gets added to a device which already has another fwnode as primary node it will become the secondary fwnode for that device.
Currently if a software-node with GPIO properties ends up as the secondary fwnode then gpiod_find_by_fwnode() will fail to find the GPIOs.
Add a check to gpiod_find_by_fwnode() to try a software-node lookup on the secondary fwnode if the GPIO was not found in the primary fwnode.
Fixes: e7f9ff5dc90c ("gpiolib: add support for software nodes") Cc: stable@vger.kernel.org Cc: Dmitry Torokhov dmitry.torokhov@gmail.com Signed-off-by: Hans de Goede hansg@kernel.org --- I found this issue while testing "platform/x86: x86-android-tablets: convert wm1502 devices to GPIO references": https://lore.kernel.org/platform-driver-x86/20250810-x86-andoroid-tablet-v2-... which adds a software node with GPIO lookup info the a spi-10WM5102:00 device which has an ACPI fwnode as primary fwnode. --- drivers/gpio/gpiolib.c | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index 0d2b470a252e..b619fea498c8 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -4601,6 +4601,12 @@ static struct gpio_desc *gpiod_find_by_fwnode(struct fwnode_handle *fwnode, desc = swnode_find_gpio(fwnode, con_id, idx, lookupflags); }
+ if (desc == ERR_PTR(-ENOENT) && fwnode && is_software_node(fwnode->secondary)) { + dev_dbg(consumer, "using secondary-swnode '%pfw' for '%s' GPIO lookup\n", + fwnode->secondary, name); + desc = swnode_find_gpio(fwnode->secondary, con_id, idx, lookupflags); + } + return desc; }
On Sat, Sep 13, 2025 at 9:43 PM Hans de Goede hansg@kernel.org wrote:
When a software-node gets added to a device which already has another fwnode as primary node it will become the secondary fwnode for that device.
Currently if a software-node with GPIO properties ends up as the secondary fwnode then gpiod_find_by_fwnode() will fail to find the GPIOs.
Add a check to gpiod_find_by_fwnode() to try a software-node lookup on the secondary fwnode if the GPIO was not found in the primary fwnode.
I found this issue while testing "platform/x86: x86-android-tablets: convert wm1502 devices to GPIO references": https://lore.kernel.org/platform-driver-x86/20250810-x86-andoroid-tablet-v2-... which adds a software node with GPIO lookup info the a spi-10WM5102:00 device which has an ACPI fwnode as primary fwnode.
While this is a quick fix, the long term one should be in a full redesigning of the fwnode concept in the kernel. The limitation of the linked list to two sooner or later strikes us. Besides that, the list of fwnodes conceptually is not property of the fwnode itself. The struct device may have struct list_head swnodes; besides possible other users. In particular this also will allow to have OF and ACPI nodes along with swnodes. You can say "are you crazy?", but look at the DSA development and other interesting PCI devices that are basically computers-as-a-card. The floating patch series is to enable OF enumeration for the devices on that type of cards even on ACPI based platforms. Which make above mentioned use-case not so theoretical.
On Sun, Sep 14, 2025 at 4:34 PM Andy Shevchenko andy.shevchenko@gmail.com wrote:
On Sat, Sep 13, 2025 at 9:43 PM Hans de Goede hansg@kernel.org wrote:
...
the long term one should be in a full redesigning of the fwnode concept in the kernel. The limitation of the linked list to two sooner or later strikes us. Besides that, the list of fwnodes conceptually is not property of the fwnode itself. The struct device may have struct list_head swnodes; besides possible other users. In particular this also will allow to have OF and ACPI nodes along with swnodes. You can say "are you crazy?", but look at the DSA development and other interesting PCI devices that are basically computers-as-a-card. The floating patch series is to enable OF enumeration for the devices on that type of cards even on ACPI based platforms. Which make above mentioned use-case not so theoretical.
FWIW, that's why I for more than a year require people to use dev_fwnode() and dev_of_node() (and similar) APIs instead of dereferencing them directly in order to make less churn in case of the above ever happens.
Hi Hans,
On Sat, Sep 13, 2025 at 08:43:09PM +0200, Hans de Goede wrote:
When a software-node gets added to a device which already has another fwnode as primary node it will become the secondary fwnode for that device.
Currently if a software-node with GPIO properties ends up as the secondary fwnode then gpiod_find_by_fwnode() will fail to find the GPIOs.
Add a check to gpiod_find_by_fwnode() to try a software-node lookup on the secondary fwnode if the GPIO was not found in the primary fwnode.
Thanks for catching this. I think it would be better if we added handling of the secondary node to gpiod_find_and_request(). This way the fallback will work for all kind of combinations, even if secondary node happens to be an OF or ACPI one.
Thanks.
linux-stable-mirror@lists.linaro.org
-
Andy Shevchenko -
Dmitry Torokhov -
Hans de Goede