* Santosh Shilimkar <santosh.shilimkar@xxxxxx> [121024 23:34]: > On Thursday 25 October 2012 06:12 AM, Tony Lindgren wrote: > >* Tony Lindgren <tony@xxxxxxxxxxx> [121024 17:36]: > >>* Santosh Shilimkar <santosh.shilimkar@xxxxxx> [121017 06:35]: > >>>(Looping Arnd and Olof) > >>> > >>>On Wednesday 17 October 2012 06:58 PM, Lokesh Vutla wrote: > >>>>When building omap_l3_noc/smx drivers as modules, the following > >>>>warning appears: > >>>> > >>>>CC [M] drivers/bus/omap_l3_smx.o > >>>>drivers/bus/omap_l3_smx.c:291: warning: data definition has no type or storage class > >>>>drivers/bus/omap_l3_smx.c:291: warning: type defaults to 'int' in declaration of 'postcore_initcall_sync' > >>>>drivers/bus/omap_l3_smx.c:291: warning: parameter names (without types) in function declaration > >>>>drivers/bus/omap_l3_smx.c:287: warning: 'omap3_l3_init' defined but not used > >>>>CC [M] drivers/bus/omap_l3_noc.o > >>>>drivers/bus/omap_l3_noc.c:260: warning: data definition has no type or storage class > >>>>drivers/bus/omap_l3_noc.c:260: warning: type defaults to 'int' in declaration of 'arch_initcall_sync' > >>>>drivers/bus/omap_l3_noc.c:260: warning: parameter names (without types) in function declaration > >>>>drivers/bus/omap_l3_noc.c:256: warning: 'omap4_l3_init' defined but not used > >>>> > >>>>Adding module_init() and macros in omap_l3_noc/smx drivers when building > >>>>as modules to remove the above warning. > >>>> > >>>>Reported-by: Tony Lindgren <tony@xxxxxxxxxxx> > >>>>Signed-off-by: Lokesh Vutla <lokeshvutla@xxxxxx> > >>>>--- > >>>Thanks for the fix Lokesh. Looks fine to me. > >>> > >>>Acked-by: Santosh Shilimkar <santosh.shilimkar@xxxxxx> > >> > >>Looks like nobody else has picked this up so I'll queue this along > >>with few other omap warnings and regressions. > > > >Hmm actually this might require some more discussion. If we make > >it use regular initcalls, then the ugly ifdefs can be left > >out. Is there a reason to init this early, can't we just use regular > >initcalls? > > > I thought about it. The whole reason we want interconnect errors > enabled early in the boot to avoid bad accesses issued on > interconnect > in early boot by various init codes. We managed to discovered many > init sequence issues where the a driver is trying to access registers > when clocks are not active, or drivers are using bad mapping. At times > these errors gets un-noticed because of the behavior of interconnect > and later causes serious issues. Leaving the driver init late in the > boot means we can't catch any of the issues happen till the L3 driver > init happens. OK yeah that makes sense. How about let's just make it just postcore_initcall instead of postcore_initcall_sync? In include/linux/module.h we have: ... #else /* MODULE */ /* Don't use these in loadable modules, but some people do... */ #define early_initcall(fn) module_init(fn) #define core_initcall(fn) module_init(fn) #define postcore_initcall(fn) module_init(fn) ... While the postcore_initcall_sync does not have those. No idea what the current plan is, but I sort of remember reading that the _sync versions are going away at some point anyways? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
