On 22 February 2016 at 23:38, Simon Glass <[email protected]> wrote: > Hi Bin, > > On 16 February 2016 at 02:31, Bin Meng <[email protected]> wrote: >> Hi Simon, >> >> On Fri, Feb 12, 2016 at 4:23 AM, Simon Glass <[email protected]> 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 <[email protected]> >>> --- >>> >>> 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. _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
