Compiling the current mainline tree (commit 288d5abec8314ae50fe6692f324b0444acae8486) produces some omap-related warnings. Most of them are harmless, and they are simple enough to fix that even I can do it. I hope.. The compiler warnings from running `make omap2plus_defconfig uImage CONFIG_DEBUG_SECTION_MISMATCH=1': ... CC arch/arm/mach-omap2/clock44xx_data.o arch/arm/mach-omap2/clock44xx_data.c: In function 'omap4xxx_clk_init': arch/arm/mach-omap2/clock44xx_data.c:3371: warning: 'cpu_clkflg' may be used uninitialized in this function ... CC arch/arm/mach-omap2/usb-musb.o arch/arm/mach-omap2/usb-musb.c:71: warning: 'usb_musb_mux_init' defined but not used arch/arm/mach-omap2/usb-musb.c: In function 'usb_musb_init': arch/arm/mach-omap2/usb-musb.c:141: warning: 'dev' may be used uninitialized in this function ... CC arch/arm/mach-omap2/display.o arch/arm/mach-omap2/display.c: In function 'omap_display_init': arch/arm/mach-omap2/display.c:101: warning: assignment from incompatible pointer type ... LD arch/arm/mach-omap2/built-in.o WARNING: arch/arm/mach-omap2/built-in.o(.data+0x354d0): Section mismatch in reference from the variable keypad_data to the (unknown reference) .init.data:(unknown) The variable keypad_data references the (unknown reference) __initdata (unknown) By applying the patches is this series, most of these warnings are gone. The warning from omap_display has not been fixed. I could do something similar to what hsmmc.c is using, but I think this is unnessarily complex. I think the real fix for this warning is to make the type of the returned value from omap_pm_get_dev_context_loss_count() be the same as the prototype in struct omap_dss_board_info. I can't see why one should be u32, and the other int. However, I don't know which to fix.. The resulting kernel has been booted on a pandaboard. Please note that commit a0bfa1373859e9d11dc92561a8667588803e42d8 introduces a typo in arch/arm/kernel/process.c, and this needs to be fixed in order to even compile the kernel. Please see attached patch. This patch is sufficient to make it compile, but probably not a complete fix for the problems introduced by the changes to cpu_idle. There is still a boot messages from lockdep pointing to cpu_idle. Bjarne Steinsbo
Attachment:
0001-cpuidle-fix-typos.patch
Description: Binary data
