[U-Boot] Driver-model - Issue with early device_probe

[Simon Glass]

Hi Suneel,

On 17 February 2017 at 17:44, Suneel Garapati <suneelglinux at gmail.com> wrote:
> Hi All,
>  Request for help on the below issue.
>
>  Hi Simon,
>  As I suppose it is related to driver-model in u-boot.
>
>  One of the boards at Cavium has SPI as PCI device and I am trying to
>  enable CONFIG_ENV_IS_IN_SPI_FLASH for this device.
>
>  Below is the sequence which causes crash, due to early of probing for
>  all parent and children in PCI node of devicetree. As some drivers,
>  like network, have to have eth_initialize called before to have global
>  structures initialized.
>
>  1. Init_sequence_r in board_r.c calls initr_env before any other
>  framework init is called.
>  2. initr_env checks for the device to load environment from, SPI,
>  calls env_relocate_spec from env_sf.c
>  3. SPI probe is triggered from env_relocate_spec, because of driver
>  model framework, this internally triggers device_probe.
>  4. device_probe iterates on spi parent, PCI, and its childs and calls
>  probe on each of them.
>  5. This early probe call may work for some frameowrks but not for all.
>  6. Network drivers like thunderx_smi (pci device) probe calls
>  mdio_register, internally calls miiphy_get_dev_by_name which tries to
>  access list mii_devs, which is uninitialized at this moment and
>  crashes.
>  7. mii_devs is initialized through mii_phy_init, called from
>  initr_net->eth_initialize->eth_common_init.
>  8. initr_net is called much later in init_sequence_r.
>
>  There is no CONFIG item to have control on environment storage devices
>  like MMC,SPI,NOR flash device probes to be singled out in the
>  initr_env initcall.
>
>  Please suggest on how to fix it or workaround. Also, let me know if I
>  am missing something obvious here.

I think the root cause is that Ethernet PHYs do not yet use driver
model. If that were fixed, then things should work fine.

eth_common_init() is a work-around which should go away once we have
this support.

For now, you could call eth_common_init() from your board code (e.g.
in board_early_init_r()) perhaps? You may need to find a way to
disable the later call, but perhaps it will not matter?

Regards,
Simon