Hi Simon,
2015-08-26 11:26 GMT+09:00 Simon Glass <s...@chromium.org>: >> >> >>>> + return -EINVAL; >>> >>> That is normally used for an invalid device tree arg. How about -ENOSYS? >> >> >> >> This is the comment block in U-Boot: >> >> #define ENOSYS 38 /* Function not implemented */ >> >> >> And this is the one in Linux: >> >> /* >> * This error code is special: arch syscall entry code will return >> * -ENOSYS if users try to call a syscall that doesn't exist. To keep >> * failures of syscalls that really do exist distinguishable from >> * failures due to attempts to use a nonexistent syscall, syscall >> * implementations should refrain from returning -ENOSYS. >> */ >> #define ENOSYS 38 /* Invalid system call number */ >> >> >> >> From the comment above, I hesitate to use -ENOSYS for normal error cases. >> >> >> I chose ENOTSUPP for unimplemented functions and it is widely used >> in Linux's pinctrl drivers. > > OK, but in U-Boot we use -ENOSYS when there is no driver model method > defined for a call. The case you describe does not exist in U-Boot but > is analogous to a missing method. > > It doesn't much matter what one we use, but we do need to be consistent. > > If we now want to move to ENOTSUPP then we should change all existing > users. But ENOTSUPP says > > /* Operation not supported on transport endpoint */ > > which seems less applicable to me. I was hit by this, too. I asked the question in LKML: https://lkml.org/lkml/2015/7/3/166 I am not sure if you are convinced with this... I agree that we should be consistent with this, so I can send v5 with s/ENOSUPP/ENOSYS/ . -- Best Regards Masahiro Yamada _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
