[U-Boot] [RFC v3 PATCH 2/4] pinctrl: add pin control uclass support

[Masahiro Yamada]

Hi Simon,



2015-08-26 11:26 GMT+09:00 Simon Glass <sjg at 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