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

From: Miquel Raynal <[email-masked]>
Date: Wed, 29 Apr 2026 16:31:16 +0200

On 29/04/2026 at 15:02:22 +02, Alexander Dahl <[email-masked]> 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@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
>
>> 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/[email-masked]/
>
> Regarding the drawback: This can't be much memory, can it?

I guess it is preferable to have the probe mapped at the cost of a few
hundred more RAM bytes than a brick...

Good to know that this fixed your problem.

Thanks,
Miquèl