All of lore.kernel.org
 help / color / mirror / Atom feed
* [U-Boot]  Driver-model - Issue with early device_probe
@ 2017-02-18  0:44 Suneel Garapati
  2017-02-22  3:59 ` Simon Glass
  0 siblings, 1 reply; 3+ messages in thread
From: Suneel Garapati @ 2017-02-18  0:44 UTC (permalink / raw)
  To: u-boot

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.

 Thanks,
 Suneel

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [U-Boot] Driver-model - Issue with early device_probe
  2017-02-18  0:44 [U-Boot] Driver-model - Issue with early device_probe Suneel Garapati
@ 2017-02-22  3:59 ` Simon Glass
  2017-02-24 18:39   ` Suneel Garapati
  0 siblings, 1 reply; 3+ messages in thread
From: Simon Glass @ 2017-02-22  3:59 UTC (permalink / raw)
  To: u-boot

Hi Suneel,

On 17 February 2017 at 17:44, Suneel Garapati <suneelglinux@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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [U-Boot] Driver-model - Issue with early device_probe
  2017-02-22  3:59 ` Simon Glass
@ 2017-02-24 18:39   ` Suneel Garapati
  0 siblings, 0 replies; 3+ messages in thread
From: Suneel Garapati @ 2017-02-24 18:39 UTC (permalink / raw)
  To: u-boot

On Tue, Feb 21, 2017 at 7:59 PM, Simon Glass <sjg@chromium.org> wrote:
> Hi Suneel,
>
> On 17 February 2017 at 17:44, Suneel Garapati <suneelglinux@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?

Thanks Simon,

Workaround - Using board_early_init_r to call eth_common_init() helps.
It matters if we dont disable the later call,  eth_devices will
re-initialize to NULL and miiphy_init will make it lose all mdio
inited devices.

Regards,
Suneel
>
> Regards,
> Simon

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2017-02-24 18:39 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-02-18  0:44 [U-Boot] Driver-model - Issue with early device_probe Suneel Garapati
2017-02-22  3:59 ` Simon Glass
2017-02-24 18:39   ` Suneel Garapati

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.