Subject: Re: [PATCH 14/19] powerpc: mpc83xx: Switch to of_platform_populate

From: J. Neuschäfer <[email-masked]>
Date: Fri, 10 Jan 2025 14:45:49 +0000

On Sun, Jan 05, 2025 at 02:28:37PM -0600, Rob Herring wrote:
> On Sat, Jan 4, 2025 at 8:50 AM J. Neuschäfer <[email-masked]> wrote:
> >
> > On Thu, Jan 02, 2025 at 12:51:47PM -0600, Rob Herring wrote:
> > > On Thu, Jan 2, 2025 at 12:32 PM J. Neuschäfer via B4 Relay
> > > <[email-masked]> wrote:
[...]
> > > >  static const struct of_device_id of_bus_ids[] __initconst = {
> > > >         { .type = "soc", },
> > >
> > > of_platform_populate() won't work on this match unless there's a
> > > compatible in the node, too. Can we use compatible instead or are
> > > there a bunch of them?
> >
> > In arch/powerpc/boot/dts, I can find the following cases of device_type
> > = "soc" without compatible = "simple-bus":
> >
[...]
> > - arch/powerpc/boot/dts/asp834x-redboot.dts  (MPC83xx!)
> > - arch/powerpc/boot/dts/ksi8560.dts          (MPC85xx)
> >
> > i.e. there is one affected devicetree. I can simply patch that one in
> > the next iteration.
> 
> You can, but that doesn't fix existing DTBs with your kernel change.
> 
> We either have to determine no one cares about that platform or the
> ABI or add a fixup to add the compatible property.

The last substantial change to asp834x-redboot.dts happened in 2009,
so I think it's fairly safe to suspect that any remaining users are
stuck with old software versions; new or recurring users will have to do
some debugging to get the board up and running anyway.

> > >
> > > > -       { .compatible = "soc", },
> > > >         { .compatible = "simple-bus" },
> > > >         { .compatible = "gianfar" },
> > > > -       { .compatible = "gpio-leds", },
> > > > -       { .type = "qe", },
> > > > -       { .compatible = "fsl,qe", },
> > >
> > > Better still would be if we could move the remaining ones to the
> > > default table and just call of_platform_default_populate().
> >
> > of_platform_default_populate does sound preferable.
> >
> > I'll investigate why exactly the "gianfar" match is necessary and how to
> > fix it in the corresponding driver (I don't think it's general enough to
> > warrant being listed in of_default_bus_match_table).
> 
> That may work too.

I have investigated this issue now and will include a patch in the next
version.

Best regards,
J. Neuschäfer