Hi Masahiro, On 25 August 2015 at 19:42, Masahiro Yamada <yamada.masah...@socionext.com> wrote: > 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/ . > >
OK, well other that that: Acked-by: Simon Glass <s...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
