Use the new automatic secondary fwnode API to ensure that when the
baytrail pinctrl device is added to the platform bus, the static
software node provided for drivers not able to use ACPI will get
automatically assigned as the secondary fwnode of the primary ACPI node.

Create a new header under linux/pinctrl/ containing intel-specific
symbols and declare the new variables there.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
 drivers/pinctrl/intel/pinctrl-baytrail.c | 40 +++++++++++++++++++++++++++++++-
 include/linux/pinctrl/intel.h            | 12 ++++++++++
 2 files changed, 51 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/intel/pinctrl-baytrail.c b/drivers/pinctrl/intel/pinctrl-baytrail.c
index 02fdadf2189afb0ff654c80c131f813b59d623d6..bd0ba7c3351c021584127b3679c59d7463cc8a57 100644
--- a/drivers/pinctrl/intel/pinctrl-baytrail.c
+++ b/drivers/pinctrl/intel/pinctrl-baytrail.c
@@ -22,6 +22,7 @@
 #include <linux/seq_file.h>
 #include <linux/string_helpers.h>
 
+#include <linux/pinctrl/intel.h>
 #include <linux/pinctrl/pinctrl.h>
 #include <linux/pinctrl/pinmux.h>
 #include <linux/pinctrl/pinconf.h>
@@ -1723,9 +1724,46 @@ static struct platform_driver byt_gpio_driver = {
 	},
 };
 
+const struct software_node baytrail_gpio_node_00 = {
+	.name = "INT33FC:00",
+};
+EXPORT_SYMBOL_NS_GPL(baytrail_gpio_node_00, "PINCTRL_INTEL");
+
+const struct software_node baytrail_gpio_node_01 = {
+	.name = "INT33FC:01",
+};
+EXPORT_SYMBOL_NS_GPL(baytrail_gpio_node_01, "PINCTRL_INTEL");
+
+const struct software_node baytrail_gpio_node_02 = {
+	.name = "INT33FC:02",
+};
+EXPORT_SYMBOL_NS_GPL(baytrail_gpio_node_02, "PINCTRL_INTEL");
+
+static const struct software_node *baytrail_gpio_node_group[] = {
+	&baytrail_gpio_node_00,
+	&baytrail_gpio_node_01,
+	&baytrail_gpio_node_02,
+	NULL
+};
+
+static struct software_node_auto_secondary byt_auto_secondary = {
+	.node_group = baytrail_gpio_node_group,
+	.bus = &platform_bus_type,
+};
+
 static int __init byt_gpio_init(void)
 {
-	return platform_driver_register(&byt_gpio_driver);
+	int ret;
+
+	ret = software_node_register_auto_secondary(&byt_auto_secondary);
+	if (ret)
+		return ret;
+
+	ret = platform_driver_register(&byt_gpio_driver);
+	if (ret)
+		software_node_unregister_auto_secondary(&byt_auto_secondary);
+
+	return ret;
 }
 subsys_initcall(byt_gpio_init);
 
diff --git a/include/linux/pinctrl/intel.h b/include/linux/pinctrl/intel.h
new file mode 100644
index 0000000000000000000000000000000000000000..d45f090adc1f532f866c98aeca144a4d83fa28f4
--- /dev/null
+++ b/include/linux/pinctrl/intel.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef __LINUX_PINCTRL_INTEL_H
+#define __LINUX_PINCTRL_INTEL_H
+
+struct software_node;
+
+extern const struct software_node baytrail_gpio_node_00;
+extern const struct software_node baytrail_gpio_node_01;
+extern const struct software_node baytrail_gpio_node_02;
+
+#endif /* __LINUX_PINCTRL_INTEL_H */

-- 
2.47.3

On Thu, Mar 19, 2026 at 05:10:55PM +0100, Bartosz Golaszewski wrote:
> Use the new automatic secondary fwnode API to ensure that when the
> baytrail pinctrl device is added to the platform bus, the static
> software node provided for drivers not able to use ACPI will get
> automatically assigned as the secondary fwnode of the primary ACPI node.
> 
> Create a new header under linux/pinctrl/ containing intel-specific
> symbols and declare the new variables there.

As I read the code, this doesn't need to be part of drivers/pinctrl/intel/.
I.o.w. I am unable to see why we need to penetrate the certain pinctrl
driver for this.

...

>  static int __init byt_gpio_init(void)
>  {
> -	return platform_driver_register(&byt_gpio_driver);
> +	int ret;
> +
> +	ret = software_node_register_auto_secondary(&byt_auto_secondary);
> +	if (ret)
> +		return ret;
> +
> +	ret = platform_driver_register(&byt_gpio_driver);
> +	if (ret)
> +		software_node_unregister_auto_secondary(&byt_auto_secondary);
> +
> +	return ret;
>  }

This hack can be done in similar way on how we do ACPI LPSS for those
platforms, i.e. in drivers/acpi/x86/lpss.c. No?

-- 
With Best Regards,
Andy Shevchenko

On Fri, Mar 20, 2026 at 11:39 AM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Thu, Mar 19, 2026 at 05:10:55PM +0100, Bartosz Golaszewski wrote:
> > Use the new automatic secondary fwnode API to ensure that when the
> > baytrail pinctrl device is added to the platform bus, the static
> > software node provided for drivers not able to use ACPI will get
> > automatically assigned as the secondary fwnode of the primary ACPI node.
> >
> > Create a new header under linux/pinctrl/ containing intel-specific
> > symbols and declare the new variables there.
>
> As I read the code, this doesn't need to be part of drivers/pinctrl/intel/.
> I.o.w. I am unable to see why we need to penetrate the certain pinctrl
> driver for this.
>

If old board files were an analogy, the kind of information software
nodes carry would live neither in the provider module nor in the
consumer driver. It would be defined in a third place - the board
file. Do we need something like this or should this logic be invoked
from the x86 platform driver that uses these GPIOs but accesses them
via the swnode lookup?

> ...
>
> >  static int __init byt_gpio_init(void)
> >  {
> > -     return platform_driver_register(&byt_gpio_driver);
> > +     int ret;
> > +
> > +     ret = software_node_register_auto_secondary(&byt_auto_secondary);
> > +     if (ret)
> > +             return ret;
> > +
> > +     ret = platform_driver_register(&byt_gpio_driver);
> > +     if (ret)
> > +             software_node_unregister_auto_secondary(&byt_auto_secondary);
> > +
> > +     return ret;
> >  }
>
> This hack can be done in similar way on how we do ACPI LPSS for those
> platforms, i.e. in drivers/acpi/x86/lpss.c. No?
>

Hey, this is not a hack! I'm coming up with a generic solution here. :)

It already is similar in that it uses a notifier. For v2 howevere, I
want to propose a mechanism for having multiple ways of matching real
fwnodes with software nodes.

Bart

On Mon, Mar 23, 2026 at 04:28:39PM +0100, Bartosz Golaszewski wrote:
> On Fri, Mar 20, 2026 at 11:39 AM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> >
> > On Thu, Mar 19, 2026 at 05:10:55PM +0100, Bartosz Golaszewski wrote:
> > > Use the new automatic secondary fwnode API to ensure that when the
> > > baytrail pinctrl device is added to the platform bus, the static
> > > software node provided for drivers not able to use ACPI will get
> > > automatically assigned as the secondary fwnode of the primary ACPI node.
> > >
> > > Create a new header under linux/pinctrl/ containing intel-specific
> > > symbols and declare the new variables there.
> >
> > As I read the code, this doesn't need to be part of drivers/pinctrl/intel/.
> > I.o.w. I am unable to see why we need to penetrate the certain pinctrl
> > driver for this.
> 
> If old board files were an analogy, the kind of information software
> nodes carry would live neither in the provider module nor in the
> consumer driver. It would be defined in a third place - the board
> file. Do we need something like this or should this logic be invoked
> from the x86 platform driver that uses these GPIOs but accesses them
> via the swnode lookup?

Yes, fine, and that file is kinda board files (or rather quirks) for the
Bay Trail, Braswell and a few more. Please, use that one instead, let's
keep drivers/pinctrl/intel/ clean from it.

...

> > >  static int __init byt_gpio_init(void)
> > >  {
> > > -     return platform_driver_register(&byt_gpio_driver);
> > > +     int ret;
> > > +
> > > +     ret = software_node_register_auto_secondary(&byt_auto_secondary);
> > > +     if (ret)
> > > +             return ret;
> > > +
> > > +     ret = platform_driver_register(&byt_gpio_driver);
> > > +     if (ret)
> > > +             software_node_unregister_auto_secondary(&byt_auto_secondary);
> > > +
> > > +     return ret;
> > >  }
> >
> > This hack can be done in similar way on how we do ACPI LPSS for those
> > platforms, i.e. in drivers/acpi/x86/lpss.c. No?
> 
> Hey, this is not a hack! I'm coming up with a generic solution here. :)

Sorry, let's call it solution.

> It already is similar in that it uses a notifier. For v2 howevere, I
> want to propose a mechanism for having multiple ways of matching real
> fwnodes with software nodes.

Good.

-- 
With Best Regards,
Andy Shevchenko

On Fri, Mar 20, 2026 at 12:38:24PM +0200, Andy Shevchenko wrote:
> On Thu, Mar 19, 2026 at 05:10:55PM +0100, Bartosz Golaszewski wrote:
> > Use the new automatic secondary fwnode API to ensure that when the
> > baytrail pinctrl device is added to the platform bus, the static
> > software node provided for drivers not able to use ACPI will get
> > automatically assigned as the secondary fwnode of the primary ACPI node.
> > 
> > Create a new header under linux/pinctrl/ containing intel-specific
> > symbols and declare the new variables there.
> 
> As I read the code, this doesn't need to be part of drivers/pinctrl/intel/.
> I.o.w. I am unable to see why we need to penetrate the certain pinctrl
> driver for this.

...

> >  static int __init byt_gpio_init(void)
> >  {
> > -	return platform_driver_register(&byt_gpio_driver);
> > +	int ret;
> > +
> > +	ret = software_node_register_auto_secondary(&byt_auto_secondary);
> > +	if (ret)
> > +		return ret;
> > +
> > +	ret = platform_driver_register(&byt_gpio_driver);
> > +	if (ret)
> > +		software_node_unregister_auto_secondary(&byt_auto_secondary);
> > +
> > +	return ret;
> >  }
> 
> This hack can be done in similar way on how we do ACPI LPSS for those
> platforms, i.e. in drivers/acpi/x86/lpss.c. No?

Note, that driver is used on above mentioned platforms. Without it they are
basically useless. With that said, requiring that driver is fine and good thing
to do on those platforms (Bay Trail and Cherry View).

-- 
With Best Regards,
Andy Shevchenko