Hi Masahiro,
On 25 August 2015 at 19:42, Masahiro Yamada yamada.masahiro@socionext.com wrote:
Hi Simon,
2015-08-26 11:26 GMT+09:00 Simon Glass sjg@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/ .
OK, well other that that:
Acked-by: Simon Glass sjg@chromium.org
Two more things: - What to do about tests? - Please can you check my patches here and provide your comments:
http://patchwork.ozlabs.org/patch/510082/ http://patchwork.ozlabs.org/patch/510079/
Regards, Simon