Re: [PATCH] pci: bus: only call of_platform_populate() if CONFIG_OF is defined

[Lukas Wunner <lukas@wunner.de>]

On Sat, Jul 06, 2024 at 07:12:48PM +0200, Bartosz Golaszewski wrote:
> On Sat, Jul 6, 2024 at 10:43???AM Lukas Wunner <lukas@wunner.de> wrote:
> > On Wed, Jul 03, 2024 at 11:32:05AM +0200, Bartosz Golaszewski wrote:
> > > On Wed, Jul 3, 2024 at 11:15 AM Bert Karwatzki <spasswolf@web.de> wrote:
> > > > If of_platform_populate() is called when CONFIG_OF is not defined this
> > > > leads to spurious error messages of the following type:
> > > >  pci 0000:00:01.1: failed to populate child OF nodes (-19)
> > > >  pci 0000:00:02.1: failed to populate child OF nodes (-19)
[...]
> > > > --- a/drivers/pci/bus.c
> > > > +++ b/drivers/pci/bus.c
> > > > @@ -350,6 +350,7 @@ void pci_bus_add_device(struct pci_dev *dev)
> > > >
> > > >         pci_dev_assign_added(dev, true);
> > > >
> > > > +#ifdef CONFIG_OF
> > > >         if (pci_is_bridge(dev)) {
> > > 
> > > There's a better (less ifdeffery) fix on the list that I'll pick up
> > > later today[1].
> > >
> > > [1] https://lore.kernel.org/lkml/20240702180839.71491-1-superm1@kernel.org/T/
> >
> > That other fix doesn't feel very robust as it depends on
> > of_platform_populate() never returning -ENODEV in the
> > CONFIG_OF=y case.
> 
> If we even have to play these ifdef games then the stubs for
> of_platform_populate() are broken and should probably return 0 with
> !OF as otherwise the stubs themselves are useless.

The stub was introduced by commit 964dba283439 ("devicetree: Add empty
of_platform_populate() for !CONFIG_OF_ADDRESS (sparc)") some twelve
years ago.

From a brief look I'm under the impression that the commit used -ENODEV
on purpose (instead of 0).

There are 100 files in the kernel source tree referencing
of_platform_populate().  The majority is probably not compiled
in the CONFIG_OF=n case, nevertheless changing the stub risks
regressing some of those 100 callers unless great care is
observed.

Just making this conditional on IS_ENABLED(CONFIG_OF) is the
least risky option.

Thanks,

Lukas