[maverick][PATCH] UBUNTU: SAUCE: Load SysLink modules on start-up on OMAP4 devices
Lee Jones
lee.jones at canonical.com
Wed Jul 7 11:52:08 UTC 2010
Hi Nicolas,
Thank you for your comments.
>> >> +static struct platform_device omap4_syslink_device = {
>> >> + .name = "syslink_ipc",
>> >> + .id = -1,
>> >> + .num_resources = 0,
>> >> +};
>> >>
>> >> +static struct platform_device *omap4_syslink_devices[] = {
>> >> + &omap4_syslink_device,
>> >> +};
>> >> +
> >
> > is it worth using an array of platform_device for just 1 device? At least the array should be marked as __initdata so that
> > it does not take memory after init. However I would prefer not to use an array.
> >
I thought by doing this way it would be easier if we were to add more devices at a later date.
I did have __initdata there. I took it out during debugging, as it was causing compile errors. I would be fine now though.
I have no preference either way - pick one and we'll run with it.
>> >> +module_init(omap4_syslink_init);
> >
> > you aren't in a module here, this code is built-in in the kernel (and will always be). This is supposed to be called during
> > platform init, not during do_initcall. Can we call this function from the machine init function instead of using this trick? (e.g. omap_4430sdp_init() and omap_panda_init())
Yes, this code is built-in, but it is part of the SysLink code, which is a module and is happy to be initiated at the same time.
Do: "grep -nHre module_init arch/*", and you'll see it is used many times within architecture specific code.
> > Can we call this function from the machine init function instead of using this trick? (e.g. omap_4430sdp_init() and omap_panda_init())
We can call the function from each machine, but it will need to be added to every OMAP4 machine that you release.
There are other *_initcalls available if you'd rather change it - some will work, some won't:
early_initcall - kills the kernel (I think this is done before the platform code is initiated)
core_initcall - not tried
postcore_initcall - not tried
arch_initcall - not tried
subsys_initcall - not tried
fs_initcall - not tried
rootfs_initcall - not tried
device_initcall - not tried
late_initcall - not tried
If anyone else has any better ideas (or knows the _correct_ solution), feel free to chirp in.
Kind regards,
Lee
More information about the kernel-team
mailing list