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
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
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
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
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
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
© 2016 - 2026 Red Hat, Inc.