[PATCH v4 00/20] x86-android-tablets: convert to use GPIO references + Acer A1-840 support

[PATCH v4 00/20] x86-android-tablets: convert to use GPIO references + Acer A1-840 support

[Hans de Goede]

Hi all,

Original cover-letter from Dmitry's v2 posting:

"This series came about because now software nodes can be used to
describe GPIOs (via PROPERTY_ENTRY_GPIO() macros) and I would like to
eventually get rid of gpio_keys_platform_data structure.

So while I was doing the conversions from GPIO_LOOKUP() tables for
gpio_keys devices I decided to convert the rest of them as well. Maybe
some time in the future we can drop support for GPIO_LOOKUP() and rely
on device properties exclusively."

Follow-up changes / new patches from me:

Changes in v4:
- "convert Yoga Tab2 fast charger to GPIO references" change:
  Split propagating the platform-dev fwnode to the serdev and
  the fwnode_handle_get() call on the serdev fwnode into 2 separate
  statements
- New patch: "Simplify node-group [un]registration"

Changes in v3:
- Add missing pinctrl_put() in lenovo_yoga_tab2_830_1050_init_codec()
  error-exit paths after the pinctrl_get_select() succeeds

- Adding a swnode to the yt3 spi device changes the name of the SPI/codec
  device and the sound/soc/intel/boards/bytcr_wm5102.c machine driver looks
  up the code by name, update the machine driver to use the new name.

- Make yoga-tab2-pro-1380-fastcharger.c propagate the fwnode set on
  the platform-device to the serdev it creates to fix this.

- Fix the commit message of "platform/x86: x86-android-tablets: convert
  gpio_keys devices to GPIO references" which contained a stray reference
  to wm5102.

New patches in v3:

- Change sw_bat register mechanism into a generic swnode_group mechanism

- Use swnode_group mechanism to register groups needed, instead of having
  init() callbacks manually do this

- Changed my email address in the driver to hansg@kernel.org

- Rebased "platform/x86: x86-android-tablets: Add support for Acer A1-840
  tablet" on top, switched that to also use software-nodes for GPIOs and
  added it to this series

- Some Lenovo Yoga Tab 2 support fixes

Regards,

Hans


Dmitry Torokhov (11):
  platform/x86: x86-android-tablets: convert Goodix devices to GPIO
    references
  platform/x86: x86-android-tablets: convert Wacom devices to GPIO
    references
  platform/x86: x86-android-tablets: convert HiDeep devices to GPIO
    references
  platform/x86: x86-android-tablets: convert Novatek devices to GPIO
    references
  platform/x86: x86-android-tablets: convert EDT devices to GPIO
    references
  platform/x86: x86-android-tablets: convert int3496 devices to GPIO
    references
  platform/x86: x86-android-tablets: convert wm1502 devices to GPIO
    references
  platform/x86: x86-android-tablets: convert HID-I2C devices to GPIO
    references
  platform/x86: x86-android-tablets: convert Yoga Tab2 fast charger to
    GPIO references
  platform/x86: x86-android-tablets: remove support for GPIO lookup
    tables
  platform/x86: x86-android-tablets: convert gpio_keys devices to GPIO
    references

Hans de Goede (9):
  platform/x86: x86-android-tablets: replace bat_swnode with
    swnode_group
  platform/x86: x86-android-tablets: use swnode_group instead of manual
    registering
  platform/x86: x86-android-tablets: Simplify node-group
    [un]registration
  platform/x86: x86-android-tablets: Update my email address
  platform/x86: x86-android-tablets: Move Acer info to its own file
  platform/x86: x86-android-tablets: Add support for Acer A1-840 tablet
  platform/x86: x86-android-tablets: Simplify
    lenovo_yoga_tab2_830_1050_exit()
  platform/x86: x86-android-tablets: Fix modules lists for Lenovo
    devices
  platform/x86: x86-android-tablets: Stop using EPROBE_DEFER

 .../lenovo/yoga-tab2-pro-1380-fastcharger.c   |   5 +
 .../platform/x86/x86-android-tablets/Makefile |   2 +-
 .../platform/x86/x86-android-tablets/acer.c   | 247 +++++++++++++
 .../platform/x86/x86-android-tablets/asus.c   | 108 +++---
 .../platform/x86/x86-android-tablets/core.c   | 118 +++---
 .../platform/x86/x86-android-tablets/dmi.c    |  12 +-
 .../platform/x86/x86-android-tablets/lenovo.c | 291 ++++++++-------
 .../platform/x86/x86-android-tablets/other.c  | 338 ++++++------------
 .../x86/x86-android-tablets/shared-psy-info.c |  34 +-
 .../x86/x86-android-tablets/shared-psy-info.h |   8 +-
 .../x86/x86-android-tablets/vexia_atla10_ec.c |   2 +-
 .../x86-android-tablets/x86-android-tablets.h |  28 +-
 sound/soc/intel/boards/bytcr_wm5102.c         |   2 +-
 13 files changed, 714 insertions(+), 481 deletions(-)
 create mode 100644 drivers/platform/x86/x86-android-tablets/acer.c

-- 
2.51.0

[PATCH v4 01/20] platform/x86: x86-android-tablets: convert Goodix devices to GPIO references

[Hans de Goede]

From: Dmitry Torokhov <dmitry.torokhov@gmail.com>

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.

Because this adds a new point of failure in x86_android_tablet_probe(),
x86_android_tablet_remove() is rearranged to handle cases where battery
swnode has not been registered yet, and registering of GPIO lookup
tables is moved earlier as it can not fail.

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Tested-by: Hans de Goede <hansg@kernel.org>
Reviewed-by: Hans de Goede <hansg@kernel.org>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hansg@kernel.org>
---
 .../platform/x86/x86-android-tablets/asus.c   | 23 ++++---
 .../platform/x86/x86-android-tablets/core.c   | 69 ++++++++++++++++---
 .../platform/x86/x86-android-tablets/lenovo.c | 23 ++++---
 .../platform/x86/x86-android-tablets/other.c  | 37 ++--------
 .../x86-android-tablets/x86-android-tablets.h | 11 +++
 5 files changed, 105 insertions(+), 58 deletions(-)

diff --git a/drivers/platform/x86/x86-android-tablets/asus.c b/drivers/platform/x86/x86-android-tablets/asus.c
index 97cd14c1fd23..6c4468f4004b 100644
--- a/drivers/platform/x86/x86-android-tablets/asus.c
+++ b/drivers/platform/x86/x86-android-tablets/asus.c
@@ -9,6 +9,7 @@
  */
 
 #include <linux/gpio/machine.h>
+#include <linux/gpio/property.h>
 #include <linux/input.h>
 #include <linux/platform_device.h>
 
@@ -77,6 +78,16 @@ static const struct software_node asus_me176c_ug3105_node = {
 	.properties = asus_me176c_ug3105_props,
 };
 
+static const struct property_entry asus_me176c_touchscreen_props[] = {
+	PROPERTY_ENTRY_GPIO("reset-gpios", &baytrail_gpiochip_nodes[0], 60, GPIO_ACTIVE_HIGH),
+	PROPERTY_ENTRY_GPIO("irq-gpios", &baytrail_gpiochip_nodes[2], 28, GPIO_ACTIVE_HIGH),
+	{ }
+};
+
+static const struct software_node asus_me176c_touchscreen_node = {
+	.properties = asus_me176c_touchscreen_props,
+};
+
 static const struct x86_i2c_client_info asus_me176c_i2c_clients[] __initconst = {
 	{
 		/* bq24297 battery charger */
@@ -132,6 +143,7 @@ static const struct x86_i2c_client_info asus_me176c_i2c_clients[] __initconst =
 			.type = "GDIX1001:00",
 			.addr = 0x14,
 			.dev_name = "goodix_ts",
+			.swnode = &asus_me176c_touchscreen_node,
 		},
 		.adapter_path = "\\_SB_.I2C6",
 		.irq_data = {
@@ -152,18 +164,8 @@ static const struct x86_serdev_info asus_me176c_serdevs[] __initconst = {
 	},
 };
 
-static struct gpiod_lookup_table asus_me176c_goodix_gpios = {
-	.dev_id = "i2c-goodix_ts",
-	.table = {
-		GPIO_LOOKUP("INT33FC:00", 60, "reset", GPIO_ACTIVE_HIGH),
-		GPIO_LOOKUP("INT33FC:02", 28, "irq", GPIO_ACTIVE_HIGH),
-		{ }
-	},
-};
-
 static struct gpiod_lookup_table * const asus_me176c_gpios[] = {
 	&int3496_gpo2_pin22_gpios,
-	&asus_me176c_goodix_gpios,
 	NULL
 };
 
@@ -179,6 +181,7 @@ const struct x86_dev_info asus_me176c_info __initconst = {
 	.gpiod_lookup_tables = asus_me176c_gpios,
 	.bat_swnode = &generic_lipo_hv_4v35_battery_node,
 	.modules = bq24190_modules,
+	.gpiochip_type = X86_GPIOCHIP_BAYTRAIL,
 };
 
 /* Asus TF103C tablets have an Android factory image with everything hardcoded */
diff --git a/drivers/platform/x86/x86-android-tablets/core.c b/drivers/platform/x86/x86-android-tablets/core.c
index db76ba3abd7b..7b5942010c78 100644
--- a/drivers/platform/x86/x86-android-tablets/core.c
+++ b/drivers/platform/x86/x86-android-tablets/core.c
@@ -155,6 +155,7 @@ static struct serdev_device **serdevs;
 static struct gpio_keys_button *buttons;
 static struct gpiod_lookup_table * const *gpiod_lookup_tables;
 static const struct software_node *bat_swnode;
+static const struct software_node **gpiochip_node_group;
 static void (*exit_handler)(void);
 
 static __init struct i2c_adapter *
@@ -330,6 +331,34 @@ static __init int x86_instantiate_serdev(const struct x86_dev_info *dev_info, in
 	return ret;
 }
 
+const struct software_node baytrail_gpiochip_nodes[] = {
+	{ .name = "INT33FC:00" },
+	{ .name = "INT33FC:01" },
+	{ .name = "INT33FC:02" },
+};
+
+static const struct software_node *baytrail_gpiochip_node_group[] = {
+	&baytrail_gpiochip_nodes[0],
+	&baytrail_gpiochip_nodes[1],
+	&baytrail_gpiochip_nodes[2],
+	NULL
+};
+
+const struct software_node cherryview_gpiochip_nodes[] = {
+	{ .name = "INT33FF:00" },
+	{ .name = "INT33FF:01" },
+	{ .name = "INT33FF:02" },
+	{ .name = "INT33FF:03" },
+};
+
+static const struct software_node *cherryview_gpiochip_node_group[] = {
+	&cherryview_gpiochip_nodes[0],
+	&cherryview_gpiochip_nodes[1],
+	&cherryview_gpiochip_nodes[2],
+	&cherryview_gpiochip_nodes[3],
+	NULL
+};
+
 static void x86_android_tablet_remove(struct platform_device *pdev)
 {
 	int i;
@@ -360,10 +389,14 @@ static void x86_android_tablet_remove(struct platform_device *pdev)
 	if (exit_handler)
 		exit_handler();
 
+	if (bat_swnode)
+		software_node_unregister(bat_swnode);
+
+	if (gpiochip_node_group)
+		software_node_unregister_node_group(gpiochip_node_group);
+
 	for (i = 0; gpiod_lookup_tables && gpiod_lookup_tables[i]; i++)
 		gpiod_remove_lookup_table(gpiod_lookup_tables[i]);
-
-	software_node_unregister(bat_swnode);
 }
 
 static __init int x86_android_tablet_probe(struct platform_device *pdev)
@@ -387,16 +420,36 @@ static __init int x86_android_tablet_probe(struct platform_device *pdev)
 	for (i = 0; dev_info->modules && dev_info->modules[i]; i++)
 		request_module(dev_info->modules[i]);
 
-	bat_swnode = dev_info->bat_swnode;
-	if (bat_swnode) {
-		ret = software_node_register(bat_swnode);
+	gpiod_lookup_tables = dev_info->gpiod_lookup_tables;
+	for (i = 0; gpiod_lookup_tables && gpiod_lookup_tables[i]; i++)
+		gpiod_add_lookup_table(gpiod_lookup_tables[i]);
+
+	switch (dev_info->gpiochip_type) {
+	case X86_GPIOCHIP_BAYTRAIL:
+		gpiochip_node_group = baytrail_gpiochip_node_group;
+		break;
+	case X86_GPIOCHIP_CHERRYVIEW:
+		gpiochip_node_group = cherryview_gpiochip_node_group;
+		break;
+	case X86_GPIOCHIP_UNSPECIFIED:
+		gpiochip_node_group = NULL;
+		break;
+	}
+
+	if (gpiochip_node_group) {
+		ret = software_node_register_node_group(gpiochip_node_group);
 		if (ret)
 			return ret;
 	}
 
-	gpiod_lookup_tables = dev_info->gpiod_lookup_tables;
-	for (i = 0; gpiod_lookup_tables && gpiod_lookup_tables[i]; i++)
-		gpiod_add_lookup_table(gpiod_lookup_tables[i]);
+	if (dev_info->bat_swnode) {
+		ret = software_node_register(dev_info->bat_swnode);
+		if (ret) {
+			x86_android_tablet_remove(pdev);
+			return ret;
+		}
+		bat_swnode = dev_info->bat_swnode;
+	}
 
 	if (dev_info->init) {
 		ret = dev_info->init(&pdev->dev);
diff --git a/drivers/platform/x86/x86-android-tablets/lenovo.c b/drivers/platform/x86/x86-android-tablets/lenovo.c
index 1241a97cda39..22fe76ef5b5a 100644
--- a/drivers/platform/x86/x86-android-tablets/lenovo.c
+++ b/drivers/platform/x86/x86-android-tablets/lenovo.c
@@ -12,6 +12,7 @@
 
 #include <linux/efi.h>
 #include <linux/gpio/machine.h>
+#include <linux/gpio/property.h>
 #include <linux/mfd/arizona/pdata.h>
 #include <linux/mfd/arizona/registers.h>
 #include <linux/mfd/intel_soc_pmic.h>
@@ -61,6 +62,16 @@ static struct lp855x_platform_data lenovo_lp8557_reg_only_pdata = {
 
 /* Lenovo Yoga Book X90F / X90L's Android factory image has everything hardcoded */
 
+static const struct property_entry lenovo_yb1_x90_goodix_props[] = {
+	PROPERTY_ENTRY_GPIO("reset-gpios", &cherryview_gpiochip_nodes[1], 53, GPIO_ACTIVE_HIGH),
+	PROPERTY_ENTRY_GPIO("irq-gpios", &cherryview_gpiochip_nodes[1], 56, GPIO_ACTIVE_HIGH),
+	{ }
+};
+
+static const struct software_node lenovo_yb1_x90_goodix_node = {
+	.properties = lenovo_yb1_x90_goodix_props,
+};
+
 static const struct property_entry lenovo_yb1_x90_wacom_props[] = {
 	PROPERTY_ENTRY_U32("hid-descr-addr", 0x0001),
 	PROPERTY_ENTRY_U32("post-reset-deassert-delay-ms", 150),
@@ -108,6 +119,7 @@ static const struct x86_i2c_client_info lenovo_yb1_x90_i2c_clients[] __initconst
 			.type = "GDIX1001:00",
 			.addr = 0x14,
 			.dev_name = "goodix_ts",
+			.swnode = &lenovo_yb1_x90_goodix_node,
 		},
 		.adapter_path = "\\_SB_.PCI0.I2C2",
 		.irq_data = {
@@ -198,15 +210,6 @@ static const struct x86_gpio_button lenovo_yb1_x90_lid __initconst = {
 	.pin = 19,
 };
 
-static struct gpiod_lookup_table lenovo_yb1_x90_goodix_gpios = {
-	.dev_id = "i2c-goodix_ts",
-	.table = {
-		GPIO_LOOKUP("INT33FF:01", 53, "reset", GPIO_ACTIVE_HIGH),
-		GPIO_LOOKUP("INT33FF:01", 56, "irq", GPIO_ACTIVE_HIGH),
-		{ }
-	},
-};
-
 static struct gpiod_lookup_table lenovo_yb1_x90_hideep_gpios = {
 	.dev_id = "i2c-hideep_ts",
 	.table = {
@@ -225,7 +228,6 @@ static struct gpiod_lookup_table lenovo_yb1_x90_wacom_gpios = {
 
 static struct gpiod_lookup_table * const lenovo_yb1_x90_gpios[] = {
 	&lenovo_yb1_x90_hideep_gpios,
-	&lenovo_yb1_x90_goodix_gpios,
 	&lenovo_yb1_x90_wacom_gpios,
 	NULL
 };
@@ -259,6 +261,7 @@ const struct x86_dev_info lenovo_yogabook_x90_info __initconst = {
 	.gpio_button = &lenovo_yb1_x90_lid,
 	.gpio_button_count = 1,
 	.gpiod_lookup_tables = lenovo_yb1_x90_gpios,
+	.gpiochip_type = X86_GPIOCHIP_CHERRYVIEW,
 	.init = lenovo_yb1_x90_init,
 };
 
diff --git a/drivers/platform/x86/x86-android-tablets/other.c b/drivers/platform/x86/x86-android-tablets/other.c
index f7bd9f863c85..e3907812c8bc 100644
--- a/drivers/platform/x86/x86-android-tablets/other.c
+++ b/drivers/platform/x86/x86-android-tablets/other.c
@@ -10,6 +10,7 @@
 
 #include <linux/acpi.h>
 #include <linux/gpio/machine.h>
+#include <linux/gpio/property.h>
 #include <linux/input.h>
 #include <linux/leds.h>
 #include <linux/pci.h>
@@ -297,6 +298,8 @@ static const struct software_node medion_lifetab_s10346_accel_node = {
 static const struct property_entry medion_lifetab_s10346_touchscreen_props[] = {
 	PROPERTY_ENTRY_BOOL("touchscreen-inverted-x"),
 	PROPERTY_ENTRY_BOOL("touchscreen-swapped-x-y"),
+	PROPERTY_ENTRY_GPIO("reset-gpios", &baytrail_gpiochip_nodes[1], 26, GPIO_ACTIVE_HIGH),
+	PROPERTY_ENTRY_GPIO("irq-gpios", &baytrail_gpiochip_nodes[2], 3, GPIO_ACTIVE_HIGH),
 	{ }
 };
 
@@ -340,24 +343,10 @@ static const struct x86_i2c_client_info medion_lifetab_s10346_i2c_clients[] __in
 	},
 };
 
-static struct gpiod_lookup_table medion_lifetab_s10346_goodix_gpios = {
-	.dev_id = "i2c-goodix_ts",
-	.table = {
-		GPIO_LOOKUP("INT33FC:01", 26, "reset", GPIO_ACTIVE_HIGH),
-		GPIO_LOOKUP("INT33FC:02", 3, "irq", GPIO_ACTIVE_HIGH),
-		{ }
-	},
-};
-
-static struct gpiod_lookup_table * const medion_lifetab_s10346_gpios[] = {
-	&medion_lifetab_s10346_goodix_gpios,
-	NULL
-};
-
 const struct x86_dev_info medion_lifetab_s10346_info __initconst = {
 	.i2c_client_info = medion_lifetab_s10346_i2c_clients,
 	.i2c_client_count = ARRAY_SIZE(medion_lifetab_s10346_i2c_clients),
-	.gpiod_lookup_tables = medion_lifetab_s10346_gpios,
+	.gpiochip_type = X86_GPIOCHIP_BAYTRAIL,
 };
 
 /* Nextbook Ares 8 (BYT) tablets have an Android factory image with everything hardcoded */
@@ -543,6 +532,8 @@ static const struct property_entry whitelabel_tm800a550l_goodix_props[] = {
 	PROPERTY_ENTRY_STRING("firmware-name", "gt912-tm800a550l.fw"),
 	PROPERTY_ENTRY_STRING("goodix,config-name", "gt912-tm800a550l.cfg"),
 	PROPERTY_ENTRY_U32("goodix,main-clk", 54),
+	PROPERTY_ENTRY_GPIO("reset-gpios", &baytrail_gpiochip_nodes[1], 26, GPIO_ACTIVE_HIGH),
+	PROPERTY_ENTRY_GPIO("irq-gpios", &baytrail_gpiochip_nodes[2], 3, GPIO_ACTIVE_HIGH),
 	{ }
 };
 
@@ -578,24 +569,10 @@ static const struct x86_i2c_client_info whitelabel_tm800a550l_i2c_clients[] __in
 	},
 };
 
-static struct gpiod_lookup_table whitelabel_tm800a550l_goodix_gpios = {
-	.dev_id = "i2c-goodix_ts",
-	.table = {
-		GPIO_LOOKUP("INT33FC:01", 26, "reset", GPIO_ACTIVE_HIGH),
-		GPIO_LOOKUP("INT33FC:02", 3, "irq", GPIO_ACTIVE_HIGH),
-		{ }
-	},
-};
-
-static struct gpiod_lookup_table * const whitelabel_tm800a550l_gpios[] = {
-	&whitelabel_tm800a550l_goodix_gpios,
-	NULL
-};
-
 const struct x86_dev_info whitelabel_tm800a550l_info __initconst = {
 	.i2c_client_info = whitelabel_tm800a550l_i2c_clients,
 	.i2c_client_count = ARRAY_SIZE(whitelabel_tm800a550l_i2c_clients),
-	.gpiod_lookup_tables = whitelabel_tm800a550l_gpios,
+	.gpiochip_type = X86_GPIOCHIP_BAYTRAIL,
 };
 
 /*
diff --git a/drivers/platform/x86/x86-android-tablets/x86-android-tablets.h b/drivers/platform/x86/x86-android-tablets/x86-android-tablets.h
index dcf8d49e3b5f..a54d09408866 100644
--- a/drivers/platform/x86/x86-android-tablets/x86-android-tablets.h
+++ b/drivers/platform/x86/x86-android-tablets/x86-android-tablets.h
@@ -32,6 +32,12 @@ enum x86_acpi_irq_type {
 	X86_ACPI_IRQ_TYPE_PMIC,
 };
 
+enum x86_gpiochip_type {
+	X86_GPIOCHIP_UNSPECIFIED = 0,
+	X86_GPIOCHIP_BAYTRAIL,
+	X86_GPIOCHIP_CHERRYVIEW,
+};
+
 struct x86_acpi_irq_data {
 	char *chip;   /* GPIO chip label (GPIOINT) or PMIC ACPI path (PMIC) */
 	enum x86_acpi_irq_type type;
@@ -99,6 +105,7 @@ struct x86_dev_info {
 	int (*init)(struct device *dev);
 	void (*exit)(void);
 	bool use_pci;
+	enum x86_gpiochip_type gpiochip_type;
 };
 
 int x86_android_tablet_get_gpiod(const char *chip, int pin, const char *con_id,
@@ -106,6 +113,10 @@ int x86_android_tablet_get_gpiod(const char *chip, int pin, const char *con_id,
 				 struct gpio_desc **desc);
 int x86_acpi_irq_helper_get(const struct x86_acpi_irq_data *data);
 
+/* Software nodes representing GPIO chips used by various tablets */
+extern const struct software_node baytrail_gpiochip_nodes[];
+extern const struct software_node cherryview_gpiochip_nodes[];
+
 /*
  * Extern declarations of x86_dev_info structs so there can be a single
  * MODULE_DEVICE_TABLE(dmi, ...), while splitting the board descriptions.
-- 
2.51.0

[PATCH v4 02/20] platform/x86: x86-android-tablets: convert Wacom devices to GPIO references

[Hans de Goede]

From: Dmitry Torokhov <dmitry.torokhov@gmail.com>

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

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Tested-by: Hans de Goede <hansg@kernel.org>
Reviewed-by: Hans de Goede <hansg@kernel.org>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hansg@kernel.org>
---
 drivers/platform/x86/x86-android-tablets/lenovo.c | 10 +---------
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/drivers/platform/x86/x86-android-tablets/lenovo.c b/drivers/platform/x86/x86-android-tablets/lenovo.c
index 22fe76ef5b5a..f8d261d37284 100644
--- a/drivers/platform/x86/x86-android-tablets/lenovo.c
+++ b/drivers/platform/x86/x86-android-tablets/lenovo.c
@@ -75,6 +75,7 @@ static const struct software_node lenovo_yb1_x90_goodix_node = {
 static const struct property_entry lenovo_yb1_x90_wacom_props[] = {
 	PROPERTY_ENTRY_U32("hid-descr-addr", 0x0001),
 	PROPERTY_ENTRY_U32("post-reset-deassert-delay-ms", 150),
+	PROPERTY_ENTRY_GPIO("reset-gpios", &cherryview_gpiochip_nodes[0], 82, GPIO_ACTIVE_LOW),
 	{ }
 };
 
@@ -218,17 +219,8 @@ static struct gpiod_lookup_table lenovo_yb1_x90_hideep_gpios = {
 	},
 };
 
-static struct gpiod_lookup_table lenovo_yb1_x90_wacom_gpios = {
-	.dev_id = "i2c-wacom",
-	.table = {
-		GPIO_LOOKUP("INT33FF:00", 82, "reset", GPIO_ACTIVE_LOW),
-		{ }
-	},
-};
-
 static struct gpiod_lookup_table * const lenovo_yb1_x90_gpios[] = {
 	&lenovo_yb1_x90_hideep_gpios,
-	&lenovo_yb1_x90_wacom_gpios,
 	NULL
 };
 
-- 
2.51.0

[PATCH v4 03/20] platform/x86: x86-android-tablets: convert HiDeep devices to GPIO references

[Hans de Goede]

From: Dmitry Torokhov <dmitry.torokhov@gmail.com>

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

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Tested-by: Hans de Goede <hansg@kernel.org>
Reviewed-by: Hans de Goede <hansg@kernel.org>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hansg@kernel.org>
---
 .../platform/x86/x86-android-tablets/lenovo.c | 26 +++----------------
 1 file changed, 3 insertions(+), 23 deletions(-)

diff --git a/drivers/platform/x86/x86-android-tablets/lenovo.c b/drivers/platform/x86/x86-android-tablets/lenovo.c
index f8d261d37284..49388266201b 100644
--- a/drivers/platform/x86/x86-android-tablets/lenovo.c
+++ b/drivers/platform/x86/x86-android-tablets/lenovo.c
@@ -97,6 +97,7 @@ static const struct property_entry lenovo_yb1_x90_hideep_ts_props[] = {
 	PROPERTY_ENTRY_U32("touchscreen-size-y", 1920),
 	PROPERTY_ENTRY_U32("touchscreen-max-pressure", 16384),
 	PROPERTY_ENTRY_BOOL("hideep,force-native-protocol"),
+	PROPERTY_ENTRY_GPIO("reset-gpios", &cherryview_gpiochip_nodes[0], 7, GPIO_ACTIVE_LOW),
 	{ }
 };
 
@@ -211,19 +212,6 @@ static const struct x86_gpio_button lenovo_yb1_x90_lid __initconst = {
 	.pin = 19,
 };
 
-static struct gpiod_lookup_table lenovo_yb1_x90_hideep_gpios = {
-	.dev_id = "i2c-hideep_ts",
-	.table = {
-		GPIO_LOOKUP("INT33FF:00", 7, "reset", GPIO_ACTIVE_LOW),
-		{ }
-	},
-};
-
-static struct gpiod_lookup_table * const lenovo_yb1_x90_gpios[] = {
-	&lenovo_yb1_x90_hideep_gpios,
-	NULL
-};
-
 static int __init lenovo_yb1_x90_init(struct device *dev)
 {
 	/* Enable the regulators used by the touchscreens */
@@ -252,7 +240,6 @@ const struct x86_dev_info lenovo_yogabook_x90_info __initconst = {
 	.serdev_count = ARRAY_SIZE(lenovo_yb1_x90_serdevs),
 	.gpio_button = &lenovo_yb1_x90_lid,
 	.gpio_button_count = 1,
-	.gpiod_lookup_tables = lenovo_yb1_x90_gpios,
 	.gpiochip_type = X86_GPIOCHIP_CHERRYVIEW,
 	.init = lenovo_yb1_x90_init,
 };
@@ -819,6 +806,7 @@ static const struct property_entry lenovo_yt3_hideep_ts_props[] = {
 	PROPERTY_ENTRY_U32("touchscreen-size-x", 1600),
 	PROPERTY_ENTRY_U32("touchscreen-size-y", 2560),
 	PROPERTY_ENTRY_U32("touchscreen-max-pressure", 255),
+	PROPERTY_ENTRY_GPIO("reset-gpios", &cherryview_gpiochip_nodes[0], 7, GPIO_ACTIVE_LOW),
 	{ }
 };
 
@@ -1008,14 +996,6 @@ static int __init lenovo_yt3_init(struct device *dev)
 	return 0;
 }
 
-static struct gpiod_lookup_table lenovo_yt3_hideep_gpios = {
-	.dev_id = "i2c-hideep_ts",
-	.table = {
-		GPIO_LOOKUP("INT33FF:00", 7, "reset", GPIO_ACTIVE_LOW),
-		{ }
-	},
-};
-
 static struct gpiod_lookup_table lenovo_yt3_wm5102_gpios = {
 	.dev_id = "spi1.0",
 	.table = {
@@ -1028,7 +1008,6 @@ static struct gpiod_lookup_table lenovo_yt3_wm5102_gpios = {
 };
 
 static struct gpiod_lookup_table * const lenovo_yt3_gpios[] = {
-	&lenovo_yt3_hideep_gpios,
 	&lenovo_yt3_wm5102_gpios,
 	NULL
 };
@@ -1039,5 +1018,6 @@ const struct x86_dev_info lenovo_yt3_info __initconst = {
 	.spi_dev_info = lenovo_yt3_spi_devs,
 	.spi_dev_count = ARRAY_SIZE(lenovo_yt3_spi_devs),
 	.gpiod_lookup_tables = lenovo_yt3_gpios,
+	.gpiochip_type = X86_GPIOCHIP_CHERRYVIEW,
 	.init = lenovo_yt3_init,
 };
-- 
2.51.0

[PATCH v4 04/20] platform/x86: x86-android-tablets: convert Novatek devices to GPIO references

[Hans de Goede]

From: Dmitry Torokhov <dmitry.torokhov@gmail.com>

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

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Tested-by: Hans de Goede <hansg@kernel.org>
Reviewed-by: Hans de Goede <hansg@kernel.org>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hansg@kernel.org>
---
 .../platform/x86/x86-android-tablets/other.c  | 20 ++++++++++---------
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/platform/x86/x86-android-tablets/other.c b/drivers/platform/x86/x86-android-tablets/other.c
index e3907812c8bc..95c5001004a1 100644
--- a/drivers/platform/x86/x86-android-tablets/other.c
+++ b/drivers/platform/x86/x86-android-tablets/other.c
@@ -38,6 +38,15 @@ static const struct software_node acer_b1_750_bma250e_node = {
 	.properties = acer_b1_750_bma250e_props,
 };
 
+static const struct property_entry acer_b1_750_novatek_props[] = {
+	PROPERTY_ENTRY_GPIO("reset-gpios", &baytrail_gpiochip_nodes[1], 26, GPIO_ACTIVE_LOW),
+	{ }
+};
+
+static const struct software_node acer_b1_750_novatek_node = {
+	.properties = acer_b1_750_novatek_props,
+};
+
 static const struct x86_i2c_client_info acer_b1_750_i2c_clients[] __initconst = {
 	{
 		/* Novatek NVT-ts touchscreen */
@@ -45,6 +54,7 @@ static const struct x86_i2c_client_info acer_b1_750_i2c_clients[] __initconst =
 			.type = "nt11205-ts",
 			.addr = 0x34,
 			.dev_name = "NVT-ts",
+			.swnode = &acer_b1_750_novatek_node,
 		},
 		.adapter_path = "\\_SB_.I2C4",
 		.irq_data = {
@@ -74,16 +84,7 @@ static const struct x86_i2c_client_info acer_b1_750_i2c_clients[] __initconst =
 	},
 };
 
-static struct gpiod_lookup_table acer_b1_750_nvt_ts_gpios = {
-	.dev_id = "i2c-NVT-ts",
-	.table = {
-		GPIO_LOOKUP("INT33FC:01", 26, "reset", GPIO_ACTIVE_LOW),
-		{ }
-	},
-};
-
 static struct gpiod_lookup_table * const acer_b1_750_gpios[] = {
-	&acer_b1_750_nvt_ts_gpios,
 	&int3496_reference_gpios,
 	NULL
 };
@@ -94,6 +95,7 @@ const struct x86_dev_info acer_b1_750_info __initconst = {
 	.pdev_info = int3496_pdevs,
 	.pdev_count = 1,
 	.gpiod_lookup_tables = acer_b1_750_gpios,
+	.gpiochip_type = X86_GPIOCHIP_BAYTRAIL,
 };
 
 /*
-- 
2.51.0

[PATCH v4 05/20] platform/x86: x86-android-tablets: convert EDT devices to GPIO references

[Hans de Goede]

From: Dmitry Torokhov <dmitry.torokhov@gmail.com>

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

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Tested-by: Hans de Goede <hansg@kernel.org>
Reviewed-by: Hans de Goede <hansg@kernel.org>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hansg@kernel.org>
---
 .../platform/x86/x86-android-tablets/other.c  | 28 +++++++++----------
 1 file changed, 13 insertions(+), 15 deletions(-)

diff --git a/drivers/platform/x86/x86-android-tablets/other.c b/drivers/platform/x86/x86-android-tablets/other.c
index 95c5001004a1..0f3cc0ea877e 100644
--- a/drivers/platform/x86/x86-android-tablets/other.c
+++ b/drivers/platform/x86/x86-android-tablets/other.c
@@ -436,6 +436,17 @@ static const struct software_node nextbook_ares8a_accel_node = {
 	.properties = nextbook_ares8a_accel_props,
 };
 
+static const struct property_entry nextbook_ares8a_ft5416_props[] = {
+	PROPERTY_ENTRY_U32("touchscreen-size-x", 800),
+	PROPERTY_ENTRY_U32("touchscreen-size-y", 1280),
+	PROPERTY_ENTRY_GPIO("reset-gpios", &cherryview_gpiochip_nodes[1], 25, GPIO_ACTIVE_LOW),
+	{ }
+};
+
+static const struct software_node nextbook_ares8a_ft5416_node = {
+	.properties = nextbook_ares8a_ft5416_props,
+};
+
 static const struct x86_i2c_client_info nextbook_ares8a_i2c_clients[] __initconst = {
 	{
 		/* Freescale MMA8653FC accelerometer */
@@ -452,7 +463,7 @@ static const struct x86_i2c_client_info nextbook_ares8a_i2c_clients[] __initcons
 			.type = "edt-ft5x06",
 			.addr = 0x38,
 			.dev_name = "ft5416",
-			.swnode = &nextbook_ares8_touchscreen_node,
+			.swnode = &nextbook_ares8a_ft5416_node,
 		},
 		.adapter_path = "\\_SB_.PCI0.I2C6",
 		.irq_data = {
@@ -466,23 +477,10 @@ static const struct x86_i2c_client_info nextbook_ares8a_i2c_clients[] __initcons
 	},
 };
 
-static struct gpiod_lookup_table nextbook_ares8a_ft5416_gpios = {
-	.dev_id = "i2c-ft5416",
-	.table = {
-		GPIO_LOOKUP("INT33FF:01", 25, "reset", GPIO_ACTIVE_LOW),
-		{ }
-	},
-};
-
-static struct gpiod_lookup_table * const nextbook_ares8a_gpios[] = {
-	&nextbook_ares8a_ft5416_gpios,
-	NULL
-};
-
 const struct x86_dev_info nextbook_ares8a_info __initconst = {
 	.i2c_client_info = nextbook_ares8a_i2c_clients,
 	.i2c_client_count = ARRAY_SIZE(nextbook_ares8a_i2c_clients),
-	.gpiod_lookup_tables = nextbook_ares8a_gpios,
+	.gpiochip_type = X86_GPIOCHIP_CHERRYVIEW,
 };
 
 /*
-- 
2.51.0

[PATCH v4 06/20] platform/x86: x86-android-tablets: convert int3496 devices to GPIO references

[Hans de Goede]

From: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Now that gpiolib supports software nodes to describe GPIOs, switch the
driver away from using GPIO lookup tables for int3496 devices to using
PROPERTY_ENTRY_GPIO().

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Tested-by: Hans de Goede <hansg@kernel.org>
Reviewed-by: Hans de Goede <hansg@kernel.org>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hansg@kernel.org>
---
Changes in v3:
- Leave int3496_pdevs[] in shared-psy-info.c instead of moving it to
  other.c, it will also be used in the upcoming acer.c so it needs to
  stay shared
---
 .../platform/x86/x86-android-tablets/asus.c   | 37 ++++++++-----------
 .../platform/x86/x86-android-tablets/lenovo.c | 24 +++++++-----
 .../platform/x86/x86-android-tablets/other.c  | 13 +------
 .../x86/x86-android-tablets/shared-psy-info.c | 22 +++++------
 .../x86/x86-android-tablets/shared-psy-info.h |  2 -
 5 files changed, 43 insertions(+), 55 deletions(-)

diff --git a/drivers/platform/x86/x86-android-tablets/asus.c b/drivers/platform/x86/x86-android-tablets/asus.c
index 6c4468f4004b..ce581d161551 100644
--- a/drivers/platform/x86/x86-android-tablets/asus.c
+++ b/drivers/platform/x86/x86-android-tablets/asus.c
@@ -17,11 +17,17 @@
 #include "x86-android-tablets.h"
 
 /* Asus ME176C and TF103C tablets shared data */
-static struct gpiod_lookup_table int3496_gpo2_pin22_gpios = {
-	.dev_id = "intel-int3496",
-	.table = {
-		GPIO_LOOKUP("INT33FC:02", 22, "id", GPIO_ACTIVE_HIGH),
-		{ }
+static const struct property_entry asus_me176c_tf103c_int3496_props[] __initconst = {
+	PROPERTY_ENTRY_GPIO("id-gpios", &baytrail_gpiochip_nodes[2], 22, GPIO_ACTIVE_HIGH),
+	{ }
+};
+
+static const struct platform_device_info asus_me176c_tf103c_pdevs[] __initconst = {
+	{
+		/* For micro USB ID pin handling */
+		.name = "intel-int3496",
+		.id = PLATFORM_DEVID_NONE,
+		.properties = asus_me176c_tf103c_int3496_props,
 	},
 };
 
@@ -164,21 +170,15 @@ static const struct x86_serdev_info asus_me176c_serdevs[] __initconst = {
 	},
 };
 
-static struct gpiod_lookup_table * const asus_me176c_gpios[] = {
-	&int3496_gpo2_pin22_gpios,
-	NULL
-};
-
 const struct x86_dev_info asus_me176c_info __initconst = {
 	.i2c_client_info = asus_me176c_i2c_clients,
 	.i2c_client_count = ARRAY_SIZE(asus_me176c_i2c_clients),
-	.pdev_info = int3496_pdevs,
-	.pdev_count = 1,
+	.pdev_info = asus_me176c_tf103c_pdevs,
+	.pdev_count = ARRAY_SIZE(asus_me176c_tf103c_pdevs),
 	.serdev_info = asus_me176c_serdevs,
 	.serdev_count = ARRAY_SIZE(asus_me176c_serdevs),
 	.gpio_button = &asus_me176c_tf103c_lid,
 	.gpio_button_count = 1,
-	.gpiod_lookup_tables = asus_me176c_gpios,
 	.bat_swnode = &generic_lipo_hv_4v35_battery_node,
 	.modules = bq24190_modules,
 	.gpiochip_type = X86_GPIOCHIP_BAYTRAIL,
@@ -296,19 +296,14 @@ static const struct x86_i2c_client_info asus_tf103c_i2c_clients[] __initconst =
 	},
 };
 
-static struct gpiod_lookup_table * const asus_tf103c_gpios[] = {
-	&int3496_gpo2_pin22_gpios,
-	NULL
-};
-
 const struct x86_dev_info asus_tf103c_info __initconst = {
 	.i2c_client_info = asus_tf103c_i2c_clients,
 	.i2c_client_count = ARRAY_SIZE(asus_tf103c_i2c_clients),
-	.pdev_info = int3496_pdevs,
-	.pdev_count = 1,
+	.pdev_info = asus_me176c_tf103c_pdevs,
+	.pdev_count = ARRAY_SIZE(asus_me176c_tf103c_pdevs),
 	.gpio_button = &asus_me176c_tf103c_lid,
 	.gpio_button_count = 1,
-	.gpiod_lookup_tables = asus_tf103c_gpios,
 	.bat_swnode = &generic_lipo_4v2_battery_node,
 	.modules = bq24190_modules,
+	.gpiochip_type = X86_GPIOCHIP_BAYTRAIL,
 };
diff --git a/drivers/platform/x86/x86-android-tablets/lenovo.c b/drivers/platform/x86/x86-android-tablets/lenovo.c
index 49388266201b..db6337671357 100644
--- a/drivers/platform/x86/x86-android-tablets/lenovo.c
+++ b/drivers/platform/x86/x86-android-tablets/lenovo.c
@@ -366,12 +366,18 @@ static struct x86_i2c_client_info lenovo_yoga_tab2_830_1050_i2c_clients[] __init
 	},
 };
 
-static struct gpiod_lookup_table lenovo_yoga_tab2_830_1050_int3496_gpios = {
-	.dev_id = "intel-int3496",
-	.table = {
-		GPIO_LOOKUP("INT33FC:02", 1, "mux", GPIO_ACTIVE_LOW),
-		GPIO_LOOKUP("INT33FC:02", 24, "id", GPIO_ACTIVE_HIGH),
-		{ }
+static const struct property_entry lenovo_yoga_tab2_830_1050_int3496_props[] __initconst = {
+	PROPERTY_ENTRY_GPIO("mux-gpios", &baytrail_gpiochip_nodes[2], 1, GPIO_ACTIVE_LOW),
+	PROPERTY_ENTRY_GPIO("id-gpios", &baytrail_gpiochip_nodes[2], 24, GPIO_ACTIVE_HIGH),
+	{ }
+};
+
+static const struct platform_device_info lenovo_yoga_tab2_830_1050_pdevs[] __initconst = {
+	{
+		/* For micro USB ID pin handling */
+		.name = "intel-int3496",
+		.id = PLATFORM_DEVID_NONE,
+		.properties = lenovo_yoga_tab2_830_1050_int3496_props,
 	},
 };
 
@@ -389,7 +395,6 @@ static struct gpiod_lookup_table lenovo_yoga_tab2_830_1050_codec_gpios = {
 };
 
 static struct gpiod_lookup_table * const lenovo_yoga_tab2_830_1050_gpios[] = {
-	&lenovo_yoga_tab2_830_1050_int3496_gpios,
 	&lenovo_yoga_tab2_830_1050_codec_gpios,
 	NULL
 };
@@ -400,13 +405,14 @@ static void lenovo_yoga_tab2_830_1050_exit(void);
 const struct x86_dev_info lenovo_yoga_tab2_830_1050_info __initconst = {
 	.i2c_client_info = lenovo_yoga_tab2_830_1050_i2c_clients,
 	.i2c_client_count = ARRAY_SIZE(lenovo_yoga_tab2_830_1050_i2c_clients),
-	.pdev_info = int3496_pdevs,
-	.pdev_count = 1,
+	.pdev_info = lenovo_yoga_tab2_830_1050_pdevs,
+	.pdev_count = ARRAY_SIZE(lenovo_yoga_tab2_830_1050_pdevs),
 	.gpio_button = &lenovo_yoga_tab2_830_1050_lid,
 	.gpio_button_count = 1,
 	.gpiod_lookup_tables = lenovo_yoga_tab2_830_1050_gpios,
 	.bat_swnode = &generic_lipo_hv_4v35_battery_node,
 	.modules = bq24190_modules,
+	.gpiochip_type = X86_GPIOCHIP_BAYTRAIL,
 	.init = lenovo_yoga_tab2_830_1050_init,
 	.exit = lenovo_yoga_tab2_830_1050_exit,
 };
diff --git a/drivers/platform/x86/x86-android-tablets/other.c b/drivers/platform/x86/x86-android-tablets/other.c
index 0f3cc0ea877e..2f12b68080ba 100644
--- a/drivers/platform/x86/x86-android-tablets/other.c
+++ b/drivers/platform/x86/x86-android-tablets/other.c
@@ -84,17 +84,11 @@ static const struct x86_i2c_client_info acer_b1_750_i2c_clients[] __initconst =
 	},
 };
 
-static struct gpiod_lookup_table * const acer_b1_750_gpios[] = {
-	&int3496_reference_gpios,
-	NULL
-};
-
 const struct x86_dev_info acer_b1_750_info __initconst = {
 	.i2c_client_info = acer_b1_750_i2c_clients,
 	.i2c_client_count = ARRAY_SIZE(acer_b1_750_i2c_clients),
 	.pdev_info = int3496_pdevs,
 	.pdev_count = 1,
-	.gpiod_lookup_tables = acer_b1_750_gpios,
 	.gpiochip_type = X86_GPIOCHIP_BAYTRAIL,
 };
 
@@ -407,17 +401,12 @@ static const struct x86_i2c_client_info nextbook_ares8_i2c_clients[] __initconst
 	},
 };
 
-static struct gpiod_lookup_table * const nextbook_ares8_gpios[] = {
-	&int3496_reference_gpios,
-	NULL
-};
-
 const struct x86_dev_info nextbook_ares8_info __initconst = {
 	.i2c_client_info = nextbook_ares8_i2c_clients,
 	.i2c_client_count = ARRAY_SIZE(nextbook_ares8_i2c_clients),
 	.pdev_info = int3496_pdevs,
 	.pdev_count = 1,
-	.gpiod_lookup_tables = nextbook_ares8_gpios,
+	.gpiochip_type = X86_GPIOCHIP_BAYTRAIL,
 };
 
 /* Nextbook Ares 8A (CHT) tablets have an Android factory image with everything hardcoded */
diff --git a/drivers/platform/x86/x86-android-tablets/shared-psy-info.c b/drivers/platform/x86/x86-android-tablets/shared-psy-info.c
index fe34cedb6257..6ebe282bda6e 100644
--- a/drivers/platform/x86/x86-android-tablets/shared-psy-info.c
+++ b/drivers/platform/x86/x86-android-tablets/shared-psy-info.c
@@ -9,12 +9,14 @@
  */
 
 #include <linux/gpio/machine.h>
+#include <linux/gpio/property.h>
 #include <linux/platform_device.h>
 #include <linux/power/bq24190_charger.h>
 #include <linux/property.h>
 #include <linux/regulator/machine.h>
 
 #include "shared-psy-info.h"
+#include "x86-android-tablets.h"
 
 /* Generic / shared charger / battery settings */
 const char * const tusb1211_chg_det_psy[] = { "tusb1211-charger-detect" };
@@ -156,21 +158,19 @@ const char * const bq24190_modules[] __initconst = {
 	NULL
 };
 
-/* Generic platform device array and GPIO lookup table for micro USB ID pin handling */
+static const struct property_entry int3496_reference_props[] __initconst = {
+	PROPERTY_ENTRY_GPIO("vbus-gpios", &baytrail_gpiochip_nodes[1], 15, GPIO_ACTIVE_HIGH),
+	PROPERTY_ENTRY_GPIO("mux-gpios", &baytrail_gpiochip_nodes[2], 1, GPIO_ACTIVE_HIGH),
+	PROPERTY_ENTRY_GPIO("id-gpios", &baytrail_gpiochip_nodes[2], 18, GPIO_ACTIVE_HIGH),
+	{ }
+};
+
+/* Generic pdevs array and gpio-lookups for micro USB ID pin handling */
 const struct platform_device_info int3496_pdevs[] __initconst = {
 	{
 		/* For micro USB ID pin handling */
 		.name = "intel-int3496",
 		.id = PLATFORM_DEVID_NONE,
-	},
-};
-
-struct gpiod_lookup_table int3496_reference_gpios = {
-	.dev_id = "intel-int3496",
-	.table = {
-		GPIO_LOOKUP("INT33FC:01", 15, "vbus", GPIO_ACTIVE_HIGH),
-		GPIO_LOOKUP("INT33FC:02", 1, "mux", GPIO_ACTIVE_HIGH),
-		GPIO_LOOKUP("INT33FC:02", 18, "id", GPIO_ACTIVE_HIGH),
-		{ }
+		.properties = int3496_reference_props,
 	},
 };
diff --git a/drivers/platform/x86/x86-android-tablets/shared-psy-info.h b/drivers/platform/x86/x86-android-tablets/shared-psy-info.h
index bcf9845ad275..b9cbc291aa4d 100644
--- a/drivers/platform/x86/x86-android-tablets/shared-psy-info.h
+++ b/drivers/platform/x86/x86-android-tablets/shared-psy-info.h
@@ -11,7 +11,6 @@
 #define __PDX86_SHARED_PSY_INFO_H
 
 struct bq24190_platform_data;
-struct gpiod_lookup_table;
 struct platform_device_info;
 struct software_node;
 
@@ -28,6 +27,5 @@ extern struct bq24190_platform_data bq24190_pdata;
 extern const char * const bq24190_modules[];
 
 extern const struct platform_device_info int3496_pdevs[];
-extern struct gpiod_lookup_table int3496_reference_gpios;
 
 #endif
-- 
2.51.0

[PATCH v4 07/20] platform/x86: x86-android-tablets: convert wm1502 devices to GPIO references

[Hans de Goede]

From: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Now that gpiolib supports software nodes to describe GPIOs, switch the
driver away from using GPIO lookup tables for wm1502 devices to using
PROPERTY_ENTRY_GPIO().

Adding a swnode to the yt3 spi device changes the name of the SPI/codec
device and the sound/soc/intel/boards/bytcr_wm5102.c machine driver looks
up the code by name, update the machine driver to use the new name.

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Tested-by: Hans de Goede <hansg@kernel.org>
Reviewed-by: Hans de Goede <hansg@kernel.org>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hansg@kernel.org>
---
Changes in v3:
- Add pinctrl_put() to error-exit paths in lenovo_yoga_tab2_830_1050_init_codec()
- Share arizona_gpiochip_node between yoga tablet2 and yoga tab3 settings
- Give lenovo_yt3_wm5102 swnode a name so that the codec SPI-dev gets a stable name
- Adjust sound/soc/intel/boards/bytcr_wm5102.c for the new SPI/codec dev-name
---
 .../platform/x86/x86-android-tablets/lenovo.c | 107 ++++++++++++------
 sound/soc/intel/boards/bytcr_wm5102.c         |   2 +-
 2 files changed, 76 insertions(+), 33 deletions(-)

diff --git a/drivers/platform/x86/x86-android-tablets/lenovo.c b/drivers/platform/x86/x86-android-tablets/lenovo.c
index db6337671357..aaa946bb1e7c 100644
--- a/drivers/platform/x86/x86-android-tablets/lenovo.c
+++ b/drivers/platform/x86/x86-android-tablets/lenovo.c
@@ -60,6 +60,14 @@ static struct lp855x_platform_data lenovo_lp8557_reg_only_pdata = {
 	.initial_brightness = 128,
 };
 
+static const struct software_node arizona_gpiochip_node = {
+	.name = "arizona",
+};
+
+static const struct software_node crystalcove_gpiochip_node = {
+	.name = "gpio_crystalcove",
+};
+
 /* Lenovo Yoga Book X90F / X90L's Android factory image has everything hardcoded */
 
 static const struct property_entry lenovo_yb1_x90_goodix_props[] = {
@@ -383,19 +391,26 @@ static const struct platform_device_info lenovo_yoga_tab2_830_1050_pdevs[] __ini
 
 #define LENOVO_YOGA_TAB2_830_1050_CODEC_NAME "spi-10WM5102:00"
 
-static struct gpiod_lookup_table lenovo_yoga_tab2_830_1050_codec_gpios = {
-	.dev_id = LENOVO_YOGA_TAB2_830_1050_CODEC_NAME,
-	.table = {
-		GPIO_LOOKUP("gpio_crystalcove", 3, "reset", GPIO_ACTIVE_HIGH),
-		GPIO_LOOKUP("INT33FC:01", 23, "wlf,ldoena", GPIO_ACTIVE_HIGH),
-		GPIO_LOOKUP("arizona", 2, "wlf,spkvdd-ena", GPIO_ACTIVE_HIGH),
-		GPIO_LOOKUP("arizona", 4, "wlf,micd-pol", GPIO_ACTIVE_LOW),
-		{ }
-	},
+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),
+	{ }
 };
 
-static struct gpiod_lookup_table * const lenovo_yoga_tab2_830_1050_gpios[] = {
-	&lenovo_yoga_tab2_830_1050_codec_gpios,
+static const struct software_node lenovo_yoga_tab2_830_1050_wm5102 = {
+	.properties = lenovo_yoga_tab2_830_1050_wm1502_props,
+};
+
+static const struct software_node *lenovo_yoga_tab2_830_1050_swnodes[] = {
+	&crystalcove_gpiochip_node,
+	&arizona_gpiochip_node,
+	&lenovo_yoga_tab2_830_1050_wm5102,
 	NULL
 };
 
@@ -409,7 +424,6 @@ const struct x86_dev_info lenovo_yoga_tab2_830_1050_info __initconst = {
 	.pdev_count = ARRAY_SIZE(lenovo_yoga_tab2_830_1050_pdevs),
 	.gpio_button = &lenovo_yoga_tab2_830_1050_lid,
 	.gpio_button_count = 1,
-	.gpiod_lookup_tables = lenovo_yoga_tab2_830_1050_gpios,
 	.bat_swnode = &generic_lipo_hv_4v35_battery_node,
 	.modules = bq24190_modules,
 	.gpiochip_type = X86_GPIOCHIP_BAYTRAIL,
@@ -469,6 +483,7 @@ static const struct pinctrl_map lenovo_yoga_tab2_830_1050_codec_pinctrl_map =
 	PIN_MAP_MUX_GROUP(LENOVO_YOGA_TAB2_830_1050_CODEC_NAME, "codec_32khz_clk",
 			  "INT33FC:02", "pmu_clk2_grp", "pmu_clk");
 
+static struct device *lenovo_yoga_tab2_830_1050_codec_dev;
 static struct pinctrl *lenovo_yoga_tab2_830_1050_codec_pinctrl;
 static struct sys_off_handler *lenovo_yoga_tab2_830_1050_sys_off_handler;
 
@@ -495,12 +510,26 @@ static int __init lenovo_yoga_tab2_830_1050_init_codec(void)
 		goto err_unregister_mappings;
 	}
 
-	/* We're done with the codec_dev now */
-	put_device(codec_dev);
+	ret = software_node_register_node_group(lenovo_yoga_tab2_830_1050_swnodes);
+	if (ret) {
+		ret = dev_err_probe(codec_dev, ret, "registering software nodes\n");
+		goto err_put_pinctrl;
+	}
 
+	ret = device_add_software_node(codec_dev, &lenovo_yoga_tab2_830_1050_wm5102);
+	if (ret) {
+		ret = dev_err_probe(codec_dev, ret, "adding software node\n");
+		goto err_unregister_swnodes;
+	}
+
+	lenovo_yoga_tab2_830_1050_codec_dev = codec_dev;
 	lenovo_yoga_tab2_830_1050_codec_pinctrl = pinctrl;
 	return 0;
 
+err_unregister_swnodes:
+	software_node_unregister_node_group(lenovo_yoga_tab2_830_1050_swnodes);
+err_put_pinctrl:
+	pinctrl_put(lenovo_yoga_tab2_830_1050_codec_pinctrl);
 err_unregister_mappings:
 	pinctrl_unregister_mappings(&lenovo_yoga_tab2_830_1050_codec_pinctrl_map);
 err_put_device:
@@ -548,6 +577,12 @@ static void lenovo_yoga_tab2_830_1050_exit(void)
 {
 	unregister_sys_off_handler(lenovo_yoga_tab2_830_1050_sys_off_handler);
 
+	if (lenovo_yoga_tab2_830_1050_codec_dev) {
+		device_remove_software_node(lenovo_yoga_tab2_830_1050_codec_dev);
+		put_device(lenovo_yoga_tab2_830_1050_codec_dev);
+		software_node_unregister_node_group(lenovo_yoga_tab2_830_1050_swnodes);
+	}
+
 	if (lenovo_yoga_tab2_830_1050_codec_pinctrl) {
 		pinctrl_put(lenovo_yoga_tab2_830_1050_codec_pinctrl);
 		pinctrl_unregister_mappings(&lenovo_yoga_tab2_830_1050_codec_pinctrl_map);
@@ -750,7 +785,6 @@ static struct gpiod_lookup_table lenovo_yoga_tab2_1380_fc_gpios = {
 };
 
 static struct gpiod_lookup_table * const lenovo_yoga_tab2_1380_gpios[] = {
-	&lenovo_yoga_tab2_830_1050_codec_gpios,
 	&lenovo_yoga_tab2_1380_fc_gpios,
 	NULL
 };
@@ -947,12 +981,34 @@ static struct arizona_pdata lenovo_yt3_wm5102_pdata = {
 	},
 };
 
+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),
+	{ }
+};
+
+static const struct software_node lenovo_yt3_wm5102 = {
+	.properties = lenovo_yt3_wm1502_props,
+	.name = "wm5102",
+};
+
+static const struct software_node *lenovo_yt3_swnodes[] = {
+	&arizona_gpiochip_node,
+	&lenovo_yt3_wm5102,
+	NULL
+};
+
 static const struct x86_spi_dev_info lenovo_yt3_spi_devs[] __initconst = {
 	{
 		/* WM5102 codec */
 		.board_info = {
 			.modalias = "wm5102",
 			.platform_data = &lenovo_yt3_wm5102_pdata,
+			.swnode = &lenovo_yt3_wm5102,
 			.max_speed_hz = 5000000,
 		},
 		.ctrl_path = "\\_SB_.PCI0.SPI1",
@@ -999,31 +1055,18 @@ static int __init lenovo_yt3_init(struct device *dev)
 	intel_soc_pmic_exec_mipi_pmic_seq_element(0x6e, 0x9b, 0x02, 0xff);
 	intel_soc_pmic_exec_mipi_pmic_seq_element(0x6e, 0xa0, 0x02, 0xff);
 
+	ret = software_node_register_node_group(lenovo_yt3_swnodes);
+	if (ret)
+		return dev_err_probe(dev, ret, "registering software nodes\n");
+
 	return 0;
 }
 
-static struct gpiod_lookup_table lenovo_yt3_wm5102_gpios = {
-	.dev_id = "spi1.0",
-	.table = {
-		GPIO_LOOKUP("INT33FF:00", 75, "wlf,spkvdd-ena", GPIO_ACTIVE_HIGH),
-		GPIO_LOOKUP("INT33FF:00", 81, "wlf,ldoena", GPIO_ACTIVE_HIGH),
-		GPIO_LOOKUP("INT33FF:00", 82, "reset", GPIO_ACTIVE_HIGH),
-		GPIO_LOOKUP("arizona", 2, "wlf,micd-pol", GPIO_ACTIVE_HIGH),
-		{ }
-	},
-};
-
-static struct gpiod_lookup_table * const lenovo_yt3_gpios[] = {
-	&lenovo_yt3_wm5102_gpios,
-	NULL
-};
-
 const struct x86_dev_info lenovo_yt3_info __initconst = {
 	.i2c_client_info = lenovo_yt3_i2c_clients,
 	.i2c_client_count = ARRAY_SIZE(lenovo_yt3_i2c_clients),
 	.spi_dev_info = lenovo_yt3_spi_devs,
 	.spi_dev_count = ARRAY_SIZE(lenovo_yt3_spi_devs),
-	.gpiod_lookup_tables = lenovo_yt3_gpios,
 	.gpiochip_type = X86_GPIOCHIP_CHERRYVIEW,
 	.init = lenovo_yt3_init,
 };
diff --git a/sound/soc/intel/boards/bytcr_wm5102.c b/sound/soc/intel/boards/bytcr_wm5102.c
index a6dfbcfdf74e..da0fdb8d677d 100644
--- a/sound/soc/intel/boards/bytcr_wm5102.c
+++ b/sound/soc/intel/boards/bytcr_wm5102.c
@@ -552,7 +552,7 @@ static int snd_byt_wm5102_mc_probe(struct platform_device *pdev)
 		acpi_dev_put(adev);
 	} else {
 		/* Special case for when the codec is missing from the DSTD */
-		strscpy(codec_name, "spi1.0", sizeof(codec_name));
+		strscpy(codec_name, "spi-wm5102", sizeof(codec_name));
 	}
 
 	codec_dev = bus_find_device_by_name(&spi_bus_type, NULL, codec_name);
-- 
2.51.0

[PATCH v4 08/20] platform/x86: x86-android-tablets: convert HID-I2C devices to GPIO references

[Hans de Goede]

From: Dmitry Torokhov <dmitry.torokhov@gmail.com>

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

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Tested-by: Hans de Goede <hansg@kernel.org>
Reviewed-by: Hans de Goede <hansg@kernel.org>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hansg@kernel.org>
---
 .../platform/x86/x86-android-tablets/other.c  | 32 +++----------------
 1 file changed, 4 insertions(+), 28 deletions(-)

diff --git a/drivers/platform/x86/x86-android-tablets/other.c b/drivers/platform/x86/x86-android-tablets/other.c
index 2f12b68080ba..5309831243b3 100644
--- a/drivers/platform/x86/x86-android-tablets/other.c
+++ b/drivers/platform/x86/x86-android-tablets/other.c
@@ -571,6 +571,7 @@ const struct x86_dev_info whitelabel_tm800a550l_info __initconst = {
 static const struct property_entry vexia_edu_atla10_5v_touchscreen_props[] = {
 	PROPERTY_ENTRY_U32("hid-descr-addr", 0x0000),
 	PROPERTY_ENTRY_U32("post-reset-deassert-delay-ms", 120),
+	PROPERTY_ENTRY_GPIO("reset-gpios", &baytrail_gpiochip_nodes[1], 26, GPIO_ACTIVE_LOW),
 	{ }
 };
 
@@ -605,23 +606,10 @@ static const struct x86_i2c_client_info vexia_edu_atla10_5v_i2c_clients[] __init
 	}
 };
 
-static struct gpiod_lookup_table vexia_edu_atla10_5v_ft5416_gpios = {
-	.dev_id = "i2c-FTSC1000",
-	.table = {
-		GPIO_LOOKUP("INT33FC:01", 26, "reset", GPIO_ACTIVE_LOW),
-		{ }
-	},
-};
-
-static struct gpiod_lookup_table * const vexia_edu_atla10_5v_gpios[] = {
-	&vexia_edu_atla10_5v_ft5416_gpios,
-	NULL
-};
-
 const struct x86_dev_info vexia_edu_atla10_5v_info __initconst = {
 	.i2c_client_info = vexia_edu_atla10_5v_i2c_clients,
 	.i2c_client_count = ARRAY_SIZE(vexia_edu_atla10_5v_i2c_clients),
-	.gpiod_lookup_tables = vexia_edu_atla10_5v_gpios,
+	.gpiochip_type = X86_GPIOCHIP_BAYTRAIL,
 };
 
 /*
@@ -657,6 +645,7 @@ static const struct software_node vexia_edu_atla10_9v_accel_node = {
 static const struct property_entry vexia_edu_atla10_9v_touchscreen_props[] = {
 	PROPERTY_ENTRY_U32("hid-descr-addr", 0x0000),
 	PROPERTY_ENTRY_U32("post-reset-deassert-delay-ms", 120),
+	PROPERTY_ENTRY_GPIO("reset-gpios", &baytrail_gpiochip_nodes[0], 60, GPIO_ACTIVE_LOW),
 	{ }
 };
 
@@ -749,19 +738,6 @@ static const struct x86_serdev_info vexia_edu_atla10_9v_serdevs[] __initconst =
 	},
 };
 
-static struct gpiod_lookup_table vexia_edu_atla10_9v_ft5416_gpios = {
-	.dev_id = "i2c-FTSC1000",
-	.table = {
-		GPIO_LOOKUP("INT33FC:00", 60, "reset", GPIO_ACTIVE_LOW),
-		{ }
-	},
-};
-
-static struct gpiod_lookup_table * const vexia_edu_atla10_9v_gpios[] = {
-	&vexia_edu_atla10_9v_ft5416_gpios,
-	NULL
-};
-
 static int __init vexia_edu_atla10_9v_init(struct device *dev)
 {
 	struct pci_dev *pdev;
@@ -791,9 +767,9 @@ const struct x86_dev_info vexia_edu_atla10_9v_info __initconst = {
 	.i2c_client_count = ARRAY_SIZE(vexia_edu_atla10_9v_i2c_clients),
 	.serdev_info = vexia_edu_atla10_9v_serdevs,
 	.serdev_count = ARRAY_SIZE(vexia_edu_atla10_9v_serdevs),
-	.gpiod_lookup_tables = vexia_edu_atla10_9v_gpios,
 	.init = vexia_edu_atla10_9v_init,
 	.use_pci = true,
+	.gpiochip_type = X86_GPIOCHIP_BAYTRAIL,
 };
 
 /*
-- 
2.51.0

[PATCH v4 09/20] platform/x86: x86-android-tablets: convert Yoga Tab2 fast charger to GPIO references

[Hans de Goede]

From: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Now that gpiolib supports software nodes to describe GPIOs, switch the
driver away from using GPIO lookup tables for the fast charger device
to using PROPERTY_ENTRY_GPIO().

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Tested-by: Hans de Goede <hansg@kernel.org>
Reviewed-by: Hans de Goede <hansg@kernel.org>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hansg@kernel.org>
---
Changes in v4:
- Split propagating the platform-dev fwnode to the serdev and
  the fwnode_handle_get() call on the serdev fwnode into 2 separate
  statements

Changes in v3:
- Make yoga-tab2-pro-1380-fastcharger.c propagate the fwnode set on
  the platform-device to the serdev it creates
- Mark lenovo_yoga_tab2_1380_fc_props[] __initconst
---
 .../lenovo/yoga-tab2-pro-1380-fastcharger.c   |  5 ++++
 .../platform/x86/x86-android-tablets/lenovo.c | 23 +++++++------------
 2 files changed, 13 insertions(+), 15 deletions(-)

diff --git a/drivers/platform/x86/lenovo/yoga-tab2-pro-1380-fastcharger.c b/drivers/platform/x86/lenovo/yoga-tab2-pro-1380-fastcharger.c
index 1b33c977f6d7..8551ab4d2c7d 100644
--- a/drivers/platform/x86/lenovo/yoga-tab2-pro-1380-fastcharger.c
+++ b/drivers/platform/x86/lenovo/yoga-tab2-pro-1380-fastcharger.c
@@ -255,6 +255,11 @@ static int yt2_1380_fc_pdev_probe(struct platform_device *pdev)
 	if (!serdev)
 		return -ENOMEM;
 
+	/* Propagate pdev-fwnode set by x86-android-tablets to serdev */
+	device_set_node(&serdev->dev, dev_fwnode(&pdev->dev));
+	/* The fwnode is a managed node, so it will be auto-put on serdev_device_put() */
+	fwnode_handle_get(dev_fwnode(&serdev->dev));
+
 	ret = serdev_device_add(serdev);
 	if (ret) {
 		serdev_device_put(serdev);
diff --git a/drivers/platform/x86/x86-android-tablets/lenovo.c b/drivers/platform/x86/x86-android-tablets/lenovo.c
index aaa946bb1e7c..7d1808a3437f 100644
--- a/drivers/platform/x86/x86-android-tablets/lenovo.c
+++ b/drivers/platform/x86/x86-android-tablets/lenovo.c
@@ -741,11 +741,18 @@ static const struct x86_i2c_client_info lenovo_yoga_tab2_1380_i2c_clients[] __in
 	}
 };
 
+static const struct property_entry lenovo_yoga_tab2_1380_fc_props[] __initconst = {
+	PROPERTY_ENTRY_GPIO("uart3_txd-gpios", &baytrail_gpiochip_nodes[0], 57, GPIO_ACTIVE_HIGH),
+	PROPERTY_ENTRY_GPIO("uart3_rxd-gpios", &baytrail_gpiochip_nodes[0], 61, GPIO_ACTIVE_HIGH),
+	{ }
+};
+
 static const struct platform_device_info lenovo_yoga_tab2_1380_pdevs[] __initconst = {
 	{
 		/* For the Tablet 2 Pro 1380's custom fast charging driver */
 		.name = "lenovo-yoga-tab2-pro-1380-fastcharger",
 		.id = PLATFORM_DEVID_NONE,
+		.properties = lenovo_yoga_tab2_1380_fc_props,
 	},
 };
 
@@ -775,20 +782,6 @@ static int __init lenovo_yoga_tab2_1380_init(struct device *dev)
 	return 0;
 }
 
-static struct gpiod_lookup_table lenovo_yoga_tab2_1380_fc_gpios = {
-	.dev_id = "serial0-0",
-	.table = {
-		GPIO_LOOKUP("INT33FC:00", 57, "uart3_txd", GPIO_ACTIVE_HIGH),
-		GPIO_LOOKUP("INT33FC:00", 61, "uart3_rxd", GPIO_ACTIVE_HIGH),
-		{ }
-	},
-};
-
-static struct gpiod_lookup_table * const lenovo_yoga_tab2_1380_gpios[] = {
-	&lenovo_yoga_tab2_1380_fc_gpios,
-	NULL
-};
-
 const struct x86_dev_info lenovo_yoga_tab2_1380_info __initconst = {
 	.i2c_client_info = lenovo_yoga_tab2_1380_i2c_clients,
 	.i2c_client_count = ARRAY_SIZE(lenovo_yoga_tab2_1380_i2c_clients),
@@ -796,9 +789,9 @@ const struct x86_dev_info lenovo_yoga_tab2_1380_info __initconst = {
 	.pdev_count = ARRAY_SIZE(lenovo_yoga_tab2_1380_pdevs),
 	.gpio_button = &lenovo_yoga_tab2_830_1050_lid,
 	.gpio_button_count = 1,
-	.gpiod_lookup_tables = lenovo_yoga_tab2_1380_gpios,
 	.bat_swnode = &generic_lipo_hv_4v35_battery_node,
 	.modules = lenovo_yoga_tab2_1380_modules,
+	.gpiochip_type = X86_GPIOCHIP_BAYTRAIL,
 	.init = lenovo_yoga_tab2_1380_init,
 	.exit = lenovo_yoga_tab2_830_1050_exit,
 };
-- 
2.51.0

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

[Hans de Goede]

From: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Now that everything that used the lookup tables has been switched to
using property entries to describe GPIOs, we can remove support for
registering and unregistering the lookup tables.

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Tested-by: Hans de Goede <hansg@kernel.org>
Reviewed-by: Hans de Goede <hansg@kernel.org>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hansg@kernel.org>
---
 drivers/platform/x86/x86-android-tablets/core.c           | 8 --------
 .../x86/x86-android-tablets/x86-android-tablets.h         | 2 --
 2 files changed, 10 deletions(-)

diff --git a/drivers/platform/x86/x86-android-tablets/core.c b/drivers/platform/x86/x86-android-tablets/core.c
index 7b5942010c78..1eb59c999baf 100644
--- a/drivers/platform/x86/x86-android-tablets/core.c
+++ b/drivers/platform/x86/x86-android-tablets/core.c
@@ -153,7 +153,6 @@ static struct spi_device **spi_devs;
 static struct platform_device **pdevs;
 static struct serdev_device **serdevs;
 static struct gpio_keys_button *buttons;
-static struct gpiod_lookup_table * const *gpiod_lookup_tables;
 static const struct software_node *bat_swnode;
 static const struct software_node **gpiochip_node_group;
 static void (*exit_handler)(void);
@@ -394,9 +393,6 @@ static void x86_android_tablet_remove(struct platform_device *pdev)
 
 	if (gpiochip_node_group)
 		software_node_unregister_node_group(gpiochip_node_group);
-
-	for (i = 0; gpiod_lookup_tables && gpiod_lookup_tables[i]; i++)
-		gpiod_remove_lookup_table(gpiod_lookup_tables[i]);
 }
 
 static __init int x86_android_tablet_probe(struct platform_device *pdev)
@@ -420,10 +416,6 @@ static __init int x86_android_tablet_probe(struct platform_device *pdev)
 	for (i = 0; dev_info->modules && dev_info->modules[i]; i++)
 		request_module(dev_info->modules[i]);
 
-	gpiod_lookup_tables = dev_info->gpiod_lookup_tables;
-	for (i = 0; gpiod_lookup_tables && gpiod_lookup_tables[i]; i++)
-		gpiod_add_lookup_table(gpiod_lookup_tables[i]);
-
 	switch (dev_info->gpiochip_type) {
 	case X86_GPIOCHIP_BAYTRAIL:
 		gpiochip_node_group = baytrail_gpiochip_node_group;
diff --git a/drivers/platform/x86/x86-android-tablets/x86-android-tablets.h b/drivers/platform/x86/x86-android-tablets/x86-android-tablets.h
index a54d09408866..d037e3962a51 100644
--- a/drivers/platform/x86/x86-android-tablets/x86-android-tablets.h
+++ b/drivers/platform/x86/x86-android-tablets/x86-android-tablets.h
@@ -17,7 +17,6 @@
 #include <linux/spi/spi.h>
 
 struct gpio_desc;
-struct gpiod_lookup_table;
 struct platform_device_info;
 struct software_node;
 
@@ -91,7 +90,6 @@ struct x86_gpio_button {
 struct x86_dev_info {
 	const char * const *modules;
 	const struct software_node *bat_swnode;
-	struct gpiod_lookup_table * const *gpiod_lookup_tables;
 	const struct x86_i2c_client_info *i2c_client_info;
 	const struct x86_spi_dev_info *spi_dev_info;
 	const struct platform_device_info *pdev_info;
-- 
2.51.0

[PATCH v4 11/20] platform/x86: x86-android-tablets: convert gpio_keys devices to GPIO references

[Hans de Goede]

From: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Now that gpiolib supports software nodes to describe GPIOs, switch the
driver away from using GPIO lookup tables for gpio_keys devices to using
PROPERTY_ENTRY_GPIO().

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Tested-by: Hans de Goede <hansg@kernel.org>
Reviewed-by: Hans de Goede <hansg@kernel.org>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hansg@kernel.org>
---
 .../platform/x86/x86-android-tablets/asus.c   |  42 ++++--
 .../platform/x86/x86-android-tablets/core.c   |  44 ++----
 .../platform/x86/x86-android-tablets/lenovo.c |  79 ++++++----
 .../platform/x86/x86-android-tablets/other.c  | 138 +++++++++++-------
 .../x86-android-tablets/x86-android-tablets.h |  10 +-
 5 files changed, 177 insertions(+), 136 deletions(-)

diff --git a/drivers/platform/x86/x86-android-tablets/asus.c b/drivers/platform/x86/x86-android-tablets/asus.c
index ce581d161551..91245f1bfd87 100644
--- a/drivers/platform/x86/x86-android-tablets/asus.c
+++ b/drivers/platform/x86/x86-android-tablets/asus.c
@@ -10,7 +10,7 @@
 
 #include <linux/gpio/machine.h>
 #include <linux/gpio/property.h>
-#include <linux/input.h>
+#include <linux/input-event-codes.h>
 #include <linux/platform_device.h>
 
 #include "shared-psy-info.h"
@@ -31,17 +31,29 @@ static const struct platform_device_info asus_me176c_tf103c_pdevs[] __initconst
 	},
 };
 
-static const struct x86_gpio_button asus_me176c_tf103c_lid __initconst = {
-	.button = {
-		.code = SW_LID,
-		.active_low = true,
-		.desc = "lid_sw",
-		.type = EV_SW,
-		.wakeup = true,
-		.debounce_interval = 50,
-	},
-	.chip = "INT33FC:02",
-	.pin = 12,
+static const struct software_node asus_me176c_tf103c_gpio_keys_node = {
+	.name = "lid_sw",
+};
+
+static const struct property_entry asus_me176c_tf103c_lid_props[] = {
+	PROPERTY_ENTRY_U32("linux,input-type", EV_SW),
+	PROPERTY_ENTRY_U32("linux,code", SW_LID),
+	PROPERTY_ENTRY_STRING("label", "lid_sw"),
+	PROPERTY_ENTRY_GPIO("gpios", &baytrail_gpiochip_nodes[2], 12, GPIO_ACTIVE_LOW),
+	PROPERTY_ENTRY_U32("debounce-interval", 50),
+	PROPERTY_ENTRY_BOOL("wakeup-source"),
+	{ }
+};
+
+static const struct software_node asus_me176c_tf103c_lid_node = {
+	.parent = &asus_me176c_tf103c_gpio_keys_node,
+	.properties = asus_me176c_tf103c_lid_props,
+};
+
+static const struct software_node *asus_me176c_tf103c_lid_swnodes[] = {
+	&asus_me176c_tf103c_gpio_keys_node,
+	&asus_me176c_tf103c_lid_node,
+	NULL
 };
 
 /* Asus ME176C tablets have an Android factory image with everything hardcoded */
@@ -177,8 +189,7 @@ const struct x86_dev_info asus_me176c_info __initconst = {
 	.pdev_count = ARRAY_SIZE(asus_me176c_tf103c_pdevs),
 	.serdev_info = asus_me176c_serdevs,
 	.serdev_count = ARRAY_SIZE(asus_me176c_serdevs),
-	.gpio_button = &asus_me176c_tf103c_lid,
-	.gpio_button_count = 1,
+	.gpio_button_swnodes = asus_me176c_tf103c_lid_swnodes,
 	.bat_swnode = &generic_lipo_hv_4v35_battery_node,
 	.modules = bq24190_modules,
 	.gpiochip_type = X86_GPIOCHIP_BAYTRAIL,
@@ -301,8 +312,7 @@ const struct x86_dev_info asus_tf103c_info __initconst = {
 	.i2c_client_count = ARRAY_SIZE(asus_tf103c_i2c_clients),
 	.pdev_info = asus_me176c_tf103c_pdevs,
 	.pdev_count = ARRAY_SIZE(asus_me176c_tf103c_pdevs),
-	.gpio_button = &asus_me176c_tf103c_lid,
-	.gpio_button_count = 1,
+	.gpio_button_swnodes = asus_me176c_tf103c_lid_swnodes,
 	.bat_swnode = &generic_lipo_4v2_battery_node,
 	.modules = bq24190_modules,
 	.gpiochip_type = X86_GPIOCHIP_BAYTRAIL,
diff --git a/drivers/platform/x86/x86-android-tablets/core.c b/drivers/platform/x86/x86-android-tablets/core.c
index 1eb59c999baf..955a2c83a9bf 100644
--- a/drivers/platform/x86/x86-android-tablets/core.c
+++ b/drivers/platform/x86/x86-android-tablets/core.c
@@ -152,7 +152,7 @@ static struct i2c_client **i2c_clients;
 static struct spi_device **spi_devs;
 static struct platform_device **pdevs;
 static struct serdev_device **serdevs;
-static struct gpio_keys_button *buttons;
+static const struct software_node **gpio_button_swnodes;
 static const struct software_node *bat_swnode;
 static const struct software_node **gpiochip_node_group;
 static void (*exit_handler)(void);
@@ -373,7 +373,6 @@ static void x86_android_tablet_remove(struct platform_device *pdev)
 		platform_device_unregister(pdevs[i]);
 
 	kfree(pdevs);
-	kfree(buttons);
 
 	for (i = spi_dev_count - 1; i >= 0; i--)
 		spi_unregister_device(spi_devs[i]);
@@ -388,6 +387,9 @@ static void x86_android_tablet_remove(struct platform_device *pdev)
 	if (exit_handler)
 		exit_handler();
 
+	if (gpio_button_swnodes)
+		software_node_unregister_node_group(gpio_button_swnodes);
+
 	if (bat_swnode)
 		software_node_unregister(bat_swnode);
 
@@ -514,38 +516,22 @@ static __init int x86_android_tablet_probe(struct platform_device *pdev)
 		}
 	}
 
-	if (dev_info->gpio_button_count) {
-		struct gpio_keys_platform_data pdata = { };
-		struct gpio_desc *gpiod;
+	if (dev_info->gpio_button_swnodes) {
+		struct platform_device_info button_info = {
+			.name = "gpio-keys",
+			.id = PLATFORM_DEVID_AUTO,
+		};
 
-		buttons = kcalloc(dev_info->gpio_button_count, sizeof(*buttons), GFP_KERNEL);
-		if (!buttons) {
+		ret = software_node_register_node_group(dev_info->gpio_button_swnodes);
+		if (ret < 0) {
 			x86_android_tablet_remove(pdev);
-			return -ENOMEM;
+			return ret;
 		}
 
-		for (i = 0; i < dev_info->gpio_button_count; i++) {
-			ret = x86_android_tablet_get_gpiod(dev_info->gpio_button[i].chip,
-							   dev_info->gpio_button[i].pin,
-							   dev_info->gpio_button[i].button.desc,
-							   false, GPIOD_IN, &gpiod);
-			if (ret < 0) {
-				x86_android_tablet_remove(pdev);
-				return ret;
-			}
+		gpio_button_swnodes = dev_info->gpio_button_swnodes;
 
-			buttons[i] = dev_info->gpio_button[i].button;
-			buttons[i].gpio = desc_to_gpio(gpiod);
-			/* Release GPIO descriptor so that gpio-keys can request it */
-			devm_gpiod_put(&x86_android_tablet_device->dev, gpiod);
-		}
-
-		pdata.buttons = buttons;
-		pdata.nbuttons = dev_info->gpio_button_count;
-
-		pdevs[pdev_count] = platform_device_register_data(&pdev->dev, "gpio-keys",
-								  PLATFORM_DEVID_AUTO,
-								  &pdata, sizeof(pdata));
+		button_info.fwnode = software_node_fwnode(dev_info->gpio_button_swnodes[0]);
+		pdevs[pdev_count] = platform_device_register_full(&button_info);
 		if (IS_ERR(pdevs[pdev_count])) {
 			ret = PTR_ERR(pdevs[pdev_count]);
 			x86_android_tablet_remove(pdev);
diff --git a/drivers/platform/x86/x86-android-tablets/lenovo.c b/drivers/platform/x86/x86-android-tablets/lenovo.c
index 7d1808a3437f..9a28216642c3 100644
--- a/drivers/platform/x86/x86-android-tablets/lenovo.c
+++ b/drivers/platform/x86/x86-android-tablets/lenovo.c
@@ -13,6 +13,7 @@
 #include <linux/efi.h>
 #include <linux/gpio/machine.h>
 #include <linux/gpio/property.h>
+#include <linux/input-event-codes.h>
 #include <linux/mfd/arizona/pdata.h>
 #include <linux/mfd/arizona/registers.h>
 #include <linux/mfd/intel_soc_pmic.h>
@@ -207,17 +208,34 @@ static const struct x86_serdev_info lenovo_yb1_x90_serdevs[] __initconst = {
 	},
 };
 
-static const struct x86_gpio_button lenovo_yb1_x90_lid __initconst = {
-	.button = {
-		.code = SW_LID,
-		.active_low = true,
-		.desc = "lid_sw",
-		.type = EV_SW,
-		.wakeup = true,
-		.debounce_interval = 50,
-	},
-	.chip = "INT33FF:02",
-	.pin = 19,
+/*
+ * Software node attached to gpio-keys device representing the LID and
+ * serving as a parent to software nodes representing individual keys/buttons
+ * as required by the device tree binding.
+ */
+static const struct software_node lenovo_lid_gpio_keys_node = {
+	.name = "lid_sw",
+};
+
+static const struct property_entry lenovo_yb1_x90_lid_props[] = {
+	PROPERTY_ENTRY_U32("linux,input-type", EV_SW),
+	PROPERTY_ENTRY_U32("linux,code", SW_LID),
+	PROPERTY_ENTRY_STRING("label", "lid_sw"),
+	PROPERTY_ENTRY_GPIO("gpios", &cherryview_gpiochip_nodes[2], 19, GPIO_ACTIVE_LOW),
+	PROPERTY_ENTRY_U32("debounce-interval", 50),
+	PROPERTY_ENTRY_BOOL("wakeup-source"),
+	{ }
+};
+
+static const struct software_node lenovo_yb1_x90_lid_node = {
+	.parent = &lenovo_lid_gpio_keys_node,
+	.properties = lenovo_yb1_x90_lid_props,
+};
+
+static const struct software_node *lenovo_yb1_x90_lid_swnodes[] = {
+	&lenovo_lid_gpio_keys_node,
+	&lenovo_yb1_x90_lid_node,
+	NULL
 };
 
 static int __init lenovo_yb1_x90_init(struct device *dev)
@@ -246,8 +264,7 @@ const struct x86_dev_info lenovo_yogabook_x90_info __initconst = {
 	.pdev_count = ARRAY_SIZE(lenovo_yb1_x90_pdevs),
 	.serdev_info = lenovo_yb1_x90_serdevs,
 	.serdev_count = ARRAY_SIZE(lenovo_yb1_x90_serdevs),
-	.gpio_button = &lenovo_yb1_x90_lid,
-	.gpio_button_count = 1,
+	.gpio_button_swnodes = lenovo_yb1_x90_lid_swnodes,
 	.gpiochip_type = X86_GPIOCHIP_CHERRYVIEW,
 	.init = lenovo_yb1_x90_init,
 };
@@ -284,17 +301,25 @@ static const struct software_node lenovo_yoga_tab2_830_1050_bq24190_node = {
 	.properties = lenovo_yoga_tab2_830_1050_bq24190_props,
 };
 
-static const struct x86_gpio_button lenovo_yoga_tab2_830_1050_lid __initconst = {
-	.button = {
-		.code = SW_LID,
-		.active_low = true,
-		.desc = "lid_sw",
-		.type = EV_SW,
-		.wakeup = true,
-		.debounce_interval = 50,
-	},
-	.chip = "INT33FC:02",
-	.pin = 26,
+static const struct property_entry lenovo_yoga_tab2_830_1050_lid_props[] = {
+	PROPERTY_ENTRY_U32("linux,input-type", EV_SW),
+	PROPERTY_ENTRY_U32("linux,code", SW_LID),
+	PROPERTY_ENTRY_STRING("label", "lid_sw"),
+	PROPERTY_ENTRY_GPIO("gpios", &baytrail_gpiochip_nodes[2], 26, GPIO_ACTIVE_LOW),
+	PROPERTY_ENTRY_U32("debounce-interval", 50),
+	PROPERTY_ENTRY_BOOL("wakeup-source"),
+	{ }
+};
+
+static const struct software_node lenovo_yoga_tab2_830_1050_lid_node = {
+	.parent = &lenovo_lid_gpio_keys_node,
+	.properties = lenovo_yoga_tab2_830_1050_lid_props,
+};
+
+static const struct software_node *lenovo_yoga_tab2_830_1050_lid_swnodes[] = {
+	&lenovo_lid_gpio_keys_node,
+	&lenovo_yoga_tab2_830_1050_lid_node,
+	NULL
 };
 
 /* This gets filled by lenovo_yoga_tab2_830_1050_init() */
@@ -422,8 +447,7 @@ const struct x86_dev_info lenovo_yoga_tab2_830_1050_info __initconst = {
 	.i2c_client_count = ARRAY_SIZE(lenovo_yoga_tab2_830_1050_i2c_clients),
 	.pdev_info = lenovo_yoga_tab2_830_1050_pdevs,
 	.pdev_count = ARRAY_SIZE(lenovo_yoga_tab2_830_1050_pdevs),
-	.gpio_button = &lenovo_yoga_tab2_830_1050_lid,
-	.gpio_button_count = 1,
+	.gpio_button_swnodes = lenovo_yoga_tab2_830_1050_lid_swnodes,
 	.bat_swnode = &generic_lipo_hv_4v35_battery_node,
 	.modules = bq24190_modules,
 	.gpiochip_type = X86_GPIOCHIP_BAYTRAIL,
@@ -787,8 +811,7 @@ const struct x86_dev_info lenovo_yoga_tab2_1380_info __initconst = {
 	.i2c_client_count = ARRAY_SIZE(lenovo_yoga_tab2_1380_i2c_clients),
 	.pdev_info = lenovo_yoga_tab2_1380_pdevs,
 	.pdev_count = ARRAY_SIZE(lenovo_yoga_tab2_1380_pdevs),
-	.gpio_button = &lenovo_yoga_tab2_830_1050_lid,
-	.gpio_button_count = 1,
+	.gpio_button_swnodes = lenovo_yoga_tab2_830_1050_lid_swnodes,
 	.bat_swnode = &generic_lipo_hv_4v35_battery_node,
 	.modules = lenovo_yoga_tab2_1380_modules,
 	.gpiochip_type = X86_GPIOCHIP_BAYTRAIL,
diff --git a/drivers/platform/x86/x86-android-tablets/other.c b/drivers/platform/x86/x86-android-tablets/other.c
index 5309831243b3..1362f4167e3d 100644
--- a/drivers/platform/x86/x86-android-tablets/other.c
+++ b/drivers/platform/x86/x86-android-tablets/other.c
@@ -11,7 +11,7 @@
 #include <linux/acpi.h>
 #include <linux/gpio/machine.h>
 #include <linux/gpio/property.h>
-#include <linux/input.h>
+#include <linux/input-event-codes.h>
 #include <linux/leds.h>
 #include <linux/pci.h>
 #include <linux/platform_device.h>
@@ -98,22 +98,32 @@ const struct x86_dev_info acer_b1_750_info __initconst = {
  * which is not described in the ACPI tables in anyway.
  * Use the x86-android-tablets infra to create a gpio-keys device for this.
  */
-static const struct x86_gpio_button advantech_mica_071_button __initconst = {
-	.button = {
-		.code = KEY_PROG1,
-		.active_low = true,
-		.desc = "prog1_key",
-		.type = EV_KEY,
-		.wakeup = false,
-		.debounce_interval = 50,
-	},
-	.chip = "INT33FC:00",
-	.pin = 2,
+static const struct software_node advantech_mica_071_gpio_keys_node = {
+	.name = "prog1_key",
+};
+
+static const struct property_entry advantech_mica_071_prog1_key_props[] = {
+	PROPERTY_ENTRY_U32("linux,code", KEY_PROG1),
+	PROPERTY_ENTRY_STRING("label", "prog1_key"),
+	PROPERTY_ENTRY_GPIO("gpios", &baytrail_gpiochip_nodes[0], 2, GPIO_ACTIVE_LOW),
+	PROPERTY_ENTRY_U32("debounce-interval", 50),
+	{ }
+};
+
+static const struct software_node advantech_mica_071_prog1_key_node = {
+	.parent = &advantech_mica_071_gpio_keys_node,
+	.properties = advantech_mica_071_prog1_key_props,
+};
+
+static const struct software_node *advantech_mica_071_button_swnodes[] = {
+	&advantech_mica_071_gpio_keys_node,
+	&advantech_mica_071_prog1_key_node,
+	NULL
 };
 
 const struct x86_dev_info advantech_mica_071_info __initconst = {
-	.gpio_button = &advantech_mica_071_button,
-	.gpio_button_count = 1,
+	.gpio_button_swnodes = advantech_mica_071_button_swnodes,
+	.gpiochip_type = X86_GPIOCHIP_BAYTRAIL,
 };
 
 /*
@@ -209,36 +219,46 @@ const struct x86_dev_info chuwi_hi8_info __initconst = {
  * in the button row with the power + volume-buttons labeled P and F.
  * Use the x86-android-tablets infra to create a gpio-keys device for these.
  */
-static const struct x86_gpio_button cyberbook_t116_buttons[] __initconst = {
-	{
-		.button = {
-			.code = KEY_PROG1,
-			.active_low = true,
-			.desc = "prog1_key",
-			.type = EV_KEY,
-			.wakeup = false,
-			.debounce_interval = 50,
-		},
-		.chip = "INT33FF:00",
-		.pin = 30,
-	},
-	{
-		.button = {
-			.code = KEY_PROG2,
-			.active_low = true,
-			.desc = "prog2_key",
-			.type = EV_KEY,
-			.wakeup = false,
-			.debounce_interval = 50,
-		},
-		.chip = "INT33FF:03",
-		.pin = 48,
-	},
+static const struct software_node cyberbook_t116_gpio_keys_node = {
+	.name = "prog_keys",
+};
+
+static const struct property_entry cyberbook_t116_prog1_key_props[] = {
+	PROPERTY_ENTRY_U32("linux,code", KEY_PROG1),
+	PROPERTY_ENTRY_STRING("label", "prog1_key"),
+	PROPERTY_ENTRY_GPIO("gpios", &cherryview_gpiochip_nodes[0], 30, GPIO_ACTIVE_LOW),
+	PROPERTY_ENTRY_U32("debounce-interval", 50),
+	{ }
+};
+
+static const struct software_node cyberbook_t116_prog1_key_node = {
+	.parent = &cyberbook_t116_gpio_keys_node,
+	.properties = cyberbook_t116_prog1_key_props,
+};
+
+static const struct property_entry cyberbook_t116_prog2_key_props[] = {
+	PROPERTY_ENTRY_U32("linux,code", KEY_PROG2),
+	PROPERTY_ENTRY_STRING("label", "prog2_key"),
+	PROPERTY_ENTRY_GPIO("gpios", &cherryview_gpiochip_nodes[3], 48, GPIO_ACTIVE_LOW),
+	PROPERTY_ENTRY_U32("debounce-interval", 50),
+	{ }
+};
+
+static const struct software_node cyberbook_t116_prog2_key_node = {
+	.parent = &cyberbook_t116_gpio_keys_node,
+	.properties = cyberbook_t116_prog2_key_props,
+};
+
+static const struct software_node *cyberbook_t116_buttons_swnodes[] = {
+	&cyberbook_t116_gpio_keys_node,
+	&cyberbook_t116_prog1_key_node,
+	&cyberbook_t116_prog2_key_node,
+	NULL
 };
 
 const struct x86_dev_info cyberbook_t116_info __initconst = {
-	.gpio_button = cyberbook_t116_buttons,
-	.gpio_button_count = ARRAY_SIZE(cyberbook_t116_buttons),
+	.gpio_button_swnodes = cyberbook_t116_buttons_swnodes,
+	.gpiochip_type = X86_GPIOCHIP_CHERRYVIEW,
 };
 
 #define CZC_EC_EXTRA_PORT	0x68
@@ -478,22 +498,32 @@ const struct x86_dev_info nextbook_ares8a_info __initconst = {
  * This button has a WMI interface, but that is broken. Instead of trying to
  * use the broken WMI interface, instantiate a gpio-keys device for this.
  */
-static const struct x86_gpio_button peaq_c1010_button __initconst = {
-	.button = {
-		.code = KEY_SOUND,
-		.active_low = true,
-		.desc = "dolby_key",
-		.type = EV_KEY,
-		.wakeup = false,
-		.debounce_interval = 50,
-	},
-	.chip = "INT33FC:00",
-	.pin = 3,
+static const struct software_node peaq_c1010_gpio_keys_node = {
+	.name = "gpio_keys",
+};
+
+static const struct property_entry peaq_c1010_dolby_key_props[] = {
+	PROPERTY_ENTRY_U32("linux,code", KEY_SOUND),
+	PROPERTY_ENTRY_STRING("label", "dolby_key"),
+	PROPERTY_ENTRY_GPIO("gpios", &baytrail_gpiochip_nodes[0], 3, GPIO_ACTIVE_LOW),
+	PROPERTY_ENTRY_U32("debounce-interval", 50),
+	{ }
+};
+
+static const struct software_node peaq_c1010_dolby_key_node = {
+	.parent = &peaq_c1010_gpio_keys_node,
+	.properties = peaq_c1010_dolby_key_props,
+};
+
+static const struct software_node *peaq_c1010_button_swnodes[] = {
+	&peaq_c1010_gpio_keys_node,
+	&peaq_c1010_dolby_key_node,
+	NULL
 };
 
 const struct x86_dev_info peaq_c1010_info __initconst = {
-	.gpio_button = &peaq_c1010_button,
-	.gpio_button_count = 1,
+	.gpio_button_swnodes = peaq_c1010_button_swnodes,
+	.gpiochip_type = X86_GPIOCHIP_BAYTRAIL,
 };
 
 /*
diff --git a/drivers/platform/x86/x86-android-tablets/x86-android-tablets.h b/drivers/platform/x86/x86-android-tablets/x86-android-tablets.h
index d037e3962a51..f4a67a9b74ea 100644
--- a/drivers/platform/x86/x86-android-tablets/x86-android-tablets.h
+++ b/drivers/platform/x86/x86-android-tablets/x86-android-tablets.h
@@ -11,7 +11,6 @@
 #define __PDX86_X86_ANDROID_TABLETS_H
 
 #include <linux/gpio/consumer.h>
-#include <linux/gpio_keys.h>
 #include <linux/i2c.h>
 #include <linux/irqdomain_defs.h>
 #include <linux/spi/spi.h>
@@ -81,12 +80,6 @@ struct x86_serdev_info {
 	const char *serdev_hid;
 };
 
-struct x86_gpio_button {
-	struct gpio_keys_button button;
-	const char *chip;
-	int pin;
-};
-
 struct x86_dev_info {
 	const char * const *modules;
 	const struct software_node *bat_swnode;
@@ -94,12 +87,11 @@ struct x86_dev_info {
 	const struct x86_spi_dev_info *spi_dev_info;
 	const struct platform_device_info *pdev_info;
 	const struct x86_serdev_info *serdev_info;
-	const struct x86_gpio_button *gpio_button;
+	const struct software_node **gpio_button_swnodes;
 	int i2c_client_count;
 	int spi_dev_count;
 	int pdev_count;
 	int serdev_count;
-	int gpio_button_count;
 	int (*init)(struct device *dev);
 	void (*exit)(void);
 	bool use_pci;
-- 
2.51.0

[PATCH v4 12/20] platform/x86: x86-android-tablets: replace bat_swnode with swnode_group

[Hans de Goede]

Now that we are using software-nodes are used in more places it is
useful to have a more generic mechanism to have the core code register
software-nodes.

Replace the bat_swnode registration mechanism with a more generic
swnode_group registration mechanism.

Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hansg@kernel.org>
---
 drivers/platform/x86/x86-android-tablets/asus.c      |  4 ++--
 drivers/platform/x86/x86-android-tablets/core.c      | 12 ++++++------
 drivers/platform/x86/x86-android-tablets/lenovo.c    |  4 ++--
 .../x86/x86-android-tablets/shared-psy-info.c        | 10 ++++++++++
 .../x86/x86-android-tablets/shared-psy-info.h        |  4 ++++
 .../x86/x86-android-tablets/x86-android-tablets.h    |  2 +-
 6 files changed, 25 insertions(+), 11 deletions(-)

diff --git a/drivers/platform/x86/x86-android-tablets/asus.c b/drivers/platform/x86/x86-android-tablets/asus.c
index 91245f1bfd87..39eb2f9dc031 100644
--- a/drivers/platform/x86/x86-android-tablets/asus.c
+++ b/drivers/platform/x86/x86-android-tablets/asus.c
@@ -190,7 +190,7 @@ const struct x86_dev_info asus_me176c_info __initconst = {
 	.serdev_info = asus_me176c_serdevs,
 	.serdev_count = ARRAY_SIZE(asus_me176c_serdevs),
 	.gpio_button_swnodes = asus_me176c_tf103c_lid_swnodes,
-	.bat_swnode = &generic_lipo_hv_4v35_battery_node,
+	.swnode_group = generic_lipo_hv_4v35_battery_swnodes,
 	.modules = bq24190_modules,
 	.gpiochip_type = X86_GPIOCHIP_BAYTRAIL,
 };
@@ -313,7 +313,7 @@ const struct x86_dev_info asus_tf103c_info __initconst = {
 	.pdev_info = asus_me176c_tf103c_pdevs,
 	.pdev_count = ARRAY_SIZE(asus_me176c_tf103c_pdevs),
 	.gpio_button_swnodes = asus_me176c_tf103c_lid_swnodes,
-	.bat_swnode = &generic_lipo_4v2_battery_node,
+	.swnode_group = generic_lipo_4v2_battery_swnodes,
 	.modules = bq24190_modules,
 	.gpiochip_type = X86_GPIOCHIP_BAYTRAIL,
 };
diff --git a/drivers/platform/x86/x86-android-tablets/core.c b/drivers/platform/x86/x86-android-tablets/core.c
index 955a2c83a9bf..5675e888d84f 100644
--- a/drivers/platform/x86/x86-android-tablets/core.c
+++ b/drivers/platform/x86/x86-android-tablets/core.c
@@ -153,7 +153,7 @@ static struct spi_device **spi_devs;
 static struct platform_device **pdevs;
 static struct serdev_device **serdevs;
 static const struct software_node **gpio_button_swnodes;
-static const struct software_node *bat_swnode;
+static const struct software_node **swnode_group;
 static const struct software_node **gpiochip_node_group;
 static void (*exit_handler)(void);
 
@@ -390,8 +390,8 @@ static void x86_android_tablet_remove(struct platform_device *pdev)
 	if (gpio_button_swnodes)
 		software_node_unregister_node_group(gpio_button_swnodes);
 
-	if (bat_swnode)
-		software_node_unregister(bat_swnode);
+	if (swnode_group)
+		software_node_unregister_node_group(swnode_group);
 
 	if (gpiochip_node_group)
 		software_node_unregister_node_group(gpiochip_node_group);
@@ -436,13 +436,13 @@ static __init int x86_android_tablet_probe(struct platform_device *pdev)
 			return ret;
 	}
 
-	if (dev_info->bat_swnode) {
-		ret = software_node_register(dev_info->bat_swnode);
+	if (dev_info->swnode_group) {
+		ret = software_node_register_node_group(dev_info->swnode_group);
 		if (ret) {
 			x86_android_tablet_remove(pdev);
 			return ret;
 		}
-		bat_swnode = dev_info->bat_swnode;
+		swnode_group = dev_info->swnode_group;
 	}
 
 	if (dev_info->init) {
diff --git a/drivers/platform/x86/x86-android-tablets/lenovo.c b/drivers/platform/x86/x86-android-tablets/lenovo.c
index 9a28216642c3..66617f6ff13e 100644
--- a/drivers/platform/x86/x86-android-tablets/lenovo.c
+++ b/drivers/platform/x86/x86-android-tablets/lenovo.c
@@ -448,7 +448,7 @@ const struct x86_dev_info lenovo_yoga_tab2_830_1050_info __initconst = {
 	.pdev_info = lenovo_yoga_tab2_830_1050_pdevs,
 	.pdev_count = ARRAY_SIZE(lenovo_yoga_tab2_830_1050_pdevs),
 	.gpio_button_swnodes = lenovo_yoga_tab2_830_1050_lid_swnodes,
-	.bat_swnode = &generic_lipo_hv_4v35_battery_node,
+	.swnode_group = generic_lipo_hv_4v35_battery_swnodes,
 	.modules = bq24190_modules,
 	.gpiochip_type = X86_GPIOCHIP_BAYTRAIL,
 	.init = lenovo_yoga_tab2_830_1050_init,
@@ -812,7 +812,7 @@ const struct x86_dev_info lenovo_yoga_tab2_1380_info __initconst = {
 	.pdev_info = lenovo_yoga_tab2_1380_pdevs,
 	.pdev_count = ARRAY_SIZE(lenovo_yoga_tab2_1380_pdevs),
 	.gpio_button_swnodes = lenovo_yoga_tab2_830_1050_lid_swnodes,
-	.bat_swnode = &generic_lipo_hv_4v35_battery_node,
+	.swnode_group = generic_lipo_hv_4v35_battery_swnodes,
 	.modules = lenovo_yoga_tab2_1380_modules,
 	.gpiochip_type = X86_GPIOCHIP_BAYTRAIL,
 	.init = lenovo_yoga_tab2_1380_init,
diff --git a/drivers/platform/x86/x86-android-tablets/shared-psy-info.c b/drivers/platform/x86/x86-android-tablets/shared-psy-info.c
index 6ebe282bda6e..62f41c14e6ba 100644
--- a/drivers/platform/x86/x86-android-tablets/shared-psy-info.c
+++ b/drivers/platform/x86/x86-android-tablets/shared-psy-info.c
@@ -113,6 +113,11 @@ const struct software_node generic_lipo_4v2_battery_node = {
 	.properties = generic_lipo_4v2_battery_props,
 };
 
+const struct software_node *generic_lipo_4v2_battery_swnodes[] = {
+	&generic_lipo_4v2_battery_node,
+	NULL
+};
+
 /* LiPo HighVoltage (max 4.35V) settings used by most devs with a HV battery */
 static const struct property_entry generic_lipo_hv_4v35_battery_props[] = {
 	PROPERTY_ENTRY_STRING("compatible", "simple-battery"),
@@ -133,6 +138,11 @@ const struct software_node generic_lipo_hv_4v35_battery_node = {
 	.properties = generic_lipo_hv_4v35_battery_props,
 };
 
+const struct software_node *generic_lipo_hv_4v35_battery_swnodes[] = {
+	&generic_lipo_hv_4v35_battery_node,
+	NULL
+};
+
 /* For enabling the bq24190 5V boost based on id-pin */
 static struct regulator_consumer_supply intel_int3496_consumer = {
 	.supply = "vbus",
diff --git a/drivers/platform/x86/x86-android-tablets/shared-psy-info.h b/drivers/platform/x86/x86-android-tablets/shared-psy-info.h
index b9cbc291aa4d..e5ba1c65d62b 100644
--- a/drivers/platform/x86/x86-android-tablets/shared-psy-info.h
+++ b/drivers/platform/x86/x86-android-tablets/shared-psy-info.h
@@ -20,8 +20,12 @@ extern const char * const bq25890_psy[];
 
 extern const struct software_node fg_bq24190_supply_node;
 extern const struct software_node fg_bq25890_supply_node;
+
 extern const struct software_node generic_lipo_4v2_battery_node;
+extern const struct software_node *generic_lipo_4v2_battery_swnodes[];
+
 extern const struct software_node generic_lipo_hv_4v35_battery_node;
+extern const struct software_node *generic_lipo_hv_4v35_battery_swnodes[];
 
 extern struct bq24190_platform_data bq24190_pdata;
 extern const char * const bq24190_modules[];
diff --git a/drivers/platform/x86/x86-android-tablets/x86-android-tablets.h b/drivers/platform/x86/x86-android-tablets/x86-android-tablets.h
index f4a67a9b74ea..4bf4bcdf50c0 100644
--- a/drivers/platform/x86/x86-android-tablets/x86-android-tablets.h
+++ b/drivers/platform/x86/x86-android-tablets/x86-android-tablets.h
@@ -82,7 +82,7 @@ struct x86_serdev_info {
 
 struct x86_dev_info {
 	const char * const *modules;
-	const struct software_node *bat_swnode;
+	const struct software_node **swnode_group;
 	const struct x86_i2c_client_info *i2c_client_info;
 	const struct x86_spi_dev_info *spi_dev_info;
 	const struct platform_device_info *pdev_info;
-- 
2.51.0

[PATCH v4 13/20] platform/x86: x86-android-tablets: use swnode_group instead of manual registering

[Hans de Goede]

Replace manually calling software_node_register_node_group() from init()
with the new swnode_group registration mechanism.

Note this also fixes a missing software_node_unregister_node_group()
for lenovo_yt3_swnodes.

Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hansg@kernel.org>
---
 .../platform/x86/x86-android-tablets/lenovo.c | 21 +++++--------------
 .../platform/x86/x86-android-tablets/other.c  | 14 ++-----------
 2 files changed, 7 insertions(+), 28 deletions(-)

diff --git a/drivers/platform/x86/x86-android-tablets/lenovo.c b/drivers/platform/x86/x86-android-tablets/lenovo.c
index 66617f6ff13e..1f325b2947ab 100644
--- a/drivers/platform/x86/x86-android-tablets/lenovo.c
+++ b/drivers/platform/x86/x86-android-tablets/lenovo.c
@@ -436,6 +436,7 @@ static const struct software_node *lenovo_yoga_tab2_830_1050_swnodes[] = {
 	&crystalcove_gpiochip_node,
 	&arizona_gpiochip_node,
 	&lenovo_yoga_tab2_830_1050_wm5102,
+	&generic_lipo_hv_4v35_battery_node,
 	NULL
 };
 
@@ -448,7 +449,7 @@ const struct x86_dev_info lenovo_yoga_tab2_830_1050_info __initconst = {
 	.pdev_info = lenovo_yoga_tab2_830_1050_pdevs,
 	.pdev_count = ARRAY_SIZE(lenovo_yoga_tab2_830_1050_pdevs),
 	.gpio_button_swnodes = lenovo_yoga_tab2_830_1050_lid_swnodes,
-	.swnode_group = generic_lipo_hv_4v35_battery_swnodes,
+	.swnode_group = lenovo_yoga_tab2_830_1050_swnodes,
 	.modules = bq24190_modules,
 	.gpiochip_type = X86_GPIOCHIP_BAYTRAIL,
 	.init = lenovo_yoga_tab2_830_1050_init,
@@ -534,24 +535,16 @@ static int __init lenovo_yoga_tab2_830_1050_init_codec(void)
 		goto err_unregister_mappings;
 	}
 
-	ret = software_node_register_node_group(lenovo_yoga_tab2_830_1050_swnodes);
-	if (ret) {
-		ret = dev_err_probe(codec_dev, ret, "registering software nodes\n");
-		goto err_put_pinctrl;
-	}
-
 	ret = device_add_software_node(codec_dev, &lenovo_yoga_tab2_830_1050_wm5102);
 	if (ret) {
 		ret = dev_err_probe(codec_dev, ret, "adding software node\n");
-		goto err_unregister_swnodes;
+		goto err_put_pinctrl;
 	}
 
 	lenovo_yoga_tab2_830_1050_codec_dev = codec_dev;
 	lenovo_yoga_tab2_830_1050_codec_pinctrl = pinctrl;
 	return 0;
 
-err_unregister_swnodes:
-	software_node_unregister_node_group(lenovo_yoga_tab2_830_1050_swnodes);
 err_put_pinctrl:
 	pinctrl_put(lenovo_yoga_tab2_830_1050_codec_pinctrl);
 err_unregister_mappings:
@@ -604,7 +597,6 @@ static void lenovo_yoga_tab2_830_1050_exit(void)
 	if (lenovo_yoga_tab2_830_1050_codec_dev) {
 		device_remove_software_node(lenovo_yoga_tab2_830_1050_codec_dev);
 		put_device(lenovo_yoga_tab2_830_1050_codec_dev);
-		software_node_unregister_node_group(lenovo_yoga_tab2_830_1050_swnodes);
 	}
 
 	if (lenovo_yoga_tab2_830_1050_codec_pinctrl) {
@@ -812,7 +804,7 @@ const struct x86_dev_info lenovo_yoga_tab2_1380_info __initconst = {
 	.pdev_info = lenovo_yoga_tab2_1380_pdevs,
 	.pdev_count = ARRAY_SIZE(lenovo_yoga_tab2_1380_pdevs),
 	.gpio_button_swnodes = lenovo_yoga_tab2_830_1050_lid_swnodes,
-	.swnode_group = generic_lipo_hv_4v35_battery_swnodes,
+	.swnode_group = lenovo_yoga_tab2_830_1050_swnodes,
 	.modules = lenovo_yoga_tab2_1380_modules,
 	.gpiochip_type = X86_GPIOCHIP_BAYTRAIL,
 	.init = lenovo_yoga_tab2_1380_init,
@@ -1071,10 +1063,6 @@ static int __init lenovo_yt3_init(struct device *dev)
 	intel_soc_pmic_exec_mipi_pmic_seq_element(0x6e, 0x9b, 0x02, 0xff);
 	intel_soc_pmic_exec_mipi_pmic_seq_element(0x6e, 0xa0, 0x02, 0xff);
 
-	ret = software_node_register_node_group(lenovo_yt3_swnodes);
-	if (ret)
-		return dev_err_probe(dev, ret, "registering software nodes\n");
-
 	return 0;
 }
 
@@ -1083,6 +1071,7 @@ const struct x86_dev_info lenovo_yt3_info __initconst = {
 	.i2c_client_count = ARRAY_SIZE(lenovo_yt3_i2c_clients),
 	.spi_dev_info = lenovo_yt3_spi_devs,
 	.spi_dev_count = ARRAY_SIZE(lenovo_yt3_spi_devs),
+	.swnode_group = lenovo_yt3_swnodes,
 	.gpiochip_type = X86_GPIOCHIP_CHERRYVIEW,
 	.init = lenovo_yt3_init,
 };
diff --git a/drivers/platform/x86/x86-android-tablets/other.c b/drivers/platform/x86/x86-android-tablets/other.c
index 1362f4167e3d..174f02322e52 100644
--- a/drivers/platform/x86/x86-android-tablets/other.c
+++ b/drivers/platform/x86/x86-android-tablets/other.c
@@ -895,7 +895,6 @@ static int xiaomi_mipad2_brightness_set(struct led_classdev *led_cdev,
 static int __init xiaomi_mipad2_init(struct device *dev)
 {
 	struct led_classdev *led_cdev;
-	int ret;
 
 	xiaomi_mipad2_led_pwm = devm_pwm_get(dev, "pwm_soc_lpss_2");
 	if (IS_ERR(xiaomi_mipad2_led_pwm))
@@ -912,16 +911,7 @@ static int __init xiaomi_mipad2_init(struct device *dev)
 	/* Turn LED off during suspend */
 	led_cdev->flags = LED_CORE_SUSPENDRESUME;
 
-	ret = devm_led_classdev_register(dev, led_cdev);
-	if (ret)
-		return dev_err_probe(dev, ret, "registering LED\n");
-
-	return software_node_register_node_group(ktd2026_node_group);
-}
-
-static void xiaomi_mipad2_exit(void)
-{
-	software_node_unregister_node_group(ktd2026_node_group);
+	return devm_led_classdev_register(dev, led_cdev);
 }
 
 /*
@@ -956,6 +946,6 @@ static const struct x86_i2c_client_info xiaomi_mipad2_i2c_clients[] __initconst
 const struct x86_dev_info xiaomi_mipad2_info __initconst = {
 	.i2c_client_info = xiaomi_mipad2_i2c_clients,
 	.i2c_client_count = ARRAY_SIZE(xiaomi_mipad2_i2c_clients),
+	.swnode_group = ktd2026_node_group,
 	.init = xiaomi_mipad2_init,
-	.exit = xiaomi_mipad2_exit,
 };
-- 
2.51.0

[PATCH v4 14/20] platform/x86: x86-android-tablets: Simplify node-group [un]registration

[Hans de Goede]

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.

Suggested-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hansg@kernel.org>
---
 .../platform/x86/x86-android-tablets/core.c   | 31 +++++++------------
 1 file changed, 11 insertions(+), 20 deletions(-)

diff --git a/drivers/platform/x86/x86-android-tablets/core.c b/drivers/platform/x86/x86-android-tablets/core.c
index 5675e888d84f..d0638664d1da 100644
--- a/drivers/platform/x86/x86-android-tablets/core.c
+++ b/drivers/platform/x86/x86-android-tablets/core.c
@@ -387,14 +387,9 @@ static void x86_android_tablet_remove(struct platform_device *pdev)
 	if (exit_handler)
 		exit_handler();
 
-	if (gpio_button_swnodes)
-		software_node_unregister_node_group(gpio_button_swnodes);
-
-	if (swnode_group)
-		software_node_unregister_node_group(swnode_group);
-
-	if (gpiochip_node_group)
-		software_node_unregister_node_group(gpiochip_node_group);
+	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)
@@ -430,20 +425,16 @@ static __init int x86_android_tablet_probe(struct platform_device *pdev)
 		break;
 	}
 
-	if (gpiochip_node_group) {
-		ret = software_node_register_node_group(gpiochip_node_group);
-		if (ret)
-			return ret;
-	}
+	ret = software_node_register_node_group(gpiochip_node_group);
+	if (ret)
+		return ret;
 
-	if (dev_info->swnode_group) {
-		ret = software_node_register_node_group(dev_info->swnode_group);
-		if (ret) {
-			x86_android_tablet_remove(pdev);
-			return ret;
-		}
-		swnode_group = dev_info->swnode_group;
+	ret = software_node_register_node_group(dev_info->swnode_group);
+	if (ret) {
+		x86_android_tablet_remove(pdev);
+		return ret;
 	}
+	swnode_group = dev_info->swnode_group;
 
 	if (dev_info->init) {
 		ret = dev_info->init(&pdev->dev);
-- 
2.51.0

[PATCH v4 15/20] platform/x86: x86-android-tablets: Update my email address

[Hans de Goede]

hdegoede@redhat.com will stop working soon, replace it with my kernel.org
address.

Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hansg@kernel.org>
---
 drivers/platform/x86/x86-android-tablets/asus.c               | 2 +-
 drivers/platform/x86/x86-android-tablets/core.c               | 4 ++--
 drivers/platform/x86/x86-android-tablets/dmi.c                | 2 +-
 drivers/platform/x86/x86-android-tablets/lenovo.c             | 2 +-
 drivers/platform/x86/x86-android-tablets/other.c              | 2 +-
 drivers/platform/x86/x86-android-tablets/shared-psy-info.c    | 2 +-
 drivers/platform/x86/x86-android-tablets/shared-psy-info.h    | 2 +-
 drivers/platform/x86/x86-android-tablets/vexia_atla10_ec.c    | 2 +-
 .../platform/x86/x86-android-tablets/x86-android-tablets.h    | 2 +-
 9 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/platform/x86/x86-android-tablets/asus.c b/drivers/platform/x86/x86-android-tablets/asus.c
index 39eb2f9dc031..7d29c7654d21 100644
--- a/drivers/platform/x86/x86-android-tablets/asus.c
+++ b/drivers/platform/x86/x86-android-tablets/asus.c
@@ -5,7 +5,7 @@
  * devices typically have a bunch of things hardcoded, rather than specified
  * in their DSDT.
  *
- * Copyright (C) 2021-2023 Hans de Goede <hdegoede@redhat.com>
+ * Copyright (C) 2021-2023 Hans de Goede <hansg@kernel.org>
  */
 
 #include <linux/gpio/machine.h>
diff --git a/drivers/platform/x86/x86-android-tablets/core.c b/drivers/platform/x86/x86-android-tablets/core.c
index d0638664d1da..a8e9fa97b676 100644
--- a/drivers/platform/x86/x86-android-tablets/core.c
+++ b/drivers/platform/x86/x86-android-tablets/core.c
@@ -5,7 +5,7 @@
  * devices typically have a bunch of things hardcoded, rather than specified
  * in their DSDT.
  *
- * Copyright (C) 2021-2023 Hans de Goede <hdegoede@redhat.com>
+ * Copyright (C) 2021-2023 Hans de Goede <hansg@kernel.org>
  */
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
@@ -558,6 +558,6 @@ static void __exit x86_android_tablet_exit(void)
 }
 module_exit(x86_android_tablet_exit);
 
-MODULE_AUTHOR("Hans de Goede <hdegoede@redhat.com>");
+MODULE_AUTHOR("Hans de Goede <hansg@kernel.org>");
 MODULE_DESCRIPTION("X86 Android tablets DSDT fixups driver");
 MODULE_LICENSE("GPL");
diff --git a/drivers/platform/x86/x86-android-tablets/dmi.c b/drivers/platform/x86/x86-android-tablets/dmi.c
index 278c6d151dc4..ebba7400d5c9 100644
--- a/drivers/platform/x86/x86-android-tablets/dmi.c
+++ b/drivers/platform/x86/x86-android-tablets/dmi.c
@@ -5,7 +5,7 @@
  * devices typically have a bunch of things hardcoded, rather than specified
  * in their DSDT.
  *
- * Copyright (C) 2021-2023 Hans de Goede <hdegoede@redhat.com>
+ * Copyright (C) 2021-2023 Hans de Goede <hansg@kernel.org>
  */
 
 #include <linux/dmi.h>
diff --git a/drivers/platform/x86/x86-android-tablets/lenovo.c b/drivers/platform/x86/x86-android-tablets/lenovo.c
index 1f325b2947ab..832be02495b5 100644
--- a/drivers/platform/x86/x86-android-tablets/lenovo.c
+++ b/drivers/platform/x86/x86-android-tablets/lenovo.c
@@ -5,7 +5,7 @@
  * devices typically have a bunch of things hardcoded, rather than specified
  * in their DSDT.
  *
- * Copyright (C) 2021-2023 Hans de Goede <hdegoede@redhat.com>
+ * Copyright (C) 2021-2023 Hans de Goede <hansg@kernel.org>
  */
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
diff --git a/drivers/platform/x86/x86-android-tablets/other.c b/drivers/platform/x86/x86-android-tablets/other.c
index 174f02322e52..bc473979e4f6 100644
--- a/drivers/platform/x86/x86-android-tablets/other.c
+++ b/drivers/platform/x86/x86-android-tablets/other.c
@@ -5,7 +5,7 @@
  * devices typically have a bunch of things hardcoded, rather than specified
  * in their DSDT.
  *
- * Copyright (C) 2021-2023 Hans de Goede <hdegoede@redhat.com>
+ * Copyright (C) 2021-2023 Hans de Goede <hansg@kernel.org>
  */
 
 #include <linux/acpi.h>
diff --git a/drivers/platform/x86/x86-android-tablets/shared-psy-info.c b/drivers/platform/x86/x86-android-tablets/shared-psy-info.c
index 62f41c14e6ba..29fc466f76fe 100644
--- a/drivers/platform/x86/x86-android-tablets/shared-psy-info.c
+++ b/drivers/platform/x86/x86-android-tablets/shared-psy-info.c
@@ -5,7 +5,7 @@
  * devices typically have a bunch of things hardcoded, rather than specified
  * in their DSDT.
  *
- * Copyright (C) 2021-2023 Hans de Goede <hdegoede@redhat.com>
+ * Copyright (C) 2021-2023 Hans de Goede <hansg@kernel.org>
  */
 
 #include <linux/gpio/machine.h>
diff --git a/drivers/platform/x86/x86-android-tablets/shared-psy-info.h b/drivers/platform/x86/x86-android-tablets/shared-psy-info.h
index e5ba1c65d62b..149befba3330 100644
--- a/drivers/platform/x86/x86-android-tablets/shared-psy-info.h
+++ b/drivers/platform/x86/x86-android-tablets/shared-psy-info.h
@@ -5,7 +5,7 @@
  * devices typically have a bunch of things hardcoded, rather than specified
  * in their DSDT.
  *
- * Copyright (C) 2021-2023 Hans de Goede <hdegoede@redhat.com>
+ * Copyright (C) 2021-2023 Hans de Goede <hansg@kernel.org>
  */
 #ifndef __PDX86_SHARED_PSY_INFO_H
 #define __PDX86_SHARED_PSY_INFO_H
diff --git a/drivers/platform/x86/x86-android-tablets/vexia_atla10_ec.c b/drivers/platform/x86/x86-android-tablets/vexia_atla10_ec.c
index 5d02af1c5aaa..2f8cd8d9e0ab 100644
--- a/drivers/platform/x86/x86-android-tablets/vexia_atla10_ec.c
+++ b/drivers/platform/x86/x86-android-tablets/vexia_atla10_ec.c
@@ -256,6 +256,6 @@ static struct i2c_driver atla10_ec_driver = {
 };
 module_i2c_driver(atla10_ec_driver);
 
-MODULE_AUTHOR("Hans de Goede <hdegoede@redhat.com>");
+MODULE_AUTHOR("Hans de Goede <hansg@kernel.org>");
 MODULE_DESCRIPTION("Battery driver for Vexia EDU ATLA 10 tablet EC");
 MODULE_LICENSE("GPL");
diff --git a/drivers/platform/x86/x86-android-tablets/x86-android-tablets.h b/drivers/platform/x86/x86-android-tablets/x86-android-tablets.h
index 4bf4bcdf50c0..8e7d04bcb3f8 100644
--- a/drivers/platform/x86/x86-android-tablets/x86-android-tablets.h
+++ b/drivers/platform/x86/x86-android-tablets/x86-android-tablets.h
@@ -5,7 +5,7 @@
  * devices typically have a bunch of things hardcoded, rather than specified
  * in their DSDT.
  *
- * Copyright (C) 2021-2023 Hans de Goede <hdegoede@redhat.com>
+ * Copyright (C) 2021-2023 Hans de Goede <hansg@kernel.org>
  */
 #ifndef __PDX86_X86_ANDROID_TABLETS_H
 #define __PDX86_X86_ANDROID_TABLETS_H
-- 
2.51.0

[PATCH v4 16/20] platform/x86: x86-android-tablets: Move Acer info to its own file

[Hans de Goede]

Acer has several x86 based Android tablets which need x86-android-tablets
support to work around their broken ACPI tables.

At the moment x86-android-tablets only support one model, move this to
its own file before adding support for more models to avoid needing to
move more code around later.

Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hansg@kernel.org>
---
Changes in v3:
- Rebase on top of Dmitry's GPIO software node reference series and
  include it as part of this series
---
 .../platform/x86/x86-android-tablets/Makefile |  2 +-
 .../platform/x86/x86-android-tablets/acer.c   | 87 +++++++++++++++++++
 .../platform/x86/x86-android-tablets/other.c  | 70 ---------------
 3 files changed, 88 insertions(+), 71 deletions(-)
 create mode 100644 drivers/platform/x86/x86-android-tablets/acer.c

diff --git a/drivers/platform/x86/x86-android-tablets/Makefile b/drivers/platform/x86/x86-android-tablets/Makefile
index 313be30548bc..a2cf8cbdb351 100644
--- a/drivers/platform/x86/x86-android-tablets/Makefile
+++ b/drivers/platform/x86/x86-android-tablets/Makefile
@@ -6,4 +6,4 @@
 obj-$(CONFIG_X86_ANDROID_TABLETS) += vexia_atla10_ec.o
 obj-$(CONFIG_X86_ANDROID_TABLETS) += x86-android-tablets.o
 x86-android-tablets-y := core.o dmi.o shared-psy-info.o \
-			 asus.o lenovo.o other.o
+			 acer.o asus.o lenovo.o other.o
diff --git a/drivers/platform/x86/x86-android-tablets/acer.c b/drivers/platform/x86/x86-android-tablets/acer.c
new file mode 100644
index 000000000000..e5850da8037a
--- /dev/null
+++ b/drivers/platform/x86/x86-android-tablets/acer.c
@@ -0,0 +1,87 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Board info for Acer X86 tablets which ship with Android as the factory image
+ * and which have broken DSDT tables. The factory kernels shipped on these
+ * devices typically have a bunch of things hardcoded, rather than specified
+ * in their DSDT.
+ *
+ * Copyright (C) 2021-2025 Hans de Goede <hansg@kernel.org>
+ */
+
+#include <linux/gpio/machine.h>
+#include <linux/gpio/property.h>
+#include <linux/platform_device.h>
+#include <linux/property.h>
+
+#include "shared-psy-info.h"
+#include "x86-android-tablets.h"
+
+/* Acer Iconia One 7 B1-750 has an Android factory image with everything hardcoded */
+static const char * const acer_b1_750_mount_matrix[] = {
+	"-1", "0", "0",
+	"0", "1", "0",
+	"0", "0", "1"
+};
+
+static const struct property_entry acer_b1_750_bma250e_props[] = {
+	PROPERTY_ENTRY_STRING_ARRAY("mount-matrix", acer_b1_750_mount_matrix),
+	{ }
+};
+
+static const struct software_node acer_b1_750_bma250e_node = {
+	.properties = acer_b1_750_bma250e_props,
+};
+
+static const struct property_entry acer_b1_750_novatek_props[] = {
+	PROPERTY_ENTRY_GPIO("reset-gpios", &baytrail_gpiochip_nodes[1], 26, GPIO_ACTIVE_LOW),
+	{ }
+};
+
+static const struct software_node acer_b1_750_novatek_node = {
+	.properties = acer_b1_750_novatek_props,
+};
+
+static const struct x86_i2c_client_info acer_b1_750_i2c_clients[] __initconst = {
+	{
+		/* Novatek NVT-ts touchscreen */
+		.board_info = {
+			.type = "nt11205-ts",
+			.addr = 0x34,
+			.dev_name = "NVT-ts",
+			.swnode = &acer_b1_750_novatek_node,
+		},
+		.adapter_path = "\\_SB_.I2C4",
+		.irq_data = {
+			.type = X86_ACPI_IRQ_TYPE_GPIOINT,
+			.chip = "INT33FC:02",
+			.index = 3,
+			.trigger = ACPI_EDGE_SENSITIVE,
+			.polarity = ACPI_ACTIVE_LOW,
+			.con_id = "NVT-ts_irq",
+		},
+	}, {
+		/* BMA250E accelerometer */
+		.board_info = {
+			.type = "bma250e",
+			.addr = 0x18,
+			.swnode = &acer_b1_750_bma250e_node,
+		},
+		.adapter_path = "\\_SB_.I2C3",
+		.irq_data = {
+			.type = X86_ACPI_IRQ_TYPE_GPIOINT,
+			.chip = "INT33FC:02",
+			.index = 25,
+			.trigger = ACPI_LEVEL_SENSITIVE,
+			.polarity = ACPI_ACTIVE_HIGH,
+			.con_id = "bma250e_irq",
+		},
+	},
+};
+
+const struct x86_dev_info acer_b1_750_info __initconst = {
+	.i2c_client_info = acer_b1_750_i2c_clients,
+	.i2c_client_count = ARRAY_SIZE(acer_b1_750_i2c_clients),
+	.pdev_info = int3496_pdevs,
+	.pdev_count = 1,
+	.gpiochip_type = X86_GPIOCHIP_BAYTRAIL,
+};
diff --git a/drivers/platform/x86/x86-android-tablets/other.c b/drivers/platform/x86/x86-android-tablets/other.c
index bc473979e4f6..ea7a01d7ccb4 100644
--- a/drivers/platform/x86/x86-android-tablets/other.c
+++ b/drivers/platform/x86/x86-android-tablets/other.c
@@ -22,76 +22,6 @@
 #include "shared-psy-info.h"
 #include "x86-android-tablets.h"
 
-/* Acer Iconia One 7 B1-750 has an Android factory image with everything hardcoded */
-static const char * const acer_b1_750_mount_matrix[] = {
-	"-1", "0", "0",
-	"0", "1", "0",
-	"0", "0", "1"
-};
-
-static const struct property_entry acer_b1_750_bma250e_props[] = {
-	PROPERTY_ENTRY_STRING_ARRAY("mount-matrix", acer_b1_750_mount_matrix),
-	{ }
-};
-
-static const struct software_node acer_b1_750_bma250e_node = {
-	.properties = acer_b1_750_bma250e_props,
-};
-
-static const struct property_entry acer_b1_750_novatek_props[] = {
-	PROPERTY_ENTRY_GPIO("reset-gpios", &baytrail_gpiochip_nodes[1], 26, GPIO_ACTIVE_LOW),
-	{ }
-};
-
-static const struct software_node acer_b1_750_novatek_node = {
-	.properties = acer_b1_750_novatek_props,
-};
-
-static const struct x86_i2c_client_info acer_b1_750_i2c_clients[] __initconst = {
-	{
-		/* Novatek NVT-ts touchscreen */
-		.board_info = {
-			.type = "nt11205-ts",
-			.addr = 0x34,
-			.dev_name = "NVT-ts",
-			.swnode = &acer_b1_750_novatek_node,
-		},
-		.adapter_path = "\\_SB_.I2C4",
-		.irq_data = {
-			.type = X86_ACPI_IRQ_TYPE_GPIOINT,
-			.chip = "INT33FC:02",
-			.index = 3,
-			.trigger = ACPI_EDGE_SENSITIVE,
-			.polarity = ACPI_ACTIVE_LOW,
-			.con_id = "NVT-ts_irq",
-		},
-	}, {
-		/* BMA250E accelerometer */
-		.board_info = {
-			.type = "bma250e",
-			.addr = 0x18,
-			.swnode = &acer_b1_750_bma250e_node,
-		},
-		.adapter_path = "\\_SB_.I2C3",
-		.irq_data = {
-			.type = X86_ACPI_IRQ_TYPE_GPIOINT,
-			.chip = "INT33FC:02",
-			.index = 25,
-			.trigger = ACPI_LEVEL_SENSITIVE,
-			.polarity = ACPI_ACTIVE_HIGH,
-			.con_id = "bma250e_irq",
-		},
-	},
-};
-
-const struct x86_dev_info acer_b1_750_info __initconst = {
-	.i2c_client_info = acer_b1_750_i2c_clients,
-	.i2c_client_count = ARRAY_SIZE(acer_b1_750_i2c_clients),
-	.pdev_info = int3496_pdevs,
-	.pdev_count = 1,
-	.gpiochip_type = X86_GPIOCHIP_BAYTRAIL,
-};
-
 /*
  * Advantech MICA-071
  * This is a standard Windows tablet, but it has an extra "quick launch" button
-- 
2.51.0

[PATCH v4 17/20] platform/x86: x86-android-tablets: Add support for Acer A1-840 tablet

[Hans de Goede]

Add support for the Acer Iconia One 8 A1-840 (non FHD version) tablet.

This tablet has the usual issues for tablets shipped with Android as
factory OS. The DSDT is broken in various ways, so i2c_clients for
various devices as well as the INT3496 platform-device for OTG extcon
handling need to be instantiated manually by x86-android-tablets.

This tablet is special in that it is the first time a Bay Trail device
has been found to use the Dollar Cove TI PMIC and the first time that
the PMIC's Coulomb Counter is used as fuel-gauge.

So far this PMIC has only been used together with Cherry Trail SoCs
and always in combination with a separate full-featured fuel-gauge IC.

Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hansg@kernel.org>
---
Changes in v3:
- Rebase on top of Dmitry's GPIO software node reference series and
  use GPIO swnode references instead of GPIO lookup tables
- Use the new swnode_group register mechanism to simplify init() and exit()
---
 .../platform/x86/x86-android-tablets/acer.c   | 160 ++++++++++++++++++
 .../platform/x86/x86-android-tablets/dmi.c    |  10 ++
 .../x86-android-tablets/x86-android-tablets.h |   1 +
 3 files changed, 171 insertions(+)

diff --git a/drivers/platform/x86/x86-android-tablets/acer.c b/drivers/platform/x86/x86-android-tablets/acer.c
index e5850da8037a..d48c70ffd992 100644
--- a/drivers/platform/x86/x86-android-tablets/acer.c
+++ b/drivers/platform/x86/x86-android-tablets/acer.c
@@ -16,6 +16,166 @@
 #include "shared-psy-info.h"
 #include "x86-android-tablets.h"
 
+/* Acer Iconia One 8 A1-840 (non FHD version) */
+static const struct property_entry acer_a1_840_bq24190_props[] = {
+	PROPERTY_ENTRY_REF("monitored-battery", &generic_lipo_4v2_battery_node),
+	PROPERTY_ENTRY_BOOL("omit-battery-class"),
+	PROPERTY_ENTRY_BOOL("disable-reset"),
+	{ }
+};
+
+static const struct software_node acer_a1_840_bq24190_node = {
+	.properties = acer_a1_840_bq24190_props,
+};
+
+static const struct property_entry acer_a1_840_touchscreen_props[] = {
+	PROPERTY_ENTRY_U32("touchscreen-size-x", 800),
+	PROPERTY_ENTRY_U32("touchscreen-size-y", 1280),
+	PROPERTY_ENTRY_GPIO("reset-gpios", &baytrail_gpiochip_nodes[1], 26, GPIO_ACTIVE_LOW),
+	{ }
+};
+
+static const struct software_node acer_a1_840_touchscreen_node = {
+	.properties = acer_a1_840_touchscreen_props,
+};
+
+static const struct x86_i2c_client_info acer_a1_840_i2c_clients[] __initconst = {
+	{
+		/* BQ24297 charger IC */
+		.board_info = {
+			.type = "bq24297",
+			.addr = 0x6b,
+			.dev_name = "bq24297",
+			.swnode = &acer_a1_840_bq24190_node,
+			.platform_data = &bq24190_pdata,
+		},
+		.adapter_path = "\\_SB_.I2C1",
+		.irq_data = {
+			.type = X86_ACPI_IRQ_TYPE_GPIOINT,
+			.chip = "INT33FC:02",
+			.index = 2,
+			.trigger = ACPI_EDGE_SENSITIVE,
+			.polarity = ACPI_ACTIVE_LOW,
+			.con_id = "bq24297_irq",
+		},
+	}, {
+		/* MPU6515 sensors */
+		.board_info = {
+			.type = "mpu6515",
+			.addr = 0x69,
+			.dev_name = "mpu6515",
+		},
+		.adapter_path = "\\_SB_.I2C3",
+		.irq_data = {
+			.type = X86_ACPI_IRQ_TYPE_APIC,
+			.index = 0x47,
+			.trigger = ACPI_EDGE_SENSITIVE,
+			.polarity = ACPI_ACTIVE_HIGH,
+		},
+	}, {
+		/* FT5416 touchscreen controller */
+		.board_info = {
+			.type = "edt-ft5x06",
+			.addr = 0x38,
+			.dev_name = "ft5416",
+			.swnode = &acer_a1_840_touchscreen_node,
+		},
+		.adapter_path = "\\_SB_.I2C4",
+		.irq_data = {
+			.type = X86_ACPI_IRQ_TYPE_APIC,
+			.index = 0x45,
+			.trigger = ACPI_EDGE_SENSITIVE,
+			.polarity = ACPI_ACTIVE_HIGH,
+		},
+	}
+};
+
+static const struct property_entry acer_a1_840_int3496_props[] __initconst = {
+	PROPERTY_ENTRY_GPIO("mux-gpios", &baytrail_gpiochip_nodes[2], 1, GPIO_ACTIVE_HIGH),
+	PROPERTY_ENTRY_GPIO("id-gpios", &baytrail_gpiochip_nodes[2], 18, GPIO_ACTIVE_HIGH),
+	{ }
+};
+
+static const struct platform_device_info acer_a1_840_pdevs[] __initconst = {
+	{
+		/* For micro USB ID pin handling */
+		.name = "intel-int3496",
+		.id = PLATFORM_DEVID_NONE,
+		.properties = acer_a1_840_int3496_props,
+	},
+};
+
+/* Properties for the Dollar Cove TI PMIC battery MFD child used as fuel-gauge */
+static const struct property_entry acer_a1_840_fg_props[] = {
+	PROPERTY_ENTRY_REF("monitored-battery", &generic_lipo_4v2_battery_node),
+	PROPERTY_ENTRY_STRING_ARRAY_LEN("supplied-from", bq24190_psy, 1),
+	PROPERTY_ENTRY_GPIO("charged-gpios", &baytrail_gpiochip_nodes[2], 10, GPIO_ACTIVE_HIGH),
+	{ }
+};
+
+static struct device *acer_a1_840_fg_dev;
+static struct fwnode_handle *acer_a1_840_fg_node;
+
+static int __init acer_a1_840_init(struct device *dev)
+{
+	int ret;
+
+	acer_a1_840_fg_dev = bus_find_device_by_name(&platform_bus_type, NULL, "chtdc_ti_battery");
+	if (!acer_a1_840_fg_dev)
+		return dev_err_probe(dev, -EPROBE_DEFER, "getting chtdc_ti_battery dev\n");
+
+	acer_a1_840_fg_node = fwnode_create_software_node(acer_a1_840_fg_props, NULL);
+	if (IS_ERR(acer_a1_840_fg_node)) {
+		ret = PTR_ERR(acer_a1_840_fg_node);
+		goto err_put;
+	}
+
+	ret = device_add_software_node(acer_a1_840_fg_dev,
+				       to_software_node(acer_a1_840_fg_node));
+	if (ret)
+		goto err_put;
+
+	return 0;
+
+err_put:
+	fwnode_handle_put(acer_a1_840_fg_node);
+	acer_a1_840_fg_node = NULL;
+	put_device(acer_a1_840_fg_dev);
+	acer_a1_840_fg_dev = NULL;
+	return ret;
+}
+
+static void acer_a1_840_exit(void)
+{
+	device_remove_software_node(acer_a1_840_fg_dev);
+	/*
+	 * Skip fwnode_handle_put(acer_a1_840_fg_node), instead leak the node.
+	 * The intel_dc_ti_battery driver may still reference the strdup-ed
+	 * "supplied-from" string. This string will be free-ed if the node
+	 * is released.
+	 */
+	acer_a1_840_fg_node = NULL;
+	put_device(acer_a1_840_fg_dev);
+	acer_a1_840_fg_dev = NULL;
+}
+
+static const char * const acer_a1_840_modules[] __initconst = {
+	"bq24190_charger",	/* For the Vbus regulator for intel-int3496 */
+	NULL
+};
+
+const struct x86_dev_info acer_a1_840_info __initconst = {
+	.i2c_client_info = acer_a1_840_i2c_clients,
+	.i2c_client_count = ARRAY_SIZE(acer_a1_840_i2c_clients),
+	.pdev_info = acer_a1_840_pdevs,
+	.pdev_count = ARRAY_SIZE(acer_a1_840_pdevs),
+	.gpiochip_type = X86_GPIOCHIP_BAYTRAIL,
+	.swnode_group = generic_lipo_4v2_battery_swnodes,
+	.modules = acer_a1_840_modules,
+	.init = acer_a1_840_init,
+	.exit = acer_a1_840_exit,
+};
+
 /* Acer Iconia One 7 B1-750 has an Android factory image with everything hardcoded */
 static const char * const acer_b1_750_mount_matrix[] = {
 	"-1", "0", "0",
diff --git a/drivers/platform/x86/x86-android-tablets/dmi.c b/drivers/platform/x86/x86-android-tablets/dmi.c
index ebba7400d5c9..4a5720d6fc1d 100644
--- a/drivers/platform/x86/x86-android-tablets/dmi.c
+++ b/drivers/platform/x86/x86-android-tablets/dmi.c
@@ -16,6 +16,16 @@
 #include "x86-android-tablets.h"
 
 const struct dmi_system_id x86_android_tablet_ids[] __initconst = {
+	{
+		/* Acer Iconia One 8 A1-840 (non FHD version) */
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Insyde"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "BayTrail"),
+			/* Above strings are too generic also match BIOS date */
+			DMI_MATCH(DMI_BIOS_DATE, "04/01/2014"),
+		},
+		.driver_data = (void *)&acer_a1_840_info,
+	},
 	{
 		/* Acer Iconia One 7 B1-750 */
 		.matches = {
diff --git a/drivers/platform/x86/x86-android-tablets/x86-android-tablets.h b/drivers/platform/x86/x86-android-tablets/x86-android-tablets.h
index 8e7d04bcb3f8..2498390958ad 100644
--- a/drivers/platform/x86/x86-android-tablets/x86-android-tablets.h
+++ b/drivers/platform/x86/x86-android-tablets/x86-android-tablets.h
@@ -111,6 +111,7 @@ extern const struct software_node cherryview_gpiochip_nodes[];
  * Extern declarations of x86_dev_info structs so there can be a single
  * MODULE_DEVICE_TABLE(dmi, ...), while splitting the board descriptions.
  */
+extern const struct x86_dev_info acer_a1_840_info;
 extern const struct x86_dev_info acer_b1_750_info;
 extern const struct x86_dev_info advantech_mica_071_info;
 extern const struct x86_dev_info asus_me176c_info;
-- 
2.51.0

[PATCH v4 18/20] platform/x86: x86-android-tablets: Simplify lenovo_yoga_tab2_830_1050_exit()

[Hans de Goede]

lenovo_yoga_tab2_830_1050_exit() only gets called after a successful
lenovo_yoga_tab2_830_1050_init() call so there is no need to check
if lenovo_yoga_tab2_830_1050_codec_[dev|pinctrl] are set.

Also change the exit() order to be the exact reverse of init().

Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hansg@kernel.org>
---
 drivers/platform/x86/x86-android-tablets/lenovo.c | 13 ++++---------
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/platform/x86/x86-android-tablets/lenovo.c b/drivers/platform/x86/x86-android-tablets/lenovo.c
index 832be02495b5..08cabaa5e0c0 100644
--- a/drivers/platform/x86/x86-android-tablets/lenovo.c
+++ b/drivers/platform/x86/x86-android-tablets/lenovo.c
@@ -594,15 +594,10 @@ static void lenovo_yoga_tab2_830_1050_exit(void)
 {
 	unregister_sys_off_handler(lenovo_yoga_tab2_830_1050_sys_off_handler);
 
-	if (lenovo_yoga_tab2_830_1050_codec_dev) {
-		device_remove_software_node(lenovo_yoga_tab2_830_1050_codec_dev);
-		put_device(lenovo_yoga_tab2_830_1050_codec_dev);
-	}
-
-	if (lenovo_yoga_tab2_830_1050_codec_pinctrl) {
-		pinctrl_put(lenovo_yoga_tab2_830_1050_codec_pinctrl);
-		pinctrl_unregister_mappings(&lenovo_yoga_tab2_830_1050_codec_pinctrl_map);
-	}
+	device_remove_software_node(lenovo_yoga_tab2_830_1050_codec_dev);
+	pinctrl_put(lenovo_yoga_tab2_830_1050_codec_pinctrl);
+	pinctrl_unregister_mappings(&lenovo_yoga_tab2_830_1050_codec_pinctrl_map);
+	put_device(lenovo_yoga_tab2_830_1050_codec_dev);
 }
 
 /*
-- 
2.51.0

[PATCH v4 19/20] platform/x86: x86-android-tablets: Fix modules lists for Lenovo devices

[Hans de Goede]

2 fixes for Lenovo tablets:

- The bq24190 charger on the Lenovo Yoga Tab2 830/1050 devices does not use
  the crystal-cove PMIC charger IRQ, so these shouldn't use bq24190_modules
  as that includes "intel_crystal_cove_charger"

- Both the Tab2 and the Tab3 devices have a SPI audio-codec which init()
  attaches properties to, resp. the whole SPI device gets instantiated by
  the x86-android-tablets code. This requires the "spi_pxa2xx_platform"
  module to be loaded before init() runs

Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hansg@kernel.org>
---
 .../platform/x86/x86-android-tablets/lenovo.c | 21 ++++++++++++-------
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/drivers/platform/x86/x86-android-tablets/lenovo.c b/drivers/platform/x86/x86-android-tablets/lenovo.c
index 08cabaa5e0c0..e3d3a8290949 100644
--- a/drivers/platform/x86/x86-android-tablets/lenovo.c
+++ b/drivers/platform/x86/x86-android-tablets/lenovo.c
@@ -443,6 +443,12 @@ static const struct software_node *lenovo_yoga_tab2_830_1050_swnodes[] = {
 static int __init lenovo_yoga_tab2_830_1050_init(struct device *dev);
 static void lenovo_yoga_tab2_830_1050_exit(void);
 
+static const char * const lenovo_yoga_tab2_modules[] __initconst = {
+	"spi_pxa2xx_platform",	/* For the SPI codec device */
+	"bq24190_charger",	/* For the Vbus regulator for int3496/lc824206xa */
+	NULL
+};
+
 const struct x86_dev_info lenovo_yoga_tab2_830_1050_info __initconst = {
 	.i2c_client_info = lenovo_yoga_tab2_830_1050_i2c_clients,
 	.i2c_client_count = ARRAY_SIZE(lenovo_yoga_tab2_830_1050_i2c_clients),
@@ -450,7 +456,7 @@ const struct x86_dev_info lenovo_yoga_tab2_830_1050_info __initconst = {
 	.pdev_count = ARRAY_SIZE(lenovo_yoga_tab2_830_1050_pdevs),
 	.gpio_button_swnodes = lenovo_yoga_tab2_830_1050_lid_swnodes,
 	.swnode_group = lenovo_yoga_tab2_830_1050_swnodes,
-	.modules = bq24190_modules,
+	.modules = lenovo_yoga_tab2_modules,
 	.gpiochip_type = X86_GPIOCHIP_BAYTRAIL,
 	.init = lenovo_yoga_tab2_830_1050_init,
 	.exit = lenovo_yoga_tab2_830_1050_exit,
@@ -767,11 +773,6 @@ static const struct platform_device_info lenovo_yoga_tab2_1380_pdevs[] __initcon
 	},
 };
 
-static const char * const lenovo_yoga_tab2_1380_modules[] __initconst = {
-	"bq24190_charger",            /* For the Vbus regulator for lc824206xa */
-	NULL
-};
-
 static int __init lenovo_yoga_tab2_1380_init(struct device *dev)
 {
 	int ret;
@@ -800,7 +801,7 @@ const struct x86_dev_info lenovo_yoga_tab2_1380_info __initconst = {
 	.pdev_count = ARRAY_SIZE(lenovo_yoga_tab2_1380_pdevs),
 	.gpio_button_swnodes = lenovo_yoga_tab2_830_1050_lid_swnodes,
 	.swnode_group = lenovo_yoga_tab2_830_1050_swnodes,
-	.modules = lenovo_yoga_tab2_1380_modules,
+	.modules = lenovo_yoga_tab2_modules,
 	.gpiochip_type = X86_GPIOCHIP_BAYTRAIL,
 	.init = lenovo_yoga_tab2_1380_init,
 	.exit = lenovo_yoga_tab2_830_1050_exit,
@@ -1061,12 +1062,18 @@ static int __init lenovo_yt3_init(struct device *dev)
 	return 0;
 }
 
+static const char * const lenovo_yt3_modules[] __initconst = {
+	"spi_pxa2xx_platform",	/* For the SPI codec device */
+	NULL
+};
+
 const struct x86_dev_info lenovo_yt3_info __initconst = {
 	.i2c_client_info = lenovo_yt3_i2c_clients,
 	.i2c_client_count = ARRAY_SIZE(lenovo_yt3_i2c_clients),
 	.spi_dev_info = lenovo_yt3_spi_devs,
 	.spi_dev_count = ARRAY_SIZE(lenovo_yt3_spi_devs),
 	.swnode_group = lenovo_yt3_swnodes,
+	.modules = lenovo_yt3_modules,
 	.gpiochip_type = X86_GPIOCHIP_CHERRYVIEW,
 	.init = lenovo_yt3_init,
 };
-- 
2.51.0

[PATCH v4 20/20] platform/x86: x86-android-tablets: Stop using EPROBE_DEFER

[Hans de Goede]

Since the x86-android-tablets code uses platform_create_bundle() it cannot
use EPROBE_DEFER and the driver-core will translate EPROBE_DEFER to ENXIO.

Stop using EPROBE_DEFER instead log an error and return ENODEV, or for non
fatal cases log a warning and return 0.

Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hansg@kernel.org>
---
 drivers/platform/x86/x86-android-tablets/core.c  | 6 ++++--
 drivers/platform/x86/x86-android-tablets/other.c | 6 ++++--
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/platform/x86/x86-android-tablets/core.c b/drivers/platform/x86/x86-android-tablets/core.c
index a8e9fa97b676..6588fae30356 100644
--- a/drivers/platform/x86/x86-android-tablets/core.c
+++ b/drivers/platform/x86/x86-android-tablets/core.c
@@ -276,8 +276,10 @@ get_serdev_controller_by_pci_parent(const struct x86_serdev_info *info)
 	struct pci_dev *pdev;
 
 	pdev = pci_get_domain_bus_and_slot(0, 0, info->ctrl.pci.devfn);
-	if (!pdev)
-		return ERR_PTR(-EPROBE_DEFER);
+	if (!pdev) {
+		pr_err("error could not get PCI serdev at devfn 0x%02x\n", info->ctrl.pci.devfn);
+		return ERR_PTR(-ENODEV);
+	}
 
 	/* This puts our reference on pdev and returns a ref on the ctrl */
 	return get_serdev_controller_from_parent(&pdev->dev, 0, info->ctrl_devname);
diff --git a/drivers/platform/x86/x86-android-tablets/other.c b/drivers/platform/x86/x86-android-tablets/other.c
index ea7a01d7ccb4..7532af2d72d1 100644
--- a/drivers/platform/x86/x86-android-tablets/other.c
+++ b/drivers/platform/x86/x86-android-tablets/other.c
@@ -711,8 +711,10 @@ static int __init vexia_edu_atla10_9v_init(struct device *dev)
 
 	/* Reprobe the SDIO controller to enumerate the now enabled Wifi module */
 	pdev = pci_get_domain_bus_and_slot(0, 0, PCI_DEVFN(0x11, 0));
-	if (!pdev)
-		return -EPROBE_DEFER;
+	if (!pdev) {
+		pr_warn("Could not get PCI SDIO at devfn 0x%02x\n", PCI_DEVFN(0x11, 0));
+		return 0;
+	}
 
 	ret = device_reprobe(&pdev->dev);
 	if (ret)
-- 
2.51.0

Re: [PATCH v4 14/20] platform/x86: x86-android-tablets: Simplify node-group [un]registration

[Andy Shevchenko]

On Sat, Sep 20, 2025 at 11:07 PM Hans de Goede <hansg@kernel.org> wrote:
>
> 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.

Reviewed-by: Andy Shevchenko <andy@kernel.org>

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v4 00/20] x86-android-tablets: convert to use GPIO references + Acer A1-840 support

[Ilpo Järvinen]

On Sat, 20 Sep 2025 22:06:53 +0200, Hans de Goede wrote:

> Original cover-letter from Dmitry's v2 posting:
> 
> "This series came about because now software nodes can be used to
> describe GPIOs (via PROPERTY_ENTRY_GPIO() macros) and I would like to
> eventually get rid of gpio_keys_platform_data structure.
> 
> So while I was doing the conversions from GPIO_LOOKUP() tables for
> gpio_keys devices I decided to convert the rest of them as well. Maybe
> some time in the future we can drop support for GPIO_LOOKUP() and rely
> on device properties exclusively."
> 
> [...]


Thank you for your contribution, it has been applied to my local
review-ilpo-next branch. Note it will show up in the public
platform-drivers-x86/review-ilpo-next branch only once I've pushed my
local branch there, which might take a while.

The list of commits applied:
[01/20] platform/x86: x86-android-tablets: convert Goodix devices to GPIO references
        commit: 18410aa9a7eb0d14e356938dd3731d80fbc63a9b
[02/20] platform/x86: x86-android-tablets: convert Wacom devices to GPIO references
        commit: da63c8c7efc659b43e41c17cf36f86fb3b1528df
[03/20] platform/x86: x86-android-tablets: convert HiDeep devices to GPIO references
        commit: b395bd659d69a2c541e1d29139c152820186da04
[04/20] platform/x86: x86-android-tablets: convert Novatek devices to GPIO references
        commit: b02961cfb5db0c8f3bae2e8a2ecd733bb7a80351
[05/20] platform/x86: x86-android-tablets: convert EDT devices to GPIO references
        commit: 390d5ea98d52c48d76a6698fecd76979d9486869
[06/20] platform/x86: x86-android-tablets: convert int3496 devices to GPIO references
        commit: 59c4c7c35fc0608e9d1950bac312ad468f2b13f4
[07/20] platform/x86: x86-android-tablets: convert wm1502 devices to GPIO references
        commit: 21b4d30ffb105b959937c997d66b9a9640e8faac
[08/20] platform/x86: x86-android-tablets: convert HID-I2C devices to GPIO references
        commit: baa146abe2e931dba74f77216bcb7d51ffb90fec
[09/20] platform/x86: x86-android-tablets: convert Yoga Tab2 fast charger to GPIO references
        commit: 2a20809592c230a0398bb49754b9ccd480efd2ad
[10/20] platform/x86: x86-android-tablets: remove support for GPIO lookup tables
        commit: 8aba782e0dd9480d593170c04a1382891f13a7df
[11/20] platform/x86: x86-android-tablets: convert gpio_keys devices to GPIO references
        commit: 0cf7267b7fc08506a408b666d32a3a7d34409412
[12/20] platform/x86: x86-android-tablets: replace bat_swnode with swnode_group
        commit: a4808b2cea16d3f00891f059c824e8efb02eb79e
[13/20] platform/x86: x86-android-tablets: use swnode_group instead of manual registering
        commit: 3ac7425599611213f7a6a3f4b15d677da1b36eac
[14/20] platform/x86: x86-android-tablets: Simplify node-group [un]registration
        commit: e79c3a11e2ec9b350464c02a2649214deef53399
[15/20] platform/x86: x86-android-tablets: Update my email address
        commit: 982733083fd9c596d83a2a80b4b07e79e574d028
[16/20] platform/x86: x86-android-tablets: Move Acer info to its own file
        commit: 13ebe111502e6bd2b80f601ef04b9eeb32b3e7fe
[17/20] platform/x86: x86-android-tablets: Add support for Acer A1-840 tablet
        commit: 3aa776857ffb3430a4bec67a384277ee49f8d298
[18/20] platform/x86: x86-android-tablets: Simplify lenovo_yoga_tab2_830_1050_exit()
        commit: f6e9dcdf47c47d29bf5958f463ffc69afe2f3f7c
[19/20] platform/x86: x86-android-tablets: Fix modules lists for Lenovo devices
        commit: 973a8cce1bcb3af7cb1be57f71eb0363645edede
[20/20] platform/x86: x86-android-tablets: Stop using EPROBE_DEFER
        commit: cbeab8fbf4dc51e9050892402ba44b35db6f2bd7

--
 i.

Re: [PATCH v4 01/20] platform/x86: x86-android-tablets: convert Goodix devices to GPIO references

[Yauhen Kharuzhy]

On Sat, Sep 20, 2025 at 10:06:54PM +0200, Hans de Goede wrote:
> From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> 
> 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/20251120-reset-gpios-swnodes-v7-0-a100493a0f4b@linaro.org/

-- 
Yauhen Kharuzhy

Re: [PATCH v4 01/20] platform/x86: x86-android-tablets: convert Goodix devices to GPIO references

[Andy Shevchenko]

+Cc: Bart.

On Mon, Feb 09, 2026 at 01:32:57AM +0200, Yauhen Kharuzhy wrote:
> On Sat, Sep 20, 2025 at 10:06:54PM +0200, Hans de Goede wrote:

> > 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/20251120-reset-gpios-swnodes-v7-0-a100493a0f4b@linaro.org/

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v4 01/20] platform/x86: x86-android-tablets: convert Goodix devices to GPIO references

[Bartosz Golaszewski]

On Mon, 9 Feb 2026 09:08:04 +0100, Andy Shevchenko
<andriy.shevchenko@intel.com> said:
> +Cc: Bart.
>
> On Mon, Feb 09, 2026 at 01:32:57AM +0200, Yauhen Kharuzhy wrote:
>> On Sat, Sep 20, 2025 at 10:06:54PM +0200, Hans de Goede wrote:
>
>> > 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.

Bartosz

Re: [PATCH v4 01/20] platform/x86: x86-android-tablets: convert Goodix devices to GPIO references

[Hans de Goede]

Hi Bartosz,

On 9-Feb-26 12:52, Bartosz Golaszewski wrote:
> On Mon, 9 Feb 2026 09:08:04 +0100, Andy Shevchenko
> <andriy.shevchenko@intel.com> said:
>> +Cc: Bart.
>>
>> On Mon, Feb 09, 2026 at 01:32:57AM +0200, Yauhen Kharuzhy wrote:
>>> On Sat, Sep 20, 2025 at 10:06:54PM +0200, Hans de Goede wrote:
>>
>>>> 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.

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/c60ccef1-7213-4dd7-8c10-e8ef03675bd8@kernel.org/

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/20250920200713.20193-1-hansg@kernel.org/

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/20250920200713.20193-1-hansg@kernel.org/

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.

Regards,

Hans

Re: [PATCH v4 01/20] platform/x86: x86-android-tablets: convert Goodix devices to GPIO references

[Hans de Goede]

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

...

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

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

That just leaves the non main SoC GPIOs used in combination
with the WM5102 codec and as mentioned I think for those it
would be best to just switch back to GPIO lookups by reverting:

[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

Regards,

Hans

Re: [PATCH v4 01/20] platform/x86: x86-android-tablets: convert Goodix devices to GPIO references

[Bartosz Golaszewski]

On Mon, 9 Feb 2026 15:00:40 +0100, Hans de Goede <hansg@kernel.org> said:
> Hi Bartosz,
>
> On 9-Feb-26 12:52, Bartosz Golaszewski wrote:
>> On Mon, 9 Feb 2026 09:08:04 +0100, Andy Shevchenko
>> <andriy.shevchenko@intel.com> said:
>>> +Cc: Bart.
>>>
>>> On Mon, Feb 09, 2026 at 01:32:57AM +0200, Yauhen Kharuzhy wrote:
>>>> On Sat, Sep 20, 2025 at 10:06:54PM +0200, Hans de Goede wrote:
>>>
>>>>> 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.
>
> 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/c60ccef1-7213-4dd7-8c10-e8ef03675bd8@kernel.org/
>
> 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/20250920200713.20193-1-hansg@kernel.org/
>

Using swnodes is better than lookup tables granted that we actually use the
swnodes. If we just keep comparing strings and only change the strings we
compare then that doesn't make much sense.

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

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

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

No need to attach anything - the main firmware node will do as explained
above.

> 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/20250920200713.20193-1-hansg@kernel.org/
>
> 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.

I'm not very fond of going back to comparing swnode names. I'm also not very
happy that this has only been noticed now - this change has been released in
v6.18! I would prefer to just fix the users and I'm ready to help with that.

Bart

Re: [PATCH v4 01/20] platform/x86: x86-android-tablets: convert Goodix devices to GPIO references

[Dmitry Torokhov]

Hi Bartosz, Hans,

On Mon, Feb 09, 2026 at 03:00:40PM +0100, Hans de Goede wrote:
> Hi Bartosz,
> 
> On 9-Feb-26 12:52, Bartosz Golaszewski wrote:
> > On Mon, 9 Feb 2026 09:08:04 +0100, Andy Shevchenko
> > <andriy.shevchenko@intel.com> said:
> >> +Cc: Bart.
> >>
> >> On Mon, Feb 09, 2026 at 01:32:57AM +0200, Yauhen Kharuzhy wrote:
> >>> On Sat, Sep 20, 2025 at 10:06:54PM +0200, Hans de Goede wrote:
> >>
> >>>> 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

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

> > 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/c60ccef1-7213-4dd7-8c10-e8ef03675bd8@kernel.org/
> 
> 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/20250920200713.20193-1-hansg@kernel.org/
> 
> 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/20250920200713.20193-1-hansg@kernel.org/
> 
> 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.

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?

Thanks.

-- 
Dmitry

Re: [PATCH v4 01/20] platform/x86: x86-android-tablets: convert Goodix devices to GPIO references

[Dmitry Torokhov]

On Mon, Feb 09, 2026 at 08:36:01AM -0600, Bartosz Golaszewski wrote:
> On Mon, 9 Feb 2026 15:00:40 +0100, Hans de Goede <hansg@kernel.org> said:
> >
> > 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.
> >
> 
> 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?

Thanks.

-- 
Dmitry

Re: [PATCH v4 01/20] platform/x86: x86-android-tablets: convert Goodix devices to GPIO references

[Arnd Bergmann]

On Mon, Feb 9, 2026, at 15:41, Dmitry Torokhov wrote:
> On Mon, Feb 09, 2026 at 03:00:40PM +0100, Hans de Goede wrote:
>> On 9-Feb-26 12:52, Bartosz Golaszewski wrote:
>> > On Mon, 9 Feb 2026 09:08:04 +0100, Andy Shevchenko <andriy.shevchenko@intel.com> 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.

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

      Arnd

Re: [PATCH v4 01/20] platform/x86: x86-android-tablets: convert Goodix devices to GPIO references

[Andy Shevchenko]

+ Cc: Aaro for N770 case.

On Mon, Feb 09, 2026 at 04:13:26PM +0100, Arnd Bergmann wrote:
> On Mon, Feb 9, 2026, at 15:41, Dmitry Torokhov wrote:
> > On Mon, Feb 09, 2026 at 03:00:40PM +0100, Hans de Goede wrote:
> >> On 9-Feb-26 12:52, Bartosz Golaszewski wrote:
> >> > On Mon, 9 Feb 2026 09:08:04 +0100, Andy Shevchenko <andriy.shevchenko@intel.com> 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.
> 
> 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").

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v4 01/20] platform/x86: x86-android-tablets: convert Goodix devices to GPIO references

[Bartosz Golaszewski]

On Mon, 9 Feb 2026 15:41:54 +0100, Dmitry Torokhov
<dmitry.torokhov@gmail.com> said:
> Hi Bartosz, Hans,
>

[snip]

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

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

> 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:

> 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. :)

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

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?

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

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]

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

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.

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

Bartosz

Re: [PATCH v4 01/20] platform/x86: x86-android-tablets: convert Goodix devices to GPIO references

[Bartosz Golaszewski]

On Mon, 9 Feb 2026 15:41:54 +0100, Dmitry Torokhov
<dmitry.torokhov@gmail.com> said:
> Hi Bartosz, Hans,
>

[snip]

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

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

> 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:

> 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. :)

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

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?

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

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]

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

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.

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

Bartosz

Re: [PATCH v4 01/20] platform/x86: x86-android-tablets: convert Goodix devices to GPIO references

[Bartosz Golaszewski]

On Mon, 9 Feb 2026 15:46:55 +0100, Dmitry Torokhov
<dmitry.torokhov@gmail.com> said:
> On Mon, Feb 09, 2026 at 08:36:01AM -0600, Bartosz Golaszewski wrote:
>> On Mon, 9 Feb 2026 15:00:40 +0100, Hans de Goede <hansg@kernel.org> said:
>> >
>> > 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.
>> >
>>
>> 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?
>

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.

Bartosz

Re: [PATCH v4 01/20] platform/x86: x86-android-tablets: convert Goodix devices to GPIO references

[Dmitry Torokhov]

On Mon, Feb 09, 2026 at 10:30:25AM -0600, Bartosz Golaszewski wrote:
> On Mon, 9 Feb 2026 15:46:55 +0100, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> said:
> > On Mon, Feb 09, 2026 at 08:36:01AM -0600, Bartosz Golaszewski wrote:
> >> On Mon, 9 Feb 2026 15:00:40 +0100, Hans de Goede <hansg@kernel.org> said:
> >> >
> >> > 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.
> >> >
> >>
> >> 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?
> >
> 
> 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.

Thanks.

-- 
Dmitry

Re: [PATCH v4 01/20] platform/x86: x86-android-tablets: convert Goodix devices to GPIO references

[Bartosz Golaszewski]

On Mon, Feb 9, 2026 at 5:40 PM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> > >
> > > 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.
>
> 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?

Bartosz

Re: [PATCH v4 01/20] platform/x86: x86-android-tablets: convert Goodix devices to GPIO references

[Dmitry Torokhov]

On Mon, Feb 09, 2026 at 10:25:47AM -0600, Bartosz Golaszewski wrote:
> On Mon, 9 Feb 2026 15:41:54 +0100, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> said:
> > Hi Bartosz, Hans,
> >
> 
> [snip]
> 
> >> >>>
> >> >>> 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.
> >
> 
> I would even say that if we keep comparing strings, then it's no better
> than GPIO lookup tables.

I would like to stop using lookup tables so that we always excessive the
common (fwnode-based) paths for finding gpios in consumers, and not an
exception like we have with the lookup tables.

> 
> > 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:

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

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

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.

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

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

> 
> [snip]
> 
> >
> > 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.
> >
> 
> 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.

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

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

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

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

Thanks.

-- 
Dmitry

Re: [PATCH v4 01/20] platform/x86: x86-android-tablets: convert Goodix devices to GPIO references

[Dmitry Torokhov]

On Mon, Feb 09, 2026 at 05:45:55PM +0100, Bartosz Golaszewski wrote:
> On Mon, Feb 9, 2026 at 5:40 PM Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> >
> > > >
> > > > 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.
> >
> > 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?

As I mentioned in the other subthread - to be able to use static
property entries to describe the rest of the setup and being able to
drop support for bespoke platform data from the generic drivers. 

Thanks.

-- 
Dmitry

Re: [PATCH v4 01/20] platform/x86: x86-android-tablets: convert Goodix devices to GPIO references

[Bartosz Golaszewski]

On Mon, Feb 9, 2026 at 6:23 PM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> On Mon, Feb 09, 2026 at 10:25:47AM -0600, Bartosz Golaszewski wrote:
> > On Mon, 9 Feb 2026 15:41:54 +0100, Dmitry Torokhov
> > <dmitry.torokhov@gmail.com> said:
> > > Hi Bartosz, Hans,

[snip]

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

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

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

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.

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

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

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

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

> >
> > [snip]
> >
> > >
> > > 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.
> > >
> >
> > 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.

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

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

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

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

Bartosz

Re: [PATCH v4 01/20] platform/x86: x86-android-tablets: convert Goodix devices to GPIO references

[Dmitry Torokhov]

On Mon, Feb 09, 2026 at 09:24:46PM +0100, Bartosz Golaszewski wrote:
> On Mon, Feb 9, 2026 at 6:23 PM Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> >
> > On Mon, Feb 09, 2026 at 10:25:47AM -0600, Bartosz Golaszewski wrote:
> > > On Mon, 9 Feb 2026 15:41:54 +0100, Dmitry Torokhov
> > > <dmitry.torokhov@gmail.com> said:
> > > > Hi Bartosz, Hans,
> 
> [snip]
> 
> >
> > 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.
> 
> > >
> > > 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.
> >
> > 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.
> 
> > >
> > > 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.
> >
> 
> 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.

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

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

Thank you.

> 
> > >
> > > [snip]
> > >
> > > >
> > > > 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.
> > > >
> > >
> > > 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.
> 
> > >
> > > 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.
> 
> > >
> > > > 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.
> >
> > 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/.
> 
> > >
> > > 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.
> >
> 
> 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).

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.

Thanks.

-- 
Dmitry

Re: [PATCH v4 01/20] platform/x86: x86-android-tablets: convert Goodix devices to GPIO references

[Yauhen Kharuzhy]

On Mon, Feb 09, 2026 at 03:18:55PM +0100, Hans de Goede wrote:
> On 9-Feb-26 15:00, Hans de Goede wrote:
> 
> ...
> 
> > 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.
> 
> 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


-- 
Yauhen Kharuzhy

Re: [PATCH v4 01/20] platform/x86: x86-android-tablets: convert Goodix devices to GPIO references

[Bartosz Golaszewski]

On Mon, 9 Feb 2026 21:41:49 +0100, Dmitry Torokhov
<dmitry.torokhov@gmail.com> said:
>>
>> 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.
>

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.

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

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

>
> OK, so maybe:
>
> 1. Restore the label matching as a fallback for now (keeping the fwnode
>    identity mapping as the first choice)

I sent a patch.

Bart

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

Re: [PATCH v4 01/20] platform/x86: x86-android-tablets: convert Goodix devices to GPIO references

[Hans de Goede]

Hi Yauhen,

Thank you for bringing this problem to our attention.

On 10-Feb-26 00:13, Yauhen Kharuzhy wrote:

...

> OK, but what about additional GPIO chips?

You could look those up by label and then manually
attach the swnode to the GPIO-controller device before
using the properties.

But since you are then still doing matching by label that
would be a bit silly and for now at least we are going with
restoring name based GPIO-controller swnode matching as
a fallback:

https://lore.kernel.org/linux-gpio/20260210094806.38146-1-bartosz.golaszewski@oss.qualcomm.com/

> 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

Oh nice you've patches for sound now :)

Is this working ?  Any plans to upstream this ?

Regards,

Hans

Re: [PATCH v4 01/20] platform/x86: x86-android-tablets: convert Goodix devices to GPIO references

[Yauhen Kharuzhy]

>
> Hi Yauhen,

> > 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 ?

Yes, sound is fully working for YB1-X90 and YB1-X91 on 6.18.6 (there
is a workaround for broken GPIO swnodes matching in stable >=6.18.4).
I started cleaning the patches and preparing to mainline but ran into
the problem under discussion.

-- 
Yauhen Kharuzhy

Re: [PATCH v4 01/20] platform/x86: x86-android-tablets: convert Goodix devices to GPIO references

[Dmitry Torokhov]

On Tue, Feb 10, 2026 at 01:53:11AM -0800, Bartosz Golaszewski wrote:
> On Mon, 9 Feb 2026 21:41:49 +0100, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> said:
> >>
> >> 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.
> >
> 
> 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.
> 
> >>
> >> 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.
> >
> 
> 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?

Thanks.

-- 
Dmitry

Re: [PATCH v4 01/20] platform/x86: x86-android-tablets: convert Goodix devices to GPIO references

[Bartosz Golaszewski]

On Thu, 12 Feb 2026 04:44:05 +0100, Dmitry Torokhov
<dmitry.torokhov@gmail.com> said:
>>
>> 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):

diff --git a/drivers/mfd/lpc_ich.c b/drivers/mfd/lpc_ich.c
index 4b7d0cb9340f1..ab9730dcd2688 100644
--- a/drivers/mfd/lpc_ich.c
+++ b/drivers/mfd/lpc_ich.c
@@ -45,6 +45,7 @@
 #include <linux/acpi.h>
 #include <linux/pci.h>
 #include <linux/pinctrl/pinctrl.h>
+#include <linux/property.h>
 #include <linux/mfd/core.h>
 #include <linux/mfd/lpc_ich.h>
 #include <linux/platform_data/itco_wdt.h>
@@ -125,11 +126,15 @@ static struct mfd_cell lpc_ich_wdt_cell = {
 	.ignore_resource_conflicts = true,
 };

+const struct software_node lpc_ich_gpio_swnode = { };
+EXPORT_SYMBOL(lpc_ich_gpio_swnode);
+
 static struct mfd_cell lpc_ich_gpio_cell = {
 	.name = "gpio_ich",
 	.num_resources = ARRAY_SIZE(gpio_ich_res),
 	.resources = gpio_ich_res,
 	.ignore_resource_conflicts = true,
+	.swnode = &lpc_ich_gpio_swnode,
 };

 #define INTEL_GPIO_RESOURCE_SIZE	0x1000
diff --git a/drivers/platform/x86/meraki-mx100.c
b/drivers/platform/x86/meraki-mx100.c
index 8c5276d985123..ce60c79ff700e 100644
--- a/drivers/platform/x86/meraki-mx100.c
+++ b/drivers/platform/x86/meraki-mx100.c
@@ -20,16 +20,13 @@
 #include <linux/input-event-codes.h>
 #include <linux/io.h>
 #include <linux/kernel.h>
+#include <linux/mfd/lpc_ich.h>
 #include <linux/module.h>
 #include <linux/platform_device.h>
 #include <linux/property.h>

-#define TINK_GPIO_DRIVER_NAME "gpio_ich"
-
-static const struct software_node gpio_ich_node = {
-	.name = TINK_GPIO_DRIVER_NAME,
-};
-
 /* LEDs */
 static const struct software_node tink_gpio_leds_node = {
 	.name = "meraki-mx100-leds",
@@ -38,7 +35,7 @@ static const struct software_node tink_gpio_leds_node = {
 static const struct property_entry tink_internet_led_props[] = {
 	PROPERTY_ENTRY_STRING("label", "mx100:green:internet"),
 	PROPERTY_ENTRY_STRING("linux,default-trigger", "default-on"),
-	PROPERTY_ENTRY_GPIO("gpios", &gpio_ich_node, 11, GPIO_ACTIVE_LOW),
+	PROPERTY_ENTRY_GPIO("gpios", &lpc_ich_gpio_swnode, 11, GPIO_ACTIVE_LOW),
 	{ }
 };

@@ -50,7 +47,7 @@ static const struct software_node tink_internet_led_node = {

 static const struct property_entry tink_lan2_led_props[] = {
 	PROPERTY_ENTRY_STRING("label", "mx100:green:lan2"),
-	PROPERTY_ENTRY_GPIO("gpios", &gpio_ich_node, 18, GPIO_ACTIVE_HIGH),
+	PROPERTY_ENTRY_GPIO("gpios", &lpc_ich_gpio_swnode, 18, GPIO_ACTIVE_HIGH),
 	{ }
 };

@@ -62,7 +59,7 @@ static const struct software_node tink_lan2_led_node = {

 static const struct property_entry tink_lan3_led_props[] = {
 	PROPERTY_ENTRY_STRING("label", "mx100:green:lan3"),
-	PROPERTY_ENTRY_GPIO("gpios", &gpio_ich_node, 20, GPIO_ACTIVE_HIGH),
+	PROPERTY_ENTRY_GPIO("gpios", &lpc_ich_gpio_swnode, 20, GPIO_ACTIVE_HIGH),
 	{ }
 };

@@ -74,7 +71,7 @@ static const struct software_node tink_lan3_led_node = {

 static const struct property_entry tink_lan4_led_props[] = {
 	PROPERTY_ENTRY_STRING("label", "mx100:green:lan4"),
-	PROPERTY_ENTRY_GPIO("gpios", &gpio_ich_node, 22, GPIO_ACTIVE_HIGH),
+	PROPERTY_ENTRY_GPIO("gpios", &lpc_ich_gpio_swnode, 22, GPIO_ACTIVE_HIGH),
 	{ }
 };

@@ -86,7 +83,7 @@ static const struct software_node tink_lan4_led_node = {

 static const struct property_entry tink_lan5_led_props[] = {
 	PROPERTY_ENTRY_STRING("label", "mx100:green:lan5"),
-	PROPERTY_ENTRY_GPIO("gpios", &gpio_ich_node, 23, GPIO_ACTIVE_HIGH),
+	PROPERTY_ENTRY_GPIO("gpios", &lpc_ich_gpio_swnode, 23, GPIO_ACTIVE_HIGH),
 	{ }
 };

@@ -98,7 +95,7 @@ static const struct software_node tink_lan5_led_node = {

 static const struct property_entry tink_lan6_led_props[] = {
 	PROPERTY_ENTRY_STRING("label", "mx100:green:lan6"),
-	PROPERTY_ENTRY_GPIO("gpios", &gpio_ich_node, 32, GPIO_ACTIVE_HIGH),
+	PROPERTY_ENTRY_GPIO("gpios", &lpc_ich_gpio_swnode, 32, GPIO_ACTIVE_HIGH),
 	{ }
 };

@@ -110,7 +107,7 @@ static const struct software_node tink_lan6_led_node = {

 static const struct property_entry tink_lan7_led_props[] = {
 	PROPERTY_ENTRY_STRING("label", "mx100:green:lan7"),
-	PROPERTY_ENTRY_GPIO("gpios", &gpio_ich_node, 34, GPIO_ACTIVE_HIGH),
+	PROPERTY_ENTRY_GPIO("gpios", &lpc_ich_gpio_swnode, 34, GPIO_ACTIVE_HIGH),
 	{ }
 };

@@ -122,7 +119,7 @@ static const struct software_node tink_lan7_led_node = {

 static const struct property_entry tink_lan8_led_props[] = {
 	PROPERTY_ENTRY_STRING("label", "mx100:green:lan8"),
-	PROPERTY_ENTRY_GPIO("gpios", &gpio_ich_node, 35, GPIO_ACTIVE_HIGH),
+	PROPERTY_ENTRY_GPIO("gpios", &lpc_ich_gpio_swnode, 35, GPIO_ACTIVE_HIGH),
 	{ }
 };

@@ -134,7 +131,7 @@ static const struct software_node tink_lan8_led_node = {

 static const struct property_entry tink_lan9_led_props[] = {
 	PROPERTY_ENTRY_STRING("label", "mx100:green:lan9"),
-	PROPERTY_ENTRY_GPIO("gpios", &gpio_ich_node, 36, GPIO_ACTIVE_HIGH),
+	PROPERTY_ENTRY_GPIO("gpios", &lpc_ich_gpio_swnode, 36, GPIO_ACTIVE_HIGH),
 	{ }
 };

@@ -146,7 +143,7 @@ static const struct software_node tink_lan9_led_node = {

 static const struct property_entry tink_lan10_led_props[] = {
 	PROPERTY_ENTRY_STRING("label", "mx100:green:lan10"),
-	PROPERTY_ENTRY_GPIO("gpios", &gpio_ich_node, 37, GPIO_ACTIVE_HIGH),
+	PROPERTY_ENTRY_GPIO("gpios", &lpc_ich_gpio_swnode, 37, GPIO_ACTIVE_HIGH),
 	{ }
 };

@@ -158,7 +155,7 @@ static const struct software_node tink_lan10_led_node = {

 static const struct property_entry tink_lan11_led_props[] = {
 	PROPERTY_ENTRY_STRING("label", "mx100:green:lan11"),
-	PROPERTY_ENTRY_GPIO("gpios", &gpio_ich_node, 48, GPIO_ACTIVE_HIGH),
+	PROPERTY_ENTRY_GPIO("gpios", &lpc_ich_gpio_swnode, 48, GPIO_ACTIVE_HIGH),
 	{ }
 };

@@ -170,7 +167,7 @@ static const struct software_node tink_lan11_led_node = {

 static const struct property_entry tink_ha_green_led_props[] = {
 	PROPERTY_ENTRY_STRING("label", "mx100:green:ha"),
-	PROPERTY_ENTRY_GPIO("gpios", &gpio_ich_node, 16, GPIO_ACTIVE_LOW),
+	PROPERTY_ENTRY_GPIO("gpios", &lpc_ich_gpio_swnode, 16, GPIO_ACTIVE_LOW),
 	{ }
 };

@@ -182,7 +179,7 @@ static const struct software_node tink_ha_green_led_node = {

 static const struct property_entry tink_ha_orange_led_props[] = {
 	PROPERTY_ENTRY_STRING("label", "mx100:orange:ha"),
-	PROPERTY_ENTRY_GPIO("gpios", &gpio_ich_node, 7, GPIO_ACTIVE_LOW),
+	PROPERTY_ENTRY_GPIO("gpios", &lpc_ich_gpio_swnode, 7, GPIO_ACTIVE_LOW),
 	{ }
 };

@@ -194,7 +191,7 @@ static const struct software_node
tink_ha_orange_led_node = {

 static const struct property_entry tink_usb_green_led_props[] = {
 	PROPERTY_ENTRY_STRING("label", "mx100:green:usb"),
-	PROPERTY_ENTRY_GPIO("gpios", &gpio_ich_node, 21, GPIO_ACTIVE_LOW),
+	PROPERTY_ENTRY_GPIO("gpios", &lpc_ich_gpio_swnode, 21, GPIO_ACTIVE_LOW),
 	{ }
 };

@@ -206,7 +203,7 @@ static const struct software_node
tink_usb_green_led_node = {

 static const struct property_entry tink_usb_orange_led_props[] = {
 	PROPERTY_ENTRY_STRING("label", "mx100:orange:usb"),
-	PROPERTY_ENTRY_GPIO("gpios", &gpio_ich_node, 19, GPIO_ACTIVE_LOW),
+	PROPERTY_ENTRY_GPIO("gpios", &lpc_ich_gpio_swnode, 19, GPIO_ACTIVE_LOW),
 	{ }
 };

@@ -230,7 +227,7 @@ static const struct software_node tink_gpio_keys_node = {
 static const struct property_entry tink_reset_key_props[] = {
 	PROPERTY_ENTRY_U32("linux,code", KEY_RESTART),
 	PROPERTY_ENTRY_STRING("label", "Reset"),
-	PROPERTY_ENTRY_GPIO("gpios", &gpio_ich_node, 60, GPIO_ACTIVE_LOW),
+	PROPERTY_ENTRY_GPIO("gpios", &lpc_ich_gpio_swnode, 60, GPIO_ACTIVE_LOW),
 	PROPERTY_ENTRY_U32("linux,input-type", EV_KEY),
 	PROPERTY_ENTRY_U32("debounce-interval", 100),
 	{ }
@@ -243,7 +240,6 @@ static const struct software_node tink_reset_key_node = {
 };

 static const struct software_node *tink_swnodes[] = {
-	&gpio_ich_node,
 	/* LEDs nodes */
 	&tink_gpio_leds_node,
 	&tink_internet_led_node,
diff --git a/include/linux/mfd/lpc_ich.h b/include/linux/mfd/lpc_ich.h
index 1fbda1f8967db..1819aa743c5c9 100644
--- a/include/linux/mfd/lpc_ich.h
+++ b/include/linux/mfd/lpc_ich.h
@@ -37,4 +37,6 @@ struct lpc_ich_info {
 	u8 use_gpio;
 };

+extern const struct software_node lpc_ich_gpio_swnode;
+
 #endif

Bart

Re: [PATCH v4 01/20] platform/x86: x86-android-tablets: convert Goodix devices to GPIO references

[Bartosz Golaszewski]

On Thu, 12 Feb 2026 11:01:02 +0100, Bartosz Golaszewski <brgl@kernel.org> said:
> On Thu, 12 Feb 2026 04:44:05 +0100, Dmitry Torokhov <dmitry.torokhov@gmail.com> said:
>>>
>>> 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):
>
> diff --git a/drivers/mfd/lpc_ich.c b/drivers/mfd/lpc_ich.c
> index 4b7d0cb9340f1..ab9730dcd2688 100644

[snip]

In fact: MFD cells are the easy use-case: we typically have a header in which
to expose the relevant software nodes. What's more complex is when there's
a GPIO controller that has an OF node but no definition in C of any kind.

If we don't want to dynamically wait for it to appear in the system or look
for its OF node, then I was thinking about something like this:

declare_future_fwnode_from_of_by_name(gpio_node, "gpio0");

static const struct property_entry consumer_props[] = {
	PROPERTY_ENTRY_GPIO("reset", gpio_node, 1, GPIO_ACTIVE_LOW),
	{ }
};

Where the gpio_node fwnode would be a proxy resolving the reference to
-EPROBE_DEFER until the tree is scanned, after which it would return the
actual fwnode we're looking for.

We could potentially also add declare_future_fwnode_from_dev_by_name() for
when we know the name of the device and are waiting for it to appear.

This way the deferal would happen inside gpiolib-swnode.c using the normal
path for waiting for devices to appear and this could be reused for other
such cases.

Bartosz

Re: [PATCH v4 01/20] platform/x86: x86-android-tablets: convert Goodix devices to GPIO references

[Andy Shevchenko]

On Wed, Feb 11, 2026 at 07:44:05PM -0800, Dmitry Torokhov wrote:
> On Tue, Feb 10, 2026 at 01:53:11AM -0800, Bartosz Golaszewski wrote:
> > On Mon, 9 Feb 2026 21:41:49 +0100, Dmitry Torokhov
> > <dmitry.torokhov@gmail.com> said:

...

> > 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?

For PCI devices the ACPI companion may or may not be present using _ADR()
method. And it's an optional, so some BIOSes might have it, but my gut
feelings that the majority don't provide that. It means there is no associated
firmware node.

To solve this one may think of adding the swnode to the GPIO device by default
at registration, the problem is that fwnode is a single linked list of maximum
two elements, and we have already GPIO drivers that use firmware node _and_
software node (Intel Galileo boards with Synopsys DesignWare GPIO IP).

To me it looks like we again bump into the very old design problem of fwnode.
The roadmap to fix that is:
- make sure we never ever dereference fwnode/of_node of struct device anywhere
except the driver core
- convert fwnode to be a (double linked) list of more than two elements
- decouple of_node/fwnode from struct device, so it will only have a list head
- introduce a simple priority for nodes, the head for the firmware, the tail
for the software nodes
- kill primary/secondary fwnode approach for good


-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v4 01/20] platform/x86: x86-android-tablets: convert Goodix devices to GPIO references

[Andy Shevchenko]

On Thu, Feb 12, 2026 at 02:01:02AM -0800, Bartosz Golaszewski wrote:
> On Thu, 12 Feb 2026 04:44:05 +0100, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> said:
> >>
> >> 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?

...

> +const struct software_node lpc_ich_gpio_swnode = { };

(With name, please!)

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v4 01/20] platform/x86: x86-android-tablets: convert Goodix devices to GPIO references

[Dmitry Torokhov]

On Thu, Feb 12, 2026 at 12:28:41PM +0200, Andy Shevchenko wrote:
> On Thu, Feb 12, 2026 at 02:01:02AM -0800, Bartosz Golaszewski wrote:
> > On Thu, 12 Feb 2026 04:44:05 +0100, Dmitry Torokhov
> > <dmitry.torokhov@gmail.com> said:
> > >>
> > >> 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):

I see. I guess what I do not like about this approach is that it
introduces link dependency and may affect load order. I guess it is
ok...

> 
> 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?
> 
> ...
> 
> > +const struct software_node lpc_ich_gpio_swnode = { };
> 
> (With name, please!)

That we could match against... /duck

-- 
Dmitry

Re: [PATCH v4 01/20] platform/x86: x86-android-tablets: convert Goodix devices to GPIO references

[Andy Shevchenko]

On Thu, Feb 12, 2026 at 07:49:31AM -0800, Dmitry Torokhov wrote:
> On Thu, Feb 12, 2026 at 12:28:41PM +0200, Andy Shevchenko wrote:
> > On Thu, Feb 12, 2026 at 02:01:02AM -0800, Bartosz Golaszewski wrote:
> > > On Thu, 12 Feb 2026 04:44:05 +0100, Dmitry Torokhov
> > > <dmitry.torokhov@gmail.com> said:

...

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

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v4 01/20] platform/x86: x86-android-tablets: convert Goodix devices to GPIO references

[Andy Shevchenko]

On Thu, Feb 12, 2026 at 06:12:56PM +0200, Andy Shevchenko wrote:
> On Thu, Feb 12, 2026 at 07:49:31AM -0800, Dmitry Torokhov wrote:
> > On Thu, Feb 12, 2026 at 12:28:41PM +0200, Andy Shevchenko wrote:
> > > On Thu, Feb 12, 2026 at 02:01:02AM -0800, Bartosz Golaszewski wrote:
> > > > On Thu, 12 Feb 2026 04:44:05 +0100, Dmitry Torokhov
> > > > <dmitry.torokhov@gmail.com> said:

...

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

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v4 01/20] platform/x86: x86-android-tablets: convert Goodix devices to GPIO references

[Dmitry Torokhov]

On Thu, Feb 12, 2026 at 06:14:28PM +0200, Andy Shevchenko wrote:
> On Thu, Feb 12, 2026 at 06:12:56PM +0200, Andy Shevchenko wrote:
> > On Thu, Feb 12, 2026 at 07:49:31AM -0800, Dmitry Torokhov wrote:
> > > On Thu, Feb 12, 2026 at 12:28:41PM +0200, Andy Shevchenko wrote:
> > > > On Thu, Feb 12, 2026 at 02:01:02AM -0800, Bartosz Golaszewski wrote:
> > > > > On Thu, 12 Feb 2026 04:44:05 +0100, Dmitry Torokhov
> > > > > <dmitry.torokhov@gmail.com> said:
> 
> ...
> 
> > > > > +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.

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

Thanks.

-- 
Dmitry

Re: [PATCH v4 01/20] platform/x86: x86-android-tablets: convert Goodix devices to GPIO references

[Bartosz Golaszewski]

On Thu, Feb 12, 2026 at 5:50 PM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> On Thu, Feb 12, 2026 at 06:14:28PM +0200, Andy Shevchenko wrote:
> > On Thu, Feb 12, 2026 at 06:12:56PM +0200, Andy Shevchenko wrote:
> > > On Thu, Feb 12, 2026 at 07:49:31AM -0800, Dmitry Torokhov wrote:
> > > > On Thu, Feb 12, 2026 at 12:28:41PM +0200, Andy Shevchenko wrote:
> > > > > On Thu, Feb 12, 2026 at 02:01:02AM -0800, Bartosz Golaszewski wrote:
> > > > > > On Thu, 12 Feb 2026 04:44:05 +0100, Dmitry Torokhov
> > > > > > <dmitry.torokhov@gmail.com> said:
> >
> > ...
> >
> > > > > > +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.
>
> 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.

Bart

Re: [PATCH v4 01/20] platform/x86: x86-android-tablets: convert Goodix devices to GPIO references

[Dmitry Torokhov]

On Thu, Feb 12, 2026 at 06:07:32PM +0100, Bartosz Golaszewski wrote:
> On Thu, Feb 12, 2026 at 5:50 PM Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> >
> > On Thu, Feb 12, 2026 at 06:14:28PM +0200, Andy Shevchenko wrote:
> > > On Thu, Feb 12, 2026 at 06:12:56PM +0200, Andy Shevchenko wrote:
> > > > On Thu, Feb 12, 2026 at 07:49:31AM -0800, Dmitry Torokhov wrote:
> > > > > On Thu, Feb 12, 2026 at 12:28:41PM +0200, Andy Shevchenko wrote:
> > > > > > On Thu, Feb 12, 2026 at 02:01:02AM -0800, Bartosz Golaszewski wrote:
> > > > > > > On Thu, 12 Feb 2026 04:44:05 +0100, Dmitry Torokhov
> > > > > > > <dmitry.torokhov@gmail.com> said:
> > >
> > > ...
> > >
> > > > > > > +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.
> >
> > 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.

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.

Thanks.

-- 
Dmitry

Re: [PATCH v4 01/20] platform/x86: x86-android-tablets: convert Goodix devices to GPIO references

[Bartosz Golaszewski]

On Thu, Feb 12, 2026 at 6:19 PM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> > > >
> > > > 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.
> > >
> >
> > 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.

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

Bartosz

Re: [PATCH v4 01/20] platform/x86: x86-android-tablets: convert Goodix devices to GPIO references

[Arnd Bergmann]

On Fri, Feb 13, 2026, at 14:41, Bartosz Golaszewski wrote:
> On Thu, Feb 12, 2026 at 6:19 PM Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
>>
>> 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.

Right, and we already have cases where a PCIe card contains a complex
SoC such as drivers/misc/lan966x_pci.c. In that case they chose to
use a DT overlay, which is more work initially than doing the same
thing with software nodes, but should scale to multiple identical
cards.

The cases I see of software nodes being used in mainline today
all seem to be for a fixed number of devices, either on an SoC
or on a specific board.

      Arnd

Re: [PATCH v4 01/20] platform/x86: x86-android-tablets: convert Goodix devices to GPIO references

[Hans de Goede]

Hi,

On 13-Feb-26 14:41, Bartosz Golaszewski wrote:
> On Thu, Feb 12, 2026 at 6:19 PM Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
>>>>>
>>>>> 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.
>>>>
>>>
>>> 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.

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 :)

Regards,

Hans

Re: [PATCH v4 01/20] platform/x86: x86-android-tablets: convert Goodix devices to GPIO references

[Bartosz Golaszewski]

On Fri, Feb 13, 2026 at 5:05 PM Hans de Goede <hansg@kernel.org> wrote:
>
> Hi,
>
> On 13-Feb-26 14:41, Bartosz Golaszewski wrote:
> > On Thu, Feb 12, 2026 at 6:19 PM Dmitry Torokhov
> > <dmitry.torokhov@gmail.com> wrote:
> >>>>>
> >>>>> 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.
> >>>>
> >>>
> >>> 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.
>
> 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.
>

In case I didn't make myself clear before this point but let me
rephrase: It's wrong for consumers to create software nodes *for*
their providers (GPIO or otherwise). I hope we all agree on this. The
situation you're describing should not be happening and we should work
towards fixing existing examples.

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

Yes, like the meraki series I sent earlier today.

Bartosz

> 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 :)
>

Re: [PATCH v4 01/20] platform/x86: x86-android-tablets: convert Goodix devices to GPIO references

[Dmitry Torokhov]

On Mon, Feb 09, 2026 at 04:13:26PM +0100, Arnd Bergmann wrote:
> On Mon, Feb 9, 2026, at 15:41, Dmitry Torokhov wrote:
> > On Mon, Feb 09, 2026 at 03:00:40PM +0100, Hans de Goede wrote:
> >> On 9-Feb-26 12:52, Bartosz Golaszewski wrote:
> >> > On Mon, 9 Feb 2026 09:08:04 +0100, Andy Shevchenko <andriy.shevchenko@intel.com> 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.
> 
> 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.

Arnd, what is the timeline for this?

Thanks.

-- 
Dmitry