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

[Simon Glass]

Hi Masahiro,

On 25 August 2015 at 00:32, Masahiro Yamada
<yamada.masahiro at socionext.com> wrote:
> Simon,
>
>
> I've just posted v4.
>
> Sorry for the delay.
>
>
>
> 2015-08-12 23:16 GMT+09:00 Simon Glass <sjg at chromium.org>:
>> Hi Masahiro,
>>
>> On 10 August 2015 at 10:05, Masahiro Yamada
>> <yamada.masahiro at socionext.com> wrote:
>>> This creates a new framework for handling of pin control devices,
>>> i.e. devices that control different aspects of package pins.
>>>
>>> This uclass handles pinmuxing and pin configuration; pinmuxing
>>> controls switching among silicon blocks that share certain physical
>>> pins, pin configuration handles electronic properties such as pin-
>>> biasing, load capacitance etc.
>>>
>>> This framework supports the same device tree bindings, but if you
>>> do not need full interface support, you can disable some features
>>> to reduce memory foot print.
>>>
>>> Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
>>> ---
>>>
>>>  drivers/Kconfig                   |   2 +
>>>  drivers/Makefile                  |   1 +
>>>  drivers/core/device.c             |   4 +
>>>  drivers/pinctrl/Kconfig           |  42 +++++
>>>  drivers/pinctrl/Makefile          |   2 +
>>>  drivers/pinctrl/pinctrl-generic.c | 351 ++++++++++++++++++++++++++++++++++++++
>>>  drivers/pinctrl/pinctrl-uclass.c  | 151 ++++++++++++++++
>>>  include/dm/pinctrl.h              | 218 +++++++++++++++++++++++
>>>  include/dm/uclass-id.h            |   2 +
>>>  9 files changed, 773 insertions(+)
>>>  create mode 100644 drivers/pinctrl/Kconfig
>>>  create mode 100644 drivers/pinctrl/Makefile
>>>  create mode 100644 drivers/pinctrl/pinctrl-generic.c
>>>  create mode 100644 drivers/pinctrl/pinctrl-uclass.c
>>>  create mode 100644 include/dm/pinctrl.h
>>>

[snip]

>
>
>>> +               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.

[snip]

Regards,
Simon