[PATCH 00/62] arm-soc randconfig fixes

[PATCH 00/62] arm-soc randconfig fixes

[Arnd Bergmann]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 8283 bytes --]

Hi everyone,

This is my much too long series of mostly trivial build for ARM platform
code. It's about a third of the total set of patches I have in a local
tree that I use for build testing randconfig kernels. Most of the other
patches are for device drivers, but there is also a significant chunk
for ARM architecture code, and a few things that are controversial or
not yet properly fixed.

I'd like to put all or most of these into a branch in arm-soc for
the coming merge window. Acks are very much appreciated, as as
Naks when I got something wrong. Everything I don't hear back
from I will assume is ok and put in.

Statistically speaking, I probably made a couple of mistakes here,
so please have a look if you find the time.

Arnd Bergmann (62):
  ARM: at91: split out at91x40 into a top-level option
  ARM: at91: don't provide dt init code for at91x40
  ARM: at91: export sam9_smc interfaces
  ARM: at91: fix broken "if () else" statement
  ARM: at91: sama5 always uses DT
  ARM: davinci: export da8xx_syscfg0_base
  ARM: davinci: make dm644x-evm phy fixup conditional
  ARM: davinci: use explicit 'select' for DA850_EVM
  ARM: efm32: allow uncompress debug output
  ARM: efm32: select AUTO_ZRELADDR
  ARM: ep93xx: export ep93xx_chip_revision
  ARM: hisi: fix building without CONFIG_HOTPLUG_CPU
  ARM: hisi: select HAVE_ARM_SCU only for SMP
  ARM: imx: imx6q_set_lpm is only defined for CONFIG_PM=y
  ARM: ixp4xx/omixp: always include linux/leds.h
  ARM: ixp4xx: avoid use of PCIBIOS_MIN_MEM in io.h
  ARM: ixp4xx: fix gpio rework
  ARM: ks8695/og: make PCI setup conditional
  ARM: lpc32xx: export lpc32xx_return_iram_size
  ARM: msm: add missing include of linux/module.h
  ARM: msm: avoid calling debug_ll_addr on !MMU
  ARM: msm: export legacy DMA interfaces
  ARM: omap1: fix building without 32K_TIMER
  ARM: omap1: select I2C where needed for PMIC
  ARM: mvebu: add missing header
  ARM: mvebu: don't select CONFIG_NEON
  ARM: orion5x: make dns323 independent of PHY support
  ARM: pxa: FB_W100 must be built-in
  ARM: pxa: don't "select" SMC91X on MACH_XCEP
  ARM: pxa: enable pxafb unconditionally for some boards
  ARM: pxa: fix colibri build
  ARM: pxa: fix pxa_ssp_* declarations
  ARM: pxa: remove broken balloon3_gpio_vbus reference
  ARM: pxa: select I2C_GPIO only if I2C is on
  ARM: pxa: trizeps4 and trizeps4wl use the same file
  ARM: rpc: autoselect CPU_SA110
  ARM: sa1100/pxa: fix MTD_XIP build
  ARM: footbridge: don't build floppy code for addin mode
  ARM: footbridge: fix build with PCI disabled
  ARM: footbridge: make screen_info setup conditional
  ARM: realview: fix sparsemem build
  ARM: realview: use explicit core tile config options
  ARM: integrator: only select pl01x if TTY is enabled
  ARM: integrator: refine CPU selection
  ARM: s3c24xx: MINI2440 needs I2C for EEPROM_AT24
  ARM: s3c24xx: fix gta02 build error
  ARM: s3c64xx: MACH_SMDK6400 needs HSMMC1
  ARM: s3c64xx: select power domains only when used
  ARM: s5p64x0: fix building with only one soc type
  ARM: s5pv210: enable IDE support in MACH_TORBRECK
  ARM: samsung: allow serial driver to be disabled
  ARM: samsung: disable decompressor watchdog on exynos
  ARM: samsung: fix SAMSUNG_PM_DEBUG Kconfig logic
  ARM: samsung: select ATAGS where necessary
  ARM: samsung: select CRC32 for SAMSUNG_PM_CHECK
  ARM: samsung: select I2C where needed for PMIC
  ARM: exynos: fix l2x0 saved regs handling
  ARM: exynos: add missing include of linux/module.h
  ARM: shmobile: ak4642 needs i2c support
  ARM: shmobile: work around CONFIG_PHYLIB=m
  ARM: sunxi: fix build for THUMB2_KERNEL
  ARM: tegra: make debug_ll code build for ARMv6

 arch/arm/Kconfig                             |  9 ++++-
 arch/arm/Kconfig.debug                       |  2 +-
 arch/arm/include/debug/tegra.S               | 18 ++++-----
 arch/arm/mach-at91/Kconfig                   | 23 +++++++++--
 arch/arm/mach-at91/Kconfig.non_dt            |  8 +---
 arch/arm/mach-at91/at91sam9260_devices.c     |  4 +-
 arch/arm/mach-at91/sam9_smc.c                |  3 ++
 arch/arm/mach-at91/setup.c                   |  2 +-
 arch/arm/mach-davinci/Kconfig                |  7 +---
 arch/arm/mach-davinci/board-dm644x-evm.c     | 11 +++---
 arch/arm/mach-davinci/devices-da8xx.c        |  1 +
 arch/arm/mach-ep93xx/core.c                  |  1 +
 arch/arm/mach-exynos/common.c                |  6 ++-
 arch/arm/mach-exynos/cpuidle.c               |  1 +
 arch/arm/mach-footbridge/Kconfig             |  2 +-
 arch/arm/mach-footbridge/Makefile            |  3 +-
 arch/arm/mach-footbridge/cats-hw.c           |  2 +
 arch/arm/mach-hisi/Kconfig                   |  2 +-
 arch/arm/mach-hisi/Makefile                  |  3 +-
 arch/arm/mach-hisi/hotplug.c                 |  2 +
 arch/arm/mach-imx/clk-imx6q.c                |  3 +-
 arch/arm/mach-imx/clk-imx6sl.c               |  3 +-
 arch/arm/mach-imx/cpuidle-imx6sl.c           |  3 ++
 arch/arm/mach-integrator/Kconfig             | 19 ++++++++--
 arch/arm/mach-ixp4xx/common.c                |  6 +--
 arch/arm/mach-ixp4xx/goramo_mlr.c            |  7 ++++
 arch/arm/mach-ixp4xx/include/mach/io.h       |  3 +-
 arch/arm/mach-ixp4xx/omixp-setup.c           |  2 -
 arch/arm/mach-ks8695/board-og.c              |  3 +-
 arch/arm/mach-lpc32xx/common.c               |  1 +
 arch/arm/mach-msm/dma.c                      |  3 ++
 arch/arm/mach-msm/io.c                       |  2 +
 arch/arm/mach-mvebu/Kconfig                  |  2 -
 arch/arm/mach-mvebu/board-v7.c               |  1 +
 arch/arm/mach-omap1/Kconfig                  |  4 ++
 arch/arm/mach-omap1/pm.c                     |  8 ++--
 arch/arm/mach-orion5x/Kconfig                |  1 -
 arch/arm/mach-orion5x/dns323-setup.c         |  2 +
 arch/arm/mach-pxa/Kconfig                    | 10 +++--
 arch/arm/mach-pxa/balloon3.c                 |  1 -
 arch/arm/mach-pxa/colibri-evalboard.c        |  1 +
 arch/arm/mach-pxa/include/mach/mtd-xip.h     |  7 ++--
 arch/arm/mach-pxa/irq.c                      |  8 ++++
 arch/arm/mach-realview/Kconfig               | 57 ++++++++++++++++++++++++++++
 arch/arm/mach-realview/include/mach/memory.h |  2 +
 arch/arm/mach-s3c24xx/Kconfig                |  3 +-
 arch/arm/mach-s3c24xx/mach-gta02.c           |  2 +-
 arch/arm/mach-s3c64xx/Kconfig                |  3 ++
 arch/arm/mach-s3c64xx/irq-pm.c               | 12 ++++--
 arch/arm/mach-s5p64x0/common.c               | 18 ++++++++-
 arch/arm/mach-s5p64x0/common.h               |  5 +--
 arch/arm/mach-s5p64x0/irq-pm.c               |  6 +++
 arch/arm/mach-s5pv210/Kconfig                |  1 +
 arch/arm/mach-sa1100/include/mach/mtd-xip.h  |  4 +-
 arch/arm/mach-shmobile/Kconfig               | 12 +++---
 arch/arm/mach-shmobile/board-koelsch.c       |  2 +-
 arch/arm/mach-shmobile/board-lager.c         |  2 +-
 arch/arm/mach-sunxi/headsmp.S                |  3 +-
 arch/arm/mm/Kconfig                          | 30 +++++++--------
 arch/arm/plat-samsung/Kconfig                |  7 ++--
 arch/arm/plat-samsung/init.c                 |  4 ++
 drivers/video/Kconfig                        |  4 +-
 include/linux/pxa2xx_ssp.h                   |  2 +-
 63 files changed, 276 insertions(+), 113 deletions(-)

-- 
1.8.3.2

Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Uwe Kleine-König <kernel@pengutronix.de>
Cc: Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Shawn Guo <shawn.guo@freescale.com>
Cc: Krzysztof Halasa <khc@pm.waw.pl>
Cc: David Brown <davidb@codeaurora.org>
Cc: linux-omap@vger.kernel.org
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Simon Horman <horms@verge.net.au>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 00/62] arm-soc randconfig fixes

[Arnd Bergmann]

Hi everyone,

This is my much too long series of mostly trivial build for ARM platform
code. It's about a third of the total set of patches I have in a local
tree that I use for build testing randconfig kernels. Most of the other
patches are for device drivers, but there is also a significant chunk
for ARM architecture code, and a few things that are controversial or
not yet properly fixed.

I'd like to put all or most of these into a branch in arm-soc for
the coming merge window. Acks are very much appreciated, as as
Naks when I got something wrong. Everything I don't hear back
from I will assume is ok and put in.

Statistically speaking, I probably made a couple of mistakes here,
so please have a look if you find the time.

Arnd Bergmann (62):
  ARM: at91: split out at91x40 into a top-level option
  ARM: at91: don't provide dt init code for at91x40
  ARM: at91: export sam9_smc interfaces
  ARM: at91: fix broken "if () else" statement
  ARM: at91: sama5 always uses DT
  ARM: davinci: export da8xx_syscfg0_base
  ARM: davinci: make dm644x-evm phy fixup conditional
  ARM: davinci: use explicit 'select' for DA850_EVM
  ARM: efm32: allow uncompress debug output
  ARM: efm32: select AUTO_ZRELADDR
  ARM: ep93xx: export ep93xx_chip_revision
  ARM: hisi: fix building without CONFIG_HOTPLUG_CPU
  ARM: hisi: select HAVE_ARM_SCU only for SMP
  ARM: imx: imx6q_set_lpm is only defined for CONFIG_PM=y
  ARM: ixp4xx/omixp: always include linux/leds.h
  ARM: ixp4xx: avoid use of PCIBIOS_MIN_MEM in io.h
  ARM: ixp4xx: fix gpio rework
  ARM: ks8695/og: make PCI setup conditional
  ARM: lpc32xx: export lpc32xx_return_iram_size
  ARM: msm: add missing include of linux/module.h
  ARM: msm: avoid calling debug_ll_addr on !MMU
  ARM: msm: export legacy DMA interfaces
  ARM: omap1: fix building without 32K_TIMER
  ARM: omap1: select I2C where needed for PMIC
  ARM: mvebu: add missing header
  ARM: mvebu: don't select CONFIG_NEON
  ARM: orion5x: make dns323 independent of PHY support
  ARM: pxa: FB_W100 must be built-in
  ARM: pxa: don't "select" SMC91X on MACH_XCEP
  ARM: pxa: enable pxafb unconditionally for some boards
  ARM: pxa: fix colibri build
  ARM: pxa: fix pxa_ssp_* declarations
  ARM: pxa: remove broken balloon3_gpio_vbus reference
  ARM: pxa: select I2C_GPIO only if I2C is on
  ARM: pxa: trizeps4 and trizeps4wl use the same file
  ARM: rpc: autoselect CPU_SA110
  ARM: sa1100/pxa: fix MTD_XIP build
  ARM: footbridge: don't build floppy code for addin mode
  ARM: footbridge: fix build with PCI disabled
  ARM: footbridge: make screen_info setup conditional
  ARM: realview: fix sparsemem build
  ARM: realview: use explicit core tile config options
  ARM: integrator: only select pl01x if TTY is enabled
  ARM: integrator: refine CPU selection
  ARM: s3c24xx: MINI2440 needs I2C for EEPROM_AT24
  ARM: s3c24xx: fix gta02 build error
  ARM: s3c64xx: MACH_SMDK6400 needs HSMMC1
  ARM: s3c64xx: select power domains only when used
  ARM: s5p64x0: fix building with only one soc type
  ARM: s5pv210: enable IDE support in MACH_TORBRECK
  ARM: samsung: allow serial driver to be disabled
  ARM: samsung: disable decompressor watchdog on exynos
  ARM: samsung: fix SAMSUNG_PM_DEBUG Kconfig logic
  ARM: samsung: select ATAGS where necessary
  ARM: samsung: select CRC32 for SAMSUNG_PM_CHECK
  ARM: samsung: select I2C where needed for PMIC
  ARM: exynos: fix l2x0 saved regs handling
  ARM: exynos: add missing include of linux/module.h
  ARM: shmobile: ak4642 needs i2c support
  ARM: shmobile: work around CONFIG_PHYLIB=m
  ARM: sunxi: fix build for THUMB2_KERNEL
  ARM: tegra: make debug_ll code build for ARMv6

 arch/arm/Kconfig                             |  9 ++++-
 arch/arm/Kconfig.debug                       |  2 +-
 arch/arm/include/debug/tegra.S               | 18 ++++-----
 arch/arm/mach-at91/Kconfig                   | 23 +++++++++--
 arch/arm/mach-at91/Kconfig.non_dt            |  8 +---
 arch/arm/mach-at91/at91sam9260_devices.c     |  4 +-
 arch/arm/mach-at91/sam9_smc.c                |  3 ++
 arch/arm/mach-at91/setup.c                   |  2 +-
 arch/arm/mach-davinci/Kconfig                |  7 +---
 arch/arm/mach-davinci/board-dm644x-evm.c     | 11 +++---
 arch/arm/mach-davinci/devices-da8xx.c        |  1 +
 arch/arm/mach-ep93xx/core.c                  |  1 +
 arch/arm/mach-exynos/common.c                |  6 ++-
 arch/arm/mach-exynos/cpuidle.c               |  1 +
 arch/arm/mach-footbridge/Kconfig             |  2 +-
 arch/arm/mach-footbridge/Makefile            |  3 +-
 arch/arm/mach-footbridge/cats-hw.c           |  2 +
 arch/arm/mach-hisi/Kconfig                   |  2 +-
 arch/arm/mach-hisi/Makefile                  |  3 +-
 arch/arm/mach-hisi/hotplug.c                 |  2 +
 arch/arm/mach-imx/clk-imx6q.c                |  3 +-
 arch/arm/mach-imx/clk-imx6sl.c               |  3 +-
 arch/arm/mach-imx/cpuidle-imx6sl.c           |  3 ++
 arch/arm/mach-integrator/Kconfig             | 19 ++++++++--
 arch/arm/mach-ixp4xx/common.c                |  6 +--
 arch/arm/mach-ixp4xx/goramo_mlr.c            |  7 ++++
 arch/arm/mach-ixp4xx/include/mach/io.h       |  3 +-
 arch/arm/mach-ixp4xx/omixp-setup.c           |  2 -
 arch/arm/mach-ks8695/board-og.c              |  3 +-
 arch/arm/mach-lpc32xx/common.c               |  1 +
 arch/arm/mach-msm/dma.c                      |  3 ++
 arch/arm/mach-msm/io.c                       |  2 +
 arch/arm/mach-mvebu/Kconfig                  |  2 -
 arch/arm/mach-mvebu/board-v7.c               |  1 +
 arch/arm/mach-omap1/Kconfig                  |  4 ++
 arch/arm/mach-omap1/pm.c                     |  8 ++--
 arch/arm/mach-orion5x/Kconfig                |  1 -
 arch/arm/mach-orion5x/dns323-setup.c         |  2 +
 arch/arm/mach-pxa/Kconfig                    | 10 +++--
 arch/arm/mach-pxa/balloon3.c                 |  1 -
 arch/arm/mach-pxa/colibri-evalboard.c        |  1 +
 arch/arm/mach-pxa/include/mach/mtd-xip.h     |  7 ++--
 arch/arm/mach-pxa/irq.c                      |  8 ++++
 arch/arm/mach-realview/Kconfig               | 57 ++++++++++++++++++++++++++++
 arch/arm/mach-realview/include/mach/memory.h |  2 +
 arch/arm/mach-s3c24xx/Kconfig                |  3 +-
 arch/arm/mach-s3c24xx/mach-gta02.c           |  2 +-
 arch/arm/mach-s3c64xx/Kconfig                |  3 ++
 arch/arm/mach-s3c64xx/irq-pm.c               | 12 ++++--
 arch/arm/mach-s5p64x0/common.c               | 18 ++++++++-
 arch/arm/mach-s5p64x0/common.h               |  5 +--
 arch/arm/mach-s5p64x0/irq-pm.c               |  6 +++
 arch/arm/mach-s5pv210/Kconfig                |  1 +
 arch/arm/mach-sa1100/include/mach/mtd-xip.h  |  4 +-
 arch/arm/mach-shmobile/Kconfig               | 12 +++---
 arch/arm/mach-shmobile/board-koelsch.c       |  2 +-
 arch/arm/mach-shmobile/board-lager.c         |  2 +-
 arch/arm/mach-sunxi/headsmp.S                |  3 +-
 arch/arm/mm/Kconfig                          | 30 +++++++--------
 arch/arm/plat-samsung/Kconfig                |  7 ++--
 arch/arm/plat-samsung/init.c                 |  4 ++
 drivers/video/Kconfig                        |  4 +-
 include/linux/pxa2xx_ssp.h                   |  2 +-
 63 files changed, 276 insertions(+), 113 deletions(-)

-- 
1.8.3.2

Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Uwe Kleine-K?nig <kernel@pengutronix.de>
Cc: Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Shawn Guo <shawn.guo@freescale.com>
Cc: Krzysztof Halasa <khc@pm.waw.pl>
Cc: David Brown <davidb@codeaurora.org>
Cc: linux-omap at vger.kernel.org
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Simon Horman <horms@verge.net.au>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>

[PATCH 01/62] ARM: at91: split out at91x40 into a top-level option

[Arnd Bergmann]

at91x40 is different from all the other at91 machines, and it is
impossible to build a kernel that works on both this SoC and
any of the others, even though it is possible to build a noMMU
kernel for any at91 machine.

By turning at91x40 into a separate top-level option, we explicitly
forbid enabling invalid configurations that include mutually exclusive
machines.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Andrew Victor <linux@maxim.org.za>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
---
 arch/arm/mach-at91/Kconfig        | 22 ++++++++++++++++++----
 arch/arm/mach-at91/Kconfig.non_dt |  8 +-------
 2 files changed, 19 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index ae6617e..7209c5b 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -64,11 +64,22 @@ choice
 
 	prompt "Core type"
 
+config ARCH_AT91X40
+	bool "ARM7/ARM9 AT91X40"
+	depends on !MMU
+	select CPU_ARM7TDMI
+	select ARCH_USES_GETTIMEOFFSET
+	select MULTI_IRQ_HANDLER
+	select SPARSE_IRQ
+
+	help
+	  Select this if you are using one of Atmel's AT91X40 SoC.
+
 config SOC_SAM_V4_V5
-	bool "ARM7/ARM9"
+	bool "ARM7/ARM9 AT91SAM9/AT91RM9200"
 	help
-	  Select this if you are using one of Atmel's AT91SAM9, AT91RM9200
-	  or AT91X40 SoC.
+	  Select this if you are using one of Atmel's AT91SAM9 or
+	  AT91RM9200 SoC.
 
 config SOC_SAM_V7
 	bool "Cortex A5"
@@ -177,9 +188,12 @@ config SOC_AT91SAM9N12
 	  Select this if you are using Atmel's AT91SAM9N12 SoC.
 
 # ----------------------------------------------------------
+endif # SOC_SAM_V4_V5
+
 
+if SOC_SAM_V4_V5 || ARCH_AT91X40
 source arch/arm/mach-at91/Kconfig.non_dt
-endif # SOC_SAM_V4_V5
+endif
 
 comment "Generic Board Type"
 
diff --git a/arch/arm/mach-at91/Kconfig.non_dt b/arch/arm/mach-at91/Kconfig.non_dt
index 1f73e9b..44ace32 100644
--- a/arch/arm/mach-at91/Kconfig.non_dt
+++ b/arch/arm/mach-at91/Kconfig.non_dt
@@ -5,6 +5,7 @@ config HAVE_AT91_DATAFLASH_CARD
 
 choice
 	prompt "Atmel AT91 Processor Devices for non DT boards"
+	depends on !ARCH_AT91X40
 
 config ARCH_AT91_NONE
 	bool "None"
@@ -39,13 +40,6 @@ config ARCH_AT91SAM9G45
 	select SOC_AT91SAM9G45
 	select AT91_USE_OLD_CLK
 
-config ARCH_AT91X40
-	bool "AT91x40"
-	depends on !MMU
-	select ARCH_USES_GETTIMEOFFSET
-	select MULTI_IRQ_HANDLER
-	select SPARSE_IRQ
-
 endchoice
 
 config ARCH_AT91SAM9G20
-- 
1.8.3.2

[PATCH 02/62] ARM: at91: don't provide dt init code for at91x40

[Arnd Bergmann]

at91x40 has no support for device tree, but Kconfig allows
us to enable CONFIG_OF anyway, causing a link error in the
at91 reset controller initialization.

The easiest fix is to adapt the existing #ifdef to omit
the broken code on at91x40 where it is never called anyway.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Andrew Victor <linux@maxim.org.za>
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, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-at91/setup.c b/arch/arm/mach-at91/setup.c
index f7ca97b..f7a07a5 100644
--- a/arch/arm/mach-at91/setup.c
+++ b/arch/arm/mach-at91/setup.c
@@ -351,7 +351,7 @@ void __init at91_ioremap_matrix(u32 base_addr)
 		panic("Impossible to ioremap at91_matrix_base\n");
 }
 
-#if defined(CONFIG_OF)
+#if defined(CONFIG_OF) && !defined(CONFIG_ARCH_AT91X40)
 static struct of_device_id rstc_ids[] = {
 	{ .compatible = "atmel,at91sam9260-rstc", .data = at91sam9_alt_restart },
 	{ .compatible = "atmel,at91sam9g45-rstc", .data = at91sam9g45_restart },
-- 
1.8.3.2

[PATCH 03/62] ARM: at91: export sam9_smc interfaces

[Arnd Bergmann]

The pata_at91 driver uses interfaces defined in the sam9_smc
platform code. Since the pata driver can be a loadable module,
we have to export those symbols in order to link cleanly.

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

diff --git a/arch/arm/mach-at91/sam9_smc.c b/arch/arm/mach-at91/sam9_smc.c
index b26156b..826315a 100644
--- a/arch/arm/mach-at91/sam9_smc.c
+++ b/arch/arm/mach-at91/sam9_smc.c
@@ -36,6 +36,7 @@ void sam9_smc_write_mode(int id, int cs,
 {
 	sam9_smc_cs_write_mode(AT91_SMC_CS(id, cs), config);
 }
+EXPORT_SYMBOL_GPL(sam9_smc_write_mode);
 
 static void sam9_smc_cs_configure(void __iomem *base,
 					struct sam9_smc_config *config)
@@ -69,6 +70,7 @@ void sam9_smc_configure(int id, int cs,
 {
 	sam9_smc_cs_configure(AT91_SMC_CS(id, cs), config);
 }
+EXPORT_SYMBOL_GPL(sam9_smc_configure);
 
 static void sam9_smc_cs_read_mode(void __iomem *base,
 					struct sam9_smc_config *config)
@@ -84,6 +86,7 @@ void sam9_smc_read_mode(int id, int cs,
 {
 	sam9_smc_cs_read_mode(AT91_SMC_CS(id, cs), config);
 }
+EXPORT_SYMBOL_GPL(sam9_smc_read_mode);
 
 static void sam9_smc_cs_read(void __iomem *base,
 					struct sam9_smc_config *config)
-- 
1.8.3.2

[PATCH 04/62] ARM: at91: fix broken "if () else" statement

[Arnd Bergmann]

If CONFIG_PATA_AT91 is disabled, the code in at91_add_device_cf
is turned into invalid C statements due to the lack of an
expression before the 'else' clause.

This moves the first half of the condition inside of the #ifdef,
which seems to be what the author intended.

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

diff --git a/arch/arm/mach-at91/at91sam9260_devices.c b/arch/arm/mach-at91/at91sam9260_devices.c
index 2ae7715..4222a7d 100644
--- a/arch/arm/mach-at91/at91sam9260_devices.c
+++ b/arch/arm/mach-at91/at91sam9260_devices.c
@@ -1263,13 +1263,13 @@ void __init at91_add_device_cf(struct at91_cf_data *data)
 	at91_set_A_periph(AT91_PIN_PC10, 0);    /* CFRNW */
 	at91_set_A_periph(AT91_PIN_PC15, 1);    /* NWAIT */
 
-	if (data->flags & AT91_CF_TRUE_IDE)
 #if defined(CONFIG_PATA_AT91) || defined(CONFIG_PATA_AT91_MODULE)
+	if (data->flags & AT91_CF_TRUE_IDE)
 		pdev->name = "pata_at91";
+	else
 #else
 #warning "board requires AT91_CF_TRUE_IDE: enable pata_at91"
 #endif
-	else
 		pdev->name = "at91_cf";
 
 	platform_device_register(pdev);
-- 
1.8.3.2

[PATCH 05/62] ARM: at91: sama5 always uses DT

[Arnd Bergmann]

It makes no sense for sama5 support to be enabled if we don't
also enable USE_OF. Making this automatic in Kconfig avoids
a possible randconfig conflict between the old and new clock
support code.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Andrew Victor <linux@maxim.org.za>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
---
 arch/arm/mach-at91/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index 7209c5b..5ec1da1 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -57,6 +57,7 @@ config SOC_SAMA5
 	select GENERIC_CLOCKEVENTS
 	select MULTI_IRQ_HANDLER
 	select SPARSE_IRQ
+	select USE_OF
 
 menu "Atmel AT91 System-on-Chip"
 
-- 
1.8.3.2

[PATCH 06/62] ARM: davinci: export da8xx_syscfg0_base

[Arnd Bergmann]

The ohci-da8xx driver uses the DA8XX_SYSCFG0_VIRT macro to
access the CFGCHIP2 register for controlling its PHY.

The macro in turn relies on the da8xx_syscfg0_base global
variable. Since the OHCI driver can be a loadable module,
this requires the symbol to be exported from platform code.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: davinci-linux-open-source at linux.davincidsp.com
---
 arch/arm/mach-davinci/devices-da8xx.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
index 0486cdf..4da868a 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -66,6 +66,7 @@
 #define DA850_DMA_MMCSD1_TX	EDMA_CTLR_CHAN(1, 29)
 
 void __iomem *da8xx_syscfg0_base;
+EXPORT_SYMBOL_GPL(da8xx_syscfg0_base); /* used by OHCI_HCD */
 void __iomem *da8xx_syscfg1_base;
 
 static struct plat_serial8250_port da8xx_serial0_pdata[] = {
-- 
1.8.3.2

[PATCH 07/62] ARM: davinci: make dm644x-evm phy fixup conditional

[Arnd Bergmann]

We cannot call phy_register_fixup_for_uid() if CONFIG_PHYLIB
is not built into the kernel, and we should not enforce that
to be built into vmlinux either, because one might want to
disable the entire network stack.

This change uses a compile-time condition on CONFIG_PHYLIB
to remove the call in the cases where it cannot work.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: davinci-linux-open-source at linux.davincidsp.com
---
 arch/arm/mach-davinci/board-dm644x-evm.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c
index 5602957..e583e58 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -804,11 +804,12 @@ static __init void davinci_evm_init(void)
 	/* irlml6401 switches over 1A, in under 8 msec */
 	davinci_setup_usb(1000, 8);
 
-	soc_info->emac_pdata->phy_id = DM644X_EVM_PHY_ID;
-	/* Register the fixup for PHY on DaVinci */
-	phy_register_fixup_for_uid(LXT971_PHY_ID, LXT971_PHY_MASK,
-					davinci_phy_fixup);
-
+	if (IS_BUILTIN(CONFIG_PHYLIB)) {
+		soc_info->emac_pdata->phy_id = DM644X_EVM_PHY_ID;
+		/* Register the fixup for PHY on DaVinci */
+		phy_register_fixup_for_uid(LXT971_PHY_ID, LXT971_PHY_MASK,
+						davinci_phy_fixup);
+	}
 }
 
 MACHINE_START(DAVINCI_EVM, "DaVinci DM644x EVM")
-- 
1.8.3.2

[PATCH 08/62] ARM: davinci: use explicit 'select' for DA850_EVM

[Arnd Bergmann]

The DAVINCI_DA850_EVM board uses an unusual method to
enable the GPIO_PCA953X and KEYBOARD_GPIO_POLLED symbols,
which leads to the dependencies on these symbols being
ignored. As GPIO_PCA953X actually requires I2C, that
can lead to build failures when I2C is disabled.

This patch removes the duplicate symbol definitions
and instead adds equivalent 'select' statements that
are conditional on the underlying dependencies.

A different question whether we actually want to automatically
enable them at all or rather put them into defconfig,
but that should be a separate patch.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: davinci-linux-open-source at linux.davincidsp.com
---
 arch/arm/mach-davinci/Kconfig | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
index 3b98e34..df794e9 100644
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig
@@ -163,6 +163,8 @@ config MACH_DAVINCI_DA850_EVM
 	bool "TI DA850/OMAP-L138/AM18x Reference Platform"
 	default ARCH_DAVINCI_DA850
 	depends on ARCH_DAVINCI_DA850
+	select GPIO_PCA953X if I2C
+	select KEYBOARD_GPIO_POLLED if GPIOLIB
 	help
 	  Say Y here to select the TI DA850/OMAP-L138/AM18x Evaluation Module.
 
@@ -209,11 +211,6 @@ config DA850_WL12XX
 	  Say Y if you want to use a wl1271 expansion card connected to the
 	  AM18x EVM.
 
-config GPIO_PCA953X
-	default MACH_DAVINCI_DA850_EVM
-
-config KEYBOARD_GPIO_POLLED
-	default MACH_DAVINCI_DA850_EVM
 
 config MACH_MITYOMAPL138
 	bool "Critical Link MityDSP-L138/MityARM-1808 SoM"
-- 
1.8.3.2

[PATCH 09/62] ARM: efm32: allow uncompress debug output

[Arnd Bergmann]

efm32 has no mach/uncompress.h, but we can trivially use
the fallback to the ll_debug code by just allowing this
option in Kconfig.

Found during randconfig testing.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Uwe Kleine-K?nig <kernel@pengutronix.de>
---
 arch/arm/Kconfig.debug | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index dbb6f15..8983919 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -1158,7 +1158,7 @@ config DEBUG_UNCOMPRESS
 config UNCOMPRESS_INCLUDE
 	string
 	default "debug/uncompress.h" if ARCH_MULTIPLATFORM || ARCH_MSM || \
-					ARCH_EXYNOS
+					ARCH_EXYNOS || ARCH_EFM32
 	default "mach/uncompress.h"
 
 config EARLY_PRINTK
-- 
1.8.3.2

[PATCH 10/62] ARM: efm32: select AUTO_ZRELADDR

[Arnd Bergmann]

The efm32 platform does not provide a zreladdr-y line its Makefile.boot,
so we always have to use CONFIG_AUTO_ZRELADDR in order to successfully
build and link a zImage.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Uwe Kleine-K?nig <kernel@pengutronix.de>
---
 arch/arm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 62ede9b..5776c12 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -422,6 +422,7 @@ config ARCH_EFM32
 	bool "Energy Micro efm32"
 	depends on !MMU
 	select ARCH_REQUIRE_GPIOLIB
+	select AUTO_ZRELADDR
 	select ARM_NVIC
 	select CLKSRC_OF
 	select COMMON_CLK
-- 
1.8.3.2

[PATCH 11/62] ARM: ep93xx: export ep93xx_chip_revision

[Arnd Bergmann]

ep93xx_chip_revision is used by the pata_ep93xx driver,
which can be a loadable module. Exporting the symbol
avoids a link error in this case.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Ryan Mallon <rmallon@gmail.com>
---
 arch/arm/mach-ep93xx/core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-ep93xx/core.c b/arch/arm/mach-ep93xx/core.c
index 6c70547..0e571f1 100644
--- a/arch/arm/mach-ep93xx/core.c
+++ b/arch/arm/mach-ep93xx/core.c
@@ -242,6 +242,7 @@ unsigned int ep93xx_chip_revision(void)
 	v >>= EP93XX_SYSCON_SYSCFG_REV_SHIFT;
 	return v;
 }
+EXPORT_SYMBOL_GPL(ep93xx_chip_revision);
 
 /*************************************************************************
  * EP93xx GPIO
-- 
1.8.3.2

[PATCH 12/62] ARM: hisi: fix building without CONFIG_HOTPLUG_CPU

[Arnd Bergmann]

The hisi SMP code always uses the hi3xxx_set_cpu() function
defined in the hotplug.c file, so we cannot build without
this when CONFIG_SMP is enabled. This patch slightly restructures
the code so we always build the parts of hotplug.c that we need
but just leave out the CPU disable logic if CONFIG_HOTPLUG_CPU
is turned off.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
---
 arch/arm/mach-hisi/Makefile  | 3 +--
 arch/arm/mach-hisi/hotplug.c | 2 ++
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-hisi/Makefile b/arch/arm/mach-hisi/Makefile
index 6870058..2ae1b59 100644
--- a/arch/arm/mach-hisi/Makefile
+++ b/arch/arm/mach-hisi/Makefile
@@ -3,5 +3,4 @@
 #
 
 obj-y	+= hisilicon.o
-obj-$(CONFIG_SMP)		+= platsmp.o
-obj-$(CONFIG_HOTPLUG_CPU)	+= hotplug.o
+obj-$(CONFIG_SMP)		+= platsmp.o hotplug.o
diff --git a/arch/arm/mach-hisi/hotplug.c b/arch/arm/mach-hisi/hotplug.c
index b909854..abd441b 100644
--- a/arch/arm/mach-hisi/hotplug.c
+++ b/arch/arm/mach-hisi/hotplug.c
@@ -178,6 +178,7 @@ static inline void cpu_enter_lowpower(void)
 	  : "cc");
 }
 
+#ifdef CONFIG_HOTPLUG_CPU
 void hi3xxx_cpu_die(unsigned int cpu)
 {
 	cpu_enter_lowpower();
@@ -198,3 +199,4 @@ int hi3xxx_cpu_kill(unsigned int cpu)
 	hi3xxx_set_cpu(cpu, false);
 	return 1;
 }
+#endif
-- 
1.8.3.2

[PATCH 13/62] ARM: hisi: select HAVE_ARM_SCU only for SMP

[Arnd Bergmann]

The SCU code does not build unless we are compiling
an SMP kernel. This does the same as every other
platform with an SCU.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
---
 arch/arm/mach-hisi/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-hisi/Kconfig b/arch/arm/mach-hisi/Kconfig
index 9d0a87b..feee4db 100644
--- a/arch/arm/mach-hisi/Kconfig
+++ b/arch/arm/mach-hisi/Kconfig
@@ -4,7 +4,7 @@ config ARCH_HI3xxx
 	select ARM_GIC
 	select ARM_TIMER_SP804
 	select CACHE_L2X0
-	select HAVE_ARM_SCU
+	select HAVE_ARM_SCU if SMP
 	select HAVE_ARM_TWD if SMP
 	select PINCTRL
 	select PINCTRL_SINGLE
-- 
1.8.3.2

[PATCH 14/62] ARM: imx: imx6q_set_lpm is only defined for CONFIG_PM=y

[Arnd Bergmann]

This ensures that we only call imx6q_set_lpm if CONFIG_PM
is enabled and we are building the pm-imx6q.c file.

Another fix that has been suggested for this is to always
build this file conditionally build only the parts of it
that are relevant only to CONFIG_PM.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Shawn Guo <shawn.guo@freescale.com>
Cc: Sascha Hauer <kernel@pengutronix.de>
---
 arch/arm/mach-imx/clk-imx6q.c      | 3 ++-
 arch/arm/mach-imx/clk-imx6sl.c     | 3 ++-
 arch/arm/mach-imx/cpuidle-imx6sl.c | 3 +++
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index b0e7f9d..133b23e 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -478,7 +478,8 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
 		clk_set_parent(clk[lvds1_sel], clk[sata_ref]);
 
 	/* Set initial power mode */
-	imx6q_set_lpm(WAIT_CLOCKED);
+	if (IS_ENABLED(CONFIG_PM))
+		imx6q_set_lpm(WAIT_CLOCKED);
 
 	np = of_find_compatible_node(NULL, NULL, "fsl,imx6q-gpt");
 	base = of_iomap(np, 0);
diff --git a/arch/arm/mach-imx/clk-imx6sl.c b/arch/arm/mach-imx/clk-imx6sl.c
index f7073c0..a882bdf 100644
--- a/arch/arm/mach-imx/clk-imx6sl.c
+++ b/arch/arm/mach-imx/clk-imx6sl.c
@@ -382,7 +382,8 @@ static void __init imx6sl_clocks_init(struct device_node *ccm_node)
 	clk_set_parent(clks[IMX6SL_CLK_SPDIF0_SEL], clks[IMX6SL_CLK_PLL3_PFD3]);
 
 	/* Set initial power mode */
-	imx6q_set_lpm(WAIT_CLOCKED);
+	if (IS_ENABLED(CONFIG_PM))
+		imx6q_set_lpm(WAIT_CLOCKED);
 
 	np = of_find_compatible_node(NULL, NULL, "fsl,imx6sl-gpt");
 	base = of_iomap(np, 0);
diff --git a/arch/arm/mach-imx/cpuidle-imx6sl.c b/arch/arm/mach-imx/cpuidle-imx6sl.c
index d4b6b81..c9a6aa8 100644
--- a/arch/arm/mach-imx/cpuidle-imx6sl.c
+++ b/arch/arm/mach-imx/cpuidle-imx6sl.c
@@ -53,5 +53,8 @@ static struct cpuidle_driver imx6sl_cpuidle_driver = {
 
 int __init imx6sl_cpuidle_init(void)
 {
+	if (!IS_ENABLED(CONFIG_PM))
+		return -ENOSYS;
+
 	return cpuidle_register(&imx6sl_cpuidle_driver, NULL);
 }
-- 
1.8.3.2

[PATCH 15/62] ARM: ixp4xx/omixp: always include linux/leds.h

[Arnd Bergmann]

The omixp board code unconditionally defines a gpio-led
device, but for some reason includes the header file
for this only if CONFIG_LEDS_CLASS is enabled, causing
a build error otherwise.

Removing the #ifdef fixes the build error with no downsides
whatsoever.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Imre Kaloz <kaloz@openwrt.org>
Cc: Krzysztof Halasa <khc@pm.waw.pl>
---
 arch/arm/mach-ixp4xx/omixp-setup.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/mach-ixp4xx/omixp-setup.c b/arch/arm/mach-ixp4xx/omixp-setup.c
index 75ef03d..2d494b4 100644
--- a/arch/arm/mach-ixp4xx/omixp-setup.c
+++ b/arch/arm/mach-ixp4xx/omixp-setup.c
@@ -17,9 +17,7 @@
 #include <linux/serial_8250.h>
 #include <linux/mtd/mtd.h>
 #include <linux/mtd/partitions.h>
-#ifdef CONFIG_LEDS_CLASS
 #include <linux/leds.h>
-#endif
 
 #include <asm/setup.h>
 #include <asm/memory.h>
-- 
1.8.3.2

[PATCH 16/62] ARM: ixp4xx: avoid use of PCIBIOS_MIN_MEM in io.h

[Arnd Bergmann]

When using CONFIG_IXP4XX_INDIRECT_PCI, we run into a recursive
header file dependency between mach/io.h and asm/pci.h, resulting
in a build failure:

mach-ixp4xx/include/mach/io.h: In function 'is_pci_memory':
mach-ixp4xx/include/mach/io.h:53:18: error: 'PCIBIOS_MIN_MEM' undeclared (first use in this function)
  return (addr >= PCIBIOS_MIN_MEM) && (addr <= 0x4FFFFFFF);
                  ^
mach-ixp4xx/include/mach/io.h:53:18: note: each undeclared identifier is reported only once for each function it appears in

We can work around this by referencing the pcibios_min_mem variable
directly through an extern declaration, rather than using the macro.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Imre Kaloz <kaloz@openwrt.org>
Cc: Krzysztof Halasa <khc@pm.waw.pl>
---
 arch/arm/mach-ixp4xx/include/mach/io.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-ixp4xx/include/mach/io.h b/arch/arm/mach-ixp4xx/include/mach/io.h
index 5cf30d1..559c69a 100644
--- a/arch/arm/mach-ixp4xx/include/mach/io.h
+++ b/arch/arm/mach-ixp4xx/include/mach/io.h
@@ -48,9 +48,10 @@ extern int ixp4xx_pci_write(u32 addr, u32 cmd, u32 data);
  * fallback to the default.
  */
 
+extern unsigned long pcibios_min_mem;
 static inline int is_pci_memory(u32 addr)
 {
-	return (addr >= PCIBIOS_MIN_MEM) && (addr <= 0x4FFFFFFF);
+	return (addr >= pcibios_min_mem) && (addr <= 0x4FFFFFFF);
 }
 
 #define writeb(v, p)			__indirect_writeb(v, p)
-- 
1.8.3.2

[PATCH 17/62] ARM: ixp4xx: fix gpio rework

[Arnd Bergmann]

Commit 098e30f6558f8 "ARM: ixp4xx: stop broadcasting the custom GPIO API"
changed the internal gpio code of ixp4xx to be accessible only from
common.c, but unfortunately that broke the Goramo MultiLink code, which
uses this API.

This tries to restore the previous state without exposing the
API globally again. A better solution might be needed.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Krzysztof Halasa <khc@pm.waw.pl>
Cc: Imre Kaloz <kaloz@openwrt.org>
---
 arch/arm/mach-ixp4xx/common.c     | 6 +++---
 arch/arm/mach-ixp4xx/goramo_mlr.c | 7 +++++++
 2 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-ixp4xx/common.c b/arch/arm/mach-ixp4xx/common.c
index bffbce4..d628b3d 100644
--- a/arch/arm/mach-ixp4xx/common.c
+++ b/arch/arm/mach-ixp4xx/common.c
@@ -110,7 +110,7 @@ void __init ixp4xx_map_io(void)
 #define IXP4XX_GPIO_CLK_0		14
 #define IXP4XX_GPIO_CLK_1		15
 
-static void gpio_line_config(u8 line, u32 direction)
+void gpio_line_config(u8 line, u32 direction)
 {
 	if (direction == IXP4XX_GPIO_IN)
 		*IXP4XX_GPIO_GPOER |= (1 << line);
@@ -118,12 +118,12 @@ static void gpio_line_config(u8 line, u32 direction)
 		*IXP4XX_GPIO_GPOER &= ~(1 << line);
 }
 
-static void gpio_line_get(u8 line, int *value)
+void gpio_line_get(u8 line, int *value)
 {
 	*value = (*IXP4XX_GPIO_GPINR >> line) & 0x1;
 }
 
-static void gpio_line_set(u8 line, int value)
+void gpio_line_set(u8 line, int value)
 {
 	if (value == IXP4XX_GPIO_HIGH)
 	    *IXP4XX_GPIO_GPOUTR |= (1 << line);
diff --git a/arch/arm/mach-ixp4xx/goramo_mlr.c b/arch/arm/mach-ixp4xx/goramo_mlr.c
index e54ff491..5a635c6 100644
--- a/arch/arm/mach-ixp4xx/goramo_mlr.c
+++ b/arch/arm/mach-ixp4xx/goramo_mlr.c
@@ -17,6 +17,13 @@
 #include <asm/mach/pci.h>
 #include <asm/system_info.h>
 
+#define IXP4XX_GPIO_OUT 		0x1
+#define IXP4XX_GPIO_IN  		0x2
+
+void gpio_line_config(u8 line, u32 direction);
+void gpio_line_get(u8 line, int *value);
+void gpio_line_set(u8 line, int value);
+
 #define SLOT_ETHA		0x0B	/* IDSEL = AD21 */
 #define SLOT_ETHB		0x0C	/* IDSEL = AD20 */
 #define SLOT_MPCI		0x0D	/* IDSEL = AD19 */
-- 
1.8.3.2

[PATCH 18/62] ARM: ks8695/og: make PCI setup conditional

[Arnd Bergmann]

The 'og' machine tries to always initialized the PCI code, but that
may be disabled in Kconfig, leading to a build error.

This patch changes the code to use the same Kconfig symbol to decide
about calling the ks8695_init_pci function at build time that we
use to decide about building the ks8695 PCI support.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Ungerer <gerg@uclinux.org>
---
 arch/arm/mach-ks8695/board-og.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-ks8695/board-og.c b/arch/arm/mach-ks8695/board-og.c
index 002bc61..f265816 100644
--- a/arch/arm/mach-ks8695/board-og.c
+++ b/arch/arm/mach-ks8695/board-og.c
@@ -44,7 +44,8 @@ static void __init og_register_pci(void)
 	if (machine_is_im4004())
 		ks8695_gpio_interrupt(KS8695_GPIO_1, IRQ_TYPE_LEVEL_LOW);
 
-	ks8695_init_pci(&og_pci);
+	if (IS_ENABLED(CONFIG_PCI))
+		ks8695_init_pci(&og_pci);
 }
 
 /*
-- 
1.8.3.2

[PATCH 19/62] ARM: lpc32xx: export lpc32xx_return_iram_size

[Arnd Bergmann]

This symbol is used by the lpc_eth driver, which may
be a loadable module.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Roland Stigge <stigge@antcom.de>
---
 arch/arm/mach-lpc32xx/common.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-lpc32xx/common.c b/arch/arm/mach-lpc32xx/common.c
index d7aa54c..de03620 100644
--- a/arch/arm/mach-lpc32xx/common.c
+++ b/arch/arm/mach-lpc32xx/common.c
@@ -99,6 +99,7 @@ u32 lpc32xx_return_iram_size(void)
 
 	return iram_size;
 }
+EXPORT_SYMBOL_GPL(lpc32xx_return_iram_size);
 
 /*
  * Computes PLL rate from PLL register and input clock
-- 
1.8.3.2

[PATCH 20/62] ARM: msm: add missing include of linux/module.h

[Arnd Bergmann]

After the restructuring of the module.h and init.h headers,
we now need to include this explicitly here.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: David Brown <davidb@codeaurora.org>
Cc: Daniel Walker <dwalker@fifo99.com>
Cc: Bryan Huntsman <bryanh@codeaurora.org>
---
 arch/arm/mach-msm/dma.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-msm/dma.c b/arch/arm/mach-msm/dma.c
index f8f6adf..ba62f02 100644
--- a/arch/arm/mach-msm/dma.c
+++ b/arch/arm/mach-msm/dma.c
@@ -18,6 +18,7 @@
 #include <linux/io.h>
 #include <linux/interrupt.h>
 #include <linux/completion.h>
+#include <linux/module.h>
 #include <mach/dma.h>
 #include <mach/msm_iomap.h>
 
-- 
1.8.3.2

[PATCH 21/62] ARM: msm: avoid calling debug_ll_addr on !MMU

[Arnd Bergmann]

MSM7X00A has an open-coded version of debug_ll_io_init so it
can use MT_DEVICE_NONSHARED as required by the platform.

However, this fails to build on no-MMU kernels because the
debug_ll_addr function is not available. Since the iotable_init
function doesn't actually do anyting in this configuration,
we can simply get away by enclosing the broken function call
in an #ifdef, which seems to be the least ugly workaround.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: David Brown <davidb@codeaurora.org>
Cc: Daniel Walker <dwalker@fifo99.com>
Cc: Bryan Huntsman <bryanh@codeaurora.org>
---
 arch/arm/mach-msm/io.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-msm/io.c b/arch/arm/mach-msm/io.c
index adc8971..34e0947 100644
--- a/arch/arm/mach-msm/io.c
+++ b/arch/arm/mach-msm/io.c
@@ -78,8 +78,10 @@ void __init msm_map_common_io(void)
 	asm("mcr p15, 0, %0, c15, c2, 4" : : "r" (0));
 #if defined(CONFIG_DEBUG_MSM_UART1) || defined(CONFIG_DEBUG_MSM_UART2) || \
 		defined(CONFIG_DEBUG_MSM_UART3)
+#ifdef CONFIG_MMU
 	debug_ll_addr(&msm_io_desc[size - 1].pfn,
 		      &msm_io_desc[size - 1].virtual);
+#endif
 	msm_io_desc[size - 1].pfn = __phys_to_pfn(msm_io_desc[size - 1].pfn);
 #endif
 	iotable_init(msm_io_desc, size);
-- 
1.8.3.2

[PATCH 22/62] ARM: msm: export legacy DMA interfaces

[Arnd Bergmann]

The msm_sdcc MMC driver and the msm_serial_hs uart driver both
use the pre-dmaengine interfaces provided by the MSM platform.

Since these drivers can be loadable modules, we should export
the functions used in the drivers.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: David Brown <davidb@codeaurora.org>
Cc: Daniel Walker <dwalker@fifo99.com>
Cc: Bryan Huntsman <bryanh@codeaurora.org>
---
 arch/arm/mach-msm/dma.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-msm/dma.c b/arch/arm/mach-msm/dma.c
index ba62f02..fb976246 100644
--- a/arch/arm/mach-msm/dma.c
+++ b/arch/arm/mach-msm/dma.c
@@ -78,6 +78,7 @@ void msm_dmov_stop_cmd(unsigned id, struct msm_dmov_cmd *cmd, int graceful)
 {
 	writel((graceful << 31), DMOV_FLUSH0(id));
 }
+EXPORT_SYMBOL_GPL(msm_dmov_stop_cmd);
 
 void msm_dmov_enqueue_cmd(unsigned id, struct msm_dmov_cmd *cmd)
 {
@@ -116,6 +117,7 @@ void msm_dmov_enqueue_cmd(unsigned id, struct msm_dmov_cmd *cmd)
 	}
 	spin_unlock_irqrestore(&msm_dmov_lock, irq_flags);
 }
+EXPORT_SYMBOL_GPL(msm_dmov_enqueue_cmd);
 
 struct msm_dmov_exec_cmdptr_cmd {
 	struct msm_dmov_cmd dmov_cmd;
-- 
1.8.3.2

[PATCH 23/62] ARM: omap1: fix building without 32K_TIMER

[Arnd Bergmann]

If we enable CONFIG_OMAP_MPU_TIMER and CONFIG_OMAP_DM_TIMER but
not CONFIG_OMAP_32K_TIMER on OMAP1, we currently get this build error:

mach-omap1/pm.c: In function 'omap1_pm_idle':
mach-omap1/pm.c:123:9: error: 'enable_dyn_sleep' undeclared (first use in this function)
  while (enable_dyn_sleep) {
         ^
mach-omap1/pm.c:123:9: note: each undeclared identifier is reported only once for each function it appears in

This attempts to fix the #ifdef logic to deal with all combinations
of timers.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: linux-omap@vger.kernel.org
Cc: Tony Lindgren <tony@atomide.com>
---
 arch/arm/mach-omap1/pm.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap1/pm.c b/arch/arm/mach-omap1/pm.c
index 40a1ae3..7dff68e 100644
--- a/arch/arm/mach-omap1/pm.c
+++ b/arch/arm/mach-omap1/pm.c
@@ -71,10 +71,10 @@ static unsigned int mpui7xx_sleep_save[MPUI7XX_SLEEP_SAVE_SIZE];
 static unsigned int mpui1510_sleep_save[MPUI1510_SLEEP_SAVE_SIZE];
 static unsigned int mpui1610_sleep_save[MPUI1610_SLEEP_SAVE_SIZE];
 
-#ifdef CONFIG_OMAP_32K_TIMER
-
 static unsigned short enable_dyn_sleep = 1;
 
+#if defined(CONFIG_OMAP_32K_TIMER) || defined(CONFIG_OMAP_MPU_TIMER)
+
 static ssize_t idle_show(struct kobject *kobj, struct kobj_attribute *attr,
 			 char *buf)
 {
@@ -643,7 +643,7 @@ static const struct platform_suspend_ops omap_pm_ops = {
 static int __init omap_pm_init(void)
 {
 
-#ifdef CONFIG_OMAP_32K_TIMER
+#if defined(CONFIG_OMAP_32K_TIMER) || defined(CONFIG_OMAP_MPU_TIMER)
 	int error;
 #endif
 
@@ -700,7 +700,7 @@ static int __init omap_pm_init(void)
 	omap_pm_init_debugfs();
 #endif
 
-#ifdef CONFIG_OMAP_32K_TIMER
+#if defined(CONFIG_OMAP_32K_TIMER) || defined(CONFIG_OMAP_MPU_TIMER)
 	error = sysfs_create_file(power_kobj, &sleep_while_idle_attr.attr);
 	if (error)
 		printk(KERN_ERR "sysfs_create_file failed: %d\n", error);
-- 
1.8.3.2

[PATCH 23/62] ARM: omap1: fix building without 32K_TIMER

[Arnd Bergmann]

If we enable CONFIG_OMAP_MPU_TIMER and CONFIG_OMAP_DM_TIMER but
not CONFIG_OMAP_32K_TIMER on OMAP1, we currently get this build error:

mach-omap1/pm.c: In function 'omap1_pm_idle':
mach-omap1/pm.c:123:9: error: 'enable_dyn_sleep' undeclared (first use in this function)
  while (enable_dyn_sleep) {
         ^
mach-omap1/pm.c:123:9: note: each undeclared identifier is reported only once for each function it appears in

This attempts to fix the #ifdef logic to deal with all combinations
of timers.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: linux-omap at vger.kernel.org
Cc: Tony Lindgren <tony@atomide.com>
---
 arch/arm/mach-omap1/pm.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap1/pm.c b/arch/arm/mach-omap1/pm.c
index 40a1ae3..7dff68e 100644
--- a/arch/arm/mach-omap1/pm.c
+++ b/arch/arm/mach-omap1/pm.c
@@ -71,10 +71,10 @@ static unsigned int mpui7xx_sleep_save[MPUI7XX_SLEEP_SAVE_SIZE];
 static unsigned int mpui1510_sleep_save[MPUI1510_SLEEP_SAVE_SIZE];
 static unsigned int mpui1610_sleep_save[MPUI1610_SLEEP_SAVE_SIZE];
 
-#ifdef CONFIG_OMAP_32K_TIMER
-
 static unsigned short enable_dyn_sleep = 1;
 
+#if defined(CONFIG_OMAP_32K_TIMER) || defined(CONFIG_OMAP_MPU_TIMER)
+
 static ssize_t idle_show(struct kobject *kobj, struct kobj_attribute *attr,
 			 char *buf)
 {
@@ -643,7 +643,7 @@ static const struct platform_suspend_ops omap_pm_ops = {
 static int __init omap_pm_init(void)
 {
 
-#ifdef CONFIG_OMAP_32K_TIMER
+#if defined(CONFIG_OMAP_32K_TIMER) || defined(CONFIG_OMAP_MPU_TIMER)
 	int error;
 #endif
 
@@ -700,7 +700,7 @@ static int __init omap_pm_init(void)
 	omap_pm_init_debugfs();
 #endif
 
-#ifdef CONFIG_OMAP_32K_TIMER
+#if defined(CONFIG_OMAP_32K_TIMER) || defined(CONFIG_OMAP_MPU_TIMER)
 	error = sysfs_create_file(power_kobj, &sleep_while_idle_attr.attr);
 	if (error)
 		printk(KERN_ERR "sysfs_create_file failed: %d\n", error);
-- 
1.8.3.2

[PATCH 24/62] ARM: omap1: select I2C where needed for PMIC

[Arnd Bergmann]

The OMAP H2, OSK and OSIRIS machines cannot build without
I2C and TPS65010 both enabled unconditionally.

In each case, failing to enable CONFIG_I2C results in a
build or link error, so most consistent solution is to
ensure that it is impossible to disable those options.

It would be nice to leave CONFIG_I2C as user-selectable,
but doing that properly would require more work.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tony Lindgren <tony@atomide.com>
Cc: linux-omap@vger.kernel.org
---
 arch/arm/mach-omap1/Kconfig | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/mach-omap1/Kconfig b/arch/arm/mach-omap1/Kconfig
index cdd05f2..23ab1d5 100644
--- a/arch/arm/mach-omap1/Kconfig
+++ b/arch/arm/mach-omap1/Kconfig
@@ -44,6 +44,8 @@ config MACH_OMAP_INNOVATOR
 config MACH_OMAP_H2
 	bool "TI H2 Support"
 	depends on ARCH_OMAP1 && ARCH_OMAP16XX
+	select TPS65010
+	select I2C
     	help
 	  TI OMAP 1610/1611B H2 board support. Say Y here if you have such
 	  a board.
@@ -64,6 +66,8 @@ config MACH_HERALD
 config MACH_OMAP_OSK
 	bool "TI OSK Support"
 	depends on ARCH_OMAP1 && ARCH_OMAP16XX
+	select TPS65010
+	select I2C
     	help
 	  TI OMAP 5912 OSK (OMAP Starter Kit) board support. Say Y here
           if you have such a board.
-- 
1.8.3.2

[PATCH 24/62] ARM: omap1: select I2C where needed for PMIC

[Arnd Bergmann]

The OMAP H2, OSK and OSIRIS machines cannot build without
I2C and TPS65010 both enabled unconditionally.

In each case, failing to enable CONFIG_I2C results in a
build or link error, so most consistent solution is to
ensure that it is impossible to disable those options.

It would be nice to leave CONFIG_I2C as user-selectable,
but doing that properly would require more work.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tony Lindgren <tony@atomide.com>
Cc: linux-omap at vger.kernel.org
---
 arch/arm/mach-omap1/Kconfig | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/mach-omap1/Kconfig b/arch/arm/mach-omap1/Kconfig
index cdd05f2..23ab1d5 100644
--- a/arch/arm/mach-omap1/Kconfig
+++ b/arch/arm/mach-omap1/Kconfig
@@ -44,6 +44,8 @@ config MACH_OMAP_INNOVATOR
 config MACH_OMAP_H2
 	bool "TI H2 Support"
 	depends on ARCH_OMAP1 && ARCH_OMAP16XX
+	select TPS65010
+	select I2C
     	help
 	  TI OMAP 1610/1611B H2 board support. Say Y here if you have such
 	  a board.
@@ -64,6 +66,8 @@ config MACH_HERALD
 config MACH_OMAP_OSK
 	bool "TI OSK Support"
 	depends on ARCH_OMAP1 && ARCH_OMAP16XX
+	select TPS65010
+	select I2C
     	help
 	  TI OMAP 5912 OSK (OMAP Starter Kit) board support. Say Y here
           if you have such a board.
-- 
1.8.3.2

[PATCH 25/62] ARM: mvebu: add missing header

[Arnd Bergmann]

The definition for SIGBUS may not be visible without including
linux/signal.h, as I found during randconfig testing.

Adding an explicit include is certainly the right thing to do.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Gregory Clement <gregory.clement@free-electrons.com>
Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
 arch/arm/mach-mvebu/board-v7.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-mvebu/board-v7.c b/arch/arm/mach-mvebu/board-v7.c
index 746134e..333fca8 100644
--- a/arch/arm/mach-mvebu/board-v7.c
+++ b/arch/arm/mach-mvebu/board-v7.c
@@ -21,6 +21,7 @@
 #include <linux/clocksource.h>
 #include <linux/dma-mapping.h>
 #include <linux/mbus.h>
+#include <linux/signal.h>
 #include <linux/slab.h>
 #include <asm/hardware/cache-l2x0.h>
 #include <asm/mach/arch.h>
-- 
1.8.3.2

[PATCH 26/62] ARM: mvebu: don't select CONFIG_NEON

[Arnd Bergmann]

CONFIG_NEON is meant to be user-selectable. Turning it on
unconditionally means we can't build a smaller kernel when
we don't need it, and causes build errors if CONFIG_VFP
is not also enabled.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Gregory Clement <gregory.clement@free-electrons.com>
Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
 arch/arm/mach-mvebu/Kconfig | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 485513cb..b24a082 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -39,7 +39,6 @@ config MACH_ARMADA_375
 	select ARMADA_375_CLK
 	select CPU_V7
 	select MACH_MVEBU_V7
-	select NEON
 	select PINCTRL_ARMADA_375
 	help
 	  Say 'Y' here if you want your kernel to support boards based
@@ -53,7 +52,6 @@ config MACH_ARMADA_38X
 	select ARMADA_38X_CLK
 	select CPU_V7
 	select MACH_MVEBU_V7
-	select NEON
 	select PINCTRL_ARMADA_38X
 	help
 	  Say 'Y' here if you want your kernel to support boards based
-- 
1.8.3.2

[PATCH 27/62] ARM: orion5x: make dns323 independent of PHY support

[Arnd Bergmann]

The D-Link DNS-323 machine tries to unconditionally select CONFIG_PHYLIB,
but that has other dependencies that might not necessarily be enabled,
causing random build errors.

To work around this, this patch removes the 'select' statement and
instead uses a compile-time check to skip the phy_register_fixup_for_uid()
call if PHYLIB is not available in the kernel.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Gregory Clement <gregory.clement@free-electrons.com>
Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
 arch/arm/mach-orion5x/Kconfig        | 1 -
 arch/arm/mach-orion5x/dns323-setup.c | 2 ++
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-orion5x/Kconfig b/arch/arm/mach-orion5x/Kconfig
index 2cb2f06..14f2cae 100644
--- a/arch/arm/mach-orion5x/Kconfig
+++ b/arch/arm/mach-orion5x/Kconfig
@@ -33,7 +33,6 @@ config MACH_KUROBOX_PRO
 config MACH_DNS323
 	bool "D-Link DNS-323"
 	select I2C_BOARDINFO
-	select PHYLIB
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  D-Link DNS-323 platform.
diff --git a/arch/arm/mach-orion5x/dns323-setup.c b/arch/arm/mach-orion5x/dns323-setup.c
index 7097473..56edeab 100644
--- a/arch/arm/mach-orion5x/dns323-setup.c
+++ b/arch/arm/mach-orion5x/dns323-setup.c
@@ -642,6 +642,8 @@ static void __init dns323_init(void)
 		platform_device_register_simple("dns323c-fan", 0, NULL, 0);
 
 		/* Register fixup for the PHY LEDs */
+		if (!IS_BUILTIN(CONFIG_PHYLIB))
+			break;
 		phy_register_fixup_for_uid(MARVELL_PHY_ID_88E1118,
 					   MARVELL_PHY_ID_MASK,
 					   dns323c_phy_fixup);
-- 
1.8.3.2

[PATCH 28/62] ARM: pxa: FB_W100 must be built-in

[Arnd Bergmann]

The pxa platform code directly calls into the W100 framebuffer
driver for eseries. This means it cannot be a loadable module
and we also have to ensure that the core framebuffer code
is built-in.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Daniel Mack <zonque@gmail.com>
---
 arch/arm/mach-pxa/Kconfig | 1 +
 drivers/video/Kconfig     | 4 ++--
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
index 96100db..562b17f 100644
--- a/arch/arm/mach-pxa/Kconfig
+++ b/arch/arm/mach-pxa/Kconfig
@@ -556,6 +556,7 @@ config MACH_ICONTROL
 config ARCH_PXA_ESERIES
 	bool "PXA based Toshiba e-series PDAs"
 	select FB_W100
+	select FB
 	select PXA25x
 
 config MACH_E330
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index dade5b7..86873ff 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -1996,8 +1996,8 @@ config FB_FSL_DIU
 	  Framebuffer driver for the Freescale SoC DIU
 
 config FB_W100
-	tristate "W100 frame buffer support"
-	depends on FB && ARCH_PXA
+	bool "W100 frame buffer support"
+	depends on FB=y && ARCH_PXA
  	select FB_CFB_FILLRECT
  	select FB_CFB_COPYAREA
  	select FB_CFB_IMAGEBLIT
-- 
1.8.3.2

[PATCH 29/62] ARM: pxa: don't "select" SMC91X on MACH_XCEP

[Arnd Bergmann]

We normally don't hard-enable Kconfig options just because
a board contains a specific piece of hardware. In this case,
selecting SMC91X causes a build error, if we don't also enable
basic network device driver support.

Since the platform has no direct dependency on this driver
at link time, we can just remove the 'select' statement.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Daniel Mack <zonque@gmail.com>
---
 arch/arm/mach-pxa/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
index 562b17f..2c7498a 100644
--- a/arch/arm/mach-pxa/Kconfig
+++ b/arch/arm/mach-pxa/Kconfig
@@ -164,7 +164,6 @@ config MACH_XCEP
 	select MTD_CFI_INTELEXT
 	select MTD_PHYSMAP
 	select PXA25x
-	select SMC91X
 	help
 	  PXA255 based Single Board Computer with SMC 91C111 ethernet chip and 64 MB of flash.
 	  Tuned for usage in Libera instruments for particle accelerators.
-- 
1.8.3.2

[PATCH 30/62] ARM: pxa: enable pxafb unconditionally for some boards

[Arnd Bergmann]

The SAAR and TAVOREVB machines try to call functions from
the PXAFB frame buffer driver from their platform code,
which only works if that driver is built-in.

This patch ensures that both the generic frame buffer
code and the specific pxafb driver are always enabled
when we build a kernel for one of the two boards.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Daniel Mack <zonque@gmail.com>
---
 arch/arm/mach-pxa/Kconfig | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
index 2c7498a..50f6132 100644
--- a/arch/arm/mach-pxa/Kconfig
+++ b/arch/arm/mach-pxa/Kconfig
@@ -53,12 +53,16 @@ config MACH_TAVOREVB
 	select CPU_PXA930
 	select CPU_PXA935
 	select PXA3xx
+	select FB
+	select FB_PXA
 
 config MACH_SAAR
 	bool "PXA930 Handheld Platform (aka SAAR)"
 	select CPU_PXA930
 	select CPU_PXA935
 	select PXA3xx
+	select FB
+	select FB_PXA
 
 comment "Third Party Dev Platforms (sorted by vendor name)"
 
-- 
1.8.3.2

[PATCH 31/62] ARM: pxa: fix colibri build

[Arnd Bergmann]

The colibri_ohci_init function performs a register access through
the io_p2v() macro, which requires the IOMEM macro to be defined.

By explicitly including the asm/io.h header file that contains
this macro, we avoid the build error:

arch/arm/mach-pxa/colibri-evalboard.c: In function 'colibri_ohci_init':
arch/arm/mach-pxa/colibri-evalboard.c:68:2: error: implicit declaration of function 'IOMEM' [-Werror=implicit-function-declaration]
  UP2OCR = UP2OCR_HXS | UP2OCR_HXOE | UP2OCR_DPPDE | UP2OCR_DMPDE;

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Daniel Mack <zonque@gmail.com>
---
 arch/arm/mach-pxa/colibri-evalboard.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-pxa/colibri-evalboard.c b/arch/arm/mach-pxa/colibri-evalboard.c
index 8404b24..638b0bb 100644
--- a/arch/arm/mach-pxa/colibri-evalboard.c
+++ b/arch/arm/mach-pxa/colibri-evalboard.c
@@ -20,6 +20,7 @@
 #include <asm/mach/arch.h>
 #include <linux/i2c.h>
 #include <linux/i2c/pxa-i2c.h>
+#include <asm/io.h>
 
 #include <mach/pxa27x.h>
 #include <mach/colibri.h>
-- 
1.8.3.2

[PATCH 32/62] ARM: pxa: fix pxa_ssp_* declarations

[Arnd Bergmann]

The functions declared in include/linux/pxa2xx_ssp.h are
defined in plat-pxa/ssp.c, which can also be built for
PLAT_MMP, but may be disabled there. This can lead to
both unresolved symbols at link time and to duplicate
symbols at compile time for random configurations.

Changing the #ifdef in the header file to match the
Kconfig symbol that decides if the file is built solves
both problems.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Daniel Mack <zonque@gmail.com>
---
 include/linux/pxa2xx_ssp.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/pxa2xx_ssp.h b/include/linux/pxa2xx_ssp.h
index 4944420..f2b4051 100644
--- a/include/linux/pxa2xx_ssp.h
+++ b/include/linux/pxa2xx_ssp.h
@@ -219,7 +219,7 @@ static inline u32 pxa_ssp_read_reg(struct ssp_device *dev, u32 reg)
 	return __raw_readl(dev->mmio_base + reg);
 }
 
-#ifdef CONFIG_ARCH_PXA
+#if IS_ENABLED(CONFIG_PXA_SSP)
 struct ssp_device *pxa_ssp_request(int port, const char *label);
 void pxa_ssp_free(struct ssp_device *);
 struct ssp_device *pxa_ssp_request_of(const struct device_node *of_node,
-- 
1.8.3.2

[PATCH 33/62] ARM: pxa: remove broken balloon3_gpio_vbus reference

[Arnd Bergmann]

balloon3_udc_init() tries to register a balloon3_gpio_vbus
device, but this has never been defined in the mainline
kernel. To avoid the obvious build failure when this function
is enabled, remove the bogus reference here.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Daniel Mack <zonque@gmail.com>
---
 arch/arm/mach-pxa/balloon3.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/mach-pxa/balloon3.c b/arch/arm/mach-pxa/balloon3.c
index 2f71b3f..43596e0 100644
--- a/arch/arm/mach-pxa/balloon3.c
+++ b/arch/arm/mach-pxa/balloon3.c
@@ -331,7 +331,6 @@ static struct pxa2xx_udc_mach_info balloon3_udc_info __initdata = {
 static void __init balloon3_udc_init(void)
 {
 	pxa_set_udc_info(&balloon3_udc_info);
-	platform_device_register(&balloon3_gpio_vbus);
 }
 #else
 static inline void balloon3_udc_init(void) {}
-- 
1.8.3.2

[PATCH 34/62] ARM: pxa: select I2C_GPIO only if I2C is on

[Arnd Bergmann]

The Arcom/Eurotech VIPER SBC enables the I2C_GPIO driver, but
that has a dependency on I2C, and causes build failures if I2C
is disabled. To keep existing configurations running while fixing
the randconfig problems, this changes the logic to only enable
I2C_GPIO if I2C is already enabled.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Daniel Mack <zonque@gmail.com>
---
 arch/arm/mach-pxa/Kconfig | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
index 50f6132..8d9f4f1 100644
--- a/arch/arm/mach-pxa/Kconfig
+++ b/arch/arm/mach-pxa/Kconfig
@@ -73,8 +73,7 @@ config ARCH_PXA_IDP
 config ARCH_VIPER
 	bool "Arcom/Eurotech VIPER SBC"
 	select ARCOM_PCMCIA
-	select HAVE_PWM
-	select I2C_GPIO
+	select I2C_GPIO if I2C=y
 	select ISA
 	select PXA25x
 	select PXA_HAVE_ISA_IRQS
-- 
1.8.3.2

[PATCH 35/62] ARM: pxa: trizeps4 and trizeps4wl use the same file

[Arnd Bergmann]

The trizeps4 and trizeps4wl platforms are both implemented
using the same board file. Since the trizeps4wl code is a
superset of trizeps4, it makes no sense to enable just the
latter, but with the current Kconfig logic, it causes the
board file not to be built at all.

Selecting MACH_TRIZEPS4 from MACH_TRIZEPS4WL ensures that
we are actually building the board file.

Found during randconfig testing.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Daniel Mack <zonque@gmail.com>
---
 arch/arm/mach-pxa/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
index 8d9f4f1..692aa5c 100644
--- a/arch/arm/mach-pxa/Kconfig
+++ b/arch/arm/mach-pxa/Kconfig
@@ -183,6 +183,7 @@ config MACH_TRIZEPS4
 config MACH_TRIZEPS4WL
 	bool "Keith und Koep Trizeps4-WL DIMM-Module"
 	depends on TRIZEPS_PXA
+	select MACH_TRIZEPS4
 	select PXA27x
 	select TRIZEPS_PCMCIA
 
-- 
1.8.3.2

[PATCH 36/62] ARM: rpc: autoselect CPU_SA110

[Arnd Bergmann]

ARCH_RPC no longer supports other CPUs aside from StrongARM110,
so we can make the option implicitly selected by the platform
and no longer give the option of building a kernel without CPU
support.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@arm.linux.org.uk>
---
 arch/arm/Kconfig    | 1 +
 arch/arm/mm/Kconfig | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5776c12..4721007 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -696,6 +696,7 @@ config ARCH_RPC
 	select ARCH_MAY_HAVE_PC_FDC
 	select ARCH_SPARSEMEM_ENABLE
 	select ARCH_USES_GETTIMEOFFSET
+	select CPU_SA110
 	select FIQ
 	select HAVE_IDE
 	select HAVE_PATA_PLATFORM
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index dccd7e1..297b63b 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -264,7 +264,7 @@ config CPU_ARM1026
 
 # SA110
 config CPU_SA110
-	bool "Support StrongARM(R) SA-110 processor" if ARCH_RPC
+	bool
 	select CPU_32v3 if ARCH_RPC
 	select CPU_32v4 if !ARCH_RPC
 	select CPU_ABRT_EV4
-- 
1.8.3.2

[PATCH 37/62] ARM: sa1100/pxa: fix MTD_XIP build

[Arnd Bergmann]

In commit 3169663ac5902 "ARM: sa11x0/pxa: convert OS timer registers
to IOMEM", the definition of the OSCR macro was changed to be an
__iomem pointer, but the same register is also used by the XIP
code. This patch does the corresponding change here as well.

Since PXA now uses a local variable for the base address of the
ICIP register, the xip_irqpending function has to be moved
into irq.c in the process.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@arm.linux.org.uk>
---
 arch/arm/mach-pxa/include/mach/mtd-xip.h    | 7 ++++---
 arch/arm/mach-pxa/irq.c                     | 8 ++++++++
 arch/arm/mach-sa1100/include/mach/mtd-xip.h | 4 ++--
 3 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-pxa/include/mach/mtd-xip.h b/arch/arm/mach-pxa/include/mach/mtd-xip.h
index 990d2bf..c4c90d1 100644
--- a/arch/arm/mach-pxa/include/mach/mtd-xip.h
+++ b/arch/arm/mach-pxa/include/mach/mtd-xip.h
@@ -17,11 +17,12 @@
 
 #include <mach/regs-ost.h>
 
-#define xip_irqpending()	(ICIP & ICMR)
+extern bool xip_irqpending(void);
 
 /* we sample OSCR and convert desired delta to usec (1/4 ~= 1000000/3686400) */
-#define xip_currtime()		(OSCR)
-#define xip_elapsed_since(x)	(signed)((OSCR - (x)) / 4)
+#define xip_irqpending()	xip_irqpending()
+#define xip_currtime()		readl(OSCR)
+#define xip_elapsed_since(x)	(signed)((readl(OSCR) - (x)) / 4)
 
 /*
  * xip_cpu_idle() is used when waiting for a delay equal or larger than
diff --git a/arch/arm/mach-pxa/irq.c b/arch/arm/mach-pxa/irq.c
index 0eecd83..dcc8522 100644
--- a/arch/arm/mach-pxa/irq.c
+++ b/arch/arm/mach-pxa/irq.c
@@ -81,6 +81,14 @@ void pxa_unmask_irq(struct irq_data *d)
 	__raw_writel(icmr, base + ICMR);
 }
 
+#ifdef CONFIG_MTD_XIP
+bool xip_irqpending(void)
+{
+	return readl(pxa_irq_base + ICIP) & readl(pxa_irq_base + ICMR);
+}
+EXPORT_SYMBOL_GPL(xip_irqpending);
+#endif
+
 static struct irq_chip pxa_internal_irq_chip = {
 	.name		= "SC",
 	.irq_ack	= pxa_mask_irq,
diff --git a/arch/arm/mach-sa1100/include/mach/mtd-xip.h b/arch/arm/mach-sa1100/include/mach/mtd-xip.h
index b3d6840..cb76096 100644
--- a/arch/arm/mach-sa1100/include/mach/mtd-xip.h
+++ b/arch/arm/mach-sa1100/include/mach/mtd-xip.h
@@ -20,7 +20,7 @@
 #define xip_irqpending()	(ICIP & ICMR)
 
 /* we sample OSCR and convert desired delta to usec (1/4 ~= 1000000/3686400) */
-#define xip_currtime()		(OSCR)
-#define xip_elapsed_since(x)	(signed)((OSCR - (x)) / 4)
+#define xip_currtime()		readl_relaxed(OSCR)
+#define xip_elapsed_since(x)	(signed)((readl_relaxed(OSCR) - (x)) / 4)
 
 #endif /* __ARCH_SA1100_MTD_XIP_H__ */
-- 
1.8.3.2

[PATCH 38/62] ARM: footbridge: don't build floppy code for addin mode

[Arnd Bergmann]

The ARCH_EBSA285_ADDIN platform does not provide the
ISA_DMA API, which is required by the floppy driver.

Let's ensure that the floppy code can only be built
when ISA_DMA is also enabled, by moving the select
statement into ARCH_EBSA285_HOST.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@arm.linux.org.uk>
---
 arch/arm/mach-footbridge/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-footbridge/Kconfig b/arch/arm/mach-footbridge/Kconfig
index fba55fb..07152d0 100644
--- a/arch/arm/mach-footbridge/Kconfig
+++ b/arch/arm/mach-footbridge/Kconfig
@@ -52,6 +52,7 @@ config ARCH_EBSA285_HOST
 	select FOOTBRIDGE_HOST
 	select ISA
 	select ISA_DMA
+	select ARCH_MAY_HAVE_PC_FDC
 	select PCI
 	help
 	  Say Y here if you intend to run this kernel on the EBSA285 card
@@ -94,6 +95,5 @@ config FOOTBRIDGE_ADDIN
 # EBSA285 board in either host or addin mode
 config ARCH_EBSA285
 	bool
-	select ARCH_MAY_HAVE_PC_FDC
 
 endif
-- 
1.8.3.2

[PATCH 39/62] ARM: footbridge: fix build with PCI disabled

[Arnd Bergmann]

The dc21285.c source file cannot be built when CONFIG_PCI is
disabled, because it calls a number of PCI core interfaces.

This changes the Makefile so we don't include this file in the
build if CONFIG_PCI is disabled. No other code references anything
defined inside of this file in this case.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@arm.linux.org.uk>
---
 arch/arm/mach-footbridge/Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-footbridge/Makefile b/arch/arm/mach-footbridge/Makefile
index 0b64dd4..c3faa3b 100644
--- a/arch/arm/mach-footbridge/Makefile
+++ b/arch/arm/mach-footbridge/Makefile
@@ -4,11 +4,12 @@
 
 # Object file lists.
 
-obj-y			:= common.o dc21285.o dma.o isa-irq.o
+obj-y			:= common.o dma.o isa-irq.o
 obj-m			:=
 obj-n			:=
 obj-			:=
 
+pci-y			+= dc21285.o
 pci-$(CONFIG_ARCH_CATS) += cats-pci.o
 pci-$(CONFIG_ARCH_EBSA285_HOST) += ebsa285-pci.o
 pci-$(CONFIG_ARCH_NETWINDER) += netwinder-pci.o
-- 
1.8.3.2

[PATCH 40/62] ARM: footbridge: make screen_info setup conditional

[Arnd Bergmann]

The global screen_info structure is used to communicate
data about the console from platform code to the console
driver, but is only defined on ARM if either the VGA or
dummy consoles are in use.

This changes the footbridge code so we don't try to access
this structure in case it is not defined, which prevents
a possible randconfig build error.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@arm.linux.org.uk>
---
 arch/arm/mach-footbridge/cats-hw.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-footbridge/cats-hw.c b/arch/arm/mach-footbridge/cats-hw.c
index 9669cc0..da04150 100644
--- a/arch/arm/mach-footbridge/cats-hw.c
+++ b/arch/arm/mach-footbridge/cats-hw.c
@@ -78,9 +78,11 @@ __initcall(cats_hw_init);
 static void __init
 fixup_cats(struct tag *tags, char **cmdline, struct meminfo *mi)
 {
+#if defined(CONFIG_VGA_CONSOLE) || defined(CONFIG_DUMMY_CONSOLE)
 	screen_info.orig_video_lines  = 25;
 	screen_info.orig_video_points = 16;
 	screen_info.orig_y = 24;
+#endif
 }
 
 MACHINE_START(CATS, "Chalice-CATS")
-- 
1.8.3.2

[PATCH 41/62] ARM: realview: fix sparsemem build

[Arnd Bergmann]

Commit b713aa0b15 "ARM: fix asm/memory.h build error" broke some
configurations on mach-realview with sparsemem enabled, which
is missing a definition of PHYS_OFFSET:

arch/arm/include/asm/memory.h:268:42: error: 'PHYS_OFFSET' undeclared (first use in this function)
 #define PHYS_PFN_OFFSET ((unsigned long)(PHYS_OFFSET >> PAGE_SHIFT))
arch/arm/include/asm/dma-mapping.h:104:9: note: in expansion of macro 'PHYS_PFN_OFFSET'
  return PHYS_PFN_OFFSET + dma_to_pfn(dev, *dev->dma_mask);

An easy workaround is for realview to define PHYS_OFFSET itself,
in the same way we define it for platforms that don't have a private
__virt_to_phys function.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Linus Walleij <linus.walleij@linaro.org>
---
 arch/arm/mach-realview/include/mach/memory.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-realview/include/mach/memory.h b/arch/arm/mach-realview/include/mach/memory.h
index 2022e09..db09170 100644
--- a/arch/arm/mach-realview/include/mach/memory.h
+++ b/arch/arm/mach-realview/include/mach/memory.h
@@ -56,6 +56,8 @@
 #define PAGE_OFFSET1	(PAGE_OFFSET + 0x10000000)
 #define PAGE_OFFSET2	(PAGE_OFFSET + 0x30000000)
 
+#define PHYS_OFFSET PLAT_PHYS_OFFSET
+
 #define __phys_to_virt(phys)						\
 	((phys) >= 0x80000000 ?	(phys) - 0x80000000 + PAGE_OFFSET2 :	\
 	 (phys) >= 0x20000000 ?	(phys) - 0x20000000 + PAGE_OFFSET1 :	\
-- 
1.8.3.2

[PATCH 42/62] ARM: realview: use explicit core tile config options

[Arnd Bergmann]

The realview platform can be used with numerous core tiles,
which have to be enabled in the CPU menu at the moment, and
the user has to know at configuration time which CPUs can
be enabled in the same kernel.

Most importantly, it is not a valid configuration to select
both ARMv5 and ARMv6/v7 based CPU cores in the same kernel,
and trying that leads to compile errors.

To make it possible to use realview on randconfig kernels,
and to simplify manual configuration, this lists all
supported combinations of machines and core tiles explicitly
and ensures that we cannot enable the ARM926T CPU if any
ARMv6 or v7 CPU is already enabled.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Linus Walleij <linus.walleij@linaro.org>
---
 arch/arm/mach-realview/Kconfig | 57 ++++++++++++++++++++++++++++++++++++++++++
 arch/arm/mm/Kconfig            |  8 +++---
 2 files changed, 61 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-realview/Kconfig b/arch/arm/mach-realview/Kconfig
index 9db2029..938fd06 100644
--- a/arch/arm/mach-realview/Kconfig
+++ b/arch/arm/mach-realview/Kconfig
@@ -8,6 +8,38 @@ config MACH_REALVIEW_EB
 	  Include support for the ARM(R) RealView(R) Emulation Baseboard
 	  platform.
 
+config REALVIEW_EB_ARM926
+	bool "Support ARM926EJ-S Tile"
+	depends on MACH_REALVIEW_EB && !(CPU_V6 || CPU_V6K || CPU_V7)
+	select CPU_ARM926T
+	help
+	  Enable support for the ARM926 tile fitted to the
+	  Realview(R) Emulation Baseboard platform.
+
+config REALVIEW_EB_ARM1136
+	bool "Support ARM1136J(F)-S Tile"
+	depends on MACH_REALVIEW_EB
+	select CPU_V6
+	help
+	  Enable support for the ARM1136 tile fitted to the
+	  Realview(R) Emulation Baseboard platform.
+
+config REALVIEW_EB_ARM1176
+	bool "Support ARM1176JZ(F)-S Tile"
+	depends on MACH_REALVIEW_EB
+	select CPU_V6K
+	help
+	  Enable support for the ARM1176 tile fitted to the
+	  Realview(R) Emulation Baseboard platform.
+
+config REALVIEW_EB_V7
+	bool "Support Cortex-A5/A7/A8/A9/A12/A15 Tile"
+	depends on MACH_REALVIEW_EB
+	select CPU_V7
+	help
+	  Enable support for Cortex-A class ARMv7-A uniprocessor tiles
+	  fitted to the Realview(R) Emulation Baseboard platform.
+
 config REALVIEW_EB_A9MP
 	bool "Support Multicore Cortex-A9 Tile"
 	depends on MACH_REALVIEW_EB
@@ -101,6 +133,31 @@ config MACH_REALVIEW_PBX
 	  Include support for the ARM(R) RealView(R) Platform Baseboard
 	  Explore.
 
+config REALVIEW_PBX_ARM1136
+	bool "Support ARM1136J(F)-S Tile"
+	depends on MACH_REALVIEW_PBX
+	select CPU_V6
+	help
+	  Enable support for the ARM1136 tile fitted to the
+	  Realview(R) Platform Baseboard Explore.
+
+config REALVIEW_PBX_ARM1176
+	bool "Support ARM1176JZ(F)-S Tile"
+	depends on MACH_REALVIEW_PBX
+	select CPU_V6K
+	help
+	  Enable support for the ARM1176 tile fitted to the
+	  Realview(R) Platform Baseboard Explore.
+
+config REALVIEW_PBX_V7
+	bool "Support Cortex-A5/A7/A8/A9/A12/A15 Tile"
+	depends on MACH_REALVIEW_PBX
+	select CPU_V7
+	help
+	  Enable support for Cortex-A class ARMv7-A uniprocessor tiles
+	  fitted to the Realview(R) Platform Baseboard Explore.
+
+
 config REALVIEW_HIGH_PHYS_OFFSET
 	bool "High physical base address for the RealView platform"
 	depends on MMU && !MACH_REALVIEW_PB1176
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 297b63b..8c94496 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -127,7 +127,7 @@ config CPU_ARM925T
 
 # ARM926T
 config CPU_ARM926T
-	bool "Support ARM926T processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB
+	bool "Support ARM926T processor" if ARCH_INTEGRATOR
 	select CPU_32v5
 	select CPU_ABRT_EV5TJ
 	select CPU_CACHE_VIVT
@@ -358,7 +358,7 @@ config CPU_PJ4B
 
 # ARMv6
 config CPU_V6
-	bool "Support ARM V6 processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX
+	bool "Support ARM V6 processor" if ARCH_INTEGRATOR
 	select CPU_32v6
 	select CPU_ABRT_EV6
 	select CPU_CACHE_V6
@@ -371,7 +371,7 @@ config CPU_V6
 
 # ARMv6k
 config CPU_V6K
-	bool "Support ARM V6K processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX
+	bool "Support ARM V6K processor" if ARCH_INTEGRATOR
 	select CPU_32v6
 	select CPU_32v6K
 	select CPU_ABRT_EV6
@@ -385,7 +385,7 @@ config CPU_V6K
 
 # ARMv7
 config CPU_V7
-	bool "Support ARM V7 processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX
+	bool "Support ARM V7 processor" if ARCH_INTEGRATOR
 	select CPU_32v6K
 	select CPU_32v7
 	select CPU_ABRT_EV7
-- 
1.8.3.2

[PATCH 43/62] ARM: integrator: only select pl01x if TTY is enabled

[Arnd Bergmann]

Building the integrator platform without TTY support currently
results in a build failure because we always turn on the
pl010 or pl011 drivers. Changing this to a conditional 'select'
statement enables us to build more random configurations, although
it should have little impact for practical configurations.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Linus Walleij <linus.walleij@linaro.org>
---
 arch/arm/mach-integrator/Kconfig | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-integrator/Kconfig b/arch/arm/mach-integrator/Kconfig
index 6e8b0e1..ba43321 100644
--- a/arch/arm/mach-integrator/Kconfig
+++ b/arch/arm/mach-integrator/Kconfig
@@ -6,8 +6,8 @@ config ARCH_INTEGRATOR_AP
 	bool "Support Integrator/AP and Integrator/PP2 platforms"
 	select CLKSRC_MMIO
 	select MIGHT_HAVE_PCI
-	select SERIAL_AMBA_PL010
-	select SERIAL_AMBA_PL010_CONSOLE
+	select SERIAL_AMBA_PL010 if TTY
+	select SERIAL_AMBA_PL010_CONSOLE if TTY
 	select SOC_BUS
 	help
 	  Include support for the ARM(R) Integrator/AP and
@@ -18,8 +18,8 @@ config ARCH_INTEGRATOR_CP
 	select ARCH_CINTEGRATOR
 	select ARM_TIMER_SP804
 	select PLAT_VERSATILE_CLCD
-	select SERIAL_AMBA_PL011
-	select SERIAL_AMBA_PL011_CONSOLE
+	select SERIAL_AMBA_PL011 if TTY
+	select SERIAL_AMBA_PL011_CONSOLE if TTY
 	select SOC_BUS
 	help
 	  Include support for the ARM(R) Integrator CP platform.
-- 
1.8.3.2

[PATCH 44/62] ARM: integrator: refine CPU selection

[Arnd Bergmann]

This adds a new Kconfig option for the Integrator platform to
choose between ARMv4/ARMv5 based CPUs and those based on ARMv6/ARMv7,
which is required because we cannot have both classes enabled in the
same kernel at compile time.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Linus Walleij <linus.walleij@linaro.org>
---
 arch/arm/mach-integrator/Kconfig | 11 +++++++++++
 arch/arm/mm/Kconfig              | 28 ++++++++++++++--------------
 2 files changed, 25 insertions(+), 14 deletions(-)

diff --git a/arch/arm/mach-integrator/Kconfig b/arch/arm/mach-integrator/Kconfig
index ba43321..8c797e77 100644
--- a/arch/arm/mach-integrator/Kconfig
+++ b/arch/arm/mach-integrator/Kconfig
@@ -2,6 +2,17 @@ if ARCH_INTEGRATOR
 
 menu "Integrator Options"
 
+choice
+	prompt "CPU architecture level"
+
+config ARCH_INTEGRATOR_V4_V5
+	bool "ARMv4 or ARMv5 CPUs"
+
+config ARCH_INTEGRATOR_V6_V7
+	bool "ARMv6 or ARMv7 CPUs"
+
+endchoice
+
 config ARCH_INTEGRATOR_AP
 	bool "Support Integrator/AP and Integrator/PP2 platforms"
 	select CLKSRC_MMIO
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 8c94496..af76df4 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -21,7 +21,7 @@ config CPU_ARM7TDMI
 
 # ARM720T
 config CPU_ARM720T
-	bool "Support ARM720T processor" if ARCH_INTEGRATOR
+	bool "Support ARM720T processor" if ARCH_INTEGRATOR_V4_V5
 	select CPU_32v4T
 	select CPU_ABRT_LV4T
 	select CPU_CACHE_V4
@@ -39,7 +39,7 @@ config CPU_ARM720T
 
 # ARM740T
 config CPU_ARM740T
-	bool "Support ARM740T processor" if ARCH_INTEGRATOR
+	bool "Support ARM740T processor" if ARCH_INTEGRATOR_V4_V5
 	depends on !MMU
 	select CPU_32v4T
 	select CPU_ABRT_LV4T
@@ -71,7 +71,7 @@ config CPU_ARM9TDMI
 
 # ARM920T
 config CPU_ARM920T
-	bool "Support ARM920T processor" if ARCH_INTEGRATOR
+	bool "Support ARM920T processor" if ARCH_INTEGRATOR_V4_V5
 	select CPU_32v4T
 	select CPU_ABRT_EV4T
 	select CPU_CACHE_V4WT
@@ -89,7 +89,7 @@ config CPU_ARM920T
 
 # ARM922T
 config CPU_ARM922T
-	bool "Support ARM922T processor" if ARCH_INTEGRATOR
+	bool "Support ARM922T processor" if ARCH_INTEGRATOR_V4_V5
 	select CPU_32v4T
 	select CPU_ABRT_EV4T
 	select CPU_CACHE_V4WT
@@ -127,7 +127,7 @@ config CPU_ARM925T
 
 # ARM926T
 config CPU_ARM926T
-	bool "Support ARM926T processor" if ARCH_INTEGRATOR
+	bool "Support ARM926T processor" if ARCH_INTEGRATOR_V4_V5
 	select CPU_32v5
 	select CPU_ABRT_EV5TJ
 	select CPU_CACHE_VIVT
@@ -163,7 +163,7 @@ config CPU_FA526
 
 # ARM940T
 config CPU_ARM940T
-	bool "Support ARM940T processor" if ARCH_INTEGRATOR
+	bool "Support ARM940T processor" if ARCH_INTEGRATOR_V4_V5
 	depends on !MMU
 	select CPU_32v4T
 	select CPU_ABRT_NOMMU
@@ -181,7 +181,7 @@ config CPU_ARM940T
 
 # ARM946E-S
 config CPU_ARM946E
-	bool "Support ARM946E-S processor" if ARCH_INTEGRATOR
+	bool "Support ARM946E-S processor" if ARCH_INTEGRATOR_V4_V5
 	depends on !MMU
 	select CPU_32v5
 	select CPU_ABRT_NOMMU
@@ -198,7 +198,7 @@ config CPU_ARM946E
 
 # ARM1020 - needs validating
 config CPU_ARM1020
-	bool "Support ARM1020T (rev 0) processor" if ARCH_INTEGRATOR
+	bool "Support ARM1020T (rev 0) processor" if ARCH_INTEGRATOR_V4_V5
 	select CPU_32v5
 	select CPU_ABRT_EV4T
 	select CPU_CACHE_V4WT
@@ -216,7 +216,7 @@ config CPU_ARM1020
 
 # ARM1020E - needs validating
 config CPU_ARM1020E
-	bool "Support ARM1020E processor" if ARCH_INTEGRATOR
+	bool "Support ARM1020E processor" if ARCH_INTEGRATOR_V4_V5
 	depends on n
 	select CPU_32v5
 	select CPU_ABRT_EV4T
@@ -229,7 +229,7 @@ config CPU_ARM1020E
 
 # ARM1022E
 config CPU_ARM1022
-	bool "Support ARM1022E processor" if ARCH_INTEGRATOR
+	bool "Support ARM1022E processor" if ARCH_INTEGRATOR_V4_V5
 	select CPU_32v5
 	select CPU_ABRT_EV4T
 	select CPU_CACHE_VIVT
@@ -247,7 +247,7 @@ config CPU_ARM1022
 
 # ARM1026EJ-S
 config CPU_ARM1026
-	bool "Support ARM1026EJ-S processor" if ARCH_INTEGRATOR
+	bool "Support ARM1026EJ-S processor" if ARCH_INTEGRATOR_V4_V5
 	select CPU_32v5
 	select CPU_ABRT_EV5T # But need Jazelle, but EV5TJ ignores bit 10
 	select CPU_CACHE_VIVT
@@ -358,7 +358,7 @@ config CPU_PJ4B
 
 # ARMv6
 config CPU_V6
-	bool "Support ARM V6 processor" if ARCH_INTEGRATOR
+	bool "Support ARM V6 processor" if ARCH_INTEGRATOR_V6_V7
 	select CPU_32v6
 	select CPU_ABRT_EV6
 	select CPU_CACHE_V6
@@ -371,7 +371,7 @@ config CPU_V6
 
 # ARMv6k
 config CPU_V6K
-	bool "Support ARM V6K processor" if ARCH_INTEGRATOR
+	bool "Support ARM V6K processor" if ARCH_INTEGRATOR_V6_V7
 	select CPU_32v6
 	select CPU_32v6K
 	select CPU_ABRT_EV6
@@ -385,7 +385,7 @@ config CPU_V6K
 
 # ARMv7
 config CPU_V7
-	bool "Support ARM V7 processor" if ARCH_INTEGRATOR
+	bool "Support ARM V7 processor" if ARCH_INTEGRATOR_V6_V7
 	select CPU_32v6K
 	select CPU_32v7
 	select CPU_ABRT_EV7
-- 
1.8.3.2

[PATCH 45/62] ARM: s3c24xx: MINI2440 needs I2C for EEPROM_AT24

[Arnd Bergmann]

If I2C is disabled, we cannot build the AT24 driver, so we
should not select it.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
---
 arch/arm/mach-s3c24xx/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index bb1fa603..a6060d0 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -536,7 +536,7 @@ config MACH_AT2440EVB
 
 config MACH_MINI2440
 	bool "MINI2440 development board"
-	select EEPROM_AT24
+	select EEPROM_AT24 if I2C
 	select LEDS_CLASS
 	select LEDS_TRIGGERS
 	select LEDS_TRIGGER_BACKLIGHT
-- 
1.8.3.2

[PATCH 46/62] ARM: s3c24xx: fix gta02 build error

[Arnd Bergmann]

The gta02 has always been broken in the case when CONFIG_PCF50633_ADC
is not used, since gta02_charger_worker then passes a nonexisting
variable into the pcf50633_mbc_usb_curlim_set() function.

This addresses the obvious typo by using the variable that is
used everywhere else in this file.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
---
 arch/arm/mach-s3c24xx/mach-gta02.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-s3c24xx/mach-gta02.c b/arch/arm/mach-s3c24xx/mach-gta02.c
index 8e05813..dc4db84 100644
--- a/arch/arm/mach-s3c24xx/mach-gta02.c
+++ b/arch/arm/mach-s3c24xx/mach-gta02.c
@@ -196,7 +196,7 @@ static void gta02_charger_worker(struct work_struct *work)
 	 * If the PCF50633 ADC is disabled we fallback to a
 	 * 100mA limit for safety.
 	 */
-	pcf50633_mbc_usb_curlim_set(pcf, 100);
+	pcf50633_mbc_usb_curlim_set(gta02_pcf, 100);
 #endif
 }
 
-- 
1.8.3.2

[PATCH 47/62] ARM: s3c64xx: MACH_SMDK6400 needs HSMMC1

[Arnd Bergmann]

This board uses both MMC controllers, so we need to enable
the Kconfig option to define the platform data.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
---
 arch/arm/mach-s3c64xx/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
index 64f04e6..92885d7 100644
--- a/arch/arm/mach-s3c64xx/Kconfig
+++ b/arch/arm/mach-s3c64xx/Kconfig
@@ -87,6 +87,7 @@ config MACH_SMDK6400
 	select CPU_S3C6400
 	select S3C64XX_SETUP_SDHCI
 	select S3C_DEV_HSMMC
+	select S3C_DEV_HSMMC1
 	select S3C_DEV_NAND
 	help
 	  Machine support for the Samsung SMDK6400
-- 
1.8.3.2

[PATCH 48/62] ARM: s3c64xx: select power domains only when used

[Arnd Bergmann]

The power domain code is only available when CONFIG_PM
is enabled, so we must not select that unconditionally for
s3c64xx. Changing it to 'select PM_GENERIC_DOMAINS if PM'
mirrors what we do on other platforms, and fixes a possible
randconfig build bug.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
---
 arch/arm/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 4721007..6ffcadd 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -764,7 +764,7 @@ config ARCH_S3C64XX
 	select HAVE_TCM
 	select NO_IOPORT
 	select PLAT_SAMSUNG
-	select PM_GENERIC_DOMAINS
+	select PM_GENERIC_DOMAINS if PM
 	select S3C_DEV_NAND
 	select S3C_GPIO_TRACK
 	select SAMSUNG_ATAGS
-- 
1.8.3.2

[PATCH 49/62] ARM: s5p64x0: fix building with only one soc type

[Arnd Bergmann]

The s5p64x0 platform supports two distinct SoCs, s5p6440 and s5p6450,
and in the normal configuration, both are enabled. However if we build
a kernel that only enables one of the two, the #ifdef logic in common.c
breaks down, as some of the functions declared in the header are defined
to NULL using the preprocessor but then defined anyway.

This patch cleans up the mess and ensures that each function has either
exactly one C declaration and one matching C definition, or we have
a NULL defined function pointer but no C definition.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
---
 arch/arm/mach-s5p64x0/common.c | 18 ++++++++++++++++--
 arch/arm/mach-s5p64x0/common.h |  5 +----
 2 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-s5p64x0/common.c b/arch/arm/mach-s5p64x0/common.c
index eb2ad14..9a43be0 100644
--- a/arch/arm/mach-s5p64x0/common.c
+++ b/arch/arm/mach-s5p64x0/common.c
@@ -205,6 +205,7 @@ void __init s5p64x0_init_io(struct map_desc *mach_desc, int size)
 	samsung_pwm_set_platdata(&s5p64x0_pwm_variant);
 }
 
+#ifdef CONFIG_CPU_S5P6440
 void __init s5p6440_map_io(void)
 {
 	/* initialize any device information early */
@@ -218,7 +219,9 @@ void __init s5p6440_map_io(void)
 
 	iotable_init(s5p6440_iodesc, ARRAY_SIZE(s5p6440_iodesc));
 }
+#endif
 
+#ifdef CONFIG_CPU_S5P6450
 void __init s5p6450_map_io(void)
 {
 	/* initialize any device information early */
@@ -232,13 +235,14 @@ void __init s5p6450_map_io(void)
 
 	iotable_init(s5p6450_iodesc, ARRAY_SIZE(s5p6450_iodesc));
 }
+#endif
 
 /*
  * s5p64x0_init_clocks
  *
  * register and setup the CPU clocks
  */
-
+#ifdef CONFIG_CPU_S5P6440
 void __init s5p6440_init_clocks(int xtal)
 {
 	printk(KERN_DEBUG "%s: initializing clocks\n", __func__);
@@ -248,7 +252,9 @@ void __init s5p6440_init_clocks(int xtal)
 	s5p6440_register_clocks();
 	s5p6440_setup_clocks();
 }
+#endif
 
+#ifdef CONFIG_CPU_S5P6450
 void __init s5p6450_init_clocks(int xtal)
 {
 	printk(KERN_DEBUG "%s: initializing clocks\n", __func__);
@@ -258,13 +264,14 @@ void __init s5p6450_init_clocks(int xtal)
 	s5p6450_register_clocks();
 	s5p6450_setup_clocks();
 }
+#endif
 
 /*
  * s5p64x0_init_irq
  *
  * register the CPU interrupts
  */
-
+#ifdef CONFIG_CPU_S5P6440
 void __init s5p6440_init_irq(void)
 {
 	/* S5P6440 supports 2 VIC */
@@ -279,7 +286,9 @@ void __init s5p6440_init_irq(void)
 
 	s5p_init_irq(vic, ARRAY_SIZE(vic));
 }
+#endif
 
+#ifdef CONFIG_CPU_S5P6450
 void __init s5p6450_init_irq(void)
 {
 	/* S5P6450 supports only 2 VIC */
@@ -294,6 +303,7 @@ void __init s5p6450_init_irq(void)
 
 	s5p_init_irq(vic, ARRAY_SIZE(vic));
 }
+#endif
 
 struct bus_type s5p64x0_subsys = {
 	.name		= "s5p64x0-core",
@@ -321,6 +331,7 @@ int __init s5p64x0_init(void)
 }
 
 /* uart registration process */
+#ifdef CONFIG_CPU_S5P6440
 void __init s5p6440_init_uarts(struct s3c2410_uartcfg *cfg, int no)
 {
 	int uart;
@@ -332,11 +343,14 @@ void __init s5p6440_init_uarts(struct s3c2410_uartcfg *cfg, int no)
 
 	s3c24xx_init_uartdevs("s3c6400-uart", s5p_uart_resources, cfg, no);
 }
+#endif
 
+#ifdef CONFIG_CPU_S5P6450
 void __init s5p6450_init_uarts(struct s3c2410_uartcfg *cfg, int no)
 {
 	s3c24xx_init_uartdevs("s3c6400-uart", s5p_uart_resources, cfg, no);
 }
+#endif
 
 #define eint_offset(irq)	((irq) - IRQ_EINT(0))
 
diff --git a/arch/arm/mach-s5p64x0/common.h b/arch/arm/mach-s5p64x0/common.h
index f3a9b43..cbe7f3d 100644
--- a/arch/arm/mach-s5p64x0/common.h
+++ b/arch/arm/mach-s5p64x0/common.h
@@ -25,10 +25,10 @@ void s5p6450_register_clocks(void);
 void s5p6450_setup_clocks(void);
 
 void s5p64x0_restart(enum reboot_mode mode, const char *cmd);
+extern  int s5p64x0_init(void);
 
 #ifdef CONFIG_CPU_S5P6440
 
-extern  int s5p64x0_init(void);
 extern void s5p6440_map_io(void);
 extern void s5p6440_init_clocks(int xtal);
 
@@ -38,12 +38,10 @@ extern void s5p6440_init_uarts(struct s3c2410_uartcfg *cfg, int no);
 #define s5p6440_init_clocks NULL
 #define s5p6440_init_uarts NULL
 #define s5p6440_map_io NULL
-#define s5p64x0_init NULL
 #endif
 
 #ifdef CONFIG_CPU_S5P6450
 
-extern  int s5p64x0_init(void);
 extern void s5p6450_map_io(void);
 extern void s5p6450_init_clocks(int xtal);
 
@@ -53,7 +51,6 @@ extern void s5p6450_init_uarts(struct s3c2410_uartcfg *cfg, int no);
 #define s5p6450_init_clocks NULL
 #define s5p6450_init_uarts NULL
 #define s5p6450_map_io NULL
-#define s5p64x0_init NULL
 #endif
 
 #endif /* __ARCH_ARM_MACH_S5P64X0_COMMON_H */
-- 
1.8.3.2

[PATCH 50/62] ARM: s5pv210: enable IDE support in MACH_TORBRECK

[Arnd Bergmann]

Building MACH_TORBRECK by itself results in a build error
because we try to reference the s3c_device_cfcon definition
that is hidden inside CONFIG_SAMSUNG_DEV_IDE. This changes
the Kconfig logic to ensure that option is enabled when we
need it.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
---
 arch/arm/mach-s5pv210/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-s5pv210/Kconfig b/arch/arm/mach-s5pv210/Kconfig
index caaedaf..8c3abe5 100644
--- a/arch/arm/mach-s5pv210/Kconfig
+++ b/arch/arm/mach-s5pv210/Kconfig
@@ -189,6 +189,7 @@ config MACH_TORBRECK
 	select S5PV210_SETUP_I2C1
 	select S5PV210_SETUP_I2C2
 	select S5PV210_SETUP_SDHCI
+	select SAMSUNG_DEV_IDE
 	help
 	  Machine support for aESOP Torbreck
 
-- 
1.8.3.2

[PATCH 51/62] ARM: samsung: allow serial driver to be disabled

[Arnd Bergmann]

If CONFIG_SERIAL_SAMSUNG is disabled, we run into build errors
with some samsung platforms. This adds a couple of #ifdef
statements to hopefully deal with this more gracefully.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
---
 arch/arm/mach-s3c64xx/irq-pm.c | 12 +++++++++---
 arch/arm/mach-s5p64x0/irq-pm.c |  6 ++++++
 arch/arm/plat-samsung/init.c   |  4 ++++
 3 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-s3c64xx/irq-pm.c b/arch/arm/mach-s3c64xx/irq-pm.c
index a61247b..ae4ea76 100644
--- a/arch/arm/mach-s3c64xx/irq-pm.c
+++ b/arch/arm/mach-s3c64xx/irq-pm.c
@@ -55,7 +55,13 @@ static struct irq_grp_save {
 	u32	mask;
 } eint_grp_save[5];
 
-static u32 irq_uart_mask[CONFIG_SERIAL_SAMSUNG_UARTS];
+#ifndef CONFIG_SERIAL_SAMSUNG_UARTS
+#define SERIAL_SAMSUNG_UARTS 0
+#else
+#define	SERIAL_SAMSUNG_UARTS CONFIG_SERIAL_SAMSUNG_UARTS
+#endif
+
+static u32 irq_uart_mask[SERIAL_SAMSUNG_UARTS];
 
 static int s3c64xx_irq_pm_suspend(void)
 {
@@ -66,7 +72,7 @@ static int s3c64xx_irq_pm_suspend(void)
 
 	s3c_pm_do_save(irq_save, ARRAY_SIZE(irq_save));
 
-	for (i = 0; i < CONFIG_SERIAL_SAMSUNG_UARTS; i++)
+	for (i = 0; i < SERIAL_SAMSUNG_UARTS; i++)
 		irq_uart_mask[i] = __raw_readl(S3C_VA_UARTx(i) + S3C64XX_UINTM);
 
 	for (i = 0; i < ARRAY_SIZE(eint_grp_save); i++, grp++) {
@@ -87,7 +93,7 @@ static void s3c64xx_irq_pm_resume(void)
 
 	s3c_pm_do_restore(irq_save, ARRAY_SIZE(irq_save));
 
-	for (i = 0; i < CONFIG_SERIAL_SAMSUNG_UARTS; i++)
+	for (i = 0; i < SERIAL_SAMSUNG_UARTS; i++)
 		__raw_writel(irq_uart_mask[i], S3C_VA_UARTx(i) + S3C64XX_UINTM);
 
 	for (i = 0; i < ARRAY_SIZE(eint_grp_save); i++, grp++) {
diff --git a/arch/arm/mach-s5p64x0/irq-pm.c b/arch/arm/mach-s5p64x0/irq-pm.c
index 1c83d28..2ed921e 100644
--- a/arch/arm/mach-s5p64x0/irq-pm.c
+++ b/arch/arm/mach-s5p64x0/irq-pm.c
@@ -34,7 +34,9 @@ static struct irq_grp_save {
 	u32	mask;
 } eint_grp_save[4];
 
+#ifdef CONFIG_SERIAL_SAMSUNG
 static u32 irq_uart_mask[CONFIG_SERIAL_SAMSUNG_UARTS];
+#endif
 
 static int s5p64x0_irq_pm_suspend(void)
 {
@@ -45,8 +47,10 @@ static int s5p64x0_irq_pm_suspend(void)
 
 	s3c_pm_do_save(irq_save, ARRAY_SIZE(irq_save));
 
+#ifdef CONFIG_SERIAL_SAMSUNG
 	for (i = 0; i < CONFIG_SERIAL_SAMSUNG_UARTS; i++)
 		irq_uart_mask[i] = __raw_readl(S3C_VA_UARTx(i) + S3C64XX_UINTM);
+#endif
 
 	for (i = 0; i < ARRAY_SIZE(eint_grp_save); i++, grp++) {
 		grp->con = __raw_readl(S5P64X0_EINT12CON + (i * 4));
@@ -66,8 +70,10 @@ static void s5p64x0_irq_pm_resume(void)
 
 	s3c_pm_do_restore(irq_save, ARRAY_SIZE(irq_save));
 
+#ifdef CONFIG_SERIAL_SAMSUNG
 	for (i = 0; i < CONFIG_SERIAL_SAMSUNG_UARTS; i++)
 		__raw_writel(irq_uart_mask[i], S3C_VA_UARTx(i) + S3C64XX_UINTM);
+#endif
 
 	for (i = 0; i < ARRAY_SIZE(eint_grp_save); i++, grp++) {
 		__raw_writel(grp->con, S5P64X0_EINT12CON + (i * 4));
diff --git a/arch/arm/plat-samsung/init.c b/arch/arm/plat-samsung/init.c
index 0ffc84a..c32df1f 100644
--- a/arch/arm/plat-samsung/init.c
+++ b/arch/arm/plat-samsung/init.c
@@ -96,7 +96,9 @@ void __init s3c24xx_init_clocks(int xtal)
 #if IS_ENABLED(CONFIG_SAMSUNG_ATAGS)
 static int nr_uarts __initdata = 0;
 
+#ifdef CONFIG_SERIAL_SAMSUNG_UARTS
 static struct s3c2410_uartcfg uart_cfgs[CONFIG_SERIAL_SAMSUNG_UARTS];
+#endif
 
 /* s3c24xx_init_uartdevs
  *
@@ -111,6 +113,7 @@ void __init s3c24xx_init_uartdevs(char *name,
 				  struct s3c24xx_uart_resources *res,
 				  struct s3c2410_uartcfg *cfg, int no)
 {
+#ifdef CONFIG_SERIAL_SAMSUNG_UARTS
 	struct platform_device *platdev;
 	struct s3c2410_uartcfg *cfgptr = uart_cfgs;
 	struct s3c24xx_uart_resources *resp;
@@ -133,6 +136,7 @@ void __init s3c24xx_init_uartdevs(char *name,
 	}
 
 	nr_uarts = no;
+#endif
 }
 
 void __init s3c24xx_init_uarts(struct s3c2410_uartcfg *cfg, int no)
-- 
1.8.3.2

[PATCH 52/62] ARM: samsung: disable decompressor watchdog on exynos

[Arnd Bergmann]

The S3C_BOOT_ERROR_RESET option only works when using the
samsung specific mach/uncompress.h implementation. The
Exynos platform has now moved on to using the generic
implementation instead, which does not support this.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
---
 arch/arm/plat-samsung/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
index 58645a5..04974db 100644
--- a/arch/arm/plat-samsung/Kconfig
+++ b/arch/arm/plat-samsung/Kconfig
@@ -42,6 +42,7 @@ comment "Boot options"
 
 config S3C_BOOT_ERROR_RESET
 	bool "S3C Reboot on decompression error"
+	depends on PLAT_S5P || PLAT_S3C24XX || ARCH_S3C64XX
 	help
 	  Say y here to use the watchdog to reset the system if the
 	  kernel decompressor detects an error during decompression.
-- 
1.8.3.2

[PATCH 53/62] ARM: samsung: fix SAMSUNG_PM_DEBUG Kconfig logic

[Arnd Bergmann]

The suspend debug code for Samsung has multiple dependencies
that we should not unconditionally enable. In particular,
we rely on the DEBUG_S3C_UART setting, which in turn depends
on the samsung UART driver.

Signed-off-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
---
 arch/arm/plat-samsung/Kconfig | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
index 04974db..c72d612 100644
--- a/arch/arm/plat-samsung/Kconfig
+++ b/arch/arm/plat-samsung/Kconfig
@@ -428,8 +428,7 @@ comment "Power management"
 
 config SAMSUNG_PM_DEBUG
 	bool "S3C2410 PM Suspend debug"
-	depends on PM
-	select DEBUG_LL
+	depends on PM && DEBUG_KERNEL && DEBUG_S3C_UART
 	help
 	  Say Y here if you want verbose debugging from the PM Suspend and
 	  Resume code. See <file:Documentation/arm/Samsung-S3C24XX/Suspend.txt>
-- 
1.8.3.2

[PATCH 54/62] ARM: samsung: select ATAGS where necessary

[Arnd Bergmann]

Most of the Samsung platforms do not yet allow building with
DT at all, so we should select CONFIG_ATAGS for now in all
cases we also select CONFIG_SAMSUNG_ATAGS.

Found during randconfig testing.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
---
 arch/arm/Kconfig | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 6ffcadd..3fb9b7e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -731,6 +731,7 @@ config ARCH_S3C24XX
 	bool "Samsung S3C24XX SoCs"
 	select ARCH_HAS_CPUFREQ
 	select ARCH_REQUIRE_GPIOLIB
+	select ATAGS
 	select CLKDEV_LOOKUP
 	select CLKSRC_SAMSUNG_PWM
 	select GENERIC_CLOCKEVENTS
@@ -753,6 +754,7 @@ config ARCH_S3C64XX
 	select ARCH_REQUIRE_GPIOLIB
 	select ARM_AMBA
 	select ARM_VIC
+	select ATAGS
 	select CLKDEV_LOOKUP
 	select CLKSRC_SAMSUNG_PWM
 	select COMMON_CLK
@@ -776,6 +778,7 @@ config ARCH_S3C64XX
 
 config ARCH_S5P64X0
 	bool "Samsung S5P6440 S5P6450"
+	select ATAGS
 	select CLKDEV_LOOKUP
 	select CLKSRC_SAMSUNG_PWM
 	select CPU_V6
@@ -794,6 +797,7 @@ config ARCH_S5P64X0
 config ARCH_S5PC100
 	bool "Samsung S5PC100"
 	select ARCH_REQUIRE_GPIOLIB
+	select ATAGS
 	select CLKDEV_LOOKUP
 	select CLKSRC_SAMSUNG_PWM
 	select CPU_V7
@@ -813,6 +817,7 @@ config ARCH_S5PV210
 	select ARCH_HAS_CPUFREQ
 	select ARCH_HAS_HOLES_MEMORYMODEL
 	select ARCH_SPARSEMEM_ENABLE
+	select ATAGS
 	select CLKDEV_LOOKUP
 	select CLKSRC_SAMSUNG_PWM
 	select CPU_V7
-- 
1.8.3.2

[PATCH 55/62] ARM: samsung: select CRC32 for SAMSUNG_PM_CHECK

[Arnd Bergmann]

The Samsung pm_check code uses the crc32 library code, which can
be built as a loadable module, in which case we get a link error
building the kernel.

A better solution is to use 'select CRC32', which is what all
other users of this code do, as it ensures it is always built-in.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
---
 arch/arm/plat-samsung/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
index c72d612..98f223c 100644
--- a/arch/arm/plat-samsung/Kconfig
+++ b/arch/arm/plat-samsung/Kconfig
@@ -445,7 +445,8 @@ config S3C_PM_DEBUG_LED_SMDK
 
 config SAMSUNG_PM_CHECK
 	bool "S3C2410 PM Suspend Memory CRC"
-	depends on PM && CRC32
+	depends on PM
+	select CRC32
 	help
 	  Enable the PM code's memory area checksum over sleep. This option
 	  will generate CRCs of all blocks of memory, and store them before
-- 
1.8.3.2

[PATCH 56/62] ARM: samsung: select I2C where needed for PMIC

[Arnd Bergmann]

The OSIRIS machine cannot build without I2C and
TPS65010 both enabled unconditionally.

The SMDK6410_WM1190_EV1 and SMDK6410_WM1192_EV1 add-on
cards already select MFD_WM*_I2C.

In each case, failing to enable CONFIG_I2C results in a
build or link error, so most consistent solution is to
ensure that it is impossible to disable those options.

It would be nice to leave CONFIG_I2C as user-selectable,
but doing that properly would require more work.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
---
 arch/arm/mach-s3c24xx/Kconfig | 1 +
 arch/arm/mach-s3c64xx/Kconfig | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index a6060d0..1272647 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -572,6 +572,7 @@ config MACH_OSIRIS_DVS
 	tristate "Simtec IM2440D20 (OSIRIS) Dynamic Voltage Scaling driver"
 	depends on MACH_OSIRIS
 	select TPS65010
+	select I2C
 	help
 	  Say Y/M here if you want to have dynamic voltage scaling support
 	  on the Simtec IM2440D20 (OSIRIS) module via the TPS65011.
diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
index 92885d7..0148112 100644
--- a/arch/arm/mach-s3c64xx/Kconfig
+++ b/arch/arm/mach-s3c64xx/Kconfig
@@ -191,6 +191,7 @@ endchoice
 config SMDK6410_WM1190_EV1
 	bool "Support Wolfson Microelectronics 1190-EV1 PMIC card"
 	depends on MACH_SMDK6410
+	select I2C
 	select MFD_WM8350_I2C
 	select REGULATOR
 	select REGULATOR_WM8350
@@ -205,6 +206,7 @@ config SMDK6410_WM1190_EV1
 config SMDK6410_WM1192_EV1
 	bool "Support Wolfson Microelectronics 1192-EV1 PMIC card"
 	depends on MACH_SMDK6410
+	select I2C
 	select MFD_WM831X
 	select MFD_WM831X_I2C
 	select REGULATOR
-- 
1.8.3.2

[PATCH 57/62] ARM: exynos: fix l2x0 saved regs handling

[Arnd Bergmann]

The exynos4_l2x0_cache_init function tries to flush the data cache
for the location of the saved l2x0 registers and pass the physical
address to the s5p-sleep implementation.

However, the s5p-sleep code is optional, and if it is disabled,
we get a linker error here when the l2x0_regs_phys variable does
not exist.

To solve this, use a compile-time conditional to drop this code
if we don't want it.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
---
 arch/arm/mach-exynos/common.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index 025fd82..b2f9bb0 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -404,8 +404,10 @@ static int __init exynos4_l2x0_cache_init(void)
 	if (ret)
 		return ret;
 
-	l2x0_regs_phys = virt_to_phys(&l2x0_saved_regs);
-	clean_dcache_area(&l2x0_regs_phys, sizeof(unsigned long));
+	if (IS_ENABLED(CONFIG_S5P_SLEEP)) {
+		l2x0_regs_phys = virt_to_phys(&l2x0_saved_regs);
+		clean_dcache_area(&l2x0_regs_phys, sizeof(unsigned long));
+	}
 	return 0;
 }
 early_initcall(exynos4_l2x0_cache_init);
-- 
1.8.3.2

[PATCH 58/62] ARM: exynos: add missing include of linux/module.h

[Arnd Bergmann]

After the restructuring of the module.h and init.h headers,
we now need to include this explicitly here.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
---
 arch/arm/mach-exynos/cpuidle.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-exynos/cpuidle.c
index f57cb91..93d2dec 100644
--- a/arch/arm/mach-exynos/cpuidle.c
+++ b/arch/arm/mach-exynos/cpuidle.c
@@ -14,6 +14,7 @@
 #include <linux/cpu_pm.h>
 #include <linux/io.h>
 #include <linux/export.h>
+#include <linux/module.h>
 #include <linux/time.h>
 #include <linux/platform_device.h>
 
-- 
1.8.3.2

[PATCH 59/62] ARM: shmobile: ak4642 needs i2c support

[Arnd Bergmann]

We cannot select SND_SOC_AK4642 if the I2C core layer
is disabled. Making the select statement conditional
ensures that we can build all configurations.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Simon Horman <horms@verge.net.au>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: linux-sh@vger.kernel.org
---
 arch/arm/mach-shmobile/Kconfig | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 5249ff0..6e3904e 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -170,7 +170,7 @@ config MACH_MACKEREL
 	select ARCH_REQUIRE_GPIOLIB
 	select REGULATOR_FIXED_VOLTAGE if REGULATOR
 	select SMSC_PHY if SMSC911X
-	select SND_SOC_AK4642 if SND_SIMPLE_CARD
+	select SND_SOC_AK4642 if SND_SIMPLE_CARD && I2C=y
 	select USE_OF
 
 config MACH_ARMADILLO800EVA
@@ -179,7 +179,7 @@ config MACH_ARMADILLO800EVA
 	select ARCH_REQUIRE_GPIOLIB
 	select REGULATOR_FIXED_VOLTAGE if REGULATOR
 	select SMSC_PHY if SH_ETH
-	select SND_SOC_WM8978 if SND_SIMPLE_CARD
+	select SND_SOC_WM8978 if SND_SIMPLE_CARD && I2C=y
 	select USE_OF
 
 config MACH_ARMADILLO800EVA_REFERENCE
@@ -188,7 +188,7 @@ config MACH_ARMADILLO800EVA_REFERENCE
 	select ARCH_REQUIRE_GPIOLIB
 	select REGULATOR_FIXED_VOLTAGE if REGULATOR
 	select SMSC_PHY if SH_ETH
-	select SND_SOC_WM8978 if SND_SIMPLE_CARD
+	select SND_SOC_WM8978 if SND_SIMPLE_CARD && I2C=y
 	select USE_OF
 	---help---
 	   Use reference implementation of Aramdillo800 EVA board support
@@ -204,7 +204,7 @@ config MACH_BOCKW
 	select REGULATOR_FIXED_VOLTAGE if REGULATOR
 	select RENESAS_INTC_IRQPIN
 	select SND_SOC_AK4554 if SND_SIMPLE_CARD
-	select SND_SOC_AK4642 if SND_SIMPLE_CARD
+	select SND_SOC_AK4642 if SND_SIMPLE_CARD && I2C=y
 	select USE_OF
 
 config MACH_BOCKW_REFERENCE
@@ -277,7 +277,7 @@ config MACH_KZM9G
 	select ARCH_HAS_OPP
 	select ARCH_REQUIRE_GPIOLIB
 	select REGULATOR_FIXED_VOLTAGE if REGULATOR
-	select SND_SOC_AK4642 if SND_SIMPLE_CARD
+	select SND_SOC_AK4642 if SND_SIMPLE_CARD && I2C=y
 	select USE_OF
 
 config MACH_KZM9G_REFERENCE
@@ -285,7 +285,7 @@ config MACH_KZM9G_REFERENCE
 	depends on ARCH_SH73A0
 	select ARCH_REQUIRE_GPIOLIB
 	select REGULATOR_FIXED_VOLTAGE if REGULATOR
-	select SND_SOC_AK4642 if SND_SIMPLE_CARD
+	select SND_SOC_AK4642 if SND_SIMPLE_CARD && I2C=y
 	select USE_OF
 	---help---
 	   Use reference implementation of KZM-A9-GT board support
-- 
1.8.3.2

[PATCH 59/62] ARM: shmobile: ak4642 needs i2c support

[Arnd Bergmann]

We cannot select SND_SOC_AK4642 if the I2C core layer
is disabled. Making the select statement conditional
ensures that we can build all configurations.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Simon Horman <horms@verge.net.au>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: linux-sh at vger.kernel.org
---
 arch/arm/mach-shmobile/Kconfig | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 5249ff0..6e3904e 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -170,7 +170,7 @@ config MACH_MACKEREL
 	select ARCH_REQUIRE_GPIOLIB
 	select REGULATOR_FIXED_VOLTAGE if REGULATOR
 	select SMSC_PHY if SMSC911X
-	select SND_SOC_AK4642 if SND_SIMPLE_CARD
+	select SND_SOC_AK4642 if SND_SIMPLE_CARD && I2C=y
 	select USE_OF
 
 config MACH_ARMADILLO800EVA
@@ -179,7 +179,7 @@ config MACH_ARMADILLO800EVA
 	select ARCH_REQUIRE_GPIOLIB
 	select REGULATOR_FIXED_VOLTAGE if REGULATOR
 	select SMSC_PHY if SH_ETH
-	select SND_SOC_WM8978 if SND_SIMPLE_CARD
+	select SND_SOC_WM8978 if SND_SIMPLE_CARD && I2C=y
 	select USE_OF
 
 config MACH_ARMADILLO800EVA_REFERENCE
@@ -188,7 +188,7 @@ config MACH_ARMADILLO800EVA_REFERENCE
 	select ARCH_REQUIRE_GPIOLIB
 	select REGULATOR_FIXED_VOLTAGE if REGULATOR
 	select SMSC_PHY if SH_ETH
-	select SND_SOC_WM8978 if SND_SIMPLE_CARD
+	select SND_SOC_WM8978 if SND_SIMPLE_CARD && I2C=y
 	select USE_OF
 	---help---
 	   Use reference implementation of Aramdillo800 EVA board support
@@ -204,7 +204,7 @@ config MACH_BOCKW
 	select REGULATOR_FIXED_VOLTAGE if REGULATOR
 	select RENESAS_INTC_IRQPIN
 	select SND_SOC_AK4554 if SND_SIMPLE_CARD
-	select SND_SOC_AK4642 if SND_SIMPLE_CARD
+	select SND_SOC_AK4642 if SND_SIMPLE_CARD && I2C=y
 	select USE_OF
 
 config MACH_BOCKW_REFERENCE
@@ -277,7 +277,7 @@ config MACH_KZM9G
 	select ARCH_HAS_OPP
 	select ARCH_REQUIRE_GPIOLIB
 	select REGULATOR_FIXED_VOLTAGE if REGULATOR
-	select SND_SOC_AK4642 if SND_SIMPLE_CARD
+	select SND_SOC_AK4642 if SND_SIMPLE_CARD && I2C=y
 	select USE_OF
 
 config MACH_KZM9G_REFERENCE
@@ -285,7 +285,7 @@ config MACH_KZM9G_REFERENCE
 	depends on ARCH_SH73A0
 	select ARCH_REQUIRE_GPIOLIB
 	select REGULATOR_FIXED_VOLTAGE if REGULATOR
-	select SND_SOC_AK4642 if SND_SIMPLE_CARD
+	select SND_SOC_AK4642 if SND_SIMPLE_CARD && I2C=y
 	select USE_OF
 	---help---
 	   Use reference implementation of KZM-A9-GT board support
-- 
1.8.3.2

[PATCH 60/62] ARM: shmobile: work around CONFIG_PHYLIB=m

[Arnd Bergmann]

When phylib is set to be built as a module, the lager and koelsch
boards fail to build:

arch/arm/mach-shmobile/built-in.o: In function `lager_ksz8041_fixup':
:(.text+0x738): undefined reference to `mdiobus_read'
:(.text+0x73c): undefined reference to `mdiobus_write'
arch/arm/mach-shmobile/built-in.o: In function `koelsch_ksz8041_fixup':
:(.text+0x7e8): undefined reference to `mdiobus_read'
:(.text+0x7ec): undefined reference to `mdiobus_write'

To work around that problem, this changes the code to check for
IS_BUILTIN rather than IS_ENABLED, turning the error into a runtime
problem. It's now possible to build random configurations, but the
phy may be set up incorrectly in this case.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Simon Horman <horms@verge.net.au>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: linux-sh@vger.kernel.org
---
 arch/arm/mach-shmobile/board-koelsch.c | 2 +-
 arch/arm/mach-shmobile/board-lager.c   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-shmobile/board-koelsch.c b/arch/arm/mach-shmobile/board-koelsch.c
index 5a034ff..b724f33 100644
--- a/arch/arm/mach-shmobile/board-koelsch.c
+++ b/arch/arm/mach-shmobile/board-koelsch.c
@@ -510,7 +510,7 @@ static void __init koelsch_init(void)
 
 	irq_set_irq_type(irq_pin(0), IRQ_TYPE_LEVEL_LOW);
 
-	if (IS_ENABLED(CONFIG_PHYLIB))
+	if (IS_BUILTIN(CONFIG_PHYLIB))
 		phy_register_fixup_for_id("r8a7791-ether-ff:01",
 					  koelsch_ksz8041_fixup);
 }
diff --git a/arch/arm/mach-shmobile/board-lager.c b/arch/arm/mach-shmobile/board-lager.c
index f0104bf..67b1069 100644
--- a/arch/arm/mach-shmobile/board-lager.c
+++ b/arch/arm/mach-shmobile/board-lager.c
@@ -869,7 +869,7 @@ static void __init lager_init(void)
 
 	irq_set_irq_type(irq_pin(0), IRQ_TYPE_LEVEL_LOW);
 
-	if (IS_ENABLED(CONFIG_PHYLIB))
+	if (IS_BUILTIN(CONFIG_PHYLIB))
 		phy_register_fixup_for_id("r8a7790-ether-ff:01",
 					  lager_ksz8041_fixup);
 }
-- 
1.8.3.2

[PATCH 60/62] ARM: shmobile: work around CONFIG_PHYLIB=m

[Arnd Bergmann]

When phylib is set to be built as a module, the lager and koelsch
boards fail to build:

arch/arm/mach-shmobile/built-in.o: In function `lager_ksz8041_fixup':
:(.text+0x738): undefined reference to `mdiobus_read'
:(.text+0x73c): undefined reference to `mdiobus_write'
arch/arm/mach-shmobile/built-in.o: In function `koelsch_ksz8041_fixup':
:(.text+0x7e8): undefined reference to `mdiobus_read'
:(.text+0x7ec): undefined reference to `mdiobus_write'

To work around that problem, this changes the code to check for
IS_BUILTIN rather than IS_ENABLED, turning the error into a runtime
problem. It's now possible to build random configurations, but the
phy may be set up incorrectly in this case.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Simon Horman <horms@verge.net.au>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: linux-sh at vger.kernel.org
---
 arch/arm/mach-shmobile/board-koelsch.c | 2 +-
 arch/arm/mach-shmobile/board-lager.c   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-shmobile/board-koelsch.c b/arch/arm/mach-shmobile/board-koelsch.c
index 5a034ff..b724f33 100644
--- a/arch/arm/mach-shmobile/board-koelsch.c
+++ b/arch/arm/mach-shmobile/board-koelsch.c
@@ -510,7 +510,7 @@ static void __init koelsch_init(void)
 
 	irq_set_irq_type(irq_pin(0), IRQ_TYPE_LEVEL_LOW);
 
-	if (IS_ENABLED(CONFIG_PHYLIB))
+	if (IS_BUILTIN(CONFIG_PHYLIB))
 		phy_register_fixup_for_id("r8a7791-ether-ff:01",
 					  koelsch_ksz8041_fixup);
 }
diff --git a/arch/arm/mach-shmobile/board-lager.c b/arch/arm/mach-shmobile/board-lager.c
index f0104bf..67b1069 100644
--- a/arch/arm/mach-shmobile/board-lager.c
+++ b/arch/arm/mach-shmobile/board-lager.c
@@ -869,7 +869,7 @@ static void __init lager_init(void)
 
 	irq_set_irq_type(irq_pin(0), IRQ_TYPE_LEVEL_LOW);
 
-	if (IS_ENABLED(CONFIG_PHYLIB))
+	if (IS_BUILTIN(CONFIG_PHYLIB))
 		phy_register_fixup_for_id("r8a7790-ether-ff:01",
 					  lager_ksz8041_fixup);
 }
-- 
1.8.3.2

[PATCH 61/62] ARM: sunxi: fix build for THUMB2_KERNEL

[Arnd Bergmann]

Building an SMP kernel for the sunxi platform with THUMB2 instructions
fails with this error at the moment:

headsmp.S:7: Error: Thumb encoding does not support an immediate here -- `msr cpsr_fsxc,#0xd3'

This changes the code to use a register for loading the
value instead, which works in both ARM and THUMB mode.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 arch/arm/mach-sunxi/headsmp.S | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-sunxi/headsmp.S b/arch/arm/mach-sunxi/headsmp.S
index a10d494..a8e0fef 100644
--- a/arch/arm/mach-sunxi/headsmp.S
+++ b/arch/arm/mach-sunxi/headsmp.S
@@ -4,6 +4,7 @@
         .section ".text.head", "ax"
 
 ENTRY(sun6i_secondary_startup)
-	msr	cpsr_fsxc, #0xd3
+	mov	r0, #0xd3
+	msr	cpsr_fsxc, r0
 	b	secondary_startup
 ENDPROC(sun6i_secondary_startup)
-- 
1.8.3.2

[PATCH 62/62] ARM: tegra: make debug_ll code build for ARMv6

[Arnd Bergmann]

In a combined ARMv6/v7 kernel, we cannot use the
movt/movw instructions to load an immediate, as they
are not valid on ARMv6.

This changes the file to use an indirect load instead,
as lots of other implementations do.

Signed-off-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Cc: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
Cc: Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
---
 arch/arm/include/debug/tegra.S | 18 ++++++++----------
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/arch/arm/include/debug/tegra.S b/arch/arm/include/debug/tegra.S
index f98763f..3bc8059 100644
--- a/arch/arm/include/debug/tegra.S
+++ b/arch/arm/include/debug/tegra.S
@@ -53,8 +53,7 @@
 
 #define checkuart(rp, rv, lhu, bit, uart) \
 		/* Load address of CLK_RST register */ \
-		movw	rp, #TEGRA_CLK_RST_DEVICES_##lhu & 0xffff ; \
-		movt	rp, #TEGRA_CLK_RST_DEVICES_##lhu >> 16 ; \
+		ldr	rp, =TEGRA_CLK_RST_DEVICES_##lhu ; \
 		/* Load value from CLK_RST register */ \
 		ldr	rp, [rp, #0] ; \
 		/* Test UART's reset bit */ \
@@ -62,8 +61,7 @@
 		/* If set, can't use UART; jump to save no UART */ \
 		bne	90f ; \
 		/* Load address of CLK_OUT_ENB register */ \
-		movw	rp, #TEGRA_CLK_OUT_ENB_##lhu & 0xffff ; \
-		movt	rp, #TEGRA_CLK_OUT_ENB_##lhu >> 16 ; \
+		ldr	rp, =TEGRA_CLK_OUT_ENB_##lhu ; \
 		/* Load value from CLK_OUT_ENB register */ \
 		ldr	rp, [rp, #0] ; \
 		/* Test UART's clock enable bit */ \
@@ -71,8 +69,7 @@
 		/* If clear, can't use UART; jump to save no UART */ \
 		beq	90f ; \
 		/* Passed all tests, load address of UART registers */ \
-		movw	rp, #TEGRA_UART##uart##_BASE & 0xffff ; \
-		movt	rp, #TEGRA_UART##uart##_BASE >> 16 ; \
+		ldr	rp, =TEGRA_UART##uart##_BASE ; \
 		/* Jump to save UART address */ \
 		b 91f
 
@@ -90,15 +87,16 @@
 
 #ifdef CONFIG_TEGRA_DEBUG_UART_AUTO_ODMDATA
 		/* Check ODMDATA */
-10:		movw	\rp, #TEGRA_PMC_SCRATCH20 & 0xffff
-		movt	\rp, #TEGRA_PMC_SCRATCH20 >> 16
+10:		ldr	\rp, =TEGRA_PMC_SCRATCH20
 		ldr	\rp, [\rp, #0]		@ Load PMC_SCRATCH20
-		ubfx	\rv, \rp, #18, #2	@ 19:18 are console type
+		lsr	\rv, \rp, #18		@ 19:18 are console type
+		and	\rv, \rv, #3
 		cmp	\rv, #2			@ 2 and 3 mean DCC, UART
 		beq	11f			@ some boards swap the meaning
 		cmp	\rv, #3			@ so accept either
 		bne	90f
-11:		ubfx	\rv, \rp, #15, #3	@ 17:15 are UART ID
+11:		lsr	\rv, \rp, #15		@ 17:15 are UART ID
+		and	\rv, #7	
 		cmp	\rv, #0			@ UART 0?
 		beq	20f
 		cmp	\rv, #1			@ UART 1?
-- 
1.8.3.2

[PATCH 62/62] ARM: tegra: make debug_ll code build for ARMv6

[Arnd Bergmann]

In a combined ARMv6/v7 kernel, we cannot use the
movt/movw instructions to load an immediate, as they
are not valid on ARMv6.

This changes the file to use an indirect load instead,
as lots of other implementations do.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: linux-tegra at vger.kernel.org
---
 arch/arm/include/debug/tegra.S | 18 ++++++++----------
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/arch/arm/include/debug/tegra.S b/arch/arm/include/debug/tegra.S
index f98763f..3bc8059 100644
--- a/arch/arm/include/debug/tegra.S
+++ b/arch/arm/include/debug/tegra.S
@@ -53,8 +53,7 @@
 
 #define checkuart(rp, rv, lhu, bit, uart) \
 		/* Load address of CLK_RST register */ \
-		movw	rp, #TEGRA_CLK_RST_DEVICES_##lhu & 0xffff ; \
-		movt	rp, #TEGRA_CLK_RST_DEVICES_##lhu >> 16 ; \
+		ldr	rp, =TEGRA_CLK_RST_DEVICES_##lhu ; \
 		/* Load value from CLK_RST register */ \
 		ldr	rp, [rp, #0] ; \
 		/* Test UART's reset bit */ \
@@ -62,8 +61,7 @@
 		/* If set, can't use UART; jump to save no UART */ \
 		bne	90f ; \
 		/* Load address of CLK_OUT_ENB register */ \
-		movw	rp, #TEGRA_CLK_OUT_ENB_##lhu & 0xffff ; \
-		movt	rp, #TEGRA_CLK_OUT_ENB_##lhu >> 16 ; \
+		ldr	rp, =TEGRA_CLK_OUT_ENB_##lhu ; \
 		/* Load value from CLK_OUT_ENB register */ \
 		ldr	rp, [rp, #0] ; \
 		/* Test UART's clock enable bit */ \
@@ -71,8 +69,7 @@
 		/* If clear, can't use UART; jump to save no UART */ \
 		beq	90f ; \
 		/* Passed all tests, load address of UART registers */ \
-		movw	rp, #TEGRA_UART##uart##_BASE & 0xffff ; \
-		movt	rp, #TEGRA_UART##uart##_BASE >> 16 ; \
+		ldr	rp, =TEGRA_UART##uart##_BASE ; \
 		/* Jump to save UART address */ \
 		b 91f
 
@@ -90,15 +87,16 @@
 
 #ifdef CONFIG_TEGRA_DEBUG_UART_AUTO_ODMDATA
 		/* Check ODMDATA */
-10:		movw	\rp, #TEGRA_PMC_SCRATCH20 & 0xffff
-		movt	\rp, #TEGRA_PMC_SCRATCH20 >> 16
+10:		ldr	\rp, =TEGRA_PMC_SCRATCH20
 		ldr	\rp, [\rp, #0]		@ Load PMC_SCRATCH20
-		ubfx	\rv, \rp, #18, #2	@ 19:18 are console type
+		lsr	\rv, \rp, #18		@ 19:18 are console type
+		and	\rv, \rv, #3
 		cmp	\rv, #2			@ 2 and 3 mean DCC, UART
 		beq	11f			@ some boards swap the meaning
 		cmp	\rv, #3			@ so accept either
 		bne	90f
-11:		ubfx	\rv, \rp, #15, #3	@ 17:15 are UART ID
+11:		lsr	\rv, \rp, #15		@ 17:15 are UART ID
+		and	\rv, #7	
 		cmp	\rv, #0			@ UART 0?
 		beq	20f
 		cmp	\rv, #1			@ UART 1?
-- 
1.8.3.2

[PATCH 25/62] ARM: mvebu: add missing header

[Jason Cooper]

On Wed, Mar 19, 2014 at 08:29:22PM +0100, Arnd Bergmann wrote:
> The definition for SIGBUS may not be visible without including
> linux/signal.h, as I found during randconfig testing.
> 
> Adding an explicit include is certainly the right thing to do.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Gregory Clement <gregory.clement@free-electrons.com>
> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> ---
>  arch/arm/mach-mvebu/board-v7.c | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Jason Cooper <jason@lakedaemon.net>

thx,

Jason.

[PATCH 26/62] ARM: mvebu: don't select CONFIG_NEON

[Jason Cooper]

On Wed, Mar 19, 2014 at 08:29:23PM +0100, Arnd Bergmann wrote:
> CONFIG_NEON is meant to be user-selectable. Turning it on
> unconditionally means we can't build a smaller kernel when
> we don't need it, and causes build errors if CONFIG_VFP
> is not also enabled.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Gregory Clement <gregory.clement@free-electrons.com>
> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> ---
>  arch/arm/mach-mvebu/Kconfig | 2 --
>  1 file changed, 2 deletions(-)

Acked-by: Jason Cooper <jason@lakedaemon.net>

Gregory, Thomas, Ezequiel,

Care to spin a patch adding NEON to mvebu_v7_defconfig?  (If you want
it)

thx,

Jason.

[PATCH 27/62] ARM: orion5x: make dns323 independent of PHY support

[Jason Cooper]

On Wed, Mar 19, 2014 at 08:29:24PM +0100, Arnd Bergmann wrote:
> The D-Link DNS-323 machine tries to unconditionally select CONFIG_PHYLIB,
> but that has other dependencies that might not necessarily be enabled,
> causing random build errors.
> 
> To work around this, this patch removes the 'select' statement and
> instead uses a compile-time check to skip the phy_register_fixup_for_uid()
> call if PHYLIB is not available in the kernel.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Gregory Clement <gregory.clement@free-electrons.com>
> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> ---
>  arch/arm/mach-orion5x/Kconfig        | 1 -
>  arch/arm/mach-orion5x/dns323-setup.c | 2 ++
>  2 files changed, 2 insertions(+), 1 deletion(-)

Acked-by: Jason Cooper <jason@lakedaemon.net>

thx,

Jason.

Re: [PATCH 62/62] ARM: tegra: make debug_ll code build for ARMv6

[Stephen Warren]

On 03/19/2014 01:29 PM, Arnd Bergmann wrote:
> In a combined ARMv6/v7 kernel, we cannot use the
> movt/movw instructions to load an immediate, as they
> are not valid on ARMv6.
> 
> This changes the file to use an indirect load instead,
> as lots of other implementations do.

Hmmm. This code is guaranteed to only execute on Tegra (well, perhaps
someone can turn on the wrong debug option and run it on non-Tegra, but
then it's guaranteed not to work since the HW it touches doesn't exist).
As such, the code ought to be able to use ARMv7 instructions.

As a fix for similar issues in assembly code in arch/arm/mach-tegra/*.S,
Makefile there does:

asflags-y                               += -march=armv7-a

(I think you added that? Yes, in 408e713545ca "ARM: tegra: build
assembly files with -march=armv7-a")

Shouldn't we use the same fix in this case too?

[PATCH 62/62] ARM: tegra: make debug_ll code build for ARMv6

[Stephen Warren]

On 03/19/2014 01:29 PM, Arnd Bergmann wrote:
> In a combined ARMv6/v7 kernel, we cannot use the
> movt/movw instructions to load an immediate, as they
> are not valid on ARMv6.
> 
> This changes the file to use an indirect load instead,
> as lots of other implementations do.

Hmmm. This code is guaranteed to only execute on Tegra (well, perhaps
someone can turn on the wrong debug option and run it on non-Tegra, but
then it's guaranteed not to work since the HW it touches doesn't exist).
As such, the code ought to be able to use ARMv7 instructions.

As a fix for similar issues in assembly code in arch/arm/mach-tegra/*.S,
Makefile there does:

asflags-y                               += -march=armv7-a

(I think you added that? Yes, in 408e713545ca "ARM: tegra: build
assembly files with -march=armv7-a")

Shouldn't we use the same fix in this case too?

Re: [PATCH 59/62] ARM: shmobile: ak4642 needs i2c support

[Sergei Shtylyov]

Hello.

On 03/19/2014 10:29 PM, Arnd Bergmann wrote:

> We cannot select SND_SOC_AK4642 if the I2C core layer
> is disabled. Making the select statement conditional
> ensures that we can build all configurations.

    Yes, but you also touch WM8978 selects. Is it the same as AK4642 or you 
just forgot to mention that?

> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Simon Horman <horms@verge.net.au>
> Cc: Magnus Damm <magnus.damm@gmail.com>
> Cc: linux-sh@vger.kernel.org
> ---
>   arch/arm/mach-shmobile/Kconfig | 12 ++++++------
>   1 file changed, 6 insertions(+), 6 deletions(-)

> diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
> index 5249ff0..6e3904e 100644
> --- a/arch/arm/mach-shmobile/Kconfig
> +++ b/arch/arm/mach-shmobile/Kconfig
> @@ -170,7 +170,7 @@ config MACH_MACKEREL
>   	select ARCH_REQUIRE_GPIOLIB
>   	select REGULATOR_FIXED_VOLTAGE if REGULATOR
>   	select SMSC_PHY if SMSC911X
> -	select SND_SOC_AK4642 if SND_SIMPLE_CARD
> +	select SND_SOC_AK4642 if SND_SIMPLE_CARD && I2C=y
>   	select USE_OF
>
>   config MACH_ARMADILLO800EVA
> @@ -179,7 +179,7 @@ config MACH_ARMADILLO800EVA
>   	select ARCH_REQUIRE_GPIOLIB
>   	select REGULATOR_FIXED_VOLTAGE if REGULATOR
>   	select SMSC_PHY if SH_ETH
> -	select SND_SOC_WM8978 if SND_SIMPLE_CARD
> +	select SND_SOC_WM8978 if SND_SIMPLE_CARD && I2C=y
>   	select USE_OF
>
>   config MACH_ARMADILLO800EVA_REFERENCE
> @@ -188,7 +188,7 @@ config MACH_ARMADILLO800EVA_REFERENCE
>   	select ARCH_REQUIRE_GPIOLIB
>   	select REGULATOR_FIXED_VOLTAGE if REGULATOR
>   	select SMSC_PHY if SH_ETH
> -	select SND_SOC_WM8978 if SND_SIMPLE_CARD
> +	select SND_SOC_WM8978 if SND_SIMPLE_CARD && I2C=y
>   	select USE_OF
>   	---help---
>   	   Use reference implementation of Aramdillo800 EVA board support
[...]

WBR, Sergei

Re: [PATCH 62/62] ARM: tegra: make debug_ll code build for ARMv6

[Arnd Bergmann]

On Wednesday 19 March 2014 13:40:06 Stephen Warren wrote:
> Hmmm. This code is guaranteed to only execute on Tegra (well, perhaps
> someone can turn on the wrong debug option and run it on non-Tegra, but
> then it's guaranteed not to work since the HW it touches doesn't exist).
> As such, the code ought to be able to use ARMv7 instructions.
> 
> As a fix for similar issues in assembly code in arch/arm/mach-tegra/*.S,
> Makefile there does:
> 
> asflags-y                               += -march=armv7-a
> 
> (I think you added that? Yes, in 408e713545ca "ARM: tegra: build
> assembly files with -march=armv7-a")
> 
> Shouldn't we use the same fix in this case too?

That was my first idea, but I couldn't come up with a nice way to do this
for arch/arm/kernel/debug.S, which #includes the specific implementation.

I'd rather not put lots of per-platform hacks into arch/arm/kernel/Makefile.

	Arnd

[PATCH 62/62] ARM: tegra: make debug_ll code build for ARMv6

[Arnd Bergmann]

On Wednesday 19 March 2014 13:40:06 Stephen Warren wrote:
> Hmmm. This code is guaranteed to only execute on Tegra (well, perhaps
> someone can turn on the wrong debug option and run it on non-Tegra, but
> then it's guaranteed not to work since the HW it touches doesn't exist).
> As such, the code ought to be able to use ARMv7 instructions.
> 
> As a fix for similar issues in assembly code in arch/arm/mach-tegra/*.S,
> Makefile there does:
> 
> asflags-y                               += -march=armv7-a
> 
> (I think you added that? Yes, in 408e713545ca "ARM: tegra: build
> assembly files with -march=armv7-a")
> 
> Shouldn't we use the same fix in this case too?

That was my first idea, but I couldn't come up with a nice way to do this
for arch/arm/kernel/debug.S, which #includes the specific implementation.

I'd rather not put lots of per-platform hacks into arch/arm/kernel/Makefile.

	Arnd

Re: [PATCH 23/62] ARM: omap1: fix building without 32K_TIMER

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 2461 bytes --]

Hi,

On Wed, Mar 19, 2014 at 08:29:20PM +0100, Arnd Bergmann wrote:
> If we enable CONFIG_OMAP_MPU_TIMER and CONFIG_OMAP_DM_TIMER but
> not CONFIG_OMAP_32K_TIMER on OMAP1, we currently get this build error:
> 
> mach-omap1/pm.c: In function 'omap1_pm_idle':
> mach-omap1/pm.c:123:9: error: 'enable_dyn_sleep' undeclared (first use in this function)
>   while (enable_dyn_sleep) {
>          ^
> mach-omap1/pm.c:123:9: note: each undeclared identifier is reported only once for each function it appears in
> 
> This attempts to fix the #ifdef logic to deal with all combinations
> of timers.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: linux-omap@vger.kernel.org
> Cc: Tony Lindgren <tony@atomide.com>

I had sent a fix for months and months ago, what happened to it ?

> ---
>  arch/arm/mach-omap1/pm.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/mach-omap1/pm.c b/arch/arm/mach-omap1/pm.c
> index 40a1ae3..7dff68e 100644
> --- a/arch/arm/mach-omap1/pm.c
> +++ b/arch/arm/mach-omap1/pm.c
> @@ -71,10 +71,10 @@ static unsigned int mpui7xx_sleep_save[MPUI7XX_SLEEP_SAVE_SIZE];
>  static unsigned int mpui1510_sleep_save[MPUI1510_SLEEP_SAVE_SIZE];
>  static unsigned int mpui1610_sleep_save[MPUI1610_SLEEP_SAVE_SIZE];
>  
> -#ifdef CONFIG_OMAP_32K_TIMER
> -
>  static unsigned short enable_dyn_sleep = 1;
>  
> +#if defined(CONFIG_OMAP_32K_TIMER) || defined(CONFIG_OMAP_MPU_TIMER)
> +
>  static ssize_t idle_show(struct kobject *kobj, struct kobj_attribute *attr,
>  			 char *buf)
>  {
> @@ -643,7 +643,7 @@ static const struct platform_suspend_ops omap_pm_ops = {
>  static int __init omap_pm_init(void)
>  {
>  
> -#ifdef CONFIG_OMAP_32K_TIMER
> +#if defined(CONFIG_OMAP_32K_TIMER) || defined(CONFIG_OMAP_MPU_TIMER)
>  	int error;
>  #endif
>  
> @@ -700,7 +700,7 @@ static int __init omap_pm_init(void)
>  	omap_pm_init_debugfs();
>  #endif
>  
> -#ifdef CONFIG_OMAP_32K_TIMER
> +#if defined(CONFIG_OMAP_32K_TIMER) || defined(CONFIG_OMAP_MPU_TIMER)
>  	error = sysfs_create_file(power_kobj, &sleep_while_idle_attr.attr);
>  	if (error)
>  		printk(KERN_ERR "sysfs_create_file failed: %d\n", error);
> -- 
> 1.8.3.2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[PATCH 23/62] ARM: omap1: fix building without 32K_TIMER

[Felipe Balbi]

Hi,

On Wed, Mar 19, 2014 at 08:29:20PM +0100, Arnd Bergmann wrote:
> If we enable CONFIG_OMAP_MPU_TIMER and CONFIG_OMAP_DM_TIMER but
> not CONFIG_OMAP_32K_TIMER on OMAP1, we currently get this build error:
> 
> mach-omap1/pm.c: In function 'omap1_pm_idle':
> mach-omap1/pm.c:123:9: error: 'enable_dyn_sleep' undeclared (first use in this function)
>   while (enable_dyn_sleep) {
>          ^
> mach-omap1/pm.c:123:9: note: each undeclared identifier is reported only once for each function it appears in
> 
> This attempts to fix the #ifdef logic to deal with all combinations
> of timers.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: linux-omap at vger.kernel.org
> Cc: Tony Lindgren <tony@atomide.com>

I had sent a fix for months and months ago, what happened to it ?

> ---
>  arch/arm/mach-omap1/pm.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/mach-omap1/pm.c b/arch/arm/mach-omap1/pm.c
> index 40a1ae3..7dff68e 100644
> --- a/arch/arm/mach-omap1/pm.c
> +++ b/arch/arm/mach-omap1/pm.c
> @@ -71,10 +71,10 @@ static unsigned int mpui7xx_sleep_save[MPUI7XX_SLEEP_SAVE_SIZE];
>  static unsigned int mpui1510_sleep_save[MPUI1510_SLEEP_SAVE_SIZE];
>  static unsigned int mpui1610_sleep_save[MPUI1610_SLEEP_SAVE_SIZE];
>  
> -#ifdef CONFIG_OMAP_32K_TIMER
> -
>  static unsigned short enable_dyn_sleep = 1;
>  
> +#if defined(CONFIG_OMAP_32K_TIMER) || defined(CONFIG_OMAP_MPU_TIMER)
> +
>  static ssize_t idle_show(struct kobject *kobj, struct kobj_attribute *attr,
>  			 char *buf)
>  {
> @@ -643,7 +643,7 @@ static const struct platform_suspend_ops omap_pm_ops = {
>  static int __init omap_pm_init(void)
>  {
>  
> -#ifdef CONFIG_OMAP_32K_TIMER
> +#if defined(CONFIG_OMAP_32K_TIMER) || defined(CONFIG_OMAP_MPU_TIMER)
>  	int error;
>  #endif
>  
> @@ -700,7 +700,7 @@ static int __init omap_pm_init(void)
>  	omap_pm_init_debugfs();
>  #endif
>  
> -#ifdef CONFIG_OMAP_32K_TIMER
> +#if defined(CONFIG_OMAP_32K_TIMER) || defined(CONFIG_OMAP_MPU_TIMER)
>  	error = sysfs_create_file(power_kobj, &sleep_while_idle_attr.attr);
>  	if (error)
>  		printk(KERN_ERR "sysfs_create_file failed: %d\n", error);
> -- 
> 1.8.3.2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140319/dbfd0ffe/attachment.sig>

Re: [PATCH 23/62] ARM: omap1: fix building without 32K_TIMER

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]

On Wed, Mar 19, 2014 at 02:59:13PM -0500, Felipe Balbi wrote:
> Hi,
> 
> On Wed, Mar 19, 2014 at 08:29:20PM +0100, Arnd Bergmann wrote:
> > If we enable CONFIG_OMAP_MPU_TIMER and CONFIG_OMAP_DM_TIMER but
> > not CONFIG_OMAP_32K_TIMER on OMAP1, we currently get this build error:
> > 
> > mach-omap1/pm.c: In function 'omap1_pm_idle':
> > mach-omap1/pm.c:123:9: error: 'enable_dyn_sleep' undeclared (first use in this function)
> >   while (enable_dyn_sleep) {
> >          ^
> > mach-omap1/pm.c:123:9: note: each undeclared identifier is reported only once for each function it appears in
> > 
> > This attempts to fix the #ifdef logic to deal with all combinations
> > of timers.
> > 
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: linux-omap@vger.kernel.org
> > Cc: Tony Lindgren <tony@atomide.com>
> 
> I had sent a fix for months and months ago, what happened to it ?

Here

http://marc.info/?l=linux-omap&m=138963632408031&w=2

Tony, did you forget to send a pull request ?

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[PATCH 23/62] ARM: omap1: fix building without 32K_TIMER

[Felipe Balbi]

On Wed, Mar 19, 2014 at 02:59:13PM -0500, Felipe Balbi wrote:
> Hi,
> 
> On Wed, Mar 19, 2014 at 08:29:20PM +0100, Arnd Bergmann wrote:
> > If we enable CONFIG_OMAP_MPU_TIMER and CONFIG_OMAP_DM_TIMER but
> > not CONFIG_OMAP_32K_TIMER on OMAP1, we currently get this build error:
> > 
> > mach-omap1/pm.c: In function 'omap1_pm_idle':
> > mach-omap1/pm.c:123:9: error: 'enable_dyn_sleep' undeclared (first use in this function)
> >   while (enable_dyn_sleep) {
> >          ^
> > mach-omap1/pm.c:123:9: note: each undeclared identifier is reported only once for each function it appears in
> > 
> > This attempts to fix the #ifdef logic to deal with all combinations
> > of timers.
> > 
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: linux-omap at vger.kernel.org
> > Cc: Tony Lindgren <tony@atomide.com>
> 
> I had sent a fix for months and months ago, what happened to it ?

Here

http://marc.info/?l=linux-omap&m=138963632408031&w=2

Tony, did you forget to send a pull request ?

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140319/1f1a2926/attachment-0001.sig>

[PATCH 19/62] ARM: lpc32xx: export lpc32xx_return_iram_size

[Roland Stigge]

On 19/03/14 20:29, Arnd Bergmann wrote:
> This symbol is used by the lpc_eth driver, which may
> be a loadable module.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Roland Stigge <stigge@antcom.de>
> ---
>  arch/arm/mach-lpc32xx/common.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/mach-lpc32xx/common.c b/arch/arm/mach-lpc32xx/common.c
> index d7aa54c..de03620 100644
> --- a/arch/arm/mach-lpc32xx/common.c
> +++ b/arch/arm/mach-lpc32xx/common.c
> @@ -99,6 +99,7 @@ u32 lpc32xx_return_iram_size(void)
>  
>  	return iram_size;
>  }
> +EXPORT_SYMBOL_GPL(lpc32xx_return_iram_size);
>  
>  /*
>   * Computes PLL rate from PLL register and input clock
> 

Of course; thanks!

Acked-by: Roland Stigge <stigge@antcom.de>

Re: [PATCH 62/62] ARM: tegra: make debug_ll code build for ARMv6

[Stephen Warren]

On 03/19/2014 01:51 PM, Arnd Bergmann wrote:
> On Wednesday 19 March 2014 13:40:06 Stephen Warren wrote:
>> Hmmm. This code is guaranteed to only execute on Tegra (well, perhaps
>> someone can turn on the wrong debug option and run it on non-Tegra, but
>> then it's guaranteed not to work since the HW it touches doesn't exist).
>> As such, the code ought to be able to use ARMv7 instructions.
>>
>> As a fix for similar issues in assembly code in arch/arm/mach-tegra/*.S,
>> Makefile there does:
>>
>> asflags-y                               += -march=armv7-a
>>
>> (I think you added that? Yes, in 408e713545ca "ARM: tegra: build
>> assembly files with -march=armv7-a")
>>
>> Shouldn't we use the same fix in this case too?
> 
> That was my first idea, but I couldn't come up with a nice way to do this
> for arch/arm/kernel/debug.S, which #includes the specific implementation.
> 
> I'd rather not put lots of per-platform hacks into arch/arm/kernel/Makefile.

Oh, I guess the fact it's include makes it a bit more painful.

You could deal with it in Kconfig reasonably easily by having each of
DEBUG_*_UART select a config option indicating how to compile code that
includes DEBUG_LL_INCLUDE, and then have the Makefiles set up asflags
based on those. Still, that would be a lot of work and this patch is
simpler.

Tested-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Acked-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>

[PATCH 62/62] ARM: tegra: make debug_ll code build for ARMv6

[Stephen Warren]

On 03/19/2014 01:51 PM, Arnd Bergmann wrote:
> On Wednesday 19 March 2014 13:40:06 Stephen Warren wrote:
>> Hmmm. This code is guaranteed to only execute on Tegra (well, perhaps
>> someone can turn on the wrong debug option and run it on non-Tegra, but
>> then it's guaranteed not to work since the HW it touches doesn't exist).
>> As such, the code ought to be able to use ARMv7 instructions.
>>
>> As a fix for similar issues in assembly code in arch/arm/mach-tegra/*.S,
>> Makefile there does:
>>
>> asflags-y                               += -march=armv7-a
>>
>> (I think you added that? Yes, in 408e713545ca "ARM: tegra: build
>> assembly files with -march=armv7-a")
>>
>> Shouldn't we use the same fix in this case too?
> 
> That was my first idea, but I couldn't come up with a nice way to do this
> for arch/arm/kernel/debug.S, which #includes the specific implementation.
> 
> I'd rather not put lots of per-platform hacks into arch/arm/kernel/Makefile.

Oh, I guess the fact it's include makes it a bit more painful.

You could deal with it in Kconfig reasonably easily by having each of
DEBUG_*_UART select a config option indicating how to compile code that
includes DEBUG_LL_INCLUDE, and then have the Makefiles set up asflags
based on those. Still, that would be a lot of work and this patch is
simpler.

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

[PATCH 37/62] ARM: sa1100/pxa: fix MTD_XIP build

[Russell King - ARM Linux]

On Wed, Mar 19, 2014 at 08:29:34PM +0100, Arnd Bergmann wrote:
> In commit 3169663ac5902 "ARM: sa11x0/pxa: convert OS timer registers
> to IOMEM", the definition of the OSCR macro was changed to be an
> __iomem pointer, but the same register is also used by the XIP
> code. This patch does the corresponding change here as well.
> 
> Since PXA now uses a local variable for the base address of the
> ICIP register, the xip_irqpending function has to be moved
> into irq.c in the process.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Russell King <linux@arm.linux.org.uk>
> ---
>  arch/arm/mach-pxa/include/mach/mtd-xip.h    | 7 ++++---
>  arch/arm/mach-pxa/irq.c                     | 8 ++++++++
>  arch/arm/mach-sa1100/include/mach/mtd-xip.h | 4 ++--
>  3 files changed, 14 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/mach-pxa/include/mach/mtd-xip.h b/arch/arm/mach-pxa/include/mach/mtd-xip.h
> index 990d2bf..c4c90d1 100644
> --- a/arch/arm/mach-pxa/include/mach/mtd-xip.h
> +++ b/arch/arm/mach-pxa/include/mach/mtd-xip.h
> @@ -17,11 +17,12 @@
>  
>  #include <mach/regs-ost.h>
>  
> -#define xip_irqpending()	(ICIP & ICMR)
> +extern bool xip_irqpending(void);
>  
>  /* we sample OSCR and convert desired delta to usec (1/4 ~= 1000000/3686400) */
> -#define xip_currtime()		(OSCR)
> -#define xip_elapsed_since(x)	(signed)((OSCR - (x)) / 4)
> +#define xip_irqpending()	xip_irqpending()
> +#define xip_currtime()		readl(OSCR)
> +#define xip_elapsed_since(x)	(signed)((readl(OSCR) - (x)) / 4)

I don't think you can do that.  I believe xip_irqpending() has to be
inline so that the XIP code (located in RAM) can detect when an
interrupt is pending, suspend the MTD operation, switch the MTD back
to read mode, and then allow the kernel to run.

I'd be nervous about this without Nicolas checking it, or it being
built and the resulting assembly inspected.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

[PATCH 11/62] ARM: ep93xx: export ep93xx_chip_revision

[Hartley Sweeten]

On Wednesday, March 19, 2014 12:29 PM, Arnd Bergmann wrote:
> ep93xx_chip_revision is used by the pata_ep93xx driver,
> which can be a loadable module. Exporting the symbol
> avoids a link error in this case.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Hartley Sweeten <hsweeten@visionengravers.com>
> Cc: Ryan Mallon <rmallon@gmail.com>
> ---
>  arch/arm/mach-ep93xx/core.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-ep93xx/core.c b/arch/arm/mach-ep93xx/core.c
> index 6c70547..0e571f1 100644
> --- a/arch/arm/mach-ep93xx/core.c
> +++ b/arch/arm/mach-ep93xx/core.c
> @@ -242,6 +242,7 @@ unsigned int ep93xx_chip_revision(void)
>  	v >>= EP93XX_SYSCON_SYSCFG_REV_SHIFT;
>  	return v;
>  }
> +EXPORT_SYMBOL_GPL(ep93xx_chip_revision);
>  
>  /*************************************************************************
>   * EP93xx GPIO

Good catch. Thanks.

Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>

[PATCH 06/62] ARM: davinci: export da8xx_syscfg0_base

[Arnd Bergmann]

On Wednesday 19 March 2014 23:53:18 Sergei Shtylyov wrote:
> On 03/19/2014 10:29 PM, Arnd Bergmann wrote:
> 
> > The ohci-da8xx driver uses the DA8XX_SYSCFG0_VIRT macro to
> > access the CFGCHIP2 register for controlling its PHY.
> 
> > The macro in turn relies on the da8xx_syscfg0_base global
> > variable. Since the OHCI driver can be a loadable module,
> > this requires the symbol to be exported from platform code.
> 
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Sekhar Nori <nsekhar@ti.com>
> > Cc: Kevin Hilman <khilman@deeprootsystems.com>
> > Cc: davinci-linux-open-source at linux.davincidsp.com
> > ---
> >   arch/arm/mach-davinci/devices-da8xx.c | 1 +
> >   1 file changed, 1 insertion(+)
> 
> > diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
> > index 0486cdf..4da868a 100644
> > --- a/arch/arm/mach-davinci/devices-da8xx.c
> > +++ b/arch/arm/mach-davinci/devices-da8xx.c
> > @@ -66,6 +66,7 @@
> >   #define DA850_DMA_MMCSD1_TX EDMA_CTLR_CHAN(1, 29)
> >
> >   void __iomem *da8xx_syscfg0_base;
> > +EXPORT_SYMBOL_GPL(da8xx_syscfg0_base); /* used by OHCI_HCD */
> 
>     I have submitted such patch years ago and it was turned down. 
> 

The question is whether there is anyone who would do this properly.

Both the OHCI and MUSB drivers use exactly one register (CFGCHIP2)
to control the clock, phy and host/gadget mode switch.

In the modern world, we'd probably want to have a clock driver and
a phy driver for these, based on a syscon driver.

In all honesty I don't see that happening on davinci.

A somewhat better approach would be to export a set of exported
functions to access the one register from the platform, e.g.

u32 da8xx_cfgchip2_get(void);
void da8xx_cfgchip2_set(u32);

That interface would still be a bit ugly, but much better than
what we have today, and easy to implement.

	Arnd

Re: [PATCH 59/62] ARM: shmobile: ak4642 needs i2c support

[Arnd Bergmann]

On Wednesday 19 March 2014, Sergei Shtylyov wrote:
> On 03/19/2014 10:29 PM, Arnd Bergmann wrote:
> 
> > We cannot select SND_SOC_AK4642 if the I2C core layer
> > is disabled. Making the select statement conditional
> > ensures that we can build all configurations.
> 
>     Yes, but you also touch WM8978 selects. Is it the same as AK4642 or you 
> just forgot to mention that?

My bad, I probably screwed up when I folded some older patches
into a common one.

	Arnd

[PATCH 59/62] ARM: shmobile: ak4642 needs i2c support

[Arnd Bergmann]

On Wednesday 19 March 2014, Sergei Shtylyov wrote:
> On 03/19/2014 10:29 PM, Arnd Bergmann wrote:
> 
> > We cannot select SND_SOC_AK4642 if the I2C core layer
> > is disabled. Making the select statement conditional
> > ensures that we can build all configurations.
> 
>     Yes, but you also touch WM8978 selects. Is it the same as AK4642 or you 
> just forgot to mention that?

My bad, I probably screwed up when I folded some older patches
into a common one.

	Arnd

Re: [PATCH 23/62] ARM: omap1: fix building without 32K_TIMER

[Tony Lindgren]

* Felipe Balbi <balbi@ti.com> [140319 13:06]:
> On Wed, Mar 19, 2014 at 02:59:13PM -0500, Felipe Balbi wrote:
> > Hi,
> > 
> > On Wed, Mar 19, 2014 at 08:29:20PM +0100, Arnd Bergmann wrote:
> > > If we enable CONFIG_OMAP_MPU_TIMER and CONFIG_OMAP_DM_TIMER but
> > > not CONFIG_OMAP_32K_TIMER on OMAP1, we currently get this build error:
> > > 
> > > mach-omap1/pm.c: In function 'omap1_pm_idle':
> > > mach-omap1/pm.c:123:9: error: 'enable_dyn_sleep' undeclared (first use in this function)
> > >   while (enable_dyn_sleep) {
> > >          ^
> > > mach-omap1/pm.c:123:9: note: each undeclared identifier is reported only once for each function it appears in
> > > 
> > > This attempts to fix the #ifdef logic to deal with all combinations
> > > of timers.
> > > 
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > Cc: linux-omap@vger.kernel.org
> > > Cc: Tony Lindgren <tony@atomide.com>
> > 
> > I had sent a fix for months and months ago, what happened to it ?
> 
> Here
> 
> http://marc.info/?l=linux-omap&m=138963632408031&w=2
> 
> Tony, did you forget to send a pull request ?

Hmm yes weird, can't see it in my omap-for-v3.14/fixes branch.

I must have gotten interrupted while applying and then probably
ran git reset --hard before committing.

Arnd, maybe pick up Felipe's earlier patch instead?

Acked-by: Tony Lindgren <tony@atomide.com>

[PATCH 23/62] ARM: omap1: fix building without 32K_TIMER

[Tony Lindgren]

* Felipe Balbi <balbi@ti.com> [140319 13:06]:
> On Wed, Mar 19, 2014 at 02:59:13PM -0500, Felipe Balbi wrote:
> > Hi,
> > 
> > On Wed, Mar 19, 2014 at 08:29:20PM +0100, Arnd Bergmann wrote:
> > > If we enable CONFIG_OMAP_MPU_TIMER and CONFIG_OMAP_DM_TIMER but
> > > not CONFIG_OMAP_32K_TIMER on OMAP1, we currently get this build error:
> > > 
> > > mach-omap1/pm.c: In function 'omap1_pm_idle':
> > > mach-omap1/pm.c:123:9: error: 'enable_dyn_sleep' undeclared (first use in this function)
> > >   while (enable_dyn_sleep) {
> > >          ^
> > > mach-omap1/pm.c:123:9: note: each undeclared identifier is reported only once for each function it appears in
> > > 
> > > This attempts to fix the #ifdef logic to deal with all combinations
> > > of timers.
> > > 
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > Cc: linux-omap at vger.kernel.org
> > > Cc: Tony Lindgren <tony@atomide.com>
> > 
> > I had sent a fix for months and months ago, what happened to it ?
> 
> Here
> 
> http://marc.info/?l=linux-omap&m=138963632408031&w=2
> 
> Tony, did you forget to send a pull request ?

Hmm yes weird, can't see it in my omap-for-v3.14/fixes branch.

I must have gotten interrupted while applying and then probably
ran git reset --hard before committing.

Arnd, maybe pick up Felipe's earlier patch instead?

Acked-by: Tony Lindgren <tony@atomide.com>

[PATCH 25/62] ARM: mvebu: add missing header

[Gregory CLEMENT]

On 19/03/2014 20:29, Arnd Bergmann wrote:
> The definition for SIGBUS may not be visible without including
> linux/signal.h, as I found during randconfig testing.
> 
> Adding an explicit include is certainly the right thing to do.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Gregory Clement <gregory.clement@free-electrons.com>
> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>


Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>

Thanks,

Gregory


> ---
>  arch/arm/mach-mvebu/board-v7.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/mach-mvebu/board-v7.c b/arch/arm/mach-mvebu/board-v7.c
> index 746134e..333fca8 100644
> --- a/arch/arm/mach-mvebu/board-v7.c
> +++ b/arch/arm/mach-mvebu/board-v7.c
> @@ -21,6 +21,7 @@
>  #include <linux/clocksource.h>
>  #include <linux/dma-mapping.h>
>  #include <linux/mbus.h>
> +#include <linux/signal.h>
>  #include <linux/slab.h>
>  #include <asm/hardware/cache-l2x0.h>
>  #include <asm/mach/arch.h>
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [PATCH 24/62] ARM: omap1: select I2C where needed for PMIC

[Tony Lindgren]

* Arnd Bergmann <arnd@arndb.de> [140319 12:33]:
> The OMAP H2, OSK and OSIRIS machines cannot build without
> I2C and TPS65010 both enabled unconditionally.
> 
> In each case, failing to enable CONFIG_I2C results in a
> build or link error, so most consistent solution is to
> ensure that it is impossible to disable those options.
> 
> It would be nice to leave CONFIG_I2C as user-selectable,
> but doing that properly would require more work.

We should not select drivers. How about let's just have
the tps65010 stuff behind an ifdef CONFIG_TPS65010 for
those boards?

Regards,

Tony
 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: linux-omap@vger.kernel.org
> ---
>  arch/arm/mach-omap1/Kconfig | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/arm/mach-omap1/Kconfig b/arch/arm/mach-omap1/Kconfig
> index cdd05f2..23ab1d5 100644
> --- a/arch/arm/mach-omap1/Kconfig
> +++ b/arch/arm/mach-omap1/Kconfig
> @@ -44,6 +44,8 @@ config MACH_OMAP_INNOVATOR
>  config MACH_OMAP_H2
>  	bool "TI H2 Support"
>  	depends on ARCH_OMAP1 && ARCH_OMAP16XX
> +	select TPS65010
> +	select I2C
>      	help
>  	  TI OMAP 1610/1611B H2 board support. Say Y here if you have such
>  	  a board.
> @@ -64,6 +66,8 @@ config MACH_HERALD
>  config MACH_OMAP_OSK
>  	bool "TI OSK Support"
>  	depends on ARCH_OMAP1 && ARCH_OMAP16XX
> +	select TPS65010
> +	select I2C
>      	help
>  	  TI OMAP 5912 OSK (OMAP Starter Kit) board support. Say Y here
>            if you have such a board.
> -- 
> 1.8.3.2
> 

[PATCH 24/62] ARM: omap1: select I2C where needed for PMIC

[Tony Lindgren]

* Arnd Bergmann <arnd@arndb.de> [140319 12:33]:
> The OMAP H2, OSK and OSIRIS machines cannot build without
> I2C and TPS65010 both enabled unconditionally.
> 
> In each case, failing to enable CONFIG_I2C results in a
> build or link error, so most consistent solution is to
> ensure that it is impossible to disable those options.
> 
> It would be nice to leave CONFIG_I2C as user-selectable,
> but doing that properly would require more work.

We should not select drivers. How about let's just have
the tps65010 stuff behind an ifdef CONFIG_TPS65010 for
those boards?

Regards,

Tony
 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: linux-omap at vger.kernel.org
> ---
>  arch/arm/mach-omap1/Kconfig | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/arm/mach-omap1/Kconfig b/arch/arm/mach-omap1/Kconfig
> index cdd05f2..23ab1d5 100644
> --- a/arch/arm/mach-omap1/Kconfig
> +++ b/arch/arm/mach-omap1/Kconfig
> @@ -44,6 +44,8 @@ config MACH_OMAP_INNOVATOR
>  config MACH_OMAP_H2
>  	bool "TI H2 Support"
>  	depends on ARCH_OMAP1 && ARCH_OMAP16XX
> +	select TPS65010
> +	select I2C
>      	help
>  	  TI OMAP 1610/1611B H2 board support. Say Y here if you have such
>  	  a board.
> @@ -64,6 +66,8 @@ config MACH_HERALD
>  config MACH_OMAP_OSK
>  	bool "TI OSK Support"
>  	depends on ARCH_OMAP1 && ARCH_OMAP16XX
> +	select TPS65010
> +	select I2C
>      	help
>  	  TI OMAP 5912 OSK (OMAP Starter Kit) board support. Say Y here
>            if you have such a board.
> -- 
> 1.8.3.2
> 

[PATCH 44/62] ARM: integrator: refine CPU selection

[Russell King - ARM Linux]

On Wed, Mar 19, 2014 at 08:29:41PM +0100, Arnd Bergmann wrote:
> This adds a new Kconfig option for the Integrator platform to
> choose between ARMv4/ARMv5 based CPUs and those based on ARMv6/ARMv7,
> which is required because we cannot have both classes enabled in the
> same kernel at compile time.

Wouldn't it just be easier to make the older CPUs depend on
!CPU_V6 && !CPU_V7 rather than trying to hack this for each platform?

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

[PATCH 59/62] ARM: shmobile: ak4642 needs i2c support

[Sergei Shtylyov]

Hello.

On 03/19/2014 10:29 PM, Arnd Bergmann wrote:

> We cannot select SND_SOC_AK4642 if the I2C core layer
> is disabled. Making the select statement conditional
> ensures that we can build all configurations.

    Yes, but you also touch WM8978 selects. Is it the same as AK4642 or you 
just forgot to mention that?

> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Simon Horman <horms@verge.net.au>
> Cc: Magnus Damm <magnus.damm@gmail.com>
> Cc: linux-sh at vger.kernel.org
> ---
>   arch/arm/mach-shmobile/Kconfig | 12 ++++++------
>   1 file changed, 6 insertions(+), 6 deletions(-)

> diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
> index 5249ff0..6e3904e 100644
> --- a/arch/arm/mach-shmobile/Kconfig
> +++ b/arch/arm/mach-shmobile/Kconfig
> @@ -170,7 +170,7 @@ config MACH_MACKEREL
>   	select ARCH_REQUIRE_GPIOLIB
>   	select REGULATOR_FIXED_VOLTAGE if REGULATOR
>   	select SMSC_PHY if SMSC911X
> -	select SND_SOC_AK4642 if SND_SIMPLE_CARD
> +	select SND_SOC_AK4642 if SND_SIMPLE_CARD && I2C=y
>   	select USE_OF
>
>   config MACH_ARMADILLO800EVA
> @@ -179,7 +179,7 @@ config MACH_ARMADILLO800EVA
>   	select ARCH_REQUIRE_GPIOLIB
>   	select REGULATOR_FIXED_VOLTAGE if REGULATOR
>   	select SMSC_PHY if SH_ETH
> -	select SND_SOC_WM8978 if SND_SIMPLE_CARD
> +	select SND_SOC_WM8978 if SND_SIMPLE_CARD && I2C=y
>   	select USE_OF
>
>   config MACH_ARMADILLO800EVA_REFERENCE
> @@ -188,7 +188,7 @@ config MACH_ARMADILLO800EVA_REFERENCE
>   	select ARCH_REQUIRE_GPIOLIB
>   	select REGULATOR_FIXED_VOLTAGE if REGULATOR
>   	select SMSC_PHY if SH_ETH
> -	select SND_SOC_WM8978 if SND_SIMPLE_CARD
> +	select SND_SOC_WM8978 if SND_SIMPLE_CARD && I2C=y
>   	select USE_OF
>   	---help---
>   	   Use reference implementation of Aramdillo800 EVA board support
[...]

WBR, Sergei

[PATCH 06/62] ARM: davinci: export da8xx_syscfg0_base

[Sergei Shtylyov]

On 03/19/2014 10:29 PM, Arnd Bergmann wrote:

> The ohci-da8xx driver uses the DA8XX_SYSCFG0_VIRT macro to
> access the CFGCHIP2 register for controlling its PHY.

> The macro in turn relies on the da8xx_syscfg0_base global
> variable. Since the OHCI driver can be a loadable module,
> this requires the symbol to be exported from platform code.

> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Sekhar Nori <nsekhar@ti.com>
> Cc: Kevin Hilman <khilman@deeprootsystems.com>
> Cc: davinci-linux-open-source at linux.davincidsp.com
> ---
>   arch/arm/mach-davinci/devices-da8xx.c | 1 +
>   1 file changed, 1 insertion(+)

> diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
> index 0486cdf..4da868a 100644
> --- a/arch/arm/mach-davinci/devices-da8xx.c
> +++ b/arch/arm/mach-davinci/devices-da8xx.c
> @@ -66,6 +66,7 @@
>   #define DA850_DMA_MMCSD1_TX	EDMA_CTLR_CHAN(1, 29)
>
>   void __iomem *da8xx_syscfg0_base;
> +EXPORT_SYMBOL_GPL(da8xx_syscfg0_base); /* used by OHCI_HCD */

    I have submitted such patch years ago and it was turned down. :-)

WBR, Sergei

Re: [PATCH 24/62] ARM: omap1: select I2C where needed for PMIC

[Arnd Bergmann]

On Wednesday 19 March 2014 13:46:19 Tony Lindgren wrote:
> * Arnd Bergmann <arnd@arndb.de> [140319 12:33]:
> > The OMAP H2, OSK and OSIRIS machines cannot build without
> > I2C and TPS65010 both enabled unconditionally.
> > 
> > In each case, failing to enable CONFIG_I2C results in a
> > build or link error, so most consistent solution is to
> > ensure that it is impossible to disable those options.
> > 
> > It would be nice to leave CONFIG_I2C as user-selectable,
> > but doing that properly would require more work.
> 
> We should not select drivers. How about let's just have
> the tps65010 stuff behind an ifdef CONFIG_TPS65010 for
> those boards?

Good idea. Like this?

	Arnd


diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index fd90caf..65d2acb 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -318,6 +318,9 @@ static void __init h2_init_smc91x(void)
 
 static int tps_setup(struct i2c_client *client, void *context)
 {
+	if (!IS_BUILTIN(CONFIG_TPS65010))
+		return -ENOSYS;
+	
 	tps65010_config_vregs1(TPS_LDO2_ENABLE | TPS_VLDO2_3_0V |
 				TPS_LDO1_ENABLE | TPS_VLDO1_3_0V);
 
diff --git a/arch/arm/mach-omap1/board-osk.c b/arch/arm/mach-omap1/board-osk.c
index d68909b..3a02621 100644
--- a/arch/arm/mach-omap1/board-osk.c
+++ b/arch/arm/mach-omap1/board-osk.c
@@ -191,6 +191,9 @@ static struct platform_device osk5912_tps_leds = {
 
 static int osk_tps_setup(struct i2c_client *client, void *context)
 {
+	if (!IS_BUILTIN(CONFIG_TPS65010))
+		return -ENOSYS;
+
 	/* Set GPIO 1 HIGH to disable VBUS power supply;
 	 * OHCI driver powers it up/down as needed.
 	 */

[PATCH 24/62] ARM: omap1: select I2C where needed for PMIC

[Arnd Bergmann]

On Wednesday 19 March 2014 13:46:19 Tony Lindgren wrote:
> * Arnd Bergmann <arnd@arndb.de> [140319 12:33]:
> > The OMAP H2, OSK and OSIRIS machines cannot build without
> > I2C and TPS65010 both enabled unconditionally.
> > 
> > In each case, failing to enable CONFIG_I2C results in a
> > build or link error, so most consistent solution is to
> > ensure that it is impossible to disable those options.
> > 
> > It would be nice to leave CONFIG_I2C as user-selectable,
> > but doing that properly would require more work.
> 
> We should not select drivers. How about let's just have
> the tps65010 stuff behind an ifdef CONFIG_TPS65010 for
> those boards?

Good idea. Like this?

	Arnd


diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index fd90caf..65d2acb 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -318,6 +318,9 @@ static void __init h2_init_smc91x(void)
 
 static int tps_setup(struct i2c_client *client, void *context)
 {
+	if (!IS_BUILTIN(CONFIG_TPS65010))
+		return -ENOSYS;
+	
 	tps65010_config_vregs1(TPS_LDO2_ENABLE | TPS_VLDO2_3_0V |
 				TPS_LDO1_ENABLE | TPS_VLDO1_3_0V);
 
diff --git a/arch/arm/mach-omap1/board-osk.c b/arch/arm/mach-omap1/board-osk.c
index d68909b..3a02621 100644
--- a/arch/arm/mach-omap1/board-osk.c
+++ b/arch/arm/mach-omap1/board-osk.c
@@ -191,6 +191,9 @@ static struct platform_device osk5912_tps_leds = {
 
 static int osk_tps_setup(struct i2c_client *client, void *context)
 {
+	if (!IS_BUILTIN(CONFIG_TPS65010))
+		return -ENOSYS;
+
 	/* Set GPIO 1 HIGH to disable VBUS power supply;
 	 * OHCI driver powers it up/down as needed.
 	 */

Re: [PATCH 24/62] ARM: omap1: select I2C where needed for PMIC

[Tony Lindgren]

* Arnd Bergmann <arnd@arndb.de> [140319 14:01]:
> On Wednesday 19 March 2014 13:46:19 Tony Lindgren wrote:
> > * Arnd Bergmann <arnd@arndb.de> [140319 12:33]:
> > > The OMAP H2, OSK and OSIRIS machines cannot build without
> > > I2C and TPS65010 both enabled unconditionally.
> > > 
> > > In each case, failing to enable CONFIG_I2C results in a
> > > build or link error, so most consistent solution is to
> > > ensure that it is impossible to disable those options.
> > > 
> > > It would be nice to leave CONFIG_I2C as user-selectable,
> > > but doing that properly would require more work.
> > 
> > We should not select drivers. How about let's just have
> > the tps65010 stuff behind an ifdef CONFIG_TPS65010 for
> > those boards?
> 
> Good idea. Like this?

Looks good to me :)

Acked-by: Tony Lindgren <tony@atomide.com>
 
> diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
> index fd90caf..65d2acb 100644
> --- a/arch/arm/mach-omap1/board-h2.c
> +++ b/arch/arm/mach-omap1/board-h2.c
> @@ -318,6 +318,9 @@ static void __init h2_init_smc91x(void)
>  
>  static int tps_setup(struct i2c_client *client, void *context)
>  {
> +	if (!IS_BUILTIN(CONFIG_TPS65010))
> +		return -ENOSYS;
> +	
>  	tps65010_config_vregs1(TPS_LDO2_ENABLE | TPS_VLDO2_3_0V |
>  				TPS_LDO1_ENABLE | TPS_VLDO1_3_0V);
>  
> diff --git a/arch/arm/mach-omap1/board-osk.c b/arch/arm/mach-omap1/board-osk.c
> index d68909b..3a02621 100644
> --- a/arch/arm/mach-omap1/board-osk.c
> +++ b/arch/arm/mach-omap1/board-osk.c
> @@ -191,6 +191,9 @@ static struct platform_device osk5912_tps_leds = {
>  
>  static int osk_tps_setup(struct i2c_client *client, void *context)
>  {
> +	if (!IS_BUILTIN(CONFIG_TPS65010))
> +		return -ENOSYS;
> +
>  	/* Set GPIO 1 HIGH to disable VBUS power supply;
>  	 * OHCI driver powers it up/down as needed.
>  	 */
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 24/62] ARM: omap1: select I2C where needed for PMIC

[Tony Lindgren]

* Arnd Bergmann <arnd@arndb.de> [140319 14:01]:
> On Wednesday 19 March 2014 13:46:19 Tony Lindgren wrote:
> > * Arnd Bergmann <arnd@arndb.de> [140319 12:33]:
> > > The OMAP H2, OSK and OSIRIS machines cannot build without
> > > I2C and TPS65010 both enabled unconditionally.
> > > 
> > > In each case, failing to enable CONFIG_I2C results in a
> > > build or link error, so most consistent solution is to
> > > ensure that it is impossible to disable those options.
> > > 
> > > It would be nice to leave CONFIG_I2C as user-selectable,
> > > but doing that properly would require more work.
> > 
> > We should not select drivers. How about let's just have
> > the tps65010 stuff behind an ifdef CONFIG_TPS65010 for
> > those boards?
> 
> Good idea. Like this?

Looks good to me :)

Acked-by: Tony Lindgren <tony@atomide.com>
 
> diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
> index fd90caf..65d2acb 100644
> --- a/arch/arm/mach-omap1/board-h2.c
> +++ b/arch/arm/mach-omap1/board-h2.c
> @@ -318,6 +318,9 @@ static void __init h2_init_smc91x(void)
>  
>  static int tps_setup(struct i2c_client *client, void *context)
>  {
> +	if (!IS_BUILTIN(CONFIG_TPS65010))
> +		return -ENOSYS;
> +	
>  	tps65010_config_vregs1(TPS_LDO2_ENABLE | TPS_VLDO2_3_0V |
>  				TPS_LDO1_ENABLE | TPS_VLDO1_3_0V);
>  
> diff --git a/arch/arm/mach-omap1/board-osk.c b/arch/arm/mach-omap1/board-osk.c
> index d68909b..3a02621 100644
> --- a/arch/arm/mach-omap1/board-osk.c
> +++ b/arch/arm/mach-omap1/board-osk.c
> @@ -191,6 +191,9 @@ static struct platform_device osk5912_tps_leds = {
>  
>  static int osk_tps_setup(struct i2c_client *client, void *context)
>  {
> +	if (!IS_BUILTIN(CONFIG_TPS65010))
> +		return -ENOSYS;
> +
>  	/* Set GPIO 1 HIGH to disable VBUS power supply;
>  	 * OHCI driver powers it up/down as needed.
>  	 */
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 44/62] ARM: integrator: refine CPU selection

[Arnd Bergmann]

On Wednesday 19 March 2014 20:49:47 Russell King - ARM Linux wrote:
> On Wed, Mar 19, 2014 at 08:29:41PM +0100, Arnd Bergmann wrote:
> > This adds a new Kconfig option for the Integrator platform to
> > choose between ARMv4/ARMv5 based CPUs and those based on ARMv6/ARMv7,
> > which is required because we cannot have both classes enabled in the
> > same kernel at compile time.
> 
> Wouldn't it just be easier to make the older CPUs depend on
> !CPU_V6 && !CPU_V7 rather than trying to hack this for each platform?

It's only two platforms: integrator and realview. Actually I took two
different approaches on these, and wanted to make up my mind first
which one is better. Any suggestion?

I have a mild preference to always using 'select' on the CPU_* symbol
from the platform, mostly for consistency. The downside is that it
gets a little messy for Integrator, but that's just one platform in
the end.

At some point, I think I got into circular dependencies when one CPU
depended on another one being disabled, but I don't remember exactly
what case that was.

	Arnd

[PATCH 20/62] ARM: msm: add missing include of linux/module.h

[David Brown]

On Wed, Mar 19, 2014 at 08:29:17PM +0100, Arnd Bergmann wrote:
>After the restructuring of the module.h and init.h headers,
>we now need to include this explicitly here.
>
>Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>Cc: David Brown <davidb@codeaurora.org>
>Cc: Daniel Walker <dwalker@fifo99.com>
>Cc: Bryan Huntsman <bryanh@codeaurora.org>
>---
> arch/arm/mach-msm/dma.c | 1 +
> 1 file changed, 1 insertion(+)

Acked-by: David Brown <davidb@codeaurora.org>

>diff --git a/arch/arm/mach-msm/dma.c b/arch/arm/mach-msm/dma.c
>index f8f6adf..ba62f02 100644
>--- a/arch/arm/mach-msm/dma.c
>+++ b/arch/arm/mach-msm/dma.c
>@@ -18,6 +18,7 @@
> #include <linux/io.h>
> #include <linux/interrupt.h>
> #include <linux/completion.h>
>+#include <linux/module.h>
> #include <mach/dma.h>
> #include <mach/msm_iomap.h>
>
>-- 
>1.8.3.2
>

-- 
sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 21/62] ARM: msm: avoid calling debug_ll_addr on !MMU

[David Brown]

On Wed, Mar 19, 2014 at 08:29:18PM +0100, Arnd Bergmann wrote:
>MSM7X00A has an open-coded version of debug_ll_io_init so it
>can use MT_DEVICE_NONSHARED as required by the platform.
>
>However, this fails to build on no-MMU kernels because the
>debug_ll_addr function is not available. Since the iotable_init
>function doesn't actually do anyting in this configuration,
>we can simply get away by enclosing the broken function call
>in an #ifdef, which seems to be the least ugly workaround.
>
>Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>Cc: David Brown <davidb@codeaurora.org>
>Cc: Daniel Walker <dwalker@fifo99.com>
>Cc: Bryan Huntsman <bryanh@codeaurora.org>
>---
> arch/arm/mach-msm/io.c | 2 ++
> 1 file changed, 2 insertions(+)

Acked-by: David Brown <davidb@codeaurora.org>

>diff --git a/arch/arm/mach-msm/io.c b/arch/arm/mach-msm/io.c
>index adc8971..34e0947 100644
>--- a/arch/arm/mach-msm/io.c
>+++ b/arch/arm/mach-msm/io.c
>@@ -78,8 +78,10 @@ void __init msm_map_common_io(void)
> 	asm("mcr p15, 0, %0, c15, c2, 4" : : "r" (0));
> #if defined(CONFIG_DEBUG_MSM_UART1) || defined(CONFIG_DEBUG_MSM_UART2) || \
> 		defined(CONFIG_DEBUG_MSM_UART3)
>+#ifdef CONFIG_MMU
> 	debug_ll_addr(&msm_io_desc[size - 1].pfn,
> 		      &msm_io_desc[size - 1].virtual);
>+#endif
> 	msm_io_desc[size - 1].pfn = __phys_to_pfn(msm_io_desc[size - 1].pfn);
> #endif
> 	iotable_init(msm_io_desc, size);
>-- 
>1.8.3.2
>

-- 
sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 22/62] ARM: msm: export legacy DMA interfaces

[David Brown]

On Wed, Mar 19, 2014 at 08:29:19PM +0100, Arnd Bergmann wrote:
>The msm_sdcc MMC driver and the msm_serial_hs uart driver both
>use the pre-dmaengine interfaces provided by the MSM platform.
>
>Since these drivers can be loadable modules, we should export
>the functions used in the drivers.
>
>Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>Cc: David Brown <davidb@codeaurora.org>
>Cc: Daniel Walker <dwalker@fifo99.com>
>Cc: Bryan Huntsman <bryanh@codeaurora.org>
>---
> arch/arm/mach-msm/dma.c | 2 ++
> 1 file changed, 2 insertions(+)

Acked-by: David Brown <davidb@codeaurora.org>

-- 
sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 26/62] ARM: mvebu: don't select CONFIG_NEON

[Gregory CLEMENT]

On 19/03/2014 20:37, Jason Cooper wrote:
> On Wed, Mar 19, 2014 at 08:29:23PM +0100, Arnd Bergmann wrote:
>> CONFIG_NEON is meant to be user-selectable. Turning it on
>> unconditionally means we can't build a smaller kernel when
>> we don't need it, and causes build errors if CONFIG_VFP
>> is not also enabled.
>>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> Cc: Jason Cooper <jason@lakedaemon.net>
>> Cc: Andrew Lunn <andrew@lunn.ch>
>> Cc: Gregory Clement <gregory.clement@free-electrons.com>
>> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
>> ---
>>  arch/arm/mach-mvebu/Kconfig | 2 --
>>  1 file changed, 2 deletions(-)
> 
> Acked-by: Jason Cooper <jason@lakedaemon.net>


Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>


> 
> Gregory, Thomas, Ezequiel,
> 
> Care to spin a patch adding NEON to mvebu_v7_defconfig?  (If you want
> it)

I will send a patch in a couple of minute. I'd like that it was applied
on the same release that this patch if possible.


Thanks,

Gregory


> 
> thx,
> 
> Jason.
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[PATCH 37/62] ARM: sa1100/pxa: fix MTD_XIP build

[Nicolas Pitre]

On Wed, 19 Mar 2014, Russell King - ARM Linux wrote:

> On Wed, Mar 19, 2014 at 08:29:34PM +0100, Arnd Bergmann wrote:
> > In commit 3169663ac5902 "ARM: sa11x0/pxa: convert OS timer registers
> > to IOMEM", the definition of the OSCR macro was changed to be an
> > __iomem pointer, but the same register is also used by the XIP
> > code. This patch does the corresponding change here as well.
> > 
> > Since PXA now uses a local variable for the base address of the
> > ICIP register, the xip_irqpending function has to be moved
> > into irq.c in the process.
> > 
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Russell King <linux@arm.linux.org.uk>
> > ---
> >  arch/arm/mach-pxa/include/mach/mtd-xip.h    | 7 ++++---
> >  arch/arm/mach-pxa/irq.c                     | 8 ++++++++
> >  arch/arm/mach-sa1100/include/mach/mtd-xip.h | 4 ++--
> >  3 files changed, 14 insertions(+), 5 deletions(-)
> > 
> > diff --git a/arch/arm/mach-pxa/include/mach/mtd-xip.h b/arch/arm/mach-pxa/include/mach/mtd-xip.h
> > index 990d2bf..c4c90d1 100644
> > --- a/arch/arm/mach-pxa/include/mach/mtd-xip.h
> > +++ b/arch/arm/mach-pxa/include/mach/mtd-xip.h
> > @@ -17,11 +17,12 @@
> >  
> >  #include <mach/regs-ost.h>
> >  
> > -#define xip_irqpending()	(ICIP & ICMR)
> > +extern bool xip_irqpending(void);
> >  
> >  /* we sample OSCR and convert desired delta to usec (1/4 ~= 1000000/3686400) */
> > -#define xip_currtime()		(OSCR)
> > -#define xip_elapsed_since(x)	(signed)((OSCR - (x)) / 4)
> > +#define xip_irqpending()	xip_irqpending()
> > +#define xip_currtime()		readl(OSCR)
> > +#define xip_elapsed_since(x)	(signed)((readl(OSCR) - (x)) / 4)
> 
> I don't think you can do that.  I believe xip_irqpending() has to be
> inline so that the XIP code (located in RAM) can detect when an
> interrupt is pending, suspend the MTD operation, switch the MTD back
> to read mode, and then allow the kernel to run.
> 
> I'd be nervous about this without Nicolas checking it, or it being
> built and the resulting assembly inspected.

At the very minimum, xip_irqpending() should be marked with the __xipram 
attribute.


Nicolas

[PATCH 61/62] ARM: sunxi: fix build for THUMB2_KERNEL

[Rob Herring]

On Wed, Mar 19, 2014 at 2:29 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> Building an SMP kernel for the sunxi platform with THUMB2 instructions
> fails with this error at the moment:
>
> headsmp.S:7: Error: Thumb encoding does not support an immediate here -- `msr cpsr_fsxc,#0xd3'
>
> This changes the code to use a register for loading the
> value instead, which works in both ARM and THUMB mode.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
>  arch/arm/mach-sunxi/headsmp.S | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-sunxi/headsmp.S b/arch/arm/mach-sunxi/headsmp.S
> index a10d494..a8e0fef 100644
> --- a/arch/arm/mach-sunxi/headsmp.S
> +++ b/arch/arm/mach-sunxi/headsmp.S
> @@ -4,6 +4,7 @@
>          .section ".text.head", "ax"
>
>  ENTRY(sun6i_secondary_startup)
> -       msr     cpsr_fsxc, #0xd3
> +       mov     r0, #0xd3
> +       msr     cpsr_fsxc, r0
>         b       secondary_startup

Secondary cores should always enter the kernel in ARM mode like the
primary core, right? So we need the same switching to Thumb2 as
head.S, but even secondary_startup doesn't do any switching. So either
platforms jump into the kernel with a bx and happen to work or
secondary boot is broken for Thumb2 kernels.

Also, secondary_startup takes care of making sure the core is in SVC
mode, so this function shouldn't be needed in the first place.

Rob

[PATCH 06/62] ARM: davinci: export da8xx_syscfg0_base

[Sergei Shtylyov]

On 03/19/2014 11:21 PM, Arnd Bergmann wrote:

>>> The ohci-da8xx driver uses the DA8XX_SYSCFG0_VIRT macro to
>>> access the CFGCHIP2 register for controlling its PHY.

>>> The macro in turn relies on the da8xx_syscfg0_base global
>>> variable. Since the OHCI driver can be a loadable module,
>>> this requires the symbol to be exported from platform code.

>>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>>> Cc: Sekhar Nori <nsekhar@ti.com>
>>> Cc: Kevin Hilman <khilman@deeprootsystems.com>
>>> Cc: davinci-linux-open-source at linux.davincidsp.com
>>> ---
>>>    arch/arm/mach-davinci/devices-da8xx.c | 1 +
>>>    1 file changed, 1 insertion(+)

>>> diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
>>> index 0486cdf..4da868a 100644
>>> --- a/arch/arm/mach-davinci/devices-da8xx.c
>>> +++ b/arch/arm/mach-davinci/devices-da8xx.c
>>> @@ -66,6 +66,7 @@
>>>    #define DA850_DMA_MMCSD1_TX EDMA_CTLR_CHAN(1, 29)
>>>
>>>    void __iomem *da8xx_syscfg0_base;
>>> +EXPORT_SYMBOL_GPL(da8xx_syscfg0_base); /* used by OHCI_HCD */

>>      I have submitted such patch years ago and it was turned down.

    I also had a pleasure of completing implementation of this driver and 
submitting it back in 2009 when I was working for MontaVista. :-)

> The question is whether there is anyone who would do this properly.

    Nobody cares, it seems. As you can imagine, I stopped to care enough after 
being switched to other projects.

> Both the OHCI and MUSB drivers use exactly one register (CFGCHIP2)

    The idea at the time was to just ioremap() this register but I was not 
very eager.
There was no USB PHY driver subsystem yet.

> to control the clock, phy

    Note that it only controls PHY clock (PLL) which could be covered by an 
USB PHY driver.

> and host/gadget mode switch.

    The main mode the USB 2.0 PHY should function now is OTG. The host/gadged 
modes are forced overrides of the ID pin. Unfortunately, the board code has to 
force host mode when host-only driver config is selected (these MUSB's 
host/gadget only modes were removed at one point but got reintroduced again).

> In the modern world, we'd probably want to have a clock driver and

    Not sure about the clock driver...

> a phy driver for these,

    Yes, that's what the MUSB maintainer wants too. The issue is the driver 
should somehow differ which USB controller it's bound too and do different 
things depending on that (at least that's how it looks now). I'm not sure it's 
possible, so probably should be rethought.

> based on a syscon driver.

    I don't know what syscon is...

> In all honesty I don't see that happening on davinci.

    I don't think people use USB 1.1 controllers these days, especially when 
there is USB 2.0 in the same SoC. For MUSB, there were recent attempt to get 
the DA8xx driver out of the broken state but it was turned down as well, IIRC, 
since it didn't offer a PHY driver.

> A somewhat better approach would be to export a set of exported
> functions to access the one register from the platform, e.g.

> u32 da8xx_cfgchip2_get(void);
> void da8xx_cfgchip2_set(u32);

> That interface would still be a bit ugly, but much better than
> what we have today, and easy to implement.

    I'm leaving this idea to Sekhar...

> 	Arnd

WBR, Sergei

[PATCH 18/62] ARM: ks8695/og: make PCI setup conditional

[Greg Ungerer]

On 20/03/14 05:29, Arnd Bergmann wrote:
> The 'og' machine tries to always initialized the PCI code, but that
> may be disabled in Kconfig, leading to a build error.
> 
> This patch changes the code to use the same Kconfig symbol to decide
> about calling the ks8695_init_pci function at build time that we
> use to decide about building the ks8695 PCI support.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Greg Ungerer <gerg@uclinux.org>

Looks good.

Acked-by: Greg Ungerer <gerg@uclinux.org>


>  arch/arm/mach-ks8695/board-og.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-ks8695/board-og.c b/arch/arm/mach-ks8695/board-og.c
> index 002bc61..f265816 100644
> --- a/arch/arm/mach-ks8695/board-og.c
> +++ b/arch/arm/mach-ks8695/board-og.c
> @@ -44,7 +44,8 @@ static void __init og_register_pci(void)
>  	if (machine_is_im4004())
>  		ks8695_gpio_interrupt(KS8695_GPIO_1, IRQ_TYPE_LEVEL_LOW);
>  
> -	ks8695_init_pci(&og_pci);
> +	if (IS_ENABLED(CONFIG_PCI))
> +		ks8695_init_pci(&og_pci);
>  }
>  
>  /*
> 

[PATCH 13/62] ARM: hisi: select HAVE_ARM_SCU only for SMP

[Haojian Zhuang]

On Thu, Mar 20, 2014 at 3:29 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> The SCU code does not build unless we are compiling
> an SMP kernel. This does the same as every other
> platform with an SCU.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
> ---
>  arch/arm/mach-hisi/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-hisi/Kconfig b/arch/arm/mach-hisi/Kconfig
> index 9d0a87b..feee4db 100644
> --- a/arch/arm/mach-hisi/Kconfig
> +++ b/arch/arm/mach-hisi/Kconfig
> @@ -4,7 +4,7 @@ config ARCH_HI3xxx
>         select ARM_GIC
>         select ARM_TIMER_SP804
>         select CACHE_L2X0
> -       select HAVE_ARM_SCU
> +       select HAVE_ARM_SCU if SMP
>         select HAVE_ARM_TWD if SMP
>         select PINCTRL
>         select PINCTRL_SINGLE
> --
> 1.8.3.2
>

Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com>

[PATCH 12/62] ARM: hisi: fix building without CONFIG_HOTPLUG_CPU

[Haojian Zhuang]

On Thu, Mar 20, 2014 at 3:29 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> The hisi SMP code always uses the hi3xxx_set_cpu() function
> defined in the hotplug.c file, so we cannot build without
> this when CONFIG_SMP is enabled. This patch slightly restructures
> the code so we always build the parts of hotplug.c that we need
> but just leave out the CPU disable logic if CONFIG_HOTPLUG_CPU
> is turned off.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
> ---
>  arch/arm/mach-hisi/Makefile  | 3 +--
>  arch/arm/mach-hisi/hotplug.c | 2 ++
>  2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-hisi/Makefile b/arch/arm/mach-hisi/Makefile
> index 6870058..2ae1b59 100644
> --- a/arch/arm/mach-hisi/Makefile
> +++ b/arch/arm/mach-hisi/Makefile
> @@ -3,5 +3,4 @@
>  #
>
>  obj-y  += hisilicon.o
> -obj-$(CONFIG_SMP)              += platsmp.o
> -obj-$(CONFIG_HOTPLUG_CPU)      += hotplug.o
> +obj-$(CONFIG_SMP)              += platsmp.o hotplug.o
> diff --git a/arch/arm/mach-hisi/hotplug.c b/arch/arm/mach-hisi/hotplug.c
> index b909854..abd441b 100644
> --- a/arch/arm/mach-hisi/hotplug.c
> +++ b/arch/arm/mach-hisi/hotplug.c
> @@ -178,6 +178,7 @@ static inline void cpu_enter_lowpower(void)
>           : "cc");
>  }
>
> +#ifdef CONFIG_HOTPLUG_CPU
>  void hi3xxx_cpu_die(unsigned int cpu)
>  {
>         cpu_enter_lowpower();
> @@ -198,3 +199,4 @@ int hi3xxx_cpu_kill(unsigned int cpu)
>         hi3xxx_set_cpu(cpu, false);
>         return 1;
>  }
> +#endif
> --
> 1.8.3.2
>

Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com>

[PATCH 34/62] ARM: pxa: select I2C_GPIO only if I2C is on

[Haojian Zhuang]

On Thu, Mar 20, 2014 at 3:29 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> The Arcom/Eurotech VIPER SBC enables the I2C_GPIO driver, but
> that has a dependency on I2C, and causes build failures if I2C
> is disabled. To keep existing configurations running while fixing
> the randconfig problems, this changes the logic to only enable
> I2C_GPIO if I2C is already enabled.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Eric Miao <eric.y.miao@gmail.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
> Cc: Daniel Mack <zonque@gmail.com>
> ---
>  arch/arm/mach-pxa/Kconfig | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
> index 50f6132..8d9f4f1 100644
> --- a/arch/arm/mach-pxa/Kconfig
> +++ b/arch/arm/mach-pxa/Kconfig
> @@ -73,8 +73,7 @@ config ARCH_PXA_IDP
>  config ARCH_VIPER
>         bool "Arcom/Eurotech VIPER SBC"
>         select ARCOM_PCMCIA
> -       select HAVE_PWM
> -       select I2C_GPIO
> +       select I2C_GPIO if I2C=y
>         select ISA
>         select PXA25x
>         select PXA_HAVE_ISA_IRQS
> --
> 1.8.3.2
>

Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com>

[PATCH 45/62] ARM: s3c24xx: MINI2440 needs I2C for EEPROM_AT24

[Kukjin Kim]

Arnd Bergmann wrote:
> 
> If I2C is disabled, we cannot build the AT24 driver, so we
> should not select it.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Kukjin Kim <kgene.kim@samsung.com>

Acked-by: Kukjin Kim <kgene.kim@samsung.com>

Thanks,
Kukjin

> Cc: Ben Dooks <ben-linux@fluff.org>
> ---
>  arch/arm/mach-s3c24xx/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
> index bb1fa603..a6060d0 100644
> --- a/arch/arm/mach-s3c24xx/Kconfig
> +++ b/arch/arm/mach-s3c24xx/Kconfig
> @@ -536,7 +536,7 @@ config MACH_AT2440EVB
> 
>  config MACH_MINI2440
>  	bool "MINI2440 development board"
> -	select EEPROM_AT24
> +	select EEPROM_AT24 if I2C
>  	select LEDS_CLASS
>  	select LEDS_TRIGGERS
>  	select LEDS_TRIGGER_BACKLIGHT
> --
> 1.8.3.2

[PATCH 46/62] ARM: s3c24xx: fix gta02 build error

[Kukjin Kim]

Arnd Bergmann wrote:
> 
> The gta02 has always been broken in the case when CONFIG_PCF50633_ADC
> is not used, since gta02_charger_worker then passes a nonexisting
> variable into the pcf50633_mbc_usb_curlim_set() function.
> 
> This addresses the obvious typo by using the variable that is
> used everywhere else in this file.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Kukjin Kim <kgene.kim@samsung.com>

Acked-by: Kukjin Kim <kgene.kim@samsung.com>

Thanks,
Kukjin

> Cc: Ben Dooks <ben-linux@fluff.org>
> ---
>  arch/arm/mach-s3c24xx/mach-gta02.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-s3c24xx/mach-gta02.c b/arch/arm/mach-
> s3c24xx/mach-gta02.c
> index 8e05813..dc4db84 100644
> --- a/arch/arm/mach-s3c24xx/mach-gta02.c
> +++ b/arch/arm/mach-s3c24xx/mach-gta02.c
> @@ -196,7 +196,7 @@ static void gta02_charger_worker(struct work_struct
> *work)
>  	 * If the PCF50633 ADC is disabled we fallback to a
>  	 * 100mA limit for safety.
>  	 */
> -	pcf50633_mbc_usb_curlim_set(pcf, 100);
> +	pcf50633_mbc_usb_curlim_set(gta02_pcf, 100);
>  #endif
>  }
> 
> --
> 1.8.3.2

Re: [PATCH 60/62] ARM: shmobile: work around CONFIG_PHYLIB=m

[Simon Horman]

On Wed, Mar 19, 2014 at 08:29:57PM +0100, Arnd Bergmann wrote:
> When phylib is set to be built as a module, the lager and koelsch
> boards fail to build:
> 
> arch/arm/mach-shmobile/built-in.o: In function `lager_ksz8041_fixup':
> :(.text+0x738): undefined reference to `mdiobus_read'
> :(.text+0x73c): undefined reference to `mdiobus_write'
> arch/arm/mach-shmobile/built-in.o: In function `koelsch_ksz8041_fixup':
> :(.text+0x7e8): undefined reference to `mdiobus_read'
> :(.text+0x7ec): undefined reference to `mdiobus_write'
> 
> To work around that problem, this changes the code to check for
> IS_BUILTIN rather than IS_ENABLED, turning the error into a runtime
> problem. It's now possible to build random configurations, but the
> phy may be set up incorrectly in this case.

I wonder if Kconfig for koelsch should be tightened up somehow to
ensure that PHYLIB is either unselected or builtin.

Also, a minor nit, I would prefer changes for different boards
in different patches. But I can split the patch myself if its
not going to be changed otherwise.

> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Simon Horman <horms@verge.net.au>
> Cc: Magnus Damm <magnus.damm@gmail.com>
> Cc: linux-sh@vger.kernel.org
> ---
>  arch/arm/mach-shmobile/board-koelsch.c | 2 +-
>  arch/arm/mach-shmobile/board-lager.c   | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-shmobile/board-koelsch.c b/arch/arm/mach-shmobile/board-koelsch.c
> index 5a034ff..b724f33 100644
> --- a/arch/arm/mach-shmobile/board-koelsch.c
> +++ b/arch/arm/mach-shmobile/board-koelsch.c
> @@ -510,7 +510,7 @@ static void __init koelsch_init(void)
>  
>  	irq_set_irq_type(irq_pin(0), IRQ_TYPE_LEVEL_LOW);
>  
> -	if (IS_ENABLED(CONFIG_PHYLIB))
> +	if (IS_BUILTIN(CONFIG_PHYLIB))
>  		phy_register_fixup_for_id("r8a7791-ether-ff:01",
>  					  koelsch_ksz8041_fixup);
>  }
> diff --git a/arch/arm/mach-shmobile/board-lager.c b/arch/arm/mach-shmobile/board-lager.c
> index f0104bf..67b1069 100644
> --- a/arch/arm/mach-shmobile/board-lager.c
> +++ b/arch/arm/mach-shmobile/board-lager.c
> @@ -869,7 +869,7 @@ static void __init lager_init(void)
>  
>  	irq_set_irq_type(irq_pin(0), IRQ_TYPE_LEVEL_LOW);
>  
> -	if (IS_ENABLED(CONFIG_PHYLIB))
> +	if (IS_BUILTIN(CONFIG_PHYLIB))
>  		phy_register_fixup_for_id("r8a7790-ether-ff:01",
>  					  lager_ksz8041_fixup);
>  }
> -- 
> 1.8.3.2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

[PATCH 60/62] ARM: shmobile: work around CONFIG_PHYLIB=m

[Simon Horman]

On Wed, Mar 19, 2014 at 08:29:57PM +0100, Arnd Bergmann wrote:
> When phylib is set to be built as a module, the lager and koelsch
> boards fail to build:
> 
> arch/arm/mach-shmobile/built-in.o: In function `lager_ksz8041_fixup':
> :(.text+0x738): undefined reference to `mdiobus_read'
> :(.text+0x73c): undefined reference to `mdiobus_write'
> arch/arm/mach-shmobile/built-in.o: In function `koelsch_ksz8041_fixup':
> :(.text+0x7e8): undefined reference to `mdiobus_read'
> :(.text+0x7ec): undefined reference to `mdiobus_write'
> 
> To work around that problem, this changes the code to check for
> IS_BUILTIN rather than IS_ENABLED, turning the error into a runtime
> problem. It's now possible to build random configurations, but the
> phy may be set up incorrectly in this case.

I wonder if Kconfig for koelsch should be tightened up somehow to
ensure that PHYLIB is either unselected or builtin.

Also, a minor nit, I would prefer changes for different boards
in different patches. But I can split the patch myself if its
not going to be changed otherwise.

> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Simon Horman <horms@verge.net.au>
> Cc: Magnus Damm <magnus.damm@gmail.com>
> Cc: linux-sh at vger.kernel.org
> ---
>  arch/arm/mach-shmobile/board-koelsch.c | 2 +-
>  arch/arm/mach-shmobile/board-lager.c   | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-shmobile/board-koelsch.c b/arch/arm/mach-shmobile/board-koelsch.c
> index 5a034ff..b724f33 100644
> --- a/arch/arm/mach-shmobile/board-koelsch.c
> +++ b/arch/arm/mach-shmobile/board-koelsch.c
> @@ -510,7 +510,7 @@ static void __init koelsch_init(void)
>  
>  	irq_set_irq_type(irq_pin(0), IRQ_TYPE_LEVEL_LOW);
>  
> -	if (IS_ENABLED(CONFIG_PHYLIB))
> +	if (IS_BUILTIN(CONFIG_PHYLIB))
>  		phy_register_fixup_for_id("r8a7791-ether-ff:01",
>  					  koelsch_ksz8041_fixup);
>  }
> diff --git a/arch/arm/mach-shmobile/board-lager.c b/arch/arm/mach-shmobile/board-lager.c
> index f0104bf..67b1069 100644
> --- a/arch/arm/mach-shmobile/board-lager.c
> +++ b/arch/arm/mach-shmobile/board-lager.c
> @@ -869,7 +869,7 @@ static void __init lager_init(void)
>  
>  	irq_set_irq_type(irq_pin(0), IRQ_TYPE_LEVEL_LOW);
>  
> -	if (IS_ENABLED(CONFIG_PHYLIB))
> +	if (IS_BUILTIN(CONFIG_PHYLIB))
>  		phy_register_fixup_for_id("r8a7790-ether-ff:01",
>  					  lager_ksz8041_fixup);
>  }
> -- 
> 1.8.3.2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

[PATCH 47/62] ARM: s3c64xx: MACH_SMDK6400 needs HSMMC1

[Kukjin Kim]

Arnd Bergmann wrote:
> 
> This board uses both MMC controllers, so we need to enable
> the Kconfig option to define the platform data.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Kukjin Kim <kgene.kim@samsung.com>
> Cc: Ben Dooks <ben-linux@fluff.org>
> ---
>  arch/arm/mach-s3c64xx/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
> index 64f04e6..92885d7 100644
> --- a/arch/arm/mach-s3c64xx/Kconfig
> +++ b/arch/arm/mach-s3c64xx/Kconfig
> @@ -87,6 +87,7 @@ config MACH_SMDK6400
>  	select CPU_S3C6400
>  	select S3C64XX_SETUP_SDHCI
>  	select S3C_DEV_HSMMC
> +	select S3C_DEV_HSMMC1
>  	select S3C_DEV_NAND

Well, only HSMMC ch1 is used on smdk6400 and S3C_DEV_NAND is not needed.

So should be following:

diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
index 64f04e6..3136d86 100644
--- a/arch/arm/mach-s3c64xx/Kconfig
+++ b/arch/arm/mach-s3c64xx/Kconfig
@@ -86,8 +86,7 @@ config MACH_SMDK6400
        bool "SMDK6400"
 	select CPU_S3C6400
 	select S3C64XX_SETUP_SDHCI
-	select S3C_DEV_HSMMC
-	select S3C_DEV_NAND
+	select S3C_DEV_HSMMC1
 	help
 	  Machine support for the Samsung SMDK6400

Thanks,
Kukjin

>  	help
>  	  Machine support for the Samsung SMDK6400
> --
> 1.8.3.2

[PATCH 48/62] ARM: s3c64xx: select power domains only when used

[Kukjin Kim]

Arnd Bergmann wrote:
> 
> The power domain code is only available when CONFIG_PM
> is enabled, so we must not select that unconditionally for
> s3c64xx. Changing it to 'select PM_GENERIC_DOMAINS if PM'
> mirrors what we do on other platforms, and fixes a possible
> randconfig build bug.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Kukjin Kim <kgene.kim@samsung.com>

Acked-by: Kukjin Kim <kgene.kim@samsung.com>

Thanks,
Kukjin

> Cc: Ben Dooks <ben-linux@fluff.org>
> ---
>  arch/arm/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 4721007..6ffcadd 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -764,7 +764,7 @@ config ARCH_S3C64XX
>  	select HAVE_TCM
>  	select NO_IOPORT
>  	select PLAT_SAMSUNG
> -	select PM_GENERIC_DOMAINS
> +	select PM_GENERIC_DOMAINS if PM
>  	select S3C_DEV_NAND
>  	select S3C_GPIO_TRACK
>  	select SAMSUNG_ATAGS
> --
> 1.8.3.2

[PATCH 49/62] ARM: s5p64x0: fix building with only one soc type

[Kukjin Kim]

Arnd Bergmann wrote:
> 
> The s5p64x0 platform supports two distinct SoCs, s5p6440 and s5p6450,
> and in the normal configuration, both are enabled. However if we build
> a kernel that only enables one of the two, the #ifdef logic in common.c
> breaks down, as some of the functions declared in the header are defined
> to NULL using the preprocessor but then defined anyway.
> 
> This patch cleans up the mess and ensures that each function has either
> exactly one C declaration and one matching C definition, or we have
> a NULL defined function pointer but no C definition.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Kukjin Kim <kgene.kim@samsung.com>

Yes you're right, we need to sort them(6440 and 6450) out later though.

Acked-by: Kukjin Kim <kgene.kim@samsung.com>

Thanks,
Kukjin

> Cc: Ben Dooks <ben-linux@fluff.org>
> ---
>  arch/arm/mach-s5p64x0/common.c | 18 ++++++++++++++++--
>  arch/arm/mach-s5p64x0/common.h |  5 +----
>  2 files changed, 17 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/mach-s5p64x0/common.c b/arch/arm/mach-
> s5p64x0/common.c
> index eb2ad14..9a43be0 100644
> --- a/arch/arm/mach-s5p64x0/common.c
> +++ b/arch/arm/mach-s5p64x0/common.c
> @@ -205,6 +205,7 @@ void __init s5p64x0_init_io(struct map_desc
*mach_desc,
> int size)
>  	samsung_pwm_set_platdata(&s5p64x0_pwm_variant);
>  }
> 
> +#ifdef CONFIG_CPU_S5P6440
>  void __init s5p6440_map_io(void)
>  {
>  	/* initialize any device information early */
> @@ -218,7 +219,9 @@ void __init s5p6440_map_io(void)
> 
>  	iotable_init(s5p6440_iodesc, ARRAY_SIZE(s5p6440_iodesc));
>  }
> +#endif
> 
> +#ifdef CONFIG_CPU_S5P6450
>  void __init s5p6450_map_io(void)
>  {
>  	/* initialize any device information early */
> @@ -232,13 +235,14 @@ void __init s5p6450_map_io(void)
> 
>  	iotable_init(s5p6450_iodesc, ARRAY_SIZE(s5p6450_iodesc));
>  }
> +#endif
> 
>  /*
>   * s5p64x0_init_clocks
>   *
>   * register and setup the CPU clocks
>   */
> -
> +#ifdef CONFIG_CPU_S5P6440
>  void __init s5p6440_init_clocks(int xtal)
>  {
>  	printk(KERN_DEBUG "%s: initializing clocks\n", __func__);
> @@ -248,7 +252,9 @@ void __init s5p6440_init_clocks(int xtal)
>  	s5p6440_register_clocks();
>  	s5p6440_setup_clocks();
>  }
> +#endif
> 
> +#ifdef CONFIG_CPU_S5P6450
>  void __init s5p6450_init_clocks(int xtal)
>  {
>  	printk(KERN_DEBUG "%s: initializing clocks\n", __func__);
> @@ -258,13 +264,14 @@ void __init s5p6450_init_clocks(int xtal)
>  	s5p6450_register_clocks();
>  	s5p6450_setup_clocks();
>  }
> +#endif
> 
>  /*
>   * s5p64x0_init_irq
>   *
>   * register the CPU interrupts
>   */
> -
> +#ifdef CONFIG_CPU_S5P6440
>  void __init s5p6440_init_irq(void)
>  {
>  	/* S5P6440 supports 2 VIC */
> @@ -279,7 +286,9 @@ void __init s5p6440_init_irq(void)
> 
>  	s5p_init_irq(vic, ARRAY_SIZE(vic));
>  }
> +#endif
> 
> +#ifdef CONFIG_CPU_S5P6450
>  void __init s5p6450_init_irq(void)
>  {
>  	/* S5P6450 supports only 2 VIC */
> @@ -294,6 +303,7 @@ void __init s5p6450_init_irq(void)
> 
>  	s5p_init_irq(vic, ARRAY_SIZE(vic));
>  }
> +#endif
> 
>  struct bus_type s5p64x0_subsys = {
>  	.name		= "s5p64x0-core",
> @@ -321,6 +331,7 @@ int __init s5p64x0_init(void)
>  }
> 
>  /* uart registration process */
> +#ifdef CONFIG_CPU_S5P6440
>  void __init s5p6440_init_uarts(struct s3c2410_uartcfg *cfg, int no)
>  {
>  	int uart;
> @@ -332,11 +343,14 @@ void __init s5p6440_init_uarts(struct
> s3c2410_uartcfg *cfg, int no)
> 
>  	s3c24xx_init_uartdevs("s3c6400-uart", s5p_uart_resources, cfg, no);
>  }
> +#endif
> 
> +#ifdef CONFIG_CPU_S5P6450
>  void __init s5p6450_init_uarts(struct s3c2410_uartcfg *cfg, int no)
>  {
>  	s3c24xx_init_uartdevs("s3c6400-uart", s5p_uart_resources, cfg, no);
>  }
> +#endif
> 
>  #define eint_offset(irq)	((irq) - IRQ_EINT(0))
> 
> diff --git a/arch/arm/mach-s5p64x0/common.h b/arch/arm/mach-
> s5p64x0/common.h
> index f3a9b43..cbe7f3d 100644
> --- a/arch/arm/mach-s5p64x0/common.h
> +++ b/arch/arm/mach-s5p64x0/common.h
> @@ -25,10 +25,10 @@ void s5p6450_register_clocks(void);
>  void s5p6450_setup_clocks(void);
> 
>  void s5p64x0_restart(enum reboot_mode mode, const char *cmd);
> +extern  int s5p64x0_init(void);
> 
>  #ifdef CONFIG_CPU_S5P6440
> 
> -extern  int s5p64x0_init(void);
>  extern void s5p6440_map_io(void);
>  extern void s5p6440_init_clocks(int xtal);
> 
> @@ -38,12 +38,10 @@ extern void s5p6440_init_uarts(struct s3c2410_uartcfg
> *cfg, int no);
>  #define s5p6440_init_clocks NULL
>  #define s5p6440_init_uarts NULL
>  #define s5p6440_map_io NULL
> -#define s5p64x0_init NULL
>  #endif
> 
>  #ifdef CONFIG_CPU_S5P6450
> 
> -extern  int s5p64x0_init(void);
>  extern void s5p6450_map_io(void);
>  extern void s5p6450_init_clocks(int xtal);
> 
> @@ -53,7 +51,6 @@ extern void s5p6450_init_uarts(struct s3c2410_uartcfg
> *cfg, int no);
>  #define s5p6450_init_clocks NULL
>  #define s5p6450_init_uarts NULL
>  #define s5p6450_map_io NULL
> -#define s5p64x0_init NULL
>  #endif
> 
>  #endif /* __ARCH_ARM_MACH_S5P64X0_COMMON_H */
> --
> 1.8.3.2

[PATCH 50/62] ARM: s5pv210: enable IDE support in MACH_TORBRECK

[Kukjin Kim]

Arnd Bergmann wrote:
> 
> Building MACH_TORBRECK by itself results in a build error
> because we try to reference the s3c_device_cfcon definition
> that is hidden inside CONFIG_SAMSUNG_DEV_IDE. This changes
> the Kconfig logic to ensure that option is enabled when we
> need it.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Kukjin Kim <kgene.kim@samsung.com>

Acked-by: Kukjin Kim <kgene.kim@samsung.com>

Thanks,
Kukjin

> Cc: Ben Dooks <ben-linux@fluff.org>
> ---
>  arch/arm/mach-s5pv210/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/mach-s5pv210/Kconfig b/arch/arm/mach-s5pv210/Kconfig
> index caaedaf..8c3abe5 100644
> --- a/arch/arm/mach-s5pv210/Kconfig
> +++ b/arch/arm/mach-s5pv210/Kconfig
> @@ -189,6 +189,7 @@ config MACH_TORBRECK
>  	select S5PV210_SETUP_I2C1
>  	select S5PV210_SETUP_I2C2
>  	select S5PV210_SETUP_SDHCI
> +	select SAMSUNG_DEV_IDE
>  	help
>  	  Machine support for aESOP Torbreck
> 
> --
> 1.8.3.2

[PATCH 51/62] ARM: samsung: allow serial driver to be disabled

[Kukjin Kim]

Arnd Bergmann wrote:
> 
> If CONFIG_SERIAL_SAMSUNG is disabled, we run into build errors
> with some samsung platforms. This adds a couple of #ifdef
> statements to hopefully deal with this more gracefully.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Kukjin Kim <kgene.kim@samsung.com>

Looks good to me,

Acked-by: Kukjin Kim <kgene.kim@samsung.com>

Thanks,
Kukjin

> Cc: Ben Dooks <ben-linux@fluff.org>
> ---
>  arch/arm/mach-s3c64xx/irq-pm.c | 12 +++++++++---
>  arch/arm/mach-s5p64x0/irq-pm.c |  6 ++++++
>  arch/arm/plat-samsung/init.c   |  4 ++++
>  3 files changed, 19 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/mach-s3c64xx/irq-pm.c b/arch/arm/mach-s3c64xx/irq-
> pm.c
> index a61247b..ae4ea76 100644
> --- a/arch/arm/mach-s3c64xx/irq-pm.c
> +++ b/arch/arm/mach-s3c64xx/irq-pm.c
> @@ -55,7 +55,13 @@ static struct irq_grp_save {
>  	u32	mask;
>  } eint_grp_save[5];
> 
> -static u32 irq_uart_mask[CONFIG_SERIAL_SAMSUNG_UARTS];
> +#ifndef CONFIG_SERIAL_SAMSUNG_UARTS
> +#define SERIAL_SAMSUNG_UARTS 0
> +#else
> +#define	SERIAL_SAMSUNG_UARTS CONFIG_SERIAL_SAMSUNG_UARTS
> +#endif
> +
> +static u32 irq_uart_mask[SERIAL_SAMSUNG_UARTS];
> 
>  static int s3c64xx_irq_pm_suspend(void)
>  {
> @@ -66,7 +72,7 @@ static int s3c64xx_irq_pm_suspend(void)
> 
>  	s3c_pm_do_save(irq_save, ARRAY_SIZE(irq_save));
> 
> -	for (i = 0; i < CONFIG_SERIAL_SAMSUNG_UARTS; i++)
> +	for (i = 0; i < SERIAL_SAMSUNG_UARTS; i++)
>  		irq_uart_mask[i] = __raw_readl(S3C_VA_UARTx(i) +
> S3C64XX_UINTM);
> 
>  	for (i = 0; i < ARRAY_SIZE(eint_grp_save); i++, grp++) {
> @@ -87,7 +93,7 @@ static void s3c64xx_irq_pm_resume(void)
> 
>  	s3c_pm_do_restore(irq_save, ARRAY_SIZE(irq_save));
> 
> -	for (i = 0; i < CONFIG_SERIAL_SAMSUNG_UARTS; i++)
> +	for (i = 0; i < SERIAL_SAMSUNG_UARTS; i++)
>  		__raw_writel(irq_uart_mask[i], S3C_VA_UARTx(i) +
> S3C64XX_UINTM);
> 
>  	for (i = 0; i < ARRAY_SIZE(eint_grp_save); i++, grp++) {
> diff --git a/arch/arm/mach-s5p64x0/irq-pm.c b/arch/arm/mach-s5p64x0/irq-
> pm.c
> index 1c83d28..2ed921e 100644
> --- a/arch/arm/mach-s5p64x0/irq-pm.c
> +++ b/arch/arm/mach-s5p64x0/irq-pm.c
> @@ -34,7 +34,9 @@ static struct irq_grp_save {
>  	u32	mask;
>  } eint_grp_save[4];
> 
> +#ifdef CONFIG_SERIAL_SAMSUNG
>  static u32 irq_uart_mask[CONFIG_SERIAL_SAMSUNG_UARTS];
> +#endif
> 
>  static int s5p64x0_irq_pm_suspend(void)
>  {
> @@ -45,8 +47,10 @@ static int s5p64x0_irq_pm_suspend(void)
> 
>  	s3c_pm_do_save(irq_save, ARRAY_SIZE(irq_save));
> 
> +#ifdef CONFIG_SERIAL_SAMSUNG
>  	for (i = 0; i < CONFIG_SERIAL_SAMSUNG_UARTS; i++)
>  		irq_uart_mask[i] = __raw_readl(S3C_VA_UARTx(i) +
> S3C64XX_UINTM);
> +#endif
> 
>  	for (i = 0; i < ARRAY_SIZE(eint_grp_save); i++, grp++) {
>  		grp->con = __raw_readl(S5P64X0_EINT12CON + (i * 4));
> @@ -66,8 +70,10 @@ static void s5p64x0_irq_pm_resume(void)
> 
>  	s3c_pm_do_restore(irq_save, ARRAY_SIZE(irq_save));
> 
> +#ifdef CONFIG_SERIAL_SAMSUNG
>  	for (i = 0; i < CONFIG_SERIAL_SAMSUNG_UARTS; i++)
>  		__raw_writel(irq_uart_mask[i], S3C_VA_UARTx(i) +
> S3C64XX_UINTM);
> +#endif
> 
>  	for (i = 0; i < ARRAY_SIZE(eint_grp_save); i++, grp++) {
>  		__raw_writel(grp->con, S5P64X0_EINT12CON + (i * 4));
> diff --git a/arch/arm/plat-samsung/init.c b/arch/arm/plat-samsung/init.c
> index 0ffc84a..c32df1f 100644
> --- a/arch/arm/plat-samsung/init.c
> +++ b/arch/arm/plat-samsung/init.c
> @@ -96,7 +96,9 @@ void __init s3c24xx_init_clocks(int xtal)
>  #if IS_ENABLED(CONFIG_SAMSUNG_ATAGS)
>  static int nr_uarts __initdata = 0;
> 
> +#ifdef CONFIG_SERIAL_SAMSUNG_UARTS
>  static struct s3c2410_uartcfg uart_cfgs[CONFIG_SERIAL_SAMSUNG_UARTS];
> +#endif
> 
>  /* s3c24xx_init_uartdevs
>   *
> @@ -111,6 +113,7 @@ void __init s3c24xx_init_uartdevs(char *name,
>  				  struct s3c24xx_uart_resources *res,
>  				  struct s3c2410_uartcfg *cfg, int no)
>  {
> +#ifdef CONFIG_SERIAL_SAMSUNG_UARTS
>  	struct platform_device *platdev;
>  	struct s3c2410_uartcfg *cfgptr = uart_cfgs;
>  	struct s3c24xx_uart_resources *resp;
> @@ -133,6 +136,7 @@ void __init s3c24xx_init_uartdevs(char *name,
>  	}
> 
>  	nr_uarts = no;
> +#endif
>  }
> 
>  void __init s3c24xx_init_uarts(struct s3c2410_uartcfg *cfg, int no)
> --
> 1.8.3.2

[PATCH 52/62] ARM: samsung: disable decompressor watchdog on exynos

[Kukjin Kim]

Arnd Bergmann wrote:
> 
> The S3C_BOOT_ERROR_RESET option only works when using the
> samsung specific mach/uncompress.h implementation. The
> Exynos platform has now moved on to using the generic
> implementation instead, which does not support this.
> 
Yeah, correct and I've applied to use the generic uncompress for other
Samsung SoCs into samsung tree and I sent to arm-soc a couple of days ago.
Even though it is not cleaned for regarding configs e.g.,
S3C_BOOT_ERROR_RESET yet, this is not used more.

Thanks,
Kukjin

> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Kukjin Kim <kgene.kim@samsung.com>
> Cc: Ben Dooks <ben-linux@fluff.org>
> ---
>  arch/arm/plat-samsung/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
> index 58645a5..04974db 100644
> --- a/arch/arm/plat-samsung/Kconfig
> +++ b/arch/arm/plat-samsung/Kconfig
> @@ -42,6 +42,7 @@ comment "Boot options"
> 
>  config S3C_BOOT_ERROR_RESET
>  	bool "S3C Reboot on decompression error"
> +	depends on PLAT_S5P || PLAT_S3C24XX || ARCH_S3C64XX
>  	help
>  	  Say y here to use the watchdog to reset the system if the
>  	  kernel decompressor detects an error during decompression.
> --
> 1.8.3.2

[PATCH 53/62] ARM: samsung: fix SAMSUNG_PM_DEBUG Kconfig logic

[Kukjin Kim]

Arnd Bergmann wrote:
> 
> The suspend debug code for Samsung has multiple dependencies
> that we should not unconditionally enable. In particular,
> we rely on the DEBUG_S3C_UART setting, which in turn depends
> on the samsung UART driver.
> 
> Signed-off-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Kukjin Kim <kgene.kim@samsung.com>

Yes, right.

Acked-by: Kukjin Kim <kgene.kim@samsung.com>

Thanks,
Kukjin

> Cc: Ben Dooks <ben-linux@fluff.org>
> ---
>  arch/arm/plat-samsung/Kconfig | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
> index 04974db..c72d612 100644
> --- a/arch/arm/plat-samsung/Kconfig
> +++ b/arch/arm/plat-samsung/Kconfig
> @@ -428,8 +428,7 @@ comment "Power management"
> 
>  config SAMSUNG_PM_DEBUG
>  	bool "S3C2410 PM Suspend debug"
> -	depends on PM
> -	select DEBUG_LL
> +	depends on PM && DEBUG_KERNEL && DEBUG_S3C_UART
>  	help
>  	  Say Y here if you want verbose debugging from the PM Suspend and
>  	  Resume code. See <file:Documentation/arm/Samsung-
> S3C24XX/Suspend.txt>
> --
> 1.8.3.2

[PATCH 54/62] ARM: samsung: select ATAGS where necessary

[Kukjin Kim]

Arnd Bergmann wrote:
> 
> Most of the Samsung platforms do not yet allow building with
> DT at all, so we should select CONFIG_ATAGS for now in all
> cases we also select CONFIG_SAMSUNG_ATAGS.
> 
> Found during randconfig testing.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Kukjin Kim <kgene.kim@samsung.com>

Acked-by: Kukjin Kim <kgene.kim@samsung.com>

Thanks,
Kukjin

> Cc: Ben Dooks <ben-linux@fluff.org>
> ---
>  arch/arm/Kconfig | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 6ffcadd..3fb9b7e 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -731,6 +731,7 @@ config ARCH_S3C24XX
>  	bool "Samsung S3C24XX SoCs"
>  	select ARCH_HAS_CPUFREQ
>  	select ARCH_REQUIRE_GPIOLIB
> +	select ATAGS
>  	select CLKDEV_LOOKUP
>  	select CLKSRC_SAMSUNG_PWM
>  	select GENERIC_CLOCKEVENTS
> @@ -753,6 +754,7 @@ config ARCH_S3C64XX
>  	select ARCH_REQUIRE_GPIOLIB
>  	select ARM_AMBA
>  	select ARM_VIC
> +	select ATAGS
>  	select CLKDEV_LOOKUP
>  	select CLKSRC_SAMSUNG_PWM
>  	select COMMON_CLK
> @@ -776,6 +778,7 @@ config ARCH_S3C64XX
> 
>  config ARCH_S5P64X0
>  	bool "Samsung S5P6440 S5P6450"
> +	select ATAGS
>  	select CLKDEV_LOOKUP
>  	select CLKSRC_SAMSUNG_PWM
>  	select CPU_V6
> @@ -794,6 +797,7 @@ config ARCH_S5P64X0
>  config ARCH_S5PC100
>  	bool "Samsung S5PC100"
>  	select ARCH_REQUIRE_GPIOLIB
> +	select ATAGS
>  	select CLKDEV_LOOKUP
>  	select CLKSRC_SAMSUNG_PWM
>  	select CPU_V7
> @@ -813,6 +817,7 @@ config ARCH_S5PV210
>  	select ARCH_HAS_CPUFREQ
>  	select ARCH_HAS_HOLES_MEMORYMODEL
>  	select ARCH_SPARSEMEM_ENABLE
> +	select ATAGS
>  	select CLKDEV_LOOKUP
>  	select CLKSRC_SAMSUNG_PWM
>  	select CPU_V7
> --
> 1.8.3.2

[PATCH 55/62] ARM: samsung: select CRC32 for SAMSUNG_PM_CHECK

[Kukjin Kim]

Arnd Bergmann wrote:
> 
> The Samsung pm_check code uses the crc32 library code, which can
> be built as a loadable module, in which case we get a link error
> building the kernel.
> 
> A better solution is to use 'select CRC32', which is what all
> other users of this code do, as it ensures it is always built-in.
> 
Agreed.

> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Kukjin Kim <kgene.kim@samsung.com>

Acked-by: Kukjin Kim <kgene.kim@samsung.com>

Thanks,
Kukjin

> Cc: Ben Dooks <ben-linux@fluff.org>
> ---
>  arch/arm/plat-samsung/Kconfig | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
> index c72d612..98f223c 100644
> --- a/arch/arm/plat-samsung/Kconfig
> +++ b/arch/arm/plat-samsung/Kconfig
> @@ -445,7 +445,8 @@ config S3C_PM_DEBUG_LED_SMDK
> 
>  config SAMSUNG_PM_CHECK
>  	bool "S3C2410 PM Suspend Memory CRC"
> -	depends on PM && CRC32
> +	depends on PM
> +	select CRC32
>  	help
>  	  Enable the PM code's memory area checksum over sleep. This option
>  	  will generate CRCs of all blocks of memory, and store them before
> --
> 1.8.3.2

[PATCH 56/62] ARM: samsung: select I2C where needed for PMIC

[Kukjin Kim]

Arnd Bergmann wrote:
> 
> The OSIRIS machine cannot build without I2C and
> TPS65010 both enabled unconditionally.
> 
> The SMDK6410_WM1190_EV1 and SMDK6410_WM1192_EV1 add-on
> cards already select MFD_WM*_I2C.
> 
> In each case, failing to enable CONFIG_I2C results in a
> build or link error, so most consistent solution is to
> ensure that it is impossible to disable those options.
> 
> It would be nice to leave CONFIG_I2C as user-selectable,
> but doing that properly would require more work.
> 
Yes, OK.

> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Kukjin Kim <kgene.kim@samsung.com>

Acked-by: Kukjin Kim <kgene.kim@samsung.com>

Thanks,
Kukjin

> Cc: Ben Dooks <ben-linux@fluff.org>
> ---
>  arch/arm/mach-s3c24xx/Kconfig | 1 +
>  arch/arm/mach-s3c64xx/Kconfig | 2 ++
>  2 files changed, 3 insertions(+)
> 
> diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
> index a6060d0..1272647 100644
> --- a/arch/arm/mach-s3c24xx/Kconfig
> +++ b/arch/arm/mach-s3c24xx/Kconfig
> @@ -572,6 +572,7 @@ config MACH_OSIRIS_DVS
>  	tristate "Simtec IM2440D20 (OSIRIS) Dynamic Voltage Scaling driver"
>  	depends on MACH_OSIRIS
>  	select TPS65010
> +	select I2C
>  	help
>  	  Say Y/M here if you want to have dynamic voltage scaling support
>  	  on the Simtec IM2440D20 (OSIRIS) module via the TPS65011.
> diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
> index 92885d7..0148112 100644
> --- a/arch/arm/mach-s3c64xx/Kconfig
> +++ b/arch/arm/mach-s3c64xx/Kconfig
> @@ -191,6 +191,7 @@ endchoice
>  config SMDK6410_WM1190_EV1
>  	bool "Support Wolfson Microelectronics 1190-EV1 PMIC card"
>  	depends on MACH_SMDK6410
> +	select I2C
>  	select MFD_WM8350_I2C
>  	select REGULATOR
>  	select REGULATOR_WM8350
> @@ -205,6 +206,7 @@ config SMDK6410_WM1190_EV1
>  config SMDK6410_WM1192_EV1
>  	bool "Support Wolfson Microelectronics 1192-EV1 PMIC card"
>  	depends on MACH_SMDK6410
> +	select I2C
>  	select MFD_WM831X
>  	select MFD_WM831X_I2C
>  	select REGULATOR
> --
> 1.8.3.2

[PATCH 57/62] ARM: exynos: fix l2x0 saved regs handling

[Kukjin Kim]

Arnd Bergmann wrote:
> 
> The exynos4_l2x0_cache_init function tries to flush the data cache
> for the location of the saved l2x0 registers and pass the physical
> address to the s5p-sleep implementation.
> 
> However, the s5p-sleep code is optional, and if it is disabled,
> we get a linker error here when the l2x0_regs_phys variable does
> not exist.
> 
> To solve this, use a compile-time conditional to drop this code
> if we don't want it.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Kukjin Kim <kgene.kim@samsung.com>

Acked-by: Kukjin Kim <kgene.kim@samsung.com>

Thanks,
Kukjin

> Cc: Ben Dooks <ben-linux@fluff.org>
> ---
>  arch/arm/mach-exynos/common.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
> index 025fd82..b2f9bb0 100644
> --- a/arch/arm/mach-exynos/common.c
> +++ b/arch/arm/mach-exynos/common.c
> @@ -404,8 +404,10 @@ static int __init exynos4_l2x0_cache_init(void)
>  	if (ret)
>  		return ret;
> 
> -	l2x0_regs_phys = virt_to_phys(&l2x0_saved_regs);
> -	clean_dcache_area(&l2x0_regs_phys, sizeof(unsigned long));
> +	if (IS_ENABLED(CONFIG_S5P_SLEEP)) {
> +		l2x0_regs_phys = virt_to_phys(&l2x0_saved_regs);
> +		clean_dcache_area(&l2x0_regs_phys, sizeof(unsigned long));
> +	}
>  	return 0;
>  }
>  early_initcall(exynos4_l2x0_cache_init);
> --
> 1.8.3.2

[PATCH 58/62] ARM: exynos: add missing include of linux/module.h

[Kukjin Kim]

Arnd Bergmann wrote:
> 
> After the restructuring of the module.h and init.h headers,
> we now need to include this explicitly here.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Kukjin Kim <kgene.kim@samsung.com>

Acked-by: Kukjin Kim <kgene.kim@samsung.com>

Arnd,

If you want me to take this fixes for Samsung stuff into samsung tree,
please let me know.

Thanks,
Kukjin

> Cc: Ben Dooks <ben-linux@fluff.org>
> ---
>  arch/arm/mach-exynos/cpuidle.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-
> exynos/cpuidle.c
> index f57cb91..93d2dec 100644
> --- a/arch/arm/mach-exynos/cpuidle.c
> +++ b/arch/arm/mach-exynos/cpuidle.c
> @@ -14,6 +14,7 @@
>  #include <linux/cpu_pm.h>
>  #include <linux/io.h>
>  #include <linux/export.h>
> +#include <linux/module.h>
>  #include <linux/time.h>
>  #include <linux/platform_device.h>
> 
> --
> 1.8.3.2

[PATCH 06/62] ARM: davinci: export da8xx_syscfg0_base

[Arnd Bergmann]

On Thursday 20 March 2014 01:36:13 Sergei Shtylyov wrote:
> On 03/19/2014 11:21 PM, Arnd Bergmann wrote:
> > The question is whether there is anyone who would do this properly.
> 
>     Nobody cares, it seems. As you can imagine, I stopped to care enough after 
> being switched to other projects.

I only care about it because I have the intention to get all 'randconfig'
kernels to build eventually. For stuff that is definitely 'legacy'
and won't get cleaned up properly, I'm fine with a hack.

> > Both the OHCI and MUSB drivers use exactly one register (CFGCHIP2)
> 
>     The idea at the time was to just ioremap() this register but I was not 
> very eager.

Yes, that would work, too. However, that would cause problems later
if we ever try to make the davinci platform "multiplatform", unless we also
pass the physical address in a platform resource and make this a larger
driver. I think we can reasonably have an exported set of functions
declared in the platform data header file for these drivers, but passing
the physical address through a header file wouldn't be much of an improvement
over passing the virtual address.

> There was no USB PHY driver subsystem yet.
> 
> > to control the clock, phy
> 
>     Note that it only controls PHY clock (PLL) which could be covered by an 
> USB PHY driver.

Good point.

> > and host/gadget mode switch.
> 
>     The main mode the USB 2.0 PHY should function now is OTG. The host/gadged 
> modes are forced overrides of the ID pin. Unfortunately, the board code has to 
> force host mode when host-only driver config is selected (these MUSB's 
> host/gadget only modes were removed at one point but got reintroduced again).

I think they are also required for 'randconfig' builds to some degree, because
you can build a kernel without host mode for instance.

> > In the modern world, we'd probably want to have a clock driver and
> 
>     Not sure about the clock driver...
>
> > a phy driver for these,
> 
>     Yes, that's what the MUSB maintainer wants too. The issue is the driver 
> should somehow differ which USB controller it's bound too and do different 
> things depending on that (at least that's how it looks now). I'm not sure it's 
> possible, so probably should be rethought.

Yes, a phy driver seems the right approach if we can find someone to do it.
Ideally that should let us use generic versions of the ohci and musb drivers
even, if that's the only davinci specific part of these drivers.

> > based on a syscon driver.
> 
>     I don't know what syscon is...

The syscon (system controller) framework helps share a set of registers
across multiple drivers. If all accesses to the CFGCHIP2 register are
in a single PHY driver, we wouldn't need it.

> > In all honesty I don't see that happening on davinci.
> 
>     I don't think people use USB 1.1 controllers these days, especially when 
> there is USB 2.0 in the same SoC. For MUSB, there were recent attempt to get 
> the DA8xx driver out of the broken state but it was turned down as well, IIRC, 
> since it didn't offer a PHY driver.

For USB 2.0 compliance you actually need to provide something to handle the
low speed modes. A lot of people use a hub to do that nowadays rather than
an OHCI or UHCI, but I don't know if that works with OTG.

	Arnd

[PATCH 14/62] ARM: imx: imx6q_set_lpm is only defined for CONFIG_PM=y

[Shawn Guo]

On Wed, Mar 19, 2014 at 08:29:11PM +0100, Arnd Bergmann wrote:
> This ensures that we only call imx6q_set_lpm if CONFIG_PM
> is enabled and we are building the pm-imx6q.c file.
> 
> Another fix that has been suggested for this is to always
> build this file conditionally build only the parts of it
> that are relevant only to CONFIG_PM.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Shawn Guo <shawn.guo@freescale.com>
> Cc: Sascha Hauer <kernel@pengutronix.de>

I think this should have been fixed by commit 28a9f3b (ARM: imx6: build
pm-imx6q.c independently of CONFIG_PM) on mainline.

Shawn

> ---
>  arch/arm/mach-imx/clk-imx6q.c      | 3 ++-
>  arch/arm/mach-imx/clk-imx6sl.c     | 3 ++-
>  arch/arm/mach-imx/cpuidle-imx6sl.c | 3 +++
>  3 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
> index b0e7f9d..133b23e 100644
> --- a/arch/arm/mach-imx/clk-imx6q.c
> +++ b/arch/arm/mach-imx/clk-imx6q.c
> @@ -478,7 +478,8 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
>  		clk_set_parent(clk[lvds1_sel], clk[sata_ref]);
>  
>  	/* Set initial power mode */
> -	imx6q_set_lpm(WAIT_CLOCKED);
> +	if (IS_ENABLED(CONFIG_PM))
> +		imx6q_set_lpm(WAIT_CLOCKED);
>  
>  	np = of_find_compatible_node(NULL, NULL, "fsl,imx6q-gpt");
>  	base = of_iomap(np, 0);
> diff --git a/arch/arm/mach-imx/clk-imx6sl.c b/arch/arm/mach-imx/clk-imx6sl.c
> index f7073c0..a882bdf 100644
> --- a/arch/arm/mach-imx/clk-imx6sl.c
> +++ b/arch/arm/mach-imx/clk-imx6sl.c
> @@ -382,7 +382,8 @@ static void __init imx6sl_clocks_init(struct device_node *ccm_node)
>  	clk_set_parent(clks[IMX6SL_CLK_SPDIF0_SEL], clks[IMX6SL_CLK_PLL3_PFD3]);
>  
>  	/* Set initial power mode */
> -	imx6q_set_lpm(WAIT_CLOCKED);
> +	if (IS_ENABLED(CONFIG_PM))
> +		imx6q_set_lpm(WAIT_CLOCKED);
>  
>  	np = of_find_compatible_node(NULL, NULL, "fsl,imx6sl-gpt");
>  	base = of_iomap(np, 0);
> diff --git a/arch/arm/mach-imx/cpuidle-imx6sl.c b/arch/arm/mach-imx/cpuidle-imx6sl.c
> index d4b6b81..c9a6aa8 100644
> --- a/arch/arm/mach-imx/cpuidle-imx6sl.c
> +++ b/arch/arm/mach-imx/cpuidle-imx6sl.c
> @@ -53,5 +53,8 @@ static struct cpuidle_driver imx6sl_cpuidle_driver = {
>  
>  int __init imx6sl_cpuidle_init(void)
>  {
> +	if (!IS_ENABLED(CONFIG_PM))
> +		return -ENOSYS;
> +
>  	return cpuidle_register(&imx6sl_cpuidle_driver, NULL);
>  }
> -- 
> 1.8.3.2
> 
> 
> 

[PATCH 01/62] ARM: at91: split out at91x40 into a top-level option

[Nicolas Ferre]

On 19/03/2014 20:28, Arnd Bergmann :
> at91x40 is different from all the other at91 machines, and it is
> impossible to build a kernel that works on both this SoC and
> any of the others, even though it is possible to build a noMMU
> kernel for any at91 machine.
> 
> By turning at91x40 into a separate top-level option, we explicitly
> forbid enabling invalid configurations that include mutually exclusive
> machines.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Andrew Victor <linux@maxim.org.za>
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>

I added below little modifications to the comments, now that the AT91X40
is another entry.

Otherwise:

Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>

> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> ---
>  arch/arm/mach-at91/Kconfig        | 22 ++++++++++++++++++----
>  arch/arm/mach-at91/Kconfig.non_dt |  8 +-------
>  2 files changed, 19 insertions(+), 11 deletions(-)
> 
> diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
> index ae6617e..7209c5b 100644
> --- a/arch/arm/mach-at91/Kconfig
> +++ b/arch/arm/mach-at91/Kconfig
> @@ -64,11 +64,22 @@ choice
>  
>  	prompt "Core type"
>  
> +config ARCH_AT91X40
> +	bool "ARM7/ARM9 AT91X40"

AT91X40 is an ARM7TDMI, so you can remove the alternative here:

+	bool "ARM7 AT91X40"

seems better.


> +	depends on !MMU
> +	select CPU_ARM7TDMI
> +	select ARCH_USES_GETTIMEOFFSET
> +	select MULTI_IRQ_HANDLER
> +	select SPARSE_IRQ
> +
> +	help
> +	  Select this if you are using one of Atmel's AT91X40 SoC.
> +
>  config SOC_SAM_V4_V5
> -	bool "ARM7/ARM9"
> +	bool "ARM7/ARM9 AT91SAM9/AT91RM9200"

Now that we have only ARM9s here, remove the alternative:

+	bool "ARM9 AT91SAM9/AT91RM9200"


>  	help
> -	  Select this if you are using one of Atmel's AT91SAM9, AT91RM9200
> -	  or AT91X40 SoC.
> +	  Select this if you are using one of Atmel's AT91SAM9 or
> +	  AT91RM9200 SoC.
>  
>  config SOC_SAM_V7
>  	bool "Cortex A5"
> @@ -177,9 +188,12 @@ config SOC_AT91SAM9N12
>  	  Select this if you are using Atmel's AT91SAM9N12 SoC.
>  
>  # ----------------------------------------------------------
> +endif # SOC_SAM_V4_V5
> +
>  
> +if SOC_SAM_V4_V5 || ARCH_AT91X40
>  source arch/arm/mach-at91/Kconfig.non_dt
> -endif # SOC_SAM_V4_V5
> +endif
>  
>  comment "Generic Board Type"
>  
> diff --git a/arch/arm/mach-at91/Kconfig.non_dt b/arch/arm/mach-at91/Kconfig.non_dt
> index 1f73e9b..44ace32 100644
> --- a/arch/arm/mach-at91/Kconfig.non_dt
> +++ b/arch/arm/mach-at91/Kconfig.non_dt
> @@ -5,6 +5,7 @@ config HAVE_AT91_DATAFLASH_CARD
>  
>  choice
>  	prompt "Atmel AT91 Processor Devices for non DT boards"
> +	depends on !ARCH_AT91X40
>  
>  config ARCH_AT91_NONE
>  	bool "None"
> @@ -39,13 +40,6 @@ config ARCH_AT91SAM9G45
>  	select SOC_AT91SAM9G45
>  	select AT91_USE_OLD_CLK
>  
> -config ARCH_AT91X40
> -	bool "AT91x40"
> -	depends on !MMU
> -	select ARCH_USES_GETTIMEOFFSET
> -	select MULTI_IRQ_HANDLER
> -	select SPARSE_IRQ
> -
>  endchoice
>  
>  config ARCH_AT91SAM9G20
> 


-- 
Nicolas Ferre

[PATCH 02/62] ARM: at91: don't provide dt init code for at91x40

[Nicolas Ferre]

On 19/03/2014 20:28, Arnd Bergmann :
> at91x40 has no support for device tree, but Kconfig allows
> us to enable CONFIG_OF anyway, causing a link error in the
> at91 reset controller initialization.
> 
> The easiest fix is to adapt the existing #ifdef to omit
> the broken code on at91x40 where it is never called anyway.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Andrew Victor <linux@maxim.org.za>
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>

Yes, simple and does the trick:

Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>

> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> ---
>  arch/arm/mach-at91/setup.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-at91/setup.c b/arch/arm/mach-at91/setup.c
> index f7ca97b..f7a07a5 100644
> --- a/arch/arm/mach-at91/setup.c
> +++ b/arch/arm/mach-at91/setup.c
> @@ -351,7 +351,7 @@ void __init at91_ioremap_matrix(u32 base_addr)
>  		panic("Impossible to ioremap at91_matrix_base\n");
>  }
>  
> -#if defined(CONFIG_OF)
> +#if defined(CONFIG_OF) && !defined(CONFIG_ARCH_AT91X40)
>  static struct of_device_id rstc_ids[] = {
>  	{ .compatible = "atmel,at91sam9260-rstc", .data = at91sam9_alt_restart },
>  	{ .compatible = "atmel,at91sam9g45-rstc", .data = at91sam9g45_restart },
> 


-- 
Nicolas Ferre

[PATCH 03/62] ARM: at91: export sam9_smc interfaces

[Nicolas Ferre]

On 19/03/2014 20:29, Arnd Bergmann :
> The pata_at91 driver uses interfaces defined in the sam9_smc
> platform code. Since the pata driver can be a loadable module,
> we have to export those symbols in order to link cleanly.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Andrew Victor <linux@maxim.org.za>
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>

SMC may change in the near future (Cf. Jean-Jacques' patches sent some
weeks ago). But I do not think this patch conflicts with the ongoing
initiative...

So:

Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>

> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> ---
>  arch/arm/mach-at91/sam9_smc.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm/mach-at91/sam9_smc.c b/arch/arm/mach-at91/sam9_smc.c
> index b26156b..826315a 100644
> --- a/arch/arm/mach-at91/sam9_smc.c
> +++ b/arch/arm/mach-at91/sam9_smc.c
> @@ -36,6 +36,7 @@ void sam9_smc_write_mode(int id, int cs,
>  {
>  	sam9_smc_cs_write_mode(AT91_SMC_CS(id, cs), config);
>  }
> +EXPORT_SYMBOL_GPL(sam9_smc_write_mode);
>  
>  static void sam9_smc_cs_configure(void __iomem *base,
>  					struct sam9_smc_config *config)
> @@ -69,6 +70,7 @@ void sam9_smc_configure(int id, int cs,
>  {
>  	sam9_smc_cs_configure(AT91_SMC_CS(id, cs), config);
>  }
> +EXPORT_SYMBOL_GPL(sam9_smc_configure);
>  
>  static void sam9_smc_cs_read_mode(void __iomem *base,
>  					struct sam9_smc_config *config)
> @@ -84,6 +86,7 @@ void sam9_smc_read_mode(int id, int cs,
>  {
>  	sam9_smc_cs_read_mode(AT91_SMC_CS(id, cs), config);
>  }
> +EXPORT_SYMBOL_GPL(sam9_smc_read_mode);
>  
>  static void sam9_smc_cs_read(void __iomem *base,
>  					struct sam9_smc_config *config)
> 


-- 
Nicolas Ferre

[PATCH 04/62] ARM: at91: fix broken "if () else" statement

[Nicolas Ferre]

On 19/03/2014 20:29, Arnd Bergmann :
> If CONFIG_PATA_AT91 is disabled, the code in at91_add_device_cf
> is turned into invalid C statements due to the lack of an
> expression before the 'else' clause.
> 
> This moves the first half of the condition inside of the #ifdef,
> which seems to be what the author intended.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Andrew Victor <linux@maxim.org.za>
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>

Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>

> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> ---
>  arch/arm/mach-at91/at91sam9260_devices.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-at91/at91sam9260_devices.c b/arch/arm/mach-at91/at91sam9260_devices.c
> index 2ae7715..4222a7d 100644
> --- a/arch/arm/mach-at91/at91sam9260_devices.c
> +++ b/arch/arm/mach-at91/at91sam9260_devices.c
> @@ -1263,13 +1263,13 @@ void __init at91_add_device_cf(struct at91_cf_data *data)
>  	at91_set_A_periph(AT91_PIN_PC10, 0);    /* CFRNW */
>  	at91_set_A_periph(AT91_PIN_PC15, 1);    /* NWAIT */
>  
> -	if (data->flags & AT91_CF_TRUE_IDE)
>  #if defined(CONFIG_PATA_AT91) || defined(CONFIG_PATA_AT91_MODULE)
> +	if (data->flags & AT91_CF_TRUE_IDE)
>  		pdev->name = "pata_at91";
> +	else
>  #else
>  #warning "board requires AT91_CF_TRUE_IDE: enable pata_at91"
>  #endif
> -	else
>  		pdev->name = "at91_cf";
>  
>  	platform_device_register(pdev);
> 


-- 
Nicolas Ferre

[PATCH 05/62] ARM: at91: sama5 always uses DT

[Nicolas Ferre]

On 19/03/2014 20:29, Arnd Bergmann :
> It makes no sense for sama5 support to be enabled if we don't
> also enable USE_OF. Making this automatic in Kconfig avoids
> a possible randconfig conflict between the old and new clock
> support code.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Andrew Victor <linux@maxim.org.za>
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>

Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>

> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> ---
>  arch/arm/mach-at91/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
> index 7209c5b..5ec1da1 100644
> --- a/arch/arm/mach-at91/Kconfig
> +++ b/arch/arm/mach-at91/Kconfig
> @@ -57,6 +57,7 @@ config SOC_SAMA5
>  	select GENERIC_CLOCKEVENTS
>  	select MULTI_IRQ_HANDLER
>  	select SPARSE_IRQ
> +	select USE_OF
>  
>  menu "Atmel AT91 System-on-Chip"
>  
> 


-- 
Nicolas Ferre

[PATCH 06/62] ARM: davinci: export da8xx_syscfg0_base

[Sekhar Nori]

Hi Arnd,

On Thursday 20 March 2014 01:51 AM, Arnd Bergmann wrote:
> On Wednesday 19 March 2014 23:53:18 Sergei Shtylyov wrote:
>> On 03/19/2014 10:29 PM, Arnd Bergmann wrote:
>>
>>> The ohci-da8xx driver uses the DA8XX_SYSCFG0_VIRT macro to
>>> access the CFGCHIP2 register for controlling its PHY.
>>
>>> The macro in turn relies on the da8xx_syscfg0_base global
>>> variable. Since the OHCI driver can be a loadable module,
>>> this requires the symbol to be exported from platform code.
>>
>>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>>> Cc: Sekhar Nori <nsekhar@ti.com>
>>> Cc: Kevin Hilman <khilman@deeprootsystems.com>
>>> Cc: davinci-linux-open-source at linux.davincidsp.com
>>> ---
>>>   arch/arm/mach-davinci/devices-da8xx.c | 1 +
>>>   1 file changed, 1 insertion(+)
>>
>>> diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
>>> index 0486cdf..4da868a 100644
>>> --- a/arch/arm/mach-davinci/devices-da8xx.c
>>> +++ b/arch/arm/mach-davinci/devices-da8xx.c
>>> @@ -66,6 +66,7 @@
>>>   #define DA850_DMA_MMCSD1_TX EDMA_CTLR_CHAN(1, 29)
>>>
>>>   void __iomem *da8xx_syscfg0_base;
>>> +EXPORT_SYMBOL_GPL(da8xx_syscfg0_base); /* used by OHCI_HCD */
>>
>>     I have submitted such patch years ago and it was turned down. 
>>
> 
> The question is whether there is anyone who would do this properly.
> 
> Both the OHCI and MUSB drivers use exactly one register (CFGCHIP2)
> to control the clock, phy and host/gadget mode switch.
> 
> In the modern world, we'd probably want to have a clock driver and
> a phy driver for these, based on a syscon driver.
> 
> In all honesty I don't see that happening on davinci.
> 
> A somewhat better approach would be to export a set of exported
> functions to access the one register from the platform, e.g.
> 
> u32 da8xx_cfgchip2_get(void);
> void da8xx_cfgchip2_set(u32);
> 
> That interface would still be a bit ugly, but much better than
> what we have today, and easy to implement.

There is another thing we can do albeit in the driver (see patch).
Not sure how the USB maintainer will feel about it but I think this
has the advantage of not creating any hacky interfaces. And it
leaves me with the hope that someone will find the time to convert
to phy driver based on syscon at some point.

Thanks,
Sekhar

---8<---
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 3586460..c807d3f 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1178,7 +1178,8 @@ MODULE_LICENSE ("GPL");
 #define SA1111_DRIVER          ohci_hcd_sa1111_driver
 #endif
 
-#ifdef CONFIG_ARCH_DAVINCI_DA8XX
+/* DA8XX uses platform internal symbols. Cannot be built as module. */
+#if defined(CONFIG_ARCH_DAVINCI_DA8XX) && !defined(CONFIG_USB_OHCI_HCD_MODULE)
 #include "ohci-da8xx.c"
 #define DAVINCI_PLATFORM_DRIVER        ohci_hcd_da8xx_driver
 #endif

[PATCH 06/62] ARM: davinci: export da8xx_syscfg0_base

[Sekhar Nori]

On Thursday 20 March 2014 12:12 PM, Arnd Bergmann wrote:
> On Thursday 20 March 2014 01:36:13 Sergei Shtylyov wrote:
>> On 03/19/2014 11:21 PM, Arnd Bergmann wrote:
>>> The question is whether there is anyone who would do this properly.
>>
>>     Nobody cares, it seems. As you can imagine, I stopped to care enough after 
>> being switched to other projects.
> 
> I only care about it because I have the intention to get all 'randconfig'
> kernels to build eventually. For stuff that is definitely 'legacy'
> and won't get cleaned up properly, I'm fine with a hack.
> 
>>> Both the OHCI and MUSB drivers use exactly one register (CFGCHIP2)
>>
>>     The idea at the time was to just ioremap() this register but I was not 
>> very eager.
> 
> Yes, that would work, too. However, that would cause problems later
> if we ever try to make the davinci platform "multiplatform", unless we also
> pass the physical address in a platform resource and make this a larger

Some SATA driver work done by Bartlomiej Zolnierkiewicz needed driver
access to syscfg registers too and I just asked him to pass the physical
addresses using platform resource. I think thats the best bet we have in
the absence of a modern interface.

> The syscon (system controller) framework helps share a set of registers
> across multiple drivers. If all accesses to the CFGCHIP2 register are
> in a single PHY driver, we wouldn't need it.

CFGCHIP2 has controls both for USB 1.1 (OHCI) and USB 2.0 (MUSB). Not
sure if there can be a single PHY driver for both.

Thanks,
Sekhar

[PATCH 44/62] ARM: integrator: refine CPU selection

[Arnd Bergmann]

On Wednesday 19 March 2014, Arnd Bergmann wrote:
> On Wednesday 19 March 2014 20:49:47 Russell King - ARM Linux wrote:
> > On Wed, Mar 19, 2014 at 08:29:41PM +0100, Arnd Bergmann wrote:
> > > This adds a new Kconfig option for the Integrator platform to
> > > choose between ARMv4/ARMv5 based CPUs and those based on ARMv6/ARMv7,
> > > which is required because we cannot have both classes enabled in the
> > > same kernel at compile time.
> > 
> > Wouldn't it just be easier to make the older CPUs depend on
> > !CPU_V6 && !CPU_V7 rather than trying to hack this for each platform?
> 
> It's only two platforms: integrator and realview. Actually I took two
> different approaches on these, and wanted to make up my mind first
> which one is better. Any suggestion?
> 
> I have a mild preference to always using 'select' on the CPU_* symbol
> from the platform, mostly for consistency. The downside is that it
> gets a little messy for Integrator, but that's just one platform in
> the end.
> 
> At some point, I think I got into circular dependencies when one CPU
> depended on another one being disabled, but I don't remember exactly
> what case that was.
> 

Nevermind, I'll drop this patch for now, I just had an idea to do it
better: Since Linus and I are trying to get Integrator and Realview
moved over into ARCH_MULTIPLATFORM anyway, I'll defer the CPU selection
question until that's done.

Within ARCH_MULTIPLATFORM, we already want to deal with booting machines
that are described entirely in DT and have no platform specific code,
but we also want to be able to select the CPU types built into the
kernel for them.

For the v6/v6k/v7 selection, we can do this through the top-level
multiplatform options we already have, as we don't expose the
differences between the individual core implementations for the most
part. We can potentially leave PJ4 and PJ4B as user-selectable.

For the v4/v4t/v5 selection, I would allow any CPU to be manually
enabled with a dependency on the ARCH_MULTI_V* option. Platforms
that know what they have should obviously keep selecting the one
they want. I would leave strongarm and xscale out of the selection,
because I don't expect any platform based on those cores to ever
become enabled for ARCH_MULTIPLATFORM, but all the others should
be selectable.

For the moment, I'll keep using my patches locally in order to
keep randconfig building, and I'll follow up with a new patch
after integrator and realview are part of multiplatform. That
may take a while, but I'm sure we'll get there eventually.

	Arnd

Re: [PATCH 62/62] ARM: tegra: make debug_ll code build for ARMv6

[Arnd Bergmann]

On Wednesday 19 March 2014, Stephen Warren wrote:
> On 03/19/2014 01:51 PM, Arnd Bergmann wrote:
> > On Wednesday 19 March 2014 13:40:06 Stephen Warren wrote:
> >> Hmmm. This code is guaranteed to only execute on Tegra (well, perhaps
> >> someone can turn on the wrong debug option and run it on non-Tegra, but
> >> then it's guaranteed not to work since the HW it touches doesn't exist).
> >> As such, the code ought to be able to use ARMv7 instructions.
> >>
> >> As a fix for similar issues in assembly code in arch/arm/mach-tegra/*.S,
> >> Makefile there does:
> >>
> >> asflags-y                               += -march=armv7-a
> >>
> >> (I think you added that? Yes, in 408e713545ca "ARM: tegra: build
> >> assembly files with -march=armv7-a")
> >>
> >> Shouldn't we use the same fix in this case too?
> > 
> > That was my first idea, but I couldn't come up with a nice way to do this
> > for arch/arm/kernel/debug.S, which #includes the specific implementation.
> > 
> > I'd rather not put lots of per-platform hacks into arch/arm/kernel/Makefile.
> 
> Oh, I guess the fact it's include makes it a bit more painful.
> 
> You could deal with it in Kconfig reasonably easily by having each of
> DEBUG_*_UART select a config option indicating how to compile code that
> includes DEBUG_LL_INCLUDE, and then have the Makefiles set up asflags
> based on those. Still, that would be a lot of work and this patch is
> simpler.
> 
> Tested-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> Acked-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>

Ok, thanks for testing! I'm always cautious aobut my own assembly skills,
so I'm glad this worked.

	Arnd

[PATCH 62/62] ARM: tegra: make debug_ll code build for ARMv6

[Arnd Bergmann]

On Wednesday 19 March 2014, Stephen Warren wrote:
> On 03/19/2014 01:51 PM, Arnd Bergmann wrote:
> > On Wednesday 19 March 2014 13:40:06 Stephen Warren wrote:
> >> Hmmm. This code is guaranteed to only execute on Tegra (well, perhaps
> >> someone can turn on the wrong debug option and run it on non-Tegra, but
> >> then it's guaranteed not to work since the HW it touches doesn't exist).
> >> As such, the code ought to be able to use ARMv7 instructions.
> >>
> >> As a fix for similar issues in assembly code in arch/arm/mach-tegra/*.S,
> >> Makefile there does:
> >>
> >> asflags-y                               += -march=armv7-a
> >>
> >> (I think you added that? Yes, in 408e713545ca "ARM: tegra: build
> >> assembly files with -march=armv7-a")
> >>
> >> Shouldn't we use the same fix in this case too?
> > 
> > That was my first idea, but I couldn't come up with a nice way to do this
> > for arch/arm/kernel/debug.S, which #includes the specific implementation.
> > 
> > I'd rather not put lots of per-platform hacks into arch/arm/kernel/Makefile.
> 
> Oh, I guess the fact it's include makes it a bit more painful.
> 
> You could deal with it in Kconfig reasonably easily by having each of
> DEBUG_*_UART select a config option indicating how to compile code that
> includes DEBUG_LL_INCLUDE, and then have the Makefiles set up asflags
> based on those. Still, that would be a lot of work and this patch is
> simpler.
> 
> Tested-by: Stephen Warren <swarren@nvidia.com>
> Acked-by: Stephen Warren <swarren@nvidia.com>

Ok, thanks for testing! I'm always cautious aobut my own assembly skills,
so I'm glad this worked.

	Arnd

[PATCH 61/62] ARM: sunxi: fix build for THUMB2_KERNEL

[Arnd Bergmann]

On Wednesday 19 March 2014, Rob Herring wrote:

> > --- a/arch/arm/mach-sunxi/headsmp.S
> > +++ b/arch/arm/mach-sunxi/headsmp.S
> > @@ -4,6 +4,7 @@
> >          .section ".text.head", "ax"
> >
> >  ENTRY(sun6i_secondary_startup)
> > -       msr     cpsr_fsxc, #0xd3
> > +       mov     r0, #0xd3
> > +       msr     cpsr_fsxc, r0
> >         b       secondary_startup
> 
> Secondary cores should always enter the kernel in ARM mode like the
> primary core, right? So we need the same switching to Thumb2 as
> head.S, but even secondary_startup doesn't do any switching. So either
> platforms jump into the kernel with a bx and happen to work or
> secondary boot is broken for Thumb2 kernels.

Makes sense. So should we instead do this?

.arm
ENTRY(sun6i_secondary_startup)
	ARM_BE8(setend   be ) /* I suppose we need this too */
	msr     cpsr_fsxc, #0xd3
	ldr	r0, =secondary_startup
	bx	r0

(I'm a bit confused about when to use what branch instruction, so
forgive me if the above doesn't make sense)

> Also, secondary_startup takes care of making sure the core is in SVC
> mode, so this function shouldn't be needed in the first place.

I'd rather not change this part, unless Maxime can confirm that it's
not necessary. I would assume that it's there for a reason otherwise.

	Arnd

[PATCH 06/62] ARM: davinci: export da8xx_syscfg0_base

[Arnd Bergmann]

On Thursday 20 March 2014, Sekhar Nori wrote:
> On Thursday 20 March 2014 12:12 PM, Arnd Bergmann wrote:
> > On Thursday 20 March 2014 01:36:13 Sergei Shtylyov wrote:
> >> On 03/19/2014 11:21 PM, Arnd Bergmann wrote:
> >>> The question is whether there is anyone who would do this properly.
> >>
> >>     Nobody cares, it seems. As you can imagine, I stopped to care enough after 
> >> being switched to other projects.
> > 
> > I only care about it because I have the intention to get all 'randconfig'
> > kernels to build eventually. For stuff that is definitely 'legacy'
> > and won't get cleaned up properly, I'm fine with a hack.
> > 
> >>> Both the OHCI and MUSB drivers use exactly one register (CFGCHIP2)
> >>
> >>     The idea at the time was to just ioremap() this register but I was not 
> >> very eager.
> > 
> > Yes, that would work, too. However, that would cause problems later
> > if we ever try to make the davinci platform "multiplatform", unless we also
> > pass the physical address in a platform resource and make this a larger
> 
> Some SATA driver work done by Bartlomiej Zolnierkiewicz needed driver
> access to syscfg registers too and I just asked him to pass the physical
> addresses using platform resource. I think thats the best bet we have in
> the absence of a modern interface.

Ok.

> > The syscon (system controller) framework helps share a set of registers
> > across multiple drivers. If all accesses to the CFGCHIP2 register are
> > in a single PHY driver, we wouldn't need it.
> 
> CFGCHIP2 has controls both for USB 1.1 (OHCI) and USB 2.0 (MUSB). Not
> sure if there can be a single PHY driver for both.

The phy infrastructure explicitly supports multiple consumers for one
phy, if I'm reading the code correctly.

	Arnd

[PATCH 06/62] ARM: davinci: export da8xx_syscfg0_base

[Arnd Bergmann]

On Thursday 20 March 2014, Sekhar Nori wrote:
> There is another thing we can do albeit in the driver (see patch).
> Not sure how the USB maintainer will feel about it but I think this
> has the advantage of not creating any hacky interfaces. And it
> leaves me with the hope that someone will find the time to convert
> to phy driver based on syscon at some point.

Interesting hack.

> diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
> index 3586460..c807d3f 100644
> --- a/drivers/usb/host/ohci-hcd.c
> +++ b/drivers/usb/host/ohci-hcd.c
> @@ -1178,7 +1178,8 @@ MODULE_LICENSE ("GPL");
>  #define SA1111_DRIVER          ohci_hcd_sa1111_driver
>  #endif
>  
> -#ifdef CONFIG_ARCH_DAVINCI_DA8XX
> +/* DA8XX uses platform internal symbols. Cannot be built as module. */
> +#if defined(CONFIG_ARCH_DAVINCI_DA8XX) && !defined(CONFIG_USB_OHCI_HCD_MODULE)
>  #include "ohci-da8xx.c"
>  #define DAVINCI_PLATFORM_DRIVER        ohci_hcd_da8xx_driver
>  #endif

I wouldn't want to submit that patch to GregKH ;-)

How about doing the same thing in a somewhat less sneaky way?

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 0fe936c..857250a 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -417,6 +417,16 @@ config USB_OHCI_HCD_OMAP3
 	  Enables support for the on-chip OHCI controller on
 	  OMAP3 and later chips.
 
+config USB_OHCI_HCD_DAVINCI
+	bool "OHCI support for TI DaVinci DA8xx"
+	depends on ARCH_DAVINCI_DA8XX
+	depends on USB_OHCI_HCD=y
+	default y
+	help
+	  Enables support for the DaVinci DA8xx integrated OHCI
+	  controller. This driver cannot currently be a loadable
+	  module because it lacks a proper PHY abstraction.
+
 config USB_OHCI_ATH79
 	bool "USB OHCI support for the Atheros AR71XX/AR7240 SoCs (DEPRECATED)"
 	depends on (SOC_AR71XX || SOC_AR724X)
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 3586460..f98d03f 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1178,7 +1178,7 @@ MODULE_LICENSE ("GPL");
 #define SA1111_DRIVER		ohci_hcd_sa1111_driver
 #endif
 
-#ifdef CONFIG_ARCH_DAVINCI_DA8XX
+#ifdef CONFIG_USB_OHCI_HCD_DAVINCI
 #include "ohci-da8xx.c"
 #define DAVINCI_PLATFORM_DRIVER	ohci_hcd_da8xx_driver
 #endif

[PATCH 06/62] ARM: davinci: export da8xx_syscfg0_base

[Sekhar Nori]

On Thursday 20 March 2014 05:27 PM, Arnd Bergmann wrote:
> On Thursday 20 March 2014, Sekhar Nori wrote:

>> diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
>> index 3586460..c807d3f 100644
>> --- a/drivers/usb/host/ohci-hcd.c
>> +++ b/drivers/usb/host/ohci-hcd.c
>> @@ -1178,7 +1178,8 @@ MODULE_LICENSE ("GPL");
>>  #define SA1111_DRIVER          ohci_hcd_sa1111_driver
>>  #endif
>>  
>> -#ifdef CONFIG_ARCH_DAVINCI_DA8XX
>> +/* DA8XX uses platform internal symbols. Cannot be built as module. */
>> +#if defined(CONFIG_ARCH_DAVINCI_DA8XX) && !defined(CONFIG_USB_OHCI_HCD_MODULE)
>>  #include "ohci-da8xx.c"
>>  #define DAVINCI_PLATFORM_DRIVER        ohci_hcd_da8xx_driver
>>  #endif
> 
> I wouldn't want to submit that patch to GregKH ;-)
> 
> How about doing the same thing in a somewhat less sneaky way?
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Much better! Please feel free to add

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

if it helps.

Regards,
Sekhar

[PATCH 07/62] ARM: davinci: make dm644x-evm phy fixup conditional

[Sekhar Nori]

On Thursday 20 March 2014 12:59 AM, Arnd Bergmann wrote:
> We cannot call phy_register_fixup_for_uid() if CONFIG_PHYLIB
> is not built into the kernel, and we should not enforce that
> to be built into vmlinux either, because one might want to
> disable the entire network stack.
> 
> This change uses a compile-time condition on CONFIG_PHYLIB
> to remove the call in the cases where it cannot work.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Sekhar Nori <nsekhar@ti.com>
> Cc: Kevin Hilman <khilman@deeprootsystems.com>
> Cc: davinci-linux-open-source at linux.davincidsp.com

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

Thanks,
Sekhar

[PATCH 08/62] ARM: davinci: use explicit 'select' for DA850_EVM

[Sekhar Nori]

On Thursday 20 March 2014 12:59 AM, Arnd Bergmann wrote:
> The DAVINCI_DA850_EVM board uses an unusual method to
> enable the GPIO_PCA953X and KEYBOARD_GPIO_POLLED symbols,
> which leads to the dependencies on these symbols being
> ignored. As GPIO_PCA953X actually requires I2C, that
> can lead to build failures when I2C is disabled.
> 
> This patch removes the duplicate symbol definitions

I am okay with this..

> and instead adds equivalent 'select' statements that
> are conditional on the underlying dependencies.

.. but not sure this is needed. The PCA953X was defaulted to y mainly
because the IO expander was used to detect presence of daughter cards.
Even then, I don't think there is any need to force its selection.

> 
> A different question whether we actually want to automatically
> enable them at all or rather put them into defconfig,
> but that should be a separate patch.

It can be enabled through defconfig as you said. I agree that can be a
separate patch. For now, just dropping the replicated Kconfig symbols
should be okay.

Thanks,
Sekhar

[PATCH 05/62] ARM: at91: sama5 always uses DT

[Jean-Christophe PLAGNIOL-VILLARD]

On Mar 20, 2014, at 3:29 AM, Arnd Bergmann <arnd@arndb.de> wrote:

> 
> It makes no sense for sama5 support to be enabled if we don't
> also enable USE_OF. Making this automatic in Kconfig avoids
> a possible randconfig conflict between the old and new clock
> support code.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Andrew Victor <linux@maxim.org.za>
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> 
> ---
> arch/arm/mach-at91/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
> index 7209c5b..5ec1da1 100644
> --- a/arch/arm/mach-at91/Kconfig
> +++ b/arch/arm/mach-at91/Kconfig
> @@ -57,6 +57,7 @@ config SOC_SAMA5
> 	select GENERIC_CLOCKEVENTS
> 	select MULTI_IRQ_HANDLER
> 	select SPARSE_IRQ
> +	select USE_OF
> 
> menu "Atmel AT91 System-on-Chip"
> 
> -- 
> 1.8.3.2
> 

[PATCH 04/62] ARM: at91: fix broken "if () else" statement

[Jean-Christophe PLAGNIOL-VILLARD]

On Mar 20, 2014, at 3:29 AM, Arnd Bergmann <arnd@arndb.de> wrote:

> 
> If CONFIG_PATA_AT91 is disabled, the code in at91_add_device_cf
> is turned into invalid C statements due to the lack of an
> expression before the 'else' clause.
> 
> This moves the first half of the condition inside of the #ifdef,
> which seems to be what the author intended.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Andrew Victor <linux@maxim.org.za>
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> ---
> arch/arm/mach-at91/at91sam9260_devices.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-at91/at91sam9260_devices.c b/arch/arm/mach-at91/at91sam9260_devices.c
> index 2ae7715..4222a7d 100644
> --- a/arch/arm/mach-at91/at91sam9260_devices.c
> +++ b/arch/arm/mach-at91/at91sam9260_devices.c
> @@ -1263,13 +1263,13 @@ void __init at91_add_device_cf(struct at91_cf_data *data)
> 	at91_set_A_periph(AT91_PIN_PC10, 0);    /* CFRNW */
> 	at91_set_A_periph(AT91_PIN_PC15, 1);    /* NWAIT */
> 
> -	if (data->flags & AT91_CF_TRUE_IDE)
> #if defined(CONFIG_PATA_AT91) || defined(CONFIG_PATA_AT91_MODULE)
> +	if (data->flags & AT91_CF_TRUE_IDE)
I prefer if (IS_ENABLED())
> 		pdev->name = "pata_at91";
> +	else
> #else
> #warning "board requires AT91_CF_TRUE_IDE: enable pata_at91?
but this means drop this warning
> #endif
> -	else
> 		pdev->name = "at91_cf";
> 
> 	platform_device_register(pdev);
> -- 
> 1.8.3.2
> 

[PATCH 06/62] ARM: davinci: export da8xx_syscfg0_base

[Sergei Shtylyov]

Hello.

On 20-03-2014 10:42, Arnd Bergmann wrote:

>>> Both the OHCI and MUSB drivers use exactly one register (CFGCHIP2)

>>      The idea at the time was to just ioremap() this register but I was not
>> very eager.

    ... also it was suggested to pass the CFGCHIP2 address as a resource. I 
certainly wasn't eager to do that since if done for both MUSB and OHCI, it 
would cause sort of a resource conflict (platform device resources are 
automatically registered in the resource tree, although without marking them 
exclusive), even if we don't call request_mem_region() on them (we can't do 
that since in this case the resource would be registered as exclusive, and the 
second call would fail).

> Yes, that would work, too. However, that would cause problems later
> if we ever try to make the davinci platform "multiplatform", unless we also
> pass the physical address in a platform resource and make this a larger
> driver.

    In my opinion, we don't have to pass CFGCHIP2 as a resource and could just 
ioremap() the raw physical address.

> I think we can reasonably have an exported set of functions
> declared in the platform data header file for these drivers, but passing
> the physical address through a header file

    That's how it's passed today (however, thru <mach/da8xx.h>).

> wouldn't be much of an improvement
> over passing the virtual address.

    Not sure I understood about passing virtual address.

>> There was no USB PHY driver subsystem yet.

>>> to control the clock, phy

>>      Note that it only controls PHY clock (PLL) which could be covered by an
>> USB PHY driver.

> Good point.

>>> and host/gadget mode switch.

>>      The main mode the USB 2.0 PHY should function now is OTG. The host/gadged
>> modes are forced overrides of the ID pin. Unfortunately, the board code has to
>> force host mode when host-only driver config is selected (these MUSB's
>> host/gadget only modes were removed at one point but got reintroduced again).

> I think they are also required for 'randconfig' builds to some degree, because
> you can build a kernel without host mode for instance.

    Yes.

>>> In the modern world, we'd probably want to have a clock driver and

>>      Not sure about the clock driver...

>>> a phy driver for these,

>>      Yes, that's what the MUSB maintainer wants too. The issue is the driver
>> should somehow differ which USB controller it's bound too and do different
>> things depending on that (at least that's how it looks now). I'm not sure it's
>> possible, so probably should be rethought.

> Yes, a phy driver seems the right approach if we can find someone to do it.

    Perhaps a person that tried to unbreak the DA8xx MUSB driver could be 
interested (and competent) enough to do it...

> Ideally that should let us use generic versions of the ohci and musb drivers
> even, if that's the only davinci specific part of these drivers.

    No, not really. MUSB ceratinly has DaVinci specific register set mapped in 
its register space. OHCI has up to 2 clocks to enable since USB 1.1 PHY can be 
clocked from USB 2.0 PHY clock.

>>> based on a syscon driver.

>>      I don't know what syscon is...

> The syscon (system controller) framework helps share a set of registers
> across multiple drivers. If all accesses to the CFGCHIP2 register are
> in a single PHY driver, we wouldn't need it.

    Where can I find it in the kernel tree?

>>> In all honesty I don't see that happening on davinci.

>>      I don't think people use USB 1.1 controllers these days, especially when
>> there is USB 2.0 in the same SoC. For MUSB, there were recent attempt to get
>> the DA8xx driver out of the broken state but it was turned down as well, IIRC,
>> since it didn't offer a PHY driver.

> For USB 2.0 compliance you actually need to provide something to handle the
> low speed modes. A lot of people use a hub to do that nowadays rather than
> an OHCI or UHCI, but I don't know if that works with OTG.

    MUSB handles all speeds. I think the reason TI also included USB 1.1 
controller lies in the somewhat dubious reputation of both MUSB hardware and 
the Linux driver.

> 	Arnd

WBR, Sergei

[PATCH 48/62] ARM: s3c64xx: select power domains only when used

[Kukjin Kim]

On 03/20/14 12:56, Kukjin Kim wrote:
> Arnd Bergmann wrote:
>>
>> The power domain code is only available when CONFIG_PM
>> is enabled, so we must not select that unconditionally for
>> s3c64xx. Changing it to 'select PM_GENERIC_DOMAINS if PM'
>> mirrors what we do on other platforms, and fixes a possible
>> randconfig build bug.
>>
>> Signed-off-by: Arnd Bergmann<arnd@arndb.de>
>> Cc: Tomasz Figa<tomasz.figa@gmail.com>
>> Cc: Kukjin Kim<kgene.kim@samsung.com>
>
> Acked-by: Kukjin Kim<kgene.kim@samsung.com>
>

Arnd,

Please drop this patch in your tree because there is a fix before this 
and it fixes SAMSUNG_WAKEMASK dependency together for S3C64XX.

[PATCH v2 5/6] ARM: s3c64xx: Fix incorrect selection of PM-related 
symbols <http://www.spinics.net/lists/arm-kernel/msg316391.html>

Note, I'll take above into 2nd fixes for v3.15 in samsung tree.

If any problems, please kindly let me know.

Thanks,
Kukjin

> Thanks,
> Kukjin
>
>> Cc: Ben Dooks<ben-linux@fluff.org>
>> ---
>>   arch/arm/Kconfig | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index 4721007..6ffcadd 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -764,7 +764,7 @@ config ARCH_S3C64XX
>>   	select HAVE_TCM
>>   	select NO_IOPORT
>>   	select PLAT_SAMSUNG
>> -	select PM_GENERIC_DOMAINS
>> +	select PM_GENERIC_DOMAINS if PM
>>   	select S3C_DEV_NAND
>>   	select S3C_GPIO_TRACK
>>   	select SAMSUNG_ATAGS
>> --
>> 1.8.3.2

[PATCH 06/62] ARM: davinci: export da8xx_syscfg0_base

[Arnd Bergmann]

On Thursday 20 March 2014 21:59:29 Sergei Shtylyov wrote:
> 
>     Yes, it does. The issue is that the PHY code is different in MUSB and OHCI 
> drivers. I don't think the PHY driver knows what device binds to it.

At least in the DT case, it can get that information from DT, when you
set #phy-cells=<1>. I don't know how it would be done for platform_data,
but I assume one could find a way too.

	Arnd

[PATCH 06/62] ARM: davinci: export da8xx_syscfg0_base

[Sergei Shtylyov]

Hello.

On 03/20/2014 02:50 PM, Arnd Bergmann wrote:

>>>>> The question is whether there is anyone who would do this properly.

>>>>      Nobody cares, it seems. As you can imagine, I stopped to care enough after
>>>> being switched to other projects.

>>> I only care about it because I have the intention to get all 'randconfig'
>>> kernels to build eventually. For stuff that is definitely 'legacy'
>>> and won't get cleaned up properly, I'm fine with a hack.

>>>>> Both the OHCI and MUSB drivers use exactly one register (CFGCHIP2)

>>>>      The idea at the time was to just ioremap() this register but I was not
>>>> very eager.

>>> Yes, that would work, too. However, that would cause problems later
>>> if we ever try to make the davinci platform "multiplatform", unless we also
>>> pass the physical address in a platform resource and make this a larger

>> Some SATA driver work done by Bartlomiej Zolnierkiewicz needed driver
>> access to syscfg registers too and I just asked him to pass the physical
>> addresses using platform resource. I think thats the best bet we have in
>> the absence of a modern interface.

> Ok.

    Depends on what SYSCFG register it uses. It wouldn't be good if that 
register range includes CFGCHIP2.

>>> The syscon (system controller) framework helps share a set of registers
>>> across multiple drivers. If all accesses to the CFGCHIP2 register are
>>> in a single PHY driver, we wouldn't need it.

>> CFGCHIP2 has controls both for USB 1.1 (OHCI) and USB 2.0 (MUSB). Not
>> sure if there can be a single PHY driver for both.

> The phy infrastructure explicitly supports multiple consumers for one
> phy, if I'm reading the code correctly.

    Yes, it does. The issue is that the PHY code is different in MUSB and OHCI 
drivers. I don't think the PHY driver knows what device binds to it.

> 	Arnd

WBR, Sergei

[PATCH 06/62] ARM: davinci: export da8xx_syscfg0_base

[Sergei Shtylyov]

Hello.

On 03/20/2014 09:22 PM, Arnd Bergmann wrote:

>>      Yes, it does. The issue is that the PHY code is different in MUSB and OHCI
>> drivers. I don't think the PHY driver knows what device binds to it.

> At least in the DT case, it can get that information from DT, when you
> set #phy-cells=<1>. I don't know how it would be done for platform_data,
> but I assume one could find a way too.

    #phy-cells is only defined for drivers/phy/ bindings IIRC, and I was 
thinking a drivers/usb/phy/ driver so far. Probably you have a point and we 
should go for the generic PHY framework instead. I'm just not very familiar 
with it...

> 	Arnd

WBR, Sergei

[PATCH 06/62] ARM: davinci: export da8xx_syscfg0_base

[Sergei Shtylyov]

On 03/20/2014 07:20 PM, Sergei Shtylyov wrote:

>> The syscon (system controller) framework helps share a set of registers
>> across multiple drivers. If all accesses to the CFGCHIP2 register are
>> in a single PHY driver, we wouldn't need it.

>     Where can I find it in the kernel tree?

    Found it.

WBR, Sergei

[PATCH 10/62] ARM: efm32: select AUTO_ZRELADDR

[Uwe Kleine-König]

Hello Arnd,

On Wed, Mar 19, 2014 at 08:29:07PM +0100, Arnd Bergmann wrote:
> The efm32 platform does not provide a zreladdr-y line its Makefile.boot,
> so we always have to use CONFIG_AUTO_ZRELADDR in order to successfully
> build and link a zImage.
I wonder why you need to AUTO_ZRELADDR (which is there to guess
zreladdr) while efm32 doesn't have an MMU and so there is nothing to
guess. So I think this patch fixes a build problem, but it's not a good
change.

Best regards
Uwe
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Uwe Kleine-K?nig <kernel@pengutronix.de>
> ---
>  arch/arm/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 62ede9b..5776c12 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -422,6 +422,7 @@ config ARCH_EFM32
>  	bool "Energy Micro efm32"
>  	depends on !MMU
>  	select ARCH_REQUIRE_GPIOLIB
> +	select AUTO_ZRELADDR
>  	select ARM_NVIC
>  	select CLKSRC_OF
>  	select COMMON_CLK
> -- 
> 1.8.3.2
> 
> 

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[PATCH 09/62] ARM: efm32: allow uncompress debug output

[Uwe Kleine-König]

On Wed, Mar 19, 2014 at 08:29:06PM +0100, Arnd Bergmann wrote:
> efm32 has no mach/uncompress.h, but we can trivially use
> the fallback to the ll_debug code by just allowing this
> option in Kconfig.
> 
> Found during randconfig testing.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Uwe Kleine-K?nig <kernel@pengutronix.de>
I didn't test it (and in fact I cannot because there is too little RAM
to run a zImage on my board[1]) but the change looks good for a board
having more RAM, so

Acked-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>

[1] maybe it would run long enough to see some output, but meh

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[PATCH 10/62] ARM: efm32: select AUTO_ZRELADDR

[Arnd Bergmann]

On Thursday 20 March 2014 21:48:47 Uwe Kleine-K?nig wrote:
> 
> On Wed, Mar 19, 2014 at 08:29:07PM +0100, Arnd Bergmann wrote:
> > The efm32 platform does not provide a zreladdr-y line its Makefile.boot,
> > so we always have to use CONFIG_AUTO_ZRELADDR in order to successfully
> > build and link a zImage.
> I wonder why you need to AUTO_ZRELADDR (which is there to guess
> zreladdr) while efm32 doesn't have an MMU and so there is nothing to
> guess. So I think this patch fixes a build problem, but it's not a good
> change.

It is required in order to build a compressed zImage file. You mentioned
before that your system does not have enough RAM to support this, but
the compile-time option exists, and there is no dependency on MMU support
for it, nor should there be.

	Arnd

[PATCH 48/62] ARM: s3c64xx: select power domains only when used

[Kukjin Kim]

On 03/21/14 03:14, Kukjin Kim wrote:
> On 03/20/14 12:56, Kukjin Kim wrote:
>> Arnd Bergmann wrote:
>>>
>>> The power domain code is only available when CONFIG_PM
>>> is enabled, so we must not select that unconditionally for
>>> s3c64xx. Changing it to 'select PM_GENERIC_DOMAINS if PM'
>>> mirrors what we do on other platforms, and fixes a possible
>>> randconfig build bug.
>>>
>>> Signed-off-by: Arnd Bergmann<arnd@arndb.de>
>>> Cc: Tomasz Figa<tomasz.figa@gmail.com>
>>> Cc: Kukjin Kim<kgene.kim@samsung.com>
>>
>> Acked-by: Kukjin Kim<kgene.kim@samsung.com>
>>
>
> Arnd,
>
> Please drop this patch in your tree because there is a fix before this
> and it fixes SAMSUNG_WAKEMASK dependency together for S3C64XX.
>
> [PATCH v2 5/6] ARM: s3c64xx: Fix incorrect selection of PM-related
> symbols <http://www.spinics.net/lists/arm-kernel/msg316391.html>
>
> Note, I'll take above into 2nd fixes for v3.15 in samsung tree.
>
> If any problems, please kindly let me know.
>
Oops, Arnd sorry.

Please go ahead with my ack on this because the fix, "[PATCH v2 5/6] 
ARM: s3c64xx: Fix incorrect selection of PM-related symbols" makes a 
build error...I'll look at the problem.

Thanks,
Kukjin


>>
>>> Cc: Ben Dooks<ben-linux@fluff.org>
>>> ---
>>> arch/arm/Kconfig | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>>> index 4721007..6ffcadd 100644
>>> --- a/arch/arm/Kconfig
>>> +++ b/arch/arm/Kconfig
>>> @@ -764,7 +764,7 @@ config ARCH_S3C64XX
>>> select HAVE_TCM
>>> select NO_IOPORT
>>> select PLAT_SAMSUNG
>>> - select PM_GENERIC_DOMAINS
>>> + select PM_GENERIC_DOMAINS if PM
>>> select S3C_DEV_NAND
>>> select S3C_GPIO_TRACK
>>> select SAMSUNG_ATAGS
>>> --
>>> 1.8.3.2

[PATCH 10/62] ARM: efm32: select AUTO_ZRELADDR

[Uwe Kleine-König]

Hello Arnd,

On Thu, Mar 20, 2014 at 11:16:20PM +0100, Arnd Bergmann wrote:
> On Thursday 20 March 2014 21:48:47 Uwe Kleine-K?nig wrote:
> > 
> > On Wed, Mar 19, 2014 at 08:29:07PM +0100, Arnd Bergmann wrote:
> > > The efm32 platform does not provide a zreladdr-y line its Makefile.boot,
> > > so we always have to use CONFIG_AUTO_ZRELADDR in order to successfully
> > > build and link a zImage.
> > I wonder why you need to AUTO_ZRELADDR (which is there to guess
> > zreladdr) while efm32 doesn't have an MMU and so there is nothing to
> > guess. So I think this patch fixes a build problem, but it's not a good
> > change.
> 
> It is required in order to build a compressed zImage file. You mentioned
> before that your system does not have enough RAM to support this, but
> the compile-time option exists, and there is no dependency on MMU support
> for it, nor should there be.
My objection isn't about having only little RAM. AUTO_ZRELADDR is about
guessing the physical address corresponding to PAGE_OFFSET. But without
an MMU there is nothing to guess. So I wonder if the better change would
be to do:

	#ifdef CONFIG_MMU
	#ifdef CONFIG_AUTO_ZRELADDR
		... guess zreladdress based on instruction pointer
	#else
		... use zreladdr from Makefile.boot
	#endif
	#else
		... use zreladdr = PAGE_OFFSET
	#endif

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[PATCH 10/62] ARM: efm32: select AUTO_ZRELADDR

[Arnd Bergmann]

On Friday 21 March 2014 15:32:24 Uwe Kleine-K?nig wrote:
> On Thu, Mar 20, 2014 at 11:16:20PM +0100, Arnd Bergmann wrote:
> > On Thursday 20 March 2014 21:48:47 Uwe Kleine-K?nig wrote:
> > > 
> > > On Wed, Mar 19, 2014 at 08:29:07PM +0100, Arnd Bergmann wrote:
> > > > The efm32 platform does not provide a zreladdr-y line its Makefile.boot,
> > > > so we always have to use CONFIG_AUTO_ZRELADDR in order to successfully
> > > > build and link a zImage.
> > > I wonder why you need to AUTO_ZRELADDR (which is there to guess
> > > zreladdr) while efm32 doesn't have an MMU and so there is nothing to
> > > guess. So I think this patch fixes a build problem, but it's not a good
> > > change.
> > 
> > It is required in order to build a compressed zImage file. You mentioned
> > before that your system does not have enough RAM to support this, but
> > the compile-time option exists, and there is no dependency on MMU support
> > for it, nor should there be.
> My objection isn't about having only little RAM. AUTO_ZRELADDR is about
> guessing the physical address corresponding to PAGE_OFFSET. But without
> an MMU there is nothing to guess. So I wonder if the better change would
> be to do:
> 
>         #ifdef CONFIG_MMU
>         #ifdef CONFIG_AUTO_ZRELADDR
>                 ... guess zreladdress based on instruction pointer
>         #else
>                 ... use zreladdr from Makefile.boot
>         #endif
>         #else
>                 ... use zreladdr = PAGE_OFFSET
>         #endif
> 

I don't see a reason to change the existing logic, it works for
both MMU and NOMMU kernels, and you are talking about *three* instructions
here.
Also, once we integrate efm32 into ARCH_MULTIPLATFORM, it AUTO_ZRELADDR
will be set anyway, unless we add another useless conditional.

	Arnd

[PATCH 58/62] ARM: exynos: add missing include of linux/module.h

[Arnd Bergmann]

On Thursday 20 March 2014, Kukjin Kim wrote:
> Arnd Bergmann wrote:
> > 
> > After the restructuring of the module.h and init.h headers,
> > we now need to include this explicitly here.
> > 
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Tomasz Figa <tomasz.figa@gmail.com>
> > Cc: Kukjin Kim <kgene.kim@samsung.com>
> 
> Acked-by: Kukjin Kim <kgene.kim@samsung.com>
> 
> Arnd,
> 
> If you want me to take this fixes for Samsung stuff into samsung tree,
> please let me know.

I think it's easier for me to keep the 62 fixes together as a series
this time.

When I find new bugs later on, it may be better for you and the
other platform maintainers to pick those up.

	Arnd

Re: [PATCH 60/62] ARM: shmobile: work around CONFIG_PHYLIB=m

[Arnd Bergmann]

On Thursday 20 March 2014, Simon Horman wrote:
> On Wed, Mar 19, 2014 at 08:29:57PM +0100, Arnd Bergmann wrote:
> > When phylib is set to be built as a module, the lager and koelsch
> > boards fail to build:
> > 
> > arch/arm/mach-shmobile/built-in.o: In function `lager_ksz8041_fixup':
> > :(.text+0x738): undefined reference to `mdiobus_read'
> > :(.text+0x73c): undefined reference to `mdiobus_write'
> > arch/arm/mach-shmobile/built-in.o: In function `koelsch_ksz8041_fixup':
> > :(.text+0x7e8): undefined reference to `mdiobus_read'
> > :(.text+0x7ec): undefined reference to `mdiobus_write'
> > 
> > To work around that problem, this changes the code to check for
> > IS_BUILTIN rather than IS_ENABLED, turning the error into a runtime
> > problem. It's now possible to build random configurations, but the
> > phy may be set up incorrectly in this case.
> 
> I wonder if Kconfig for koelsch should be tightened up somehow to
> ensure that PHYLIB is either unselected or builtin.
> 
> Also, a minor nit, I would prefer changes for different boards
> in different patches. But I can split the patch myself if its
> not going to be changed otherwise.

I would prefer to take the entire series directly into arm-soc
this time, if you don't mind.

	Arnd

[PATCH 60/62] ARM: shmobile: work around CONFIG_PHYLIB=m

[Arnd Bergmann]

On Thursday 20 March 2014, Simon Horman wrote:
> On Wed, Mar 19, 2014 at 08:29:57PM +0100, Arnd Bergmann wrote:
> > When phylib is set to be built as a module, the lager and koelsch
> > boards fail to build:
> > 
> > arch/arm/mach-shmobile/built-in.o: In function `lager_ksz8041_fixup':
> > :(.text+0x738): undefined reference to `mdiobus_read'
> > :(.text+0x73c): undefined reference to `mdiobus_write'
> > arch/arm/mach-shmobile/built-in.o: In function `koelsch_ksz8041_fixup':
> > :(.text+0x7e8): undefined reference to `mdiobus_read'
> > :(.text+0x7ec): undefined reference to `mdiobus_write'
> > 
> > To work around that problem, this changes the code to check for
> > IS_BUILTIN rather than IS_ENABLED, turning the error into a runtime
> > problem. It's now possible to build random configurations, but the
> > phy may be set up incorrectly in this case.
> 
> I wonder if Kconfig for koelsch should be tightened up somehow to
> ensure that PHYLIB is either unselected or builtin.
> 
> Also, a minor nit, I would prefer changes for different boards
> in different patches. But I can split the patch myself if its
> not going to be changed otherwise.

I would prefer to take the entire series directly into arm-soc
this time, if you don't mind.

	Arnd

[PATCH 01/62] ARM: at91: split out at91x40 into a top-level option

[Arnd Bergmann]

On Thursday 20 March 2014, Nicolas Ferre wrote:
> On 19/03/2014 20:28, Arnd Bergmann :
> > at91x40 is different from all the other at91 machines, and it is
> > impossible to build a kernel that works on both this SoC and
> > any of the others, even though it is possible to build a noMMU
> > kernel for any at91 machine.
> > 
> > By turning at91x40 into a separate top-level option, we explicitly
> > forbid enabling invalid configurations that include mutually exclusive
> > machines.
> > 
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Andrew Victor <linux@maxim.org.za>
> > Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
> 
> I added below little modifications to the comments, now that the AT91X40
> is another entry.
> 
> Otherwise:
> 
> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>

Changed now, thanks for the suggestion!

	Arnd

[PATCH 04/62] ARM: at91: fix broken "if () else" statement

[Arnd Bergmann]

On Thursday 20 March 2014, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On Mar 20, 2014, at 3:29 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > -	if (data->flags & AT91_CF_TRUE_IDE)
> > #if defined(CONFIG_PATA_AT91) || defined(CONFIG_PATA_AT91_MODULE)
> > +	if (data->flags & AT91_CF_TRUE_IDE)
> I prefer if (IS_ENABLED())
> > 		pdev->name = "pata_at91";
> > +	else
> > #else
> > #warning "board requires AT91_CF_TRUE_IDE: enable pata_at91?
> but this means drop this warning
> > #endif

Good idea, thanks!

	Arnd

>From ce916f429091f98cc53ee9cf11e6e02b4dc3dc25 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@arndb.de>
Date: Thu, 13 Mar 2014 17:47:23 +0100
Subject: [PATCH] ARM: at91: fix broken "if () else" statement

If CONFIG_PATA_AT91 is disabled, the code in at91_add_device_cf
is turned into invalid C statements due to the lack of an
expression before the 'else' clause.

This moves the first half of the condition inside of the #ifdef,
which seems to be what the author intended.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Andrew Victor <linux@maxim.org.za>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>

diff --git a/arch/arm/mach-at91/at91sam9260_devices.c b/arch/arm/mach-at91/at91sam9260_devices.c
index 2ae7715..33fa98d 100644
--- a/arch/arm/mach-at91/at91sam9260_devices.c
+++ b/arch/arm/mach-at91/at91sam9260_devices.c
@@ -1263,12 +1263,8 @@ void __init at91_add_device_cf(struct at91_cf_data *data)
 	at91_set_A_periph(AT91_PIN_PC10, 0);    /* CFRNW */
 	at91_set_A_periph(AT91_PIN_PC15, 1);    /* NWAIT */
 
-	if (data->flags & AT91_CF_TRUE_IDE)
-#if defined(CONFIG_PATA_AT91) || defined(CONFIG_PATA_AT91_MODULE)
+	if (IS_ENABLED(CONFIG_PATA_AT91) && (data->flags & AT91_CF_TRUE_IDE)
 		pdev->name = "pata_at91";
-#else
-#warning "board requires AT91_CF_TRUE_IDE: enable pata_at91"
-#endif
 	else
 		pdev->name = "at91_cf";
 

[PATCH 61/62] ARM: sunxi: fix build for THUMB2_KERNEL

[Rob Herring]

On Thu, Mar 20, 2014 at 5:59 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 19 March 2014, Rob Herring wrote:
>
>> > --- a/arch/arm/mach-sunxi/headsmp.S
>> > +++ b/arch/arm/mach-sunxi/headsmp.S
>> > @@ -4,6 +4,7 @@
>> >          .section ".text.head", "ax"
>> >
>> >  ENTRY(sun6i_secondary_startup)
>> > -       msr     cpsr_fsxc, #0xd3
>> > +       mov     r0, #0xd3
>> > +       msr     cpsr_fsxc, r0
>> >         b       secondary_startup
>>
>> Secondary cores should always enter the kernel in ARM mode like the
>> primary core, right? So we need the same switching to Thumb2 as
>> head.S, but even secondary_startup doesn't do any switching. So either
>> platforms jump into the kernel with a bx and happen to work or
>> secondary boot is broken for Thumb2 kernels.
>
> Makes sense. So should we instead do this?

That would work, but I'm more worried that Thumb2 may be broken on
other platforms.

>
> .arm
> ENTRY(sun6i_secondary_startup)
>         ARM_BE8(setend   be ) /* I suppose we need this too */
>         msr     cpsr_fsxc, #0xd3
>         ldr     r0, =secondary_startup
>         bx      r0
>
> (I'm a bit confused about when to use what branch instruction, so
> forgive me if the above doesn't make sense)
>
>> Also, secondary_startup takes care of making sure the core is in SVC
>> mode, so this function shouldn't be needed in the first place.
>
> I'd rather not change this part, unless Maxime can confirm that it's
> not necessary. I would assume that it's there for a reason otherwise.

That often proves to not be the case. :) Initial SOC code is whatever
we've failed to delete from vendor BSP code.

Looking at the review comments adding SMP boot, there was discussion
about entering in HYP mode and that being dependent on u-boot support,
but nothing whether this was needed or not. So it appears to me we
probably enter the kernel in the reset default of secure supervisor
mode and this code is a nop. This code would not work if it was HYP
mode. So when u-boot does correctly setup HYP mode, this code will be
broken (although other parts of smp_ops will be too).

The first things secondary_startup do are:

-set BE mode
-if in HYP mode, install hyp vectors and drop to SVC
-set the CPSR to a know value (safe_svcmode_maskall r9)

So this code is completely redundant and unnecessary. If there were
some reason for it, then it should be in secondary_startup.

Rob

[PATCH 08/62] ARM: davinci: use explicit 'select' for DA850_EVM

[Arnd Bergmann]

On Thursday 20 March 2014, Sekhar Nori wrote:
> On Thursday 20 March 2014 12:59 AM, Arnd Bergmann wrote:
> > The DAVINCI_DA850_EVM board uses an unusual method to
> > enable the GPIO_PCA953X and KEYBOARD_GPIO_POLLED symbols,
> > which leads to the dependencies on these symbols being
> > ignored. As GPIO_PCA953X actually requires I2C, that
> > can lead to build failures when I2C is disabled.
> > 
> > This patch removes the duplicate symbol definitions
> 
> I am okay with this..
> 
> > and instead adds equivalent 'select' statements that
> > are conditional on the underlying dependencies.
> 
> .. but not sure this is needed. The PCA953X was defaulted to y mainly
> because the IO expander was used to detect presence of daughter cards.
> Even then, I don't think there is any need to force its selection.
> 
> > 
> > A different question whether we actually want to automatically
> > enable them at all or rather put them into defconfig,
> > but that should be a separate patch.
> 
> It can be enabled through defconfig as you said. I agree that can be a
> separate patch. For now, just dropping the replicated Kconfig symbols
> should be okay.

Ok, even better then. I was trying to change the behavior as little
as possible, but not selecting the drivers is certainly the correct
approach. I've put the two symbols into the defconfig now so the builds
are unchanged.

	Arnd

8<----

>From 5eaf7fdfe7c831d3aa24428a6e8d4509ac160db6 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@arndb.de>
Date: Tue, 18 Feb 2014 12:23:19 +0100
Subject: [PATCH] ARM: davinci: use explicit 'select' for DA850_EVM

The DAVINCI_DA850_EVM board uses an unusual method to
enable the GPIO_PCA953X and KEYBOARD_GPIO_POLLED symbols,
which leads to the dependencies on these symbols being
ignored. As GPIO_PCA953X actually requires I2C, that
can lead to build failures when I2C is disabled.

This patch removes the duplicate symbol definitions
and instead enables them from the davinci_all_defconfig
file.

A different question whether we actually want to automatically
enable them at all or rather put them into defconfig,
but that should be a separate patch.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Sekhar Nori <nsekhar@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: davinci-linux-open-source at linux.davincidsp.com

diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index fff4eb6..16bdfab 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -218,3 +218,5 @@ CONFIG_DEBUG_ERRORS=y
 # CONFIG_CRYPTO_ANSI_CPRNG is not set
 # CONFIG_CRYPTO_HW is not set
 CONFIG_CRC_T10DIF=m
+CONFIG_GPIO_PCA953X=y
+CONFIG_KEYBOARD_GPIO_POLLED=y
diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
index 3b98e34..db18ef8 100644
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig
@@ -209,11 +209,6 @@ config DA850_WL12XX
 	  Say Y if you want to use a wl1271 expansion card connected to the
 	  AM18x EVM.
 
-config GPIO_PCA953X
-	default MACH_DAVINCI_DA850_EVM
-
-config KEYBOARD_GPIO_POLLED
-	default MACH_DAVINCI_DA850_EVM
 
 config MACH_MITYOMAPL138
 	bool "Critical Link MityDSP-L138/MityARM-1808 SoM"

Re: [PATCH 23/62] ARM: omap1: fix building without 32K_TIMER

[Arnd Bergmann]

On Wednesday 19 March 2014, Tony Lindgren wrote:
> * Felipe Balbi <balbi@ti.com> [140319 13:06]:
> > On Wed, Mar 19, 2014 at 02:59:13PM -0500, Felipe Balbi wrote:
> > > I had sent a fix for months and months ago, what happened to it ?
> > 
> > Here
> > 
> > http://marc.info/?l=linux-omap&m=138963632408031&w=2
> > 
> > Tony, did you forget to send a pull request ?
> 
> Hmm yes weird, can't see it in my omap-for-v3.14/fixes branch.
> 
> I must have gotten interrupted while applying and then probably
> ran git reset --hard before committing.
> 
> Arnd, maybe pick up Felipe's earlier patch instead?
> 
> Acked-by: Tony Lindgren <tony@atomide.com>

Ok, using this version now, thanks!

	Arnd

>From 64cdcf550319a37d1419aa6a87903e67b9d3d031 Mon Sep 17 00:00:00 2001
From: Felipe Balbi <balbi@ti.com>
Date: Sun, 16 Mar 2014 17:57:55 +0100
Subject: [PATCH] ARM: omap1: fix build when !CONFIG_OMAP_32K_TIMER

If CONFIG_OMAP_32K_TIMER isn't enabled, we will
try to use enable_dyn_sleep which wasn't defined
anywhere.

In order to fix the problem, we always define
enable_dyn_sleep as 0 when !CONFIG_OMAP_32K_TIMER.

Signed-off-by: Felipe Balbi <balbi@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

diff --git a/arch/arm/mach-omap1/pm.c b/arch/arm/mach-omap1/pm.c
index 40a1ae3..dbee729 100644
--- a/arch/arm/mach-omap1/pm.c
+++ b/arch/arm/mach-omap1/pm.c
@@ -71,7 +71,11 @@ static unsigned int mpui7xx_sleep_save[MPUI7XX_SLEEP_SAVE_SIZE];
 static unsigned int mpui1510_sleep_save[MPUI1510_SLEEP_SAVE_SIZE];
 static unsigned int mpui1610_sleep_save[MPUI1610_SLEEP_SAVE_SIZE];
 
-#ifdef CONFIG_OMAP_32K_TIMER
+#ifndef CONFIG_OMAP_32K_TIMER
+
+static unsigned short enable_dyn_sleep = 0;
+
+#else
 
 static unsigned short enable_dyn_sleep = 1;
 

[PATCH 23/62] ARM: omap1: fix building without 32K_TIMER

[Arnd Bergmann]

On Wednesday 19 March 2014, Tony Lindgren wrote:
> * Felipe Balbi <balbi@ti.com> [140319 13:06]:
> > On Wed, Mar 19, 2014 at 02:59:13PM -0500, Felipe Balbi wrote:
> > > I had sent a fix for months and months ago, what happened to it ?
> > 
> > Here
> > 
> > http://marc.info/?l=linux-omap&m=138963632408031&w=2
> > 
> > Tony, did you forget to send a pull request ?
> 
> Hmm yes weird, can't see it in my omap-for-v3.14/fixes branch.
> 
> I must have gotten interrupted while applying and then probably
> ran git reset --hard before committing.
> 
> Arnd, maybe pick up Felipe's earlier patch instead?
> 
> Acked-by: Tony Lindgren <tony@atomide.com>

Ok, using this version now, thanks!

	Arnd

>From 64cdcf550319a37d1419aa6a87903e67b9d3d031 Mon Sep 17 00:00:00 2001
From: Felipe Balbi <balbi@ti.com>
Date: Sun, 16 Mar 2014 17:57:55 +0100
Subject: [PATCH] ARM: omap1: fix build when !CONFIG_OMAP_32K_TIMER

If CONFIG_OMAP_32K_TIMER isn't enabled, we will
try to use enable_dyn_sleep which wasn't defined
anywhere.

In order to fix the problem, we always define
enable_dyn_sleep as 0 when !CONFIG_OMAP_32K_TIMER.

Signed-off-by: Felipe Balbi <balbi@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

diff --git a/arch/arm/mach-omap1/pm.c b/arch/arm/mach-omap1/pm.c
index 40a1ae3..dbee729 100644
--- a/arch/arm/mach-omap1/pm.c
+++ b/arch/arm/mach-omap1/pm.c
@@ -71,7 +71,11 @@ static unsigned int mpui7xx_sleep_save[MPUI7XX_SLEEP_SAVE_SIZE];
 static unsigned int mpui1510_sleep_save[MPUI1510_SLEEP_SAVE_SIZE];
 static unsigned int mpui1610_sleep_save[MPUI1610_SLEEP_SAVE_SIZE];
 
-#ifdef CONFIG_OMAP_32K_TIMER
+#ifndef CONFIG_OMAP_32K_TIMER
+
+static unsigned short enable_dyn_sleep = 0;
+
+#else
 
 static unsigned short enable_dyn_sleep = 1;
 

[PATCH 61/62] ARM: sunxi: fix build for THUMB2_KERNEL

[Arnd Bergmann]

On Friday 21 March 2014 10:54:49 Rob Herring wrote:
> On Thu, Mar 20, 2014 at 5:59 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Wednesday 19 March 2014, Rob Herring wrote:
> >
> >> > --- a/arch/arm/mach-sunxi/headsmp.S
> >> > +++ b/arch/arm/mach-sunxi/headsmp.S
> >> > @@ -4,6 +4,7 @@
> >> >          .section ".text.head", "ax"
> >> >
> >> >  ENTRY(sun6i_secondary_startup)
> >> > -       msr     cpsr_fsxc, #0xd3
> >> > +       mov     r0, #0xd3
> >> > +       msr     cpsr_fsxc, r0
> >> >         b       secondary_startup
> >>
> >> Secondary cores should always enter the kernel in ARM mode like the
> >> primary core, right? So we need the same switching to Thumb2 as
> >> head.S, but even secondary_startup doesn't do any switching. So either
> >> platforms jump into the kernel with a bx and happen to work or
> >> secondary boot is broken for Thumb2 kernels.
> >
> > Makes sense. So should we instead do this?
> 
> That would work, but I'm more worried that Thumb2 may be broken on
> other platforms.

I'm rather sure it is. I have found lots of build-time bugs with
thumb2, so by extrapolation there are more run-time bugs. I have
considered just enabling it in multi_v7_defconfig though, mainly
to see what would break ;-).

> > .arm
> > ENTRY(sun6i_secondary_startup)
> >         ARM_BE8(setend   be ) /* I suppose we need this too */
> >         msr     cpsr_fsxc, #0xd3
> >         ldr     r0, =secondary_startup
> >         bx      r0
> >
> > (I'm a bit confused about when to use what branch instruction, so
> > forgive me if the above doesn't make sense)
> >
> >> Also, secondary_startup takes care of making sure the core is in SVC
> >> mode, so this function shouldn't be needed in the first place.
> >
> > I'd rather not change this part, unless Maxime can confirm that it's
> > not necessary. I would assume that it's there for a reason otherwise.
> 
> That often proves to not be the case. :) Initial SOC code is whatever
> we've failed to delete from vendor BSP code.
> 
> Looking at the review comments adding SMP boot, there was discussion
> about entering in HYP mode and that being dependent on u-boot support,
> but nothing whether this was needed or not. So it appears to me we
> probably enter the kernel in the reset default of secure supervisor
> mode and this code is a nop. This code would not work if it was HYP
> mode. So when u-boot does correctly setup HYP mode, this code will be
> broken (although other parts of smp_ops will be too).
> 
> The first things secondary_startup do are:
> 
> -set BE mode
> -if in HYP mode, install hyp vectors and drop to SVC
> -set the CPSR to a know value (safe_svcmode_maskall r9)
> 
> So this code is completely redundant and unnecessary. If there were
> some reason for it, then it should be in secondary_startup.

Ah, thanks for the clarification. Shall we just delete the file then
and jump straight to secondary_startup?

	Arnd

[PATCH 26/62] ARM: mvebu: don't select CONFIG_NEON

[Arnd Bergmann]

On Wednesday 19 March 2014, Gregory CLEMENT wrote:
> On 19/03/2014 20:37, Jason Cooper wrote:
> > On Wed, Mar 19, 2014 at 08:29:23PM +0100, Arnd Bergmann wrote:
> >> CONFIG_NEON is meant to be user-selectable. Turning it on
> >> unconditionally means we can't build a smaller kernel when
> >> we don't need it, and causes build errors if CONFIG_VFP
> >> is not also enabled.
> >>
> >> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> >> Cc: Jason Cooper <jason@lakedaemon.net>
> >> Cc: Andrew Lunn <andrew@lunn.ch>
> >> Cc: Gregory Clement <gregory.clement@free-electrons.com>
> >> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> >> ---
> >>  arch/arm/mach-mvebu/Kconfig | 2 --
> >>  1 file changed, 2 deletions(-)
> > 
> > Acked-by: Jason Cooper <jason@lakedaemon.net>
> 
> 
> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>

Thanks! Here is my new version.

	Arnd

>From 59532706506c0b3bf9f46499e7ba6c0f169e3802 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@arndb.de>
Date: Mon, 24 Feb 2014 21:56:19 +0100
Subject: [PATCH] ARM: mvebu: don't select CONFIG_NEON

CONFIG_NEON is meant to be user-selectable. Turning it on
unconditionally means we can't build a smaller kernel when
we don't need it, and causes build errors if CONFIG_VFP
is not also enabled.

To still have neon enabled however, we need to turn it on
now in multi_v7_defconfig and mvebu_v7_defconfig.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Acked-by: Gregory Clement <gregory.clement@free-electrons.com>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 9ee12b5..cd16989 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -63,6 +63,7 @@ CONFIG_ARCH_VEXPRESS_CA9X4=y
 CONFIG_ARCH_VIRT=y
 CONFIG_ARCH_WM8850=y
 CONFIG_ARCH_ZYNQ=y
+CONFIG_NEON=y
 CONFIG_TRUSTED_FOUNDATIONS=y
 CONFIG_PCI=y
 CONFIG_PCI_MSI=y
diff --git a/arch/arm/configs/mvebu_v7_defconfig b/arch/arm/configs/mvebu_v7_defconfig
index 62b6a37..a34713d 100644
--- a/arch/arm/configs/mvebu_v7_defconfig
+++ b/arch/arm/configs/mvebu_v7_defconfig
@@ -13,6 +13,7 @@ CONFIG_MACH_ARMADA_370=y
 CONFIG_MACH_ARMADA_375=y
 CONFIG_MACH_ARMADA_38X=y
 CONFIG_MACH_ARMADA_XP=y
+CONFIG_NEON=y
 # CONFIG_CACHE_L2X0 is not set
 # CONFIG_SWP_EMULATE is not set
 CONFIG_PCI=y
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 485513cb..b24a082 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -39,7 +39,6 @@ config MACH_ARMADA_375
 	select ARMADA_375_CLK
 	select CPU_V7
 	select MACH_MVEBU_V7
-	select NEON
 	select PINCTRL_ARMADA_375
 	help
 	  Say 'Y' here if you want your kernel to support boards based
@@ -53,7 +52,6 @@ config MACH_ARMADA_38X
 	select ARMADA_38X_CLK
 	select CPU_V7
 	select MACH_MVEBU_V7
-	select NEON
 	select PINCTRL_ARMADA_38X
 	help
 	  Say 'Y' here if you want your kernel to support boards based

[PATCH 37/62] ARM: sa1100/pxa: fix MTD_XIP build

[Arnd Bergmann]

On Wednesday 19 March 2014, Russell King - ARM Linux wrote:
> On Wed, Mar 19, 2014 at 08:29:34PM +0100, Arnd Bergmann wrote:
> > In commit 3169663ac5902 "ARM: sa11x0/pxa: convert OS timer registers
> > to IOMEM", the definition of the OSCR macro was changed to be an
> > __iomem pointer, but the same register is also used by the XIP
> > code. This patch does the corresponding change here as well.
> > 
> > Since PXA now uses a local variable for the base address of the
> > ICIP register, the xip_irqpending function has to be moved
> > into irq.c in the process.
> > 
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Russell King <linux@arm.linux.org.uk>
> > ---
> >  arch/arm/mach-pxa/include/mach/mtd-xip.h    | 7 ++++---
> >  arch/arm/mach-pxa/irq.c                     | 8 ++++++++
> >  arch/arm/mach-sa1100/include/mach/mtd-xip.h | 4 ++--
> >  3 files changed, 14 insertions(+), 5 deletions(-)
> > 
> > diff --git a/arch/arm/mach-pxa/include/mach/mtd-xip.h b/arch/arm/mach-pxa/include/mach/mtd-xip.h
> > index 990d2bf..c4c90d1 100644
> > --- a/arch/arm/mach-pxa/include/mach/mtd-xip.h
> > +++ b/arch/arm/mach-pxa/include/mach/mtd-xip.h
> > @@ -17,11 +17,12 @@
> >  
> >  #include <mach/regs-ost.h>
> >  
> > -#define xip_irqpending()     (ICIP & ICMR)
> > +extern bool xip_irqpending(void);
> >  
> >  /* we sample OSCR and convert desired delta to usec (1/4 ~= 1000000/3686400) */
> > -#define xip_currtime()               (OSCR)
> > -#define xip_elapsed_since(x) (signed)((OSCR - (x)) / 4)
> > +#define xip_irqpending()     xip_irqpending()
> > +#define xip_currtime()               readl(OSCR)
> > +#define xip_elapsed_since(x) (signed)((readl(OSCR) - (x)) / 4)
> 
> I don't think you can do that.  I believe xip_irqpending() has to be
> inline so that the XIP code (located in RAM) can detect when an
> interrupt is pending, suspend the MTD operation, switch the MTD back
> to read mode, and then allow the kernel to run.
> 
> I'd be nervous about this without Nicolas checking it, or it being
> built and the resulting assembly inspected.

Ok, I'll drop this patch from the series for now, and mark it as
something to be investigated. and apply the change that Nico suggested.

	Arnd

[PATCH 47/62] ARM: s3c64xx: MACH_SMDK6400 needs HSMMC1

[Arnd Bergmann]

On Thursday 20 March 2014, Kukjin Kim wrote:
> 
> Well, only HSMMC ch1 is used on smdk6400 and S3C_DEV_NAND is not needed.

Ok, changed it now as you suggested:

>From 9ec2109585b54ed8ff507e4b29c8fee7af14c70d Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@arndb.de>
Date: Wed, 26 Feb 2014 21:31:18 +0100
Subject: [PATCH] ARM: s3c64xx: MACH_SMDK6400 needs HSMMC1

This board uses both MMC controllers, so we need to enable
the Kconfig option to define the platform data.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>

diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
index 64f04e6..3136d86 100644
--- a/arch/arm/mach-s3c64xx/Kconfig
+++ b/arch/arm/mach-s3c64xx/Kconfig
@@ -86,8 +86,7 @@ config MACH_SMDK6400
        bool "SMDK6400"
 	select CPU_S3C6400
 	select S3C64XX_SETUP_SDHCI
-	select S3C_DEV_HSMMC
-	select S3C_DEV_NAND
+	select S3C_DEV_HSMMC1
 	help
 	  Machine support for the Samsung SMDK6400
 

[PATCH 52/62] ARM: samsung: disable decompressor watchdog on exynos

[Arnd Bergmann]

On Thursday 20 March 2014, Kukjin Kim wrote:
> Arnd Bergmann wrote:
> > 
> > The S3C_BOOT_ERROR_RESET option only works when using the
> > samsung specific mach/uncompress.h implementation. The
> > Exynos platform has now moved on to using the generic
> > implementation instead, which does not support this.
> > 
> Yeah, correct and I've applied to use the generic uncompress for other
> Samsung SoCs into samsung tree and I sent to arm-soc a couple of days ago.
> Even though it is not cleaned for regarding configs e.g.,
> S3C_BOOT_ERROR_RESET yet, this is not used more.
> 

Ok, dropping my patch for now.

	Arnd

[PATCH 61/62] ARM: sunxi: fix build for THUMB2_KERNEL

[Arnd Bergmann]

On Friday 21 March 2014 17:05:09 Arnd Bergmann wrote:
> On Friday 21 March 2014 10:54:49 Rob Herring wrote:
> > The first things secondary_startup do are:
> > 
> > -set BE mode
> > -if in HYP mode, install hyp vectors and drop to SVC
> > -set the CPSR to a know value (safe_svcmode_maskall r9)
> > 
> > So this code is completely redundant and unnecessary. If there were
> > some reason for it, then it should be in secondary_startup.
> 
> Ah, thanks for the clarification. Shall we just delete the file then
> and jump straight to secondary_startup?

Maxime, can you test the new version?

>From 2f6220cee15e45446c43e5c43affa85a6c407b31 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@arndb.de>
Date: Sun, 16 Mar 2014 18:04:54 +0100
Subject: [PATCH] ARM: sunxi: fix build for THUMB2_KERNEL

Building an SMP kernel for the sunxi platform with THUMB2 instructions
fails with this error at the moment:

headsmp.S:7: Error: Thumb encoding does not support an immediate here -- `msr cpsr_fsxc,#0xd3'

Since the generic secondary_startup function already does
the same thing in a safe way, we can just drop the private
sunxi implementation and jump straight to secondary_startup.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>

diff --git a/arch/arm/mach-sunxi/Makefile b/arch/arm/mach-sunxi/Makefile
index d939720..27b168f 100644
--- a/arch/arm/mach-sunxi/Makefile
+++ b/arch/arm/mach-sunxi/Makefile
@@ -1,2 +1,2 @@
 obj-$(CONFIG_ARCH_SUNXI) += sunxi.o
-obj-$(CONFIG_SMP) += platsmp.o headsmp.o
+obj-$(CONFIG_SMP) += platsmp.o
diff --git a/arch/arm/mach-sunxi/common.h b/arch/arm/mach-sunxi/common.h
index 9e5ac47..08deb30 100644
--- a/arch/arm/mach-sunxi/common.h
+++ b/arch/arm/mach-sunxi/common.h
@@ -13,7 +13,6 @@
 #ifndef __ARCH_SUNXI_COMMON_H_
 #define __ARCH_SUNXI_COMMON_H_
 
-void sun6i_secondary_startup(void);
 extern struct smp_operations sun6i_smp_ops;
 
 #endif /* __ARCH_SUNXI_COMMON_H_ */
diff --git a/arch/arm/mach-sunxi/headsmp.S b/arch/arm/mach-sunxi/headsmp.S
deleted file mode 100644
index a10d494..0000000
--- a/arch/arm/mach-sunxi/headsmp.S
+++ /dev/null
@@ -1,9 +0,0 @@
-#include <linux/linkage.h>
-#include <linux/init.h>
-
-        .section ".text.head", "ax"
-
-ENTRY(sun6i_secondary_startup)
-	msr	cpsr_fsxc, #0xd3
-	b	secondary_startup
-ENDPROC(sun6i_secondary_startup)
diff --git a/arch/arm/mach-sunxi/platsmp.c b/arch/arm/mach-sunxi/platsmp.c
index 7b141d8..3f9b889 100644
--- a/arch/arm/mach-sunxi/platsmp.c
+++ b/arch/arm/mach-sunxi/platsmp.c
@@ -82,7 +82,7 @@ static int sun6i_smp_boot_secondary(unsigned int cpu,
 	spin_lock(&cpu_lock);
 
 	/* Set CPU boot address */
-	writel(virt_to_phys(sun6i_secondary_startup),
+	writel(virt_to_phys(secondary_startup),
 	       cpucfg_membase + CPUCFG_PRIVATE0_REG);
 
 	/* Assert the CPU core in reset */
@@ -120,5 +120,5 @@ static int sun6i_smp_boot_secondary(unsigned int cpu,
 
 struct smp_operations sun6i_smp_ops __initdata = {
 	.smp_prepare_cpus	= sun6i_smp_prepare_cpus,
-	.smp_boot_secondary	= sun6i_smp_boot_secondary,
+	.smp_boot_secondary	= sun6i_smp_secondary_startup,
 };

[PATCH 28/62] ARM: pxa: FB_W100 must be built-in

[Arnd Bergmann]

On Wednesday 19 March 2014, Arnd Bergmann wrote:
> The pxa platform code directly calls into the W100 framebuffer
> driver for eseries. This means it cannot be a loadable module
> and we also have to ensure that the core framebuffer code
> is built-in.
> 

Ignore this once, I'll drop it from the series and do a proper
fix, like we did for some of the other patches. It's better 
to change the code not to call into the fb driver if that is
disabled.

	Arnd

> diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
> index 96100db..562b17f 100644
> --- a/arch/arm/mach-pxa/Kconfig
> +++ b/arch/arm/mach-pxa/Kconfig
> @@ -556,6 +556,7 @@ config MACH_ICONTROL
>  config ARCH_PXA_ESERIES
>  	bool "PXA based Toshiba e-series PDAs"
>  	select FB_W100
> +	select FB
>  	select PXA25x
>  
>  config MACH_E330
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index dade5b7..86873ff 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -1996,8 +1996,8 @@ config FB_FSL_DIU
>  	  Framebuffer driver for the Freescale SoC DIU
>  
>  config FB_W100
> -	tristate "W100 frame buffer support"
> -	depends on FB && ARCH_PXA
> +	bool "W100 frame buffer support"
> +	depends on FB=y && ARCH_PXA
>   	select FB_CFB_FILLRECT
>   	select FB_CFB_COPYAREA
>   	select FB_CFB_IMAGEBLIT
> -- 
> 1.8.3.2
> 
> 

[PATCH 61/62] ARM: sunxi: fix build for THUMB2_KERNEL

[Rob Herring]

On Fri, Mar 21, 2014 at 11:24 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 21 March 2014 17:05:09 Arnd Bergmann wrote:
>> On Friday 21 March 2014 10:54:49 Rob Herring wrote:
>> > The first things secondary_startup do are:
>> >
>> > -set BE mode
>> > -if in HYP mode, install hyp vectors and drop to SVC
>> > -set the CPSR to a know value (safe_svcmode_maskall r9)
>> >
>> > So this code is completely redundant and unnecessary. If there were
>> > some reason for it, then it should be in secondary_startup.
>>
>> Ah, thanks for the clarification. Shall we just delete the file then
>> and jump straight to secondary_startup?
>
> Maxime, can you test the new version?
>
> From 2f6220cee15e45446c43e5c43affa85a6c407b31 Mon Sep 17 00:00:00 2001
> From: Arnd Bergmann <arnd@arndb.de>
> Date: Sun, 16 Mar 2014 18:04:54 +0100
> Subject: [PATCH] ARM: sunxi: fix build for THUMB2_KERNEL
>
> Building an SMP kernel for the sunxi platform with THUMB2 instructions
> fails with this error at the moment:
>
> headsmp.S:7: Error: Thumb encoding does not support an immediate here -- `msr cpsr_fsxc,#0xd3'
>
> Since the generic secondary_startup function already does
> the same thing in a safe way, we can just drop the private
> sunxi implementation and jump straight to secondary_startup.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Maxime Ripard <maxime.ripard@free-electrons.com>

One issue below, but otherwise:

Acked-by: Rob Herring <robh@kernel.org>

> diff --git a/arch/arm/mach-sunxi/Makefile b/arch/arm/mach-sunxi/Makefile
> index d939720..27b168f 100644
> --- a/arch/arm/mach-sunxi/Makefile
> +++ b/arch/arm/mach-sunxi/Makefile
> @@ -1,2 +1,2 @@
>  obj-$(CONFIG_ARCH_SUNXI) += sunxi.o
> -obj-$(CONFIG_SMP) += platsmp.o headsmp.o
> +obj-$(CONFIG_SMP) += platsmp.o
> diff --git a/arch/arm/mach-sunxi/common.h b/arch/arm/mach-sunxi/common.h
> index 9e5ac47..08deb30 100644
> --- a/arch/arm/mach-sunxi/common.h
> +++ b/arch/arm/mach-sunxi/common.h
> @@ -13,7 +13,6 @@
>  #ifndef __ARCH_SUNXI_COMMON_H_
>  #define __ARCH_SUNXI_COMMON_H_
>
> -void sun6i_secondary_startup(void);
>  extern struct smp_operations sun6i_smp_ops;
>
>  #endif /* __ARCH_SUNXI_COMMON_H_ */
> diff --git a/arch/arm/mach-sunxi/headsmp.S b/arch/arm/mach-sunxi/headsmp.S
> deleted file mode 100644
> index a10d494..0000000
> --- a/arch/arm/mach-sunxi/headsmp.S
> +++ /dev/null
> @@ -1,9 +0,0 @@
> -#include <linux/linkage.h>
> -#include <linux/init.h>
> -
> -        .section ".text.head", "ax"
> -
> -ENTRY(sun6i_secondary_startup)
> -       msr     cpsr_fsxc, #0xd3
> -       b       secondary_startup
> -ENDPROC(sun6i_secondary_startup)
> diff --git a/arch/arm/mach-sunxi/platsmp.c b/arch/arm/mach-sunxi/platsmp.c
> index 7b141d8..3f9b889 100644
> --- a/arch/arm/mach-sunxi/platsmp.c
> +++ b/arch/arm/mach-sunxi/platsmp.c
> @@ -82,7 +82,7 @@ static int sun6i_smp_boot_secondary(unsigned int cpu,
>         spin_lock(&cpu_lock);
>
>         /* Set CPU boot address */
> -       writel(virt_to_phys(sun6i_secondary_startup),
> +       writel(virt_to_phys(secondary_startup),
>                cpucfg_membase + CPUCFG_PRIVATE0_REG);
>
>         /* Assert the CPU core in reset */
> @@ -120,5 +120,5 @@ static int sun6i_smp_boot_secondary(unsigned int cpu,
>
>  struct smp_operations sun6i_smp_ops __initdata = {
>         .smp_prepare_cpus       = sun6i_smp_prepare_cpus,
> -       .smp_boot_secondary     = sun6i_smp_boot_secondary,
> +       .smp_boot_secondary     = sun6i_smp_secondary_startup,

?? This looks unintentional.

Rob

[PATCH 61/62] ARM: sunxi: fix build for THUMB2_KERNEL

[Arnd Bergmann]

On Friday 21 March 2014 13:21:04 Rob Herring wrote:
> > diff --git a/arch/arm/mach-sunxi/platsmp.c b/arch/arm/mach-sunxi/platsmp.c
> > index 7b141d8..3f9b889 100644
> > --- a/arch/arm/mach-sunxi/platsmp.c
> > +++ b/arch/arm/mach-sunxi/platsmp.c
> > @@ -82,7 +82,7 @@ static int sun6i_smp_boot_secondary(unsigned int cpu,
> >         spin_lock(&cpu_lock);
> >
> >         /* Set CPU boot address */
> > -       writel(virt_to_phys(sun6i_secondary_startup),
> > +       writel(virt_to_phys(secondary_startup),
> >                cpucfg_membase + CPUCFG_PRIVATE0_REG);
> >
> >         /* Assert the CPU core in reset */
> > @@ -120,5 +120,5 @@ static int sun6i_smp_boot_secondary(unsigned int cpu,
> >
> >  struct smp_operations sun6i_smp_ops __initdata = {
> >         .smp_prepare_cpus       = sun6i_smp_prepare_cpus,
> > -       .smp_boot_secondary     = sun6i_smp_boot_secondary,
> > +       .smp_boot_secondary     = sun6i_smp_secondary_startup,
> 
> ?? This looks unintentional.
> 

Yes, I just noticed the same thing after testing the resulting tree.

I also had to add a global declaration for secondary_startup, which apparently
mach-qcom also needs but added locally.

	Arnd

[PATCH 10/62] ARM: efm32: select AUTO_ZRELADDR

[Uwe Kleine-König]

Hello Arnd,

On Fri, Mar 21, 2014 at 04:10:37PM +0100, Arnd Bergmann wrote:
> On Friday 21 March 2014 15:32:24 Uwe Kleine-K?nig wrote:
> > On Thu, Mar 20, 2014 at 11:16:20PM +0100, Arnd Bergmann wrote:
> > > On Thursday 20 March 2014 21:48:47 Uwe Kleine-K?nig wrote:
> > > > 
> > > > On Wed, Mar 19, 2014 at 08:29:07PM +0100, Arnd Bergmann wrote:
> > > > > The efm32 platform does not provide a zreladdr-y line its Makefile.boot,
> > > > > so we always have to use CONFIG_AUTO_ZRELADDR in order to successfully
> > > > > build and link a zImage.
> > > > I wonder why you need to AUTO_ZRELADDR (which is there to guess
> > > > zreladdr) while efm32 doesn't have an MMU and so there is nothing to
> > > > guess. So I think this patch fixes a build problem, but it's not a good
> > > > change.
> > > 
> > > It is required in order to build a compressed zImage file. You mentioned
> > > before that your system does not have enough RAM to support this, but
> > > the compile-time option exists, and there is no dependency on MMU support
> > > for it, nor should there be.
> > My objection isn't about having only little RAM. AUTO_ZRELADDR is about
> > guessing the physical address corresponding to PAGE_OFFSET. But without
> > an MMU there is nothing to guess. So I wonder if the better change would
> > be to do:
> > 
> >         #ifdef CONFIG_MMU
> >         #ifdef CONFIG_AUTO_ZRELADDR
> >                 ... guess zreladdress based on instruction pointer
> >         #else
> >                 ... use zreladdr from Makefile.boot
> >         #endif
> >         #else
> >                 ... use zreladdr = PAGE_OFFSET
> >         #endif
> > 
> 
> I don't see a reason to change the existing logic, it works for
> both MMU and NOMMU kernels, and you are talking about *three* instructions
> here.
it doesn't matter how many instructions are involved. The relevant
difference is that with my approach you fix the problem for all no-MMU
platforms, with yours you only fix efm32. (OK, I think there are not too
many no-MMU platforms, but still.) An even easier implementation would
be to add something like:

	ifeq($(zreladdr-y)$(CONFIG_MMU),)
	zreladdr-y := CONFIG_PAGE_OFFSET + CONFIG_TEXT_OFFSET
	endif

to arch/arm/boot/Makefile.

But I don't care much, if you still want to make EFM32 select
AUTO_ZRELADDR go ahead.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[PATCH 61/62] ARM: sunxi: fix build for THUMB2_KERNEL

[Maxime Ripard]

On Fri, Mar 21, 2014 at 10:54:49AM -0500, Rob Herring wrote:
> >
> > .arm
> > ENTRY(sun6i_secondary_startup)
> >         ARM_BE8(setend   be ) /* I suppose we need this too */
> >         msr     cpsr_fsxc, #0xd3
> >         ldr     r0, =secondary_startup
> >         bx      r0
> >
> > (I'm a bit confused about when to use what branch instruction, so
> > forgive me if the above doesn't make sense)
> >
> >> Also, secondary_startup takes care of making sure the core is in SVC
> >> mode, so this function shouldn't be needed in the first place.
> >
> > I'd rather not change this part, unless Maxime can confirm that it's
> > not necessary. I would assume that it's there for a reason otherwise.
> 
> That often proves to not be the case. :) Initial SOC code is whatever
> we've failed to delete from vendor BSP code.

Yep, it definitely looks like it.

> Looking at the review comments adding SMP boot, there was discussion
> about entering in HYP mode and that being dependent on u-boot support,
> but nothing whether this was needed or not. So it appears to me we
> probably enter the kernel in the reset default of secure supervisor
> mode and this code is a nop. This code would not work if it was HYP
> mode. So when u-boot does correctly setup HYP mode, this code will be
> broken (although other parts of smp_ops will be too).

Actually, we don't have any proper bootloader support for this SoC,
and we're stuck with Allwinner's bootloader.

Bootloader support will come eventually, but I wouldn't worry too much
about HYP for now. And whenever we will have such a bootloader, we
will use PSCI, so we won't need to worry about it either.

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140321/9abe1377/attachment-0001.sig>

[PATCH 10/62] ARM: efm32: select AUTO_ZRELADDR

[Rob Herring]

On Fri, Mar 21, 2014 at 1:54 PM, Uwe Kleine-K?nig
<u.kleine-koenig@pengutronix.de> wrote:
> Hello Arnd,
>
> On Fri, Mar 21, 2014 at 04:10:37PM +0100, Arnd Bergmann wrote:
>> On Friday 21 March 2014 15:32:24 Uwe Kleine-K?nig wrote:
>> > On Thu, Mar 20, 2014 at 11:16:20PM +0100, Arnd Bergmann wrote:
>> > > On Thursday 20 March 2014 21:48:47 Uwe Kleine-K?nig wrote:
>> > > >
>> > > > On Wed, Mar 19, 2014 at 08:29:07PM +0100, Arnd Bergmann wrote:
>> > > > > The efm32 platform does not provide a zreladdr-y line its Makefile.boot,
>> > > > > so we always have to use CONFIG_AUTO_ZRELADDR in order to successfully
>> > > > > build and link a zImage.
>> > > > I wonder why you need to AUTO_ZRELADDR (which is there to guess
>> > > > zreladdr) while efm32 doesn't have an MMU and so there is nothing to
>> > > > guess. So I think this patch fixes a build problem, but it's not a good
>> > > > change.
>> > >
>> > > It is required in order to build a compressed zImage file. You mentioned
>> > > before that your system does not have enough RAM to support this, but
>> > > the compile-time option exists, and there is no dependency on MMU support
>> > > for it, nor should there be.
>> > My objection isn't about having only little RAM. AUTO_ZRELADDR is about
>> > guessing the physical address corresponding to PAGE_OFFSET. But without
>> > an MMU there is nothing to guess. So I wonder if the better change would
>> > be to do:
>> >
>> >         #ifdef CONFIG_MMU
>> >         #ifdef CONFIG_AUTO_ZRELADDR
>> >                 ... guess zreladdress based on instruction pointer
>> >         #else
>> >                 ... use zreladdr from Makefile.boot
>> >         #endif
>> >         #else
>> >                 ... use zreladdr = PAGE_OFFSET
>> >         #endif
>> >
>>
>> I don't see a reason to change the existing logic, it works for
>> both MMU and NOMMU kernels, and you are talking about *three* instructions
>> here.
> it doesn't matter how many instructions are involved. The relevant
> difference is that with my approach you fix the problem for all no-MMU
> platforms, with yours you only fix efm32. (OK, I think there are not too
> many no-MMU platforms, but still.) An even easier implementation would
> be to add something like:
>
>         ifeq($(zreladdr-y)$(CONFIG_MMU),)
>         zreladdr-y := CONFIG_PAGE_OFFSET + CONFIG_TEXT_OFFSET
>         endif
>
> to arch/arm/boot/Makefile.
>
> But I don't care much, if you still want to make EFM32 select
> AUTO_ZRELADDR go ahead.

How about a kconfig fix:

bool "Auto calculation of the decompressed kernel image address" if MMU
default y if !MMU

Rob

[PATCH 58/62] ARM: exynos: add missing include of linux/module.h

[Kukjin Kim]

Arnd Bergmann wrote:
> 
> On Thursday 20 March 2014, Kukjin Kim wrote:
> > Arnd Bergmann wrote:
> > >
> > > After the restructuring of the module.h and init.h headers,
> > > we now need to include this explicitly here.
> > >
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > Cc: Tomasz Figa <tomasz.figa@gmail.com>
> > > Cc: Kukjin Kim <kgene.kim@samsung.com>
> >
> > Acked-by: Kukjin Kim <kgene.kim@samsung.com>
> >
> > Arnd,
> >
> > If you want me to take this fixes for Samsung stuff into samsung tree,
> > please let me know.
> 
> I think it's easier for me to keep the 62 fixes together as a series
> this time.
> 
OK.

> When I find new bugs later on, it may be better for you and the
> other platform maintainers to pick those up.
> 
OK, thanks.

- Kukjin

[PATCH 47/62] ARM: s3c64xx: MACH_SMDK6400 needs HSMMC1

[Kukjin Kim]

Arnd Bergmann wrote:
> 
> On Thursday 20 March 2014, Kukjin Kim wrote:
> >
> > Well, only HSMMC ch1 is used on smdk6400 and S3C_DEV_NAND is not needed.
> 
> Ok, changed it now as you suggested:
> 
> From 9ec2109585b54ed8ff507e4b29c8fee7af14c70d Mon Sep 17 00:00:00 2001
> From: Arnd Bergmann <arnd@arndb.de>
> Date: Wed, 26 Feb 2014 21:31:18 +0100
> Subject: [PATCH] ARM: s3c64xx: MACH_SMDK6400 needs HSMMC1
> 
> This board uses both MMC controllers, so we need to enable
> the Kconfig option to define the platform data.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Kukjin Kim <kgene.kim@samsung.com>

Acked-by: Kukjin Kim <kgene.kim@samsung.com>

Thanks,
Kukjin

> Cc: Ben Dooks <ben-linux@fluff.org>
> 
> diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
> index 64f04e6..3136d86 100644
> --- a/arch/arm/mach-s3c64xx/Kconfig
> +++ b/arch/arm/mach-s3c64xx/Kconfig
> @@ -86,8 +86,7 @@ config MACH_SMDK6400
>         bool "SMDK6400"
>  	select CPU_S3C6400
>  	select S3C64XX_SETUP_SDHCI
> -	select S3C_DEV_HSMMC
> -	select S3C_DEV_NAND
> +	select S3C_DEV_HSMMC1
>  	help
>  	  Machine support for the Samsung SMDK6400
> 

[PATCH 52/62] ARM: samsung: disable decompressor watchdog on exynos

[Kukjin Kim]

Arnd Bergmann wrote:
> 
> On Thursday 20 March 2014, Kukjin Kim wrote:
> > Arnd Bergmann wrote:
> > >
> > > The S3C_BOOT_ERROR_RESET option only works when using the
> > > samsung specific mach/uncompress.h implementation. The
> > > Exynos platform has now moved on to using the generic
> > > implementation instead, which does not support this.
> > >
> > Yeah, correct and I've applied to use the generic uncompress for other
> > Samsung SoCs into samsung tree and I sent to arm-soc a couple of days ago.
> > Even though it is not cleaned for regarding configs e.g.,
> > S3C_BOOT_ERROR_RESET yet, this is not used more.
> >
> 
> Ok, dropping my patch for now.
> 
Thanks,
Kukjin

[PATCH 10/62] ARM: efm32: select AUTO_ZRELADDR

[Arnd Bergmann]

On Friday 21 March 2014, Rob Herring wrote:
> On Fri, Mar 21, 2014 at 1:54 PM, Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de> wrote:
> > On Fri, Mar 21, 2014 at 04:10:37PM +0100, Arnd Bergmann wrote:
> >> I don't see a reason to change the existing logic, it works for
> >> both MMU and NOMMU kernels, and you are talking about three instructions
> >> here.
> > it doesn't matter how many instructions are involved. The relevant
> > difference is that with my approach you fix the problem for all no-MMU
> > platforms, with yours you only fix efm32. (OK, I think there are not too
> > many no-MMU platforms, but still.) An even easier implementation would
> > be to add something like:
> >
> >         ifeq($(zreladdr-y)$(CONFIG_MMU),)
> >         zreladdr-y := CONFIG_PAGE_OFFSET + CONFIG_TEXT_OFFSET
> >         endif
> >
> > to arch/arm/boot/Makefile.

This makes sense, we can add it as soon as we have a use for it. At the
moment, the only problem we have is a randconfig build error, and the
obvious change I proposed should work just fine.

> > But I don't care much, if you still want to make EFM32 select
> > AUTO_ZRELADDR go ahead.
> 
> How about a kconfig fix:
> 
> bool "Auto calculation of the decompressed kernel image address" if MMU
> default y if !MMU

This however would break builds that today for some reason cannot use
AUTO_ZRELADDR on !MMU kernels, i.e. has a funny bootloader that
uses ZBOOT_ROM or other tricks. In principle any platform should
work with MMU disabled (although I'm sure there are tons of bugs),
and not every one uses AUTO_ZRELADDR today. Uwe's suggestion above
takes advantage of the fact that !MMU-kernels know what physical
address they run on.

	Arnd

[PATCH 17/62] ARM: ixp4xx: fix gpio rework

[Krzysztof Halasa]

Arnd Bergmann <arnd@arndb.de> writes:

> Commit 098e30f6558f8 "ARM: ixp4xx: stop broadcasting the custom GPIO API"
> changed the internal gpio code of ixp4xx to be accessible only from
> common.c, but unfortunately that broke the Goramo MultiLink code, which
> uses this API.
>
> This tries to restore the previous state without exposing the
> API globally again. A better solution might be needed.

I think making the changes similar to those done to other IXP4xx
platforms is, indeed, preferred. Patch posted.
-- 
Krzysztof Halasa

[PATCH 16/62] ARM: ixp4xx: avoid use of PCIBIOS_MIN_MEM in io.h

[Krzysztof Halasa]

Arnd Bergmann <arnd@arndb.de> writes:

> When using CONFIG_IXP4XX_INDIRECT_PCI, we run into a recursive
> header file dependency between mach/io.h and asm/pci.h, resulting
> in a build failure:

> +++ b/arch/arm/mach-ixp4xx/include/mach/io.h
> @@ -48,9 +48,10 @@ extern int ixp4xx_pci_write(u32 addr, u32 cmd, u32 data);
>   * fallback to the default.
>   */
>  
> +extern unsigned long pcibios_min_mem;
>  static inline int is_pci_memory(u32 addr)
>  {
> -	return (addr >= PCIBIOS_MIN_MEM) && (addr <= 0x4FFFFFFF);
> +	return (addr >= pcibios_min_mem) && (addr <= 0x4FFFFFFF);
>  }
>  

Not that I like externs very much, but since we're fixing things...
Polishing may be done later.

Acked-by: Krzysztof Halasa <khc@pm.waw.pl>
-- 
Krzysztof Halasa

[PATCH 15/62] ARM: ixp4xx/omixp: always include linux/leds.h

[Krzysztof Halasa]

Arnd Bergmann <arnd@arndb.de> writes:

> The omixp board code unconditionally defines a gpio-led
> device, but for some reason includes the header file
> for this only if CONFIG_LEDS_CLASS is enabled, causing
> a build error otherwise.
>
> Removing the #ifdef fixes the build error with no downsides
> whatsoever.

Acked-by: Krzysztof Halasa <khc@pm.waw.pl>
-- 
Krzysztof Halasa

[PATCH 10/62] ARM: efm32: select AUTO_ZRELADDR

[Uwe Kleine-König]

On Sat, Mar 22, 2014 at 10:27:09AM +0100, Arnd Bergmann wrote:
> On Friday 21 March 2014, Rob Herring wrote:
> > On Fri, Mar 21, 2014 at 1:54 PM, Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de> wrote:
> > > On Fri, Mar 21, 2014 at 04:10:37PM +0100, Arnd Bergmann wrote:
> > >> I don't see a reason to change the existing logic, it works for
> > >> both MMU and NOMMU kernels, and you are talking about three instructions
> > >> here.
> > > it doesn't matter how many instructions are involved. The relevant
> > > difference is that with my approach you fix the problem for all no-MMU
> > > platforms, with yours you only fix efm32. (OK, I think there are not too
> > > many no-MMU platforms, but still.) An even easier implementation would
> > > be to add something like:
> > >
> > >         ifeq($(zreladdr-y)$(CONFIG_MMU),)
> > >         zreladdr-y := CONFIG_PAGE_OFFSET + CONFIG_TEXT_OFFSET
> > >         endif
> > >
> > > to arch/arm/boot/Makefile.
> 
> This makes sense, we can add it as soon as we have a use for it. At the
> moment, the only problem we have is a randconfig build error, and the
> obvious change I proposed should work just fine.
My suggestion is an alternative fix for the randconfig error you see, so
there is a use already now. I fail to compile a zImage for different
reasons on top of next, but maybe this works instead of your patch:

diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile
index ec2f8065f955..2d935dd098e5 100644
--- a/arch/arm/boot/Makefile
+++ b/arch/arm/boot/Makefile
@@ -15,6 +15,10 @@ ifneq ($(MACHINE),)
 include $(srctree)/$(MACHINE)/Makefile.boot
 endif
 
+ifeq ($(zreladdr-y)$(CONFIG_MMU),)
+zreladdr-y := $(CONFIG_PAGE_OFFSET)+$(TEXT_OFFSET)
+endif
+
 # Note: the following conditions must always be true:
 #   ZRELADDR == virt_to_phys(PAGE_OFFSET + TEXT_OFFSET)
 #   PARAMS_PHYS must be within 4MB of ZRELADDR

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Re: [PATCH 60/62] ARM: shmobile: work around CONFIG_PHYLIB=m

[Simon Horman]

On Fri, Mar 21, 2014 at 04:43:24PM +0100, Arnd Bergmann wrote:
> On Thursday 20 March 2014, Simon Horman wrote:
> > On Wed, Mar 19, 2014 at 08:29:57PM +0100, Arnd Bergmann wrote:
> > > When phylib is set to be built as a module, the lager and koelsch
> > > boards fail to build:
> > > 
> > > arch/arm/mach-shmobile/built-in.o: In function `lager_ksz8041_fixup':
> > > :(.text+0x738): undefined reference to `mdiobus_read'
> > > :(.text+0x73c): undefined reference to `mdiobus_write'
> > > arch/arm/mach-shmobile/built-in.o: In function `koelsch_ksz8041_fixup':
> > > :(.text+0x7e8): undefined reference to `mdiobus_read'
> > > :(.text+0x7ec): undefined reference to `mdiobus_write'
> > > 
> > > To work around that problem, this changes the code to check for
> > > IS_BUILTIN rather than IS_ENABLED, turning the error into a runtime
> > > problem. It's now possible to build random configurations, but the
> > > phy may be set up incorrectly in this case.
> > 
> > I wonder if Kconfig for koelsch should be tightened up somehow to
> > ensure that PHYLIB is either unselected or builtin.
> > 
> > Also, a minor nit, I would prefer changes for different boards
> > in different patches. But I can split the patch myself if its
> > not going to be changed otherwise.
> 
> I would prefer to take the entire series directly into arm-soc
> this time, if you don't mind.

That I'm happy to go along with though I don't understand the motivation
for it. And regardless of how the patches go in I'd prefer if they were
split as I suggested above.


What I'm not so happy about is us potentially moving a problem from being a
compile time error, which is easy to observe, to a run-time behavioural
problem, which may be much less obvious to the beholder.

[PATCH 60/62] ARM: shmobile: work around CONFIG_PHYLIB=m

[Simon Horman]

On Fri, Mar 21, 2014 at 04:43:24PM +0100, Arnd Bergmann wrote:
> On Thursday 20 March 2014, Simon Horman wrote:
> > On Wed, Mar 19, 2014 at 08:29:57PM +0100, Arnd Bergmann wrote:
> > > When phylib is set to be built as a module, the lager and koelsch
> > > boards fail to build:
> > > 
> > > arch/arm/mach-shmobile/built-in.o: In function `lager_ksz8041_fixup':
> > > :(.text+0x738): undefined reference to `mdiobus_read'
> > > :(.text+0x73c): undefined reference to `mdiobus_write'
> > > arch/arm/mach-shmobile/built-in.o: In function `koelsch_ksz8041_fixup':
> > > :(.text+0x7e8): undefined reference to `mdiobus_read'
> > > :(.text+0x7ec): undefined reference to `mdiobus_write'
> > > 
> > > To work around that problem, this changes the code to check for
> > > IS_BUILTIN rather than IS_ENABLED, turning the error into a runtime
> > > problem. It's now possible to build random configurations, but the
> > > phy may be set up incorrectly in this case.
> > 
> > I wonder if Kconfig for koelsch should be tightened up somehow to
> > ensure that PHYLIB is either unselected or builtin.
> > 
> > Also, a minor nit, I would prefer changes for different boards
> > in different patches. But I can split the patch myself if its
> > not going to be changed otherwise.
> 
> I would prefer to take the entire series directly into arm-soc
> this time, if you don't mind.

That I'm happy to go along with though I don't understand the motivation
for it. And regardless of how the patches go in I'd prefer if they were
split as I suggested above.


What I'm not so happy about is us potentially moving a problem from being a
compile time error, which is easy to observe, to a run-time behavioural
problem, which may be much less obvious to the beholder.

[PATCH 08/62] ARM: davinci: use explicit 'select' for DA850_EVM

[Sekhar Nori]

On Friday 21 March 2014 09:26 PM, Arnd Bergmann wrote:

> From 5eaf7fdfe7c831d3aa24428a6e8d4509ac160db6 Mon Sep 17 00:00:00 2001
> From: Arnd Bergmann <arnd@arndb.de>
> Date: Tue, 18 Feb 2014 12:23:19 +0100
> Subject: [PATCH] ARM: davinci: use explicit 'select' for DA850_EVM
> 
> The DAVINCI_DA850_EVM board uses an unusual method to
> enable the GPIO_PCA953X and KEYBOARD_GPIO_POLLED symbols,
> which leads to the dependencies on these symbols being
> ignored. As GPIO_PCA953X actually requires I2C, that
> can lead to build failures when I2C is disabled.
> 
> This patch removes the duplicate symbol definitions
> and instead enables them from the davinci_all_defconfig
> file.

> A different question whether we actually want to automatically
> enable them at all or rather put them into defconfig,
> but that should be a separate patch.

This para can be dropped now.

> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Acked-by: Sekhar Nori <nsekhar@ti.com>
> Cc: Kevin Hilman <khilman@deeprootsystems.com>
> Cc: davinci-linux-open-source at linux.davincidsp.com

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

Thanks,
Sekhar

[PATCH] ARM: determine zreladdr for no-MMU machines automatically

[Uwe Kleine-König]

zreladdr must be virt_to_phys(PAGE_OFFSET + TEXT_OFFSET). For no-MMU
machines virt_to_phys is the identity mapping so zreladdr can be defined
to just PAGE_OFFSET + TEXT_OFFSET for no-MMU machines.

This fixes one of the problems when trying to compile a zImage for efm32
because this platform doesn't define zreladdr.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
Hello,

I tested this patch on top of Arnd's randconfig branch[1], it allowed to
drop db5fbcd0d71e (ARM: efm32: select AUTO_ZRELADDR) from it with zImage
still being compilable. When checking at91x40 (i.e. the other no-MMU
platform with a defconfig file), this patch would introduce a change
because arch/arm/mach-at91/Makefile.boot defines

	zreladdr-y += 0x20008000

but CONFIG_PAGE_OFFSET=0x01000000. I think that's a bug and my patch
does the right thing. Note that the at91x40 case isn't fixed though.

Best regards
Uwe

[1] http://git.kernel.org/cgit/linux/kernel/git/arnd/playground.git/?h=randconfig, commit:e65d61db588a057b5cbc3ba9bc8110819e05d748

 arch/arm/boot/Makefile | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile
index ec2f8065f955..2d935dd098e5 100644
--- a/arch/arm/boot/Makefile
+++ b/arch/arm/boot/Makefile
@@ -15,6 +15,10 @@ ifneq ($(MACHINE),)
 include $(srctree)/$(MACHINE)/Makefile.boot
 endif
 
+ifeq ($(zreladdr-y)$(CONFIG_MMU),)
+zreladdr-y := $(CONFIG_PAGE_OFFSET)+$(TEXT_OFFSET)
+endif
+
 # Note: the following conditions must always be true:
 #   ZRELADDR == virt_to_phys(PAGE_OFFSET + TEXT_OFFSET)
 #   PARAMS_PHYS must be within 4MB of ZRELADDR
-- 
1.9.0

Re: [PATCH 60/62] ARM: shmobile: work around CONFIG_PHYLIB=m

[Arnd Bergmann]

On Monday 24 March 2014 10:35:56 Simon Horman wrote:
> On Fri, Mar 21, 2014 at 04:43:24PM +0100, Arnd Bergmann wrote:
> > On Thursday 20 March 2014, Simon Horman wrote:
> > > I wonder if Kconfig for koelsch should be tightened up somehow to
> > > ensure that PHYLIB is either unselected or builtin.
> > > 
> > > Also, a minor nit, I would prefer changes for different boards
> > > in different patches. But I can split the patch myself if its
> > > not going to be changed otherwise.
> > 
> > I would prefer to take the entire series directly into arm-soc
> > this time, if you don't mind.
> 
> That I'm happy to go along with though I don't understand the motivation
> for it. And regardless of how the patches go in I'd prefer if they were
> split as I suggested above.

Sorry, I misunderstood you at first. I thought you meant you only split
them up when you apply them yourself. It's no problem for me to split
up this patch as well and then apply it here.

> What I'm not so happy about is us potentially moving a problem from being a
> compile time error, which is easy to observe, to a run-time behavioural
> problem, which may be much less obvious to the beholder.

I agree that it's not nice, but I couldn't come with a better approach,
and we are doing the same thing on other platforms as well.

The problems are:

* leaving the code as it is today prevents me from running all
  'make randconfig' kernels successfully. I use this as an important
  test case for verifying stuff we pull into the arm-soc tree.
  At the moment, I have a 160-patch series that I want to get merged
  upstream over time.

* Using 'select PHYLIB' from the platform is nasty because we want
  to be able to turn off whole subsystems (BLOCK, NET, I2C, ...)
  in Kconfig independent of the board selection. PHYLIB requires
  the network code.

* Using 'depends on' to disable the board option if PHYLIB is
  a module is counterintuitive.

* Makeing PHYLIB always built-in when NETDEVICE is would be a
  bit wasteful.

I don't have any other ideas for solving this.

	Arnd

[PATCH 60/62] ARM: shmobile: work around CONFIG_PHYLIB=m

[Arnd Bergmann]

On Monday 24 March 2014 10:35:56 Simon Horman wrote:
> On Fri, Mar 21, 2014 at 04:43:24PM +0100, Arnd Bergmann wrote:
> > On Thursday 20 March 2014, Simon Horman wrote:
> > > I wonder if Kconfig for koelsch should be tightened up somehow to
> > > ensure that PHYLIB is either unselected or builtin.
> > > 
> > > Also, a minor nit, I would prefer changes for different boards
> > > in different patches. But I can split the patch myself if its
> > > not going to be changed otherwise.
> > 
> > I would prefer to take the entire series directly into arm-soc
> > this time, if you don't mind.
> 
> That I'm happy to go along with though I don't understand the motivation
> for it. And regardless of how the patches go in I'd prefer if they were
> split as I suggested above.

Sorry, I misunderstood you at first. I thought you meant you only split
them up when you apply them yourself. It's no problem for me to split
up this patch as well and then apply it here.

> What I'm not so happy about is us potentially moving a problem from being a
> compile time error, which is easy to observe, to a run-time behavioural
> problem, which may be much less obvious to the beholder.

I agree that it's not nice, but I couldn't come with a better approach,
and we are doing the same thing on other platforms as well.

The problems are:

* leaving the code as it is today prevents me from running all
  'make randconfig' kernels successfully. I use this as an important
  test case for verifying stuff we pull into the arm-soc tree.
  At the moment, I have a 160-patch series that I want to get merged
  upstream over time.

* Using 'select PHYLIB' from the platform is nasty because we want
  to be able to turn off whole subsystems (BLOCK, NET, I2C, ...)
  in Kconfig independent of the board selection. PHYLIB requires
  the network code.

* Using 'depends on' to disable the board option if PHYLIB is
  a module is counterintuitive.

* Makeing PHYLIB always built-in when NETDEVICE is would be a
  bit wasteful.

I don't have any other ideas for solving this.

	Arnd

[PATCH 61/62] ARM: sunxi: fix build for THUMB2_KERNEL

[Maxime Ripard]

On Fri, Mar 21, 2014 at 05:24:21PM +0100, Arnd Bergmann wrote:
> On Friday 21 March 2014 17:05:09 Arnd Bergmann wrote:
> > On Friday 21 March 2014 10:54:49 Rob Herring wrote:
> > > The first things secondary_startup do are:
> > > 
> > > -set BE mode
> > > -if in HYP mode, install hyp vectors and drop to SVC
> > > -set the CPSR to a know value (safe_svcmode_maskall r9)
> > > 
> > > So this code is completely redundant and unnecessary. If there were
> > > some reason for it, then it should be in secondary_startup.
> > 
> > Ah, thanks for the clarification. Shall we just delete the file then
> > and jump straight to secondary_startup?
> 
> Maxime, can you test the new version?
> 
> From 2f6220cee15e45446c43e5c43affa85a6c407b31 Mon Sep 17 00:00:00 2001
> From: Arnd Bergmann <arnd@arndb.de>
> Date: Sun, 16 Mar 2014 18:04:54 +0100
> Subject: [PATCH] ARM: sunxi: fix build for THUMB2_KERNEL
> 
> Building an SMP kernel for the sunxi platform with THUMB2 instructions
> fails with this error at the moment:
> 
> headsmp.S:7: Error: Thumb encoding does not support an immediate here -- `msr cpsr_fsxc,#0xd3'
> 
> Since the generic secondary_startup function already does
> the same thing in a safe way, we can just drop the private
> sunxi implementation and jump straight to secondary_startup.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Maxime Ripard <maxime.ripard@free-electrons.com>

With the additional changes you mentionned later that unbreaks the
compilation, you have my acked-by.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140324/92693cd9/attachment-0001.sig>

Re: [PATCH 60/62] ARM: shmobile: work around CONFIG_PHYLIB=m

[Uwe Kleine-König]

On Mon, Mar 24, 2014 at 01:04:57PM +0100, Arnd Bergmann wrote:
> On Monday 24 March 2014 10:35:56 Simon Horman wrote:
> > On Fri, Mar 21, 2014 at 04:43:24PM +0100, Arnd Bergmann wrote:
> > > On Thursday 20 March 2014, Simon Horman wrote:
> > > > I wonder if Kconfig for koelsch should be tightened up somehow to
> > > > ensure that PHYLIB is either unselected or builtin.
> > > > 
> > > > Also, a minor nit, I would prefer changes for different boards
> > > > in different patches. But I can split the patch myself if its
> > > > not going to be changed otherwise.
> > > 
> > > I would prefer to take the entire series directly into arm-soc
> > > this time, if you don't mind.
> > 
> > That I'm happy to go along with though I don't understand the motivation
> > for it. And regardless of how the patches go in I'd prefer if they were
> > split as I suggested above.
> 
> Sorry, I misunderstood you at first. I thought you meant you only split
> them up when you apply them yourself. It's no problem for me to split
> up this patch as well and then apply it here.
> 
> > What I'm not so happy about is us potentially moving a problem from being a
> > compile time error, which is easy to observe, to a run-time behavioural
> > problem, which may be much less obvious to the beholder.
> 
> I agree that it's not nice, but I couldn't come with a better approach,
> and we are doing the same thing on other platforms as well.
> 
> The problems are:
> 
> * leaving the code as it is today prevents me from running all
>   'make randconfig' kernels successfully. I use this as an important
>   test case for verifying stuff we pull into the arm-soc tree.
>   At the moment, I have a 160-patch series that I want to get merged
>   upstream over time.
> 
> * Using 'select PHYLIB' from the platform is nasty because we want
>   to be able to turn off whole subsystems (BLOCK, NET, I2C, ...)
>   in Kconfig independent of the board selection. PHYLIB requires
>   the network code.
> 
> * Using 'depends on' to disable the board option if PHYLIB is
>   a module is counterintuitive.
> 
> * Makeing PHYLIB always built-in when NETDEVICE is would be a
>   bit wasteful.
maybe let the board

	select PHYLIB if NETDEVICE

is a nice compromise?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[PATCH 60/62] ARM: shmobile: work around CONFIG_PHYLIB=m

[Uwe Kleine-König]

On Mon, Mar 24, 2014 at 01:04:57PM +0100, Arnd Bergmann wrote:
> On Monday 24 March 2014 10:35:56 Simon Horman wrote:
> > On Fri, Mar 21, 2014 at 04:43:24PM +0100, Arnd Bergmann wrote:
> > > On Thursday 20 March 2014, Simon Horman wrote:
> > > > I wonder if Kconfig for koelsch should be tightened up somehow to
> > > > ensure that PHYLIB is either unselected or builtin.
> > > > 
> > > > Also, a minor nit, I would prefer changes for different boards
> > > > in different patches. But I can split the patch myself if its
> > > > not going to be changed otherwise.
> > > 
> > > I would prefer to take the entire series directly into arm-soc
> > > this time, if you don't mind.
> > 
> > That I'm happy to go along with though I don't understand the motivation
> > for it. And regardless of how the patches go in I'd prefer if they were
> > split as I suggested above.
> 
> Sorry, I misunderstood you at first. I thought you meant you only split
> them up when you apply them yourself. It's no problem for me to split
> up this patch as well and then apply it here.
> 
> > What I'm not so happy about is us potentially moving a problem from being a
> > compile time error, which is easy to observe, to a run-time behavioural
> > problem, which may be much less obvious to the beholder.
> 
> I agree that it's not nice, but I couldn't come with a better approach,
> and we are doing the same thing on other platforms as well.
> 
> The problems are:
> 
> * leaving the code as it is today prevents me from running all
>   'make randconfig' kernels successfully. I use this as an important
>   test case for verifying stuff we pull into the arm-soc tree.
>   At the moment, I have a 160-patch series that I want to get merged
>   upstream over time.
> 
> * Using 'select PHYLIB' from the platform is nasty because we want
>   to be able to turn off whole subsystems (BLOCK, NET, I2C, ...)
>   in Kconfig independent of the board selection. PHYLIB requires
>   the network code.
> 
> * Using 'depends on' to disable the board option if PHYLIB is
>   a module is counterintuitive.
> 
> * Makeing PHYLIB always built-in when NETDEVICE is would be a
>   bit wasteful.
maybe let the board

	select PHYLIB if NETDEVICE

is a nice compromise?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[PATCH 43/62] ARM: integrator: only select pl01x if TTY is enabled

[Linus Walleij]

On Wed, Mar 19, 2014 at 8:29 PM, Arnd Bergmann <arnd@arndb.de> wrote:

> Building the integrator platform without TTY support currently
> results in a build failure because we always turn on the
> pl010 or pl011 drivers. Changing this to a conditional 'select'
> statement enables us to build more random configurations, although
> it should have little impact for practical configurations.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Linus Walleij <linus.walleij@linaro.org>

Acked-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

[PATCH 42/62] ARM: realview: use explicit core tile config options

[Linus Walleij]

On Wed, Mar 19, 2014 at 8:29 PM, Arnd Bergmann <arnd@arndb.de> wrote:

> The realview platform can be used with numerous core tiles,
> which have to be enabled in the CPU menu at the moment, and
> the user has to know at configuration time which CPUs can
> be enabled in the same kernel.
>
> Most importantly, it is not a valid configuration to select
> both ARMv5 and ARMv6/v7 based CPU cores in the same kernel,
> and trying that leads to compile errors.
>
> To make it possible to use realview on randconfig kernels,
> and to simplify manual configuration, this lists all
> supported combinations of machines and core tiles explicitly
> and ensures that we cannot enable the ARM926T CPU if any
> ARMv6 or v7 CPU is already enabled.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Linus Walleij <linus.walleij@linaro.org>

Looks good to me, I'd ask Will and/or Marc to have a look at this
and confirm.

Yours,
Linus Walleij

[PATCH 42/62] ARM: realview: use explicit core tile config options

[Arnd Bergmann]

On Tuesday 25 March 2014 15:10:31 Linus Walleij wrote:
> On Wed, Mar 19, 2014 at 8:29 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> 
> > The realview platform can be used with numerous core tiles,
> > which have to be enabled in the CPU menu at the moment, and
> > the user has to know at configuration time which CPUs can
> > be enabled in the same kernel.
> >
> > Most importantly, it is not a valid configuration to select
> > both ARMv5 and ARMv6/v7 based CPU cores in the same kernel,
> > and trying that leads to compile errors.
> >
> > To make it possible to use realview on randconfig kernels,
> > and to simplify manual configuration, this lists all
> > supported combinations of machines and core tiles explicitly
> > and ensures that we cannot enable the ARM926T CPU if any
> > ARMv6 or v7 CPU is already enabled.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Russell King <linux@arm.linux.org.uk>
> > Cc: Linus Walleij <linus.walleij@linaro.org>
> 
> Looks good to me, I'd ask Will and/or Marc to have a look at this
> and confirm.

I actually dropped it already, along with the integrator patch
of the same purpose. It will become easier when they are both
multiplatform enabled.

	Arnd

[PATCH 44/62] ARM: integrator: refine CPU selection

[Linus Walleij]

On Thu, Mar 20, 2014 at 11:48 AM, Arnd Bergmann <arnd@arndb.de> wrote:

> Nevermind, I'll drop this patch for now, I just had an idea to do it
> better: Since Linus and I are trying to get Integrator and Realview
> moved over into ARCH_MULTIPLATFORM anyway, I'll defer the CPU selection
> question until that's done.

Integrator is blocked by one single thing: <mach/memory.h>
bus_to_virt/virt_to_bus.

If we can get some consensus on Santosh's patches
(or however we want to solve that) I'll do multiplatform for
Integrator any day.

Yours,
Linus Walleij

[PATCH 44/62] ARM: integrator: refine CPU selection

[Arnd Bergmann]

On Tuesday 25 March 2014 21:34:21 Linus Walleij wrote:
> On Thu, Mar 20, 2014 at 11:48 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> 
> > Nevermind, I'll drop this patch for now, I just had an idea to do it
> > better: Since Linus and I are trying to get Integrator and Realview
> > moved over into ARCH_MULTIPLATFORM anyway, I'll defer the CPU selection
> > question until that's done.
> 
> Integrator is blocked by one single thing: <mach/memory.h>
> bus_to_virt/virt_to_bus.
> 
> If we can get some consensus on Santosh's patches
> (or however we want to solve that) I'll do multiplatform for
> Integrator any day.

Yes, I know. My point is that once the two are multiplatform, we wouldn't
do the CPU selection patches like this anymore. Instead, I would just do

config CPU_ARM920T
	bool "Support ARM920T processor" if ARCH_MULTI_V4T
	...

config CPU_ARM926T
	bool "Support ARM920T processor" if ARCH_MULTI_V5
	...

...

In a multiplatform kernel, there is nothing wrong with just letting
users turn on arbitrary combinations of CPUs as long as they are
compatible at run-time (i.e. not v5+v7 combined). This will also let
you run qemu images using the MACH_VIRT target and any CPU emulation.

Of course, most platforms will still select the CPUs they actually
use, but you can always add more.

	Arnd

[PATCH 44/62] ARM: integrator: refine CPU selection

[Linus Walleij]

On Wed, Mar 26, 2014 at 12:42 AM, Arnd Bergmann <arnd@arndb.de> wrote:

> My point is that once the two are multiplatform, we wouldn't
> do the CPU selection patches like this anymore. Instead, I would just do
>
> config CPU_ARM920T
>         bool "Support ARM920T processor" if ARCH_MULTI_V4T
>         ...
>
> config CPU_ARM926T
>         bool "Support ARM920T processor" if ARCH_MULTI_V5
>         ...

Ah I see, that's elegant. Yes let's go for this.

Yours,
Linus Walleij