linux-kernel - Re: [PATCH 1/2] power: act8945a: add charger driver for ACT8945A

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]

Message-id: <568F5F15.8050602@samsung.com>
Date:	Fri, 08 Jan 2016 16:02:45 +0900
From:	Krzysztof Kozlowski <k.kozlowski@...sung.com>
To:	"Yang, Wenyou" <Wenyou.Yang@...el.com>
Cc:	Sebastian Reichel <sre@...nel.org>,
	Dmitry Eremin-Solenikov <dbaryshkov@...il.com>,
	David Woodhouse <dwmw2@...radead.org>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	"Ferre, Nicolas" <Nicolas.FERRE@...el.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>
Subject: Re: [PATCH 1/2] power: act8945a: add charger driver for ACT8945A

On 08.01.2016 15:43, Yang, Wenyou wrote:

[...]

>>> +static struct platform_driver act8945a_charger_driver = {
>>> +       .driver = {
>>> +               .name = "act8945a-charger",
>>> +       },
>>> +       .probe  = act8945a_charger_probe,
>>> +       .remove = act8945a_charger_remove, };
>>> +
>>> +static int __init act8945a_charger_init(void) {
>>> +       return platform_driver_register(&act8945a_charger_driver);
>>> +}
>>> +subsys_initcall(act8945a_charger_init);
>>
>> Why subsys_initcall? This should be regular module_platform_driver.
> 
> I want it to register early enough as MFD.  Maybe I am wrong.

No, you shouldn't manually order the probing by initcalls. This should
be registered as usual and, if needed, support deferred probing. In this
case I even can't find any reason to register it earlier than usual.


Best regards,
Krzysztof