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.