linux-kernel - Re: [PATCH] pinctrl: add pinctrl_register

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 3 Jun 2015 00:32:33 +0900
From:	Masahiro Yamada <yamada.masahiro@...ionext.com>
To:	Linus Walleij <linus.walleij@...aro.org>
Cc:	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	Sören Brinkmann <soren.brinkmann@...inx.com>,
	Arnd Bergmann <arnd@...db.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] pinctrl: add pinctrl_register_reason() to return proper
 error code

Hi Linus,


2015-06-02 21:56 GMT+09:00 Linus Walleij <linus.walleij@...aro.org>:
> On Fri, May 29, 2015 at 1:30 PM, Masahiro Yamada
> <yamada.masahiro@...ionext.com> wrote:
>
>> The pinctrl_register() just returns NULL on error, so the callers
>> can not know the exact reason of the failure.
>>
>> Some of the pinctrl drivers return -EINVAL, some -ENODEV, and some
>> -ENOMEM on error of pinctrl_register() , although the error code
>> might be different from the actual cause of the error.
>>
>> This new function, pinctrl_register_reason(), helps the drivers get
>> and return the appropriate error code.
>>
>> Signed-off-by: Masahiro Yamada <yamada.masahiro@...ionext.com>
>> Suggested-by: Arnd Bergmann <arnd@...db.de>
>
> It should be named pinctrl_register_strict() or something.
> "reason" is anyways wrong, should be "cause", but please
> use _strict().

OK, I will do it.


>> If this patch is accepted, I can send a series to replace
>> the pinctrl_register() in each driver with pinctrl_register_reason().
>
> If it is replaced *everywhere* there is no point in keeping
> a separate function. Then you should just do a big
> patch changing all usage sites and the original function.


If nobody is opposed to this, I can send a single big patch
replacing all the references.

In that case, we would not need _strict().

My concern is the sudden change of the function interface
will break drivers that are under development out of the source tree.



-- 
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/