linux-kernel - Re: [RFC PATCH] pinctrl: pinctrl-single.c: init pinctrl single at arch

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, 8 Oct 2014 09:42:09 +0800
From:	He YunLei <heyunlei@...wei.com>
To:	Tony Lindgren <tony@...mide.com>
CC:	<linux-kernel@...r.kernel.org>, <grant.likely@...aro.org>,
	<robh+dt@...nel.org>, <wangbintian@...wei.com>,
	<liguozhu@...ilicon.com>, <kong.kongxinwei@...ilicon.com>
Subject: Re: [RFC PATCH] pinctrl: pinctrl-single.c:  init pinctrl single at
 arch_initcall time

On 2014/9/30 1:54, Tony Lindgren wrote:
> * He YunLei <heyunlei@...wei.com> [140929 03:32]:
>> On our arm platform, some modules (e.g. I2C bus driver) will use the
>> pinctrl-single driver to configure the SoC pin, but pinctrl-single driver
>> uses module_init time, that makes some modules initialize ahead the
>> pinctrl-single and fail to register.
>>
>> This patch promotes the initialization priority of pinctrl-single from
>> module_init time to arch_initcall time.
>
> This has come up earlier and so far in all cases the problem
> is that you have custom initcall levels for your other drivers.
>
> Get rid of custom initcall levels for your drivers and the
> problem goes away. There's no need to init the drivers earlier
> nowadays. If you have other dependencies then deferred probe
> helps but should be only needed for a limited number of cases.
>
> We want to initialize things later, not earlier in general. That
> removes the issues of no proper debug output while booting the
> kernel.
>
> Regards,
>
> Tony
>
>
>> Signed-off-by: Yunlei He <heyunlei@...wei.com>
>> Signed-off-by: Xinwei Kong <kong.kongxinwei@...ilicon.com>
>> ---
>>   drivers/pinctrl/pinctrl-single.c |   13 ++++++++++++-
>>   1 file changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/pinctrl/pinctrl-single.c
>> b/drivers/pinctrl/pinctrl-single.c
>> index 95dd9cf..4b9e5b9 100644
>> --- a/drivers/pinctrl/pinctrl-single.c
>> +++ b/drivers/pinctrl/pinctrl-single.c
>> @@ -2012,7 +2012,18 @@ static struct platform_driver pcs_driver = {
>>   #endif
>>   };
>>
>> -module_platform_driver(pcs_driver);
>> +static int __init pinctrl_single_init(void)
>> +{
>> +		return platform_driver_register(&pcs_driver);
>> +}
>> +
>> +static void __exit pinctrl_single_exit(void)
>> +{
>> +		platform_driver_unregister(&pcs_driver);
>> +}
>> +
>> +arch_initcall(pinctrl_single_init);
>> +module_exit(pinctrl_single_exit);
>>
>>   MODULE_AUTHOR("Tony Lindgren <tony@...mide.com>");
>>   MODULE_DESCRIPTION("One-register-per-pin type device tree based pinctrl
>> driver");
>> --
>> 1.7.9.5
>>
>
> .
>

Thanks for your review and I am really appreciated it, but in our arm 
platform, we haven't custom initcall levels for other drivers. Although 
deferred probe helps other drivers to register well, we are also 
confused for the issues of lots of pin request errors debug output while 
booting the kernel. Besides, if the number is bigger than the limited 
number, whether deferred probe can solve this problem.

Regards,
He YunLei

--
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/