Hi Heinrick,

On 19 April 2017 at 05:26, Heinrich Schuchardt <xypron.g...@gmx.de> wrote:
> When iterating over the devices of an uclass the iteration stops
> at the first device that cannot be probed.
> When calling booefi this will result in no block device being
> passed to the EFI executable if the first device cannot be probed.
>
> The problem was reported by Andreas Färber in
> https://lists.denx.de/pipermail/u-boot/2017-April/287432.html
>
> For testing I used an odroid-c2 with a dts including
> &sd_emmc_a {
>         status = "okay";
> }
> This device does not exist on the board and cannot be initialized.

I just re-read this thread and saw this point again.

If this is not on the board, shouldn't the device have "disabled" in its node?

>
> With the patch uclass_first_device and uclass_next_device
> iterate internally until they find the first device that can be
> probed or the end of the device list is reached.
>
> Debug output is provided for the two functions.
>
> Reported-by: Andreas Färber <afaer...@suse.de>
> Cc: Simon Glass <s...@chromium.org>
> Signed-off-by: Heinrich Schuchardt <xypron.g...@gmx.de>
> ---
> v2:
>   As suggested by Simon Glass correct uclass_first_device() and
>   uclass_next_device() instead of uclass_get_device_tail() to
>   avoid side effects.
> v1:
>   The original patch was posted as
>   core/uclass: uclass_get_device_tail: always set devp
>   https://lists.denx.de/pipermail/u-boot/2017-April/288068.html
> ---
>  drivers/core/uclass.c | 44 +++++++++++++++++++++++++++++++++-----------
>  1 file changed, 33 insertions(+), 11 deletions(-)

Regards,
Simon
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Reply via email to