diff mbox

drivers: bus: omap_interconnect: Fix rand-config build warning

Message ID 1350480519-1890-1-git-send-email-lokeshvutla@ti.com (mailing list archive)
State New, archived
Headers show

Commit Message

Lokesh Vutla Oct. 17, 2012, 1:28 p.m. UTC
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@atomide.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
 drivers/bus/omap_l3_noc.c |    9 +++++++++
 drivers/bus/omap_l3_smx.c |   10 ++++++++++
 2 files changed, 19 insertions(+)

Comments

Santosh Shilimkar Oct. 17, 2012, 1:34 p.m. UTC | #1
(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@atomide.com>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> ---
Thanks for the fix Lokesh. Looks fine to me.

Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tony Lindgren Oct. 25, 2012, 12:35 a.m. UTC | #2
* Santosh Shilimkar <santosh.shilimkar@ti.com> [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@atomide.com>
> >Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> >---
> Thanks for the fix Lokesh. Looks fine to me.
> 
> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

Looks like nobody else has picked this up so I'll queue this along
with few other omap warnings and regressions.

Regards,

Tony
Tony Lindgren Oct. 25, 2012, 12:42 a.m. UTC | #3
* Tony Lindgren <tony@atomide.com> [121024 17:36]:
> * Santosh Shilimkar <santosh.shilimkar@ti.com> [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@atomide.com>
> > >Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> > >---
> > Thanks for the fix Lokesh. Looks fine to me.
> > 
> > Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> 
> 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?

Dropping the patch for now anyways.

Regards,

Tony
Santosh Shilimkar Oct. 25, 2012, 6:33 a.m. UTC | #4
On Thursday 25 October 2012 06:12 AM, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [121024 17:36]:
>> * Santosh Shilimkar <santosh.shilimkar@ti.com> [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@atomide.com>
>>>> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
>>>> ---
>>> Thanks for the fix Lokesh. Looks fine to me.
>>>
>>> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>>
>> 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.

Regards
Santosh
Tony Lindgren Oct. 25, 2012, 7:15 p.m. UTC | #5
* Santosh Shilimkar <santosh.shilimkar@ti.com> [121024 23:34]:
> On Thursday 25 October 2012 06:12 AM, Tony Lindgren wrote:
> >* Tony Lindgren <tony@atomide.com> [121024 17:36]:
> >>* Santosh Shilimkar <santosh.shilimkar@ti.com> [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@atomide.com>
> >>>>Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> >>>>---
> >>>Thanks for the fix Lokesh. Looks fine to me.
> >>>
> >>>Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> >>
> >>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
Santosh Shilimkar Oct. 26, 2012, 6:35 a.m. UTC | #6
On Friday 26 October 2012 12:45 AM, Tony Lindgren wrote:
> * Santosh Shilimkar <santosh.shilimkar@ti.com> [121024 23:34]:
>> On Thursday 25 October 2012 06:12 AM, Tony Lindgren wrote:
>>> * Tony Lindgren <tony@atomide.com> [121024 17:36]:
>>>> * Santosh Shilimkar <santosh.shilimkar@ti.com> [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@atomide.com>
>>>>>> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
>>>>>> ---
>>>>> Thanks for the fix Lokesh. Looks fine to me.
>>>>>
>>>>> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>>>>
>>>> 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?
>
_sync was added by purpose since the driver has depedency on
the hwmod initialisation which is postcore_initcall. Without
the sync, we open the race condition and the l3 driver
registration will fail.

> 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?
>
I have no idea either. As mentioned sync was added to avoid the
race. If and when _sync is removed, something should come as an
alternative to avoid initcall completion dependencies for the one
which falls in same group.

Regards,
Santosh
Lokesh Vutla Oct. 29, 2012, 7:02 a.m. UTC | #7
Hi Tony,

On Friday 26 October 2012 12:05 PM, Santosh Shilimkar wrote:
> On Friday 26 October 2012 12:45 AM, Tony Lindgren wrote:
>> * Santosh Shilimkar <santosh.shilimkar@ti.com> [121024 23:34]:
>>> On Thursday 25 October 2012 06:12 AM, Tony Lindgren wrote:
>>>> * Tony Lindgren <tony@atomide.com> [121024 17:36]:
>>>>> * Santosh Shilimkar <santosh.shilimkar@ti.com> [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@atomide.com>
>>>>>>> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
>>>>>>> ---
>>>>>> Thanks for the fix Lokesh. Looks fine to me.
>>>>>>
>>>>>> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>>>>>
>>>>> 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?
>>
> _sync was added by purpose since the driver has depedency on
> the hwmod initialisation which is postcore_initcall. Without
> the sync, we open the race condition and the l3 driver
> registration will fail.
>
>> 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?
>>
> I have no idea either. As mentioned sync was added to avoid the
> race. If and when _sync is removed, something should come as an
> alternative to avoid initcall completion dependencies for the one
> which falls in same group.
Is the above discussion fine for you ?
Will you pick this patch or
you want any more modifications ?

Thanks
Lokesh
>
> Regards,
> Santosh
>
>
Tony Lindgren Oct. 31, 2012, 11:26 p.m. UTC | #8
* Lokesh Vutla <lokeshvutla@ti.com> [121029 00:03]:
> Is the above discussion fine for you ?
> Will you pick this patch or
> you want any more modifications ?

Let's see what Arnd says.

Regards,

Tony
Lokesh Vutla Nov. 28, 2012, 8:26 a.m. UTC | #9
Hi,

On Thursday 01 November 2012 04:56 AM, Tony Lindgren wrote:
> * Lokesh Vutla <lokeshvutla@ti.com> [121029 00:03]:
>> Is the above discussion fine for you ?
>> Will you pick this patch or
>> you want any more modifications ?
>
> Let's see what Arnd says.
Gentle ping on this...

Thanks
Lokesh
>
> Regards,
>
> Tony
>
diff mbox

Patch

diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index d15225f..8222a33 100644
--- a/drivers/bus/omap_l3_noc.c
+++ b/drivers/bus/omap_l3_noc.c
@@ -257,10 +257,19 @@  static int __init omap4_l3_init(void)
 {
 	return platform_driver_register(&omap4_l3_driver);
 }
+#ifndef CONFIG_OMAP_INTERCONNECT_MODULE
 postcore_initcall_sync(omap4_l3_init);
+#else
+module_init(omap4_l3_init);
+#endif
 
 static void __exit omap4_l3_exit(void)
 {
 	platform_driver_unregister(&omap4_l3_driver);
 }
 module_exit(omap4_l3_exit);
+
+MODULE_ALIAS("platform: omap_l3_noc");
+MODULE_AUTHOR("Texas Instruments Inc.");
+MODULE_DESCRIPTION("OMAP4XXX L3 Interconnect Driver");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/bus/omap_l3_smx.c b/drivers/bus/omap_l3_smx.c
index acc2164..00f712d 100644
--- a/drivers/bus/omap_l3_smx.c
+++ b/drivers/bus/omap_l3_smx.c
@@ -22,6 +22,7 @@ 
  * USA
  */
 
+#include <linux/module.h>
 #include <linux/kernel.h>
 #include <linux/slab.h>
 #include <linux/platform_device.h>
@@ -288,10 +289,19 @@  static int __init omap3_l3_init(void)
 {
 	return platform_driver_probe(&omap3_l3_driver, omap3_l3_probe);
 }
+#ifndef CONFIG_OMAP_INTERCONNECT_MODULE
 postcore_initcall_sync(omap3_l3_init);
+#else
+module_init(omap3_l3_init);
+#endif
 
 static void __exit omap3_l3_exit(void)
 {
 	platform_driver_unregister(&omap3_l3_driver);
 }
 module_exit(omap3_l3_exit);
+
+MODULE_ALIAS("platform: omap_l3_smx");
+MODULE_AUTHOR("Texas Instruments Inc.");
+MODULE_DESCRIPTION("OMAP3XXX L3 Interconnect Driver");
+MODULE_LICENSE("GPL v2");