drivers/acpi/bus.c | 1 + drivers/base/swnode.c | 2 +- drivers/gpio/gpiolib-swnode.c | 9 ++ drivers/platform/x86/x86-android-tablets/core.c | 127 +++++++++++++++++++++++- 4 files changed, 135 insertions(+), 4 deletions(-)
First let me repeat the problem statement:
==
GPIO software node lookup should rely exclusively on matching the
addresses of the referenced firmware nodes. I tried to enforce it with
commit e5d527be7e69 ("gpio: swnode: don't use the swnode's name as the
key for GPIO lookup") but it broke existing users who abuse the software
node mechanism by creating "dummy" software nodes named after the device
they want to get GPIOs from but never attaching them to the actual GPIO
devices. They rely on the current behavior of GPIOLIB where it will match
the label of the GPIO controller against the name of the software node
and does not require a true link.
x86-android-tablets driver is one of the abusers in that it creates
dummy software nodes for baytrail and cherryview GPIO controllers but
they don't really reference these devices. Before we can reapply
e5d527be7e69 and support matching by fwnode address exclusively, we need
to convert all the users to using actual fwnode references.
==
Now for the new approach:
Now with the recent patches I sent or plan to send out, it turns out
that almost all existing users of software node lookup can easily have
the software node's representing the GPIO controllers attached to their
target devices as their primary firmware node. The remaining complex
cases are: pcengines-apuv2 and geode-common but in the first case we
have control over the creation of the GPIO device - we can assign it a
firmware node - and in the second case, we deal with an MFD driver so
can export the cell's software node in a header.
The only remaining use-case where we need to reference a GPIO controller
described in ACPI from a software node is the x86-android-tablets
driver. In this case, I think it no longer makes sense to propose a new
generic interface. Instead, I'd like to propose to keep it as a
driver-specific quirk.
This series proposes the following changes:
1. Switch to returning -ENXIO if we try to resolve a reference to
a software node that's not registered as a firmware node yet to
differentiate it from other situations in which we return -ENOENT.
2. In GPIO core: return -EPROBE_DEFER from swnode lookup if
fwnode_get_reference_args() returns -ENXIO as an unregistered software
node is not much different from the situation where there's a firmware
node not backed by a device yet.
3. Export the acpi_bus_type symbol. It's already available in the
acpi_bus.h header but it's not available to loadable modules.
4. Finally: implement support for dynamic assignment of secondary
firmware nodes in the x86-android-tablets driver. More details on how
it's approached are in the relevant commit message.
Merging strategy: I'd like to propose queing patches 1-3 independently
through their respective trees: driver core, GPIO and ACPI. The final
patch would make its way upstream after v7.1-rc1. I would probably
extend it to convert the driver to using more devres interfaces too at
this point.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
Changes in v2:
- Completely new approach
- Keep the cherryview and baytrail secondary fwnode handling as a
driver-specific quirk for x86 tablets and don't introduce any new API
- Change the return value when resolving a reference to an unregistered
software node and defer probe in GPIOLIB in that situation
- Export acpi_bus_type for use in x86-android-tablets
- Link to v1: https://patch.msgid.link/20260319-baytrail-real-swnode-v1-0-75f2264ae49f@oss.qualcomm.com
---
Bartosz Golaszewski (4):
software node: return -ENXIO when referenced swnode is not registered yet
gpio: swnode: defer probe on references to unregistered software nodes
ACPI: bus: export the acpi_bus_type symbol
platform/x86: x86-android-tablets: enable fwnode matching of GPIO chips
drivers/acpi/bus.c | 1 +
drivers/base/swnode.c | 2 +-
drivers/gpio/gpiolib-swnode.c | 9 ++
drivers/platform/x86/x86-android-tablets/core.c | 127 +++++++++++++++++++++++-
4 files changed, 135 insertions(+), 4 deletions(-)
---
base-commit: d18fd67e5f09e800611b02e2afda430a870a136b
change-id: 20260319-baytrail-real-swnode-7de7a3870f78
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
On Thu, Apr 02, 2026 at 02:54:25PM +0200, Bartosz Golaszewski wrote:
> First let me repeat the problem statement:
>
> ==
>
> GPIO software node lookup should rely exclusively on matching the
> addresses of the referenced firmware nodes. I tried to enforce it with
> commit e5d527be7e69 ("gpio: swnode: don't use the swnode's name as the
> key for GPIO lookup") but it broke existing users who abuse the software
> node mechanism by creating "dummy" software nodes named after the device
> they want to get GPIOs from but never attaching them to the actual GPIO
> devices. They rely on the current behavior of GPIOLIB where it will match
> the label of the GPIO controller against the name of the software node
> and does not require a true link.
>
> x86-android-tablets driver is one of the abusers in that it creates
> dummy software nodes for baytrail and cherryview GPIO controllers but
> they don't really reference these devices. Before we can reapply
> e5d527be7e69 and support matching by fwnode address exclusively, we need
> to convert all the users to using actual fwnode references.
>
> ==
>
> Now for the new approach:
>
> Now with the recent patches I sent or plan to send out, it turns out
> that almost all existing users of software node lookup can easily have
> the software node's representing the GPIO controllers attached to their
> target devices as their primary firmware node. The remaining complex
> cases are: pcengines-apuv2 and geode-common but in the first case we
> have control over the creation of the GPIO device - we can assign it a
> firmware node - and in the second case, we deal with an MFD driver so
> can export the cell's software node in a header.
>
> The only remaining use-case where we need to reference a GPIO controller
> described in ACPI from a software node is the x86-android-tablets
> driver. In this case, I think it no longer makes sense to propose a new
> generic interface. Instead, I'd like to propose to keep it as a
> driver-specific quirk.
>
> This series proposes the following changes:
> 1. Switch to returning -ENXIO if we try to resolve a reference to
> a software node that's not registered as a firmware node yet to
> differentiate it from other situations in which we return -ENOENT.
> 2. In GPIO core: return -EPROBE_DEFER from swnode lookup if
> fwnode_get_reference_args() returns -ENXIO as an unregistered software
> node is not much different from the situation where there's a firmware
> node not backed by a device yet.
> 3. Export the acpi_bus_type symbol. It's already available in the
> acpi_bus.h header but it's not available to loadable modules.
Nowadays we don't do that but export the dev_is_acpi() or something similar if
it's not yet available and to_acpi_dev(). (Names are derived from the existing
pattern, they might be need to be adjusted, dunno.) See how PNP does that.
Note, I haven't read the patches yet, just a quick comment.
> 4. Finally: implement support for dynamic assignment of secondary
> firmware nodes in the x86-android-tablets driver. More details on how
> it's approached are in the relevant commit message.
>
> Merging strategy: I'd like to propose queing patches 1-3 independently
> through their respective trees: driver core, GPIO and ACPI. The final
> patch would make its way upstream after v7.1-rc1. I would probably
> extend it to convert the driver to using more devres interfaces too at
> this point.
--
With Best Regards,
Andy Shevchenko
On Thu, Apr 2, 2026 at 3:23 PM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > > 3. Export the acpi_bus_type symbol. It's already available in the > > acpi_bus.h header but it's not available to loadable modules. > > Nowadays we don't do that but export the dev_is_acpi() or something similar if > it's not yet available and to_acpi_dev(). (Names are derived from the existing > pattern, they might be need to be adjusted, dunno.) See how PNP does that. > Note, I haven't read the patches yet, just a quick comment. > Maybe I should have said why I do it. It's to register a notifier call on ACPI bus events. Is there a better way to do this? Bart
On Thu, Apr 02, 2026 at 03:35:24PM +0200, Bartosz Golaszewski wrote: > On Thu, Apr 2, 2026 at 3:23 PM Andy Shevchenko > <andriy.shevchenko@linux.intel.com> wrote: > > > > > 3. Export the acpi_bus_type symbol. It's already available in the > > > acpi_bus.h header but it's not available to loadable modules. > > > > Nowadays we don't do that but export the dev_is_acpi() or something similar if > > it's not yet available and to_acpi_dev(). (Names are derived from the existing > > pattern, they might be need to be adjusted, dunno.) See how PNP does that. > > Note, I haven't read the patches yet, just a quick comment. > > Maybe I should have said why I do it. It's to register a notifier call > on ACPI bus events. Is there a better way to do this? AFAIU there shouldn't be pure ACPI devices, they are companions to the real ones. Can we simply attach to the normal device notifier and check if the companion is what we are looking for? Also since it's specific to that driver and you know what the platforms you are looking for, why can't we hook something into drivers/acpi/x86/lpss.c? -- With Best Regards, Andy Shevchenko
On Thu, Apr 2, 2026 at 3:47 PM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > On Thu, Apr 02, 2026 at 03:35:24PM +0200, Bartosz Golaszewski wrote: > > On Thu, Apr 2, 2026 at 3:23 PM Andy Shevchenko > > <andriy.shevchenko@linux.intel.com> wrote: > > > > > > > 3. Export the acpi_bus_type symbol. It's already available in the > > > > acpi_bus.h header but it's not available to loadable modules. > > > > > > Nowadays we don't do that but export the dev_is_acpi() or something similar if > > > it's not yet available and to_acpi_dev(). (Names are derived from the existing > > > pattern, they might be need to be adjusted, dunno.) See how PNP does that. > > > Note, I haven't read the patches yet, just a quick comment. > > > > Maybe I should have said why I do it. It's to register a notifier call > > on ACPI bus events. Is there a better way to do this? > > AFAIU there shouldn't be pure ACPI devices, they are companions to the real > ones. Can we simply attach to the normal device notifier and check if the > companion is what we are looking for? Also since it's specific to that driver > and you know what the platforms you are looking for, why can't we hook > something into drivers/acpi/x86/lpss.c? > The ACPI companions seem to only ever be added once and never removed - unlike platform devices. This is why I prefer to check the ACPI bus. As for lpss.c - what do you sugest exactly because at first glance I'm not quite sure what's there to hook up? Bart
On Thu, Apr 02, 2026 at 05:03:10PM +0200, Bartosz Golaszewski wrote: > On Thu, Apr 2, 2026 at 3:47 PM Andy Shevchenko > <andriy.shevchenko@linux.intel.com> wrote: > > On Thu, Apr 02, 2026 at 03:35:24PM +0200, Bartosz Golaszewski wrote: > > > On Thu, Apr 2, 2026 at 3:23 PM Andy Shevchenko > > > <andriy.shevchenko@linux.intel.com> wrote: ... > > > > > 3. Export the acpi_bus_type symbol. It's already available in the > > > > > acpi_bus.h header but it's not available to loadable modules. > > > > > > > > Nowadays we don't do that but export the dev_is_acpi() or something similar if > > > > it's not yet available and to_acpi_dev(). (Names are derived from the existing > > > > pattern, they might be need to be adjusted, dunno.) See how PNP does that. > > > > Note, I haven't read the patches yet, just a quick comment. > > > > > > Maybe I should have said why I do it. It's to register a notifier call > > > on ACPI bus events. Is there a better way to do this? > > > > AFAIU there shouldn't be pure ACPI devices, they are companions to the real > > ones. Can we simply attach to the normal device notifier and check if the > > companion is what we are looking for? Also since it's specific to that driver > > and you know what the platforms you are looking for, why can't we hook > > something into drivers/acpi/x86/lpss.c? > > The ACPI companions seem to only ever be added once and never removed > - unlike platform devices. This is why I prefer to check the ACPI bus. > > As for lpss.c - what do you sugest exactly because at first glance I'm > not quite sure what's there to hook up? Can't we create / submit the software node of the given device (GPIO) when it's get created (as platform device)? That driver uses a notification when ACPI bus is scanned, that's what may trigger the software node creation and the other end will eventually see it. -- With Best Regards, Andy Shevchenko
On Thu, Apr 2, 2026 at 6:05 PM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > On Thu, Apr 02, 2026 at 05:03:10PM +0200, Bartosz Golaszewski wrote: > > On Thu, Apr 2, 2026 at 3:47 PM Andy Shevchenko > > <andriy.shevchenko@linux.intel.com> wrote: > > > On Thu, Apr 02, 2026 at 03:35:24PM +0200, Bartosz Golaszewski wrote: > > > > On Thu, Apr 2, 2026 at 3:23 PM Andy Shevchenko > > > > <andriy.shevchenko@linux.intel.com> wrote: > > ... > > > > > > > 3. Export the acpi_bus_type symbol. It's already available in the > > > > > > acpi_bus.h header but it's not available to loadable modules. > > > > > > > > > > Nowadays we don't do that but export the dev_is_acpi() or something similar if > > > > > it's not yet available and to_acpi_dev(). (Names are derived from the existing > > > > > pattern, they might be need to be adjusted, dunno.) See how PNP does that. > > > > > Note, I haven't read the patches yet, just a quick comment. > > > > > > > > Maybe I should have said why I do it. It's to register a notifier call > > > > on ACPI bus events. Is there a better way to do this? > > > > > > AFAIU there shouldn't be pure ACPI devices, they are companions to the real > > > ones. Can we simply attach to the normal device notifier and check if the > > > companion is what we are looking for? Also since it's specific to that driver > > > and you know what the platforms you are looking for, why can't we hook > > > something into drivers/acpi/x86/lpss.c? > > > > The ACPI companions seem to only ever be added once and never removed > > - unlike platform devices. This is why I prefer to check the ACPI bus. > > > > As for lpss.c - what do you sugest exactly because at first glance I'm > > not quite sure what's there to hook up? > > Can't we create / submit the software node of the given device (GPIO) > when it's get created (as platform device)? That driver uses a notification > when ACPI bus is scanned, that's what may trigger the software node creation > and the other end will eventually see it. > Yeah that would be awesome but you still need to export these software nodes to the x86-android-tablets driver. I think it's better to keep them in the driver as it's the only user and it's unlikely there'll be more similar cases. Bart
On Thu, Apr 02, 2026 at 06:13:38PM +0200, Bartosz Golaszewski wrote: > On Thu, Apr 2, 2026 at 6:05 PM Andy Shevchenko > <andriy.shevchenko@linux.intel.com> wrote: > > On Thu, Apr 02, 2026 at 05:03:10PM +0200, Bartosz Golaszewski wrote: > > > On Thu, Apr 2, 2026 at 3:47 PM Andy Shevchenko > > > <andriy.shevchenko@linux.intel.com> wrote: > > > > On Thu, Apr 02, 2026 at 03:35:24PM +0200, Bartosz Golaszewski wrote: > > > > > On Thu, Apr 2, 2026 at 3:23 PM Andy Shevchenko > > > > > <andriy.shevchenko@linux.intel.com> wrote: ... > > > > > > > 3. Export the acpi_bus_type symbol. It's already available in the > > > > > > > acpi_bus.h header but it's not available to loadable modules. > > > > > > > > > > > > Nowadays we don't do that but export the dev_is_acpi() or something similar if > > > > > > it's not yet available and to_acpi_dev(). (Names are derived from the existing > > > > > > pattern, they might be need to be adjusted, dunno.) See how PNP does that. > > > > > > Note, I haven't read the patches yet, just a quick comment. > > > > > > > > > > Maybe I should have said why I do it. It's to register a notifier call > > > > > on ACPI bus events. Is there a better way to do this? > > > > > > > > AFAIU there shouldn't be pure ACPI devices, they are companions to the real > > > > ones. Can we simply attach to the normal device notifier and check if the > > > > companion is what we are looking for? Also since it's specific to that driver > > > > and you know what the platforms you are looking for, why can't we hook > > > > something into drivers/acpi/x86/lpss.c? > > > > > > The ACPI companions seem to only ever be added once and never removed > > > - unlike platform devices. This is why I prefer to check the ACPI bus. > > > > > > As for lpss.c - what do you sugest exactly because at first glance I'm > > > not quite sure what's there to hook up? > > > > Can't we create / submit the software node of the given device (GPIO) > > when it's get created (as platform device)? That driver uses a notification > > when ACPI bus is scanned, that's what may trigger the software node creation > > and the other end will eventually see it. > > Yeah that would be awesome but you still need to export these software > nodes to the x86-android-tablets driver. I think it's better to keep > them in the driver as it's the only user and it's unlikely there'll be > more similar cases. As I mentioned, the mentioned driver is a specific enumeration for the given platform(s), it's the best place to keep things there related to LPSS island on those platforms (SoCs). Exporting is fine as that driver makes the whole SoC somewhat useful, otherwise it's just piece of x86 core which makes a little sense to have without the crucial peripheral drivers be enabled. -- With Best Regards, Andy Shevchenko
© 2016 - 2026 Red Hat, Inc.