From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Glass Date: Tue, 21 Feb 2017 20:59:39 -0700 Subject: [U-Boot] Driver-model - Issue with early device_probe In-Reply-To: References: Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Suneel, On 17 February 2017 at 17:44, Suneel Garapati 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