[PATCH v2 0/4] platform/x86: x86-android-tablets: use real firmware node references with intel drivers

[PATCH v2 0/4] platform/x86: x86-android-tablets: use real firmware node references with intel drivers

[Bartosz Golaszewski]

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>

[PATCH v2 1/4] software node: return -ENXIO when referenced swnode is not registered yet

[Bartosz Golaszewski]

It's possible that at the time of resolving a reference to a remote
software node, the node we know exists is not yet registered as a full
firmware node. We currently return -ENOENT in this case but the same
error code is also returned in some other cases, like the reference
property with given name not existing in the property list of the local
software node.

It makes sense to let users know that we're dealing with an unregistered
software node so that they can defer probe - the situation is somewhat
similar to there existing a firmware node to which no device is bound
yet - which is valid grounds for probe deferral. To that end: use -ENXIO
which stands for "No such device or address".

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
 drivers/base/swnode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
index 51320837f3a9f1bf4f65aa161d9b941affc74936..29eec7ba500e8c8a02482dfac68f2c313cfadee7 100644
--- a/drivers/base/swnode.c
+++ b/drivers/base/swnode.c
@@ -554,7 +554,7 @@ software_node_get_reference_args(const struct fwnode_handle *fwnode,
 		return -EINVAL;
 
 	if (!refnode)
-		return -ENOENT;
+		return -ENXIO;
 
 	if (nargs_prop) {
 		error = fwnode_property_read_u32(refnode, nargs_prop, &nargs_prop_val);

-- 
2.47.3

[PATCH v2 2/4] gpio: swnode: defer probe on references to unregistered software nodes

[Bartosz Golaszewski]

fwnode_property_get_reference_args() now returns -ENXIO when called on a
software node referencing another software node which has not yet been
registered as a firmware node. It makes sense to defer probe in this
situation as the node will most likely be registered later on and we'll
be able to resolve the reference eventually. Change the behavior of
swnode_find_gpio() to return -EPROBE_DEFER if the software node reference
resolution returns -ENXIO.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
 drivers/gpio/gpiolib-swnode.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpio/gpiolib-swnode.c b/drivers/gpio/gpiolib-swnode.c
index 0d7f3f09a0b4bee0cf1bbdaa8b7b8ae4cd5de581..06d74e9e199de0b91a019e5e15d4b83d330291e7 100644
--- a/drivers/gpio/gpiolib-swnode.c
+++ b/drivers/gpio/gpiolib-swnode.c
@@ -95,6 +95,15 @@ struct gpio_desc *swnode_find_gpio(struct fwnode_handle *fwnode,
 			break;
 	}
 	if (ret) {
+		if (ret == -ENXIO)
+			/*
+			 * -ENXIO for a software node reference lookup means
+			 *  that a remote struct software_node exists but has
+			 *  not yet been registered as a firmware node. Defer
+			 *  until this happens.
+			 */
+			return ERR_PTR(-EPROBE_DEFER);
+
 		pr_debug("%s: can't parse '%s' property of node '%pfwP[%d]'\n",
 			__func__, propname, fwnode, idx);
 		return ERR_PTR(ret);

-- 
2.47.3

[PATCH v2 3/4] ACPI: bus: export the acpi_bus_type symbol

[Bartosz Golaszewski]

In order to allow loadable modules to access the ACPI bus type struct,
export the relevant symbol.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
 drivers/acpi/bus.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 2ec095e2009e40b0645f654fb051429e5679dc7c..d4da76607905473de2e25e50352450c10f598784 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -1174,6 +1174,7 @@ const struct bus_type acpi_bus_type = {
 	.remove		= acpi_device_remove,
 	.uevent		= acpi_device_uevent,
 };
+EXPORT_SYMBOL_GPL(acpi_bus_type);
 
 int acpi_bus_for_each_dev(int (*fn)(struct device *, void *), void *data)
 {

-- 
2.47.3

[PATCH v2 4/4] platform/x86: x86-android-tablets: enable fwnode matching of GPIO chips

[Bartosz Golaszewski]

In order to allow GPIOLIB to match cherryview and baytrail GPIO
controllers by their firmware nodes instead of their names, we need to
attach the - currently "dangling" - existing software nodes to their
target devices dynamically.

We deal with devices described in ACPI so set up a bus notifier waiting
for the ADD events. We know the name of the device we're waiting for so
match against it and - on match - assign the appropriate software node
as the secondary firmware node of the underlying ACPI node. In case the
event was emitted earlier than this driver's probe: also make sure the
device was not added before.

Scheduling fine-grained devres actions allows for proper teardown and
unsetting of the secondary firmware nodes.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
 drivers/platform/x86/x86-android-tablets/core.c | 127 +++++++++++++++++++++++-
 1 file changed, 124 insertions(+), 3 deletions(-)

diff --git a/drivers/platform/x86/x86-android-tablets/core.c b/drivers/platform/x86/x86-android-tablets/core.c
index 021009e9085bec3db9c4daa1f6235600210a6099..9e6e8f272dfe16cda421b569802045c3d94fc0ab 100644
--- a/drivers/platform/x86/x86-android-tablets/core.c
+++ b/drivers/platform/x86/x86-android-tablets/core.c
@@ -13,10 +13,12 @@
 #include <linux/acpi.h>
 #include <linux/device.h>
 #include <linux/dmi.h>
+#include <linux/fwnode.h>
 #include <linux/gpio/consumer.h>
 #include <linux/gpio/machine.h>
 #include <linux/irq.h>
 #include <linux/module.h>
+#include <linux/notifier.h>
 #include <linux/pci.h>
 #include <linux/platform_device.h>
 #include <linux/serdev.h>
@@ -360,6 +362,124 @@ static const struct software_node *cherryview_gpiochip_node_group[] = {
 	NULL
 };
 
+struct auto_secondary_data {
+	struct notifier_block nb;
+	struct device *parent;
+};
+
+static void auto_secondary_unset(void *data)
+{
+	struct fwnode_handle *fwnode = data;
+
+	fwnode->secondary = NULL;
+}
+
+static int acpi_set_secondary_fwnode(struct device *parent, struct device *dev,
+				     const struct software_node *const swnode)
+{
+	struct acpi_device *device = to_acpi_device(dev);
+	struct fwnode_handle *fwnode;
+	int ret;
+
+	fwnode = software_node_fwnode(swnode);
+	if (WARN_ON(!fwnode))
+		return -ENOENT;
+
+	fwnode->secondary = ERR_PTR(-ENODEV);
+	device->fwnode.secondary = fwnode;
+
+	ret = devm_add_action_or_reset(parent, auto_secondary_unset, &device->fwnode);
+	if (ret)
+		dev_err(parent, "Failed to schedule the unset action for secondary fwnode\n");
+
+	return ret;
+}
+
+static int acpi_auto_secondary_notifier(struct notifier_block *nb,
+					unsigned long action, void *data)
+{
+	struct auto_secondary_data *auto_sec = container_of(nb, struct auto_secondary_data, nb);
+	const struct software_node *const *swnode;
+	struct device *dev = data;
+	int ret;
+
+	switch (action) {
+	case BUS_NOTIFY_ADD_DEVICE:
+		for (swnode = gpiochip_node_group; *swnode; swnode++) {
+			if (strcmp((*swnode)->name, dev_name(dev)) == 0) {
+				ret = acpi_set_secondary_fwnode(auto_sec->parent, dev, *swnode);
+				return ret ? NOTIFY_BAD : NOTIFY_OK;
+			}
+		}
+		break;
+	default:
+		break;
+	}
+
+	return NOTIFY_DONE;
+}
+
+static void auto_secondary_unregister_node_group(void *data)
+{
+	const struct software_node **nodes = data;
+
+	software_node_unregister_node_group(nodes);
+}
+
+static void auto_secondary_unregister_notifier(void *data)
+{
+	struct notifier_block *nb = data;
+
+	bus_unregister_notifier(&acpi_bus_type, nb);
+}
+
+static int auto_secondary_fwnode_init(struct device *parent)
+{
+	const struct software_node *const *swnode;
+	struct auto_secondary_data *data;
+	int ret;
+
+	ret = software_node_register_node_group(gpiochip_node_group);
+	if (ret)
+		return ret;
+
+	ret = devm_add_action_or_reset(parent,
+				       auto_secondary_unregister_node_group,
+				       gpiochip_node_group);
+	if (ret)
+		return ret;
+
+	data = devm_kzalloc(parent, sizeof(*data), GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+
+	data->nb.notifier_call = acpi_auto_secondary_notifier;
+	data->parent = parent;
+
+	ret = bus_register_notifier(&acpi_bus_type, &data->nb);
+	if (ret)
+		return ret;
+
+	ret = devm_add_action_or_reset(parent,
+				       auto_secondary_unregister_notifier,
+				       &data->nb);
+	if (ret)
+		return ret;
+
+	/* Device may have been already added. */
+	for (swnode = gpiochip_node_group; *swnode; swnode++) {
+		struct device *dev __free(put_device) =
+			bus_find_device_by_name(&acpi_bus_type, NULL, (*swnode)->name);
+		if (dev) {
+			ret = acpi_set_secondary_fwnode(parent, dev, *swnode);
+			if (ret)
+				return ret;
+		}
+	}
+
+	return 0;
+}
+
 static void x86_android_tablet_remove(struct platform_device *pdev)
 {
 	int i;
@@ -391,7 +511,6 @@ static void x86_android_tablet_remove(struct platform_device *pdev)
 
 	software_node_unregister_node_group(gpio_button_swnodes);
 	software_node_unregister_node_group(swnode_group);
-	software_node_unregister_node_group(gpiochip_node_group);
 }
 
 static __init int x86_android_tablet_probe(struct platform_device *pdev)
@@ -427,9 +546,11 @@ static __init int x86_android_tablet_probe(struct platform_device *pdev)
 		break;
 	}
 
-	ret = software_node_register_node_group(gpiochip_node_group);
-	if (ret)
+	ret = auto_secondary_fwnode_init(&pdev->dev);
+	if (ret) {
+		x86_android_tablet_remove(pdev);
 		return ret;
+	}
 
 	ret = software_node_register_node_group(dev_info->swnode_group);
 	if (ret) {

-- 
2.47.3

Re: [PATCH v2 0/4] platform/x86: x86-android-tablets: use real firmware node references with intel drivers

[Andy Shevchenko]

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

Re: [PATCH v2 0/4] platform/x86: x86-android-tablets: use real firmware node references with intel drivers

[Bartosz Golaszewski]

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

Re: [PATCH v2 1/4] software node: return -ENXIO when referenced swnode is not registered yet

[Andy Shevchenko]

On Thu, Apr 02, 2026 at 02:54:26PM +0200, Bartosz Golaszewski wrote:
> It's possible that at the time of resolving a reference to a remote
> software node, the node we know exists is not yet registered as a full
> firmware node. We currently return -ENOENT in this case but the same
> error code is also returned in some other cases, like the reference
> property with given name not existing in the property list of the local
> software node.
> 
> It makes sense to let users know that we're dealing with an unregistered
> software node so that they can defer probe - the situation is somewhat
> similar to there existing a firmware node to which no device is bound
> yet - which is valid grounds for probe deferral. To that end: use -ENXIO
> which stands for "No such device or address".

This error code is also too generic to my taste. What about alternative(s)?
EADDRNOTAVAIL
ENOTCONN

(The brief grep shows that the second one might suit slightly better than the
 first one by existing use cases.)

Do we need to update the (chain of) kernel-doc?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 0/4] platform/x86: x86-android-tablets: use real firmware node references with intel drivers

[Andy Shevchenko]

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

Re: [PATCH v2 0/4] platform/x86: x86-android-tablets: use real firmware node references with intel drivers

[Bartosz Golaszewski]

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

Re: [PATCH v2 0/4] platform/x86: x86-android-tablets: use real firmware node references with intel drivers

[Andy Shevchenko]

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

Re: [PATCH v2 0/4] platform/x86: x86-android-tablets: use real firmware node references with intel drivers

[Bartosz Golaszewski]

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

Re: [PATCH v2 0/4] platform/x86: x86-android-tablets: use real firmware node references with intel drivers

[Andy Shevchenko]

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

Re: [PATCH v2 1/4] software node: return -ENXIO when referenced swnode is not registered yet

[Dmitry Torokhov]

On Thu, Apr 02, 2026 at 04:35:34PM +0300, Andy Shevchenko wrote:
> On Thu, Apr 02, 2026 at 02:54:26PM +0200, Bartosz Golaszewski wrote:
> > It's possible that at the time of resolving a reference to a remote
> > software node, the node we know exists is not yet registered as a full
> > firmware node. We currently return -ENOENT in this case but the same
> > error code is also returned in some other cases, like the reference
> > property with given name not existing in the property list of the local
> > software node.
> > 
> > It makes sense to let users know that we're dealing with an unregistered
> > software node so that they can defer probe - the situation is somewhat
> > similar to there existing a firmware node to which no device is bound
> > yet - which is valid grounds for probe deferral. To that end: use -ENXIO
> > which stands for "No such device or address".
> 
> This error code is also too generic to my taste. What about alternative(s)?
> EADDRNOTAVAIL
> ENOTCONN
> 
> (The brief grep shows that the second one might suit slightly better than the
>  first one by existing use cases.)

We are in the core of the driver core. Why not simply use -EPROBE_DEFER
to which all users will resolve this error to and call it a day?

Thanks.

-- 
Dmitry

Re: [PATCH v2 2/4] gpio: swnode: defer probe on references to unregistered software nodes

[Dmitry Torokhov]

On Thu, Apr 02, 2026 at 02:54:27PM +0200, Bartosz Golaszewski wrote:
> fwnode_property_get_reference_args() now returns -ENXIO when called on a
> software node referencing another software node which has not yet been
> registered as a firmware node. It makes sense to defer probe in this
> situation as the node will most likely be registered later on and we'll
> be able to resolve the reference eventually. Change the behavior of
> swnode_find_gpio() to return -EPROBE_DEFER if the software node reference
> resolution returns -ENXIO.
> 
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> ---
>  drivers/gpio/gpiolib-swnode.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/gpio/gpiolib-swnode.c b/drivers/gpio/gpiolib-swnode.c
> index 0d7f3f09a0b4bee0cf1bbdaa8b7b8ae4cd5de581..06d74e9e199de0b91a019e5e15d4b83d330291e7 100644
> --- a/drivers/gpio/gpiolib-swnode.c
> +++ b/drivers/gpio/gpiolib-swnode.c
> @@ -95,6 +95,15 @@ struct gpio_desc *swnode_find_gpio(struct fwnode_handle *fwnode,
>  			break;
>  	}
>  	if (ret) {
> +		if (ret == -ENXIO)


I'll be just sitting here and quoting sashiko all day long ;)

"
If swnode_gpio_get_reference() returns -ENXIO during the first iteration
(for example, when checking the con_id-gpios suffix), won't the loop continue
since the return value is not 0?

Looking at the loop just above this block:

        for_each_gpio_property_name(propname, con_id) {
                ret = swnode_gpio_get_reference(fwnode, propname, idx, &args);
                if (ret == 0)
                        break;
        }

If the initial property check returns -ENXIO, but the subsequent fallback
check for the con_id-gpio suffix returns -ENOENT, the ret variable gets
overwritten. 

When the loop terminates, ret would be -ENOENT instead of -ENXIO. Could this
cause the probe deferral check to evaluate to false and fail the probe
entirely instead of deferring it as intended? 

Should the loop also break early if -ENXIO is encountered?

"

You need to change that to

	if (ret == 0 || ret == -ENXIO)
		break;

because if we get -ENXIO that means the GPIO must be there (the property
exists) but not ready yet and we do not want to fall back to another
suffix. 

Thanks.

-- 
Dmitry

Re: [PATCH v2 2/4] gpio: swnode: defer probe on references to unregistered software nodes

[Bartosz Golaszewski]

On Thu, Apr 2, 2026 at 11:04 PM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> On Thu, Apr 02, 2026 at 02:54:27PM +0200, Bartosz Golaszewski wrote:
> > fwnode_property_get_reference_args() now returns -ENXIO when called on a
> > software node referencing another software node which has not yet been
> > registered as a firmware node. It makes sense to defer probe in this
> > situation as the node will most likely be registered later on and we'll
> > be able to resolve the reference eventually. Change the behavior of
> > swnode_find_gpio() to return -EPROBE_DEFER if the software node reference
> > resolution returns -ENXIO.
> >
> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> > ---
> >  drivers/gpio/gpiolib-swnode.c | 9 +++++++++
> >  1 file changed, 9 insertions(+)
> >
> > diff --git a/drivers/gpio/gpiolib-swnode.c b/drivers/gpio/gpiolib-swnode.c
> > index 0d7f3f09a0b4bee0cf1bbdaa8b7b8ae4cd5de581..06d74e9e199de0b91a019e5e15d4b83d330291e7 100644
> > --- a/drivers/gpio/gpiolib-swnode.c
> > +++ b/drivers/gpio/gpiolib-swnode.c
> > @@ -95,6 +95,15 @@ struct gpio_desc *swnode_find_gpio(struct fwnode_handle *fwnode,
> >                       break;
> >       }
> >       if (ret) {
> > +             if (ret == -ENXIO)
>
>
> I'll be just sitting here and quoting sashiko all day long ;)
>

I would love it to produce briefer messages. I'm always put off by the
walls of text. I would literally rather deal with neanderthal mode
like: "loop continues on ret != 0, bad!".

> "
> If swnode_gpio_get_reference() returns -ENXIO during the first iteration
> (for example, when checking the con_id-gpios suffix), won't the loop continue
> since the return value is not 0?
>
> Looking at the loop just above this block:
>
>         for_each_gpio_property_name(propname, con_id) {
>                 ret = swnode_gpio_get_reference(fwnode, propname, idx, &args);
>                 if (ret == 0)
>                         break;
>         }
>
> If the initial property check returns -ENXIO, but the subsequent fallback
> check for the con_id-gpio suffix returns -ENOENT, the ret variable gets
> overwritten.
>
> When the loop terminates, ret would be -ENOENT instead of -ENXIO. Could this
> cause the probe deferral check to evaluate to false and fail the probe
> entirely instead of deferring it as intended?
>
> Should the loop also break early if -ENXIO is encountered?
>
> "
>
> You need to change that to
>
>         if (ret == 0 || ret == -ENXIO)
>                 break;
>
> because if we get -ENXIO that means the GPIO must be there (the property
> exists) but not ready yet and we do not want to fall back to another
> suffix.
>

Yes, thanks.

Bart

Re: [PATCH v2 1/4] software node: return -ENXIO when referenced swnode is not registered yet

[Bartosz Golaszewski]

On Thu, Apr 2, 2026 at 10:43 PM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> On Thu, Apr 02, 2026 at 04:35:34PM +0300, Andy Shevchenko wrote:
> > On Thu, Apr 02, 2026 at 02:54:26PM +0200, Bartosz Golaszewski wrote:
> > > It's possible that at the time of resolving a reference to a remote
> > > software node, the node we know exists is not yet registered as a full
> > > firmware node. We currently return -ENOENT in this case but the same
> > > error code is also returned in some other cases, like the reference
> > > property with given name not existing in the property list of the local
> > > software node.
> > >
> > > It makes sense to let users know that we're dealing with an unregistered
> > > software node so that they can defer probe - the situation is somewhat
> > > similar to there existing a firmware node to which no device is bound
> > > yet - which is valid grounds for probe deferral. To that end: use -ENXIO
> > > which stands for "No such device or address".
> >
> > This error code is also too generic to my taste. What about alternative(s)?
> > EADDRNOTAVAIL
> > ENOTCONN
> >
> > (The brief grep shows that the second one might suit slightly better than the
> >  first one by existing use cases.)
>
> We are in the core of the driver core. Why not simply use -EPROBE_DEFER
> to which all users will resolve this error to and call it a day?
>

Because -EPROBE_DEFER only makes sense in probe() context, while
fwnode_get_reference_args() may be called in many other situations. I
think ENOTCONN as "not connected" makes sense, though the string
representation says: "Transport endpoint is not connected" which
doesn't spell out quite the same thing.

Bart

Re: [PATCH v2 2/4] gpio: swnode: defer probe on references to unregistered software nodes

[Bartosz Golaszewski]

On Thu, Apr 2, 2026 at 11:04 PM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> You need to change that to
>
>         if (ret == 0 || ret == -ENXIO)
>                 break;
>
> because if we get -ENXIO that means the GPIO must be there (the property
> exists) but not ready yet and we do not want to fall back to another
> suffix.
>

I'm wondering if we should make this check even stricter and only
continue on -ENOENT - which means: there is no such property - and
bail out on other errors.

But that would be a separate change.

Bart

Re: [PATCH v2 1/4] software node: return -ENXIO when referenced swnode is not registered yet

[Dmitry Torokhov]

On Fri, Apr 03, 2026 at 09:29:38AM +0200, Bartosz Golaszewski wrote:
> On Thu, Apr 2, 2026 at 10:43 PM Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> >
> > On Thu, Apr 02, 2026 at 04:35:34PM +0300, Andy Shevchenko wrote:
> > > On Thu, Apr 02, 2026 at 02:54:26PM +0200, Bartosz Golaszewski wrote:
> > > > It's possible that at the time of resolving a reference to a remote
> > > > software node, the node we know exists is not yet registered as a full
> > > > firmware node. We currently return -ENOENT in this case but the same
> > > > error code is also returned in some other cases, like the reference
> > > > property with given name not existing in the property list of the local
> > > > software node.
> > > >
> > > > It makes sense to let users know that we're dealing with an unregistered
> > > > software node so that they can defer probe - the situation is somewhat
> > > > similar to there existing a firmware node to which no device is bound
> > > > yet - which is valid grounds for probe deferral. To that end: use -ENXIO
> > > > which stands for "No such device or address".
> > >
> > > This error code is also too generic to my taste. What about alternative(s)?
> > > EADDRNOTAVAIL
> > > ENOTCONN
> > >
> > > (The brief grep shows that the second one might suit slightly better than the
> > >  first one by existing use cases.)
> >
> > We are in the core of the driver core. Why not simply use -EPROBE_DEFER
> > to which all users will resolve this error to and call it a day?
> >
> 
> Because -EPROBE_DEFER only makes sense in probe() context, while
> fwnode_get_reference_args() may be called in many other situations.

Exactly same argument applies to your follow-up change: gpiod_get()
returning -EPROBE_DEFER only makes sense in probe context but it may be
called in many other situations. Are you planning to change all places
where gpiolib returns -EPROBE_DEFER to something else just in case it
might be called outside of probe context? 

-EPROBE_DEFER should have been called -ENOTREADY from the beginning and
then we would not have this argument. Or, even better, we should have
used -EAGAIN. But it is just a name, semantics does not really change.
We want to signal that something is not ready and the operation needs be
repeated. Currently we contorting ourselves by using yet another error
code that everyone will either convert to -EPORBE_DEFER or will handle
like -EAGAIN.

> I think ENOTCONN as "not connected" makes sense, though the string

Why is it better? Most of users of -ENOTCONN are in networking code so
it is somewhat unexpected to have other APIs return it. 

> representation says: "Transport endpoint is not connected" which
> doesn't spell out quite the same thing.

Yes, because it is really for networking/sockets handling.

Thanks.

-- 
Dmitryp

Re: [PATCH v2 4/4] platform/x86: x86-android-tablets: enable fwnode matching of GPIO chips

[Rafael J. Wysocki]

On Thu, Apr 2, 2026 at 2:54 PM Bartosz Golaszewski
<bartosz.golaszewski@oss.qualcomm.com> wrote:
>
> In order to allow GPIOLIB to match cherryview and baytrail GPIO
> controllers by their firmware nodes instead of their names, we need to
> attach the - currently "dangling" - existing software nodes to their
> target devices dynamically.
>
> We deal with devices described in ACPI so set up a bus notifier waiting
> for the ADD events. We know the name of the device we're waiting for so
> match against it and - on match - assign the appropriate software node
> as the secondary firmware node of the underlying ACPI node. In case the
> event was emitted earlier than this driver's probe: also make sure the
> device was not added before.
>
> Scheduling fine-grained devres actions allows for proper teardown and
> unsetting of the secondary firmware nodes.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> ---
>  drivers/platform/x86/x86-android-tablets/core.c | 127 +++++++++++++++++++++++-
>  1 file changed, 124 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/platform/x86/x86-android-tablets/core.c b/drivers/platform/x86/x86-android-tablets/core.c
> index 021009e9085bec3db9c4daa1f6235600210a6099..9e6e8f272dfe16cda421b569802045c3d94fc0ab 100644
> --- a/drivers/platform/x86/x86-android-tablets/core.c
> +++ b/drivers/platform/x86/x86-android-tablets/core.c
> @@ -13,10 +13,12 @@
>  #include <linux/acpi.h>
>  #include <linux/device.h>
>  #include <linux/dmi.h>
> +#include <linux/fwnode.h>
>  #include <linux/gpio/consumer.h>
>  #include <linux/gpio/machine.h>
>  #include <linux/irq.h>
>  #include <linux/module.h>
> +#include <linux/notifier.h>
>  #include <linux/pci.h>
>  #include <linux/platform_device.h>
>  #include <linux/serdev.h>
> @@ -360,6 +362,124 @@ static const struct software_node *cherryview_gpiochip_node_group[] = {
>         NULL
>  };
>
> +struct auto_secondary_data {
> +       struct notifier_block nb;
> +       struct device *parent;
> +};
> +
> +static void auto_secondary_unset(void *data)
> +{
> +       struct fwnode_handle *fwnode = data;
> +
> +       fwnode->secondary = NULL;
> +}
> +
> +static int acpi_set_secondary_fwnode(struct device *parent, struct device *dev,
> +                                    const struct software_node *const swnode)
> +{
> +       struct acpi_device *device = to_acpi_device(dev);
> +       struct fwnode_handle *fwnode;
> +       int ret;
> +
> +       fwnode = software_node_fwnode(swnode);
> +       if (WARN_ON(!fwnode))
> +               return -ENOENT;
> +
> +       fwnode->secondary = ERR_PTR(-ENODEV);
> +       device->fwnode.secondary = fwnode;
> +
> +       ret = devm_add_action_or_reset(parent, auto_secondary_unset, &device->fwnode);
> +       if (ret)
> +               dev_err(parent, "Failed to schedule the unset action for secondary fwnode\n");
> +
> +       return ret;
> +}
> +
> +static int acpi_auto_secondary_notifier(struct notifier_block *nb,
> +                                       unsigned long action, void *data)
> +{
> +       struct auto_secondary_data *auto_sec = container_of(nb, struct auto_secondary_data, nb);
> +       const struct software_node *const *swnode;
> +       struct device *dev = data;
> +       int ret;
> +
> +       switch (action) {
> +       case BUS_NOTIFY_ADD_DEVICE:
> +               for (swnode = gpiochip_node_group; *swnode; swnode++) {
> +                       if (strcmp((*swnode)->name, dev_name(dev)) == 0) {
> +                               ret = acpi_set_secondary_fwnode(auto_sec->parent, dev, *swnode);
> +                               return ret ? NOTIFY_BAD : NOTIFY_OK;
> +                       }
> +               }
> +               break;
> +       default:
> +               break;
> +       }
> +
> +       return NOTIFY_DONE;
> +}
> +
> +static void auto_secondary_unregister_node_group(void *data)
> +{
> +       const struct software_node **nodes = data;
> +
> +       software_node_unregister_node_group(nodes);
> +}
> +
> +static void auto_secondary_unregister_notifier(void *data)
> +{
> +       struct notifier_block *nb = data;
> +
> +       bus_unregister_notifier(&acpi_bus_type, nb);
> +}

Instead of exporting acpi_bus_type in the previous patch and defining
this function here, can you define

void acpi_bus_unregister_notifier(void *data)
{
       struct notifier_block *nb = data;

       bus_unregister_notifier(&acpi_bus_type, nb);
}

in the previous patch and use it here?

> +
> +static int auto_secondary_fwnode_init(struct device *parent)
> +{
> +       const struct software_node *const *swnode;
> +       struct auto_secondary_data *data;
> +       int ret;
> +
> +       ret = software_node_register_node_group(gpiochip_node_group);
> +       if (ret)
> +               return ret;
> +
> +       ret = devm_add_action_or_reset(parent,
> +                                      auto_secondary_unregister_node_group,
> +                                      gpiochip_node_group);
> +       if (ret)
> +               return ret;
> +
> +       data = devm_kzalloc(parent, sizeof(*data), GFP_KERNEL);
> +       if (!data)
> +               return -ENOMEM;
> +
> +       data->nb.notifier_call = acpi_auto_secondary_notifier;
> +       data->parent = parent;
> +
> +       ret = bus_register_notifier(&acpi_bus_type, &data->nb);
> +       if (ret)
> +               return ret;
> +
> +       ret = devm_add_action_or_reset(parent,
> +                                      auto_secondary_unregister_notifier,
> +                                      &data->nb);
> +       if (ret)
> +               return ret;
> +
> +       /* Device may have been already added. */
> +       for (swnode = gpiochip_node_group; *swnode; swnode++) {
> +               struct device *dev __free(put_device) =
> +                       bus_find_device_by_name(&acpi_bus_type, NULL, (*swnode)->name);
> +               if (dev) {
> +                       ret = acpi_set_secondary_fwnode(parent, dev, *swnode);
> +                       if (ret)
> +                               return ret;
> +               }
> +       }
> +
> +       return 0;
> +}
> +
>  static void x86_android_tablet_remove(struct platform_device *pdev)
>  {
>         int i;
> @@ -391,7 +511,6 @@ static void x86_android_tablet_remove(struct platform_device *pdev)
>
>         software_node_unregister_node_group(gpio_button_swnodes);
>         software_node_unregister_node_group(swnode_group);
> -       software_node_unregister_node_group(gpiochip_node_group);
>  }
>
>  static __init int x86_android_tablet_probe(struct platform_device *pdev)
> @@ -427,9 +546,11 @@ static __init int x86_android_tablet_probe(struct platform_device *pdev)
>                 break;
>         }
>
> -       ret = software_node_register_node_group(gpiochip_node_group);
> -       if (ret)
> +       ret = auto_secondary_fwnode_init(&pdev->dev);
> +       if (ret) {
> +               x86_android_tablet_remove(pdev);
>                 return ret;
> +       }
>
>         ret = software_node_register_node_group(dev_info->swnode_group);
>         if (ret) {
>
> --
> 2.47.3
>