Re: [PATCH 2/4] pinctrl: intel: expose software nodes for baytrail GPIO devices

[Andy Shevchenko]

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

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