On 22 February 2016 at 23:38, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 16 February 2016 at 02:31, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Fri, Feb 12, 2016 at 4:23 AM, Simon Glass sjg@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@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.