x86-android-tablets: convert to use GPIO references + Acer A1-840 support

From: Dmitry Torokhov <[email protected]>

Now that gpiolib supports software nodes to describe GPIOs, switch the driver away from using GPIO lookup tables for Goodix touchscreens to using PROPERTY_ENTRY_GPIO() to keep all touchscreen properties together.

Since the tablets are using either Baytrail or Cherryview GPIO controllers x86_dev_info structure has been extended to carry gpiochip type information so that the code can instantiate correct set of software nodes representing the GPIO chip.

Quoted 8 lines · Hans de Goede

Now that gpiolib supports software nodes to describe GPIOs, switch the driver away from using GPIO lookup tables for Goodix touchscreens to using PROPERTY_ENTRY_GPIO() to keep all touchscreen properties together.

Since the tablets are using either Baytrail or Cherryview GPIO controllers x86_dev_info structure has been extended to carry gpiochip type information so that the code can instantiate correct set of software nodes representing the GPIO chip.

Hi, it seems that the mechanism for looking up GPIOs using software
node names is broken now (checked on next-20260503) by commit e5d527be7e6984882306b49c067f1fec18920735 "gpio: swnode: don't use the swnode's name as the key for GPIO lookup".

As I understand, some of the issues caused by it were addressed in the series [1], but not for the x86-android-tablets driver. Now any GPIO belonging to SoC's gpiochips cannot be found by drivers. For example, for the Lenovo YB1-X90F keyboard touchpad:

[   27.297279] i2c i2c-goodix_ts: bus: 'i2c': __driver_probe_device: matched device with driver Goodix-TS
[   27.297285] i2c i2c-goodix_ts: bus: 'i2c': really_probe: probing driver Goodix-TS with device
[   27.297291] Goodix-TS i2c-goodix_ts: no default pinctrl state
[   27.297330] Goodix-TS i2c-goodix_ts: supply AVDD28 not found, using dummy regulator
[   27.297359] device: 'regulator:regulator.0--i2c:i2c-goodix_ts': device_add
[   27.297454] devices_kset: Moving i2c-goodix_ts to end of list
[   27.297459] PM: Moving i2c:i2c-goodix_ts to end of list
[   27.297463] Goodix-TS i2c-goodix_ts: Linked as a consumer to regulator.0
[   27.297472] Goodix-TS i2c-goodix_ts: supply VDDIO not found, using dummy regulator
[   27.297492] Goodix-TS i2c-goodix_ts: using swnode 'node11' for 'irq' GPIO lookup
[   27.297505] Goodix-TS i2c-goodix_ts: No GPIO consumer irq found
[   27.297511] Goodix-TS i2c-goodix_ts: error -EPROBE_DEFER: Failed to get irq GPIO
[   27.297552] Goodix-TS i2c-goodix_ts: Dropping the link to regulator.0
[   27.297558] device: 'regulator:regulator.0--i2c:i2c-goodix_ts': device_unregister
[   27.297612] Goodix-TS i2c-goodix_ts: Driver Goodix-TS requests probe deferral
[   27.297624] i2c i2c-goodix_ts: Added to deferred list

Could somebody advise on how to fix this, or does a fix already exist? I am not familiar with the swnode/fwnode framework but can do some investigation to resolve this.

1. https://lore.kernel.org/linux-sound/[email protected]/

+Cc: Bart.

Quoted 41 lines · Yauhen Kharuzhy

Quoted 8 lines · Hans de Goede

Now that gpiolib supports software nodes to describe GPIOs, switch the driver away from using GPIO lookup tables for Goodix touchscreens to using PROPERTY_ENTRY_GPIO() to keep all touchscreen properties together.

Since the tablets are using either Baytrail or Cherryview GPIO controllers x86_dev_info structure has been extended to carry gpiochip type information so that the code can instantiate correct set of software nodes representing the GPIO chip.

Hi, it seems that the mechanism for looking up GPIOs using software
node names is broken now (checked on next-20260503) by commit e5d527be7e6984882306b49c067f1fec18920735 "gpio: swnode: don't use the swnode's name as the key for GPIO lookup".

As I understand, some of the issues caused by it were addressed in the series [1], but not for the x86-android-tablets driver. Now any GPIO belonging to SoC's gpiochips cannot be found by drivers. For example, for the Lenovo YB1-X90F keyboard touchpad:

[   27.297279] i2c i2c-goodix_ts: bus: 'i2c': __driver_probe_device: matched device with driver Goodix-TS
[   27.297285] i2c i2c-goodix_ts: bus: 'i2c': really_probe: probing driver Goodix-TS with device
[   27.297291] Goodix-TS i2c-goodix_ts: no default pinctrl state
[   27.297330] Goodix-TS i2c-goodix_ts: supply AVDD28 not found, using dummy regulator
[   27.297359] device: 'regulator:regulator.0--i2c:i2c-goodix_ts': device_add
[   27.297454] devices_kset: Moving i2c-goodix_ts to end of list
[   27.297459] PM: Moving i2c:i2c-goodix_ts to end of list
[   27.297463] Goodix-TS i2c-goodix_ts: Linked as a consumer to regulator.0
[   27.297472] Goodix-TS i2c-goodix_ts: supply VDDIO not found, using dummy regulator
[   27.297492] Goodix-TS i2c-goodix_ts: using swnode 'node11' for 'irq' GPIO lookup
[   27.297505] Goodix-TS i2c-goodix_ts: No GPIO consumer irq found
[   27.297511] Goodix-TS i2c-goodix_ts: error -EPROBE_DEFER: Failed to get irq GPIO
[   27.297552] Goodix-TS i2c-goodix_ts: Dropping the link to regulator.0
[   27.297558] device: 'regulator:regulator.0--i2c:i2c-goodix_ts': device_unregister
[   27.297612] Goodix-TS i2c-goodix_ts: Driver Goodix-TS requests probe deferral
[   27.297624] i2c i2c-goodix_ts: Added to deferred list

Could somebody advise on how to fix this, or does a fix already exist? I am not familiar with the swnode/fwnode framework but can do some investigation to resolve this.

Quoted 44 lines · Andy Shevchenko

+Cc: Bart.

Quoted 41 lines · Yauhen Kharuzhy

Quoted 8 lines · Hans de Goede

Now that gpiolib supports software nodes to describe GPIOs, switch the driver away from using GPIO lookup tables for Goodix touchscreens to using PROPERTY_ENTRY_GPIO() to keep all touchscreen properties together.

Since the tablets are using either Baytrail or Cherryview GPIO controllers x86_dev_info structure has been extended to carry gpiochip type information so that the code can instantiate correct set of software nodes representing the GPIO chip.

Hi, it seems that the mechanism for looking up GPIOs using software
node names is broken now (checked on next-20260503) by commit e5d527be7e6984882306b49c067f1fec18920735 "gpio: swnode: don't use the swnode's name as the key for GPIO lookup".

As I understand, some of the issues caused by it were addressed in the series [1], but not for the x86-android-tablets driver. Now any GPIO belonging to SoC's gpiochips cannot be found by drivers. For example, for the Lenovo YB1-X90F keyboard touchpad:

[   27.297279] i2c i2c-goodix_ts: bus: 'i2c': __driver_probe_device: matched device with driver Goodix-TS
[   27.297285] i2c i2c-goodix_ts: bus: 'i2c': really_probe: probing driver Goodix-TS with device
[   27.297291] Goodix-TS i2c-goodix_ts: no default pinctrl state
[   27.297330] Goodix-TS i2c-goodix_ts: supply AVDD28 not found, using dummy regulator
[   27.297359] device: 'regulator:regulator.0--i2c:i2c-goodix_ts': device_add
[   27.297454] devices_kset: Moving i2c-goodix_ts to end of list
[   27.297459] PM: Moving i2c:i2c-goodix_ts to end of list
[   27.297463] Goodix-TS i2c-goodix_ts: Linked as a consumer to regulator.0
[   27.297472] Goodix-TS i2c-goodix_ts: supply VDDIO not found, using dummy regulator
[   27.297492] Goodix-TS i2c-goodix_ts: using swnode 'node11' for 'irq' GPIO lookup
[   27.297505] Goodix-TS i2c-goodix_ts: No GPIO consumer irq found
[   27.297511] Goodix-TS i2c-goodix_ts: error -EPROBE_DEFER: Failed to get irq GPIO
[   27.297552] Goodix-TS i2c-goodix_ts: Dropping the link to regulator.0
[   27.297558] device: 'regulator:regulator.0--i2c:i2c-goodix_ts': device_unregister
[   27.297612] Goodix-TS i2c-goodix_ts: Driver Goodix-TS requests probe deferral
[   27.297624] i2c i2c-goodix_ts: Added to deferred list

Could somebody advise on how to fix this, or does a fix already exist? I am not familiar with the swnode/fwnode framework but can do some investigation to resolve this.

I really don't want to revert to the label lookup and string comparison as this is totally broken so let me help you.

The fix should be relatively easy - we need the address of the software node associated with the GPIO chip we want to get the pin from, and we can reference it using the PROPERTY_ENTRY_GPIO() macro in the software node of the consumer.

Can you point me to the place in code where this fails? Is this drivers/platform/x86/lenovo/yogabook.c? This is the only place where "i2c-goodix_ts" if even referenced upstream. If you could enable CONFIG_DEBUG_GPIO and post the kernel log somewhere, it would help me too.

For the drivers/platform/x86/x86-android-tablets/* I think the following fix is both the easiest as well as the best solution is to modify:

drivers/pinctrl/intel/pinctrl-baytrail.c
drivers/pinctrl/intel/pinctrl-cherryview.c

To register a swnode for each GPIO controller and then EXPORT_SYMBOL_GPL an array of fwnode pointers which can then be used in the PROPERTY_ENTRY_GPIO() entries replacing e.g.:

PROPERTY_ENTRY_GPIO("reset-gpios", &cherryview_gpiochip_nodes[1], 53, GPIO_ACTIVE_HIGH)

with:

PROPERTY_ENTRY_GPIO("reset-gpios", cherryview_gpiochip_fwnodes[1], 53, GPIO_ACTIVE_HIGH)

(these 2 covers pinctrl for the Bay Trail and Cherry Trail x86 SoC based Android tablets which x86-android-tablets is for).

This should all be pretty straight forward. Assuming we are allowed to dereference an external symbol for the property initialization if not then this becomes significantly more complex.

On 9-Feb-26 15:00, Hans de Goede wrote:

...

Quoted 15 lines

For the drivers/platform/x86/x86-android-tablets/* I think the following fix is both the easiest as well as the best solution is to modify:

drivers/pinctrl/intel/pinctrl-baytrail.c
drivers/pinctrl/intel/pinctrl-cherryview.c

To register a swnode for each GPIO controller and then EXPORT_SYMBOL_GPL an array of fwnode pointers which can then be used in the PROPERTY_ENTRY_GPIO() entries replacing e.g.:

PROPERTY_ENTRY_GPIO("reset-gpios", &cherryview_gpiochip_nodes[1], 53, GPIO_ACTIVE_HIGH)

with:

Quoted 8 lines

PROPERTY_ENTRY_GPIO("reset-gpios", cherryview_gpiochip_fwnodes[1], 53, GPIO_ACTIVE_HIGH)

(these 2 covers pinctrl for the Bay Trail and Cherry Trail x86 SoC based Android tablets which x86-android-tablets is for).

This should all be pretty straight forward. Assuming we are allowed to dereference an external symbol for the property initialization if not then this becomes significantly more complex.

Looking at how the current code works, it does not use an array of swnode pointers, it just uses an array of swnodes, and then takes the address of the n-th member:

PROPERTY_ENTRY_GPIO("reset-gpios", &cherryview_gpiochip_nodes[1], 53, GPIO_ACTIVE_HIGH)

so if we just move the:

extern const struct software_node baytrail_gpiochip_nodes[]; extern const struct software_node cherryview_gpiochip_nodes[];

arrays to the 2 pinctrl drivers and actually associate them with / attach them to the GPIO controllers in the pinctrl drivers then I think that we will be set for all the references to the main SoC GPIO controllers (at the cost of a dependency on the pinctrl driver, but that is ok).

OK, but what about additional GPIO chips?

For example, on Lenovo YB1-X9*,
sound codec controls additional signals like speaker amplifier enablling. I did such trick but it looks very... weird: codec device properties reference fake node for gpiochip which will be created at driver instantiation (these properties are used by ASoC machine driver actually):

static const struct property_entry lenovo_yb1_x9x_rt5677_props[] = {
...
PROPERTY_ENTRY_GPIO("realtek,reset-gpios", &cherryview_gpiochip_nodes[3], 25, GPIO_ACTIVE_LOW), PROPERTY_ENTRY_GPIO("realtek,pow-ldo2-gpios", &cherryview_gpiochip_nodes[3], 18, GPIO_ACTIVE_HIGH), PROPERTY_ENTRY_GPIO("speaker-enable-gpios", &cherryview_gpiochip_nodes[3], 48, GPIO_ACTIVE_HIGH), PROPERTY_ENTRY_GPIO("speaker-enable2-gpios", &lenovo_yb1_rt5677_gpiochip_node, 2, GPIO_ACTIVE_HIGH), PROPERTY_ENTRY_GPIO("headphone-enable-gpios", &lenovo_yb1_rt5677_gpiochip_node, 4, GPIO_ACTIVE_HIGH), {}
};

static const struct software_node lenovo_yb1_x90_rt5677_node = {
	.properties = lenovo_yb1_x9x_rt5677_props,
};

...

		.board_info = {
			.type = "rt5677",
			.addr = 0x2c,
			.dev_name = "rt5677",
			.swnode = &lenovo_yb1_x90_rt5677_node,
		},

...

https://github.com/jekhor/yogabook-linux-kernel/commit/538313b69483c23afc455571ef638efcea767031#diff-282276fa1330b08656b929c6e956308a122423888b8f07a1d1045e61a813d8c2R159

Hi Yauhen,

Quoted 1 line

https://github.com/jekhor/yogabook-linux-kernel/commit/538313b69483c23afc455571ef638efcea767031#diff-282276fa1330b08656b929c6e956308a122423888b8f07a1d1045e61a813d8c2R159

Oh nice you've patches for sound now :)

Is this working ? Any plans to upstream this ?

Hi Bartosz,

Quoted 50 lines · Bartosz Golaszewski

Quoted 44 lines · Andy Shevchenko

+Cc: Bart.

Quoted 41 lines · Yauhen Kharuzhy

Quoted 8 lines · Hans de Goede

Now that gpiolib supports software nodes to describe GPIOs, switch the driver away from using GPIO lookup tables for Goodix touchscreens to using PROPERTY_ENTRY_GPIO() to keep all touchscreen properties together.

Since the tablets are using either Baytrail or Cherryview GPIO controllers x86_dev_info structure has been extended to carry gpiochip type information so that the code can instantiate correct set of software nodes representing the GPIO chip.

Hi, it seems that the mechanism for looking up GPIOs using software
node names is broken now (checked on next-20260503) by commit e5d527be7e6984882306b49c067f1fec18920735 "gpio: swnode: don't use the swnode's name as the key for GPIO lookup".

As I understand, some of the issues caused by it were addressed in the series [1], but not for the x86-android-tablets driver. Now any GPIO belonging to SoC's gpiochips cannot be found by drivers. For example, for the Lenovo YB1-X90F keyboard touchpad:

[   27.297279] i2c i2c-goodix_ts: bus: 'i2c': __driver_probe_device: matched device with driver Goodix-TS
[   27.297285] i2c i2c-goodix_ts: bus: 'i2c': really_probe: probing driver Goodix-TS with device
[   27.297291] Goodix-TS i2c-goodix_ts: no default pinctrl state
[   27.297330] Goodix-TS i2c-goodix_ts: supply AVDD28 not found, using dummy regulator
[   27.297359] device: 'regulator:regulator.0--i2c:i2c-goodix_ts': device_add
[   27.297454] devices_kset: Moving i2c-goodix_ts to end of list
[   27.297459] PM: Moving i2c:i2c-goodix_ts to end of list
[   27.297463] Goodix-TS i2c-goodix_ts: Linked as a consumer to regulator.0
[   27.297472] Goodix-TS i2c-goodix_ts: supply VDDIO not found, using dummy regulator
[   27.297492] Goodix-TS i2c-goodix_ts: using swnode 'node11' for 'irq' GPIO lookup
[   27.297505] Goodix-TS i2c-goodix_ts: No GPIO consumer irq found
[   27.297511] Goodix-TS i2c-goodix_ts: error -EPROBE_DEFER: Failed to get irq GPIO
[   27.297552] Goodix-TS i2c-goodix_ts: Dropping the link to regulator.0
[   27.297558] device: 'regulator:regulator.0--i2c:i2c-goodix_ts': device_unregister
[   27.297612] Goodix-TS i2c-goodix_ts: Driver Goodix-TS requests probe deferral
[   27.297624] i2c i2c-goodix_ts: Added to deferred list

Could somebody advise on how to fix this, or does a fix already exist? I am not familiar with the swnode/fwnode framework but can do some investigation to resolve this.

I really don't want to revert to the label lookup and string comparison as this is totally broken so let me help you.

Quoted 8 lines

The fix should be relatively easy - we need the address of the software node associated with the GPIO chip we want to get the pin from, and we can reference it using the PROPERTY_ENTRY_GPIO() macro in the software node of the consumer.

Can you point me to the place in code where this fails? Is this drivers/platform/x86/lenovo/yogabook.c? This is the only place where "i2c-goodix_ts" if even referenced upstream. If you could enable CONFIG_DEBUG_GPIO and post the kernel log somewhere, it would help me too.

First of all thank you for your offer to help. I actually pointed out that the whole name matching instead of using a fwnode reference was weird when a bunch of platform-driver-x86 drivers where first converted from using GPIO lookup tables to using swnodes:

https://lore.kernel.org/platform-driver-x86/[email protected]/

Dmitry convinced me back then that this is how GPIO controller swnode matching was supposed to work and now we are here...

By far the biggest user of the name based matching is the drivers/platform/x86/x86-android-tablets code which was moved to this recent(ish) by this series:

https://lore.kernel.org/platform-driver-x86/[email protected]/

But there are some other pdx86 files too:

hans@shalem:~/projects/linux$ ack -l PROPERTY_ENTRY_GPIO drivers/platform/x86/
drivers/platform/x86/x86-android-tablets/lenovo.c
drivers/platform/x86/x86-android-tablets/acer.c
drivers/platform/x86/x86-android-tablets/other.c
drivers/platform/x86/x86-android-tablets/shared-psy-info.c
drivers/platform/x86/x86-android-tablets/asus.c
drivers/platform/x86/barco-p50-gpio.c
drivers/platform/x86/meraki-mx100.c
drivers/platform/x86/pcengines-apuv2.c

For the drivers/platform/x86/x86-android-tablets/* I think the following fix is both the easiest as well as the best solution is to modify:

drivers/pinctrl/intel/pinctrl-baytrail.c
drivers/pinctrl/intel/pinctrl-cherryview.c

To register a swnode for each GPIO controller and then EXPORT_SYMBOL_GPL an array of fwnode pointers which can then be used in the PROPERTY_ENTRY_GPIO() entries replacing e.g.:

PROPERTY_ENTRY_GPIO("reset-gpios", &cherryview_gpiochip_nodes[1], 53, GPIO_ACTIVE_HIGH)

with:

PROPERTY_ENTRY_GPIO("reset-gpios", cherryview_gpiochip_fwnodes[1], 53, GPIO_ACTIVE_HIGH)

(these 2 covers pinctrl for the Bay Trail and Cherry Trail x86 SoC based Android tablets which x86-android-tablets is for).

This should all be pretty straight forward. Assuming we are allowed to dereference an external symbol for the property initialization if not then this becomes significantly more complex.

I'm not even sure if we need to add swnodes, we can probably just use the existing ACPI fwnodes for matching even and then we just need an array with the ACPI fwnode pointers.

###

Unfortunately this only covers most of the PROPERTY_ENTRY_GPIO() swnode props under drivers/platform/x86/x86-android-tablets.

These are still a problem after fixing all the ones referencing baytrail / cherryview SoC GPIO controllers:

static const struct property_entry lenovo_yoga_tab2_830_1050_wm1502_props[] = {
PROPERTY_ENTRY_GPIO("reset-gpios",
&crystalcove_gpiochip_node, 3, GPIO_ACTIVE_HIGH),
PROPERTY_ENTRY_GPIO("wlf,ldoena-gpios",
&baytrail_gpiochip_nodes[1], 23, GPIO_ACTIVE_HIGH),
PROPERTY_ENTRY_GPIO("wlf,spkvdd-ena-gpios",
&arizona_gpiochip_node, 2, GPIO_ACTIVE_HIGH),
PROPERTY_ENTRY_GPIO("wlf,micd-pol-gpios",
&arizona_gpiochip_node, 4, GPIO_ACTIVE_LOW),
{ }
};

This one gets added to a device dynamically, so we could lookup the GPIO controller, attach a swnode and then dynamically generate the above properties before attaching them.

This one:

static const struct property_entry lenovo_yt3_wm1502_props[] = {
        PROPERTY_ENTRY_GPIO("wlf,spkvdd-ena-gpios",
                            &cherryview_gpiochip_nodes[0], 75, GPIO_ACTIVE_HIGH),
        PROPERTY_ENTRY_GPIO("wlf,ldoena-gpios",
                            &cherryview_gpiochip_nodes[0], 81, GPIO_ACTIVE_HIGH),
        PROPERTY_ENTRY_GPIO("reset-gpios", &cherryview_gpiochip_nodes[0], 82, GPIO_ACTIVE_HIGH
        PROPERTY_ENTRY_GPIO("wlf,micd-pol-gpios", &arizona_gpiochip_node, 2, GPIO_ACTIVE_HIGH)
        { }
};

is more complex though, since this is used for a SPI boardinfo swmode, so generating this dynamically is going to involve some more rework.

I think it might be best to just at least partially revert:

https://lore.kernel.org/platform-driver-x86/[email protected]/

the main goal there was to stop using the deprecated desc_to_gpio() function which was being used for gpio-button platform-data.

We could revert:

[PATCH v4 10/20] platform/x86: x86-android-tablets: remove support for GPIO lookup tables [PATCH v4 07/20] platform/x86: x86-android-tablets: convert wm1502

To solve the problematic WM5102 codec lookups for non main Soc GPIOs, assuming we can fix the main SoC GPIO fwnode properties.

###

Note this just solves all the cases under drivers/platform/x86/x86-android-tablets/ and I'm happy to help testing fixes. This still leaves:

drivers/platform/x86/barco-p50-gpio.c
drivers/platform/x86/meraki-mx100.c
drivers/platform/x86/pcengines-apuv2.c

unresolved. I'm less familiar with these and I cannot test fixes for these.

Quoted 21 lines · Hans de Goede

For the drivers/platform/x86/x86-android-tablets/* I think the following fix is both the easiest as well as the best solution is to modify:

drivers/pinctrl/intel/pinctrl-baytrail.c
drivers/pinctrl/intel/pinctrl-cherryview.c

To register a swnode for each GPIO controller and then EXPORT_SYMBOL_GPL an array of fwnode pointers which can then be used in the PROPERTY_ENTRY_GPIO() entries replacing e.g.:

PROPERTY_ENTRY_GPIO("reset-gpios", &cherryview_gpiochip_nodes[1], 53, GPIO_ACTIVE_HIGH)

with:

PROPERTY_ENTRY_GPIO("reset-gpios", cherryview_gpiochip_fwnodes[1], 53, GPIO_ACTIVE_HIGH)

(these 2 covers pinctrl for the Bay Trail and Cherry Trail x86 SoC based Android tablets which x86-android-tablets is for).

Quoted 8 lines

This should all be pretty straight forward. Assuming we are allowed to dereference an external symbol for the property initialization if not then this becomes significantly more complex.

I'm not even sure if we need to add swnodes, we can probably just use the existing ACPI fwnodes for matching even and then we just need an array with the ACPI fwnode pointers.

Yes, we can now reference fwnodes from property entries. The entity that creates these devices should be able to retrieve the firmware nodes of the GPIO controllers (e.g.: via gpio_device_find_by_label() - finding it by labek is what it effectively tried to do now).

Quoted 31 lines · Bartosz Golaszewski

Quoted 29 lines · Hans de Goede

For the drivers/platform/x86/x86-android-tablets/* I think the following fix is both the easiest as well as the best solution is to modify:

drivers/pinctrl/intel/pinctrl-baytrail.c
drivers/pinctrl/intel/pinctrl-cherryview.c

To register a swnode for each GPIO controller and then EXPORT_SYMBOL_GPL an array of fwnode pointers which can then be used in the PROPERTY_ENTRY_GPIO() entries replacing e.g.:

PROPERTY_ENTRY_GPIO("reset-gpios", &cherryview_gpiochip_nodes[1], 53, GPIO_ACTIVE_HIGH)

with:

PROPERTY_ENTRY_GPIO("reset-gpios", cherryview_gpiochip_fwnodes[1], 53, GPIO_ACTIVE_HIGH)

(these 2 covers pinctrl for the Bay Trail and Cherry Trail x86 SoC based Android tablets which x86-android-tablets is for).

This should all be pretty straight forward. Assuming we are allowed to dereference an external symbol for the property initialization if not then this becomes significantly more complex.

I'm not even sure if we need to add swnodes, we can probably just use the existing ACPI fwnodes for matching even and then we just need an array with the ACPI fwnode pointers.

Quoted 4 lines

Yes, we can now reference fwnodes from property entries. The entity that creates these devices should be able to retrieve the firmware nodes of the GPIO controllers (e.g.: via gpio_device_find_by_label() - finding it by labek is what it effectively tried to do now).

How do you do that when your code happens to run first, before the controller is instantiated? gpio_device_find_by_label() will not find it, so what will you use as fwnode in that case?

Quoted 37 lines · Dmitry Torokhov

Quoted 35 lines · Bartosz Golaszewski

Quoted 21 lines · Hans de Goede

For the drivers/platform/x86/x86-android-tablets/* I think the following fix is both the easiest as well as the best solution is to modify:

drivers/pinctrl/intel/pinctrl-baytrail.c
drivers/pinctrl/intel/pinctrl-cherryview.c

To register a swnode for each GPIO controller and then EXPORT_SYMBOL_GPL an array of fwnode pointers which can then be used in the PROPERTY_ENTRY_GPIO() entries replacing e.g.:

PROPERTY_ENTRY_GPIO("reset-gpios", &cherryview_gpiochip_nodes[1], 53, GPIO_ACTIVE_HIGH)

with:

PROPERTY_ENTRY_GPIO("reset-gpios", cherryview_gpiochip_fwnodes[1], 53, GPIO_ACTIVE_HIGH)

(these 2 covers pinctrl for the Bay Trail and Cherry Trail x86 SoC based Android tablets which x86-android-tablets is for).

Quoted 8 lines

This should all be pretty straight forward. Assuming we are allowed to dereference an external symbol for the property initialization if not then this becomes significantly more complex.

I'm not even sure if we need to add swnodes, we can probably just use the existing ACPI fwnodes for matching even and then we just need an array with the ACPI fwnode pointers.

Yes, we can now reference fwnodes from property entries. The entity that creates these devices should be able to retrieve the firmware nodes of the GPIO controllers (e.g.: via gpio_device_find_by_label() - finding it by labek is what it effectively tried to do now).

Quoted 4 lines

How do you do that when your code happens to run first, before the controller is instantiated? gpio_device_find_by_label() will not find it, so what will you use as fwnode in that case?

The device that calls gpio_device_find_by_label() (most likely a "real" device with an OF or ACPI node) should return -EPROBE_DEFER if that's the case and not create children with software nodes.

Quoted 7 lines

Quoted 6 lines

How do you do that when your code happens to run first, before the controller is instantiated? gpio_device_find_by_label() will not find it, so what will you use as fwnode in that case?

Quoted 3 lines

The device that calls gpio_device_find_by_label() (most likely a "real" device with an OF or ACPI node) should return -EPROBE_DEFER if that's the case and not create children with software nodes.

There is no real OF or ACPI node in case of old legacy boards that have not been converted to device tree. In many cases there is not even a device that you can defer a probe for, and returning random errors will likely cause the boot to fail.

Quoted 7 lines · Dmitry Torokhov

Quoted 7 lines

Quoted 6 lines

How do you do that when your code happens to run first, before the controller is instantiated? gpio_device_find_by_label() will not find it, so what will you use as fwnode in that case?

Quoted 9 lines

Quoted 3 lines

The device that calls gpio_device_find_by_label() (most likely a "real" device with an OF or ACPI node) should return -EPROBE_DEFER if that's the case and not create children with software nodes.

There is no real OF or ACPI node in case of old legacy boards that have not been converted to device tree. In many cases there is not even a device that you can defer a probe for, and returning random errors will likely cause the boot to fail.

Then I believe such board files should have never been converted to (fake) software nodes because what is the advantage of them over time-proven and well tested lookup tables if all we're doing is comparing strings?

Hi Bartosz,

Quoted 49 lines · Bartosz Golaszewski

Quoted 44 lines · Andy Shevchenko

+Cc: Bart.

Quoted 41 lines · Yauhen Kharuzhy

Quoted 8 lines · Hans de Goede

Now that gpiolib supports software nodes to describe GPIOs, switch the driver away from using GPIO lookup tables for Goodix touchscreens to using PROPERTY_ENTRY_GPIO() to keep all touchscreen properties together.

Since the tablets are using either Baytrail or Cherryview GPIO controllers x86_dev_info structure has been extended to carry gpiochip type information so that the code can instantiate correct set of software nodes representing the GPIO chip.

Hi, it seems that the mechanism for looking up GPIOs using software
node names is broken now (checked on next-20260503) by commit e5d527be7e6984882306b49c067f1fec18920735 "gpio: swnode: don't use the swnode's name as the key for GPIO lookup".

As I understand, some of the issues caused by it were addressed in the series [1], but not for the x86-android-tablets driver. Now any GPIO belonging to SoC's gpiochips cannot be found by drivers. For example, for the Lenovo YB1-X90F keyboard touchpad:

[   27.297279] i2c i2c-goodix_ts: bus: 'i2c': __driver_probe_device: matched device with driver Goodix-TS
[   27.297285] i2c i2c-goodix_ts: bus: 'i2c': really_probe: probing driver Goodix-TS with device
[   27.297291] Goodix-TS i2c-goodix_ts: no default pinctrl state
[   27.297330] Goodix-TS i2c-goodix_ts: supply AVDD28 not found, using dummy regulator
[   27.297359] device: 'regulator:regulator.0--i2c:i2c-goodix_ts': device_add
[   27.297454] devices_kset: Moving i2c-goodix_ts to end of list
[   27.297459] PM: Moving i2c:i2c-goodix_ts to end of list
[   27.297463] Goodix-TS i2c-goodix_ts: Linked as a consumer to regulator.0
[   27.297472] Goodix-TS i2c-goodix_ts: supply VDDIO not found, using dummy regulator
[   27.297492] Goodix-TS i2c-goodix_ts: using swnode 'node11' for 'irq' GPIO lookup
[   27.297505] Goodix-TS i2c-goodix_ts: No GPIO consumer irq found
[   27.297511] Goodix-TS i2c-goodix_ts: error -EPROBE_DEFER: Failed to get irq GPIO
[   27.297552] Goodix-TS i2c-goodix_ts: Dropping the link to regulator.0
[   27.297558] device: 'regulator:regulator.0--i2c:i2c-goodix_ts': device_unregister
[   27.297612] Goodix-TS i2c-goodix_ts: Driver Goodix-TS requests probe deferral
[   27.297624] i2c i2c-goodix_ts: Added to deferred list

Could somebody advise on how to fix this, or does a fix already exist? I am not familiar with the swnode/fwnode framework but can do some investigation to resolve this.

I really don't want to revert to the label lookup and string comparison as this is totally broken

Quoted 10 lines

so let me help you.

The fix should be relatively easy - we need the address of the software node associated with the GPIO chip we want to get the pin from, and we can reference it using the PROPERTY_ENTRY_GPIO() macro in the software node of the consumer.

Can you point me to the place in code where this fails? Is this drivers/platform/x86/lenovo/yogabook.c? This is the only place where "i2c-goodix_ts" if even referenced upstream. If you could enable CONFIG_DEBUG_GPIO and post the kernel log somewhere, it would help me too.

First of all thank you for your offer to help. I actually pointed out that the whole name matching instead of using a fwnode reference was weird when a bunch of platform-driver-x86 drivers where first converted from using GPIO lookup tables to using swnodes:

https://lore.kernel.org/platform-driver-x86/[email protected]/

Dmitry convinced me back then that this is how GPIO controller swnode matching was supposed to work and now we are here...

By far the biggest user of the name based matching is the drivers/platform/x86/x86-android-tablets code which was moved to this recent(ish) by this series:

https://lore.kernel.org/platform-driver-x86/[email protected]/

But there are some other pdx86 files too:

hans@shalem:~/projects/linux$ ack -l PROPERTY_ENTRY_GPIO drivers/platform/x86/
drivers/platform/x86/x86-android-tablets/lenovo.c
drivers/platform/x86/x86-android-tablets/acer.c
drivers/platform/x86/x86-android-tablets/other.c
drivers/platform/x86/x86-android-tablets/shared-psy-info.c
drivers/platform/x86/x86-android-tablets/asus.c
drivers/platform/x86/barco-p50-gpio.c
drivers/platform/x86/meraki-mx100.c
drivers/platform/x86/pcengines-apuv2.c

For the drivers/platform/x86/x86-android-tablets/* I think the following fix is both the easiest as well as the best solution is to modify:

drivers/pinctrl/intel/pinctrl-baytrail.c
drivers/pinctrl/intel/pinctrl-cherryview.c

To register a swnode for each GPIO controller and then EXPORT_SYMBOL_GPL an array of fwnode pointers which can then be used in the PROPERTY_ENTRY_GPIO() entries replacing e.g.:

PROPERTY_ENTRY_GPIO("reset-gpios", &cherryview_gpiochip_nodes[1], 53, GPIO_ACTIVE_HIGH)

with:

PROPERTY_ENTRY_GPIO("reset-gpios", cherryview_gpiochip_fwnodes[1], 53, GPIO_ACTIVE_HIGH)

(these 2 covers pinctrl for the Bay Trail and Cherry Trail x86 SoC based Android tablets which x86-android-tablets is for).

This should all be pretty straight forward. Assuming we are allowed to dereference an external symbol for the property initialization if not then this becomes significantly more complex.

I'm not even sure if we need to add swnodes, we can probably just use the existing ACPI fwnodes for matching even and then we just need an array with the ACPI fwnode pointers.

###

Unfortunately this only covers most of the PROPERTY_ENTRY_GPIO() swnode props under drivers/platform/x86/x86-android-tablets.

These are still a problem after fixing all the ones referencing baytrail / cherryview SoC GPIO controllers:

static const struct property_entry lenovo_yoga_tab2_830_1050_wm1502_props[] = {
PROPERTY_ENTRY_GPIO("reset-gpios",
&crystalcove_gpiochip_node, 3, GPIO_ACTIVE_HIGH),
PROPERTY_ENTRY_GPIO("wlf,ldoena-gpios",
&baytrail_gpiochip_nodes[1], 23, GPIO_ACTIVE_HIGH),
PROPERTY_ENTRY_GPIO("wlf,spkvdd-ena-gpios",
&arizona_gpiochip_node, 2, GPIO_ACTIVE_HIGH),
PROPERTY_ENTRY_GPIO("wlf,micd-pol-gpios",
&arizona_gpiochip_node, 4, GPIO_ACTIVE_LOW),
{ }
};

This one gets added to a device dynamically, so we could lookup the GPIO controller, attach a swnode and then dynamically generate the above properties before attaching them.

This one:

static const struct property_entry lenovo_yt3_wm1502_props[] = {
        PROPERTY_ENTRY_GPIO("wlf,spkvdd-ena-gpios",
                            &cherryview_gpiochip_nodes[0], 75, GPIO_ACTIVE_HIGH),
        PROPERTY_ENTRY_GPIO("wlf,ldoena-gpios",
                            &cherryview_gpiochip_nodes[0], 81, GPIO_ACTIVE_HIGH),
        PROPERTY_ENTRY_GPIO("reset-gpios", &cherryview_gpiochip_nodes[0], 82, GPIO_ACTIVE_HIGH
        PROPERTY_ENTRY_GPIO("wlf,micd-pol-gpios", &arizona_gpiochip_node, 2, GPIO_ACTIVE_HIGH)
        { }
};

is more complex though, since this is used for a SPI boardinfo swmode, so generating this dynamically is going to involve some more rework.

I think it might be best to just at least partially revert:

https://lore.kernel.org/platform-driver-x86/[email protected]/

the main goal there was to stop using the deprecated desc_to_gpio() function which was being used for gpio-button platform-data.

We could revert:

[PATCH v4 10/20] platform/x86: x86-android-tablets: remove support for GPIO lookup tables [PATCH v4 07/20] platform/x86: x86-android-tablets: convert wm1502

To solve the problematic WM5102 codec lookups for non main Soc GPIOs, assuming we can fix the main SoC GPIO fwnode properties.

###

Note this just solves all the cases under drivers/platform/x86/x86-android-tablets/ and I'm happy to help testing fixes. This still leaves:

drivers/platform/x86/barco-p50-gpio.c
drivers/platform/x86/meraki-mx100.c
drivers/platform/x86/pcengines-apuv2.c

unresolved. I'm less familiar with these and I cannot test fixes for these.

Quoted 2 lines · Hans de Goede

Quoted 1 line · Bartosz Golaszewski

On Mon, 9 Feb 2026 09:08:04 +0100, Andy Shevchenko <[email protected]> said:

I think the hardest breakages are here:

arch/arm/mach-omap1/board-nokia770.c
arch/arm/mach-pxa/gumstix.c
arch/arm/mach-pxa/spitz.c
arch/arm/mach-tegra/board-paz00.c

If we check out at nokia, it uses drivers/gpio/gpio-omap.c. As far as I can see it does not even have a fwnode assigned: it either does not have parent or its parent is a platform device instantiated by the driver itself and does not have a firmware node associated with it.

Quoted 11 lines · Dmitry Torokhov

Quoted 2 lines · Hans de Goede

Quoted 1 line · Bartosz Golaszewski

On Mon, 9 Feb 2026 09:08:04 +0100, Andy Shevchenko <[email protected]> said:

I think the hardest breakages are here:

arch/arm/mach-omap1/board-nokia770.c
arch/arm/mach-pxa/gumstix.c
arch/arm/mach-pxa/spitz.c
arch/arm/mach-tegra/board-paz00.c

Quoted 4 lines

If we check out at nokia, it uses drivers/gpio/gpio-omap.c. As far as I can see it does not even have a fwnode assigned: it either does not have parent or its parent is a platform device instantiated by the driver itself and does not have a firmware node associated with it.

I've been meaning to drop support for mach-pxa board files including gumstix and spitz for a while, I should probably just do it sooner than later.

I don't know why paz00.c still contains the fwnode entries, I believe that should have been converted to a device node in arch/arm/boot/dts/nvidia/tegra20-paz00.dts after d64c732dfc9e ("net: rfkill: gpio: add DT support").

Quoted 11 lines · Dmitry Torokhov

Quoted 2 lines · Hans de Goede

Quoted 1 line · Bartosz Golaszewski

On Mon, 9 Feb 2026 09:08:04 +0100, Andy Shevchenko <[email protected]> said:

I think the hardest breakages are here:

arch/arm/mach-omap1/board-nokia770.c
arch/arm/mach-pxa/gumstix.c
arch/arm/mach-pxa/spitz.c
arch/arm/mach-tegra/board-paz00.c

Quoted 4 lines

If we check out at nokia, it uses drivers/gpio/gpio-omap.c. As far as I can see it does not even have a fwnode assigned: it either does not have parent or its parent is a platform device instantiated by the driver itself and does not have a firmware node associated with it.

I've been meaning to drop support for mach-pxa board files including gumstix and spitz for a while, I should probably just do it sooner than later.

Hi Bartosz, Hans,

Quoted 8 lines

Quoted 8 lines

Quoted 5 lines

Quoted 5 lines

Could somebody advise on how to fix this, or does a fix already exist? I am not familiar with the swnode/fwnode framework but can do some investigation to resolve this.

I really don't want to revert to the label lookup and string comparison as this is totally broken

I would start with explaining why exactly this is broken. So far the explanation has been:

"
Looking up a GPIO controller by label that is the name of the software node is wonky at best - the GPIO controller driver is free to set a different label than the name of its firmware node. We're already being passed a firmware node handle attached to the GPIO device to swnode_get_gpio_device() so use it instead for a more precise lookup.
"

This is weak. Indeed the controller is free to select a different label, breaking the link. This is a weakness of software nodes in general, where we do not have a mechanism to validate the scheme.

However switching to matching strictly by fwnode requires knowledge of the instance of the fwnode. This may work OK-ish for some drivers but breaks for the main intended users of this: legacy board files, where we want to specify static mappings and do not want to "reach" into individual gpiochip drivers to fish out the actual firmware node.

From the docs that were accepted (Documentation/driver-api/gpio/board.rst)

"
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.
"

Note that this is different from OF or ACPI nodes because there parsing and creating nodes is a separate process. You get the whole graph available to you right away, so it is possible to know the exact node you are referencing.

This is what I wrote to Hans when he raised his concerns:

"
I agree it is a bit weird, but this allows to disconnect the board file from the GPIO driver and makes it easier to convert to device tree down the road as it can be done in a piecemeal fashion. If you want fwnode actually attached to the gpiochip then:

1. You can't really have static/const initializers in most of the cases
2. Fishing it out from an unrelated subsystem is much harder than matching on a name.
"

I think the hardest breakages are here:

arch/arm/mach-omap1/board-nokia770.c
arch/arm/mach-pxa/gumstix.c
arch/arm/mach-pxa/spitz.c
arch/arm/mach-tegra/board-paz00.c

If we check out at nokia, it uses drivers/gpio/gpio-omap.c. As far as I can see it does not even have a fwnode assigned: it either does not have parent or its parent is a platform device instantiated by the driver itself and does not have a firmware node associated with it.

So in the end name matching allows weakly referencing objects elsewhere in the kernel for legacy and one-off devices.

Maybe we should allow for both? Do a fwnode lookup and when it fails fall back to matching on name?

Hi Bartosz, Hans,

Quoted 8 lines

Quoted 8 lines

Quoted 5 lines

Quoted 5 lines

Could somebody advise on how to fix this, or does a fix already exist? I am not familiar with the swnode/fwnode framework but can do some investigation to resolve this.

I really don't want to revert to the label lookup and string comparison as this is totally broken

I would start with explaining why exactly this is broken. So far the explanation has been:

"
Looking up a GPIO controller by label that is the name of the software node is wonky at best - the GPIO controller driver is free to set a different label than the name of its firmware node. We're already being passed a firmware node handle attached to the GPIO device to swnode_get_gpio_device() so use it instead for a more precise lookup.
"

This is weak. Indeed the controller is free to select a different label, breaking the link. This is a weakness of software nodes in general, where we do not have a mechanism to validate the scheme.

However switching to matching strictly by fwnode requires knowledge of the instance of the fwnode. This may work OK-ish for some drivers but breaks for the main intended users of this: legacy board files, where we want to specify static mappings and do not want to "reach" into individual gpiochip drivers to fish out the actual firmware node.

From the docs that were accepted (Documentation/driver-api/gpio/board.rst)

"
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.
"

Note that this is different from OF or ACPI nodes because there parsing and creating nodes is a separate process. You get the whole graph available to you right away, so it is possible to know the exact node you are referencing.

This is what I wrote to Hans when he raised his concerns:

"
I agree it is a bit weird, but this allows to disconnect the board file from the GPIO driver and makes it easier to convert to device tree down the road as it can be done in a piecemeal fashion. If you want fwnode actually attached to the gpiochip then:

1. You can't really have static/const initializers in most of the cases
2. Fishing it out from an unrelated subsystem is much harder than matching on a name.
"

I think the hardest breakages are here:

arch/arm/mach-omap1/board-nokia770.c
arch/arm/mach-pxa/gumstix.c
arch/arm/mach-pxa/spitz.c
arch/arm/mach-tegra/board-paz00.c

If we check out at nokia, it uses drivers/gpio/gpio-omap.c. As far as I can see it does not even have a fwnode assigned: it either does not have parent or its parent is a platform device instantiated by the driver itself and does not have a firmware node associated with it.

So in the end name matching allows weakly referencing objects elsewhere in the kernel for legacy and one-off devices.

Maybe we should allow for both? Do a fwnode lookup and when it fails fall back to matching on name?

Quoted 2 lines · Dmitry Torokhov

Hi Bartosz, Hans,

[snip]

Quoted 20 lines

Quoted 8 lines

Quoted 8 lines

Quoted 5 lines

Quoted 5 lines

Could somebody advise on how to fix this, or does a fix already exist? I am not familiar with the swnode/fwnode framework but can do some investigation to resolve this.

I really don't want to revert to the label lookup and string comparison as this is totally broken

I would start with explaining why exactly this is broken. So far the explanation has been:

"
Looking up a GPIO controller by label that is the name of the software node is wonky at best - the GPIO controller driver is free to set a different label than the name of its firmware node. We're already being passed a firmware node handle attached to the GPIO device to swnode_get_gpio_device() so use it instead for a more precise lookup.
"

Quoted 4 lines

This is weak. Indeed the controller is free to select a different label, breaking the link. This is a weakness of software nodes in general, where we do not have a mechanism to validate the scheme.

I would even say that if we keep comparing strings, then it's no better than GPIO lookup tables.

Quoted 7 lines

However switching to matching strictly by fwnode requires knowledge of the instance of the fwnode. This may work OK-ish for some drivers but breaks for the main intended users of this: legacy board files, where we want to specify static mappings and do not want to "reach" into individual gpiochip drivers to fish out the actual firmware node.

I'm not sure I'm following. We can (and do a lot!) reference static struct software_node instances before we register them with driver core, creating whole trees of property nodes. I get that here we're talking about *real* firmware nodes but see below:

Quoted 2 lines

From the docs that were accepted (Documentation/driver-api/gpio/board.rst)

Quick git blame, git log, ah, yes, I signed off on this. I guess it's on me now too. :)

Quoted 7 lines

"
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.
"

Quoted 5 lines

Note that this is different from OF or ACPI nodes because there parsing and creating nodes is a separate process. You get the whole graph available to you right away, so it is possible to know the exact node you are referencing.

The device that creates devices not tied to a real OF or ACPI node, is typically responsible for creating the software nodes for its children. It can check if given GPIO controller already exists (gpio_device_find_by_label()) and if not - just return -EPROBE_DEFER and not create children. If it does, then it can pass its fwnode to the children. A bit like so:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/reset/core.c#n910

Just with the lookup done by label and not fwnode.

I may have not paid attention to the docs and signed off on it but it doesn't make it correct. The strength of software nodes is that we have an actual fwnode link between devices. If we just fake this link, then why are we even using software nodes at all?

Quoted 9 lines

This is what I wrote to Hans when he raised his concerns:

"
I agree it is a bit weird, but this allows to disconnect the board file from the GPIO driver and makes it easier to convert to device tree down the road as it can be done in a piecemeal fashion. If you want fwnode actually attached to the gpiochip then:

Quoted 4 lines

1. You can't really have static/const initializers in most of the cases
2. Fishing it out from an unrelated subsystem is much harder than matching on a name.
"

Ok but if we match names then we already have a mechanism for that: lookup tables. I really fail to see how creating software nodes with a specific name in consumer code is any better.

[snip]

Quoted 8 lines

I think the hardest breakages are here:

arch/arm/mach-omap1/board-nokia770.c
arch/arm/mach-pxa/gumstix.c
arch/arm/mach-pxa/spitz.c
arch/arm/mach-tegra/board-paz00.c

Quoted 5 lines

If we check out at nokia, it uses drivers/gpio/gpio-omap.c. As far as I can see it does not even have a fwnode assigned: it either does not have parent or its parent is a platform device instantiated by the driver itself and does not have a firmware node associated with it.

In that case using software nodes makes absolutely no sense and users should stick to GPIO lookup tables. The provider does not have an fwnode attached, how can we just fake it in the consumer?

I would rather just attach a software node to the omap controller in arch/arm/mach-omap1/gpio16xx.c and use its address in these board files.

Quoted 7 lines

So in the end name matching allows weakly referencing objects elsewhere in the kernel for legacy and one-off devices.

Maybe we should allow for both? Do a fwnode lookup and when it fails fall back to matching on name?

Isn't it GPIO lookup tables with extra steps and more confusing too? Because that's how it works in GPIO core: if you can't find anything using the fwnode lookup, you fall back to comparing names in GPIO lookup tables.

My point is: it only makes sense to use software nodes if we're creating links between them. If we fake them and compare their names instead, then it's just abuse of the API. It says PROPERTY_ENTRY_REF() for a reason: it's supposed to store an address leading you to the actual device on the other side.

Quoted 3 lines · Bartosz Golaszewski

Quoted 1 line · Dmitry Torokhov

Hi Bartosz, Hans,

If your fwnode pointer is not a compile-time constant (since you have to look it up somehow) you can not make corresponding property entries static constant arrays, and have to build them dynamically (or fix them up in place after doing the lookup).

Quoted 7 lines

The device that creates devices not tied to a real OF or ACPI node, is typically responsible for creating the software nodes for its children. It can check if given GPIO controller already exists (gpio_device_find_by_label()) and if not - just return -EPROBE_DEFER and not create children. If it does, then it can pass its fwnode to the children. A bit like so:

Quoted 3 lines

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/reset/core.c#n910

Just with the lookup done by label and not fwnode.

As I mentioned another email, in case of old legacy boards you do not really have ACPI or OF nodes. If they were there then we would need to build trees of software nodes, we would simply extend the DTs for them.

Quoted 5 lines

I may have not paid attention to the docs and signed off on it but it doesn't make it correct. The strength of software nodes is that we have an actual fwnode link between devices. If we just fake this link, then why are we even using software nodes at all?

To allow drivers drop hard coded platform data and switch to generic device properties. This goes beyond GPIOs.

Quoted 9 lines

Quoted 9 lines

This is what I wrote to Hans when he raised his concerns:

"
I agree it is a bit weird, but this allows to disconnect the board file from the GPIO driver and makes it easier to convert to device tree down the road as it can be done in a piecemeal fashion. If you want fwnode actually attached to the gpiochip then:

Quoted 8 lines

Quoted 4 lines

1. You can't really have static/const initializers in most of the cases
2. Fishing it out from an unrelated subsystem is much harder than matching on a name.
"

Ok but if we match names then we already have a mechanism for that: lookup tables. I really fail to see how creating software nodes with a specific name in consumer code is any better.

I do not want to have 2 mechanisms, one for GPIOs, and one for everything else. Let's take gpio_keys driver. It uses platform data or device tree properties (generic device properties) to describe the hardware. I want to drop platform data, and I do not want to encumber the driver itself with setting up the board specific lookup tables, I

want the configuration be contained in board files. I also do not want to have to configure all properties but GPIOs through one mechanism (software nodes) and then have an exception for GPIOs to use lookup tables.

I understand that matching on firmware node is nice and may even be preferable in some cases, but I think matching on name has its own place given all practicalities.

Quoted 17 lines

[snip]

Quoted 13 lines

I think the hardest breakages are here:

arch/arm/mach-omap1/board-nokia770.c
arch/arm/mach-pxa/gumstix.c
arch/arm/mach-pxa/spitz.c
arch/arm/mach-tegra/board-paz00.c

If we check out at nokia, it uses drivers/gpio/gpio-omap.c. As far as I can see it does not even have a fwnode assigned: it either does not have parent or its parent is a platform device instantiated by the driver itself and does not have a firmware node associated with it.

Quoted 3 lines

In that case using software nodes makes absolutely no sense and users should stick to GPIO lookup tables. The provider does not have an fwnode attached, how can we just fake it in the consumer?

Why not? It allows us to use generic device properties for describing everything that we need.

Quoted 3 lines

I would rather just attach a software node to the omap controller in arch/arm/mach-omap1/gpio16xx.c and use its address in these board files.

That might work, just a bigger change than I wanted to make originally.

Quoted 8 lines

Quoted 7 lines

So in the end name matching allows weakly referencing objects elsewhere in the kernel for legacy and one-off devices.

Maybe we should allow for both? Do a fwnode lookup and when it fails fall back to matching on name?

Quoted 3 lines

Isn't it GPIO lookup tables with extra steps and more confusing too? Because that's how it works in GPIO core: if you can't find anything using the fwnode lookup, you fall back to comparing names in GPIO lookup tables.

What you are missing is that it allows to describe everything, not only GPIOs, through the common mechanism.

Quoted 6 lines

My point is: it only makes sense to use software nodes if we're creating links between them. If we fake them and compare their names instead, then it's just abuse of the API. It says PROPERTY_ENTRY_REF() for a reason: it's supposed to store an address leading you to the actual device on the other side.

No, it is supposed to store a "reference". It does not have to be a pointer, it is a reference to another object. Could be an IP address or USB port number, or something else that can uniquely identify that object. In DTS it is not a pointer, it is "&node". How it is implemented underneath is an implementation detail.

Quoted 5 lines · Dmitry Torokhov

Quoted 3 lines · Bartosz Golaszewski

Quoted 1 line · Dmitry Torokhov

Hi Bartosz, Hans,

[snip]

Quoted 6 lines

If your fwnode pointer is not a compile-time constant (since you have to look it up somehow) you can not make corresponding property entries static constant arrays, and have to build them dynamically (or fix them up in place after doing the lookup).

Ok, yes, as I described below.

Quoted 7 lines

Quoted 7 lines

The device that creates devices not tied to a real OF or ACPI node, is typically responsible for creating the software nodes for its children. It can check if given GPIO controller already exists (gpio_device_find_by_label()) and if not - just return -EPROBE_DEFER and not create children. If it does, then it can pass its fwnode to the children. A bit like so:

Quoted 8 lines

Quoted 3 lines

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/reset/core.c#n910

Just with the lookup done by label and not fwnode.

As I mentioned another email, in case of old legacy boards you do not really have ACPI or OF nodes. If they were there then we would need to build trees of software nodes, we would simply extend the DTs for them.

Adding software nodes to providers in that case is quite straightforward and the right thing to do. But we're talking about a different case: providers with real firmware nodes that we can't access until after the tree is parsed. Which happens quite early into the boot process. Once done, you could of_find_node_by_name/compatible/whatever() and reference it already from a software node. You may not really need the device for that. If all you care for is a label, then you already have it in the form of the device-node label.

Quoted 6 lines

Quoted 5 lines

I may have not paid attention to the docs and signed off on it but it doesn't make it correct. The strength of software nodes is that we have an actual fwnode link between devices. If we just fake this link, then why are we even using software nodes at all?

Quoted 3 lines

To allow drivers drop hard coded platform data and switch to generic device properties. This goes beyond GPIOs.

Consumers can already use generic gpiod_ interfaces even if their GPIOs are set up using lookup tables behind the scenes. There's no need for platform data.

Quoted 19 lines

Quoted 18 lines

Quoted 10 lines

This is what I wrote to Hans when he raised his concerns:

"
I agree it is a bit weird, but this allows to disconnect the board file from the GPIO driver and makes it easier to convert to device tree down the road as it can be done in a piecemeal fashion. If you want fwnode actually attached to the gpiochip then:

Quoted 4 lines

1. You can't really have static/const initializers in most of the cases
2. Fishing it out from an unrelated subsystem is much harder than matching on a name.
"

Ok but if we match names then we already have a mechanism for that: lookup tables. I really fail to see how creating software nodes with a specific name in consumer code is any better.

Quoted 5 lines

I do not want to have 2 mechanisms, one for GPIOs, and one for everything else. Let's take gpio_keys driver. It uses platform data or device tree properties (generic device properties) to describe the hardware. I want to drop platform data, and I do not want to encumber the driver itself with setting up the board specific lookup tables, I

Definitely but look at what we're doing now: - consumers just set up GPIOs for themselves using arbitrary strings.

Quoted 6 lines

want the configuration be contained in board files. I also do not want to have to configure all properties but GPIOs through one mechanism (software nodes) and then have an exception for GPIOs to use lookup tables.

I agree but given that we use software nodes properly and not as a placeholder for GPIO chip labels.

Quoted 4 lines

I understand that matching on firmware node is nice and may even be preferable in some cases, but I think matching on name has its own place given all practicalities.

Ok, let's start talking solutions. As I said: I'm really surprised this only shows up now when that change has been upstream since v6.18-rc1. I can conditionally re-enable name matching in gpiolib-swnode as a fall-back with the assumption that we'll work towards better solutions. I hate it but if it breaks existing users then I don't see much choice.

Quoted 18 lines

Quoted 18 lines

[snip]

Quoted 13 lines

I think the hardest breakages are here:

arch/arm/mach-omap1/board-nokia770.c
arch/arm/mach-pxa/gumstix.c
arch/arm/mach-pxa/spitz.c
arch/arm/mach-tegra/board-paz00.c

If we check out at nokia, it uses drivers/gpio/gpio-omap.c. As far as I can see it does not even have a fwnode assigned: it either does not have parent or its parent is a platform device instantiated by the driver itself and does not have a firmware node associated with it.

Quoted 7 lines

Quoted 3 lines

In that case using software nodes makes absolutely no sense and users should stick to GPIO lookup tables. The provider does not have an fwnode attached, how can we just fake it in the consumer?

Why not? It allows us to use generic device properties for describing everything that we need.

Sigh... I'm all for it but we're "faking" a reference as described above.

Quoted 6 lines

Quoted 3 lines

I would rather just attach a software node to the omap controller in arch/arm/mach-omap1/gpio16xx.c and use its address in these board files.

That might work, just a bigger change than I wanted to make originally.

That shouldn't be too big, I may look into it next week, though I can't test it. Maybe Mark Brown or Tony Lindgren could.

Quoted 8 lines

Quoted 8 lines

Quoted 7 lines

So in the end name matching allows weakly referencing objects elsewhere in the kernel for legacy and one-off devices.

Maybe we should allow for both? Do a fwnode lookup and when it fails fall back to matching on name?

Quoted 7 lines

Quoted 3 lines

Isn't it GPIO lookup tables with extra steps and more confusing too? Because that's how it works in GPIO core: if you can't find anything using the fwnode lookup, you fall back to comparing names in GPIO lookup tables.

What you are missing is that it allows to describe everything, not only GPIOs, through the common mechanism.

For sure but the GPIO label comparison is very GPIO-centric and implemented under drivers/gpio/.

Quoted 7 lines

Quoted 6 lines

My point is: it only makes sense to use software nodes if we're creating links between them. If we fake them and compare their names instead, then it's just abuse of the API. It says PROPERTY_ENTRY_REF() for a reason: it's supposed to store an address leading you to the actual device on the other side.

Quoted 6 lines

No, it is supposed to store a "reference". It does not have to be a pointer, it is a reference to another object. Could be an IP address or USB port number, or something else that can uniquely identify that object. In DTS it is not a pointer, it is "&node". How it is implemented underneath is an implementation detail.

This is incorrect. The fwnode reference is resolved - using the .get_reference_args() callback - to the contents of struct wnode_reference_args where the first member is the address of the "referenced" fwnode. Even for software nodes, the software_node_ref_args structure expects the address of either a software or firmware node and software_node_get_reference_args() will fail if it contains neither.

I added the ability for software nodes to reference "real" firmware nodes thinking it would be enough to solve such issues dynamically. I see your point about it being more complex than it should. I was thinking about proper solutions and thought about a concept of a "future_fwnode".

Something like:

extern struct fwnode_handle *future_node;

const struct software_node consumer_node = {
    PROPERTY_ENTRY_GPIO("reset-gpios", future_node, ...),
};

Where future_node initially uses an fwnode implementation returning -EPROBE_DEFER until after the devicetree or ACPI was parsed and we can then assign it a proper firmware node via some mechanism attaching OF or ACPI nodes to the correct consumers (by label or otherwise).

Quoted 4 lines

Consumers can already use generic gpiod_ interfaces even if their GPIOs are set up using lookup tables behind the scenes. There's no need for platform data.

But there are other settings that use platform data. For example:

struct gpio_keys_button {
	unsigned int code;
	int gpio;
	int active_low;
	const char *desc;
	unsigned int type;
	int wakeup;
	int wakeup_event_action;
	int debounce_interval;
	bool can_disable;
	int value;
	unsigned int irq;
	unsigned int wakeirq;
};

This describes one gpio-keys button. Besides gpio itself there is code, type, whether it is a wakeup button, whether it can be disabled, it's label, etc. Those can be expressed via device properties (in case of legacy boards via static device properties).

I do not want to have a separate way of configuring GPIOs from the rest of the properties. This would be very confusing.

Quoted 3 lines

Definitely but look at what we're doing now: - consumers just set up GPIOs for themselves using arbitrary strings.

Look _beyond_ GPIOs. There are other properties that also need to be set. GPIOs should not be special.

OK, so maybe:

1. Restore the label matching as a fallback for now (keeping the fwnode identity mapping as the first choice)

2. Work through cases where we can actually instantiate/locate the firmware node, like with omap-gpio (but we will need to see if there are linking/loading order issues there)
3. Figure out what to do with the rest (if any)
4. Drop the label matching (or agree to keep it until legacy boards die off if #3 fails).

If Arnd removes PXA boards that will help a bunch.

Quoted 22 lines · Dmitry Torokhov

Quoted 4 lines

Consumers can already use generic gpiod_ interfaces even if their GPIOs are set up using lookup tables behind the scenes. There's no need for platform data.

But there are other settings that use platform data. For example:

struct gpio_keys_button {
	unsigned int code;
	int gpio;
	int active_low;
	const char *desc;
	unsigned int type;
	int wakeup;
	int wakeup_event_action;
	int debounce_interval;
	bool can_disable;
	int value;
	unsigned int irq;
	unsigned int wakeirq;
};

Quoted 8 lines

This describes one gpio-keys button. Besides gpio itself there is code, type, whether it is a wakeup button, whether it can be disabled, it's label, etc. Those can be expressed via device properties (in case of legacy boards via static device properties).

I do not want to have a separate way of configuring GPIOs from the rest of the properties. This would be very confusing.

Yes I do get it as I said before. I am all for using device properties here. I just don't want them to be fudged like what is being done now.

Quoted 4 lines

Quoted 3 lines

Definitely but look at what we're doing now: - consumers just set up GPIOs for themselves using arbitrary strings.

Quoted 3 lines

Look _beyond_ GPIOs. There are other properties that also need to be set. GPIOs should not be special.

Agreed, I'm not advocating for using lookup tables. I'm advocating for using swnode correctly.

Quoted 3 lines

Agreed, I'm not advocating for using lookup tables. I'm advocating for using swnode correctly.

I am curious how would you approach to fixing drivers/platform/x86/meraki-mx100.c ? The GPIOs in question belong to "gpio_ich" which is a cell of a MFD PCI device (lpc_ich).

Quoted 7 lines · Dmitry Torokhov

Quoted 3 lines

Agreed, I'm not advocating for using lookup tables. I'm advocating for using swnode correctly.

I am curious how would you approach to fixing drivers/platform/x86/meraki-mx100.c ? The GPIOs in question belong to "gpio_ich" which is a cell of a MFD PCI device (lpc_ich).

Something like this (compile tested only):

+const struct software_node lpc_ich_gpio_swnode = { };

Quoted 3 lines · Bartosz Golaszewski

Quoted 1 line · Dmitry Torokhov

Quoted 1 line

Quoted 8 lines

Quoted 6 lines

Quoted 2 lines

Agreed, I'm not advocating for using lookup tables. I'm advocating for using swnode correctly.

I am curious how would you approach to fixing drivers/platform/x86/meraki-mx100.c ? The GPIOs in question belong to "gpio_ich" which is a cell of a MFD PCI device (lpc_ich).

Something like this (compile tested only):

So, as I understand the idea is to provide a reference to a standalone software node that is not connected to the chain of fwnodes for the device? It might work, but can't we do the same for any GPIO controller automatically at the time of GPIO device registration?

...

Quoted 1 line

+const struct software_node lpc_ich_gpio_swnode = { };

(With name, please!)

Quoted 3 lines · Andy Shevchenko

Quoted 2 lines · Bartosz Golaszewski

On Thu, 12 Feb 2026 04:44:05 +0100, Dmitry Torokhov <[email protected]> said:

Quoted 3 lines

Quoted 1 line

+const struct software_node lpc_ich_gpio_swnode = { };

(With name, please!)

That we could match against... /duck

Quoted 4 lines · Dmitry Torokhov

Quoted 3 lines · Andy Shevchenko

Quoted 2 lines · Bartosz Golaszewski

On Thu, 12 Feb 2026 04:44:05 +0100, Dmitry Torokhov <[email protected]> said:

Quoted 5 lines

Quoted 3 lines

Quoted 1 line

+const struct software_node lpc_ich_gpio_swnode = { };

(With name, please!)

That we could match against... /duck

:-)
No, it's for the /sys/kernel/software_nodes/ to help with debugging, et cetera.

Quoted 5 lines · Andy Shevchenko

Quoted 4 lines · Dmitry Torokhov

Quoted 3 lines · Andy Shevchenko

Quoted 2 lines · Bartosz Golaszewski

On Thu, 12 Feb 2026 04:44:05 +0100, Dmitry Torokhov <[email protected]> said:

...

Quoted 4 lines

Quoted 4 lines

Quoted 3 lines

Quoted 1 line

+const struct software_node lpc_ich_gpio_swnode = { };

(With name, please!)

Quoted 4 lines

Quoted 1 line

That we could match against... /duck

:-)
No, it's for the /sys/kernel/software_nodes/ to help with debugging, et cetera.

OTOH, if there are more than one of a such controllers in the system... And it can be found by reading the links that one of them related to a certain GPIO device. So no insisting on this.

Quoted 18 lines · Andy Shevchenko

Quoted 5 lines · Andy Shevchenko

Quoted 4 lines · Dmitry Torokhov

Quoted 3 lines · Andy Shevchenko

Quoted 2 lines · Bartosz Golaszewski

On Thu, 12 Feb 2026 04:44:05 +0100, Dmitry Torokhov <[email protected]> said:

...

Quoted 8 lines

Quoted 5 lines

Quoted 3 lines

Quoted 1 line

+const struct software_node lpc_ich_gpio_swnode = { };

(With name, please!)

That we could match against... /duck

:-)
No, it's for the /sys/kernel/software_nodes/ to help with debugging, et cetera.

Quoted 3 lines

OTOH, if there are more than one of a such controllers in the system... And it can be found by reading the links that one of them related to a certain GPIO device. So no insisting on this.

If there are multiple such controllers we cannot use a static software node anyway as it should not be shared between them.

Quoted 24 lines · Dmitry Torokhov

Quoted 21 lines · Andy Shevchenko

Quoted 5 lines · Andy Shevchenko

Quoted 4 lines · Dmitry Torokhov

Quoted 3 lines · Andy Shevchenko

Quoted 2 lines · Bartosz Golaszewski

On Thu, 12 Feb 2026 04:44:05 +0100, Dmitry Torokhov <[email protected]> said:

...

Quoted 8 lines

Quoted 5 lines

Quoted 3 lines

Quoted 1 line

+const struct software_node lpc_ich_gpio_swnode = { };

(With name, please!)

That we could match against... /duck

:-)
No, it's for the /sys/kernel/software_nodes/ to help with debugging, et cetera.

OTOH, if there are more than one of a such controllers in the system... And it can be found by reading the links that one of them related to a certain GPIO device. So no insisting on this.

Quoted 3 lines

If there are multiple such controllers we cannot use a static software node anyway as it should not be shared between them.

In such case they should do what OF nodes do (and I'm sure ACPI too):
use some ID to tell them apart.

Quoted 9 lines

Quoted 8 lines

Quoted 4 lines

OTOH, if there are more than one of a such controllers in the system... And it can be found by reading the links that one of them related to a certain GPIO device. So no insisting on this.

If there are multiple such controllers we cannot use a static software node anyway as it should not be shared between them.

Quoted 2 lines

In such case they should do what OF nodes do (and I'm sure ACPI too):
use some ID to tell them apart.

You are missing the point. You will not be able to use a static node and export it. You will need to create a dedicated software node per instance and the provide a lookup mechanism for whoever wants to use them to locate the right one.

That is inherent weakness in identity matching - the rigid coupling - and that is why I originally implemented name matching which allows for weak references.

Quoted 5 lines · Dmitry Torokhov

That is inherent weakness in identity matching - the rigid coupling - and that is why I originally implemented name matching which allows for weak references.

How does this name matching work for multiple instances? You still need to have the number of software nodes correspond with the number of devices and their names need to match the labels.

Anyway, that's purely theoretical for now, let's cross that bridge when we get there.

Quoted 9 lines · Dmitry Torokhov

Quoted 9 lines

Quoted 8 lines

Quoted 4 lines

OTOH, if there are more than one of a such controllers in the system... And it can be found by reading the links that one of them related to a certain GPIO device. So no insisting on this.

If there are multiple such controllers we cannot use a static software node anyway as it should not be shared between them.

Quoted 8 lines

Quoted 2 lines

In such case they should do what OF nodes do (and I'm sure ACPI too):
use some ID to tell them apart.

You are missing the point. You will not be able to use a static node and export it. You will need to create a dedicated software node per instance and the provide a lookup mechanism for whoever wants to use them to locate the right one.

That depends on whether you know the number of instances, doesn't it? If that number is static, you create an equivalent number of software nodes.

Hi,

Quoted 20 lines · Bartosz Golaszewski

Quoted 9 lines · Dmitry Torokhov

Quoted 9 lines

Quoted 8 lines

Quoted 4 lines

OTOH, if there are more than one of a such controllers in the system... And it can be found by reading the links that one of them related to a certain GPIO device. So no insisting on this.

If there are multiple such controllers we cannot use a static software node anyway as it should not be shared between them.

Quoted 8 lines

Quoted 2 lines

In such case they should do what OF nodes do (and I'm sure ACPI too):
use some ID to tell them apart.

You are missing the point. You will not be able to use a static node and export it. You will need to create a dedicated software node per instance and the provide a lookup mechanism for whoever wants to use them to locate the right one.

Quoted 3 lines

That depends on whether you know the number of instances, doesn't it? If that number is static, you create an equivalent number of software nodes.

I think there is some miscommunication happening here.

I _believe_ the troublesome case Dmitry is trying to point out is the following:

1. A single GPIO controller

2. 2 different drivers which need to manually add GPIO info using a swnode with a properties array with PROPERTY_ENTRY_GPIO() entries

A (so far theoretical) example of this might be both the infamous x86-android-tablets code referring to this single GPIO controller as well as some ASoC board file under sound/soc/intel/boards/ referring to it. In that case having them both declare a swnode for the GPIO controller and then both have them attach that to the GPIO controller themselves (*) will lead to a problem because only 1 swnode can be attach to the GPIO controller.

The obvious solution is to have the GPIO controller driver create and attach a swnode and have it export that swnode so that it can be used in PROPERTY_ENTRY_GPIO() declerations in multiple drivers consuming GPIOs from that controller.

Note, I'm not entirely sure this is what Dmitry is trying to say but I think it is. Regardless this is a case which I've been thinking about how to handle myself :)

Quoted 2 lines · Bartosz Golaszewski

On Mon, 9 Feb 2026 21:41:49 +0100, Dmitry Torokhov <[email protected]> said:

Quoted 2 lines

Agreed, I'm not advocating for using lookup tables. I'm advocating for using swnode correctly.

I am curious how would you approach to fixing drivers/platform/x86/meraki-mx100.c ? The GPIOs in question belong to "gpio_ich" which is a cell of a MFD PCI device (lpc_ich).

Maybe it has a standard ACPI HID, Andy, do you know?

software_node_register_node_group() / software_node_unregister_node_group() both accept a NULL node-group as argument.

So there is no need to check for the node-group being NULL before calling these functions, remove the checks to simplify the code.

Note the "if (gpio_button_swnodes)" check for registering is kept because that also guards the creation of a gpio-button platform-device.