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

Tony Lindgren tony at atomide.com
Fri Aug 30 01:48:58 EDT 2013


* zhangfei gao <zhangfei.gao at gmail.com> [130829 04:03]:
> On Thu, Aug 29, 2013 at 4:58 PM, Linus Walleij <linus.walleij at linaro.org> wrote:
> > On Wed, Aug 28, 2013 at 11:57 AM, Wolfram Sang <wsa at the-dreams.de> wrote:
> >> On Tue, Aug 20, 2013 at 04:32:28PM +0800, Zhangfei Gao wrote:
> >
> >>> Instead of use platform_driver_probe, use module_platform_driver
> >>> To support deferred probing
> >>> Also subsys_initcall may too early to auto set pinctl
> >>>
> >>> Signed-off-by: Zhangfei Gao <zhangfei.gao at linaro.org>
> >>> Acked-by: Baruch Siach <baruch at tkos.co.il>
> >>
> >> This patch is tougher than it looks. You need it, because
> >> subsys_initcall may be too early for pinctrl.
> >
> > pinctrl is initialized very early, core_initcall().
> >
> > This is more a question of individual pin control drivers
> > and when they probe, and dependencies trying to take
> > a pinctrl handle before the pin controller is available
> > will be deferred. Even by those grabbed in the core
> > by drivers/base/pinctrl.c.
> 
> Thanks Linus.
> Your explanation is really make sense.
> 
> We use drivers/pinctrl/pinctrl-single.c, if subsys_initcall for
> pinctrl-single, no issue at all.

So far we've seen that if you have issues with this, the real
problem is that some other driver is trying to initialize way
too early probably because of legacy reasons that no longer
apply.

FYI, it's best to have all the drivers initialize with just
module_init and make them work as loadable modules because of
the following reasons:

1. You will get real console error messages when something
   goes wrong with no need for debug_ll and earlyprintk

2. By creating loadable driver modules you're already getting
   some protection from spaghetti code as the interfaces
   are defined

3. It will be easier for distros to support various ARM SoCs
   with loadable driver modules

Regards,

Tony



More information about the linux-arm-kernel mailing list