Re: [PATCH 2/4] pinctrl: intel: expose software nodes for baytrail GPIO devices
From: Bartosz Golaszewski
Date: Mon Mar 23 2026 - 12:02:03 EST
On Fri, Mar 20, 2026 at 11:39 AM Andy Shevchenko
<andriy.shevchenko@xxxxxxxxxxxxxxx> 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