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

[Alexander Dahl <ada@thorsis.com>]

Hello Miquel,

thanks for your kind reply, I think with your help I have new
information now.

First of all: I could reproduce on an off-the-shelve sam9x60-curiosity
board, which has mainline dts, so others should be able to reproduce,
too.  Tested with v7.0 release and today's master
(v7.1-rc1-58-gdca922e019dd7).  See below for details:

Am Mon, Apr 27, 2026 at 05:07:01PM +0200 schrieb Miquel Raynal:
> Hi Alexander,
> 
> On 24/04/2026 at 12:56:27 +02, Alexander Dahl <ada@thorsis.com> wrote:
> 
> > Hei hei,
> >
> > after few hints in IRC yesterday, I tried to understand why neither
> > the ebi driver nor the nand driver are probed, but I failed.  See
> > below.
> 
> Just to be clear, I would not expect the NAND driver to probe "alone",
> it is described as a child node of the EBI controller which has its own
> compatible. As a result, only the of_platform_populate() at the end of
> the probe of the EBI can lead to the NAND controller to probe. The EBI
> node being a child node of a "simple-bus", this is the one we should
> focus on, because it should be probed.

Right, this is how I understood it, too.

> One reason (trying to be creative) could the that Rob's patch is
> dropping an explicit populate that maybe kind of bypasses checks that
> the "official" populate does. So maybe there is one resource that is
> missing and which is not ignored as it used to be by the core device
> driver (likely, dd.c).
> 
> Can you enable CONFIG_DEBUG_DRIVER and see in the logs if anything pops
> up? Maybe trying to trace (manually) in the core why we do not attempt
> to probe the EBI controller by looking for possible conditions to bail
> out early. Pinctrl is one of them, so maybe just removing all pinctrl
> references in the DT may help troubleshooting this (obviously probe will
> fail if pinctrl is incorrect, but if it is attempted we will have a
> culprit).

Was not aware of that option before, produces a lot of output, but I
think helpful output for this kind of problem, not quoting the whole
kernel log, but what I think is relevant here:

    [    0.177130] device: '10000000.ebi': device_add
    [    0.177222] bus: 'platform': add device 10000000.ebi
    [    0.177343] PM: Adding info for platform:10000000.ebi
    [    0.177531] platform 10000000.ebi: Not linking /ahb/apb/clock-controller@fffffc00 - might never become dev
    [    0.177584] /ahb/ebi@10000000 Dropping the fwnode link to /ahb/apb/clock-controller@fffffc00
    …
    [    0.217944] device: 'platform:fffffa00.gpio--platform:10000000.ebi': device_add
    [    0.218200] platform 10000000.ebi: Linked as a sync state only consumer to fffffa00.gpio
    …
    [    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
    …
    [    1.170809] pinctrl-at91 ahb:apb:pinctrl@fffff400: driver: 'pinctrl-at91': driver_bound: bound to device
    [    1.170871] /ahb/apb/adc@f804c000 Linked as a fwnode consumer to /ahb/apb/pinctrl@fffff400
    [    1.170947] /ahb/apb/adc@f804c000 Dropping the fwnode link to /ahb/apb/pinctrl@fffff400/adc/adc-default
    [    1.171031] /ahb/apb/adc@f804c000 Dropping the fwnode link to /ahb/apb/pinctrl@fffff400/adc/adtrg-default
    [    1.171122] /ahb/apb/can@f8004000 Linked as a fwnode consumer to /ahb/apb/pinctrl@fffff400
    [    1.171184] /ahb/apb/can@f8004000 Dropping the fwnode link to /ahb/apb/pinctrl@fffff400/can1/can1-rx-tx
    [    1.171267] /ahb/apb/serial@fffff200 Linked as a fwnode consumer to /ahb/apb/pinctrl@fffff400
    [    1.171327] /ahb/apb/serial@fffff200 Dropping the fwnode link to /ahb/apb/pinctrl@fffff400/dbgu/dbgu-0
    [    1.171409] /ahb/ebi@10000000 Linked as a fwnode consumer to /ahb/apb/pinctrl@fffff400
    [    1.171464] /ahb/ebi@10000000 Dropping the fwnode link to /ahb/apb/pinctrl@fffff400/ebi/ebi-data-lsb
    [    1.171536] /ahb/ebi@10000000 Dropping the fwnode link to /ahb/apb/pinctrl@fffff400/ebi/ebi-addr-nand
    …
    [    1.176057] platform 10000000.ebi: Linked as a sync state only consumer to ahb:apb:pinctrl@fffff400
    [    1.176127] device: 'platform:ahb:apb:pinctrl@fffff400--platform:f802c000.ethernet': device_add
    …
    [    1.178167] devices_kset: Moving 10000000.ebi to end of list
    [    1.178191] PM: Moving platform:10000000.ebi to end of list
    [    1.178222] platform 10000000.ebi: Linked as a consumer to ahb:apb:pinctrl@fffff400
    [    1.178248] /ahb/ebi@10000000 Dropping the fwnode link to /ahb/apb/pinctrl@fffff400
    …
    [    3.431138] devices_kset: Moving 10000000.ebi to end of list
    [    3.431206] PM: Moving platform:10000000.ebi to end of list
    [    3.431256] platform 10000000.ebi: Retrying from deferred list
	…
    [    3.437765] UBI error: cannot open mtd rootfs, error -2

So the ebi driver is probed but returns with -EPROBE_DEFER, to my
interpretation because the pinctrl driver is not ready?  Later the
pinctrl driver drops the relation?  On retry from the deferred list
the driver does not probe again?  This feels strange, because other
drivers probe as usual after that "Retrying from deferred list"
message.  But other deferred drivers do not have that "remove driver"
and "driver release" messages.

The pinctrl itself seems to work, gpiodetect and gpioinfo show
reasonable output, gpio connected LED works as expected.

No time to dig into this further right now,
but sharing what I have so far anyways.

Greets
Alex