[PATCH 0/2] platform/x86: meraki-mx100: create and use real software node links

[PATCH 0/2] platform/x86: meraki-mx100: create and use real software node links

[Bartosz Golaszewski]

Meraki-mx100 is one of the GPIOLIB users that abuses the software node
API by setting up a dummy software node without any logical link to the
GPIO controller it wants to use and uses the fact that the GPIO core
matches the controller's label against the swnode's name to make the
lookup work.

We want to remove this behavior from GPIOLIB in favor of actual matching
of firmware nodes but that would break this user. This series creates
a real software node in the MFD driver and references it from the meraki
driver.

This can be done in two patches and stay bisectable as the software
nodes, despite having the same name, will have different parents so
there are no kobject issues.

Merging: this should probably be acked by Hans or Ilpo and go through
the MFD tree for v7.1.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
Bartosz Golaszewski (2):
      mfd: lpc_ich: expose the GPIO controller cell's software node
      platform/x86: meraki-mx100: use real software node references

 drivers/mfd/lpc_ich.c               |  7 +++++++
 drivers/platform/x86/meraki-mx100.c | 40 ++++++++++++++++---------------------
 include/linux/mfd/lpc_ich.h         |  2 ++
 3 files changed, 26 insertions(+), 23 deletions(-)
---
base-commit: af98e93c5c39e6d0b87b42f0a32dd3066f795718
change-id: 20260213-meraki-swnodes-44430d8178b4

Best regards,
-- 
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

[PATCH 1/2] mfd: lpc_ich: expose the GPIO controller cell's software node

[Bartosz Golaszewski]

One of the users of this driver - meraki-mx100 - abuses the software
node API by setting up a dummy software node without any logical link to
this GPIO controller and uses the fact that the GPIO core matches the
controller's label against the swnode's name to make the lookup work.

We want to remove this behavior from GPIOLIB in favor of actual matching
of firmware nodes but that would break this user. To facilitate that:
create a software node for the GPIO controller cell and expose its
address in the provided MFD header.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
 drivers/mfd/lpc_ich.c       | 7 +++++++
 include/linux/mfd/lpc_ich.h | 2 ++
 2 files changed, 9 insertions(+)

diff --git a/drivers/mfd/lpc_ich.c b/drivers/mfd/lpc_ich.c
index 4b7d0cb9340f1ac51bf3845427ba1dee8cad5667..ffef785e86d34c4302f7f88a472e969c47616c9a 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,17 @@ static struct mfd_cell lpc_ich_wdt_cell = {
 	.ignore_resource_conflicts = true,
 };
 
+const struct software_node lpc_ich_gpio_swnode = {
+	.name = "gpio_ich",
+};
+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/include/linux/mfd/lpc_ich.h b/include/linux/mfd/lpc_ich.h
index 1fbda1f8967db41ba3bacd331e5d18dfa8ebca3c..1819aa743c5c9aa1ac51710bbdbbefab50670ebe 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

-- 
2.47.3

[PATCH 2/2] platform/x86: meraki-mx100: use real software node references

[Bartosz Golaszewski]

The lpc_ich MFD driver now exposes the software node associated with the
its GPIO controller cell. Remove the dummy software node from the
meraki-mx100 driver and reference the real one instead.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
 drivers/platform/x86/meraki-mx100.c | 40 ++++++++++++++++---------------------
 1 file changed, 17 insertions(+), 23 deletions(-)

diff --git a/drivers/platform/x86/meraki-mx100.c b/drivers/platform/x86/meraki-mx100.c
index 8c5276d98512390effcc9f2258a6061684420d11..170ae969bf014edb780fcbace16e50ead59dae71 100644
--- a/drivers/platform/x86/meraki-mx100.c
+++ b/drivers/platform/x86/meraki-mx100.c
@@ -20,16 +20,11 @@
 #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 +33,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 +45,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 +57,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 +69,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 +81,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 +93,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 +105,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 +117,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 +129,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 +141,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 +153,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 +165,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 +177,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 +189,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 +201,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 +225,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 +238,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,

-- 
2.47.3

Re: [PATCH 1/2] mfd: lpc_ich: expose the GPIO controller cell's software node

[Andy Shevchenko]

On Fri, Feb 13, 2026 at 09:25:24AM +0100, Bartosz Golaszewski wrote:
> One of the users of this driver - meraki-mx100 - abuses the software
> node API by setting up a dummy software node without any logical link to
> this GPIO controller and uses the fact that the GPIO core matches the
> controller's label against the swnode's name to make the lookup work.
> 
> We want to remove this behavior from GPIOLIB in favor of actual matching
> of firmware nodes but that would break this user. To facilitate that:
> create a software node for the GPIO controller cell and expose its
> address in the provided MFD header.

...

> +const struct software_node lpc_ich_gpio_swnode = {
> +	.name = "gpio_ich",
> +};
> +EXPORT_SYMBOL(lpc_ich_gpio_swnode);

Can we export in a dedicated namespace? Perhaps "LPC_ICH"?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 0/2] platform/x86: meraki-mx100: create and use real software node links

[Andy Shevchenko]

On Fri, Feb 13, 2026 at 09:25:23AM +0100, Bartosz Golaszewski wrote:
> Meraki-mx100 is one of the GPIOLIB users that abuses the software node
> API by setting up a dummy software node without any logical link to the
> GPIO controller it wants to use and uses the fact that the GPIO core
> matches the controller's label against the swnode's name to make the
> lookup work.
> 
> We want to remove this behavior from GPIOLIB in favor of actual matching
> of firmware nodes but that would break this user. This series creates
> a real software node in the MFD driver and references it from the meraki
> driver.

Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

> This can be done in two patches and stay bisectable as the software
> nodes, despite having the same name, will have different parents so
> there are no kobject issues.
> 
> Merging: this should probably be acked by Hans or Ilpo and go through
> the MFD tree for v7.1.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 1/2] mfd: lpc_ich: expose the GPIO controller cell's software node

[Bartosz Golaszewski]

On Fri, Feb 13, 2026 at 10:16 AM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Fri, Feb 13, 2026 at 09:25:24AM +0100, Bartosz Golaszewski wrote:
> > One of the users of this driver - meraki-mx100 - abuses the software
> > node API by setting up a dummy software node without any logical link to
> > this GPIO controller and uses the fact that the GPIO core matches the
> > controller's label against the swnode's name to make the lookup work.
> >
> > We want to remove this behavior from GPIOLIB in favor of actual matching
> > of firmware nodes but that would break this user. To facilitate that:
> > create a software node for the GPIO controller cell and expose its
> > address in the provided MFD header.
>
> ...
>
> > +const struct software_node lpc_ich_gpio_swnode = {
> > +     .name = "gpio_ich",
> > +};
> > +EXPORT_SYMBOL(lpc_ich_gpio_swnode);
>
> Can we export in a dedicated namespace? Perhaps "LPC_ICH"?
>

I can't test it so I would prefer to reduce the amount of runtime risk
introduced by this change. We can do it separately later.

Bartosz

Re: [PATCH 1/2] mfd: lpc_ich: expose the GPIO controller cell's software node

[Andy Shevchenko]

On Mon, Feb 16, 2026 at 09:51:18AM +0100, Bartosz Golaszewski wrote:
> On Fri, Feb 13, 2026 at 10:16 AM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Fri, Feb 13, 2026 at 09:25:24AM +0100, Bartosz Golaszewski wrote:

...

> > > +const struct software_node lpc_ich_gpio_swnode = {
> > > +     .name = "gpio_ich",
> > > +};
> > > +EXPORT_SYMBOL(lpc_ich_gpio_swnode);
> >
> > Can we export in a dedicated namespace? Perhaps "LPC_ICH"?
> 
> I can't test it so I would prefer to reduce the amount of runtime risk
> introduced by this change. We can do it separately later.

I didn't get this, In this patch you use _NS (And in any case this should be _GPL).
In the other you need to add MODULE_IMPORT_NS(). There is nothing which needs a HW
to test.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 1/2] mfd: lpc_ich: expose the GPIO controller cell's software node

[Bartosz Golaszewski]

On Mon, Feb 16, 2026 at 10:18 AM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Mon, Feb 16, 2026 at 09:51:18AM +0100, Bartosz Golaszewski wrote:
> > On Fri, Feb 13, 2026 at 10:16 AM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> > > On Fri, Feb 13, 2026 at 09:25:24AM +0100, Bartosz Golaszewski wrote:
>
> ...
>
> > > > +const struct software_node lpc_ich_gpio_swnode = {
> > > > +     .name = "gpio_ich",
> > > > +};
> > > > +EXPORT_SYMBOL(lpc_ich_gpio_swnode);
> > >
> > > Can we export in a dedicated namespace? Perhaps "LPC_ICH"?
> >
> > I can't test it so I would prefer to reduce the amount of runtime risk
> > introduced by this change. We can do it separately later.
>
> I didn't get this, In this patch you use _NS (And in any case this should be _GPL).
> In the other you need to add MODULE_IMPORT_NS(). There is nothing which needs a HW
> to test.
>

We're adding surface for an import failure but whatever, I don't mind adding it.

Bart

Re: [PATCH 1/2] mfd: lpc_ich: expose the GPIO controller cell's software node

[Andy Shevchenko]

On Mon, Feb 16, 2026 at 11:15:46AM +0100, Bartosz Golaszewski wrote:
> On Mon, Feb 16, 2026 at 10:18 AM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Mon, Feb 16, 2026 at 09:51:18AM +0100, Bartosz Golaszewski wrote:
> > > On Fri, Feb 13, 2026 at 10:16 AM Andy Shevchenko
> > > <andriy.shevchenko@linux.intel.com> wrote:
> > > > On Fri, Feb 13, 2026 at 09:25:24AM +0100, Bartosz Golaszewski wrote:

...

> > > > > +EXPORT_SYMBOL(lpc_ich_gpio_swnode);
> > > >
> > > > Can we export in a dedicated namespace? Perhaps "LPC_ICH"?
> > >
> > > I can't test it so I would prefer to reduce the amount of runtime risk
> > > introduced by this change. We can do it separately later.
> >
> > I didn't get this, In this patch you use _NS (And in any case this should be _GPL).
> > In the other you need to add MODULE_IMPORT_NS(). There is nothing which needs a HW
> > to test.

> We're adding surface for an import failure

Yes, that's the point, to avoid importing unneeded symbol just for unknown reasons.
That's why the _NS variants appeared for.

> but whatever, I don't mind adding it.

Thanks!

-- 
With Best Regards,
Andy Shevchenko