getting rid of subsys_initcall usage? (was: Re: [PATCH RESEND] i2c: designware: use module_platform_driver)

[zhangfei gao]

On Thu, Sep 12, 2013 at 9:12 AM, zhangfei gao <zhangfei.gao at gmail.com> wrote:
> On Fri, Aug 30, 2013 at 4:27 PM, Tony Lindgren <tony at atomide.com> wrote:
>> * zhangfei gao <zhangfei.gao at gmail.com> [130829 23:36]:
>>> What about concerns from Wolfram:
>>> " Other people might be
>>> depending on subsys_initcall to get I2C active before they want to
>>> activate, say, PMICs. So, I fear regressions, since deferred probing
>>> might not be available in the needed places to avoid these regressions."
>>
>> There should not be any reason to get a PMIC activated
>> early on. The system should be booting already at that point,
>> and the PMIC related init can be done later on.
>>
>>> Is it too late using module_init for PMIC?
>>
>> You can probably do it as a fix early on during the -rc
>> cycle too. Of course it needs to be verified to work first :)
>>
>
> Dear Wolfram
>
> What's your suggestion about this issue.
> Use subsys_initcall, deferred probing still exist if base on pin control driver.
>
> Thanks

Dear Wolfram

Any plan about the patch?

On one hand, module_X_driver is trend to replace subsys_initcall

Refer from Mark
"We're trying to move away from needing to do this and to using deferred
probing to resolve init ordering issues.  Should we not be able to
convert the drivers to module_X_driver()?"

On the other hand, subsys_initcall still been defered if pin
controller driver been relied on.

Thanks