[PATCH v3 3/3] ARM: at91: remove unnecessary of_platform_default_populate calls

[Rob Herring]

On Wed, Apr 29, 2026 at 03:02:22PM +0200, Alexander Dahl wrote:
> Hello Miquel,
> 
> Am Wed, Apr 29, 2026 at 11:42:19AM +0200 schrieb Miquel Raynal:
> > Hi Alexander,
> > 
> > >     [    0.958298] bus: 'platform': add driver atmel-ebi
> > >     [    0.958451] platform 10000000.ebi: bus: 'platform': __driver_probe_device: matched device with driver atmel-ebi
> > >     [    0.958566] platform 10000000.ebi: error -EPROBE_DEFER: wait for supplier /ahb/apb/pinctrl at fffff400/ebi/ebi-data-lsb
> > >     [    0.958649] platform 10000000.ebi: Added to deferred list
> > >     [    0.959429] bus: 'platform': remove driver atmel-ebi
> > >     [    0.959540] driver: 'atmel-ebi': driver_release
> > 
> > Interesting.
> > 
> > If you look at the very last line of the driver, the EBI driver does not
> > use a standard "module_platform_driver" macro, it uses some kind of
> > run-once probe that is kept in an __init section:
> > https://elixir.bootlin.com/linux/v7.0.1/source/drivers/memory/atmel-ebi.c#L637
> > 
> > And this seems to be incompatible with probe deferrals:
> > https://elixir.bootlin.com/linux/v7.0.1/source/drivers/base/platform.c#L948
> 
> Indeed. o.O

Saravana, Is there something we can do to make this issue more obvious?

> 
> > I would suggest trying something alone these lines:
> > 
> > --- a/drivers/memory/atmel-ebi.c
> > +++ b/drivers/memory/atmel-ebi.c
> > @@ -633,5 +633,6 @@ static struct platform_driver atmel_ebi_driver = {
> >                 .of_match_table = atmel_ebi_id_table,
> >                 .pm = &atmel_ebi_pm_ops,
> >         },
> > +       .probe = atmel_ebi_probe,
> >  };
> > -builtin_platform_driver_probe(atmel_ebi_driver, atmel_ebi_probe);
> > +builtin_platform_driver(atmel_ebi_driver);
> > 
> > Memory taken by the probe function will remain mapped. That seems to be
> > the drawback.
> 
> This works.  Sent a patch, see:
> 
> https://lore.kernel.org/all/20260429125930.844790-1-ada@thorsis.com/
> 
> Regarding the drawback: This can't be much memory, can it?
> 
> Greets
> Alex
>