[U-Boot] [PATCH 1/2] dm: core: Add uclass_first_device_err() to return a valid device

[Simon Glass]

On 22 February 2016 at 23:38, Simon Glass <sjg at chromium.org> wrote:
> Hi Bin,
>
> On 16 February 2016 at 02:31, Bin Meng <bmeng.cn at gmail.com> wrote:
>> Hi Simon,
>>
>> On Fri, Feb 12, 2016 at 4:23 AM, Simon Glass <sjg at chromium.org> wrote:
>>> A common pattern is to call uclass_first_device() and then check if it
>>> actually returns a device. Add a new function which does this, returning
>>> an error if there are no devices in that uclass.
>>>
>>> Signed-off-by: Simon Glass <sjg at chromium.org>
>>> ---
>>>
>>>  drivers/core/uclass.c | 13 +++++++++++++
>>>  include/dm/uclass.h   | 15 +++++++++++++--
>>>  2 files changed, 26 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c
>>> index 12095e7..1141ce1 100644
>>> --- a/drivers/core/uclass.c
>>> +++ b/drivers/core/uclass.c
>>> @@ -401,6 +401,19 @@ int uclass_first_device(enum uclass_id id, struct udevice **devp)
>>>         return uclass_get_device_tail(dev, ret, devp);
>>>  }
>>>
>>> +int uclass_first_device_err(enum uclass_id id, struct udevice **devp)
>>
>> Or maybe another way is to change uclass_first_device() behavior to
>> return -ENODEV if device is not found? (move the return value test
>> logic into uclass_first_device)
>
> Yes, that was my original plan. But when I looked at the calls about
> half of them would find that annoying, and it would add extra logic.
> After all, if the error is -ENODEV then it means there is no device,
> but all is well. If the error is -EINVAL (for example), then the error
> would need to be returned by the caller of uclass_first_device().

Applied to u-boot-dm/next.