[PATCH 01/17] ARM: shmobile: fix memory size for kota2_defconfig

[PATCH 01/17] ARM: shmobile: fix memory size for kota2_defconfig

[Arnd Bergmann]

The CONFIG_MEMORY_SIZE value is interpreted as a 32 bit integer, which
makes sense on a system without PAE. I'm assuming 0x10000000 (256 MB)
is the correct size, because that is used on most other shmobile
boards.

Without this patch, building kota2_defconfig results in:

/home/arnd/linux-arm/arch/arm/kernel/setup.c:790:2: warning: large integer implicitly truncated to unsigned type [-Woverflow]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: linux-sh@vger.kernel.org
Cc: Simon Horman <horms@verge.net.au>
---
 arch/arm/configs/kota2_defconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/configs/kota2_defconfig b/arch/arm/configs/kota2_defconfig
index b7735d6..0ea4c90 100644
--- a/arch/arm/configs/kota2_defconfig
+++ b/arch/arm/configs/kota2_defconfig
@@ -21,7 +21,7 @@ CONFIG_ARCH_SHMOBILE=y
 CONFIG_KEYBOARD_GPIO_POLLED=y
 CONFIG_ARCH_SH73A0=y
 CONFIG_MACH_KOTA2=y
-CONFIG_MEMORY_SIZE=0x1e0000000
+CONFIG_MEMORY_SIZE=0x10000000
 # CONFIG_SH_TIMER_TMU is not set
 # CONFIG_SWP_EMULATE is not set
 CONFIG_CPU_BPREDICT_DISABLE=y
-- 
1.7.10

[PATCH 02/17] ARM: shark: fix shark_pci_init return code

[Arnd Bergmann]

When run on the wrong platform, the shark_pci_init function
returns an undefined value, as reported by a gcc warning,
so let's just return -ENODEV.

Without this patch, building shark_defconfig results in:

arch/arm/mach-shark/pci.c: In function 'shark_pci_init':
arch/arm/mach-shark/pci.c:42:3: warning: 'return' with no value, in function returning non-void [-Wreturn-type]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: "Krzysztof Halasa" <khc@pm.waw.pl>
---
 arch/arm/mach-shark/pci.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-shark/pci.c b/arch/arm/mach-shark/pci.c
index 9089407..2b351a3 100644
--- a/arch/arm/mach-shark/pci.c
+++ b/arch/arm/mach-shark/pci.c
@@ -38,7 +38,7 @@ static struct hw_pci shark_pci __initdata = {
 static int __init shark_pci_init(void)
 {
 	if (!machine_is_shark())
-		return;
+		return -ENODEV;
 
 	pcibios_min_io = 0x6000;
 	pcibios_min_mem = 0x50000000;
-- 
1.7.10

[PATCH 03/17] ARM: pxa: Wunused-result warning in viper board file

[Arnd Bergmann]

Calling kstrtoul requires checking the result. In case of
the viper_tpm_setup function, let's fail the __setup function
if the number was invalid.

Without this patch, building viper_defconfig results in:

arch/arm/mach-pxa/viper.c: In function 'viper_tpm_setup':
arch/arm/mach-pxa/viper.c:771:10: warning: ignoring return value of 'kstrtoul', declared with attribute warn_unused_result [-Wunused-result]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: Marc Zyngier <maz@misterjones.org>
---
 arch/arm/mach-pxa/viper.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/mach-pxa/viper.c b/arch/arm/mach-pxa/viper.c
index 130379f..ac733e9 100644
--- a/arch/arm/mach-pxa/viper.c
+++ b/arch/arm/mach-pxa/viper.c
@@ -768,8 +768,7 @@ static unsigned long viper_tpm;
 
 static int __init viper_tpm_setup(char *str)
 {
-	strict_strtoul(str, 10, &viper_tpm);
-	return 1;
+	return strict_strtoul(str, 10, &viper_tpm) >= 0;
 }
 
 __setup("tpm=", viper_tpm_setup);
-- 
1.7.10

[PATCH 04/17] ARM: pxa: define palmte2_pxa_keys conditionally

[Arnd Bergmann]

Gcc prints a harmless warning about palmte2_pxa_keys not being used
when the gpio keyboard driver is disabled. The solution is to use
the same #ifdef that is already present in the place where the
symbol is used.

Without this patch, building palmz72_defconfig results in:

/home/arnd/linux-arm/arch/arm/mach-pxa/palmte2.c:128:31: warning: 'palmte2_pxa_keys' defined but not used [-Wunused-variable]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Marek Vasut <marek.vasut@gmail.com>
Cc: Carlos Eduardo Medaglia Dyonisio <cadu@nerdfeliz.com>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Eric Miao <eric.y.miao@gmail.com>
---
 arch/arm/mach-pxa/palmte2.c |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-pxa/palmte2.c b/arch/arm/mach-pxa/palmte2.c
index c054827..8497b28 100644
--- a/arch/arm/mach-pxa/palmte2.c
+++ b/arch/arm/mach-pxa/palmte2.c
@@ -105,6 +105,7 @@ static struct pxamci_platform_data palmte2_mci_platform_data = {
 	.gpio_power		= GPIO_NR_PALMTE2_SD_POWER,
 };
 
+#if defined(CONFIG_KEYBOARD_GPIO) || defined(CONFIG_KEYBOARD_GPIO_MODULE)
 /******************************************************************************
  * GPIO keys
  ******************************************************************************/
@@ -132,6 +133,7 @@ static struct platform_device palmte2_pxa_keys = {
 		.platform_data = &palmte2_pxa_keys_data,
 	},
 };
+#endif
 
 /******************************************************************************
  * Backlight
-- 
1.7.10

[PATCH 05/17] ARM: pxa: remove sharpsl_fatal_check function

[Arnd Bergmann]

The sharpsl_fatal_check has not been used since Pavel Machek removed
the caller in 99f329a2b "pxa/sharpsl_pm: zaurus c3000 aka spitz: fix
resume". Nobody has complained since 2009, so it's safe to assume we
can just remove the function.

Without this patch, building corgi_defconfig results in:

/home/arnd/linux-arm/arch/arm/mach-pxa/sharpsl_pm.c:693:12: warning: 'sharpsl_fatal_check' defined but not used [-Wunused-function]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Stanislav Brabec <utx@penguin.cz>
Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
---
 arch/arm/mach-pxa/sharpsl_pm.c |   48 ----------------------------------------
 1 file changed, 48 deletions(-)

diff --git a/arch/arm/mach-pxa/sharpsl_pm.c b/arch/arm/mach-pxa/sharpsl_pm.c
index bdf4cb8..6c9658f 100644
--- a/arch/arm/mach-pxa/sharpsl_pm.c
+++ b/arch/arm/mach-pxa/sharpsl_pm.c
@@ -55,7 +55,6 @@
 #ifdef CONFIG_PM
 static int sharpsl_off_charge_battery(void);
 static int sharpsl_check_battery_voltage(void);
-static int sharpsl_fatal_check(void);
 #endif
 static int sharpsl_check_battery_temp(void);
 static int sharpsl_ac_check(void);
@@ -686,53 +685,6 @@ static int corgi_pxa_pm_enter(suspend_state_t state)
 	return 0;
 }
 
-/*
- * Check for fatal battery errors
- * Fatal returns -1
- */
-static int sharpsl_fatal_check(void)
-{
-	int buff[5], temp, i, acin;
-
-	dev_dbg(sharpsl_pm.dev, "sharpsl_fatal_check entered\n");
-
-	/* Check AC-Adapter */
-	acin = sharpsl_pm.machinfo->read_devdata(SHARPSL_STATUS_ACIN);
-
-	if (acin && (sharpsl_pm.charge_mode == CHRG_ON)) {
-		sharpsl_pm.machinfo->charge(0);
-		udelay(100);
-		sharpsl_pm.machinfo->discharge(1);	/* enable discharge */
-		mdelay(SHARPSL_WAIT_DISCHARGE_ON);
-	}
-
-	if (sharpsl_pm.machinfo->discharge1)
-		sharpsl_pm.machinfo->discharge1(1);
-
-	/* Check battery : check inserting battery ? */
-	for (i = 0; i < 5; i++) {
-		buff[i] = sharpsl_pm.machinfo->read_devdata(SHARPSL_BATT_VOLT);
-		mdelay(SHARPSL_CHECK_BATTERY_WAIT_TIME_VOLT);
-	}
-
-	if (sharpsl_pm.machinfo->discharge1)
-		sharpsl_pm.machinfo->discharge1(0);
-
-	if (acin && (sharpsl_pm.charge_mode == CHRG_ON)) {
-		udelay(100);
-		sharpsl_pm.machinfo->charge(1);
-		sharpsl_pm.machinfo->discharge(0);
-	}
-
-	temp = get_select_val(buff);
-	dev_dbg(sharpsl_pm.dev, "sharpsl_fatal_check: acin: %d, discharge voltage: %d, no discharge: %ld\n", acin, temp, sharpsl_pm.machinfo->read_devdata(SHARPSL_BATT_VOLT));
-
-	if ((acin && (temp < sharpsl_pm.machinfo->fatal_acin_volt)) ||
-			(!acin && (temp < sharpsl_pm.machinfo->fatal_noacin_volt)))
-		return -1;
-	return 0;
-}
-
 static int sharpsl_off_charge_error(void)
 {
 	dev_err(sharpsl_pm.dev, "Offline Charger: Error occurred.\n");
-- 
1.7.10

[PATCH 06/17] ARM: pxa: work around duplicate definition of GPIO24_SSP1_SFRM

[Arnd Bergmann]

The symbol "GPIO24_SSP1_SFRM" is defined in both mfp-pxa27x.h and
mfp-pxa25x.h. Since the macro is not actually used in the cm-x2xx.c
file, but it includes both headers, a safe workaround should be
to just undefine it from the .c file. This is a bit hacky and
the headers should be fixed to not both define it, but for now
it gets us around an annoying warning.

Without this patch, building cm_x2xx_defconfig results in:

In file included from arch/arm/mach-pxa/include/mach-pxa/pxa27x.h:7:0,
                 from arch/arm/mach-pxa/cm-x2xx.c:25:
arch/arm/mach-pxa/include/mach-pxa/mfp-pxa27x.h:215:0: warning: "GPIO24_SSP1_SFRM" redefined [enabled by default]
arch/arm/mach-pxa/include/mach-pxa/mfp-pxa25x.h:111:0: note: this is the location of the previous definition

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Mike Rapoport <mike@compulab.co.il>
---
 arch/arm/mach-pxa/cm-x2xx.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-pxa/cm-x2xx.c b/arch/arm/mach-pxa/cm-x2xx.c
index 8fa4ad2..ae5e74a 100644
--- a/arch/arm/mach-pxa/cm-x2xx.c
+++ b/arch/arm/mach-pxa/cm-x2xx.c
@@ -22,6 +22,7 @@
 #include <asm/mach/map.h>
 
 #include <mach/pxa25x.h>
+#undef GPIO24_SSP1_SFRM
 #include <mach/pxa27x.h>
 #include <mach/audio.h>
 #include <mach/pxafb.h>
-- 
1.7.10

[PATCH 07/17] ARM: at91: skip at91_io_desc definition for NOMMU

[Arnd Bergmann]

On NOMMU systems, we do cannot remap the MMIO space, so the
definition of at91_io_desc is unused.

Without this patch, building at91x40_defconfig results in:

arch/arm/mach-at91/setup.c:90:24: warning: 'at91_io_desc' defined but not used [-Wunused-variable]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
---
 arch/arm/mach-at91/setup.c |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-at91/setup.c b/arch/arm/mach-at91/setup.c
index 944bffb..b9fdba0 100644
--- a/arch/arm/mach-at91/setup.c
+++ b/arch/arm/mach-at91/setup.c
@@ -87,12 +87,14 @@ void __init at91_init_sram(int bank, unsigned long base, unsigned int length)
 	iotable_init(desc, 1);
 }
 
+#ifdef CONFIG_MMU
 static struct map_desc at91_io_desc __initdata = {
 	.virtual	= AT91_VA_BASE_SYS,
 	.pfn		= __phys_to_pfn(AT91_BASE_SYS),
 	.length		= SZ_16K,
 	.type		= MT_DEVICE,
 };
+#endif
 
 static void __init soc_detect(u32 dbgu_base)
 {
-- 
1.7.10

[PATCH 08/17] ARM: at91: unused variable in at91_pm_verify_clocks

[Arnd Bergmann]

The code using the variable 'i' in this function is conditional, so
we have to make the declaration conditional as well to avoid a harmless
warning.

Without this patch, building at91sam9263_defconfig results in:

/home/arnd/linux-arm/arch/arm/mach-at91/pm.c: In function 'at91_pm_verify_clocks':
/home/arnd/linux-arm/arch/arm/mach-at91/pm.c:137:6: warning: unused variable 'i' [-Wunused-variable]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
---
 arch/arm/mach-at91/pm.c |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 2c2d865..cdd620d 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -135,7 +135,9 @@ static int at91_pm_begin(suspend_state_t state)
 static int at91_pm_verify_clocks(void)
 {
 	unsigned long scsr;
+#ifdef CONFIG_AT91_PROGRAMMABLE_CLOCKS
 	int i;
+#endif
 
 	scsr = at91_pmc_read(AT91_PMC_SCSR);
 
-- 
1.7.10

[PATCH 09/17] ARM: imx: select ARM_CPU_SUSPEND if necessary

[Arnd Bergmann]

As tests using 'make randconfig' showed, imx5 requires the same logic
as imx6 to select ARM_CPU_SUSPEND when building with power management
enabled.

The defconfig does not have this problem because it enables imx6
as well, but disabling it leads to this warning:

arch/arm/mach-imx/built-in.o: In function `v7_cpu_resume':
arch/arm/mach-imx/head-v7.S:104: undefined reference to `cpu_resume'

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Shawn Guo <shawn.guo@linaro.org>
---
 arch/arm/mach-imx/Kconfig |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index afd542a..8e96573 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -89,6 +89,7 @@ config SOC_IMX5
 	select ARCH_MXC_IOMUX_V3
 	select ARCH_HAS_CPUFREQ
 	select ARCH_MX5
+	select ARM_CPU_SUSPEND if PM
 	bool
 
 config SOC_IMX50
-- 
1.7.10

[PATCH 10/17] ARM: s3c24xx: fix multiple section mismatch warnings

[Arnd Bergmann]

The *_irq_add function should not be marked __init because the driver
subsystem thinks they might be called at a later stage.

The usb_simtec_init function accesses initdata and should be marked
init. This is safe because the only caller is also an init function.

Without this patch, building s3c2410_defconfig results in:

WARNING: arch/arm/mach-s3c24xx/built-in.o(.data+0x1030): Section mismatch in reference from the variable s3c2416_irq_interface to the function .init.text:s3c2416_irq_add()
The variable s3c2416_irq_interface references
the function __init s3c2416_irq_add()
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: arch/arm/mach-s3c24xx/built-in.o(.data+0x1b08): Section mismatch in reference from the variable s3c2443_irq_interface to the function .init.text:s3c2443_irq_add()
The variable s3c2443_irq_interface references
the function __init s3c2443_irq_add()
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: arch/arm/mach-s3c24xx/built-in.o(.data+0xf44): Section mismatch in reference from the variable s3c2416_irq_interface to the function .init.text:s3c2416_irq_add()
The variable s3c2416_irq_interface references
the function __init s3c2416_irq_add()
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: arch/arm/mach-s3c24xx/built-in.o(.text+0x3f7c): Section mismatch in reference from the function usb_simtec_init() to the (unknown reference) .init.data:(unknown)
The function usb_simtec_init() references
the (unknown reference) __initdata (unknown).
This is often because usb_simtec_init lacks a __initdata
annotation or the annotation of (unknown) is wrong.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Kukjin Kim <kgene.kim@samsung.com>
---
 arch/arm/mach-s3c24xx/irq-s3c2416.c |    6 +++---
 arch/arm/mach-s3c24xx/irq-s3c2443.c |    4 ++--
 arch/arm/mach-s3c24xx/simtec-usb.c  |    2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-s3c24xx/irq-s3c2416.c b/arch/arm/mach-s3c24xx/irq-s3c2416.c
index 23ec973..ff141b0 100644
--- a/arch/arm/mach-s3c24xx/irq-s3c2416.c
+++ b/arch/arm/mach-s3c24xx/irq-s3c2416.c
@@ -232,7 +232,7 @@ struct irq_chip s3c2416_irq_second = {
 
 /* IRQ initialisation code */
 
-static int __init s3c2416_add_sub(unsigned int base,
+static int s3c2416_add_sub(unsigned int base,
 				   void (*demux)(unsigned int,
 						 struct irq_desc *),
 				   struct irq_chip *chip,
@@ -251,7 +251,7 @@ static int __init s3c2416_add_sub(unsigned int base,
 	return 0;
 }
 
-static void __init s3c2416_irq_add_second(void)
+static void s3c2416_irq_add_second(void)
 {
 	unsigned long pend;
 	unsigned long last;
@@ -287,7 +287,7 @@ static void __init s3c2416_irq_add_second(void)
 	}
 }
 
-static int __init s3c2416_irq_add(struct device *dev,
+static int s3c2416_irq_add(struct device *dev,
 				  struct subsys_interface *sif)
 {
 	printk(KERN_INFO "S3C2416: IRQ Support\n");
diff --git a/arch/arm/mach-s3c24xx/irq-s3c2443.c b/arch/arm/mach-s3c24xx/irq-s3c2443.c
index ac2829f..5e69109 100644
--- a/arch/arm/mach-s3c24xx/irq-s3c2443.c
+++ b/arch/arm/mach-s3c24xx/irq-s3c2443.c
@@ -222,7 +222,7 @@ static struct irq_chip s3c2443_irq_cam = {
 
 /* IRQ initialisation code */
 
-static int __init s3c2443_add_sub(unsigned int base,
+static int s3c2443_add_sub(unsigned int base,
 				   void (*demux)(unsigned int,
 						 struct irq_desc *),
 				   struct irq_chip *chip,
@@ -241,7 +241,7 @@ static int __init s3c2443_add_sub(unsigned int base,
 	return 0;
 }
 
-static int __init s3c2443_irq_add(struct device *dev,
+static int s3c2443_irq_add(struct device *dev,
 				  struct subsys_interface *sif)
 {
 	printk("S3C2443: IRQ Support\n");
diff --git a/arch/arm/mach-s3c24xx/simtec-usb.c b/arch/arm/mach-s3c24xx/simtec-usb.c
index d91c1a7..c303d1b 100644
--- a/arch/arm/mach-s3c24xx/simtec-usb.c
+++ b/arch/arm/mach-s3c24xx/simtec-usb.c
@@ -104,7 +104,7 @@ static struct s3c2410_hcd_info usb_simtec_info __initdata = {
 };
 
 
-int usb_simtec_init(void)
+int __init usb_simtec_init(void)
 {
 	int ret;
 
-- 
1.7.10

[PATCH 11/17] ARM: mv78xx0: mark mv78xx0_timer_init as __init_refok

[Arnd Bergmann]

The sys_timer init function is only called at __init time,
so it's safe to mark mv78xx0_timer_init as __init_refok,
which allows us to call orion_time_init without getting
a link time warning.

Without this patch, building mv78xx0_defconfig results in:

WARNING: vmlinux.o(.text+0x15470): Section mismatch in reference from the function mv78xx0_timer_init() to the function .init.text:orion_time_init()
The function mv78xx0_timer_init() references
the function __init orion_time_init().
This is often because mv78xx0_timer_init lacks a __init
annotation or the annotation of orion_time_init is wrong.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
---
 arch/arm/mach-mv78xx0/common.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-mv78xx0/common.c b/arch/arm/mach-mv78xx0/common.c
index 3057f7d..e251ebc 100644
--- a/arch/arm/mach-mv78xx0/common.c
+++ b/arch/arm/mach-mv78xx0/common.c
@@ -341,7 +341,7 @@ void __init mv78xx0_init_early(void)
 	orion_time_set_base(TIMER_VIRT_BASE);
 }
 
-static void mv78xx0_timer_init(void)
+static void __init_refok mv78xx0_timer_init(void)
 {
 	orion_time_init(BRIDGE_VIRT_BASE, BRIDGE_INT_TIMER1_CLR,
 			IRQ_MV78XX0_TIMER_1, get_tclk());
-- 
1.7.10

[PATCH 12/17] ARM: iop13xx: mark iop13xx_scan_bus as __devinit

[Arnd Bergmann]

pci_scan_root_bus is __devinit, so iop13xx_scan_bus has to be the
same in order to safely call it. This is ok because the function
itself is only called from the hwpci->scan callback.

WARNING: vmlinux.o(.text+0x10138): Section mismatch in reference from the function iop13xx_scan_bus() to the function .devinit.text:pci_scan_root_bus()
The function iop13xx_scan_bus() references
the function __devinit pci_scan_root_bus().
This is often because iop13xx_scan_bus lacks a __devinit
annotation or the annotation of pci_scan_root_bus is wrong.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Lennert Buytenhek <kernel@wantstofly.org>
Cc: Dan Williams <djbw@fb.com>
---
 arch/arm/mach-iop13xx/pci.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-iop13xx/pci.c b/arch/arm/mach-iop13xx/pci.c
index 861cb12..9d7f4ca 100644
--- a/arch/arm/mach-iop13xx/pci.c
+++ b/arch/arm/mach-iop13xx/pci.c
@@ -506,7 +506,7 @@ iop13xx_pci_abort(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
 
 /* Scan an IOP13XX PCI bus.  nr selects which ATU we use.
  */
-struct pci_bus *iop13xx_scan_bus(int nr, struct pci_sys_data *sys)
+struct pci_bus * __devinit iop13xx_scan_bus(int nr, struct pci_sys_data *sys)
 {
 	int which_atu;
 	struct pci_bus *bus = NULL;
-- 
1.7.10

[PATCH 13/17] ARM: iop13xx: fix iq81340sc_atux_map_irq prototype

[Arnd Bergmann]

The pci map_irq callbacks get a 'const' pci_dev argument, so change the
iop13xx version to use the same prototype as everything else.

Without this patch, building iop13xx_defconfig results in:

arch/arm/mach-iop13xx/iq81340sc.c:63:2: warning: initialization from incompatible pointer type [enabled by default]
arch/arm/mach-iop13xx/iq81340sc.c:63:2: warning: (near initialization for 'iq81340sc_pci.map_irq') [enabled by default]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Lennert Buytenhek <kernel@wantstofly.org>
Cc: Dan Williams <djbw@fb.com>
---
 arch/arm/mach-iop13xx/iq81340sc.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-iop13xx/iq81340sc.c b/arch/arm/mach-iop13xx/iq81340sc.c
index 060cddd..e947441 100644
--- a/arch/arm/mach-iop13xx/iq81340sc.c
+++ b/arch/arm/mach-iop13xx/iq81340sc.c
@@ -30,7 +30,7 @@
 extern int init_atu;
 
 static int __init
-iq81340sc_atux_map_irq(struct pci_dev *dev, u8 idsel, u8 pin)
+iq81340sc_atux_map_irq(const struct pci_dev *dev, u8 idsel, u8 pin)
 {
 	WARN_ON(idsel < 1 || idsel > 2);
 
-- 
1.7.10

[PATCH 14/17] ARM: davinci: don't mark da850_register_cpufreq as __init

[Arnd Bergmann]

The mityomapl138_cpufreq_init and read_factory_config function in
board-mityomapl138.c are not __init functions and might be called
at a later stage, so da850_register_cpufreq must not be __init either.

Without this patch, building da8xx_omapl_defconfig results in:

WARNING: arch/arm/mach-davinci/built-in.o(.text+0x2eb4): Section mismatch in reference from the function read_factory_config() to the function .init.text:da850_register_cpufreq()
The function read_factory_config() references
the function __init da850_register_cpufreq().
This is often because read_factory_config lacks a __init
annotation or the annotation of da850_register_cpufreq is wrong.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
---
 arch/arm/mach-davinci/da850.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index b44dc84..8329e5b 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -939,7 +939,7 @@ static struct platform_device da850_cpufreq_device = {
 
 unsigned int da850_max_speed = 300000;
 
-int __init da850_register_cpufreq(char *async_clk)
+int da850_register_cpufreq(char *async_clk)
 {
 	int i;
 
-- 
1.7.10

[PATCH 15/17] ARM: rpc: check device_register return code in ecard_probe

[Arnd Bergmann]

device_register is marked __must_check, so we better propagate the error
value by returning it from ecard_probe.

Without this patch, building rpc_defconfig results in:

arch/arm/mach-rpc/ecard.c: In function 'ecard_probe':
arch/arm/mach-rpc/ecard.c:963:17: warning: ignoring return value of 'device_register', declared with attribute warn_unused_result [-Wunused-result]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/mach-rpc/ecard.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-rpc/ecard.c b/arch/arm/mach-rpc/ecard.c
index b91bc87..fcb1d59 100644
--- a/arch/arm/mach-rpc/ecard.c
+++ b/arch/arm/mach-rpc/ecard.c
@@ -960,7 +960,9 @@ static int __init ecard_probe(int slot, unsigned irq, card_type_t type)
 	*ecp = ec;
 	slot_to_expcard[slot] = ec;
 
-	device_register(&ec->dev);
+	rc = device_register(&ec->dev);
+	if (rc)
+		goto nodev;
 
 	return 0;
 
-- 
1.7.10

[PATCH 16/17] ARM: ks8695: __arch_virt_to_dma type handling

[Arnd Bergmann]

__arch_virt_to_dma expects a virtual address pointer, but
the ks8695 implementation of this macro treats it as an
integer. Adding a type cast avoids hundreds of identical
warning messages.

Without this patch, building acs5k_defconfig results in:

arch/arm/include/asm/dma-mapping.h: In function 'virt_to_dma':
arch/arm/include/asm/dma-mapping.h:60:2: warning: passing argument 1 of '__virt_to_phys' makes integer from pointer without a cast [enabled by default]
arch/arm/include/asm/memory.h:172:60: note: expected 'long unsigned int' but argument is of type 'void *'
In file included from include/linux/dma-mapping.h:73:0,
                 from include/linux/skbuff.h:33,
                 from security/commoncap.c:21:

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Krzysztof Halasa <khc@pm.waw.pl>
Cc: Daniel Silverstone <dsilvers@simtec.co.uk>
Cc: Ben Dooks <ben-linux@fluff.org>
---
 arch/arm/mach-ks8695/include/mach/memory.h |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-ks8695/include/mach/memory.h b/arch/arm/mach-ks8695/include/mach/memory.h
index f7e1b9b..95e731a 100644
--- a/arch/arm/mach-ks8695/include/mach/memory.h
+++ b/arch/arm/mach-ks8695/include/mach/memory.h
@@ -34,7 +34,8 @@ extern struct bus_type platform_bus_type;
 #define __arch_dma_to_virt(dev, x)	({ (void *) (is_lbus_device(dev) ? \
 					__phys_to_virt(x) : __bus_to_virt(x)); })
 #define __arch_virt_to_dma(dev, x)	({ is_lbus_device(dev) ? \
-					(dma_addr_t)__virt_to_phys(x) : (dma_addr_t)__virt_to_bus(x); })
+					(dma_addr_t)__virt_to_phys((unsigned long)x) \
+					: (dma_addr_t)__virt_to_bus(x); })
 #define __arch_pfn_to_dma(dev, pfn)	\
 	({ dma_addr_t __dma = __pfn_to_phys(pfn); \
 	   if (!is_lbus_device(dev)) \
-- 
1.7.10

[PATCH 17/17] ARM: soc: dependency warnings for errata

[Arnd Bergmann]

The PL310_ERRATA_753970 and ARM_ERRATA_764369 symbols only make sense
when the base features for them are enabled, so select them
conditionally in Kconfig to avoid warnings like:

warning: (UX500_SOC_COMMON) selects PL310_ERRATA_753970 which has unmet direct dependencies (CACHE_PL310)
warning: (ARCH_TEGRA_2x_SOC && ARCH_TEGRA_3x_SOC && UX500_SOC_COMMON) selects ARM_ERRATA_764369 which has unmet direct dependencies (CPU_V7 && SMP)

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Stephen Warren <swarren@wwwdotorg.org>
---
 arch/arm/mach-tegra/Kconfig |    4 ++--
 arch/arm/mach-ux500/Kconfig |    4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index 9077aaa..b5f62ab 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -16,7 +16,7 @@ config ARCH_TEGRA_2x_SOC
 	select ARM_ERRATA_742230
 	select ARM_ERRATA_751472
 	select ARM_ERRATA_754327
-	select ARM_ERRATA_764369
+	select ARM_ERRATA_764369 if SMP
 	select PL310_ERRATA_727915 if CACHE_L2X0
 	select PL310_ERRATA_769419 if CACHE_L2X0
 	select CPU_FREQ_TABLE if CPU_FREQ
@@ -38,7 +38,7 @@ config ARCH_TEGRA_3x_SOC
 	select ARM_ERRATA_743622
 	select ARM_ERRATA_751472
 	select ARM_ERRATA_754322
-	select ARM_ERRATA_764369
+	select ARM_ERRATA_764369 if SMP
 	select PL310_ERRATA_769419 if CACHE_L2X0
 	select CPU_FREQ_TABLE if CPU_FREQ
 	help
diff --git a/arch/arm/mach-ux500/Kconfig b/arch/arm/mach-ux500/Kconfig
index 53d3d46..18755f1 100644
--- a/arch/arm/mach-ux500/Kconfig
+++ b/arch/arm/mach-ux500/Kconfig
@@ -5,9 +5,9 @@ config UX500_SOC_COMMON
 	default y
 	select ARM_GIC
 	select HAS_MTU
-	select PL310_ERRATA_753970
+	select PL310_ERRATA_753970 if CACHE_PL310
 	select ARM_ERRATA_754322
-	select ARM_ERRATA_764369
+	select ARM_ERRATA_764369 if SMP
 	select CACHE_L2X0
 	select PINCTRL
 	select PINCTRL_NOMADIK
-- 
1.7.10

Re: [PATCH 03/17] ARM: pxa: Wunused-result warning in viper board file

[Marc Zyngier]

On Tue,  2 Oct 2012 18:36:42 +0200, Arnd Bergmann <arnd@arndb.de> wrote:
> Calling kstrtoul requires checking the result. In case of
> the viper_tpm_setup function, let's fail the __setup function
> if the number was invalid.
> 
> Without this patch, building viper_defconfig results in:
> 
> arch/arm/mach-pxa/viper.c: In function 'viper_tpm_setup':
> arch/arm/mach-pxa/viper.c:771:10: warning: ignoring return value of
> 'kstrtoul', declared with attribute warn_unused_result [-Wunused-result]
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
> Cc: Eric Miao <eric.y.miao@gmail.com>
> Cc: Marc Zyngier <maz@misterjones.org>

Acked-by: Marc Zyngier <maz@misterjones.org>

> ---
>  arch/arm/mach-pxa/viper.c |    3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-pxa/viper.c b/arch/arm/mach-pxa/viper.c
> index 130379f..ac733e9 100644
> --- a/arch/arm/mach-pxa/viper.c
> +++ b/arch/arm/mach-pxa/viper.c
> @@ -768,8 +768,7 @@ static unsigned long viper_tpm;
>  
>  static int __init viper_tpm_setup(char *str)
>  {
> -	strict_strtoul(str, 10, &viper_tpm);
> -	return 1;
> +	return strict_strtoul(str, 10, &viper_tpm) >= 0;
>  }
>  
>  __setup("tpm=", viper_tpm_setup);

-- 
Who you jivin' with that Cosmik Debris?

Re: [PATCH 17/17] ARM: soc: dependency warnings for errata

[Stephen Warren]

On 10/02/2012 10:36 AM, Arnd Bergmann wrote:
> The PL310_ERRATA_753970 and ARM_ERRATA_764369 symbols only make sense
> when the base features for them are enabled, so select them
> conditionally in Kconfig to avoid warnings like:
> 
> warning: (UX500_SOC_COMMON) selects PL310_ERRATA_753970 which has unmet direct dependencies (CACHE_PL310)
> warning: (ARCH_TEGRA_2x_SOC && ARCH_TEGRA_3x_SOC && UX500_SOC_COMMON) selects ARM_ERRATA_764369 which has unmet direct dependencies (CPU_V7 && SMP)

Acked-by: Stephen Warren <swarren@nvidia.com>

Re: [PATCH 08/17] ARM: at91: unused variable in at91_pm_verify_clocks

[Jean-Christophe PLAGNIOL-VILLARD]

On 18:36 Tue 02 Oct     , Arnd Bergmann wrote:
> The code using the variable 'i' in this function is conditional, so
> we have to make the declaration conditional as well to avoid a harmless
> warning.
> 
> Without this patch, building at91sam9263_defconfig results in:
> 
> /home/arnd/linux-arm/arch/arm/mach-at91/pm.c: In function 'at91_pm_verify_clocks':
> /home/arnd/linux-arm/arch/arm/mach-at91/pm.c:137:6: warning: unused variable 'i' [-Wunused-variable]
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> ---
>  arch/arm/mach-at91/pm.c |    2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
> index 2c2d865..cdd620d 100644
> --- a/arch/arm/mach-at91/pm.c
> +++ b/arch/arm/mach-at91/pm.c
> @@ -135,7 +135,9 @@ static int at91_pm_begin(suspend_state_t state)
>  static int at91_pm_verify_clocks(void)
>  {
>  	unsigned long scsr;
> +#ifdef CONFIG_AT91_PROGRAMMABLE_CLOCKS
>  	int i;
> +#endif
please is if (IS_ENBLED())

#ifdef drop code coverage

Best Regards,
J.

Re: [PATCH 07/17] ARM: at91: skip at91_io_desc definition for NOMMU

[Jean-Christophe PLAGNIOL-VILLARD]

On 18:36 Tue 02 Oct     , Arnd Bergmann wrote:
> On NOMMU systems, we do cannot remap the MMIO space, so the
> definition of at91_io_desc is unused.
> 
> Without this patch, building at91x40_defconfig results in:
> 
> arch/arm/mach-at91/setup.c:90:24: warning: 'at91_io_desc' defined but not used [-Wunused-variable]
I prefer a __maybe_unused on the struct so the compilator will just drop it

Best Regards,
J.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> ---
>  arch/arm/mach-at91/setup.c |    2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/mach-at91/setup.c b/arch/arm/mach-at91/setup.c
> index 944bffb..b9fdba0 100644
> --- a/arch/arm/mach-at91/setup.c
> +++ b/arch/arm/mach-at91/setup.c
> @@ -87,12 +87,14 @@ void __init at91_init_sram(int bank, unsigned long base, unsigned int length)
>  	iotable_init(desc, 1);
>  }
>  
> +#ifdef CONFIG_MMU
>  static struct map_desc at91_io_desc __initdata = {
>  	.virtual	= AT91_VA_BASE_SYS,
>  	.pfn		= __phys_to_pfn(AT91_BASE_SYS),
>  	.length		= SZ_16K,
>  	.type		= MT_DEVICE,
>  };
> +#endif
>  
>  static void __init soc_detect(u32 dbgu_base)
>  {
> -- 
> 1.7.10
> 

Re: [PATCH 12/17] ARM: iop13xx: mark iop13xx_scan_bus as __devinit

[Bjorn Helgaas]

On Tue, Oct 2, 2012 at 10:36 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> pci_scan_root_bus is __devinit, so iop13xx_scan_bus has to be the
> same in order to safely call it. This is ok because the function
> itself is only called from the hwpci->scan callback.
>
> WARNING: vmlinux.o(.text+0x10138): Section mismatch in reference from the function iop13xx_scan_bus() to the function .devinit.text:pci_scan_root_bus()
> The function iop13xx_scan_bus() references
> the function __devinit pci_scan_root_bus().
> This is often because iop13xx_scan_bus lacks a __devinit
> annotation or the annotation of pci_scan_root_bus is wrong.

With CONFIG_HOTPLUG going away (I think the current state is that it
is always set to "y"), __devinit will effectively become a no-op, so I
expect we'll remove it from pci_scan_root_bus().

Therefore, I would skip this patch and live with the warning a little longer.

> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Lennert Buytenhek <kernel@wantstofly.org>
> Cc: Dan Williams <djbw@fb.com>
> ---
>  arch/arm/mach-iop13xx/pci.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-iop13xx/pci.c b/arch/arm/mach-iop13xx/pci.c
> index 861cb12..9d7f4ca 100644
> --- a/arch/arm/mach-iop13xx/pci.c
> +++ b/arch/arm/mach-iop13xx/pci.c
> @@ -506,7 +506,7 @@ iop13xx_pci_abort(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
>
>  /* Scan an IOP13XX PCI bus.  nr selects which ATU we use.
>   */
> -struct pci_bus *iop13xx_scan_bus(int nr, struct pci_sys_data *sys)
> +struct pci_bus * __devinit iop13xx_scan_bus(int nr, struct pci_sys_data *sys)
>  {
>         int which_atu;
>         struct pci_bus *bus = NULL;
> --
> 1.7.10
>

Re: [PATCH 01/17] ARM: shmobile: fix memory size for kota2_defconfig

[Simon Horman]

On Tue, Oct 02, 2012 at 06:36:40PM +0200, Arnd Bergmann wrote:
> The CONFIG_MEMORY_SIZE value is interpreted as a 32 bit integer, which
> makes sense on a system without PAE. I'm assuming 0x10000000 (256 MB)
> is the correct size, because that is used on most other shmobile
> boards.
> 
> Without this patch, building kota2_defconfig results in:

Hi Arnd,

I looked through my fines and found a config that I believe
worked with a derivative of 2.6.35.7.

It has CONFIG_MEMORY_SIZE=0x1e800000.

So what I suspect has happened is that an extra zero has crept into
arch/arm/configs/kota2_defconfig and the intended value is:

CONFIG_MEMORY_SIZE=0x1e000000

Unfortunately I do not have access to a board to test this,
nor am I aware of anyone who does.

> /home/arnd/linux-arm/arch/arm/kernel/setup.c:790:2: warning: large integer implicitly truncated to unsigned type [-Woverflow]
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Paul Mundt <lethal@linux-sh.org>
> Cc: Magnus Damm <magnus.damm@gmail.com>
> Cc: linux-sh@vger.kernel.org
> Cc: Simon Horman <horms@verge.net.au>
> ---
>  arch/arm/configs/kota2_defconfig |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/configs/kota2_defconfig b/arch/arm/configs/kota2_defconfig
> index b7735d6..0ea4c90 100644
> --- a/arch/arm/configs/kota2_defconfig
> +++ b/arch/arm/configs/kota2_defconfig
> @@ -21,7 +21,7 @@ CONFIG_ARCH_SHMOBILE=y
>  CONFIG_KEYBOARD_GPIO_POLLED=y
>  CONFIG_ARCH_SH73A0=y
>  CONFIG_MACH_KOTA2=y
> -CONFIG_MEMORY_SIZE=0x1e0000000
> +CONFIG_MEMORY_SIZE=0x10000000
>  # CONFIG_SH_TIMER_TMU is not set
>  # CONFIG_SWP_EMULATE is not set
>  CONFIG_CPU_BPREDICT_DISABLE=y
> -- 
> 1.7.10
> 

Re: [PATCH 06/17] ARM: pxa: work around duplicate definition of GPIO24_SSP1_SFRM

[Igor Grinberg]

On 10/02/12 18:36, Arnd Bergmann wrote:
> The symbol "GPIO24_SSP1_SFRM" is defined in both mfp-pxa27x.h and
> mfp-pxa25x.h. Since the macro is not actually used in the cm-x2xx.c
> file, but it includes both headers, a safe workaround should be
> to just undefine it from the .c file. This is a bit hacky and
> the headers should be fixed to not both define it, but for now
> it gets us around an annoying warning.

Yep, agreed...

> 
> Without this patch, building cm_x2xx_defconfig results in:
> 
> In file included from arch/arm/mach-pxa/include/mach-pxa/pxa27x.h:7:0,
>                  from arch/arm/mach-pxa/cm-x2xx.c:25:
> arch/arm/mach-pxa/include/mach-pxa/mfp-pxa27x.h:215:0: warning: "GPIO24_SSP1_SFRM" redefined [enabled by default]
> arch/arm/mach-pxa/include/mach-pxa/mfp-pxa25x.h:111:0: note: this is the location of the previous definition
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
> Cc: Mike Rapoport <mike@compulab.co.il>

Acked-by: Igor Grinberg <grinberg@compulab.co.il>

Thanks for the patch.

> ---
>  arch/arm/mach-pxa/cm-x2xx.c |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/mach-pxa/cm-x2xx.c b/arch/arm/mach-pxa/cm-x2xx.c
> index 8fa4ad2..ae5e74a 100644
> --- a/arch/arm/mach-pxa/cm-x2xx.c
> +++ b/arch/arm/mach-pxa/cm-x2xx.c
> @@ -22,6 +22,7 @@
>  #include <asm/mach/map.h>
>  
>  #include <mach/pxa25x.h>
> +#undef GPIO24_SSP1_SFRM
>  #include <mach/pxa27x.h>
>  #include <mach/audio.h>
>  #include <mach/pxafb.h>

-- 
Regards,
Igor.

Re: [PATCH 17/17] ARM: soc: dependency warnings for errata

[Linus Walleij]

On Tue, Oct 2, 2012 at 6:36 PM, Arnd Bergmann <arnd@arndb.de> wrote:

> The PL310_ERRATA_753970 and ARM_ERRATA_764369 symbols only make sense
> when the base features for them are enabled, so select them
> conditionally in Kconfig to avoid warnings like:
>
> warning: (UX500_SOC_COMMON) selects PL310_ERRATA_753970 which has unmet direct dependencies (CACHE_PL310)
> warning: (ARCH_TEGRA_2x_SOC && ARCH_TEGRA_3x_SOC && UX500_SOC_COMMON) selects ARM_ERRATA_764369 which has unmet direct dependencies (CPU_V7 && SMP)
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Stephen Warren <swarren@wwwdotorg.org>

Makes perfect sense.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

Re: [PATCH 04/17] ARM: pxa: define palmte2_pxa_keys conditionally

[Marek Vasut]

Dear Arnd Bergmann,

> Gcc prints a harmless warning about palmte2_pxa_keys not being used
> when the gpio keyboard driver is disabled. The solution is to use
> the same #ifdef that is already present in the place where the
> symbol is used.
> 
> Without this patch, building palmz72_defconfig results in:
> 
> /home/arnd/linux-arm/arch/arm/mach-pxa/palmte2.c:128:31: warning:
> 'palmte2_pxa_keys' defined but not used [-Wunused-variable]
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Marek Vasut <marek.vasut@gmail.com>
> Cc: Carlos Eduardo Medaglia Dyonisio <cadu@nerdfeliz.com>
> Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
> Cc: Eric Miao <eric.y.miao@gmail.com>

Acked-by: Marek Vasut <marex@denx.de>

Thanks Arnd

Best regards,
Marek Vasut

Re: [PATCH 07/17] ARM: at91: skip at91_io_desc definition for NOMMU

[Arnd Bergmann]

On Tuesday 02 October 2012, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 18:36 Tue 02 Oct     , Arnd Bergmann wrote:
> > On NOMMU systems, we do cannot remap the MMIO space, so the
> > definition of at91_io_desc is unused.
> > 
> > Without this patch, building at91x40_defconfig results in:
> > 
> > arch/arm/mach-at91/setup.c:90:24: warning: 'at91_io_desc' defined but not used [-Wunused-variable]
> I prefer a __maybe_unused on the struct so the compilator will just drop it
> 

Ok, makes sense. I've fixed up the patch accordingly.

	Arnd

Re: [PATCH 08/17] ARM: at91: unused variable in at91_pm_verify_clocks

[Arnd Bergmann]

On Tuesday 02 October 2012, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >  	unsigned long scsr;
> > +#ifdef CONFIG_AT91_PROGRAMMABLE_CLOCKS
> >  	int i;
> > +#endif
> please is if (IS_ENBLED())
> 
> #ifdef drop code coverage
> 

Ok, agreed. Here is the new version:

>From bacd47abb36104665261c84f6f85bba7aef8a521 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@arndb.de>
Date: Mon, 30 Apr 2012 13:00:32 +0000
Subject: [PATCH] ARM: at91: unused variable in at91_pm_verify_clocks

The code using the variable 'i' in this function is conditional which
results in a harmless compiler warning. Using the IS_ENABLED macro
instead of #ifdef makes the code look nicer and gets rid of the
warning.

Without this patch, building at91sam9263_defconfig results in:

/home/arnd/linux-arm/arch/arm/mach-at91/pm.c: In function 'at91_pm_verify_clocks':
/home/arnd/linux-arm/arch/arm/mach-at91/pm.c:137:6: warning: unused variable 'i' [-Wunused-variable]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>

diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 2c2d865..5315f05 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -153,7 +153,9 @@ static int at91_pm_verify_clocks(void)
 		}
 	}
 
-#ifdef CONFIG_AT91_PROGRAMMABLE_CLOCKS
+	if (!IS_ENABLED(CONFIG_AT91_PROGRAMMABLE_CLOCKS))
+		return 1;
+
 	/* PCK0..PCK3 must be disabled, or configured to use clk32k */
 	for (i = 0; i < 4; i++) {
 		u32 css;
@@ -167,7 +169,6 @@ static int at91_pm_verify_clocks(void)
 			return 0;
 		}
 	}
-#endif
 
 	return 1;
 }

Re: [PATCH 01/17] ARM: shmobile: fix memory size for kota2_defconfig

[Arnd Bergmann]

On Wednesday 03 October 2012, Simon Horman wrote:
> I looked through my fines and found a config that I believe
> worked with a derivative of 2.6.35.7.
> 
> It has CONFIG_MEMORY_SIZE=0x1e800000.
> 
> So what I suspect has happened is that an extra zero has crept into
> arch/arm/configs/kota2_defconfig and the intended value is:
> 
> CONFIG_MEMORY_SIZE=0x1e000000
> 
> Unfortunately I do not have access to a board to test this,
> nor am I aware of anyone who does.

Ok, I'll drop this patch for now then, so we keep the warning around
to remind us of the problem.

	Arnd

Re: [PATCH 01/17] ARM: shmobile: fix memory size for kota2_defconfig

[Simon Horman]

On Thu, Oct 04, 2012 at 08:34:54AM +0000, Arnd Bergmann wrote:
> On Wednesday 03 October 2012, Simon Horman wrote:
> > I looked through my fines and found a config that I believe
> > worked with a derivative of 2.6.35.7.
> > 
> > It has CONFIG_MEMORY_SIZE=0x1e800000.
> > 
> > So what I suspect has happened is that an extra zero has crept into
> > arch/arm/configs/kota2_defconfig and the intended value is:
> > 
> > CONFIG_MEMORY_SIZE=0x1e000000
> > 
> > Unfortunately I do not have access to a board to test this,
> > nor am I aware of anyone who does.
> 
> Ok, I'll drop this patch for now then, so we keep the warning around
> to remind us of the problem.

Thanks. I have subsequently located a Kota2 board,
however it may be a little while before I get my hands on it.

Re: [PATCH 12/17] ARM: iop13xx: mark iop13xx_scan_bus as __devinit

[Arnd Bergmann]

(+Greg)

On Tuesday 02 October 2012, Bjorn Helgaas wrote:
> 
> On Tue, Oct 2, 2012 at 10:36 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > pci_scan_root_bus is __devinit, so iop13xx_scan_bus has to be the
> > same in order to safely call it. This is ok because the function
> > itself is only called from the hwpci->scan callback.
> >
> > WARNING: vmlinux.o(.text+0x10138): Section mismatch in reference from the function iop13xx_scan_bus() to the function .devinit.text:pci_scan_root_bus()
> > The function iop13xx_scan_bus() references
> > the function __devinit pci_scan_root_bus().
> > This is often because iop13xx_scan_bus lacks a __devinit
> > annotation or the annotation of pci_scan_root_bus is wrong.
> 
> With CONFIG_HOTPLUG going away (I think the current state is that it
> is always set to "y"), __devinit will effectively become a no-op, so I
> expect we'll remove it from pci_scan_root_bus().
> 
> Therefore, I would skip this patch and live with the warning a little longer.

Hmm, I'm just trying to get rid of all build time warnings in the defconfigs
right now, and modpost still complains about the section mismatches. I have
a bunch more of these patches, but it would also be fine with me if we can
patch mostpost to ignore these cases.

I've also redone the analysis that Greg cited in the commit message for
45f035ab9b8 "CONFIG_HOTPLUG should be always on"

   It is quite hard to disable it these days, and even if you do, it
    only saves you about 200 bytes.  However, if it is disabled, lots of
    bugs show up because it is almost never tested if the option is disabled.

My test case (ARM omap2plus_defconfig, one of the most common configurations)
shows these size -A differences:



section		nohotplug	hotplug		difference
.head.text	392		392		0
.text		4829940		4881140		51200
.rodata		1630360		1633056		2696
__ksymtab	25720		25720		0
__ksymtab_gpl	17096		17136		40
__kcrctab	12860		12860		0
__kcrctab_gpl	8548		8568		20
__ksymtab_stri	96427		96509		82
__init_rodata	0		9800		9800
__param		2320		2320		0
__modver	716		364		-352
.ARM.unwind_idx	160360		160792		432
.ARM.unwind_tab	24312		24312		0
.init.text	234632		195688		-38944
.exit.text	8680		5116		-3564
.init.proc.info	312		312		0
.init.arch.info	2964		2964		0
.init.tagtable	72		72		0
.init.smpalt	776		776		0
.init.pv_table	880		880		0
.init.data	123356		111348		-12008
.exit.data	0		0		0
.data..percpu	12928		12928		0
.data		560160		562688		2528
.notes		36		36		0
.bss		5605324		5605580		256

total		13359171	13371357	12186
after boot	13001183	13054521	53338

That is over 50kb difference after discarding the init sections,
significantly more than the 200 bytes that Greg found.
The point about lack of testing is still valid of course, and I'm
not saying we need to keep the option around, but it's really
not as obvious as before. An argument in favor of removing the
__devinit logic is that these 50kb is still just 0.4% of the
kernel size.

For the five ARM defconfig files that actually turn off hotplug,
the absolute numbers are a bit lower, but the percentage is similar.

This is the amount of space wasted by enabling on CONFIG_HOTPLUG
on them, in bytes after discarding the init sections, and as a
percentage of the vmlinux size:

at91x40_defconfig	3448	0.27%
edb7211_defconfig	8912	0.41%
footbridge_defconfig	33347	0.97%
fortunet_defconfig	4592	0.25%
pleb_defconfig		7405	0.28%

Footbridge is the only config among these that enables PCI and USB, so
it has a bunch more drivers that actually have notable functions that 
can be discarded.

	Arnd

Re: [PATCH 08/17] ARM: at91: unused variable in at91_pm_verify_clocks

[Jean-Christophe PLAGNIOL-VILLARD]

On 08:28 Thu 04 Oct     , Arnd Bergmann wrote:
> On Tuesday 02 October 2012, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > >  	unsigned long scsr;
> > > +#ifdef CONFIG_AT91_PROGRAMMABLE_CLOCKS
> > >  	int i;
> > > +#endif
> > please is if (IS_ENBLED())
> > 
> > #ifdef drop code coverage
> > 
> 
> Ok, agreed. Here is the new version:
> 
> From bacd47abb36104665261c84f6f85bba7aef8a521 Mon Sep 17 00:00:00 2001
> From: Arnd Bergmann <arnd@arndb.de>
> Date: Mon, 30 Apr 2012 13:00:32 +0000
> Subject: [PATCH] ARM: at91: unused variable in at91_pm_verify_clocks
> 
> The code using the variable 'i' in this function is conditional which
> results in a harmless compiler warning. Using the IS_ENABLED macro
> instead of #ifdef makes the code look nicer and gets rid of the
> warning.
> 
> Without this patch, building at91sam9263_defconfig results in:
> 
> /home/arnd/linux-arm/arch/arm/mach-at91/pm.c: In function 'at91_pm_verify_clocks':
> /home/arnd/linux-arm/arch/arm/mach-at91/pm.c:137:6: warning: unused variable 'i' [-Wunused-variable]
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>

Best Regards,
J.

Re: [PATCH 14/17] ARM: davinci: don't mark da850_register_cpufreq as __init

[Sekhar Nori]

On 10/2/2012 10:06 PM, Arnd Bergmann wrote:
> The mityomapl138_cpufreq_init and read_factory_config function in
> board-mityomapl138.c are not __init functions and might be called
> at a later stage, so da850_register_cpufreq must not be __init either.
> 
> Without this patch, building da8xx_omapl_defconfig results in:
> 
> WARNING: arch/arm/mach-davinci/built-in.o(.text+0x2eb4): Section mismatch in reference from the function read_factory_config() to the function .init.text:da850_register_cpufreq()
> The function read_factory_config() references
> the function __init da850_register_cpufreq().
> This is often because read_factory_config lacks a __init
> annotation or the annotation of da850_register_cpufreq is wrong.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Sekhar Nori <nsekhar@ti.com>
> Cc: Kevin Hilman <khilman@ti.com>

Acked-by: Sekhar Nori <nsekhar@ti.com>

Regards,
Sekhar

Re: [PATCH 12/17] ARM: iop13xx: mark iop13xx_scan_bus as __devinit

[Greg KH]

On Thu, Oct 04, 2012 at 10:32:20AM +0000, Arnd Bergmann wrote:
> (+Greg)
> 
> On Tuesday 02 October 2012, Bjorn Helgaas wrote:
> > 
> > On Tue, Oct 2, 2012 at 10:36 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > > pci_scan_root_bus is __devinit, so iop13xx_scan_bus has to be the
> > > same in order to safely call it. This is ok because the function
> > > itself is only called from the hwpci->scan callback.
> > >
> > > WARNING: vmlinux.o(.text+0x10138): Section mismatch in reference from the function iop13xx_scan_bus() to the function .devinit.text:pci_scan_root_bus()
> > > The function iop13xx_scan_bus() references
> > > the function __devinit pci_scan_root_bus().
> > > This is often because iop13xx_scan_bus lacks a __devinit
> > > annotation or the annotation of pci_scan_root_bus is wrong.
> > 
> > With CONFIG_HOTPLUG going away (I think the current state is that it
> > is always set to "y"), __devinit will effectively become a no-op, so I
> > expect we'll remove it from pci_scan_root_bus().
> > 
> > Therefore, I would skip this patch and live with the warning a little longer.
> 
> Hmm, I'm just trying to get rid of all build time warnings in the defconfigs
> right now, and modpost still complains about the section mismatches. I have
> a bunch more of these patches, but it would also be fine with me if we can
> patch mostpost to ignore these cases.
> 
> I've also redone the analysis that Greg cited in the commit message for
> 45f035ab9b8 "CONFIG_HOTPLUG should be always on"
> 
>    It is quite hard to disable it these days, and even if you do, it
>     only saves you about 200 bytes.  However, if it is disabled, lots of
>     bugs show up because it is almost never tested if the option is disabled.
> 
> My test case (ARM omap2plus_defconfig, one of the most common configurations)
> shows these size -A differences:
> 
> 
> 
> section		nohotplug	hotplug		difference
> .head.text	392		392		0
> .text		4829940		4881140		51200
> .rodata		1630360		1633056		2696
> __ksymtab	25720		25720		0
> __ksymtab_gpl	17096		17136		40
> __kcrctab	12860		12860		0
> __kcrctab_gpl	8548		8568		20
> __ksymtab_stri	96427		96509		82
> __init_rodata	0		9800		9800
> __param		2320		2320		0
> __modver	716		364		-352
> .ARM.unwind_idx	160360		160792		432
> .ARM.unwind_tab	24312		24312		0
> .init.text	234632		195688		-38944
> .exit.text	8680		5116		-3564
> .init.proc.info	312		312		0
> .init.arch.info	2964		2964		0
> .init.tagtable	72		72		0
> .init.smpalt	776		776		0
> .init.pv_table	880		880		0
> .init.data	123356		111348		-12008
> .exit.data	0		0		0
> .data..percpu	12928		12928		0
> .data		560160		562688		2528
> .notes		36		36		0
> .bss		5605324		5605580		256
> 
> total		13359171	13371357	12186
> after boot	13001183	13054521	53338
> 
> That is over 50kb difference after discarding the init sections,
> significantly more than the 200 bytes that Greg found.
> The point about lack of testing is still valid of course, and I'm
> not saying we need to keep the option around, but it's really
> not as obvious as before. An argument in favor of removing the
> __devinit logic is that these 50kb is still just 0.4% of the
> kernel size.
> 
> For the five ARM defconfig files that actually turn off hotplug,
> the absolute numbers are a bit lower, but the percentage is similar.
> 
> This is the amount of space wasted by enabling on CONFIG_HOTPLUG
> on them, in bytes after discarding the init sections, and as a
> percentage of the vmlinux size:
> 
> at91x40_defconfig	3448	0.27%
> edb7211_defconfig	8912	0.41%
> footbridge_defconfig	33347	0.97%
> fortunet_defconfig	4592	0.25%
> pleb_defconfig		7405	0.28%
> 
> Footbridge is the only config among these that enables PCI and USB, so
> it has a bunch more drivers that actually have notable functions that 
> can be discarded.

USB drivers should not be having anything discarded if CONFIG_HOTPLUG is
disabled (it shouldn't be disabled for USB systems, unless someone isn't
going to plug a USB device into the system after it comes up, which is
one of the main confusions here.)

As for PCI, that seems like a lot of code getting thrown away, it would
be interesting to figure out why that is.

My plans are to now start unwinding the CONFIG_HOTPLUG dependancies.  If
a driver subsystem really does want to throw away sections (like PCI
will if CONFIG_PCI_HOTPLUG is not enabled), then it should be able to.
But I imagine all of the real savings will be in the bus cores, not the
individual drivers, unless they have huge module_init() functions.

Thanks for the numbers, I'll look into this more in the coming weeks.

greg k-h

Re: [PATCH 09/17] ARM: imx: select ARM_CPU_SUSPEND if necessary

[Shawn Guo]

Isn't the following the approach we agreed on?

http://thread.gmane.org/gmane.linux.ports.arm.kernel/183222/focus=1348538

Shawn

On Tue, Oct 02, 2012 at 06:36:48PM +0200, Arnd Bergmann wrote:
> As tests using 'make randconfig' showed, imx5 requires the same logic
> as imx6 to select ARM_CPU_SUSPEND when building with power management
> enabled.
> 
> The defconfig does not have this problem because it enables imx6
> as well, but disabling it leads to this warning:
> 
> arch/arm/mach-imx/built-in.o: In function `v7_cpu_resume':
> arch/arm/mach-imx/head-v7.S:104: undefined reference to `cpu_resume'
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> ---
>  arch/arm/mach-imx/Kconfig |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index afd542a..8e96573 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -89,6 +89,7 @@ config SOC_IMX5
>  	select ARCH_MXC_IOMUX_V3
>  	select ARCH_HAS_CPUFREQ
>  	select ARCH_MX5
> +	select ARM_CPU_SUSPEND if PM
>  	bool
>  
>  config SOC_IMX50
> -- 
> 1.7.10
> 

Re: [PATCH 09/17] ARM: imx: select ARM_CPU_SUSPEND if necessary

[Arnd Bergmann]

On Sunday 07 October 2012, Shawn Guo wrote:
> Isn't the following the approach we agreed on?
> 
> http://thread.gmane.org/gmane.linux.ports.arm.kernel/183222/focus=1348538
> 

Yes, you are right, my mistake. That patch was already merged, I just
accidentally picked up the older one again when going through my backlog
and forgot to check that it still applies.

Dropping it from late/fixes now.

	Arnd

Re: [PATCH 05/17] ARM: pxa: remove sharpsl_fatal_check function

[Eric Miao]

On Wed, Oct 3, 2012 at 12:36 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> The sharpsl_fatal_check has not been used since Pavel Machek removed
> the caller in 99f329a2b "pxa/sharpsl_pm: zaurus c3000 aka spitz: fix
> resume". Nobody has complained since 2009, so it's safe to assume we
> can just remove the function.
>
> Without this patch, building corgi_defconfig results in:
>
> /home/arnd/linux-arm/arch/arm/mach-pxa/sharpsl_pm.c:693:12: warning: 'sharpsl_fatal_check' defined but not used [-Wunused-function]
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: Stanislav Brabec <utx@penguin.cz>
> Cc: Eric Miao <eric.y.miao@gmail.com>
> Cc: Haojian Zhuang <haojian.zhuang@gmail.com>

Acked-by: Eric Miao <eric.y.miao@gmail.com>

Let's get it cleaned up firstly. One can always reference the history for a
sample implementation later if this is needed in the future.

> ---
>  arch/arm/mach-pxa/sharpsl_pm.c |   48 ----------------------------------------
>  1 file changed, 48 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/sharpsl_pm.c b/arch/arm/mach-pxa/sharpsl_pm.c
> index bdf4cb8..6c9658f 100644
> --- a/arch/arm/mach-pxa/sharpsl_pm.c
> +++ b/arch/arm/mach-pxa/sharpsl_pm.c
> @@ -55,7 +55,6 @@
>  #ifdef CONFIG_PM
>  static int sharpsl_off_charge_battery(void);
>  static int sharpsl_check_battery_voltage(void);
> -static int sharpsl_fatal_check(void);
>  #endif
>  static int sharpsl_check_battery_temp(void);
>  static int sharpsl_ac_check(void);
> @@ -686,53 +685,6 @@ static int corgi_pxa_pm_enter(suspend_state_t state)
>         return 0;
>  }
>
> -/*
> - * Check for fatal battery errors
> - * Fatal returns -1
> - */
> -static int sharpsl_fatal_check(void)
> -{
> -       int buff[5], temp, i, acin;
> -
> -       dev_dbg(sharpsl_pm.dev, "sharpsl_fatal_check entered\n");
> -
> -       /* Check AC-Adapter */
> -       acin = sharpsl_pm.machinfo->read_devdata(SHARPSL_STATUS_ACIN);
> -
> -       if (acin && (sharpsl_pm.charge_mode == CHRG_ON)) {
> -               sharpsl_pm.machinfo->charge(0);
> -               udelay(100);
> -               sharpsl_pm.machinfo->discharge(1);      /* enable discharge */
> -               mdelay(SHARPSL_WAIT_DISCHARGE_ON);
> -       }
> -
> -       if (sharpsl_pm.machinfo->discharge1)
> -               sharpsl_pm.machinfo->discharge1(1);
> -
> -       /* Check battery : check inserting battery ? */
> -       for (i = 0; i < 5; i++) {
> -               buff[i] = sharpsl_pm.machinfo->read_devdata(SHARPSL_BATT_VOLT);
> -               mdelay(SHARPSL_CHECK_BATTERY_WAIT_TIME_VOLT);
> -       }
> -
> -       if (sharpsl_pm.machinfo->discharge1)
> -               sharpsl_pm.machinfo->discharge1(0);
> -
> -       if (acin && (sharpsl_pm.charge_mode == CHRG_ON)) {
> -               udelay(100);
> -               sharpsl_pm.machinfo->charge(1);
> -               sharpsl_pm.machinfo->discharge(0);
> -       }
> -
> -       temp = get_select_val(buff);
> -       dev_dbg(sharpsl_pm.dev, "sharpsl_fatal_check: acin: %d, discharge voltage: %d, no discharge: %ld\n", acin, temp, sharpsl_pm.machinfo->read_devdata(SHARPSL_BATT_VOLT));
> -
> -       if ((acin && (temp < sharpsl_pm.machinfo->fatal_acin_volt)) ||
> -                       (!acin && (temp < sharpsl_pm.machinfo->fatal_noacin_volt)))
> -               return -1;
> -       return 0;
> -}
> -
>  static int sharpsl_off_charge_error(void)
>  {
>         dev_err(sharpsl_pm.dev, "Offline Charger: Error occurred.\n");
> --
> 1.7.10
>

Re: [PATCH 05/17] ARM: pxa: remove sharpsl_fatal_check function

[Haojian Zhuang]

On Mon, Oct 8, 2012 at 10:38 AM, Eric Miao <eric.y.miao@gmail.com> wrote:
> On Wed, Oct 3, 2012 at 12:36 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> The sharpsl_fatal_check has not been used since Pavel Machek removed
>> the caller in 99f329a2b "pxa/sharpsl_pm: zaurus c3000 aka spitz: fix
>> resume". Nobody has complained since 2009, so it's safe to assume we
>> can just remove the function.
>>
>> Without this patch, building corgi_defconfig results in:
>>
>> /home/arnd/linux-arm/arch/arm/mach-pxa/sharpsl_pm.c:693:12: warning: 'sharpsl_fatal_check' defined but not used [-Wunused-function]
>>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> Cc: Pavel Machek <pavel@ucw.cz>
>> Cc: Stanislav Brabec <utx@penguin.cz>
>> Cc: Eric Miao <eric.y.miao@gmail.com>
>> Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
>
> Acked-by: Eric Miao <eric.y.miao@gmail.com>
>
> Let's get it cleaned up firstly. One can always reference the history for a
> sample implementation later if this is needed in the future.
>
Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com>

Re: [PATCH 01/17] ARM: shmobile: fix memory size for kota2_defconfig

[Olof Johansson]

Hi,

On Thu, Oct 4, 2012 at 1:58 AM, Simon Horman <horms@verge.net.au> wrote:
> On Thu, Oct 04, 2012 at 08:34:54AM +0000, Arnd Bergmann wrote:
>> On Wednesday 03 October 2012, Simon Horman wrote:
>> > I looked through my fines and found a config that I believe
>> > worked with a derivative of 2.6.35.7.
>> >
>> > It has CONFIG_MEMORY_SIZE=0x1e800000.
>> >
>> > So what I suspect has happened is that an extra zero has crept into
>> > arch/arm/configs/kota2_defconfig and the intended value is:
>> >
>> > CONFIG_MEMORY_SIZE=0x1e000000
>> >
>> > Unfortunately I do not have access to a board to test this,
>> > nor am I aware of anyone who does.
>>
>> Ok, I'll drop this patch for now then, so we keep the warning around
>> to remind us of the problem.
>
> Thanks. I have subsequently located a Kota2 board,
> however it may be a little while before I get my hands on it.

Gentle ping. I just came across this warning again so I figured I'd check.


-Olof

Re: [PATCH 01/17] ARM: shmobile: fix memory size for kota2_defconfig

[Simon Horman]

On Fri, Nov 30, 2012 at 02:10:47PM -0800, Olof Johansson wrote:
> Hi,
> 
> On Thu, Oct 4, 2012 at 1:58 AM, Simon Horman <horms@verge.net.au> wrote:
> > On Thu, Oct 04, 2012 at 08:34:54AM +0000, Arnd Bergmann wrote:
> >> On Wednesday 03 October 2012, Simon Horman wrote:
> >> > I looked through my fines and found a config that I believe
> >> > worked with a derivative of 2.6.35.7.
> >> >
> >> > It has CONFIG_MEMORY_SIZE=0x1e800000.
> >> >
> >> > So what I suspect has happened is that an extra zero has crept into
> >> > arch/arm/configs/kota2_defconfig and the intended value is:
> >> >
> >> > CONFIG_MEMORY_SIZE=0x1e000000
> >> >
> >> > Unfortunately I do not have access to a board to test this,
> >> > nor am I aware of anyone who does.
> >>
> >> Ok, I'll drop this patch for now then, so we keep the warning around
> >> to remind us of the problem.
> >
> > Thanks. I have subsequently located a Kota2 board,
> > however it may be a little while before I get my hands on it.
> 
> Gentle ping. I just came across this warning again so I figured I'd check.

Sorry, I still don't have a kota2 board.
However, I expect to obtain one within the next week.

Re: [PATCH 01/17] ARM: shmobile: fix memory size for kota2_defconfig

[Simon Horman]

On Fri, Nov 30, 2012 at 02:10:47PM -0800, Olof Johansson wrote:
> Hi,
> 
> On Thu, Oct 4, 2012 at 1:58 AM, Simon Horman <horms@verge.net.au> wrote:
> > On Thu, Oct 04, 2012 at 08:34:54AM +0000, Arnd Bergmann wrote:
> >> On Wednesday 03 October 2012, Simon Horman wrote:
> >> > I looked through my fines and found a config that I believe
> >> > worked with a derivative of 2.6.35.7.
> >> >
> >> > It has CONFIG_MEMORY_SIZE=0x1e800000.
> >> >
> >> > So what I suspect has happened is that an extra zero has crept into
> >> > arch/arm/configs/kota2_defconfig and the intended value is:
> >> >
> >> > CONFIG_MEMORY_SIZE=0x1e000000
> >> >
> >> > Unfortunately I do not have access to a board to test this,
> >> > nor am I aware of anyone who does.
> >>
> >> Ok, I'll drop this patch for now then, so we keep the warning around
> >> to remind us of the problem.
> >
> > Thanks. I have subsequently located a Kota2 board,
> > however it may be a little while before I get my hands on it.
> 
> Gentle ping. I just came across this warning again so I figured I'd check.

Hi,

I have my kota2 board up and running now and I believe that
the correct value is 0x1e000000. I will apply a patch to my
defconfigs branch accordingly.

Re: [PATCH 01/17] ARM: shmobile: fix memory size for kota2_defconfig

[Arnd Bergmann]

On Monday 07 January 2013, Simon Horman wrote:
> I have my kota2 board up and running now and I believe that
> the correct value is 0x1e000000. I will apply a patch to my
> defconfigs branch accordingly.

Ok, thanks!

Should we mark that patch for stable backports?

	Arnd

Re: [PATCH 01/17] ARM: shmobile: fix memory size for kota2_defconfig

[Simon Horman]

On Mon, Jan 07, 2013 at 01:33:56PM +0000, Arnd Bergmann wrote:
> On Monday 07 January 2013, Simon Horman wrote:
> > I have my kota2 board up and running now and I believe that
> > the correct value is 0x1e000000. I will apply a patch to my
> > defconfigs branch accordingly.
> 
> Ok, thanks!
> 
> Should we mark that patch for stable backports?

I don't believe it warrants a stable backport as
the board appears to function well without the change.

Re: [PATCH 01/17] ARM: shmobile: fix memory size for kota2_defconfig

[Arnd Bergmann]

On Tuesday 08 January 2013, Simon Horman wrote:
> > 
> > Should we mark that patch for stable backports?
> 
> I don't believe it warrants a stable backport as
> the board appears to function well without the change.

Ok, fair enough. I was thinking of getting rid of the build warning in the older
kernel, but it's probably not worth it if there is no functional impact.

	Arnd