[PATCH] arm: omap3: cm-t35: fix section mismatch warning

[PATCH] arm: omap3: cm-t35: fix section mismatch warning

[Igor Grinberg]

WARNING: arch/arm/mach-omap2/built-in.o(.text+0xeae8):
Section mismatch in reference from the function cm_t35_init_usbh()
to the (unknown reference) .init.data:(unknown)
The function cm_t35_init_usbh() references
the (unknown reference) __initdata (unknown).
This is often because cm_t35_init_usbh lacks a __initdata
annotation or the annotation of (unknown) is wrong.

Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
---
Sorry about this one. I fixed similar problem for cm-t3517 a while ago,
but somehow missed cm-t35. Thanks for spotting.
Probably enabling the CONFIG_DEBUG_SECTION_MISMATCH in defconfigs
can raise people awareness for this.

 arch/arm/mach-omap2/board-cm-t35.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c
index d839c05..a8cedbe 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -436,7 +436,7 @@ static struct usbhs_omap_board_data usbhs_bdata __initdata = {
 	.reset_gpio_port[2]  = -EINVAL
 };
 
-static void cm_t35_init_usbh(void)
+static void  __init cm_t35_init_usbh(void)
 {
 	int err;
 
-- 
1.7.3.4

[PATCH] arm: omap3: cm-t35: fix section mismatch warning

[Tony Lindgren]

* Igor Grinberg <grinberg@compulab.co.il> [120205 03:08]:
> WARNING: arch/arm/mach-omap2/built-in.o(.text+0xeae8):
> Section mismatch in reference from the function cm_t35_init_usbh()
> to the (unknown reference) .init.data:(unknown)
> The function cm_t35_init_usbh() references
> the (unknown reference) __initdata (unknown).
> This is often because cm_t35_init_usbh lacks a __initdata
> annotation or the annotation of (unknown) is wrong.
> 
> Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
> ---
> Sorry about this one. I fixed similar problem for cm-t3517 a while ago,
> but somehow missed cm-t35. Thanks for spotting.
> Probably enabling the CONFIG_DEBUG_SECTION_MISMATCH in defconfigs
> can raise people awareness for this.

Thanks applying into fixes. Yes let's plan on doing that,
and also make sure we're actually seeing the warnings..

Tony
 
>  arch/arm/mach-omap2/board-cm-t35.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c
> index d839c05..a8cedbe 100644
> --- a/arch/arm/mach-omap2/board-cm-t35.c
> +++ b/arch/arm/mach-omap2/board-cm-t35.c
> @@ -436,7 +436,7 @@ static struct usbhs_omap_board_data usbhs_bdata __initdata = {
>  	.reset_gpio_port[2]  = -EINVAL
>  };
>  
> -static void cm_t35_init_usbh(void)
> +static void  __init cm_t35_init_usbh(void)
>  {
>  	int err;
>  
> -- 
> 1.7.3.4
> 

[PATCH] ARM: OMAP: update omap1 and omap2plus defconfigs

[Igor Grinberg]

This patch updates omapX_defconfig to 3.3-rc1 and enables
the CONFIG_DEBUG_SECTION_MISMATCH.

The update is done by:
1) make mrproper && make omapX_defconfig
2) Enable the CONFIG_DEBUG_SECTION_MISMATCH
3) make savedefconfig
4) cp defconfig arch/arm/configs/omapX_defconfig

Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
---
After updating omap1_defconfig,
there are several section mismatch warnings seen.
Hopefully, I will have time to fix those tomorrow
(unless someone will be kind enough to fix them before me).
The mismatches are:

WARNING: vmlinux.o(.data+0xb7e4): Section mismatch in reference from
the variable latch1_gpio_device to the (unknown reference) .init.rodata:(unknown)
The variable latch1_gpio_device references
the (unknown reference) __initconst (unknown)
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console

WARNING: vmlinux.o(.data+0xb8f4): Section mismatch in reference from
the variable latch1_gpio_device to the (unknown reference) .init.rodata:(unknown)
The variable latch1_gpio_device references
the (unknown reference) __initconst (unknown)
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console

WARNING: vmlinux.o(.data+0xb974): Section mismatch in reference from
the variable latch2_gpio_device to the (unknown reference) .init.rodata:(unknown)
The variable latch2_gpio_device references
the (unknown reference) __initconst (unknown)
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console

WARNING: vmlinux.o(.data+0xba84): Section mismatch in reference from
the variable latch2_gpio_device to the (unknown reference) .init.rodata:(unknown)
The variable latch2_gpio_device references
the (unknown reference) __initconst (unknown)
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console

WARNING: vmlinux.o(.data+0xbb04): Section mismatch in reference from
the variable ams_delta_kp_device to the (unknown reference) .init.data:(unknown)
The variable ams_delta_kp_device references
the (unknown reference) __initdata (unknown)
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console


 arch/arm/configs/omap1_defconfig     |   35 +++++++++++----------------------
 arch/arm/configs/omap2plus_defconfig |   25 ++++++++---------------
 2 files changed, 21 insertions(+), 39 deletions(-)

diff --git a/arch/arm/configs/omap1_defconfig b/arch/arm/configs/omap1_defconfig
index dde2a1a..1122156 100644
--- a/arch/arm/configs/omap1_defconfig
+++ b/arch/arm/configs/omap1_defconfig
@@ -20,6 +20,7 @@ CONFIG_MODULE_UNLOAD=y
 CONFIG_MODULE_FORCE_UNLOAD=y
 # CONFIG_LBDAF is not set
 # CONFIG_BLK_DEV_BSG is not set
+CONFIG_PARTITION_ADVANCED=y
 # CONFIG_IOSCHED_DEADLINE is not set
 # CONFIG_IOSCHED_CFQ is not set
 CONFIG_ARCH_OMAP=y
@@ -27,7 +28,6 @@ CONFIG_ARCH_OMAP1=y
 CONFIG_OMAP_RESET_CLOCKS=y
 # CONFIG_OMAP_MUX is not set
 CONFIG_OMAP_MBOX_FWK=y
-CONFIG_OMAP_32K_TIMER=y
 CONFIG_OMAP_DM_TIMER=y
 CONFIG_ARCH_OMAP730=y
 CONFIG_ARCH_OMAP850=y
@@ -62,7 +62,6 @@ CONFIG_ZBOOT_ROM_BSS=0x0
 CONFIG_CMDLINE="root=1f03 rootfstype=jffs2"
 CONFIG_FPE_NWFPE=y
 CONFIG_BINFMT_MISC=y
-CONFIG_PM=y
 # CONFIG_SUSPEND is not set
 CONFIG_PM_RUNTIME=y
 CONFIG_NET=y
@@ -82,8 +81,6 @@ CONFIG_IP_PNP_BOOTP=y
 CONFIG_IPV6=y
 CONFIG_NETFILTER=y
 CONFIG_BT=y
-CONFIG_BT_L2CAP=y
-CONFIG_BT_SCO=y
 CONFIG_BT_RFCOMM=y
 CONFIG_BT_RFCOMM_TTY=y
 CONFIG_BT_BNEP=y
@@ -94,9 +91,6 @@ CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
 CONFIG_CONNECTOR=y
 # CONFIG_PROC_EVENTS is not set
 CONFIG_MTD=y
-CONFIG_MTD_DEBUG=y
-CONFIG_MTD_DEBUG_VERBOSE=3
-CONFIG_MTD_PARTITIONS=y
 CONFIG_MTD_CMDLINE_PARTS=y
 CONFIG_MTD_CHAR=y
 CONFIG_MTD_BLOCK=y
@@ -118,9 +112,16 @@ CONFIG_CHR_DEV_SG=y
 CONFIG_SCSI_MULTI_LUN=y
 CONFIG_NETDEVICES=y
 CONFIG_TUN=y
-CONFIG_PHYLIB=y
-CONFIG_NET_ETHERNET=y
 CONFIG_SMC91X=y
+CONFIG_PHYLIB=y
+CONFIG_PPP=y
+CONFIG_PPP_BSDCOMP=y
+CONFIG_PPP_DEFLATE=y
+CONFIG_PPP_FILTER=y
+CONFIG_PPP_MULTILINK=y
+CONFIG_PPP_ASYNC=y
+CONFIG_SLIP=y
+CONFIG_SLIP_COMPRESSED=y
 CONFIG_USB_CATC=y
 CONFIG_USB_KAWETH=y
 CONFIG_USB_PEGASUS=y
@@ -128,14 +129,6 @@ CONFIG_USB_RTL8150=y
 CONFIG_USB_USBNET=y
 # CONFIG_USB_NET_AX8817X is not set
 # CONFIG_USB_NET_CDC_SUBSET is not set
-CONFIG_PPP=y
-CONFIG_PPP_MULTILINK=y
-CONFIG_PPP_FILTER=y
-CONFIG_PPP_ASYNC=y
-CONFIG_PPP_DEFLATE=y
-CONFIG_PPP_BSDCOMP=y
-CONFIG_SLIP=y
-CONFIG_SLIP_COMPRESSED=y
 # CONFIG_INPUT_MOUSEDEV is not set
 CONFIG_INPUT_EVDEV=y
 CONFIG_INPUT_EVBUG=y
@@ -146,11 +139,11 @@ CONFIG_TOUCHSCREEN_ADS7846=y
 CONFIG_INPUT_MISC=y
 CONFIG_INPUT_UINPUT=y
 # CONFIG_SERIO is not set
+# CONFIG_LEGACY_PTYS is not set
 CONFIG_SERIAL_8250=y
 CONFIG_SERIAL_8250_CONSOLE=y
 CONFIG_SERIAL_8250_NR_UARTS=3
 CONFIG_SERIAL_8250_RUNTIME_UARTS=3
-# CONFIG_LEGACY_PTYS is not set
 CONFIG_HW_RANDOM=y
 CONFIG_I2C=y
 CONFIG_I2C_CHARDEV=y
@@ -247,7 +240,6 @@ CONFIG_NFS_FS=y
 CONFIG_NFS_V3=y
 CONFIG_NFS_V4=y
 CONFIG_ROOT_NFS=y
-CONFIG_PARTITION_ADVANCED=y
 CONFIG_NLS_CODEPAGE_437=y
 CONFIG_NLS_CODEPAGE_850=y
 CONFIG_NLS_CODEPAGE_852=y
@@ -261,16 +253,13 @@ CONFIG_NLS_KOI8_R=y
 CONFIG_NLS_UTF8=y
 # CONFIG_ENABLE_MUST_CHECK is not set
 CONFIG_MAGIC_SYSRQ=y
-CONFIG_DEBUG_KERNEL=y
+CONFIG_DEBUG_SECTION_MISMATCH=y
 CONFIG_DEBUG_SPINLOCK=y
 CONFIG_DEBUG_MUTEXES=y
 # CONFIG_DEBUG_BUGVERBOSE is not set
 CONFIG_DEBUG_INFO=y
-# CONFIG_RCU_CPU_STALL_DETECTOR is not set
 CONFIG_DEBUG_USER=y
-CONFIG_DEBUG_ERRORS=y
 CONFIG_SECURITY=y
-CONFIG_CRYPTO_ECB=y
 CONFIG_CRYPTO_PCBC=y
 CONFIG_CRYPTO_DEFLATE=y
 CONFIG_CRYPTO_ZLIB=y
diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index d5f00d7..e2e30ef 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -7,8 +7,6 @@ CONFIG_IKCONFIG_PROC=y
 CONFIG_LOG_BUF_SHIFT=16
 CONFIG_BLK_DEV_INITRD=y
 CONFIG_EXPERT=y
-# CONFIG_SYSCTL_SYSCALL is not set
-CONFIG_KALLSYMS_EXTRA_PASS=y
 CONFIG_SLAB=y
 CONFIG_PROFILING=y
 CONFIG_OPROFILE=y
@@ -20,6 +18,7 @@ CONFIG_MODULE_FORCE_UNLOAD=y
 CONFIG_MODVERSIONS=y
 CONFIG_MODULE_SRCVERSION_ALL=y
 # CONFIG_BLK_DEV_BSG is not set
+CONFIG_PARTITION_ADVANCED=y
 CONFIG_ARCH_OMAP=y
 CONFIG_OMAP_RESET_CLOCKS=y
 CONFIG_OMAP_MUX_DEBUG=y
@@ -87,21 +86,20 @@ CONFIG_SCSI_MULTI_LUN=y
 CONFIG_SCSI_SCAN_ASYNC=y
 CONFIG_MD=y
 CONFIG_NETDEVICES=y
-CONFIG_SMSC_PHY=y
-CONFIG_NET_ETHERNET=y
-CONFIG_SMC91X=y
-CONFIG_SMSC911X=y
 CONFIG_KS8851=y
 CONFIG_KS8851_MLL=y
-CONFIG_LIBERTAS=m
-CONFIG_LIBERTAS_USB=m
-CONFIG_LIBERTAS_SDIO=m
-CONFIG_LIBERTAS_DEBUG=y
+CONFIG_SMC91X=y
+CONFIG_SMSC911X=y
+CONFIG_SMSC_PHY=y
 CONFIG_USB_USBNET=y
 CONFIG_USB_ALI_M5632=y
 CONFIG_USB_AN2720=y
 CONFIG_USB_EPSON2888=y
 CONFIG_USB_KC2190=y
+CONFIG_LIBERTAS=m
+CONFIG_LIBERTAS_USB=m
+CONFIG_LIBERTAS_SDIO=m
+CONFIG_LIBERTAS_DEBUG=y
 CONFIG_INPUT_JOYDEV=y
 CONFIG_INPUT_EVDEV=y
 CONFIG_KEYBOARD_GPIO=y
@@ -137,7 +135,6 @@ CONFIG_FB=y
 CONFIG_FIRMWARE_EDID=y
 CONFIG_FB_MODE_HELPERS=y
 CONFIG_FB_TILEBLITTING=y
-CONFIG_FB_OMAP_LCD_VGA=y
 CONFIG_OMAP2_DSS=m
 CONFIG_OMAP2_DSS_RFBI=y
 CONFIG_OMAP2_DSS_SDI=y
@@ -152,7 +149,6 @@ CONFIG_PANEL_ACX565AKM=m
 CONFIG_BACKLIGHT_LCD_SUPPORT=y
 CONFIG_LCD_CLASS_DEVICE=y
 CONFIG_LCD_PLATFORM=y
-CONFIG_DISPLAY_SUPPORT=y
 CONFIG_FRAMEBUFFER_CONSOLE=y
 CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
 CONFIG_FONTS=y
@@ -213,19 +209,16 @@ CONFIG_NFS_V3=y
 CONFIG_NFS_V3_ACL=y
 CONFIG_NFS_V4=y
 CONFIG_ROOT_NFS=y
-CONFIG_PARTITION_ADVANCED=y
 CONFIG_NLS_CODEPAGE_437=y
 CONFIG_NLS_ISO8859_1=y
 CONFIG_PRINTK_TIME=y
 CONFIG_MAGIC_SYSRQ=y
-CONFIG_DEBUG_KERNEL=y
+CONFIG_DEBUG_SECTION_MISMATCH=y
 CONFIG_SCHEDSTATS=y
 CONFIG_TIMER_STATS=y
 CONFIG_PROVE_LOCKING=y
-CONFIG_DEBUG_SPINLOCK_SLEEP=y
 # CONFIG_DEBUG_BUGVERBOSE is not set
 CONFIG_DEBUG_INFO=y
-# CONFIG_RCU_CPU_STALL_DETECTOR is not set
 CONFIG_SECURITY=y
 CONFIG_CRYPTO_MICHAEL_MIC=y
 # CONFIG_CRYPTO_ANSI_CPRNG is not set
-- 
1.7.3.4

[PATCH] ARM: OMAP: update omap1 and omap2plus defconfigs

[Russell King - ARM Linux]

On Wed, Feb 08, 2012 at 12:16:13PM +0200, Igor Grinberg wrote:
> This patch updates omapX_defconfig to 3.3-rc1 and enables
> the CONFIG_DEBUG_SECTION_MISMATCH.

You shouldn't enable this in the kernel supplied defconfigs.

> The update is done by:
> 1) make mrproper && make omapX_defconfig
> 2) Enable the CONFIG_DEBUG_SECTION_MISMATCH
> 3) make savedefconfig
> 4) cp defconfig arch/arm/configs/omapX_defconfig
> 
> Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
> ---
> After updating omap1_defconfig,
> there are several section mismatch warnings seen.
> Hopefully, I will have time to fix those tomorrow
> (unless someone will be kind enough to fix them before me).
> The mismatches are:

The correct way is to build with:

make ... CONFIG_DEBUG_SECTION_MISMATCH=y

or set it in your private configuration.

[PATCH] ARM: OMAP: update omap1 and omap2plus defconfigs

[Igor Grinberg]

Hi Russell,

On 02/08/12 12:19, Russell King - ARM Linux wrote:
> On Wed, Feb 08, 2012 at 12:16:13PM +0200, Igor Grinberg wrote:
>> This patch updates omapX_defconfig to 3.3-rc1 and enables
>> the CONFIG_DEBUG_SECTION_MISMATCH.
> 
> You shouldn't enable this in the kernel supplied defconfigs.

Hmmm... Ok, looks like I've forgot the purpose of defconfigs...
It is intended for users rather than developers (right?) and
the CONFIG_DEBUG_SECTION_MISMATCH has no use for users?
Is it the case, or is there anything else?

> 
>> The update is done by:
>> 1) make mrproper && make omapX_defconfig
>> 2) Enable the CONFIG_DEBUG_SECTION_MISMATCH
>> 3) make savedefconfig
>> 4) cp defconfig arch/arm/configs/omapX_defconfig
>>
>> Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
>> ---
>> After updating omap1_defconfig,
>> there are several section mismatch warnings seen.
>> Hopefully, I will have time to fix those tomorrow
>> (unless someone will be kind enough to fix them before me).
>> The mismatches are:
> 
> The correct way is to build with:
> 
> make ... CONFIG_DEBUG_SECTION_MISMATCH=y
> 
> or set it in your private configuration.

In my current setup, command line switch would be most appropriate.
Thanks for suggestion.


-- 
Regards,
Igor.

[PATCH] ARM: OMAP: update omap1 and omap2plus defconfigs

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 01:49]:
> On Wed, Feb 08, 2012 at 12:16:13PM +0200, Igor Grinberg wrote:
> > This patch updates omapX_defconfig to 3.3-rc1 and enables
> > the CONFIG_DEBUG_SECTION_MISMATCH.
> 
> You shouldn't enable this in the kernel supplied defconfigs.
> 
> > The update is done by:
> > 1) make mrproper && make omapX_defconfig
> > 2) Enable the CONFIG_DEBUG_SECTION_MISMATCH
> > 3) make savedefconfig
> > 4) cp defconfig arch/arm/configs/omapX_defconfig
> > 
> > Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
> > ---
> > After updating omap1_defconfig,
> > there are several section mismatch warnings seen.
> > Hopefully, I will have time to fix those tomorrow
> > (unless someone will be kind enough to fix them before me).
> > The mismatches are:
> 
> The correct way is to build with:
> 
> make ... CONFIG_DEBUG_SECTION_MISMATCH=y
> 
> or set it in your private configuration.

OK that's the way to go then. Having the unoptimizer compiler flag
-fno-inline-functions-called-once is not nice in defconfigs.. And
we should already get the warning to enable section mismatch
warnings anyways.

Regrads,

Tony

[PATCH] ARM: OMAP: update omap1 and omap2plus defconfigs

[Janusz Krzysztofik]

On Wednesday 08 of February 2012 12:16:13 Igor Grinberg wrote:
> ...
> After updating omap1_defconfig,
> there are several section mismatch warnings seen.
> Hopefully, I will have time to fix those tomorrow
> (unless someone will be kind enough to fix them before me).

Sound like introduced with my recent ams-delta patches, sorry.
I'll have a look at them.

Thanks,
Janusz

> The mismatches are:
> 
> WARNING: vmlinux.o(.data+0xb7e4): Section mismatch in reference from
> the variable latch1_gpio_device to the (unknown reference)
> .init.rodata:(unknown) The variable latch1_gpio_device references
> the (unknown reference) __initconst (unknown)
> If the reference is valid then annotate the
> variable with __init* or __refdata (see linux/init.h) or name the variable:
> *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
> 
> WARNING: vmlinux.o(.data+0xb8f4): Section mismatch in reference from
> the variable latch1_gpio_device to the (unknown reference)
> .init.rodata:(unknown) The variable latch1_gpio_device references
> the (unknown reference) __initconst (unknown)
> If the reference is valid then annotate the
> variable with __init* or __refdata (see linux/init.h) or name the variable:
> *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
> 
> WARNING: vmlinux.o(.data+0xb974): Section mismatch in reference from
> the variable latch2_gpio_device to the (unknown reference)
> .init.rodata:(unknown) The variable latch2_gpio_device references
> the (unknown reference) __initconst (unknown)
> If the reference is valid then annotate the
> variable with __init* or __refdata (see linux/init.h) or name the variable:
> *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
> 
> WARNING: vmlinux.o(.data+0xba84): Section mismatch in reference from
> the variable latch2_gpio_device to the (unknown reference)
> .init.rodata:(unknown) The variable latch2_gpio_device references
> the (unknown reference) __initconst (unknown)
> If the reference is valid then annotate the
> variable with __init* or __refdata (see linux/init.h) or name the variable:
> *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
> 
> WARNING: vmlinux.o(.data+0xbb04): Section mismatch in reference from
> the variable ams_delta_kp_device to the (unknown reference)
> .init.data:(unknown) The variable ams_delta_kp_device references
> the (unknown reference) __initdata (unknown)
> If the reference is valid then annotate the
> variable with __init* or __refdata (see linux/init.h) or name the variable:
> *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console

[PATCH] ARM: OMAP1: ams-delta: clean up init data section assignments

[Janusz Krzysztofik]

The main purpose of this patch is to fix several section mismatch
warnings from the board file and a few board specific drivers,
introduced mostly with recent Amstrad Delta patch series, some of them
rising up only when building with CONFIG_MODULES not set.

While being at it, section assignments of all init data found in the
board file have been revised and hopefully optimised.

Created and tested on top of current linux-omap/omap1, commit
967809bd7faf71ddc29c8081e0f21db8b201a0f4.

Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
---
 arch/arm/mach-omap1/board-ams-delta.c |   35 +++++++++++++++++----------------
 drivers/input/serio/ams_delta_serio.c |    2 +-
 drivers/mtd/nand/ams-delta.c          |    2 +-
 drivers/video/omap/lcd_ams_delta.c    |    2 +-
 4 files changed, 21 insertions(+), 20 deletions(-)

diff --git a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c
index 87b1303..dc2455f 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -126,7 +126,7 @@ static const unsigned int ams_delta_keymap[] = {
 #define LATCH2_PHYS	0x08000000
 #define LATCH2_VIRT	0xEC000000
 
-static struct map_desc ams_delta_io_desc[] __initdata = {
+static struct map_desc ams_delta_io_desc[] __initconst = {
 	/* AMS_DELTA_LATCH1 */
 	{
 		.virtual	= LATCH1_VIRT,
@@ -150,17 +150,17 @@ static struct map_desc ams_delta_io_desc[] __initdata = {
 	}
 };
 
-static struct omap_lcd_config ams_delta_lcd_config = {
+static struct omap_lcd_config ams_delta_lcd_config __initconst = {
 	.ctrl_name	= "internal",
 };
 
-static struct omap_usb_config ams_delta_usb_config __initdata = {
+static struct omap_usb_config ams_delta_usb_config __initdata_or_module = {
 	.register_host	= 1,
 	.hmc_mode	= 16,
 	.pins[0]	= 2,
 };
 
-static struct omap_board_config_kernel ams_delta_config[] __initdata = {
+static struct omap_board_config_kernel ams_delta_config[] __initconst = {
 	{ OMAP_TAG_LCD,		&ams_delta_lcd_config },
 };
 
@@ -181,7 +181,7 @@ static struct bgpio_pdata latch1_pdata __initconst = {
 	.ngpio	= LATCH1_NGPIO,
 };
 
-static struct platform_device latch1_gpio_device = {
+static struct platform_device latch1_gpio_device __refdata = {
 	.name		= "basic-mmio-gpio",
 	.id		= 0,
 	.resource	= latch1_resources,
@@ -205,7 +205,7 @@ static struct bgpio_pdata latch2_pdata __initconst = {
 	.ngpio	= AMS_DELTA_LATCH2_NGPIO,
 };
 
-static struct platform_device latch2_gpio_device = {
+static struct platform_device latch2_gpio_device __refdata = {
 	.name		= "basic-mmio-gpio",
 	.id		= 1,
 	.resource	= latch2_resources,
@@ -271,7 +271,7 @@ void ams_delta_latch_write(int base, int ngpio, u16 mask, u16 value)
 }
 EXPORT_SYMBOL(ams_delta_latch_write);
 
-static struct resource ams_delta_nand_resources[] = {
+static struct resource ams_delta_nand_resources[] __initconst_or_module = {
 	[0] = {
 		.start	= OMAP1_MPUIO_BASE,
 		.end	= OMAP1_MPUIO_BASE +
@@ -280,14 +280,14 @@ static struct resource ams_delta_nand_resources[] = {
 	},
 };
 
-static struct platform_device ams_delta_nand_device = {
+static struct platform_device ams_delta_nand_device __refdata = {
 	.name	= "ams-delta-nand",
 	.id	= -1,
 	.num_resources	= ARRAY_SIZE(ams_delta_nand_resources),
 	.resource	= ams_delta_nand_resources,
 };
 
-static struct resource ams_delta_kp_resources[] = {
+static struct resource ams_delta_kp_resources[] __initconst_or_module = {
 	[0] = {
 		.start	= INT_KEYBOARD,
 		.end	= INT_KEYBOARD,
@@ -300,14 +300,14 @@ static const struct matrix_keymap_data ams_delta_keymap_data = {
 	.keymap_size	= ARRAY_SIZE(ams_delta_keymap),
 };
 
-static struct omap_kp_platform_data ams_delta_kp_data __initdata = {
+static struct omap_kp_platform_data ams_delta_kp_data __initconst_or_module = {
 	.rows		= 8,
 	.cols		= 8,
 	.keymap_data	= &ams_delta_keymap_data,
 	.delay		= 9,
 };
 
-static struct platform_device ams_delta_kp_device = {
+static struct platform_device ams_delta_kp_device __refdata = {
 	.name		= "omap-keypad",
 	.id		= -1,
 	.dev		= {
@@ -363,7 +363,8 @@ static struct gpio_led_platform_data leds_pdata __initconst = {
 	.num_leds	= ARRAY_SIZE(gpio_leds),
 };
 
-static struct i2c_board_info ams_delta_camera_board_info[] = {
+static struct i2c_board_info __initconst_or_module
+ams_delta_camera_board_info[] = {
 	{
 		I2C_BOARD_INFO("ov6650", 0x60),
 	},
@@ -387,7 +388,7 @@ static int ams_delta_camera_power(struct device *dev, int power)
 #define ams_delta_camera_power	NULL
 #endif
 
-static struct soc_camera_link ams_delta_iclink = {
+static struct soc_camera_link ams_delta_iclink __initconst_or_module = {
 	.bus_id         = 0,	/* OMAP1 SoC camera bus */
 	.i2c_adapter_id = 1,
 	.board_info     = &ams_delta_camera_board_info[0],
@@ -395,7 +396,7 @@ static struct soc_camera_link ams_delta_iclink = {
 	.power		= ams_delta_camera_power,
 };
 
-static struct platform_device ams_delta_camera_device = {
+static struct platform_device ams_delta_camera_device __refdata = {
 	.name   = "soc-camera-pdrv",
 	.id     = 0,
 	.dev    = {
@@ -408,7 +409,7 @@ static struct omap1_cam_platform_data ams_delta_camera_platform_data = {
 	.lclk_khz_max	= 1334,		/* results in 5fps CIF, 10fps QCIF */
 };
 
-static struct platform_device *ams_delta_devices[] __initdata = {
+static struct platform_device *ams_delta_devices[] __initconst = {
 	&latch1_gpio_device,
 	&latch2_gpio_device,
 	&ams_delta_kp_device,
@@ -459,7 +460,7 @@ static void __init ams_delta_init(void)
 	omap_writew(omap_readw(ARM_RSTCT1) | 0x0004, ARM_RSTCT1);
 }
 
-static struct plat_serial8250_port ams_delta_modem_ports[] = {
+static struct plat_serial8250_port ams_delta_modem_ports[] __initdata = {
 	{
 		.membase	= IOMEM(MODEM_VIRT),
 		.mapbase	= MODEM_PHYS,
@@ -473,7 +474,7 @@ static struct plat_serial8250_port ams_delta_modem_ports[] = {
 	{ },
 };
 
-static struct platform_device ams_delta_modem_device = {
+static struct platform_device ams_delta_modem_device __refdata = {
 	.name	= "serial8250",
 	.id	= PLAT8250_DEV_PLATFORM1,
 	.dev		= {
diff --git a/drivers/input/serio/ams_delta_serio.c b/drivers/input/serio/ams_delta_serio.c
index 0571e2e..0830a76 100644
--- a/drivers/input/serio/ams_delta_serio.c
+++ b/drivers/input/serio/ams_delta_serio.c
@@ -103,7 +103,7 @@ static void ams_delta_serio_close(struct serio *serio)
 	gpio_set_value(AMS_DELTA_GPIO_PIN_KEYBRD_PWR, 0);
 }
 
-static struct gpio ams_delta_gpios[] __initconst_or_module = {
+static const struct gpio ams_delta_gpios[] = {
 	{
 		.gpio	= AMS_DELTA_GPIO_PIN_KEYBRD_DATA,
 		.flags	= GPIOF_DIR_IN,
diff --git a/drivers/mtd/nand/ams-delta.c b/drivers/mtd/nand/ams-delta.c
index 85934dc..7341695 100644
--- a/drivers/mtd/nand/ams-delta.c
+++ b/drivers/mtd/nand/ams-delta.c
@@ -145,7 +145,7 @@ static int ams_delta_nand_ready(struct mtd_info *mtd)
 	return gpio_get_value(AMS_DELTA_GPIO_PIN_NAND_RB);
 }
 
-static struct gpio _mandatory_gpio[] __initconst_or_module = {
+static const struct gpio _mandatory_gpio[] = {
 	{
 		.gpio	= AMS_DELTA_GPIO_PIN_NAND_NCE,
 		.flags	= GPIOF_OUT_INIT_HIGH,
diff --git a/drivers/video/omap/lcd_ams_delta.c b/drivers/video/omap/lcd_ams_delta.c
index 0e71e28..d3a3113 100644
--- a/drivers/video/omap/lcd_ams_delta.c
+++ b/drivers/video/omap/lcd_ams_delta.c
@@ -99,7 +99,7 @@ static struct lcd_ops ams_delta_lcd_ops = {
 
 /* omapfb panel section */
 
-static struct gpio _gpios[] __initconst_or_module = {
+static const struct gpio _gpios[] = {
 	{
 		.gpio	= AMS_DELTA_GPIO_PIN_LCD_VBLEN,
 		.flags	= GPIOF_OUT_INIT_LOW,
-- 
1.7.3.4

[PATCH] ARM: OMAP1: ams-delta: clean up init data section assignments

[Russell King - ARM Linux]

On Thu, Feb 09, 2012 at 12:18:22PM +0100, Janusz Krzysztofik wrote:
> The main purpose of this patch is to fix several section mismatch
> warnings from the board file and a few board specific drivers,
> introduced mostly with recent Amstrad Delta patch series, some of them
> rising up only when building with CONFIG_MODULES not set.
> 
> While being at it, section assignments of all init data found in the
> board file have been revised and hopefully optimised.

There is no optimisation to adding __refdata to stuff.  That's screaming
that you have lots of bugs here.

> 
> Created and tested on top of current linux-omap/omap1, commit
> 967809bd7faf71ddc29c8081e0f21db8b201a0f4.
> 
> Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
> ---
>  arch/arm/mach-omap1/board-ams-delta.c |   35 +++++++++++++++++----------------
>  drivers/input/serio/ams_delta_serio.c |    2 +-
>  drivers/mtd/nand/ams-delta.c          |    2 +-
>  drivers/video/omap/lcd_ams_delta.c    |    2 +-
>  4 files changed, 21 insertions(+), 20 deletions(-)
> 
> diff --git a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c
> index 87b1303..dc2455f 100644
> --- a/arch/arm/mach-omap1/board-ams-delta.c
> +++ b/arch/arm/mach-omap1/board-ams-delta.c
> @@ -126,7 +126,7 @@ static const unsigned int ams_delta_keymap[] = {
>  #define LATCH2_PHYS	0x08000000
>  #define LATCH2_VIRT	0xEC000000
>  
> -static struct map_desc ams_delta_io_desc[] __initdata = {
> +static struct map_desc ams_delta_io_desc[] __initconst = {

You're not making this comst so don't change it to __initconst.

>  	/* AMS_DELTA_LATCH1 */
>  	{
>  		.virtual	= LATCH1_VIRT,
> @@ -150,17 +150,17 @@ static struct map_desc ams_delta_io_desc[] __initdata = {
>  	}
>  };
>  
> -static struct omap_lcd_config ams_delta_lcd_config = {
> +static struct omap_lcd_config ams_delta_lcd_config __initconst = {

This change probably adds a bug.  Are you sure this will never be used
outside init context?

>  	.ctrl_name	= "internal",
>  };
>  
> -static struct omap_usb_config ams_delta_usb_config __initdata = {
> +static struct omap_usb_config ams_delta_usb_config __initdata_or_module = {

Even if you don't have modules enabled, have you checked whether the
driver can be bound and unbound via
/sys/bus/platform/driver/<name>/{bind,unbind} ?

I suspect this is a bug.

>  	.register_host	= 1,
>  	.hmc_mode	= 16,
>  	.pins[0]	= 2,
>  };
>  
> -static struct omap_board_config_kernel ams_delta_config[] __initdata = {
> +static struct omap_board_config_kernel ams_delta_config[] __initconst = {
>  	{ OMAP_TAG_LCD,		&ams_delta_lcd_config },
>  };
>  
> @@ -181,7 +181,7 @@ static struct bgpio_pdata latch1_pdata __initconst = {
>  	.ngpio	= LATCH1_NGPIO,
>  };
>  
> -static struct platform_device latch1_gpio_device = {
> +static struct platform_device latch1_gpio_device __refdata = {
>  	.name		= "basic-mmio-gpio",
>  	.id		= 0,
>  	.resource	= latch1_resources,
> @@ -205,7 +205,7 @@ static struct bgpio_pdata latch2_pdata __initconst = {
>  	.ngpio	= AMS_DELTA_LATCH2_NGPIO,
>  };
>  
> -static struct platform_device latch2_gpio_device = {
> +static struct platform_device latch2_gpio_device __refdata = {
>  	.name		= "basic-mmio-gpio",
>  	.id		= 1,
>  	.resource	= latch2_resources,
> @@ -271,7 +271,7 @@ void ams_delta_latch_write(int base, int ngpio, u16 mask, u16 value)
>  }
>  EXPORT_SYMBOL(ams_delta_latch_write);
>  
> -static struct resource ams_delta_nand_resources[] = {
> +static struct resource ams_delta_nand_resources[] __initconst_or_module = {

This change definitely adds a bug.  The resources are _used_ _all_ _the_
_time_ _the_ _device_ _is_ _registered_.  Try catting /proc/iomem after
boot.

>  	[0] = {
>  		.start	= OMAP1_MPUIO_BASE,
>  		.end	= OMAP1_MPUIO_BASE +
> @@ -280,14 +280,14 @@ static struct resource ams_delta_nand_resources[] = {
>  	},
>  };
>  
> -static struct platform_device ams_delta_nand_device = {
> +static struct platform_device ams_delta_nand_device __refdata = {

Therefore, bug.

>  	.name	= "ams-delta-nand",
>  	.id	= -1,
>  	.num_resources	= ARRAY_SIZE(ams_delta_nand_resources),
>  	.resource	= ams_delta_nand_resources,
>  };
>  
> -static struct resource ams_delta_kp_resources[] = {
> +static struct resource ams_delta_kp_resources[] __initconst_or_module = {

Bug.

>  	[0] = {
>  		.start	= INT_KEYBOARD,
>  		.end	= INT_KEYBOARD,
> @@ -300,14 +300,14 @@ static const struct matrix_keymap_data ams_delta_keymap_data = {
>  	.keymap_size	= ARRAY_SIZE(ams_delta_keymap),
>  };
>  
> -static struct omap_kp_platform_data ams_delta_kp_data __initdata = {
> +static struct omap_kp_platform_data ams_delta_kp_data __initconst_or_module = {

Probably a bug if you unbind/rebind the associated driver with modules
disabled.

>  	.rows		= 8,
>  	.cols		= 8,
>  	.keymap_data	= &ams_delta_keymap_data,
>  	.delay		= 9,
>  };
>  
> -static struct platform_device ams_delta_kp_device = {
> +static struct platform_device ams_delta_kp_device __refdata = {
>  	.name		= "omap-keypad",
>  	.id		= -1,
>  	.dev		= {
> @@ -363,7 +363,8 @@ static struct gpio_led_platform_data leds_pdata __initconst = {
>  	.num_leds	= ARRAY_SIZE(gpio_leds),
>  };
>  
> -static struct i2c_board_info ams_delta_camera_board_info[] = {
> +static struct i2c_board_info __initconst_or_module
> +ams_delta_camera_board_info[] = {

No.  It's

static struct foo blah[] __whatever_init_attribute

not

static struct foo __whatever_init_attribute blah[]

I've no idea where this fucked idea came from but it's something that's
wasting a lot of review time with complaints like this about it.

>  	{
>  		I2C_BOARD_INFO("ov6650", 0x60),
>  	},
> @@ -387,7 +388,7 @@ static int ams_delta_camera_power(struct device *dev, int power)
>  #define ams_delta_camera_power	NULL
>  #endif
>  
> -static struct soc_camera_link ams_delta_iclink = {
> +static struct soc_camera_link ams_delta_iclink __initconst_or_module = {

Probably buggy.

>  	.bus_id         = 0,	/* OMAP1 SoC camera bus */
>  	.i2c_adapter_id = 1,
>  	.board_info     = &ams_delta_camera_board_info[0],
> @@ -395,7 +396,7 @@ static struct soc_camera_link ams_delta_iclink = {
>  	.power		= ams_delta_camera_power,
>  };
>  
> -static struct platform_device ams_delta_camera_device = {
> +static struct platform_device ams_delta_camera_device __refdata = {
>  	.name   = "soc-camera-pdrv",
>  	.id     = 0,
>  	.dev    = {
> @@ -408,7 +409,7 @@ static struct omap1_cam_platform_data ams_delta_camera_platform_data = {
>  	.lclk_khz_max	= 1334,		/* results in 5fps CIF, 10fps QCIF */
>  };
>  
> -static struct platform_device *ams_delta_devices[] __initdata = {
> +static struct platform_device *ams_delta_devices[] __initconst = {

Missing const.  If you can't const it, don't put it in __initconst.

>  	&latch1_gpio_device,
>  	&latch2_gpio_device,
>  	&ams_delta_kp_device,
> @@ -459,7 +460,7 @@ static void __init ams_delta_init(void)
>  	omap_writew(omap_readw(ARM_RSTCT1) | 0x0004, ARM_RSTCT1);
>  }
>  
> -static struct plat_serial8250_port ams_delta_modem_ports[] = {
> +static struct plat_serial8250_port ams_delta_modem_ports[] __initdata = {

Buggy.

>  	{
>  		.membase	= IOMEM(MODEM_VIRT),
>  		.mapbase	= MODEM_PHYS,
> @@ -473,7 +474,7 @@ static struct plat_serial8250_port ams_delta_modem_ports[] = {
>  	{ },
>  };
>  
> -static struct platform_device ams_delta_modem_device = {
> +static struct platform_device ams_delta_modem_device __refdata = {
>  	.name	= "serial8250",
>  	.id	= PLAT8250_DEV_PLATFORM1,
>  	.dev		= {

[PATCH] ARM: OMAP1: ams-delta: correct init data section assignments

[Janusz Krzysztofik]

On Thursday 09 of February 2012 14:48:53 Russell King - ARM Linux wrote:

> There is no optimisation to adding __refdata to stuff.  That's screaming
> that you have lots of bugs here.

Thanks for your teaching. I find those aspects not very exhaustively documented 
under Documentation/, so any hints are much appreciated.

> > -static struct map_desc ams_delta_io_desc[] __initdata = {
> > +static struct map_desc ams_delta_io_desc[] __initconst = {
> 
> You're not making this comst so don't change it to __initconst.

OK, however, I think there must be a bug in gcc, otherwise it should probably 
never accept such wrong constructs, while sometimes it does (not only mine, 
see [1]).

> > -static struct omap_lcd_config ams_delta_lcd_config = {
> > +static struct omap_lcd_config ams_delta_lcd_config __initconst = {
> 
> This change probably adds a bug.  Are you sure this will never be used
> outside init context?

I may be wrong, but before I've changed this, and now once again, I've verified 
that a copy of this data is made inside __init omap_init_fb() by means of a 
structure assignment operation.

> > -static struct omap_usb_config ams_delta_usb_config __initdata = {
> > +static struct omap_usb_config ams_delta_usb_config __initdata_or_module
> > = {
> Even if you don't have modules enabled, have you checked whether the
> driver can be bound and unbound via
> /sys/bus/platform/driver/<name>/{bind,unbind} ?

No, I didn't even think of it, I am afraid.

> I suspect this is a bug.

Indeed, that data is not copied on init, only pointed to, moreover, the 
ohci-omap driver provides bind/unbind opearations.

BTW, what are those bind/unbind operations intended for in case of a driver 
dedicated to a non-hotplugable SoC hardware exclusively?

> > -static struct resource ams_delta_nand_resources[] = {
> > +static struct resource ams_delta_nand_resources[] __initconst_or_module
> > = {
> This change definitely adds a bug.  The resources are _used_ _all_ _the_
> _time_ _the_ _device_ _is_ _registered_.  Try catting /proc/iomem after
> boot.

Indeed, I didn't think of that. I expected that standard init data of only 
those devices which can be actually found during init should be copied for 
runtime access, then all (found and not found) dropped instead of keeping them 
all in memory for only some of them being actually used.

> > -static struct i2c_board_info ams_delta_camera_board_info[] = {
> > +static struct i2c_board_info __initconst_or_module
> > +ams_delta_camera_board_info[] = {
> 
> No.  It's
> 
> static struct foo blah[] __whatever_init_attribute
> 
> not
> 
> static struct foo __whatever_init_attribute blah[]
> 
> I've no idea where this fucked idea came from but it's something that's
> wasting a lot of review time with complaints like this about it.

My bad, I blindly copied that pattern from another broken example under 
arch/arm instead of examining the docs carefully enough.

> > -static struct soc_camera_link ams_delta_iclink = {
> > +static struct soc_camera_link ams_delta_iclink __initconst_or_module =
> > {
> 
> Probably buggy.

Indeed. Even if the soc-camera-pdrv driver doesn't support 
unbindind/rebinding, it doesn't seem to make a copy of that platform data, 
only stores a pointer to it for runtime access, wich I missed.

> > -static struct platform_device *ams_delta_devices[] __initdata = {
> > +static struct platform_device *ams_delta_devices[] __initconst = {
> 
> Missing const.  If you can't const it, don't put it in __initconst.

I gave up trying to use both const and __initconst together after my gcc-4.2.4 
(and not only mine, see [1], [2]) refused to accept such constructs a few 
times. Now I see that this false reporting may probably happen in presence of other 
incorrect uses of __initconst without const or __initdata with const.

Hopefully better patches will follow.

Thanks,
Janusz

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-August/062421.html 
[2] http://permalink.gmane.org/gmane.linux.kernel.commits.head/202285

[PATCH v2] ARM: OMAP1: ams-delta: clean up init data section assignments

[Janusz Krzysztofik]

The main purpose of this patch is to fix several section mismatch
warnings from the board file and a few board specific drivers,
introduced with recent Amstrad Delta patch series, some of them rising
up only when building with CONFIG_MODULES not set.

While being at it, section tagging of all init data found in the board
file have been revised and hopefully corrected and/or optimized.

Created and tested on top of current linux-omap/omap1, commit
967809bd7faf71ddc29c8081e0f21db8b201a0f4.

Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
---
 arch/arm/mach-omap1/board-ams-delta.c |   18 +++++++++---------
 drivers/input/serio/ams_delta_serio.c |    2 +-
 drivers/mtd/nand/ams-delta.c          |    2 +-
 drivers/video/omap/lcd_ams_delta.c    |    2 +-
 4 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c
index 87b1303..bfe6fd1 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -150,7 +150,7 @@ static struct map_desc ams_delta_io_desc[] __initdata = {
 	}
 };
 
-static struct omap_lcd_config ams_delta_lcd_config = {
+static struct omap_lcd_config ams_delta_lcd_config __initdata = {
 	.ctrl_name	= "internal",
 };
 
@@ -167,7 +167,7 @@ static struct omap_board_config_kernel ams_delta_config[] __initdata = {
 #define LATCH1_GPIO_BASE	232
 #define LATCH1_NGPIO		8
 
-static struct resource latch1_resources[] __initconst = {
+static struct resource latch1_resources[] = {
 	[0] = {
 		.name	= "dat",
 		.start	= LATCH1_PHYS,
@@ -176,7 +176,7 @@ static struct resource latch1_resources[] __initconst = {
 	},
 };
 
-static struct bgpio_pdata latch1_pdata __initconst = {
+static struct bgpio_pdata latch1_pdata = {
 	.base	= LATCH1_GPIO_BASE,
 	.ngpio	= LATCH1_NGPIO,
 };
@@ -191,7 +191,7 @@ static struct platform_device latch1_gpio_device = {
 	},
 };
 
-static struct resource latch2_resources[] __initconst = {
+static struct resource latch2_resources[] = {
 	[0] = {
 		.name	= "dat",
 		.start	= LATCH2_PHYS,
@@ -200,7 +200,7 @@ static struct resource latch2_resources[] __initconst = {
 	},
 };
 
-static struct bgpio_pdata latch2_pdata __initconst = {
+static struct bgpio_pdata latch2_pdata = {
 	.base	= AMS_DELTA_LATCH2_GPIO_BASE,
 	.ngpio	= AMS_DELTA_LATCH2_NGPIO,
 };
@@ -215,7 +215,7 @@ static struct platform_device latch2_gpio_device = {
 	},
 };
 
-static struct gpio latch_gpios[] __initconst = {
+static const struct gpio latch_gpios[] __initconst = {
 	{
 		.gpio	= LATCH1_GPIO_BASE + 6,
 		.flags	= GPIOF_OUT_INIT_LOW,
@@ -322,7 +322,7 @@ static struct platform_device ams_delta_lcd_device = {
 	.id	= -1,
 };
 
-static struct gpio_led gpio_leds[] __initconst = {
+static const struct gpio_led gpio_leds[] __initconst = {
 	{
 		.name		 = "camera",
 		.gpio		 = LATCH1_GPIO_BASE + 0,
@@ -358,7 +358,7 @@ static struct gpio_led gpio_leds[] __initconst = {
 	},
 };
 
-static struct gpio_led_platform_data leds_pdata __initconst = {
+static const struct gpio_led_platform_data leds_pdata __initconst = {
 	.leds		= gpio_leds,
 	.num_leds	= ARRAY_SIZE(gpio_leds),
 };
@@ -415,7 +415,7 @@ static struct platform_device *ams_delta_devices[] __initdata = {
 	&ams_delta_camera_device,
 };
 
-static struct platform_device *late_devices[] __initconst = {
+static struct platform_device *late_devices[] __initdata = {
 	&ams_delta_nand_device,
 	&ams_delta_lcd_device,
 };
diff --git a/drivers/input/serio/ams_delta_serio.c b/drivers/input/serio/ams_delta_serio.c
index 0571e2e..bd5b10e 100644
--- a/drivers/input/serio/ams_delta_serio.c
+++ b/drivers/input/serio/ams_delta_serio.c
@@ -103,7 +103,7 @@ static void ams_delta_serio_close(struct serio *serio)
 	gpio_set_value(AMS_DELTA_GPIO_PIN_KEYBRD_PWR, 0);
 }
 
-static struct gpio ams_delta_gpios[] __initconst_or_module = {
+static const struct gpio ams_delta_gpios[] __initconst_or_module = {
 	{
 		.gpio	= AMS_DELTA_GPIO_PIN_KEYBRD_DATA,
 		.flags	= GPIOF_DIR_IN,
diff --git a/drivers/mtd/nand/ams-delta.c b/drivers/mtd/nand/ams-delta.c
index 85934dc..7341695 100644
--- a/drivers/mtd/nand/ams-delta.c
+++ b/drivers/mtd/nand/ams-delta.c
@@ -145,7 +145,7 @@ static int ams_delta_nand_ready(struct mtd_info *mtd)
 	return gpio_get_value(AMS_DELTA_GPIO_PIN_NAND_RB);
 }
 
-static struct gpio _mandatory_gpio[] __initconst_or_module = {
+static const struct gpio _mandatory_gpio[] = {
 	{
 		.gpio	= AMS_DELTA_GPIO_PIN_NAND_NCE,
 		.flags	= GPIOF_OUT_INIT_HIGH,
diff --git a/drivers/video/omap/lcd_ams_delta.c b/drivers/video/omap/lcd_ams_delta.c
index 0e71e28..d3a3113 100644
--- a/drivers/video/omap/lcd_ams_delta.c
+++ b/drivers/video/omap/lcd_ams_delta.c
@@ -99,7 +99,7 @@ static struct lcd_ops ams_delta_lcd_ops = {
 
 /* omapfb panel section */
 
-static struct gpio _gpios[] __initconst_or_module = {
+static const struct gpio _gpios[] = {
 	{
 		.gpio	= AMS_DELTA_GPIO_PIN_LCD_VBLEN,
 		.flags	= GPIOF_OUT_INIT_LOW,
-- 
1.7.3.4

[PATCH] ARM: OMAP1: ams-delta: correct init data section assignments

[Russell King - ARM Linux]

On Fri, Feb 10, 2012 at 05:31:31PM +0100, Janusz Krzysztofik wrote:
> On Thursday 09 of February 2012 14:48:53 Russell King - ARM Linux wrote:
> > > -static struct map_desc ams_delta_io_desc[] __initdata = {
> > > +static struct map_desc ams_delta_io_desc[] __initconst = {
> > 
> > You're not making this comst so don't change it to __initconst.
> 
> OK, however, I think there must be a bug in gcc, otherwise it should probably 
> never accept such wrong constructs, while sometimes it does (not only mine, 
> see [1]).

No - because you don't understand what's going on with these tags.
The __initconst and other tags are just tell the compiler to place
stuff into a named section.  The name is interpreted by GCC as a mere
string which it passes through to the ELF file.

So, gcc has no idea that a section named '.init.rodata' could be placed
in read-only memory, and therefore has no idea that it should also be
marked 'const'.

Therefore, gcc has no way to verify that 'const' and '__initconst' are
always paired.

> > > -static struct omap_lcd_config ams_delta_lcd_config = {
> > > +static struct omap_lcd_config ams_delta_lcd_config __initconst = {
> > 
> > This change probably adds a bug.  Are you sure this will never be used
> > outside init context?
> 
> I may be wrong, but before I've changed this, and now once again, I've verified 
> that a copy of this data is made inside __init omap_init_fb() by means of a 
> structure assignment operation.

Ok, in that case add a 'const' to it.

> > > -static struct omap_usb_config ams_delta_usb_config __initdata = {
> > > +static struct omap_usb_config ams_delta_usb_config __initdata_or_module
> > > = {
> > Even if you don't have modules enabled, have you checked whether the
> > driver can be bound and unbound via
> > /sys/bus/platform/driver/<name>/{bind,unbind} ?
> 
> No, I didn't even think of it, I am afraid.
> 
> > I suspect this is a bug.
> 
> Indeed, that data is not copied on init, only pointed to, moreover, the 
> ohci-omap driver provides bind/unbind opearations.
> 
> BTW, what are those bind/unbind operations intended for in case of a
> driver dedicated to a non-hotplugable SoC hardware exclusively?

If the driver can be built as a module, they allow exercising the
probe/remove paths for drivers which have been built-in.  Moreover,
it allows you to disable a device driver if desired.

For example, I have two platforms which are essentially the same, except
one has a daughterboard attached (which isn't hotpluggable).  The support
for the daughterboard, although it is a platform driver, can't be
modularised at the moment because quite a bit of other stuff needs it
and it contains IRQ chip code.

One has far less idle wakeups than the other.  Using unbind, I can
effectively detach this board by unbinding its platform device, which
results the entire sub-tree of its on-board devices being unregistered
and released in one big go, all the way down to things like USB devices
on the USB host.  I can then rebind it and bring all that hardware back.

That allows me to evaluate whether there's any impact from those drivers.

However, this bind/unbind is not the only issue here: how do you know
whether the driver takes a copy of the platform data, or merely stores a
pointer to it - and may access your platform data at runtime.

Unless you check, and recheck it regularly (it can change) then placing
this stuff into sections which will be discarded is asking for bugs.

> > > -static struct platform_device *ams_delta_devices[] __initdata = {
> > > +static struct platform_device *ams_delta_devices[] __initconst = {
> > 
> > Missing const.  If you can't const it, don't put it in __initconst.
> 
> I gave up trying to use both const and __initconst together after my gcc-4.2.4 
> (and not only mine, see [1], [2]) refused to accept such constructs a few 
> times. Now I see that this false reporting may probably happen in presence of other 
> incorrect uses of __initconst without const or __initdata with const.

I doubt that the compiler was refusing to accept them.  What you were
probably getting were warnings about where these were used not accepting
a const pointer.

If that's the case, more analysis needs to be done to find out whether
those uses can be converted to accept a const pointer before defining
the data with const and optionally __initconst.