[PATCH 00/15] ARM build regressions in v3.8

[PATCH 00/15] ARM build regressions in v3.8

[Arnd Bergmann]

I know this comes late, but we have a number of broken
configurations in ARM in v3.8 that were still building
in v3.7, and I'd like to get them all fixed in the
final 3.8 release.

It would be nice if the respective maintainers could
have a look at these patches and apply them directly
when they are happy with them.

The first patch in the series is strictly speaking
not a build error but just a warning, but it is a
particularly annoying one that came in through the
latest binutils release rather than a kernel change.

The same binutils update also broke the samsung
and w90x900 platforms.

A few of the other changes are the result of the
imx multiplatform conversion. I'm not really fixing
those here, just picking up the pieces. It would
be much nicer if we could actually get those drivers
to work again with CONFIG_MULTIPLATFORM enabled
rather than just disabling them, but it may be
much too late for that. At least the drivers don't
seem to be too essential, as they are only built
in allyesconfig but not in any of the defconfigs.

	Arnd

Arnd Bergmann (15):
  ARM: compressed/head.S: work around new binutils warning
  ARM: mvebu: build coherency_ll.S for arch=armv7-a
  ARM: samsung: fix assembly syntax for new gas
  ARM: w90x900: fix legacy assembly syntax
  ASoC: fsl: fiq and dma cannot both be modules
  clk: export __clk_get_name
  drm/exynos: don't include plat/gpio-cfg.h
  drm/exynos: fimd and ipp are broken on multiplatform
  media: coda: don't build on multiplatform
  mfd/vexpress: export vexpress_config_func_{put,get}
  mtd: davinci_nand: fix OF support
  USB: gadget/freescale: disable non-multiplatform drivers
  USB: ehci: make orion and mxc bus glues coexist
  samples/seccomp: be less stupid about cross compiling
  staging/omapdrm: don't build on multiplatform

 arch/arm/boot/compressed/Makefile                |    2 +-
 arch/arm/boot/compressed/head.S                  |   12 ++++++++++++
 arch/arm/mach-mvebu/coherency_ll.S               |    1 +
 arch/arm/mach-s3c24xx/include/mach/debug-macro.S |   12 ++++++------
 arch/arm/mach-s3c24xx/include/mach/entry-macro.S |    4 ++--
 arch/arm/mach-s3c24xx/pm-h1940.S                 |    2 +-
 arch/arm/mach-s3c24xx/sleep-s3c2410.S            |   12 ++++++------
 arch/arm/mach-s3c24xx/sleep-s3c2412.S            |   12 ++++++------
 arch/arm/mach-w90x900/include/mach/entry-macro.S |    4 ++--
 arch/arm/plat-samsung/include/plat/debug-macro.S |   18 +++++++++---------
 drivers/clk/clk.c                                |    1 +
 drivers/gpu/drm/exynos/Kconfig                   |    4 ++--
 drivers/gpu/drm/exynos/exynos_hdmi.c             |    1 -
 drivers/media/platform/Kconfig                   |    2 +-
 drivers/mfd/vexpress-config.c                    |    3 ++-
 drivers/mtd/nand/davinci_nand.c                  |    2 +-
 drivers/staging/omapdrm/Kconfig                  |    2 +-
 drivers/usb/gadget/Kconfig                       |    3 ++-
 drivers/usb/host/ehci-hcd.c                      |   16 +++++++++++++++-
 samples/seccomp/Makefile                         |    2 ++
 sound/soc/fsl/Kconfig                            |    3 +++
 21 files changed, 76 insertions(+), 42 deletions(-)

-- 
1.7.10.4
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: David Airlie <airlied@linux.ie>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: James Morris <james.l.morris@oracle.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: Mike Turquette <mturquette@linaro.org>
Cc: Rob Clark <rob@ti.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: alsa-devel@alsa-project.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-media@vger.kernel.org
Cc: linux-usb@vger.kernel.org

[PATCH 00/15] ARM build regressions in v3.8

[Arnd Bergmann]

I know this comes late, but we have a number of broken
configurations in ARM in v3.8 that were still building
in v3.7, and I'd like to get them all fixed in the
final 3.8 release.

It would be nice if the respective maintainers could
have a look at these patches and apply them directly
when they are happy with them.

The first patch in the series is strictly speaking
not a build error but just a warning, but it is a
particularly annoying one that came in through the
latest binutils release rather than a kernel change.

The same binutils update also broke the samsung
and w90x900 platforms.

A few of the other changes are the result of the
imx multiplatform conversion. I'm not really fixing
those here, just picking up the pieces. It would
be much nicer if we could actually get those drivers
to work again with CONFIG_MULTIPLATFORM enabled
rather than just disabling them, but it may be
much too late for that. At least the drivers don't
seem to be too essential, as they are only built
in allyesconfig but not in any of the defconfigs.

	Arnd

Arnd Bergmann (15):
  ARM: compressed/head.S: work around new binutils warning
  ARM: mvebu: build coherency_ll.S for arch=armv7-a
  ARM: samsung: fix assembly syntax for new gas
  ARM: w90x900: fix legacy assembly syntax
  ASoC: fsl: fiq and dma cannot both be modules
  clk: export __clk_get_name
  drm/exynos: don't include plat/gpio-cfg.h
  drm/exynos: fimd and ipp are broken on multiplatform
  media: coda: don't build on multiplatform
  mfd/vexpress: export vexpress_config_func_{put,get}
  mtd: davinci_nand: fix OF support
  USB: gadget/freescale: disable non-multiplatform drivers
  USB: ehci: make orion and mxc bus glues coexist
  samples/seccomp: be less stupid about cross compiling
  staging/omapdrm: don't build on multiplatform

 arch/arm/boot/compressed/Makefile                |    2 +-
 arch/arm/boot/compressed/head.S                  |   12 ++++++++++++
 arch/arm/mach-mvebu/coherency_ll.S               |    1 +
 arch/arm/mach-s3c24xx/include/mach/debug-macro.S |   12 ++++++------
 arch/arm/mach-s3c24xx/include/mach/entry-macro.S |    4 ++--
 arch/arm/mach-s3c24xx/pm-h1940.S                 |    2 +-
 arch/arm/mach-s3c24xx/sleep-s3c2410.S            |   12 ++++++------
 arch/arm/mach-s3c24xx/sleep-s3c2412.S            |   12 ++++++------
 arch/arm/mach-w90x900/include/mach/entry-macro.S |    4 ++--
 arch/arm/plat-samsung/include/plat/debug-macro.S |   18 +++++++++---------
 drivers/clk/clk.c                                |    1 +
 drivers/gpu/drm/exynos/Kconfig                   |    4 ++--
 drivers/gpu/drm/exynos/exynos_hdmi.c             |    1 -
 drivers/media/platform/Kconfig                   |    2 +-
 drivers/mfd/vexpress-config.c                    |    3 ++-
 drivers/mtd/nand/davinci_nand.c                  |    2 +-
 drivers/staging/omapdrm/Kconfig                  |    2 +-
 drivers/usb/gadget/Kconfig                       |    3 ++-
 drivers/usb/host/ehci-hcd.c                      |   16 +++++++++++++++-
 samples/seccomp/Makefile                         |    2 ++
 sound/soc/fsl/Kconfig                            |    3 +++
 21 files changed, 76 insertions(+), 42 deletions(-)

-- 
1.7.10.4
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: David Airlie <airlied@linux.ie>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: James Morris <james.l.morris@oracle.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: Mike Turquette <mturquette@linaro.org>
Cc: Rob Clark <rob@ti.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: alsa-devel at alsa-project.org
Cc: dri-devel at lists.freedesktop.org
Cc: linux-media at vger.kernel.org
Cc: linux-usb at vger.kernel.org

[PATCH 01/15] ARM: compressed/head.S: work around new binutils warning

[Arnd Bergmann]

In August 2012, Matthew Gretton-Dann checked a change
into binutils labelled "Error on obsolete & warn on
deprecated registers", apparently as part of ARMv8
support. Apparently, this was supposed to emit
the message "Warning: This coprocessor register access
is deprecated in ARMv8" when using certain mcr/mrc
instructions and building for ARMv8. Unfortunately,
the message that is actually emitted appears to be
'(null)', which is less helpful in comparison.

Even more unfortunately, this is biting us on
every single kernel build with a new gas, because
arch/arm/boot/compressed/head.S and some other files
in that directory are built with -march=all since
kernel commit 80cec14a8 "[ARM] Add -march=all to
assembly file build in arch/arm/boot/compressed"
back in v2.6.28.

This patch reverts Russell's nice solution and
replaces it with a more complex one that sprinkles
.arch statements inside of the head.S file in
functions that are executed in different architecture
levels, which seems to solve the original problem
just as well, and gets rid of the new one, too.

Without this patch, building anything results in:

arch/arm/boot/compressed/head.S: Assembler messages:
arch/arm/boot/compressed/head.S:565: Warning: (null)
arch/arm/boot/compressed/head.S:676: Warning: (null)
arch/arm/boot/compressed/head.S:698: Warning: (null)
arch/arm/boot/compressed/head.S:722: Warning: (null)
arch/arm/boot/compressed/head.S:726: Warning: (null)
arch/arm/boot/compressed/head.S:957: Warning: (null)
arch/arm/boot/compressed/head.S:996: Warning: (null)
arch/arm/boot/compressed/head.S:997: Warning: (null)
arch/arm/boot/compressed/head.S:1027: Warning: (null)
arch/arm/boot/compressed/head.S:1035: Warning: (null)
arch/arm/boot/compressed/head.S:1046: Warning: (null)
arch/arm/boot/compressed/head.S:1060: Warning: (null)
arch/arm/boot/compressed/head.S:1092: Warning: (null)
arch/arm/boot/compressed/head.S:1094: Warning: (null)
arch/arm/boot/compressed/head.S:1095: Warning: (null)
arch/arm/boot/compressed/head.S:1102: Warning: (null)
arch/arm/boot/compressed/head.S:1134: Warning: (null)

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Matthew Gretton-Dann <matthew.gretton-dann@arm.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/boot/compressed/Makefile |    2 +-
 arch/arm/boot/compressed/head.S   |   12 ++++++++++++
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index 5cad8a6..dfe5687 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -121,7 +121,7 @@ KBUILD_CFLAGS = $(subst -pg, , $(ORIG_CFLAGS))
 endif
 
 ccflags-y := -fpic -fno-builtin -I$(obj)
-asflags-y := -Wa,-march=all -DZIMAGE
+asflags-y := -DZIMAGE
 
 # Supply kernel BSS size to the decompressor via a linker symbol.
 KBSS_SZ = $(shell $(CROSS_COMPILE)size $(obj)/../../../../vmlinux | \
diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index fe4d9c3..3b0b21a 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -548,6 +548,7 @@ cache_on:	mov	r3, #8			@ cache_on function
  * to cover all 32bit address and cacheable and bufferable.
  */
 __armv4_mpu_cache_on:
+		.arch armv4
 		mov	r0, #0x3f		@ 4G, the whole
 		mcr	p15, 0, r0, c6, c7, 0	@ PR7 Area Setting
 		mcr 	p15, 0, r0, c6, c7, 1
@@ -655,6 +656,7 @@ ENDPROC(__setup_mmu)
 @ Enable unaligned access on v6, to allow better code generation
 @ for the decompressor C code:
 __armv6_mmu_cache_on:
+		.arch armv6
 		mrc	p15, 0, r0, c1, c0, 0	@ read SCTLR
 		bic	r0, r0, #2		@ A (no unaligned access fault)
 		orr	r0, r0, #1 << 22	@ U (v6 unaligned access model)
@@ -663,11 +665,13 @@ __armv6_mmu_cache_on:
 
 __arm926ejs_mmu_cache_on:
 #ifdef CONFIG_CPU_DCACHE_WRITETHROUGH
+		.arch armv5
 		mov	r0, #4			@ put dcache in WT mode
 		mcr	p15, 7, r0, c15, c0, 0
 #endif
 
 __armv4_mmu_cache_on:
+		.arch armv4
 		mov	r12, lr
 #ifdef CONFIG_MMU
 		mov	r6, #CB_BITS | 0x12	@ U
@@ -688,6 +692,7 @@ __armv4_mmu_cache_on:
 		mov	pc, r12
 
 __armv7_mmu_cache_on:
+		.arch armv7-a
 		mov	r12, lr
 #ifdef CONFIG_MMU
 		mrc	p15, 0, r11, c0, c1, 4	@ read ID_MMFR0
@@ -1031,6 +1036,7 @@ cache_clean_flush:
 		mov	r3, #16
 		b	call_cache_fn
 
+		.arch armv4
 __armv4_mpu_cache_flush:
 		mov	r2, #1
 		mov	r3, #0
@@ -1056,6 +1062,7 @@ __fa526_cache_flush:
 		mov	pc, lr
 
 __armv6_mmu_cache_flush:
+		.arch armv6
 		mov	r1, #0
 		mcr	p15, 0, r1, c7, c14, 0	@ clean+invalidate D
 		mcr	p15, 0, r1, c7, c5, 0	@ invalidate I+BTB
@@ -1063,6 +1070,7 @@ __armv6_mmu_cache_flush:
 		mcr	p15, 0, r1, c7, c10, 4	@ drain WB
 		mov	pc, lr
 
+		.arch armv7-a
 __armv7_mmu_cache_flush:
 		mrc	p15, 0, r10, c0, c1, 5	@ read ID_MMFR1
 		tst	r10, #0xf << 16		@ hierarchical cache (ARMv7)
@@ -1123,6 +1131,7 @@ iflush:
 		mcr	p15, 0, r10, c7, c5, 4	@ ISB
 		mov	pc, lr
 
+		.arch armv5
 __armv5tej_mmu_cache_flush:
 1:		mrc	p15, 0, r15, c7, c14, 3	@ test,clean,invalidate D cache
 		bne	1b
@@ -1130,6 +1139,7 @@ __armv5tej_mmu_cache_flush:
 		mcr	p15, 0, r0, c7, c10, 4	@ drain WB
 		mov	pc, lr
 
+		.arch armv4
 __armv4_mmu_cache_flush:
 		mov	r2, #64*1024		@ default: 32K dcache size (*2)
 		mov	r11, #32		@ default: 32 byte line size
@@ -1168,6 +1178,8 @@ __armv3_mpu_cache_flush:
 		mcr	p15, 0, r1, c7, c0, 0	@ invalidate whole cache v3
 		mov	pc, lr
 
+		.arch armv4
+
 /*
  * Various debugging routines for printing hex characters and
  * memory, which again must be relocatable.
-- 
1.7.10.4

[PATCH 01/15] ARM: compressed/head.S: work around new binutils warning

[Arnd Bergmann]

In August 2012, Matthew Gretton-Dann checked a change
into binutils labelled "Error on obsolete & warn on
deprecated registers", apparently as part of ARMv8
support. Apparently, this was supposed to emit
the message "Warning: This coprocessor register access
is deprecated in ARMv8" when using certain mcr/mrc
instructions and building for ARMv8. Unfortunately,
the message that is actually emitted appears to be
'(null)', which is less helpful in comparison.

Even more unfortunately, this is biting us on
every single kernel build with a new gas, because
arch/arm/boot/compressed/head.S and some other files
in that directory are built with -march=all since
kernel commit 80cec14a8 "[ARM] Add -march=all to
assembly file build in arch/arm/boot/compressed"
back in v2.6.28.

This patch reverts Russell's nice solution and
replaces it with a more complex one that sprinkles
.arch statements inside of the head.S file in
functions that are executed in different architecture
levels, which seems to solve the original problem
just as well, and gets rid of the new one, too.

Without this patch, building anything results in:

arch/arm/boot/compressed/head.S: Assembler messages:
arch/arm/boot/compressed/head.S:565: Warning: (null)
arch/arm/boot/compressed/head.S:676: Warning: (null)
arch/arm/boot/compressed/head.S:698: Warning: (null)
arch/arm/boot/compressed/head.S:722: Warning: (null)
arch/arm/boot/compressed/head.S:726: Warning: (null)
arch/arm/boot/compressed/head.S:957: Warning: (null)
arch/arm/boot/compressed/head.S:996: Warning: (null)
arch/arm/boot/compressed/head.S:997: Warning: (null)
arch/arm/boot/compressed/head.S:1027: Warning: (null)
arch/arm/boot/compressed/head.S:1035: Warning: (null)
arch/arm/boot/compressed/head.S:1046: Warning: (null)
arch/arm/boot/compressed/head.S:1060: Warning: (null)
arch/arm/boot/compressed/head.S:1092: Warning: (null)
arch/arm/boot/compressed/head.S:1094: Warning: (null)
arch/arm/boot/compressed/head.S:1095: Warning: (null)
arch/arm/boot/compressed/head.S:1102: Warning: (null)
arch/arm/boot/compressed/head.S:1134: Warning: (null)

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Matthew Gretton-Dann <matthew.gretton-dann@arm.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/boot/compressed/Makefile |    2 +-
 arch/arm/boot/compressed/head.S   |   12 ++++++++++++
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index 5cad8a6..dfe5687 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -121,7 +121,7 @@ KBUILD_CFLAGS = $(subst -pg, , $(ORIG_CFLAGS))
 endif
 
 ccflags-y := -fpic -fno-builtin -I$(obj)
-asflags-y := -Wa,-march=all -DZIMAGE
+asflags-y := -DZIMAGE
 
 # Supply kernel BSS size to the decompressor via a linker symbol.
 KBSS_SZ = $(shell $(CROSS_COMPILE)size $(obj)/../../../../vmlinux | \
diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index fe4d9c3..3b0b21a 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -548,6 +548,7 @@ cache_on:	mov	r3, #8			@ cache_on function
  * to cover all 32bit address and cacheable and bufferable.
  */
 __armv4_mpu_cache_on:
+		.arch armv4
 		mov	r0, #0x3f		@ 4G, the whole
 		mcr	p15, 0, r0, c6, c7, 0	@ PR7 Area Setting
 		mcr 	p15, 0, r0, c6, c7, 1
@@ -655,6 +656,7 @@ ENDPROC(__setup_mmu)
 @ Enable unaligned access on v6, to allow better code generation
 @ for the decompressor C code:
 __armv6_mmu_cache_on:
+		.arch armv6
 		mrc	p15, 0, r0, c1, c0, 0	@ read SCTLR
 		bic	r0, r0, #2		@ A (no unaligned access fault)
 		orr	r0, r0, #1 << 22	@ U (v6 unaligned access model)
@@ -663,11 +665,13 @@ __armv6_mmu_cache_on:
 
 __arm926ejs_mmu_cache_on:
 #ifdef CONFIG_CPU_DCACHE_WRITETHROUGH
+		.arch armv5
 		mov	r0, #4			@ put dcache in WT mode
 		mcr	p15, 7, r0, c15, c0, 0
 #endif
 
 __armv4_mmu_cache_on:
+		.arch armv4
 		mov	r12, lr
 #ifdef CONFIG_MMU
 		mov	r6, #CB_BITS | 0x12	@ U
@@ -688,6 +692,7 @@ __armv4_mmu_cache_on:
 		mov	pc, r12
 
 __armv7_mmu_cache_on:
+		.arch armv7-a
 		mov	r12, lr
 #ifdef CONFIG_MMU
 		mrc	p15, 0, r11, c0, c1, 4	@ read ID_MMFR0
@@ -1031,6 +1036,7 @@ cache_clean_flush:
 		mov	r3, #16
 		b	call_cache_fn
 
+		.arch armv4
 __armv4_mpu_cache_flush:
 		mov	r2, #1
 		mov	r3, #0
@@ -1056,6 +1062,7 @@ __fa526_cache_flush:
 		mov	pc, lr
 
 __armv6_mmu_cache_flush:
+		.arch armv6
 		mov	r1, #0
 		mcr	p15, 0, r1, c7, c14, 0	@ clean+invalidate D
 		mcr	p15, 0, r1, c7, c5, 0	@ invalidate I+BTB
@@ -1063,6 +1070,7 @@ __armv6_mmu_cache_flush:
 		mcr	p15, 0, r1, c7, c10, 4	@ drain WB
 		mov	pc, lr
 
+		.arch armv7-a
 __armv7_mmu_cache_flush:
 		mrc	p15, 0, r10, c0, c1, 5	@ read ID_MMFR1
 		tst	r10, #0xf << 16		@ hierarchical cache (ARMv7)
@@ -1123,6 +1131,7 @@ iflush:
 		mcr	p15, 0, r10, c7, c5, 4	@ ISB
 		mov	pc, lr
 
+		.arch armv5
 __armv5tej_mmu_cache_flush:
 1:		mrc	p15, 0, r15, c7, c14, 3	@ test,clean,invalidate D cache
 		bne	1b
@@ -1130,6 +1139,7 @@ __armv5tej_mmu_cache_flush:
 		mcr	p15, 0, r0, c7, c10, 4	@ drain WB
 		mov	pc, lr
 
+		.arch armv4
 __armv4_mmu_cache_flush:
 		mov	r2, #64*1024		@ default: 32K dcache size (*2)
 		mov	r11, #32		@ default: 32 byte line size
@@ -1168,6 +1178,8 @@ __armv3_mpu_cache_flush:
 		mcr	p15, 0, r1, c7, c0, 0	@ invalidate whole cache v3
 		mov	pc, lr
 
+		.arch armv4
+
 /*
  * Various debugging routines for printing hex characters and
  * memory, which again must be relocatable.
-- 
1.7.10.4

[PATCH 02/15] ARM: mvebu: build coherency_ll.S for arch=armv7-a

[Arnd Bergmann]

In a multiplatform kernel, one can enable mach-mvebu
together with one or more ARMv6 platforms, which leads
to all files being built for v6. The coherency_ll.S
uses the "dsb" instruction that is only available for
v7, causing a build error in this case. Since the
file is only used on v7 based machines, it is safe
to build it using an ".arch armv7-a" statement.

Without this patch, building allyesconfig results in:

arch/arm/mach-mvebu/coherency_ll.S: Assembler messages:
arch/arm/mach-mvebu/coherency_ll.S:45: Error: selected processor does not support ARM mode `dsb'

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>
---
 arch/arm/mach-mvebu/coherency_ll.S |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-mvebu/coherency_ll.S b/arch/arm/mach-mvebu/coherency_ll.S
index 53e8391..7648bda 100644
--- a/arch/arm/mach-mvebu/coherency_ll.S
+++ b/arch/arm/mach-mvebu/coherency_ll.S
@@ -25,6 +25,7 @@
  * r0: Coherency fabric base register address
  * r1: HW CPU id
  */
+	.arch armv7-a
 ENTRY(ll_set_cpu_coherent)
 	/* Create bit by cpu index */
 	mov	r3, #(1 << 24)
-- 
1.7.10.4

[PATCH 02/15] ARM: mvebu: build coherency_ll.S for arch=armv7-a

[Arnd Bergmann]

In a multiplatform kernel, one can enable mach-mvebu
together with one or more ARMv6 platforms, which leads
to all files being built for v6. The coherency_ll.S
uses the "dsb" instruction that is only available for
v7, causing a build error in this case. Since the
file is only used on v7 based machines, it is safe
to build it using an ".arch armv7-a" statement.

Without this patch, building allyesconfig results in:

arch/arm/mach-mvebu/coherency_ll.S: Assembler messages:
arch/arm/mach-mvebu/coherency_ll.S:45: Error: selected processor does not support ARM mode `dsb'

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>
---
 arch/arm/mach-mvebu/coherency_ll.S |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-mvebu/coherency_ll.S b/arch/arm/mach-mvebu/coherency_ll.S
index 53e8391..7648bda 100644
--- a/arch/arm/mach-mvebu/coherency_ll.S
+++ b/arch/arm/mach-mvebu/coherency_ll.S
@@ -25,6 +25,7 @@
  * r0: Coherency fabric base register address
  * r1: HW CPU id
  */
+	.arch armv7-a
 ENTRY(ll_set_cpu_coherent)
 	/* Create bit by cpu index */
 	mov	r3, #(1 << 24)
-- 
1.7.10.4

[PATCH 03/15] ARM: samsung: fix assembly syntax for new gas

[Arnd Bergmann]

Recent assembler versions complain about extraneous
whitespace inside [] brackets. This fixes all of
these instances for the samsung platforms. We should
backport this to all kernels that might need to
be built with new binutils.

arch/arm/kernel/entry-armv.S: Assembler messages:
arch/arm/kernel/entry-armv.S:214: Error: ARM register expected -- `ldr r2,[ r6,#(0x10)]'
arch/arm/kernel/entry-armv.S:214: Error: ARM register expected -- `ldr r0,[ r6,#(0x14)]'
arch/arm/kernel/entry-armv.S:430: Error: ARM register expected -- `ldr r2,[ r6,#(0x10)]'
arch/arm/kernel/entry-armv.S:430: Error: ARM register expected -- `ldr r0,[ r6,#(0x14)]'
arch/arm/mach-s3c24xx/sleep-s3c2410.S: Assembler messages:
arch/arm/mach-s3c24xx/sleep-s3c2410.S:48: Error: ARM register expected -- `ldr r7,[ r4 ]'
arch/arm/mach-s3c24xx/sleep-s3c2410.S:49: Error: ARM register expected -- `ldr r8,[ r5 ]'
arch/arm/mach-s3c24xx/sleep-s3c2410.S:50: Error: ARM register expected -- `ldr r9,[ r6 ]'
arch/arm/mach-s3c24xx/sleep-s3c2410.S:64: Error: ARM register expected -- `streq r7,[ r4 ]'
arch/arm/mach-s3c24xx/sleep-s3c2410.S:65: Error: ARM register expected -- `streq r8,[ r5 ]'
arch/arm/mach-s3c24xx/sleep-s3c2410.S:66: Error: ARM register expected -- `streq r9,[ r6 ]'
arch/arm/kernel/debug.S: Assembler messages:
arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r2,#((0x0B0)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))-((0)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))]'
arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]'
arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r2,#((0x0B0)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))-((0)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))]'
arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]'
arch/arm/mach-s3c24xx/pm-h1940.S: Assembler messages:
arch/arm/mach-s3c24xx/pm-h1940.S:33: Error: ARM register expected -- `ldr pc,[ r0,#((0x0B8)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))-(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000)))]'
arch/arm/mach-s3c24xx/sleep-s3c2412.S: Assembler messages:
arch/arm/mach-s3c24xx/sleep-s3c2412.S:60: Error: ARM register expected -- `ldrne r9,[ r1 ]'
arch/arm/mach-s3c24xx/sleep-s3c2412.S:61: Error: ARM register expected -- `strne r9,[ r1 ]'
arch/arm/mach-s3c24xx/sleep-s3c2412.S:62: Error: ARM register expected -- `ldrne r9,[ r2 ]'
arch/arm/mach-s3c24xx/sleep-s3c2412.S:63: Error: ARM register expected -- `strne r9,[ r2 ]'
arch/arm/mach-s3c24xx/sleep-s3c2412.S:64: Error: ARM register expected -- `ldrne r9,[ r3 ]'
arch/arm/mach-s3c24xx/sleep-s3c2412.S:65: Error: ARM register expected -- `strne r9,[ r3 ]'
arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x08)]'
arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]'
arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x10)]'
arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x08)]'
arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]'
arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x10)]'

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: stable@vger.kernel.org
---
 arch/arm/mach-s3c24xx/include/mach/debug-macro.S |   12 ++++++------
 arch/arm/mach-s3c24xx/include/mach/entry-macro.S |    4 ++--
 arch/arm/mach-s3c24xx/pm-h1940.S                 |    2 +-
 arch/arm/mach-s3c24xx/sleep-s3c2410.S            |   12 ++++++------
 arch/arm/mach-s3c24xx/sleep-s3c2412.S            |   12 ++++++------
 arch/arm/plat-samsung/include/plat/debug-macro.S |   18 +++++++++---------
 6 files changed, 30 insertions(+), 30 deletions(-)

diff --git a/arch/arm/mach-s3c24xx/include/mach/debug-macro.S b/arch/arm/mach-s3c24xx/include/mach/debug-macro.S
index 4135de8..13ed33c 100644
--- a/arch/arm/mach-s3c24xx/include/mach/debug-macro.S
+++ b/arch/arm/mach-s3c24xx/include/mach/debug-macro.S
@@ -40,17 +40,17 @@
 		addeq	\rd, \rx, #(S3C24XX_PA_GPIO - S3C24XX_PA_UART)
 		addne	\rd, \rx, #(S3C24XX_VA_GPIO - S3C24XX_VA_UART)
 		bic	\rd, \rd, #0xff000
-		ldr	\rd, [ \rd, # S3C2410_GSTATUS1 - S3C2410_GPIOREG(0) ]
+		ldr	\rd, [\rd, # S3C2410_GSTATUS1 - S3C2410_GPIOREG(0)]
 		and	\rd, \rd, #0x00ff0000
 		teq	\rd, #0x00440000		@ is it 2440?
 1004:
-		ldr	\rd, [ \rx, # S3C2410_UFSTAT ]
+		ldr	\rd, [\rx, # S3C2410_UFSTAT]
 		moveq	\rd, \rd, lsr #SHIFT_2440TXF
 		tst	\rd, #S3C2410_UFSTAT_TXFULL
 	.endm
 
 	.macro  fifo_full_s3c2410 rd, rx
-		ldr	\rd, [ \rx, # S3C2410_UFSTAT ]
+		ldr	\rd, [\rx, # S3C2410_UFSTAT]
 		tst	\rd, #S3C2410_UFSTAT_TXFULL
 	.endm
 
@@ -68,18 +68,18 @@
 		addeq	\rd, \rx, #(S3C24XX_PA_GPIO - S3C24XX_PA_UART)
 		addne	\rd, \rx, #(S3C24XX_VA_GPIO - S3C24XX_VA_UART)
 		bic	\rd, \rd, #0xff000
-		ldr	\rd, [ \rd, # S3C2410_GSTATUS1 - S3C2410_GPIOREG(0) ]
+		ldr	\rd, [\rd, # S3C2410_GSTATUS1 - S3C2410_GPIOREG(0)]
 		and	\rd, \rd, #0x00ff0000
 		teq	\rd, #0x00440000		@ is it 2440?
 
 10000:
-		ldr	\rd, [ \rx, # S3C2410_UFSTAT ]
+		ldr	\rd, [\rx, # S3C2410_UFSTAT]
 		andne	\rd, \rd, #S3C2410_UFSTAT_TXMASK
 		andeq	\rd, \rd, #S3C2440_UFSTAT_TXMASK
 	.endm
 
 	.macro fifo_level_s3c2410 rd, rx
-		ldr	\rd, [ \rx, # S3C2410_UFSTAT ]
+		ldr	\rd, [\rx, # S3C2410_UFSTAT]
 		and	\rd, \rd, #S3C2410_UFSTAT_TXMASK
 	.endm
 
diff --git a/arch/arm/mach-s3c24xx/include/mach/entry-macro.S b/arch/arm/mach-s3c24xx/include/mach/entry-macro.S
index 7615a14..6a21bee 100644
--- a/arch/arm/mach-s3c24xx/include/mach/entry-macro.S
+++ b/arch/arm/mach-s3c24xx/include/mach/entry-macro.S
@@ -31,10 +31,10 @@
 
 		@@ try the interrupt offset register, since it is there
 
-		ldr	\irqstat, [ \base, #INTPND ]
+		ldr	\irqstat, [\base, #INTPND ]
 		teq	\irqstat, #0
 		beq	1002f
-		ldr	\irqnr, [ \base, #INTOFFSET ]
+		ldr	\irqnr, [\base, #INTOFFSET ]
 		mov	\tmp, #1
 		tst	\irqstat, \tmp, lsl \irqnr
 		bne	1001f
diff --git a/arch/arm/mach-s3c24xx/pm-h1940.S b/arch/arm/mach-s3c24xx/pm-h1940.S
index c93bf2d..6183a68 100644
--- a/arch/arm/mach-s3c24xx/pm-h1940.S
+++ b/arch/arm/mach-s3c24xx/pm-h1940.S
@@ -30,4 +30,4 @@
 
 h1940_pm_return:
 	mov	r0, #S3C2410_PA_GPIO
-	ldr	pc, [ r0, #S3C2410_GSTATUS3 - S3C24XX_VA_GPIO ]
+	ldr	pc, [r0, #S3C2410_GSTATUS3 - S3C24XX_VA_GPIO]
diff --git a/arch/arm/mach-s3c24xx/sleep-s3c2410.S b/arch/arm/mach-s3c24xx/sleep-s3c2410.S
index dd5b638..65200ae 100644
--- a/arch/arm/mach-s3c24xx/sleep-s3c2410.S
+++ b/arch/arm/mach-s3c24xx/sleep-s3c2410.S
@@ -45,9 +45,9 @@ ENTRY(s3c2410_cpu_suspend)
 	ldr	r4, =S3C2410_REFRESH
 	ldr	r5, =S3C24XX_MISCCR
 	ldr	r6, =S3C2410_CLKCON
-	ldr	r7, [ r4 ]		@ get REFRESH (and ensure in TLB)
-	ldr	r8, [ r5 ]		@ get MISCCR (and ensure in TLB)
-	ldr	r9, [ r6 ]		@ get CLKCON (and ensure in TLB)
+	ldr	r7, [r4]		@ get REFRESH (and ensure in TLB)
+	ldr	r8, [r5]		@ get MISCCR (and ensure in TLB)
+	ldr	r9, [r6]		@ get CLKCON (and ensure in TLB)
 
 	orr	r7, r7, #S3C2410_REFRESH_SELF	@ SDRAM sleep command
 	orr	r8, r8, #S3C2410_MISCCR_SDSLEEP @ SDRAM power-down signals
@@ -61,8 +61,8 @@ ENTRY(s3c2410_cpu_suspend)
 	@@ align next bit of code to cache line
 	.align	5
 s3c2410_do_sleep:
-	streq	r7, [ r4 ]			@ SDRAM sleep command
-	streq	r8, [ r5 ]			@ SDRAM power-down config
-	streq	r9, [ r6 ]			@ CPU sleep
+	streq	r7, [r4]			@ SDRAM sleep command
+	streq	r8, [r5]			@ SDRAM power-down config
+	streq	r9, [r6]			@ CPU sleep
 1:	beq	1b
 	mov	pc, r14
diff --git a/arch/arm/mach-s3c24xx/sleep-s3c2412.S b/arch/arm/mach-s3c24xx/sleep-s3c2412.S
index c82418e..5adaceb 100644
--- a/arch/arm/mach-s3c24xx/sleep-s3c2412.S
+++ b/arch/arm/mach-s3c24xx/sleep-s3c2412.S
@@ -57,12 +57,12 @@ s3c2412_sleep_enter1:
 	 * retry, as simply returning causes the system to lock.
 	*/
 
-	ldrne	r9, [ r1 ]
-	strne	r9, [ r1 ]
-	ldrne	r9, [ r2 ]
-	strne	r9, [ r2 ]
-	ldrne	r9, [ r3 ]
-	strne	r9, [ r3 ]
+	ldrne	r9, [r1]
+	strne	r9, [r1]
+	ldrne	r9, [r2]
+	strne	r9, [r2]
+	ldrne	r9, [r3]
+	strne	r9, [r3]
 	bne	s3c2412_sleep_enter1
 
 	mov	pc, r14
diff --git a/arch/arm/plat-samsung/include/plat/debug-macro.S b/arch/arm/plat-samsung/include/plat/debug-macro.S
index 207e275..f3a9cff 100644
--- a/arch/arm/plat-samsung/include/plat/debug-macro.S
+++ b/arch/arm/plat-samsung/include/plat/debug-macro.S
@@ -14,12 +14,12 @@
 /* The S5PV210/S5PC110 implementations are as belows. */
 
 	.macro fifo_level_s5pv210 rd, rx
-		ldr	\rd, [ \rx, # S3C2410_UFSTAT ]
+		ldr	\rd, [\rx, # S3C2410_UFSTAT]
 		and	\rd, \rd, #S5PV210_UFSTAT_TXMASK
 	.endm
 
 	.macro  fifo_full_s5pv210 rd, rx
-		ldr	\rd, [ \rx, # S3C2410_UFSTAT ]
+		ldr	\rd, [\rx, # S3C2410_UFSTAT]
 		tst	\rd, #S5PV210_UFSTAT_TXFULL
 	.endm
 
@@ -27,7 +27,7 @@
  * most widely re-used */
 
 	.macro fifo_level_s3c2440 rd, rx
-		ldr	\rd, [ \rx, # S3C2410_UFSTAT ]
+		ldr	\rd, [\rx, # S3C2410_UFSTAT]
 		and	\rd, \rd, #S3C2440_UFSTAT_TXMASK
 	.endm
 
@@ -36,7 +36,7 @@
 #endif
 
 	.macro  fifo_full_s3c2440 rd, rx
-		ldr	\rd, [ \rx, # S3C2410_UFSTAT ]
+		ldr	\rd, [\rx, # S3C2410_UFSTAT]
 		tst	\rd, #S3C2440_UFSTAT_TXFULL
 	.endm
 
@@ -45,11 +45,11 @@
 #endif
 
 	.macro	senduart,rd,rx
-		strb 	\rd, [\rx, # S3C2410_UTXH ]
+		strb 	\rd, [\rx, # S3C2410_UTXH]
 	.endm
 
 	.macro	busyuart, rd, rx
-		ldr	\rd, [ \rx, # S3C2410_UFCON ]
+		ldr	\rd, [\rx, # S3C2410_UFCON]
 		tst	\rd, #S3C2410_UFCON_FIFOMODE	@ fifo enabled?
 		beq	1001f				@
 		@ FIFO enabled...
@@ -60,7 +60,7 @@
 
 1001:
 		@ busy waiting for non fifo
-		ldr	\rd, [ \rx, # S3C2410_UTRSTAT ]
+		ldr	\rd, [\rx, # S3C2410_UTRSTAT]
 		tst	\rd, #S3C2410_UTRSTAT_TXFE
 		beq	1001b
 
@@ -68,7 +68,7 @@
 	.endm
 
 	.macro	waituart,rd,rx
-		ldr	\rd, [ \rx, # S3C2410_UFCON ]
+		ldr	\rd, [\rx, # S3C2410_UFCON]
 		tst	\rd, #S3C2410_UFCON_FIFOMODE	@ fifo enabled?
 		beq	1001f				@
 		@ FIFO enabled...
@@ -79,7 +79,7 @@
 		b	1002f
 1001:
 		@ idle waiting for non fifo
-		ldr	\rd, [ \rx, # S3C2410_UTRSTAT ]
+		ldr	\rd, [\rx, # S3C2410_UTRSTAT]
 		tst	\rd, #S3C2410_UTRSTAT_TXFE
 		beq	1001b
 
-- 
1.7.10.4

[PATCH 03/15] ARM: samsung: fix assembly syntax for new gas

[Arnd Bergmann]

Recent assembler versions complain about extraneous
whitespace inside [] brackets. This fixes all of
these instances for the samsung platforms. We should
backport this to all kernels that might need to
be built with new binutils.

arch/arm/kernel/entry-armv.S: Assembler messages:
arch/arm/kernel/entry-armv.S:214: Error: ARM register expected -- `ldr r2,[ r6,#(0x10)]'
arch/arm/kernel/entry-armv.S:214: Error: ARM register expected -- `ldr r0,[ r6,#(0x14)]'
arch/arm/kernel/entry-armv.S:430: Error: ARM register expected -- `ldr r2,[ r6,#(0x10)]'
arch/arm/kernel/entry-armv.S:430: Error: ARM register expected -- `ldr r0,[ r6,#(0x14)]'
arch/arm/mach-s3c24xx/sleep-s3c2410.S: Assembler messages:
arch/arm/mach-s3c24xx/sleep-s3c2410.S:48: Error: ARM register expected -- `ldr r7,[ r4 ]'
arch/arm/mach-s3c24xx/sleep-s3c2410.S:49: Error: ARM register expected -- `ldr r8,[ r5 ]'
arch/arm/mach-s3c24xx/sleep-s3c2410.S:50: Error: ARM register expected -- `ldr r9,[ r6 ]'
arch/arm/mach-s3c24xx/sleep-s3c2410.S:64: Error: ARM register expected -- `streq r7,[ r4 ]'
arch/arm/mach-s3c24xx/sleep-s3c2410.S:65: Error: ARM register expected -- `streq r8,[ r5 ]'
arch/arm/mach-s3c24xx/sleep-s3c2410.S:66: Error: ARM register expected -- `streq r9,[ r6 ]'
arch/arm/kernel/debug.S: Assembler messages:
arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r2,#((0x0B0)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))-((0)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))]'
arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]'
arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r2,#((0x0B0)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))-((0)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))]'
arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]'
arch/arm/mach-s3c24xx/pm-h1940.S: Assembler messages:
arch/arm/mach-s3c24xx/pm-h1940.S:33: Error: ARM register expected -- `ldr pc,[ r0,#((0x0B8)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))-(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000)))]'
arch/arm/mach-s3c24xx/sleep-s3c2412.S: Assembler messages:
arch/arm/mach-s3c24xx/sleep-s3c2412.S:60: Error: ARM register expected -- `ldrne r9,[ r1 ]'
arch/arm/mach-s3c24xx/sleep-s3c2412.S:61: Error: ARM register expected -- `strne r9,[ r1 ]'
arch/arm/mach-s3c24xx/sleep-s3c2412.S:62: Error: ARM register expected -- `ldrne r9,[ r2 ]'
arch/arm/mach-s3c24xx/sleep-s3c2412.S:63: Error: ARM register expected -- `strne r9,[ r2 ]'
arch/arm/mach-s3c24xx/sleep-s3c2412.S:64: Error: ARM register expected -- `ldrne r9,[ r3 ]'
arch/arm/mach-s3c24xx/sleep-s3c2412.S:65: Error: ARM register expected -- `strne r9,[ r3 ]'
arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x08)]'
arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]'
arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x10)]'
arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x08)]'
arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]'
arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x10)]'

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: stable at vger.kernel.org
---
 arch/arm/mach-s3c24xx/include/mach/debug-macro.S |   12 ++++++------
 arch/arm/mach-s3c24xx/include/mach/entry-macro.S |    4 ++--
 arch/arm/mach-s3c24xx/pm-h1940.S                 |    2 +-
 arch/arm/mach-s3c24xx/sleep-s3c2410.S            |   12 ++++++------
 arch/arm/mach-s3c24xx/sleep-s3c2412.S            |   12 ++++++------
 arch/arm/plat-samsung/include/plat/debug-macro.S |   18 +++++++++---------
 6 files changed, 30 insertions(+), 30 deletions(-)

diff --git a/arch/arm/mach-s3c24xx/include/mach/debug-macro.S b/arch/arm/mach-s3c24xx/include/mach/debug-macro.S
index 4135de8..13ed33c 100644
--- a/arch/arm/mach-s3c24xx/include/mach/debug-macro.S
+++ b/arch/arm/mach-s3c24xx/include/mach/debug-macro.S
@@ -40,17 +40,17 @@
 		addeq	\rd, \rx, #(S3C24XX_PA_GPIO - S3C24XX_PA_UART)
 		addne	\rd, \rx, #(S3C24XX_VA_GPIO - S3C24XX_VA_UART)
 		bic	\rd, \rd, #0xff000
-		ldr	\rd, [ \rd, # S3C2410_GSTATUS1 - S3C2410_GPIOREG(0) ]
+		ldr	\rd, [\rd, # S3C2410_GSTATUS1 - S3C2410_GPIOREG(0)]
 		and	\rd, \rd, #0x00ff0000
 		teq	\rd, #0x00440000		@ is it 2440?
 1004:
-		ldr	\rd, [ \rx, # S3C2410_UFSTAT ]
+		ldr	\rd, [\rx, # S3C2410_UFSTAT]
 		moveq	\rd, \rd, lsr #SHIFT_2440TXF
 		tst	\rd, #S3C2410_UFSTAT_TXFULL
 	.endm
 
 	.macro  fifo_full_s3c2410 rd, rx
-		ldr	\rd, [ \rx, # S3C2410_UFSTAT ]
+		ldr	\rd, [\rx, # S3C2410_UFSTAT]
 		tst	\rd, #S3C2410_UFSTAT_TXFULL
 	.endm
 
@@ -68,18 +68,18 @@
 		addeq	\rd, \rx, #(S3C24XX_PA_GPIO - S3C24XX_PA_UART)
 		addne	\rd, \rx, #(S3C24XX_VA_GPIO - S3C24XX_VA_UART)
 		bic	\rd, \rd, #0xff000
-		ldr	\rd, [ \rd, # S3C2410_GSTATUS1 - S3C2410_GPIOREG(0) ]
+		ldr	\rd, [\rd, # S3C2410_GSTATUS1 - S3C2410_GPIOREG(0)]
 		and	\rd, \rd, #0x00ff0000
 		teq	\rd, #0x00440000		@ is it 2440?
 
 10000:
-		ldr	\rd, [ \rx, # S3C2410_UFSTAT ]
+		ldr	\rd, [\rx, # S3C2410_UFSTAT]
 		andne	\rd, \rd, #S3C2410_UFSTAT_TXMASK
 		andeq	\rd, \rd, #S3C2440_UFSTAT_TXMASK
 	.endm
 
 	.macro fifo_level_s3c2410 rd, rx
-		ldr	\rd, [ \rx, # S3C2410_UFSTAT ]
+		ldr	\rd, [\rx, # S3C2410_UFSTAT]
 		and	\rd, \rd, #S3C2410_UFSTAT_TXMASK
 	.endm
 
diff --git a/arch/arm/mach-s3c24xx/include/mach/entry-macro.S b/arch/arm/mach-s3c24xx/include/mach/entry-macro.S
index 7615a14..6a21bee 100644
--- a/arch/arm/mach-s3c24xx/include/mach/entry-macro.S
+++ b/arch/arm/mach-s3c24xx/include/mach/entry-macro.S
@@ -31,10 +31,10 @@
 
 		@@ try the interrupt offset register, since it is there
 
-		ldr	\irqstat, [ \base, #INTPND ]
+		ldr	\irqstat, [\base, #INTPND ]
 		teq	\irqstat, #0
 		beq	1002f
-		ldr	\irqnr, [ \base, #INTOFFSET ]
+		ldr	\irqnr, [\base, #INTOFFSET ]
 		mov	\tmp, #1
 		tst	\irqstat, \tmp, lsl \irqnr
 		bne	1001f
diff --git a/arch/arm/mach-s3c24xx/pm-h1940.S b/arch/arm/mach-s3c24xx/pm-h1940.S
index c93bf2d..6183a68 100644
--- a/arch/arm/mach-s3c24xx/pm-h1940.S
+++ b/arch/arm/mach-s3c24xx/pm-h1940.S
@@ -30,4 +30,4 @@
 
 h1940_pm_return:
 	mov	r0, #S3C2410_PA_GPIO
-	ldr	pc, [ r0, #S3C2410_GSTATUS3 - S3C24XX_VA_GPIO ]
+	ldr	pc, [r0, #S3C2410_GSTATUS3 - S3C24XX_VA_GPIO]
diff --git a/arch/arm/mach-s3c24xx/sleep-s3c2410.S b/arch/arm/mach-s3c24xx/sleep-s3c2410.S
index dd5b638..65200ae 100644
--- a/arch/arm/mach-s3c24xx/sleep-s3c2410.S
+++ b/arch/arm/mach-s3c24xx/sleep-s3c2410.S
@@ -45,9 +45,9 @@ ENTRY(s3c2410_cpu_suspend)
 	ldr	r4, =S3C2410_REFRESH
 	ldr	r5, =S3C24XX_MISCCR
 	ldr	r6, =S3C2410_CLKCON
-	ldr	r7, [ r4 ]		@ get REFRESH (and ensure in TLB)
-	ldr	r8, [ r5 ]		@ get MISCCR (and ensure in TLB)
-	ldr	r9, [ r6 ]		@ get CLKCON (and ensure in TLB)
+	ldr	r7, [r4]		@ get REFRESH (and ensure in TLB)
+	ldr	r8, [r5]		@ get MISCCR (and ensure in TLB)
+	ldr	r9, [r6]		@ get CLKCON (and ensure in TLB)
 
 	orr	r7, r7, #S3C2410_REFRESH_SELF	@ SDRAM sleep command
 	orr	r8, r8, #S3C2410_MISCCR_SDSLEEP @ SDRAM power-down signals
@@ -61,8 +61,8 @@ ENTRY(s3c2410_cpu_suspend)
 	@@ align next bit of code to cache line
 	.align	5
 s3c2410_do_sleep:
-	streq	r7, [ r4 ]			@ SDRAM sleep command
-	streq	r8, [ r5 ]			@ SDRAM power-down config
-	streq	r9, [ r6 ]			@ CPU sleep
+	streq	r7, [r4]			@ SDRAM sleep command
+	streq	r8, [r5]			@ SDRAM power-down config
+	streq	r9, [r6]			@ CPU sleep
 1:	beq	1b
 	mov	pc, r14
diff --git a/arch/arm/mach-s3c24xx/sleep-s3c2412.S b/arch/arm/mach-s3c24xx/sleep-s3c2412.S
index c82418e..5adaceb 100644
--- a/arch/arm/mach-s3c24xx/sleep-s3c2412.S
+++ b/arch/arm/mach-s3c24xx/sleep-s3c2412.S
@@ -57,12 +57,12 @@ s3c2412_sleep_enter1:
 	 * retry, as simply returning causes the system to lock.
 	*/
 
-	ldrne	r9, [ r1 ]
-	strne	r9, [ r1 ]
-	ldrne	r9, [ r2 ]
-	strne	r9, [ r2 ]
-	ldrne	r9, [ r3 ]
-	strne	r9, [ r3 ]
+	ldrne	r9, [r1]
+	strne	r9, [r1]
+	ldrne	r9, [r2]
+	strne	r9, [r2]
+	ldrne	r9, [r3]
+	strne	r9, [r3]
 	bne	s3c2412_sleep_enter1
 
 	mov	pc, r14
diff --git a/arch/arm/plat-samsung/include/plat/debug-macro.S b/arch/arm/plat-samsung/include/plat/debug-macro.S
index 207e275..f3a9cff 100644
--- a/arch/arm/plat-samsung/include/plat/debug-macro.S
+++ b/arch/arm/plat-samsung/include/plat/debug-macro.S
@@ -14,12 +14,12 @@
 /* The S5PV210/S5PC110 implementations are as belows. */
 
 	.macro fifo_level_s5pv210 rd, rx
-		ldr	\rd, [ \rx, # S3C2410_UFSTAT ]
+		ldr	\rd, [\rx, # S3C2410_UFSTAT]
 		and	\rd, \rd, #S5PV210_UFSTAT_TXMASK
 	.endm
 
 	.macro  fifo_full_s5pv210 rd, rx
-		ldr	\rd, [ \rx, # S3C2410_UFSTAT ]
+		ldr	\rd, [\rx, # S3C2410_UFSTAT]
 		tst	\rd, #S5PV210_UFSTAT_TXFULL
 	.endm
 
@@ -27,7 +27,7 @@
  * most widely re-used */
 
 	.macro fifo_level_s3c2440 rd, rx
-		ldr	\rd, [ \rx, # S3C2410_UFSTAT ]
+		ldr	\rd, [\rx, # S3C2410_UFSTAT]
 		and	\rd, \rd, #S3C2440_UFSTAT_TXMASK
 	.endm
 
@@ -36,7 +36,7 @@
 #endif
 
 	.macro  fifo_full_s3c2440 rd, rx
-		ldr	\rd, [ \rx, # S3C2410_UFSTAT ]
+		ldr	\rd, [\rx, # S3C2410_UFSTAT]
 		tst	\rd, #S3C2440_UFSTAT_TXFULL
 	.endm
 
@@ -45,11 +45,11 @@
 #endif
 
 	.macro	senduart,rd,rx
-		strb 	\rd, [\rx, # S3C2410_UTXH ]
+		strb 	\rd, [\rx, # S3C2410_UTXH]
 	.endm
 
 	.macro	busyuart, rd, rx
-		ldr	\rd, [ \rx, # S3C2410_UFCON ]
+		ldr	\rd, [\rx, # S3C2410_UFCON]
 		tst	\rd, #S3C2410_UFCON_FIFOMODE	@ fifo enabled?
 		beq	1001f				@
 		@ FIFO enabled...
@@ -60,7 +60,7 @@
 
 1001:
 		@ busy waiting for non fifo
-		ldr	\rd, [ \rx, # S3C2410_UTRSTAT ]
+		ldr	\rd, [\rx, # S3C2410_UTRSTAT]
 		tst	\rd, #S3C2410_UTRSTAT_TXFE
 		beq	1001b
 
@@ -68,7 +68,7 @@
 	.endm
 
 	.macro	waituart,rd,rx
-		ldr	\rd, [ \rx, # S3C2410_UFCON ]
+		ldr	\rd, [\rx, # S3C2410_UFCON]
 		tst	\rd, #S3C2410_UFCON_FIFOMODE	@ fifo enabled?
 		beq	1001f				@
 		@ FIFO enabled...
@@ -79,7 +79,7 @@
 		b	1002f
 1001:
 		@ idle waiting for non fifo
-		ldr	\rd, [ \rx, # S3C2410_UTRSTAT ]
+		ldr	\rd, [\rx, # S3C2410_UTRSTAT]
 		tst	\rd, #S3C2410_UTRSTAT_TXFE
 		beq	1001b
 
-- 
1.7.10.4

[PATCH 04/15] ARM: w90x900: fix legacy assembly syntax

[Arnd Bergmann]

New ARM binutils don't allow extraneous whitespace inside
of brackets, which causes this error on all mach-w90x900
defconfigs:

arch/arm/kernel/entry-armv.S: Assembler messages:
arch/arm/kernel/entry-armv.S:214: Error: ARM register expected -- `ldr r0,[ r6,#(0x10C)]'
arch/arm/kernel/entry-armv.S:214: Error: ARM register expected -- `ldr r0,[ r6,#(0x110)]'
arch/arm/kernel/entry-armv.S:430: Error: ARM register expected -- `ldr r0,[ r6,#(0x10C)]'
arch/arm/kernel/entry-armv.S:430: Error: ARM register expected -- `ldr r0,[ r6,#(0x110)]'

This removes the whitespace in order to build the kernel
again.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Wan ZongShun <mcuos.com@gmail.com>
---
 arch/arm/mach-w90x900/include/mach/entry-macro.S |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-w90x900/include/mach/entry-macro.S b/arch/arm/mach-w90x900/include/mach/entry-macro.S
index e286dac..0ff612a 100644
--- a/arch/arm/mach-w90x900/include/mach/entry-macro.S
+++ b/arch/arm/mach-w90x900/include/mach/entry-macro.S
@@ -19,8 +19,8 @@
 
 		mov	\base, #AIC_BA
 
-		ldr	\irqnr, [ \base, #AIC_IPER]
-		ldr	\irqnr, [ \base, #AIC_ISNR]
+		ldr	\irqnr, [\base, #AIC_IPER]
+		ldr	\irqnr, [\base, #AIC_ISNR]
 		cmp	\irqnr, #0
 
 	.endm
-- 
1.7.10.4

[PATCH 04/15] ARM: w90x900: fix legacy assembly syntax

[Arnd Bergmann]

New ARM binutils don't allow extraneous whitespace inside
of brackets, which causes this error on all mach-w90x900
defconfigs:

arch/arm/kernel/entry-armv.S: Assembler messages:
arch/arm/kernel/entry-armv.S:214: Error: ARM register expected -- `ldr r0,[ r6,#(0x10C)]'
arch/arm/kernel/entry-armv.S:214: Error: ARM register expected -- `ldr r0,[ r6,#(0x110)]'
arch/arm/kernel/entry-armv.S:430: Error: ARM register expected -- `ldr r0,[ r6,#(0x10C)]'
arch/arm/kernel/entry-armv.S:430: Error: ARM register expected -- `ldr r0,[ r6,#(0x110)]'

This removes the whitespace in order to build the kernel
again.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Wan ZongShun <mcuos.com@gmail.com>
---
 arch/arm/mach-w90x900/include/mach/entry-macro.S |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-w90x900/include/mach/entry-macro.S b/arch/arm/mach-w90x900/include/mach/entry-macro.S
index e286dac..0ff612a 100644
--- a/arch/arm/mach-w90x900/include/mach/entry-macro.S
+++ b/arch/arm/mach-w90x900/include/mach/entry-macro.S
@@ -19,8 +19,8 @@
 
 		mov	\base, #AIC_BA
 
-		ldr	\irqnr, [ \base, #AIC_IPER]
-		ldr	\irqnr, [ \base, #AIC_ISNR]
+		ldr	\irqnr, [\base, #AIC_IPER]
+		ldr	\irqnr, [\base, #AIC_ISNR]
 		cmp	\irqnr, #0
 
 	.endm
-- 
1.7.10.4

[PATCH 05/15] ASoC: fsl: fiq and dma cannot both be modules

[Arnd Bergmann]

The dma and fiq portions of the imx-pcm driver both
have a module_init() call, of which there can be only
one in any given module. This changes Kconfig to enforce
either the driver to be built-in in the kernel, or
to have only one of the two when building imx-pcm as
a module.

Without this patch, we cannot build the ARM 'allmodconfig', or
we get this error:

sound/soc/fsl/imx-pcm-dma.o: In function `init_module':
sound/soc/fsl/imx-pcm-dma.c:177: multiple definition of `init_module'
sound/soc/fsl/imx-pcm-fiq.o:sound/soc/fsl/imx-pcm-fiq.c:334: first defined here
sound/soc/fsl/imx-pcm-dma.o: In function `cleanup_module':
sound/soc/fsl/imx-pcm-dma.c:177: multiple definition of `cleanup_module'
sound/soc/fsl/imx-pcm-fiq.o:sound/soc/fsl/imx-pcm-fiq.c:334: first defined here

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Liam Girdwood <lrg@ti.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: alsa-devel@alsa-project.org
---
 sound/soc/fsl/Kconfig |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 3b98159..282b08e 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -127,6 +127,7 @@ config SND_SOC_IMX_AUDMUX
 config SND_MXC_SOC_WM1133_EV1
 	tristate "Audio on the i.MX31ADS with WM1133-EV1 fitted"
 	depends on MACH_MX31ADS_WM1133_EV1
+	depends on !SND_SOC_IMX_PCM_DMA || SND_IMX_SOC=y
 	select SND_SOC_WM8350
 	select SND_SOC_IMX_PCM_FIQ
 	select SND_SOC_IMX_AUDMUX
@@ -149,6 +150,7 @@ config SND_SOC_MX27VIS_AIC32X4
 config SND_SOC_PHYCORE_AC97
 	tristate "SoC Audio support for Phytec phyCORE (and phyCARD) boards"
 	depends on MACH_PCM043 || MACH_PCA100
+	depends on !SND_SOC_IMX_PCM_DMA || SND_IMX_SOC=y
 	select SND_SOC_AC97_BUS
 	select SND_SOC_WM9712
 	select SND_SOC_IMX_PCM_FIQ
@@ -165,6 +167,7 @@ config SND_SOC_EUKREA_TLV320
 		|| MACH_EUKREA_MBIMXSD35_BASEBOARD \
 		|| MACH_EUKREA_MBIMXSD51_BASEBOARD
 	depends on I2C
+	depends on !SND_SOC_IMX_PCM_DMA || SND_IMX_SOC=y
 	select SND_SOC_TLV320AIC23
 	select SND_SOC_IMX_PCM_FIQ
 	select SND_SOC_IMX_AUDMUX
-- 
1.7.10.4

[PATCH 05/15] ASoC: fsl: fiq and dma cannot both be modules

[Arnd Bergmann]

The dma and fiq portions of the imx-pcm driver both
have a module_init() call, of which there can be only
one in any given module. This changes Kconfig to enforce
either the driver to be built-in in the kernel, or
to have only one of the two when building imx-pcm as
a module.

Without this patch, we cannot build the ARM 'allmodconfig', or
we get this error:

sound/soc/fsl/imx-pcm-dma.o: In function `init_module':
sound/soc/fsl/imx-pcm-dma.c:177: multiple definition of `init_module'
sound/soc/fsl/imx-pcm-fiq.o:sound/soc/fsl/imx-pcm-fiq.c:334: first defined here
sound/soc/fsl/imx-pcm-dma.o: In function `cleanup_module':
sound/soc/fsl/imx-pcm-dma.c:177: multiple definition of `cleanup_module'
sound/soc/fsl/imx-pcm-fiq.o:sound/soc/fsl/imx-pcm-fiq.c:334: first defined here

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Liam Girdwood <lrg@ti.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: alsa-devel@alsa-project.org
---
 sound/soc/fsl/Kconfig |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 3b98159..282b08e 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -127,6 +127,7 @@ config SND_SOC_IMX_AUDMUX
 config SND_MXC_SOC_WM1133_EV1
 	tristate "Audio on the i.MX31ADS with WM1133-EV1 fitted"
 	depends on MACH_MX31ADS_WM1133_EV1
+	depends on !SND_SOC_IMX_PCM_DMA || SND_IMX_SOC=y
 	select SND_SOC_WM8350
 	select SND_SOC_IMX_PCM_FIQ
 	select SND_SOC_IMX_AUDMUX
@@ -149,6 +150,7 @@ config SND_SOC_MX27VIS_AIC32X4
 config SND_SOC_PHYCORE_AC97
 	tristate "SoC Audio support for Phytec phyCORE (and phyCARD) boards"
 	depends on MACH_PCM043 || MACH_PCA100
+	depends on !SND_SOC_IMX_PCM_DMA || SND_IMX_SOC=y
 	select SND_SOC_AC97_BUS
 	select SND_SOC_WM9712
 	select SND_SOC_IMX_PCM_FIQ
@@ -165,6 +167,7 @@ config SND_SOC_EUKREA_TLV320
 		|| MACH_EUKREA_MBIMXSD35_BASEBOARD \
 		|| MACH_EUKREA_MBIMXSD51_BASEBOARD
 	depends on I2C
+	depends on !SND_SOC_IMX_PCM_DMA || SND_IMX_SOC=y
 	select SND_SOC_TLV320AIC23
 	select SND_SOC_IMX_PCM_FIQ
 	select SND_SOC_IMX_AUDMUX
-- 
1.7.10.4

[PATCH 05/15] ASoC: fsl: fiq and dma cannot both be modules

[Arnd Bergmann]

The dma and fiq portions of the imx-pcm driver both
have a module_init() call, of which there can be only
one in any given module. This changes Kconfig to enforce
either the driver to be built-in in the kernel, or
to have only one of the two when building imx-pcm as
a module.

Without this patch, we cannot build the ARM 'allmodconfig', or
we get this error:

sound/soc/fsl/imx-pcm-dma.o: In function `init_module':
sound/soc/fsl/imx-pcm-dma.c:177: multiple definition of `init_module'
sound/soc/fsl/imx-pcm-fiq.o:sound/soc/fsl/imx-pcm-fiq.c:334: first defined here
sound/soc/fsl/imx-pcm-dma.o: In function `cleanup_module':
sound/soc/fsl/imx-pcm-dma.c:177: multiple definition of `cleanup_module'
sound/soc/fsl/imx-pcm-fiq.o:sound/soc/fsl/imx-pcm-fiq.c:334: first defined here

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Liam Girdwood <lrg@ti.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: alsa-devel at alsa-project.org
---
 sound/soc/fsl/Kconfig |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 3b98159..282b08e 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -127,6 +127,7 @@ config SND_SOC_IMX_AUDMUX
 config SND_MXC_SOC_WM1133_EV1
 	tristate "Audio on the i.MX31ADS with WM1133-EV1 fitted"
 	depends on MACH_MX31ADS_WM1133_EV1
+	depends on !SND_SOC_IMX_PCM_DMA || SND_IMX_SOC=y
 	select SND_SOC_WM8350
 	select SND_SOC_IMX_PCM_FIQ
 	select SND_SOC_IMX_AUDMUX
@@ -149,6 +150,7 @@ config SND_SOC_MX27VIS_AIC32X4
 config SND_SOC_PHYCORE_AC97
 	tristate "SoC Audio support for Phytec phyCORE (and phyCARD) boards"
 	depends on MACH_PCM043 || MACH_PCA100
+	depends on !SND_SOC_IMX_PCM_DMA || SND_IMX_SOC=y
 	select SND_SOC_AC97_BUS
 	select SND_SOC_WM9712
 	select SND_SOC_IMX_PCM_FIQ
@@ -165,6 +167,7 @@ config SND_SOC_EUKREA_TLV320
 		|| MACH_EUKREA_MBIMXSD35_BASEBOARD \
 		|| MACH_EUKREA_MBIMXSD51_BASEBOARD
 	depends on I2C
+	depends on !SND_SOC_IMX_PCM_DMA || SND_IMX_SOC=y
 	select SND_SOC_TLV320AIC23
 	select SND_SOC_IMX_PCM_FIQ
 	select SND_SOC_IMX_AUDMUX
-- 
1.7.10.4

[PATCH 06/15] clk: export __clk_get_name

[Arnd Bergmann]

The __clk_get_name is used by drivers that provide their
own clocks, which have traditionally all been built-in.
The new imx drm driver however provides clocks but can
be built as a module, so we need to export __clk_get_name.

While this is only a staging driver, it's likely that
there will be others like it in the future.

Without this patch, building ARM allmodconfig results in:

ERROR: "__clk_get_name" [drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.ko] undefined!

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Mike Turquette <mturquette@linaro.org>
---
 drivers/clk/clk.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 251e45d..13b793e 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -263,6 +263,7 @@ inline const char *__clk_get_name(struct clk *clk)
 {
 	return !clk ? NULL : clk->name;
 }
+EXPORT_SYMBOL_GPL(__clk_get_name);
 
 inline struct clk_hw *__clk_get_hw(struct clk *clk)
 {
-- 
1.7.10.4

[PATCH 06/15] clk: export __clk_get_name

[Arnd Bergmann]

The __clk_get_name is used by drivers that provide their
own clocks, which have traditionally all been built-in.
The new imx drm driver however provides clocks but can
be built as a module, so we need to export __clk_get_name.

While this is only a staging driver, it's likely that
there will be others like it in the future.

Without this patch, building ARM allmodconfig results in:

ERROR: "__clk_get_name" [drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.ko] undefined!

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Mike Turquette <mturquette@linaro.org>
---
 drivers/clk/clk.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 251e45d..13b793e 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -263,6 +263,7 @@ inline const char *__clk_get_name(struct clk *clk)
 {
 	return !clk ? NULL : clk->name;
 }
+EXPORT_SYMBOL_GPL(__clk_get_name);
 
 inline struct clk_hw *__clk_get_hw(struct clk *clk)
 {
-- 
1.7.10.4

[PATCH 07/15] drm/exynos: don't include plat/gpio-cfg.h

[Arnd Bergmann]

Patch  9eb3e9e6f3 "drm/exynos: add support for ARCH_MULTIPLATFORM"
allowed building the exynos hdmi driver on non-samsung platforms,
which unfortunately broke compilation in combination with 22c4f42897
"drm: exynos: hdmi: add support for exynos5 hdmi", which added
an inclusion of the samsung-specific plat/gpio-cfg.h header file.

Fortunately, that header file is not required any more here, so
we can simply revert the inclusion in order to build the ARM
allyesconfig again without getting this error:

drivers/gpu/drm/exynos/exynos_hdmi.c:37:27: fatal error: plat/gpio-cfg.h: No such file or directory

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Clark <rob@ti.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Rahul Sharma <rahul.sharma@samsung.com>
---
 drivers/gpu/drm/exynos/exynos_hdmi.c |    1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 41ff79d..b5f5119 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -34,7 +34,6 @@
 #include <linux/regulator/consumer.h>
 #include <linux/io.h>
 #include <linux/of_gpio.h>
-#include <plat/gpio-cfg.h>
 
 #include <drm/exynos_drm.h>
 
-- 
1.7.10.4

[PATCH 07/15] drm/exynos: don't include plat/gpio-cfg.h

[Arnd Bergmann]

Patch  9eb3e9e6f3 "drm/exynos: add support for ARCH_MULTIPLATFORM"
allowed building the exynos hdmi driver on non-samsung platforms,
which unfortunately broke compilation in combination with 22c4f42897
"drm: exynos: hdmi: add support for exynos5 hdmi", which added
an inclusion of the samsung-specific plat/gpio-cfg.h header file.

Fortunately, that header file is not required any more here, so
we can simply revert the inclusion in order to build the ARM
allyesconfig again without getting this error:

drivers/gpu/drm/exynos/exynos_hdmi.c:37:27: fatal error: plat/gpio-cfg.h: No such file or directory

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Clark <rob@ti.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Rahul Sharma <rahul.sharma@samsung.com>
---
 drivers/gpu/drm/exynos/exynos_hdmi.c |    1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 41ff79d..b5f5119 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -34,7 +34,6 @@
 #include <linux/regulator/consumer.h>
 #include <linux/io.h>
 #include <linux/of_gpio.h>
-#include <plat/gpio-cfg.h>
 
 #include <drm/exynos_drm.h>
 
-- 
1.7.10.4

[PATCH 08/15] drm/exynos: fimd and ipp are broken on multiplatform

[Arnd Bergmann]

While the exynos DRM support in principle can work on
multiplatform, the FIMD and IPP sections of it both
include the plat/map-base.h header file, which is
not available on multiplatform. Rather than disabling
the entire driver, we can just conditionally build
these two parts.

Without this patch, building allyesconfig results in:

drivers/gpu/drm/exynos/exynos_drm_fimc.c:19:27: fatal error: plat/map-base.h: No such file or directory
drivers/gpu/drm/exynos/exynos_drm_ipp.c:20:27: fatal error: plat/map-base.h: No such file or directory

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Joonyoung Shim <jy0922.shim@samsung.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
---
 drivers/gpu/drm/exynos/Kconfig |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 1d1f1e5..046bcda 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -24,7 +24,7 @@ config DRM_EXYNOS_DMABUF
 
 config DRM_EXYNOS_FIMD
 	bool "Exynos DRM FIMD"
-	depends on DRM_EXYNOS && !FB_S3C
+	depends on DRM_EXYNOS && !FB_S3C && !ARCH_MULTIPLATFORM
 	help
 	  Choose this option if you want to use Exynos FIMD for DRM.
 
@@ -48,7 +48,7 @@ config DRM_EXYNOS_G2D
 
 config DRM_EXYNOS_IPP
 	bool "Exynos DRM IPP"
-	depends on DRM_EXYNOS
+	depends on DRM_EXYNOS && !ARCH_MULTIPLATFORM
 	help
 	  Choose this option if you want to use IPP feature for DRM.
 
-- 
1.7.10.4

[PATCH 08/15] drm/exynos: fimd and ipp are broken on multiplatform

[Arnd Bergmann]

While the exynos DRM support in principle can work on
multiplatform, the FIMD and IPP sections of it both
include the plat/map-base.h header file, which is
not available on multiplatform. Rather than disabling
the entire driver, we can just conditionally build
these two parts.

Without this patch, building allyesconfig results in:

drivers/gpu/drm/exynos/exynos_drm_fimc.c:19:27: fatal error: plat/map-base.h: No such file or directory
drivers/gpu/drm/exynos/exynos_drm_ipp.c:20:27: fatal error: plat/map-base.h: No such file or directory

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Joonyoung Shim <jy0922.shim@samsung.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel at lists.freedesktop.org
---
 drivers/gpu/drm/exynos/Kconfig |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 1d1f1e5..046bcda 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -24,7 +24,7 @@ config DRM_EXYNOS_DMABUF
 
 config DRM_EXYNOS_FIMD
 	bool "Exynos DRM FIMD"
-	depends on DRM_EXYNOS && !FB_S3C
+	depends on DRM_EXYNOS && !FB_S3C && !ARCH_MULTIPLATFORM
 	help
 	  Choose this option if you want to use Exynos FIMD for DRM.
 
@@ -48,7 +48,7 @@ config DRM_EXYNOS_G2D
 
 config DRM_EXYNOS_IPP
 	bool "Exynos DRM IPP"
-	depends on DRM_EXYNOS
+	depends on DRM_EXYNOS && !ARCH_MULTIPLATFORM
 	help
 	  Choose this option if you want to use IPP feature for DRM.
 
-- 
1.7.10.4

[PATCH 08/15] drm/exynos: fimd and ipp are broken on multiplatform

[Arnd Bergmann]

While the exynos DRM support in principle can work on
multiplatform, the FIMD and IPP sections of it both
include the plat/map-base.h header file, which is
not available on multiplatform. Rather than disabling
the entire driver, we can just conditionally build
these two parts.

Without this patch, building allyesconfig results in:

drivers/gpu/drm/exynos/exynos_drm_fimc.c:19:27: fatal error: plat/map-base.h: No such file or directory
drivers/gpu/drm/exynos/exynos_drm_ipp.c:20:27: fatal error: plat/map-base.h: No such file or directory

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Joonyoung Shim <jy0922.shim@samsung.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
---
 drivers/gpu/drm/exynos/Kconfig |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 1d1f1e5..046bcda 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -24,7 +24,7 @@ config DRM_EXYNOS_DMABUF
 
 config DRM_EXYNOS_FIMD
 	bool "Exynos DRM FIMD"
-	depends on DRM_EXYNOS && !FB_S3C
+	depends on DRM_EXYNOS && !FB_S3C && !ARCH_MULTIPLATFORM
 	help
 	  Choose this option if you want to use Exynos FIMD for DRM.
 
@@ -48,7 +48,7 @@ config DRM_EXYNOS_G2D
 
 config DRM_EXYNOS_IPP
 	bool "Exynos DRM IPP"
-	depends on DRM_EXYNOS
+	depends on DRM_EXYNOS && !ARCH_MULTIPLATFORM
 	help
 	  Choose this option if you want to use IPP feature for DRM.
 
-- 
1.7.10.4

[PATCH 09/15] media: coda: don't build on multiplatform

[Arnd Bergmann]

The coda video codec driver depends on a mach-imx or mach-mxs specific
header file "mach/iram.h". This is not available when building for
multiplatform, so let us disable this driver for v3.8 when building
multiplatform, and hopefully find a proper fix for v3.9.

drivers/media/platform/coda.c:27:23: fatal error: mach/iram.h: No such file or directory

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Javier Martin <javier.martin@vista-silicon.com>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: linux-media@vger.kernel.org
---
 drivers/media/platform/Kconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 3dcfea6..049d2b2 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -142,7 +142,7 @@ if V4L_MEM2MEM_DRIVERS
 
 config VIDEO_CODA
 	tristate "Chips&Media Coda multi-standard codec IP"
-	depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_MXC
+	depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_MXC && !ARCH_MULTIPLATFORM
 	select VIDEOBUF2_DMA_CONTIG
 	select V4L2_MEM2MEM_DEV
 	select IRAM_ALLOC if SOC_IMX53
-- 
1.7.10.4

[PATCH 09/15] media: coda: don't build on multiplatform

[Arnd Bergmann]

The coda video codec driver depends on a mach-imx or mach-mxs specific
header file "mach/iram.h". This is not available when building for
multiplatform, so let us disable this driver for v3.8 when building
multiplatform, and hopefully find a proper fix for v3.9.

drivers/media/platform/coda.c:27:23: fatal error: mach/iram.h: No such file or directory

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Javier Martin <javier.martin@vista-silicon.com>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: linux-media at vger.kernel.org
---
 drivers/media/platform/Kconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 3dcfea6..049d2b2 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -142,7 +142,7 @@ if V4L_MEM2MEM_DRIVERS
 
 config VIDEO_CODA
 	tristate "Chips&Media Coda multi-standard codec IP"
-	depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_MXC
+	depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_MXC && !ARCH_MULTIPLATFORM
 	select VIDEOBUF2_DMA_CONTIG
 	select V4L2_MEM2MEM_DEV
 	select IRAM_ALLOC if SOC_IMX53
-- 
1.7.10.4

[PATCH 10/15] mfd/vexpress: export vexpress_config_func_{put,get}

[Arnd Bergmann]

The newly introduced vexpress mfd driver in linux-3.8-rc
provides access to configuration functions, but the
interfaces are not exported to modules, which breaks
when the vexpress regulator driver tries to use them.

Without this patch, building allmodconfig results in:

ERROR: "__vexpress_config_func_get" [drivers/regulator/vexpress.ko] undefined!
ERROR: "vexpress_config_func_put" [drivers/regulator/vexpress.ko] undefined!

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Samuel Ortiz <sameo@linux.intel.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
 drivers/mfd/vexpress-config.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/vexpress-config.c b/drivers/mfd/vexpress-config.c
index fae15d8..3cb34aa 100644
--- a/drivers/mfd/vexpress-config.c
+++ b/drivers/mfd/vexpress-config.c
@@ -142,6 +142,7 @@ struct vexpress_config_func *__vexpress_config_func_get(struct device *dev,
 
 	return func;
 }
+EXPORT_SYMBOL_GPL(__vexpress_config_func_get);
 
 void vexpress_config_func_put(struct vexpress_config_func *func)
 {
@@ -149,7 +150,7 @@ void vexpress_config_func_put(struct vexpress_config_func *func)
 	of_node_put(func->bridge->node);
 	kfree(func);
 }
-
+EXPORT_SYMBOL_GPL(vexpress_config_func_put);
 
 struct vexpress_config_trans {
 	struct vexpress_config_func *func;
-- 
1.7.10.4

[PATCH 10/15] mfd/vexpress: export vexpress_config_func_{put,get}

[Arnd Bergmann]

The newly introduced vexpress mfd driver in linux-3.8-rc
provides access to configuration functions, but the
interfaces are not exported to modules, which breaks
when the vexpress regulator driver tries to use them.

Without this patch, building allmodconfig results in:

ERROR: "__vexpress_config_func_get" [drivers/regulator/vexpress.ko] undefined!
ERROR: "vexpress_config_func_put" [drivers/regulator/vexpress.ko] undefined!

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Samuel Ortiz <sameo@linux.intel.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
 drivers/mfd/vexpress-config.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/vexpress-config.c b/drivers/mfd/vexpress-config.c
index fae15d8..3cb34aa 100644
--- a/drivers/mfd/vexpress-config.c
+++ b/drivers/mfd/vexpress-config.c
@@ -142,6 +142,7 @@ struct vexpress_config_func *__vexpress_config_func_get(struct device *dev,
 
 	return func;
 }
+EXPORT_SYMBOL_GPL(__vexpress_config_func_get);
 
 void vexpress_config_func_put(struct vexpress_config_func *func)
 {
@@ -149,7 +150,7 @@ void vexpress_config_func_put(struct vexpress_config_func *func)
 	of_node_put(func->bridge->node);
 	kfree(func);
 }
-
+EXPORT_SYMBOL_GPL(vexpress_config_func_put);
 
 struct vexpress_config_trans {
 	struct vexpress_config_func *func;
-- 
1.7.10.4

[PATCH 11/15] mtd: davinci_nand: fix OF support

[Arnd Bergmann]

The patch cdeadd "mtd: nand: davinci: add OF support for
davinci nand controller" ironically causes a build error
when CONFIG_OF is enabled because of a missing ';'
character:

drivers/mtd/nand/davinci_nand.c:527:1: error: expected ',' or ';' before 'extern'

This is the obvious fix.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Heiko Schocher <hs@denx.de>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: David Woodhouse <David.Woodhouse@intel.com>
---
 drivers/mtd/nand/davinci_nand.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index 3502606..feae55c 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -523,7 +523,7 @@ static struct nand_ecclayout hwecc4_2048 __initconst = {
 static const struct of_device_id davinci_nand_of_match[] = {
 	{.compatible = "ti,davinci-nand", },
 	{},
-}
+};
 MODULE_DEVICE_TABLE(of, davinci_nand_of_match);
 
 static struct davinci_nand_pdata
-- 
1.7.10.4

[PATCH 11/15] mtd: davinci_nand: fix OF support

[Arnd Bergmann]

The patch cdeadd "mtd: nand: davinci: add OF support for
davinci nand controller" ironically causes a build error
when CONFIG_OF is enabled because of a missing ';'
character:

drivers/mtd/nand/davinci_nand.c:527:1: error: expected ',' or ';' before 'extern'

This is the obvious fix.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Heiko Schocher <hs@denx.de>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: David Woodhouse <David.Woodhouse@intel.com>
---
 drivers/mtd/nand/davinci_nand.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index 3502606..feae55c 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -523,7 +523,7 @@ static struct nand_ecclayout hwecc4_2048 __initconst = {
 static const struct of_device_id davinci_nand_of_match[] = {
 	{.compatible = "ti,davinci-nand", },
 	{},
-}
+};
 MODULE_DEVICE_TABLE(of, davinci_nand_of_match);
 
 static struct davinci_nand_pdata
-- 
1.7.10.4

[PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers

[Arnd Bergmann]

Both the fsl_mxc gadget and the imx_udc gadget drivers fail to build
without the mach/hardware.h file that is not available when building
for multiplatform. Let's disable these drivers for v3.8 in combination
with CONFIG_ARCH_MULTIPLATFORM, and fix them properly in v3.9 unless
someone has an better solution.

Without this patch, building allyesconfig results in:

drivers/usb/gadget/fsl_mxc_udc.c:21:27: fatal error: mach/hardware.h: No such file or directory

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-usb@vger.kernel.org
---
 drivers/usb/gadget/Kconfig |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 14625fd..ca57a6d 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -173,6 +173,7 @@ config USB_BCM63XX_UDC
 config USB_FSL_USB2
 	tristate "Freescale Highspeed USB DR Peripheral Controller"
 	depends on FSL_SOC || ARCH_MXC
+	depends on !ARCH_MULTIPLATFORM
 	select USB_FSL_MPH_DR_OF if OF
 	help
 	   Some of Freescale PowerPC and i.MX processors have a High Speed
@@ -280,7 +281,7 @@ config USB_S3C_HSOTG
 
 config USB_IMX
 	tristate "Freescale i.MX1 USB Peripheral Controller"
-	depends on ARCH_MXC
+	depends on ARCH_MXC && !ARCH_MULTIPLATFORM
 	help
 	   Freescale's i.MX1 includes an integrated full speed
 	   USB 1.1 device controller.
-- 
1.7.10.4

[PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers

[Arnd Bergmann]

Both the fsl_mxc gadget and the imx_udc gadget drivers fail to build
without the mach/hardware.h file that is not available when building
for multiplatform. Let's disable these drivers for v3.8 in combination
with CONFIG_ARCH_MULTIPLATFORM, and fix them properly in v3.9 unless
someone has an better solution.

Without this patch, building allyesconfig results in:

drivers/usb/gadget/fsl_mxc_udc.c:21:27: fatal error: mach/hardware.h: No such file or directory

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-usb at vger.kernel.org
---
 drivers/usb/gadget/Kconfig |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 14625fd..ca57a6d 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -173,6 +173,7 @@ config USB_BCM63XX_UDC
 config USB_FSL_USB2
 	tristate "Freescale Highspeed USB DR Peripheral Controller"
 	depends on FSL_SOC || ARCH_MXC
+	depends on !ARCH_MULTIPLATFORM
 	select USB_FSL_MPH_DR_OF if OF
 	help
 	   Some of Freescale PowerPC and i.MX processors have a High Speed
@@ -280,7 +281,7 @@ config USB_S3C_HSOTG
 
 config USB_IMX
 	tristate "Freescale i.MX1 USB Peripheral Controller"
-	depends on ARCH_MXC
+	depends on ARCH_MXC && !ARCH_MULTIPLATFORM
 	help
 	   Freescale's i.MX1 includes an integrated full speed
 	   USB 1.1 device controller.
-- 
1.7.10.4

[PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist

[Arnd Bergmann]

In linux-3.8-rc1 it became possible to build the imx and
mvebu platforms together in a single kernel, which clashes
in the ehci driver.

Manjunath Goudar is already working on a patch to convert
both the imx and the mvebu glue drivers (along with all
the other ARM specific ones) to the new probing method,
but that will be too late to fix v3.8. This patch instead
adds yet another hack like the existing ones to allow
the ehci driver to load both back-ends.

Without this patch, building allyesconfig results in:

drivers/usb/host/ehci-hcd.c:1285:0: error: "PLATFORM_DRIVER" redefined
drivers/usb/host/ehci-hcd.c:1255:0: note: this is the location of the previous definition
In file included from drivers/usb/host/ehci-hcd.c:1254:0:
drivers/usb/host/ehci-mxc.c:280:31: warning: 'ehci_mxc_driver' defined but not used

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-usb@vger.kernel.org
Cc: Manjunath Goudar <manjunath.goudar@linaro.org>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Gregory Clement <gregory.clement@free-electrons.com>
---
 drivers/usb/host/ehci-hcd.c |   16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index c97503b..92e7180 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1282,7 +1282,7 @@ MODULE_LICENSE ("GPL");
 
 #ifdef CONFIG_PLAT_ORION
 #include "ehci-orion.c"
-#define	PLATFORM_DRIVER		ehci_orion_driver
+#define	ORION_PLATFORM_DRIVER		ehci_orion_driver
 #endif
 
 #ifdef CONFIG_USB_W90X900_EHCI
@@ -1353,6 +1353,7 @@ MODULE_LICENSE ("GPL");
 #if !IS_ENABLED(CONFIG_USB_EHCI_PCI) && \
 	!IS_ENABLED(CONFIG_USB_EHCI_HCD_PLATFORM) && \
 	!defined(CONFIG_USB_CHIPIDEA_HOST) && \
+	!defined(ORION_PLATFORM_DRIVER) && \
 	!defined(PLATFORM_DRIVER) && \
 	!defined(PS3_SYSTEM_BUS_DRIVER) && \
 	!defined(OF_PLATFORM_DRIVER) && \
@@ -1393,6 +1394,12 @@ static int __init ehci_hcd_init(void)
 		goto clean0;
 #endif
 
+#ifdef ORION_PLATFORM_DRIVER
+	retval = platform_driver_register(&ORION_PLATFORM_DRIVER);
+	if (retval < 0)
+		goto clean1;
+#endif
+
 #ifdef PS3_SYSTEM_BUS_DRIVER
 	retval = ps3_ehci_driver_register(&PS3_SYSTEM_BUS_DRIVER);
 	if (retval < 0)
@@ -1424,6 +1431,10 @@ clean3:
 	ps3_ehci_driver_unregister(&PS3_SYSTEM_BUS_DRIVER);
 clean2:
 #endif
+#ifdef ORION_PLATFORM_DRIVER
+	platform_driver_unregister(&ORION_PLATFORM_DRIVER);
+clean1:
+#endif
 #ifdef PLATFORM_DRIVER
 	platform_driver_unregister(&PLATFORM_DRIVER);
 clean0:
@@ -1446,6 +1457,9 @@ static void __exit ehci_hcd_cleanup(void)
 #ifdef OF_PLATFORM_DRIVER
 	platform_driver_unregister(&OF_PLATFORM_DRIVER);
 #endif
+#ifdef ORION_PLATFORM_DRIVER
+	platform_driver_unregister(&ORION_PLATFORM_DRIVER);
+#endif
 #ifdef PLATFORM_DRIVER
 	platform_driver_unregister(&PLATFORM_DRIVER);
 #endif
-- 
1.7.10.4

[PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist

[Arnd Bergmann]

In linux-3.8-rc1 it became possible to build the imx and
mvebu platforms together in a single kernel, which clashes
in the ehci driver.

Manjunath Goudar is already working on a patch to convert
both the imx and the mvebu glue drivers (along with all
the other ARM specific ones) to the new probing method,
but that will be too late to fix v3.8. This patch instead
adds yet another hack like the existing ones to allow
the ehci driver to load both back-ends.

Without this patch, building allyesconfig results in:

drivers/usb/host/ehci-hcd.c:1285:0: error: "PLATFORM_DRIVER" redefined
drivers/usb/host/ehci-hcd.c:1255:0: note: this is the location of the previous definition
In file included from drivers/usb/host/ehci-hcd.c:1254:0:
drivers/usb/host/ehci-mxc.c:280:31: warning: 'ehci_mxc_driver' defined but not used

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-usb at vger.kernel.org
Cc: Manjunath Goudar <manjunath.goudar@linaro.org>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Gregory Clement <gregory.clement@free-electrons.com>
---
 drivers/usb/host/ehci-hcd.c |   16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index c97503b..92e7180 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1282,7 +1282,7 @@ MODULE_LICENSE ("GPL");
 
 #ifdef CONFIG_PLAT_ORION
 #include "ehci-orion.c"
-#define	PLATFORM_DRIVER		ehci_orion_driver
+#define	ORION_PLATFORM_DRIVER		ehci_orion_driver
 #endif
 
 #ifdef CONFIG_USB_W90X900_EHCI
@@ -1353,6 +1353,7 @@ MODULE_LICENSE ("GPL");
 #if !IS_ENABLED(CONFIG_USB_EHCI_PCI) && \
 	!IS_ENABLED(CONFIG_USB_EHCI_HCD_PLATFORM) && \
 	!defined(CONFIG_USB_CHIPIDEA_HOST) && \
+	!defined(ORION_PLATFORM_DRIVER) && \
 	!defined(PLATFORM_DRIVER) && \
 	!defined(PS3_SYSTEM_BUS_DRIVER) && \
 	!defined(OF_PLATFORM_DRIVER) && \
@@ -1393,6 +1394,12 @@ static int __init ehci_hcd_init(void)
 		goto clean0;
 #endif
 
+#ifdef ORION_PLATFORM_DRIVER
+	retval = platform_driver_register(&ORION_PLATFORM_DRIVER);
+	if (retval < 0)
+		goto clean1;
+#endif
+
 #ifdef PS3_SYSTEM_BUS_DRIVER
 	retval = ps3_ehci_driver_register(&PS3_SYSTEM_BUS_DRIVER);
 	if (retval < 0)
@@ -1424,6 +1431,10 @@ clean3:
 	ps3_ehci_driver_unregister(&PS3_SYSTEM_BUS_DRIVER);
 clean2:
 #endif
+#ifdef ORION_PLATFORM_DRIVER
+	platform_driver_unregister(&ORION_PLATFORM_DRIVER);
+clean1:
+#endif
 #ifdef PLATFORM_DRIVER
 	platform_driver_unregister(&PLATFORM_DRIVER);
 clean0:
@@ -1446,6 +1457,9 @@ static void __exit ehci_hcd_cleanup(void)
 #ifdef OF_PLATFORM_DRIVER
 	platform_driver_unregister(&OF_PLATFORM_DRIVER);
 #endif
+#ifdef ORION_PLATFORM_DRIVER
+	platform_driver_unregister(&ORION_PLATFORM_DRIVER);
+#endif
 #ifdef PLATFORM_DRIVER
 	platform_driver_unregister(&PLATFORM_DRIVER);
 #endif
-- 
1.7.10.4

[PATCH 14/15] samples/seccomp: be less stupid about cross compiling

[Arnd Bergmann]

The seccomp filters are currently built for the build
host, not for the machine that they are going to run
on, but they are also built for with the -m32 flag
if the kernel is built for a 32 bit machine, both
of which seems rather odd.

It broke allyesconfig on my machine, which is x86-64, but
building for 32 bit ARM, with this error message:

In file included from /usr/include/stdio.h:28:0,
                 from samples/seccomp/bpf-fancy.c:15:
/usr/include/features.h:324:26: fatal error: bits/predefs.h: No such file or directory

because there are no 32 bit libc headers installed on
this machine. We should really be building all the
samples for the target machine rather than the build
host, but since the infrastructure for that appears
to be missing right now, let's be a little bit smarter
and not pass the '-m32' flag to the HOSTCC when cross-
compiling.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: James Morris <james.l.morris@oracle.com>
---
 samples/seccomp/Makefile |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/samples/seccomp/Makefile b/samples/seccomp/Makefile
index bbbd276..7203e66 100644
--- a/samples/seccomp/Makefile
+++ b/samples/seccomp/Makefile
@@ -19,6 +19,7 @@ bpf-direct-objs := bpf-direct.o
 
 # Try to match the kernel target.
 ifndef CONFIG_64BIT
+ifndef CROSS_COMPILE
 
 # s390 has -m31 flag to build 31 bit binaries
 ifndef CONFIG_S390
@@ -35,6 +36,7 @@ HOSTLOADLIBES_bpf-direct += $(MFLAG)
 HOSTLOADLIBES_bpf-fancy += $(MFLAG)
 HOSTLOADLIBES_dropper += $(MFLAG)
 endif
+endif
 
 # Tell kbuild to always build the programs
 always := $(hostprogs-y)
-- 
1.7.10.4

[PATCH 14/15] samples/seccomp: be less stupid about cross compiling

[Arnd Bergmann]

The seccomp filters are currently built for the build
host, not for the machine that they are going to run
on, but they are also built for with the -m32 flag
if the kernel is built for a 32 bit machine, both
of which seems rather odd.

It broke allyesconfig on my machine, which is x86-64, but
building for 32 bit ARM, with this error message:

In file included from /usr/include/stdio.h:28:0,
                 from samples/seccomp/bpf-fancy.c:15:
/usr/include/features.h:324:26: fatal error: bits/predefs.h: No such file or directory

because there are no 32 bit libc headers installed on
this machine. We should really be building all the
samples for the target machine rather than the build
host, but since the infrastructure for that appears
to be missing right now, let's be a little bit smarter
and not pass the '-m32' flag to the HOSTCC when cross-
compiling.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: James Morris <james.l.morris@oracle.com>
---
 samples/seccomp/Makefile |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/samples/seccomp/Makefile b/samples/seccomp/Makefile
index bbbd276..7203e66 100644
--- a/samples/seccomp/Makefile
+++ b/samples/seccomp/Makefile
@@ -19,6 +19,7 @@ bpf-direct-objs := bpf-direct.o
 
 # Try to match the kernel target.
 ifndef CONFIG_64BIT
+ifndef CROSS_COMPILE
 
 # s390 has -m31 flag to build 31 bit binaries
 ifndef CONFIG_S390
@@ -35,6 +36,7 @@ HOSTLOADLIBES_bpf-direct += $(MFLAG)
 HOSTLOADLIBES_bpf-fancy += $(MFLAG)
 HOSTLOADLIBES_dropper += $(MFLAG)
 endif
+endif
 
 # Tell kbuild to always build the programs
 always := $(hostprogs-y)
-- 
1.7.10.4

[PATCH 15/15] staging/omapdrm: don't build on multiplatform

[Arnd Bergmann]

The omapdrm driver is incorrectly flagged to allow building
on non-omap platforms, when ARCH_MULTIPLATFORM is set.

This does not work, because it unconditionally selects
the OMAP2_DSS symbol that only works on OMAP.
The problem was introduced in 5e3b087499 "staging:
drm/omap: add support for ARCH_MULTIPLATFORM", which this
patch partly reverts.

Without this patch, building allyesconfig results in:

warning: (VIDEO_OMAP2_VOUT && DRM_OMAP) selects OMAP2_DSS which has unmet direct dependencies (HAS_IOMEM && ARCH_OMAP2PLUS)
warning: (VIDEO_OMAP2_VOUT && DRM_OMAP) selects OMAP2_DSS which has unmet direct dependencies (HAS_IOMEM && ARCH_OMAP2PLUS)
drivers/video/omap2/dss/dss.c: In function 'dss_calc_clock_div':
drivers/video/omap2/dss/dss.c:572:20: error: 'CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK' undeclared (first use in this function)
drivers/video/omap2/dss/dss.c:572:20: note: each undeclared identifier is reported only once for each function it appears in
drivers/staging/omapdrm/omap_connector.c: In function 'omap_connector_dpms':
drivers/staging/omapdrm/omap_connector.c:116:8: error: 'OMAP_DSS_DISPLAY_SUSPENDED' undeclared (first use in this function)
drivers/staging/omapdrm/omap_connector.c:116:8: note: each undeclared identifier is reported only once for each function it appears in

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Clark <rob@ti.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/staging/omapdrm/Kconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/omapdrm/Kconfig b/drivers/staging/omapdrm/Kconfig
index b724a41..81a7cba 100644
--- a/drivers/staging/omapdrm/Kconfig
+++ b/drivers/staging/omapdrm/Kconfig
@@ -2,7 +2,7 @@
 config DRM_OMAP
 	tristate "OMAP DRM"
 	depends on DRM && !CONFIG_FB_OMAP2
-	depends on ARCH_OMAP2PLUS || ARCH_MULTIPLATFORM
+	depends on ARCH_OMAP2PLUS
 	select DRM_KMS_HELPER
 	select OMAP2_DSS
 	select FB_SYS_FILLRECT
-- 
1.7.10.4

[PATCH 15/15] staging/omapdrm: don't build on multiplatform

[Arnd Bergmann]

The omapdrm driver is incorrectly flagged to allow building
on non-omap platforms, when ARCH_MULTIPLATFORM is set.

This does not work, because it unconditionally selects
the OMAP2_DSS symbol that only works on OMAP.
The problem was introduced in 5e3b087499 "staging:
drm/omap: add support for ARCH_MULTIPLATFORM", which this
patch partly reverts.

Without this patch, building allyesconfig results in:

warning: (VIDEO_OMAP2_VOUT && DRM_OMAP) selects OMAP2_DSS which has unmet direct dependencies (HAS_IOMEM && ARCH_OMAP2PLUS)
warning: (VIDEO_OMAP2_VOUT && DRM_OMAP) selects OMAP2_DSS which has unmet direct dependencies (HAS_IOMEM && ARCH_OMAP2PLUS)
drivers/video/omap2/dss/dss.c: In function 'dss_calc_clock_div':
drivers/video/omap2/dss/dss.c:572:20: error: 'CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK' undeclared (first use in this function)
drivers/video/omap2/dss/dss.c:572:20: note: each undeclared identifier is reported only once for each function it appears in
drivers/staging/omapdrm/omap_connector.c: In function 'omap_connector_dpms':
drivers/staging/omapdrm/omap_connector.c:116:8: error: 'OMAP_DSS_DISPLAY_SUSPENDED' undeclared (first use in this function)
drivers/staging/omapdrm/omap_connector.c:116:8: note: each undeclared identifier is reported only once for each function it appears in

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Clark <rob@ti.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/staging/omapdrm/Kconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/omapdrm/Kconfig b/drivers/staging/omapdrm/Kconfig
index b724a41..81a7cba 100644
--- a/drivers/staging/omapdrm/Kconfig
+++ b/drivers/staging/omapdrm/Kconfig
@@ -2,7 +2,7 @@
 config DRM_OMAP
 	tristate "OMAP DRM"
 	depends on DRM && !CONFIG_FB_OMAP2
-	depends on ARCH_OMAP2PLUS || ARCH_MULTIPLATFORM
+	depends on ARCH_OMAP2PLUS
 	select DRM_KMS_HELPER
 	select OMAP2_DSS
 	select FB_SYS_FILLRECT
-- 
1.7.10.4

Re: [PATCH 10/15] mfd/vexpress: export vexpress_config_func_{put,get}

[Pawel Moll]

On Mon, 2013-01-21 at 17:16 +0000, Arnd Bergmann wrote:
> The newly introduced vexpress mfd driver in linux-3.8-rc
> provides access to configuration functions, but the
> interfaces are not exported to modules, which breaks
> when the vexpress regulator driver tries to use them.
> 
> Without this patch, building allmodconfig results in:
> 
> ERROR: "__vexpress_config_func_get" [drivers/regulator/vexpress.ko] undefined!
> ERROR: "vexpress_config_func_put" [drivers/regulator/vexpress.ko] undefined!
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Pawel Moll <pawel.moll@arm.com>
> Cc: Samuel Ortiz <sameo@linux.intel.com>
> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>

You are the third person noticing that. My bad :-(

In fact some other ones, like the *_bridge_register could do with
exporting as well... I'll get all the patches merged in my fixes branch
and send a pull request this week.

Thanks!

Paweł

[PATCH 10/15] mfd/vexpress: export vexpress_config_func_{put,get}

[Pawel Moll]

On Mon, 2013-01-21 at 17:16 +0000, Arnd Bergmann wrote:
> The newly introduced vexpress mfd driver in linux-3.8-rc
> provides access to configuration functions, but the
> interfaces are not exported to modules, which breaks
> when the vexpress regulator driver tries to use them.
> 
> Without this patch, building allmodconfig results in:
> 
> ERROR: "__vexpress_config_func_get" [drivers/regulator/vexpress.ko] undefined!
> ERROR: "vexpress_config_func_put" [drivers/regulator/vexpress.ko] undefined!
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Pawel Moll <pawel.moll@arm.com>
> Cc: Samuel Ortiz <sameo@linux.intel.com>
> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>

You are the third person noticing that. My bad :-(

In fact some other ones, like the *_bridge_register could do with
exporting as well... I'll get all the patches merged in my fixes branch
and send a pull request this week.

Thanks!

Pawe?

Re: [PATCH 15/15] staging/omapdrm: don't build on multiplatform

[Rob Clark]

On 01/21/2013 11:16 AM, Arnd Bergmann wrote:
> The omapdrm driver is incorrectly flagged to allow building
> on non-omap platforms, when ARCH_MULTIPLATFORM is set.
>
> This does not work, because it unconditionally selects
> the OMAP2_DSS symbol that only works on OMAP.
> The problem was introduced in 5e3b087499 "staging:
> drm/omap: add support for ARCH_MULTIPLATFORM", which this
> patch partly reverts.

Are you sure OMAP2_DSS requires ARCH_OMAP2PLUS?  I don't see this, and 
it at least used to not depend on ARCH_OMAP2PLUS.  If it does now, I 
think the correct fix would be to remove the dependency in OMAP2_DSS.  I 
don't think removing ARCH_MULTIPLATFORM support in omapdrm is the 
correct solution.


> Without this patch, building allyesconfig results in:
>
> warning: (VIDEO_OMAP2_VOUT && DRM_OMAP) selects OMAP2_DSS which has unmet direct dependencies (HAS_IOMEM && ARCH_OMAP2PLUS)
> warning: (VIDEO_OMAP2_VOUT && DRM_OMAP) selects OMAP2_DSS which has unmet direct dependencies (HAS_IOMEM && ARCH_OMAP2PLUS)
> drivers/video/omap2/dss/dss.c: In function 'dss_calc_clock_div':
> drivers/video/omap2/dss/dss.c:572:20: error: 'CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK' undeclared (first use in this function)
> drivers/video/omap2/dss/dss.c:572:20: note: each undeclared identifier is reported only once for each function it appears in
> drivers/staging/omapdrm/omap_connector.c: In function 'omap_connector_dpms':
> drivers/staging/omapdrm/omap_connector.c:116:8: error: 'OMAP_DSS_DISPLAY_SUSPENDED' undeclared (first use in this function)
> drivers/staging/omapdrm/omap_connector.c:116:8: note: each undeclared identifier is reported only once for each function it appears in


This was an unrelated build break which should be fixed in latest master 
after 'staging: drm/omap: use omapdss low level API'

BR,
-R

>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Rob Clark <rob@ti.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
>   drivers/staging/omapdrm/Kconfig |    2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/omapdrm/Kconfig b/drivers/staging/omapdrm/Kconfig
> index b724a41..81a7cba 100644
> --- a/drivers/staging/omapdrm/Kconfig
> +++ b/drivers/staging/omapdrm/Kconfig
> @@ -2,7 +2,7 @@
>   config DRM_OMAP
>   	tristate "OMAP DRM"
>   	depends on DRM && !CONFIG_FB_OMAP2
> -	depends on ARCH_OMAP2PLUS || ARCH_MULTIPLATFORM
> +	depends on ARCH_OMAP2PLUS
>   	select DRM_KMS_HELPER
>   	select OMAP2_DSS
>   	select FB_SYS_FILLRECT

[PATCH 15/15] staging/omapdrm: don't build on multiplatform

[Rob Clark]

On 01/21/2013 11:16 AM, Arnd Bergmann wrote:
> The omapdrm driver is incorrectly flagged to allow building
> on non-omap platforms, when ARCH_MULTIPLATFORM is set.
>
> This does not work, because it unconditionally selects
> the OMAP2_DSS symbol that only works on OMAP.
> The problem was introduced in 5e3b087499 "staging:
> drm/omap: add support for ARCH_MULTIPLATFORM", which this
> patch partly reverts.

Are you sure OMAP2_DSS requires ARCH_OMAP2PLUS?  I don't see this, and 
it at least used to not depend on ARCH_OMAP2PLUS.  If it does now, I 
think the correct fix would be to remove the dependency in OMAP2_DSS.  I 
don't think removing ARCH_MULTIPLATFORM support in omapdrm is the 
correct solution.


> Without this patch, building allyesconfig results in:
>
> warning: (VIDEO_OMAP2_VOUT && DRM_OMAP) selects OMAP2_DSS which has unmet direct dependencies (HAS_IOMEM && ARCH_OMAP2PLUS)
> warning: (VIDEO_OMAP2_VOUT && DRM_OMAP) selects OMAP2_DSS which has unmet direct dependencies (HAS_IOMEM && ARCH_OMAP2PLUS)
> drivers/video/omap2/dss/dss.c: In function 'dss_calc_clock_div':
> drivers/video/omap2/dss/dss.c:572:20: error: 'CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK' undeclared (first use in this function)
> drivers/video/omap2/dss/dss.c:572:20: note: each undeclared identifier is reported only once for each function it appears in
> drivers/staging/omapdrm/omap_connector.c: In function 'omap_connector_dpms':
> drivers/staging/omapdrm/omap_connector.c:116:8: error: 'OMAP_DSS_DISPLAY_SUSPENDED' undeclared (first use in this function)
> drivers/staging/omapdrm/omap_connector.c:116:8: note: each undeclared identifier is reported only once for each function it appears in


This was an unrelated build break which should be fixed in latest master 
after 'staging: drm/omap: use omapdss low level API'

BR,
-R

>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Rob Clark <rob@ti.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
>   drivers/staging/omapdrm/Kconfig |    2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/omapdrm/Kconfig b/drivers/staging/omapdrm/Kconfig
> index b724a41..81a7cba 100644
> --- a/drivers/staging/omapdrm/Kconfig
> +++ b/drivers/staging/omapdrm/Kconfig
> @@ -2,7 +2,7 @@
>   config DRM_OMAP
>   	tristate "OMAP DRM"
>   	depends on DRM && !CONFIG_FB_OMAP2
> -	depends on ARCH_OMAP2PLUS || ARCH_MULTIPLATFORM
> +	depends on ARCH_OMAP2PLUS
>   	select DRM_KMS_HELPER
>   	select OMAP2_DSS
>   	select FB_SYS_FILLRECT

Re: [PATCH 15/15] staging/omapdrm: don't build on multiplatform

[Rob Clark]

On 01/21/2013 11:26 AM, Rob Clark wrote:
> On 01/21/2013 11:16 AM, Arnd Bergmann wrote:
>> The omapdrm driver is incorrectly flagged to allow building
>> on non-omap platforms, when ARCH_MULTIPLATFORM is set.
>>
>> This does not work, because it unconditionally selects
>> the OMAP2_DSS symbol that only works on OMAP.
>> The problem was introduced in 5e3b087499 "staging:
>> drm/omap: add support for ARCH_MULTIPLATFORM", which this
>> patch partly reverts.
>
> Are you sure OMAP2_DSS requires ARCH_OMAP2PLUS?  I don't see this, and 
> it at least used to not depend on ARCH_OMAP2PLUS.  If it does now, I 
> think the correct fix would be to remove the dependency in OMAP2_DSS.  
> I don't think removing ARCH_MULTIPLATFORM support in omapdrm is the 
> correct solution.

hmm, yes, it does appear that OMAP2_DSS depends on ARCH_OMAP2PLUS.. let 
me have a quick look at this, fixing omapdss would be a better solution..

BR,
-R

>
>
>> Without this patch, building allyesconfig results in:
>>
>> warning: (VIDEO_OMAP2_VOUT && DRM_OMAP) selects OMAP2_DSS which has 
>> unmet direct dependencies (HAS_IOMEM && ARCH_OMAP2PLUS)
>> warning: (VIDEO_OMAP2_VOUT && DRM_OMAP) selects OMAP2_DSS which has 
>> unmet direct dependencies (HAS_IOMEM && ARCH_OMAP2PLUS)
>> drivers/video/omap2/dss/dss.c: In function 'dss_calc_clock_div':
>> drivers/video/omap2/dss/dss.c:572:20: error: 
>> 'CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK' undeclared (first use in this 
>> function)
>> drivers/video/omap2/dss/dss.c:572:20: note: each undeclared 
>> identifier is reported only once for each function it appears in
>> drivers/staging/omapdrm/omap_connector.c: In function 
>> 'omap_connector_dpms':
>> drivers/staging/omapdrm/omap_connector.c:116:8: error: 
>> 'OMAP_DSS_DISPLAY_SUSPENDED' undeclared (first use in this function)
>> drivers/staging/omapdrm/omap_connector.c:116:8: note: each undeclared 
>> identifier is reported only once for each function it appears in
>
>
> This was an unrelated build break which should be fixed in latest 
> master after 'staging: drm/omap: use omapdss low level API'
>
> BR,
> -R
>
>>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> Cc: Rob Clark <rob@ti.com>
>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> ---
>>   drivers/staging/omapdrm/Kconfig |    2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/staging/omapdrm/Kconfig 
>> b/drivers/staging/omapdrm/Kconfig
>> index b724a41..81a7cba 100644
>> --- a/drivers/staging/omapdrm/Kconfig
>> +++ b/drivers/staging/omapdrm/Kconfig
>> @@ -2,7 +2,7 @@
>>   config DRM_OMAP
>>       tristate "OMAP DRM"
>>       depends on DRM && !CONFIG_FB_OMAP2
>> -    depends on ARCH_OMAP2PLUS || ARCH_MULTIPLATFORM
>> +    depends on ARCH_OMAP2PLUS
>>       select DRM_KMS_HELPER
>>       select OMAP2_DSS
>>       select FB_SYS_FILLRECT
>

[PATCH 15/15] staging/omapdrm: don't build on multiplatform

[Rob Clark]

On 01/21/2013 11:26 AM, Rob Clark wrote:
> On 01/21/2013 11:16 AM, Arnd Bergmann wrote:
>> The omapdrm driver is incorrectly flagged to allow building
>> on non-omap platforms, when ARCH_MULTIPLATFORM is set.
>>
>> This does not work, because it unconditionally selects
>> the OMAP2_DSS symbol that only works on OMAP.
>> The problem was introduced in 5e3b087499 "staging:
>> drm/omap: add support for ARCH_MULTIPLATFORM", which this
>> patch partly reverts.
>
> Are you sure OMAP2_DSS requires ARCH_OMAP2PLUS?  I don't see this, and 
> it at least used to not depend on ARCH_OMAP2PLUS.  If it does now, I 
> think the correct fix would be to remove the dependency in OMAP2_DSS.  
> I don't think removing ARCH_MULTIPLATFORM support in omapdrm is the 
> correct solution.

hmm, yes, it does appear that OMAP2_DSS depends on ARCH_OMAP2PLUS.. let 
me have a quick look at this, fixing omapdss would be a better solution..

BR,
-R

>
>
>> Without this patch, building allyesconfig results in:
>>
>> warning: (VIDEO_OMAP2_VOUT && DRM_OMAP) selects OMAP2_DSS which has 
>> unmet direct dependencies (HAS_IOMEM && ARCH_OMAP2PLUS)
>> warning: (VIDEO_OMAP2_VOUT && DRM_OMAP) selects OMAP2_DSS which has 
>> unmet direct dependencies (HAS_IOMEM && ARCH_OMAP2PLUS)
>> drivers/video/omap2/dss/dss.c: In function 'dss_calc_clock_div':
>> drivers/video/omap2/dss/dss.c:572:20: error: 
>> 'CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK' undeclared (first use in this 
>> function)
>> drivers/video/omap2/dss/dss.c:572:20: note: each undeclared 
>> identifier is reported only once for each function it appears in
>> drivers/staging/omapdrm/omap_connector.c: In function 
>> 'omap_connector_dpms':
>> drivers/staging/omapdrm/omap_connector.c:116:8: error: 
>> 'OMAP_DSS_DISPLAY_SUSPENDED' undeclared (first use in this function)
>> drivers/staging/omapdrm/omap_connector.c:116:8: note: each undeclared 
>> identifier is reported only once for each function it appears in
>
>
> This was an unrelated build break which should be fixed in latest 
> master after 'staging: drm/omap: use omapdss low level API'
>
> BR,
> -R
>
>>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> Cc: Rob Clark <rob@ti.com>
>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> ---
>>   drivers/staging/omapdrm/Kconfig |    2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/staging/omapdrm/Kconfig 
>> b/drivers/staging/omapdrm/Kconfig
>> index b724a41..81a7cba 100644
>> --- a/drivers/staging/omapdrm/Kconfig
>> +++ b/drivers/staging/omapdrm/Kconfig
>> @@ -2,7 +2,7 @@
>>   config DRM_OMAP
>>       tristate "OMAP DRM"
>>       depends on DRM && !CONFIG_FB_OMAP2
>> -    depends on ARCH_OMAP2PLUS || ARCH_MULTIPLATFORM
>> +    depends on ARCH_OMAP2PLUS
>>       select DRM_KMS_HELPER
>>       select OMAP2_DSS
>>       select FB_SYS_FILLRECT
>

Re: [PATCH 15/15] staging/omapdrm: don't build on multiplatform

[Arnd Bergmann]

On Monday 21 January 2013, Rob Clark wrote:
> Are you sure OMAP2_DSS requires ARCH_OMAP2PLUS?  I don't see this, and 
> it at least used to not depend on ARCH_OMAP2PLUS.  If it does now, I 
> think the correct fix would be to remove the dependency in OMAP2_DSS.  I 
> don't think removing ARCH_MULTIPLATFORM support in omapdrm is the 
> correct solution.

At least it says so in drivers/video/omap2/Kconfig, which contains

if ARCH_OMAP2PLUS
source drivers/video/omap2/dss/Kconfig
endif

We can probably change this, but until we do, we should not select
OMAP2_DSS from something that doesn't also depend on ARCH_OMAP2PLUS.
 
> > drivers/video/omap2/dss/dss.c: In function 'dss_calc_clock_div':
> > drivers/video/omap2/dss/dss.c:572:20: error: 'CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK' undeclared (first use in this function)
> > drivers/video/omap2/dss/dss.c:572:20: note: each undeclared identifier is reported only once for each function it appears in
> > drivers/staging/omapdrm/omap_connector.c: In function 'omap_connector_dpms':
> > drivers/staging/omapdrm/omap_connector.c:116:8: error: 'OMAP_DSS_DISPLAY_SUSPENDED' undeclared (first use in this function)
> > drivers/staging/omapdrm/omap_connector.c:116:8: note: each undeclared identifier is reported only once for each function it appears in
> 
> 
> This was an unrelated build break which should be fixed in latest master 
> after 'staging: drm/omap: use omapdss low level API'

Ok, it seems the message is stale then, I created the patch some time ago, but
only today wrote rest of the explanation for the changeset text.

With all the other patches from my series applied, allyesconfig still gives me

drivers/video/omap2/dss/dss.c:572:20: error: 'CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK' undeclared

because that symbol is only defined when OMAP2_DSS is enabled rather than
selected. Changing drivers/video/omap2/Kconfig to not depend on OMAP seems
to work as well, but that seems a little intrusive for v3.8, because it would
let a lot of people build that code that have no use for it.

	Arnd

[PATCH 15/15] staging/omapdrm: don't build on multiplatform

[Arnd Bergmann]

On Monday 21 January 2013, Rob Clark wrote:
> Are you sure OMAP2_DSS requires ARCH_OMAP2PLUS?  I don't see this, and 
> it at least used to not depend on ARCH_OMAP2PLUS.  If it does now, I 
> think the correct fix would be to remove the dependency in OMAP2_DSS.  I 
> don't think removing ARCH_MULTIPLATFORM support in omapdrm is the 
> correct solution.

At least it says so in drivers/video/omap2/Kconfig, which contains

if ARCH_OMAP2PLUS
source drivers/video/omap2/dss/Kconfig
endif

We can probably change this, but until we do, we should not select
OMAP2_DSS from something that doesn't also depend on ARCH_OMAP2PLUS.
 
> > drivers/video/omap2/dss/dss.c: In function 'dss_calc_clock_div':
> > drivers/video/omap2/dss/dss.c:572:20: error: 'CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK' undeclared (first use in this function)
> > drivers/video/omap2/dss/dss.c:572:20: note: each undeclared identifier is reported only once for each function it appears in
> > drivers/staging/omapdrm/omap_connector.c: In function 'omap_connector_dpms':
> > drivers/staging/omapdrm/omap_connector.c:116:8: error: 'OMAP_DSS_DISPLAY_SUSPENDED' undeclared (first use in this function)
> > drivers/staging/omapdrm/omap_connector.c:116:8: note: each undeclared identifier is reported only once for each function it appears in
> 
> 
> This was an unrelated build break which should be fixed in latest master 
> after 'staging: drm/omap: use omapdss low level API'

Ok, it seems the message is stale then, I created the patch some time ago, but
only today wrote rest of the explanation for the changeset text.

With all the other patches from my series applied, allyesconfig still gives me

drivers/video/omap2/dss/dss.c:572:20: error: 'CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK' undeclared

because that symbol is only defined when OMAP2_DSS is enabled rather than
selected. Changing drivers/video/omap2/Kconfig to not depend on OMAP seems
to work as well, but that seems a little intrusive for v3.8, because it would
let a lot of people build that code that have no use for it.

	Arnd

Re: [PATCH 15/15] staging/omapdrm: don't build on multiplatform

[Rob Clark]

On 01/21/2013 11:41 AM, Arnd Bergmann wrote:
> On Monday 21 January 2013, Rob Clark wrote:
>> Are you sure OMAP2_DSS requires ARCH_OMAP2PLUS?  I don't see this, and
>> it at least used to not depend on ARCH_OMAP2PLUS.  If it does now, I
>> think the correct fix would be to remove the dependency in OMAP2_DSS.  I
>> don't think removing ARCH_MULTIPLATFORM support in omapdrm is the
>> correct solution.
> At least it says so in drivers/video/omap2/Kconfig, which contains
>
> if ARCH_OMAP2PLUS
> source drivers/video/omap2/dss/Kconfig
> endif

ahh, ok, I see.. the if ARCH_OMAP2PLUS bit looks like it came in 
recently (770b6cb)

what about changing this to 'if ARCH_OMAP2PLUS || ARCH_MULTIPLATFORM'?

BR,
-R

> We can probably change this, but until we do, we should not select
> OMAP2_DSS from something that doesn't also depend on ARCH_OMAP2PLUS.
>   
>>> drivers/video/omap2/dss/dss.c: In function 'dss_calc_clock_div':
>>> drivers/video/omap2/dss/dss.c:572:20: error: 'CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK' undeclared (first use in this function)
>>> drivers/video/omap2/dss/dss.c:572:20: note: each undeclared identifier is reported only once for each function it appears in
>>> drivers/staging/omapdrm/omap_connector.c: In function 'omap_connector_dpms':
>>> drivers/staging/omapdrm/omap_connector.c:116:8: error: 'OMAP_DSS_DISPLAY_SUSPENDED' undeclared (first use in this function)
>>> drivers/staging/omapdrm/omap_connector.c:116:8: note: each undeclared identifier is reported only once for each function it appears in
>>
>> This was an unrelated build break which should be fixed in latest master
>> after 'staging: drm/omap: use omapdss low level API'
> Ok, it seems the message is stale then, I created the patch some time ago, but
> only today wrote rest of the explanation for the changeset text.
>
> With all the other patches from my series applied, allyesconfig still gives me
>
> drivers/video/omap2/dss/dss.c:572:20: error: 'CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK' undeclared
>
> because that symbol is only defined when OMAP2_DSS is enabled rather than
> selected. Changing drivers/video/omap2/Kconfig to not depend on OMAP seems
> to work as well, but that seems a little intrusive for v3.8, because it would
> let a lot of people build that code that have no use for it.
>
> 	Arnd

[PATCH 15/15] staging/omapdrm: don't build on multiplatform

[Rob Clark]

On 01/21/2013 11:41 AM, Arnd Bergmann wrote:
> On Monday 21 January 2013, Rob Clark wrote:
>> Are you sure OMAP2_DSS requires ARCH_OMAP2PLUS?  I don't see this, and
>> it at least used to not depend on ARCH_OMAP2PLUS.  If it does now, I
>> think the correct fix would be to remove the dependency in OMAP2_DSS.  I
>> don't think removing ARCH_MULTIPLATFORM support in omapdrm is the
>> correct solution.
> At least it says so in drivers/video/omap2/Kconfig, which contains
>
> if ARCH_OMAP2PLUS
> source drivers/video/omap2/dss/Kconfig
> endif

ahh, ok, I see.. the if ARCH_OMAP2PLUS bit looks like it came in 
recently (770b6cb)

what about changing this to 'if ARCH_OMAP2PLUS || ARCH_MULTIPLATFORM'?

BR,
-R

> We can probably change this, but until we do, we should not select
> OMAP2_DSS from something that doesn't also depend on ARCH_OMAP2PLUS.
>   
>>> drivers/video/omap2/dss/dss.c: In function 'dss_calc_clock_div':
>>> drivers/video/omap2/dss/dss.c:572:20: error: 'CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK' undeclared (first use in this function)
>>> drivers/video/omap2/dss/dss.c:572:20: note: each undeclared identifier is reported only once for each function it appears in
>>> drivers/staging/omapdrm/omap_connector.c: In function 'omap_connector_dpms':
>>> drivers/staging/omapdrm/omap_connector.c:116:8: error: 'OMAP_DSS_DISPLAY_SUSPENDED' undeclared (first use in this function)
>>> drivers/staging/omapdrm/omap_connector.c:116:8: note: each undeclared identifier is reported only once for each function it appears in
>>
>> This was an unrelated build break which should be fixed in latest master
>> after 'staging: drm/omap: use omapdss low level API'
> Ok, it seems the message is stale then, I created the patch some time ago, but
> only today wrote rest of the explanation for the changeset text.
>
> With all the other patches from my series applied, allyesconfig still gives me
>
> drivers/video/omap2/dss/dss.c:572:20: error: 'CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK' undeclared
>
> because that symbol is only defined when OMAP2_DSS is enabled rather than
> selected. Changing drivers/video/omap2/Kconfig to not depend on OMAP seems
> to work as well, but that seems a little intrusive for v3.8, because it would
> let a lot of people build that code that have no use for it.
>
> 	Arnd

Re: [PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers

[Felipe Balbi]

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

Hi,

On Mon, Jan 21, 2013 at 05:16:05PM +0000, Arnd Bergmann wrote:
> Both the fsl_mxc gadget and the imx_udc gadget drivers fail to build
> without the mach/hardware.h file that is not available when building
> for multiplatform. Let's disable these drivers for v3.8 in combination
> with CONFIG_ARCH_MULTIPLATFORM, and fix them properly in v3.9 unless
> someone has an better solution.
> 
> Without this patch, building allyesconfig results in:
> 
> drivers/usb/gadget/fsl_mxc_udc.c:21:27: fatal error: mach/hardware.h: No such file or directory
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Felipe Balbi <balbi@ti.com>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: linux-usb@vger.kernel.org

NAK, I prefer to see a real fix for the problem (which in fact is
already in my fixes branch).

Next time, before enabling something by default, check that
allyesconfig, allmodconfig and allnoconfig builds fine, please.

-- 
balbi

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

[PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers

[Felipe Balbi]

Hi,

On Mon, Jan 21, 2013 at 05:16:05PM +0000, Arnd Bergmann wrote:
> Both the fsl_mxc gadget and the imx_udc gadget drivers fail to build
> without the mach/hardware.h file that is not available when building
> for multiplatform. Let's disable these drivers for v3.8 in combination
> with CONFIG_ARCH_MULTIPLATFORM, and fix them properly in v3.9 unless
> someone has an better solution.
> 
> Without this patch, building allyesconfig results in:
> 
> drivers/usb/gadget/fsl_mxc_udc.c:21:27: fatal error: mach/hardware.h: No such file or directory
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Felipe Balbi <balbi@ti.com>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: linux-usb at vger.kernel.org

NAK, I prefer to see a real fix for the problem (which in fact is
already in my fixes branch).

Next time, before enabling something by default, check that
allyesconfig, allmodconfig and allnoconfig builds fine, please.

-- 
balbi
-------------- 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/20130121/e2036f1b/attachment.sig>

Re: [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist

[Felipe Balbi]

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

On Mon, Jan 21, 2013 at 05:16:06PM +0000, Arnd Bergmann wrote:
> In linux-3.8-rc1 it became possible to build the imx and
> mvebu platforms together in a single kernel, which clashes
> in the ehci driver.
> 
> Manjunath Goudar is already working on a patch to convert
> both the imx and the mvebu glue drivers (along with all
> the other ARM specific ones) to the new probing method,
> but that will be too late to fix v3.8. This patch instead
> adds yet another hack like the existing ones to allow
> the ehci driver to load both back-ends.
> 
> Without this patch, building allyesconfig results in:
> 
> drivers/usb/host/ehci-hcd.c:1285:0: error: "PLATFORM_DRIVER" redefined
> drivers/usb/host/ehci-hcd.c:1255:0: note: this is the location of the previous definition
> In file included from drivers/usb/host/ehci-hcd.c:1254:0:
> drivers/usb/host/ehci-mxc.c:280:31: warning: 'ehci_mxc_driver' defined but not used
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Alan Stern <stern@rowland.harvard.edu>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: linux-usb@vger.kernel.org
> Cc: Manjunath Goudar <manjunath.goudar@linaro.org>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Gregory Clement <gregory.clement@free-electrons.com>

NAK, should be converted to the new usage of ehci library driver. Alan
Stern already implemented for a few drivers, help is very welcome.

-- 
balbi

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

[PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist

[Felipe Balbi]

On Mon, Jan 21, 2013 at 05:16:06PM +0000, Arnd Bergmann wrote:
> In linux-3.8-rc1 it became possible to build the imx and
> mvebu platforms together in a single kernel, which clashes
> in the ehci driver.
> 
> Manjunath Goudar is already working on a patch to convert
> both the imx and the mvebu glue drivers (along with all
> the other ARM specific ones) to the new probing method,
> but that will be too late to fix v3.8. This patch instead
> adds yet another hack like the existing ones to allow
> the ehci driver to load both back-ends.
> 
> Without this patch, building allyesconfig results in:
> 
> drivers/usb/host/ehci-hcd.c:1285:0: error: "PLATFORM_DRIVER" redefined
> drivers/usb/host/ehci-hcd.c:1255:0: note: this is the location of the previous definition
> In file included from drivers/usb/host/ehci-hcd.c:1254:0:
> drivers/usb/host/ehci-mxc.c:280:31: warning: 'ehci_mxc_driver' defined but not used
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Alan Stern <stern@rowland.harvard.edu>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: linux-usb at vger.kernel.org
> Cc: Manjunath Goudar <manjunath.goudar@linaro.org>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Gregory Clement <gregory.clement@free-electrons.com>

NAK, should be converted to the new usage of ehci library driver. Alan
Stern already implemented for a few drivers, help is very welcome.

-- 
balbi
-------------- 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/20130121/bb62631b/attachment-0001.sig>

Re: [PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers

[Greg Kroah-Hartman]

On Mon, Jan 21, 2013 at 08:41:38PM +0200, Felipe Balbi wrote:
> Hi,
> 
> On Mon, Jan 21, 2013 at 05:16:05PM +0000, Arnd Bergmann wrote:
> > Both the fsl_mxc gadget and the imx_udc gadget drivers fail to build
> > without the mach/hardware.h file that is not available when building
> > for multiplatform. Let's disable these drivers for v3.8 in combination
> > with CONFIG_ARCH_MULTIPLATFORM, and fix them properly in v3.9 unless
> > someone has an better solution.
> > 
> > Without this patch, building allyesconfig results in:
> > 
> > drivers/usb/gadget/fsl_mxc_udc.c:21:27: fatal error: mach/hardware.h: No such file or directory
> > 
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Felipe Balbi <balbi@ti.com>
> > Cc: Shawn Guo <shawn.guo@linaro.org>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: linux-usb@vger.kernel.org
> 
> NAK, I prefer to see a real fix for the problem (which in fact is
> already in my fixes branch).

I'll pull that branch now, sorry for the delay.

greg k-h

[PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers

[Greg Kroah-Hartman]

On Mon, Jan 21, 2013 at 08:41:38PM +0200, Felipe Balbi wrote:
> Hi,
> 
> On Mon, Jan 21, 2013 at 05:16:05PM +0000, Arnd Bergmann wrote:
> > Both the fsl_mxc gadget and the imx_udc gadget drivers fail to build
> > without the mach/hardware.h file that is not available when building
> > for multiplatform. Let's disable these drivers for v3.8 in combination
> > with CONFIG_ARCH_MULTIPLATFORM, and fix them properly in v3.9 unless
> > someone has an better solution.
> > 
> > Without this patch, building allyesconfig results in:
> > 
> > drivers/usb/gadget/fsl_mxc_udc.c:21:27: fatal error: mach/hardware.h: No such file or directory
> > 
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Felipe Balbi <balbi@ti.com>
> > Cc: Shawn Guo <shawn.guo@linaro.org>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: linux-usb at vger.kernel.org
> 
> NAK, I prefer to see a real fix for the problem (which in fact is
> already in my fixes branch).

I'll pull that branch now, sorry for the delay.

greg k-h

Re: [PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers

[Felipe Balbi]

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

On Mon, Jan 21, 2013 at 10:57:16AM -0800, Greg Kroah-Hartman wrote:
> On Mon, Jan 21, 2013 at 08:41:38PM +0200, Felipe Balbi wrote:
> > Hi,
> > 
> > On Mon, Jan 21, 2013 at 05:16:05PM +0000, Arnd Bergmann wrote:
> > > Both the fsl_mxc gadget and the imx_udc gadget drivers fail to build
> > > without the mach/hardware.h file that is not available when building
> > > for multiplatform. Let's disable these drivers for v3.8 in combination
> > > with CONFIG_ARCH_MULTIPLATFORM, and fix them properly in v3.9 unless
> > > someone has an better solution.
> > > 
> > > Without this patch, building allyesconfig results in:
> > > 
> > > drivers/usb/gadget/fsl_mxc_udc.c:21:27: fatal error: mach/hardware.h: No such file or directory
> > > 
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > Cc: Felipe Balbi <balbi@ti.com>
> > > Cc: Shawn Guo <shawn.guo@linaro.org>
> > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > Cc: linux-usb@vger.kernel.org
> > 
> > NAK, I prefer to see a real fix for the problem (which in fact is
> > already in my fixes branch).
> 
> I'll pull that branch now, sorry for the delay.

no problem ;-)

-- 
balbi

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

[PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers

[Felipe Balbi]

On Mon, Jan 21, 2013 at 10:57:16AM -0800, Greg Kroah-Hartman wrote:
> On Mon, Jan 21, 2013 at 08:41:38PM +0200, Felipe Balbi wrote:
> > Hi,
> > 
> > On Mon, Jan 21, 2013 at 05:16:05PM +0000, Arnd Bergmann wrote:
> > > Both the fsl_mxc gadget and the imx_udc gadget drivers fail to build
> > > without the mach/hardware.h file that is not available when building
> > > for multiplatform. Let's disable these drivers for v3.8 in combination
> > > with CONFIG_ARCH_MULTIPLATFORM, and fix them properly in v3.9 unless
> > > someone has an better solution.
> > > 
> > > Without this patch, building allyesconfig results in:
> > > 
> > > drivers/usb/gadget/fsl_mxc_udc.c:21:27: fatal error: mach/hardware.h: No such file or directory
> > > 
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > Cc: Felipe Balbi <balbi@ti.com>
> > > Cc: Shawn Guo <shawn.guo@linaro.org>
> > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > Cc: linux-usb at vger.kernel.org
> > 
> > NAK, I prefer to see a real fix for the problem (which in fact is
> > already in my fixes branch).
> 
> I'll pull that branch now, sorry for the delay.

no problem ;-)

-- 
balbi
-------------- 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/20130121/351a1fcb/attachment.sig>

Re: [PATCH 02/15] ARM: mvebu: build coherency_ll.S for arch=armv7-a

[Tony Lindgren]

* Arnd Bergmann <arnd@arndb.de> [130121 09:23]:
> In a multiplatform kernel, one can enable mach-mvebu
> together with one or more ARMv6 platforms, which leads
> to all files being built for v6. The coherency_ll.S
> uses the "dsb" instruction that is only available for
> v7, causing a build error in this case. Since the
> file is only used on v7 based machines, it is safe
> to build it using an ".arch armv7-a" statement.
> 
> Without this patch, building allyesconfig results in:
> 
> arch/arm/mach-mvebu/coherency_ll.S: Assembler messages:
> arch/arm/mach-mvebu/coherency_ll.S:45: Error: selected processor does not support ARM mode `dsb'

This should be already fixed by 72533b (arm: mvebu: Fix compile for
multiplatform when ARMv6 is selected) in arm-soc fixes branch.

Regards,

Tony
 
> 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>
> ---
>  arch/arm/mach-mvebu/coherency_ll.S |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/mach-mvebu/coherency_ll.S b/arch/arm/mach-mvebu/coherency_ll.S
> index 53e8391..7648bda 100644
> --- a/arch/arm/mach-mvebu/coherency_ll.S
> +++ b/arch/arm/mach-mvebu/coherency_ll.S
> @@ -25,6 +25,7 @@
>   * r0: Coherency fabric base register address
>   * r1: HW CPU id
>   */
> +	.arch armv7-a
>  ENTRY(ll_set_cpu_coherent)
>  	/* Create bit by cpu index */
>  	mov	r3, #(1 << 24)
> -- 
> 1.7.10.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 02/15] ARM: mvebu: build coherency_ll.S for arch=armv7-a

[Tony Lindgren]

* Arnd Bergmann <arnd@arndb.de> [130121 09:23]:
> In a multiplatform kernel, one can enable mach-mvebu
> together with one or more ARMv6 platforms, which leads
> to all files being built for v6. The coherency_ll.S
> uses the "dsb" instruction that is only available for
> v7, causing a build error in this case. Since the
> file is only used on v7 based machines, it is safe
> to build it using an ".arch armv7-a" statement.
> 
> Without this patch, building allyesconfig results in:
> 
> arch/arm/mach-mvebu/coherency_ll.S: Assembler messages:
> arch/arm/mach-mvebu/coherency_ll.S:45: Error: selected processor does not support ARM mode `dsb'

This should be already fixed by 72533b (arm: mvebu: Fix compile for
multiplatform when ARMv6 is selected) in arm-soc fixes branch.

Regards,

Tony
 
> 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>
> ---
>  arch/arm/mach-mvebu/coherency_ll.S |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/mach-mvebu/coherency_ll.S b/arch/arm/mach-mvebu/coherency_ll.S
> index 53e8391..7648bda 100644
> --- a/arch/arm/mach-mvebu/coherency_ll.S
> +++ b/arch/arm/mach-mvebu/coherency_ll.S
> @@ -25,6 +25,7 @@
>   * r0: Coherency fabric base register address
>   * r1: HW CPU id
>   */
> +	.arch armv7-a
>  ENTRY(ll_set_cpu_coherent)
>  	/* Create bit by cpu index */
>  	mov	r3, #(1 << 24)
> -- 
> 1.7.10.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 15/15] staging/omapdrm: don't build on multiplatform

[Arnd Bergmann]

On Monday 21 January 2013, Rob Clark wrote:
> ahh, ok, I see.. the if ARCH_OMAP2PLUS bit looks like it came in 
> recently (770b6cb)
> 
> what about changing this to 'if ARCH_OMAP2PLUS || ARCH_MULTIPLATFORM'?

Fine with me in general, but the patch I posted would be the more
conservative choice for v3.8.

	Arnd

[PATCH 15/15] staging/omapdrm: don't build on multiplatform

[Arnd Bergmann]

On Monday 21 January 2013, Rob Clark wrote:
> ahh, ok, I see.. the if ARCH_OMAP2PLUS bit looks like it came in 
> recently (770b6cb)
> 
> what about changing this to 'if ARCH_OMAP2PLUS || ARCH_MULTIPLATFORM'?

Fine with me in general, but the patch I posted would be the more
conservative choice for v3.8.

	Arnd

Re: [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist

[Alan Stern]

On Mon, 21 Jan 2013, Felipe Balbi wrote:

> On Mon, Jan 21, 2013 at 05:16:06PM +0000, Arnd Bergmann wrote:
> > In linux-3.8-rc1 it became possible to build the imx and
> > mvebu platforms together in a single kernel, which clashes
> > in the ehci driver.
> > 
> > Manjunath Goudar is already working on a patch to convert
> > both the imx and the mvebu glue drivers (along with all
> > the other ARM specific ones) to the new probing method,
> > but that will be too late to fix v3.8. This patch instead
> > adds yet another hack like the existing ones to allow
> > the ehci driver to load both back-ends.

Pardon me for being confused.  Is this about imx and mvebu (as 
mentioned here) or about orion and mxc (as described in the patch 
title, the error messages below, and the patch itself)?

> > Without this patch, building allyesconfig results in:
> > 
> > drivers/usb/host/ehci-hcd.c:1285:0: error: "PLATFORM_DRIVER" redefined
> > drivers/usb/host/ehci-hcd.c:1255:0: note: this is the location of the previous definition
> > In file included from drivers/usb/host/ehci-hcd.c:1254:0:
> > drivers/usb/host/ehci-mxc.c:280:31: warning: 'ehci_mxc_driver' defined but not used

Was the point here to fix the build error or to allow the two drivers
to coexist?  The first would be eaiser than the second.

> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Alan Stern <stern@rowland.harvard.edu>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: linux-usb@vger.kernel.org
> > Cc: Manjunath Goudar <manjunath.goudar@linaro.org>
> > Cc: Shawn Guo <shawn.guo@linaro.org>
> > Cc: Sascha Hauer <s.hauer@pengutronix.de>
> > Cc: Jason Cooper <jason@lakedaemon.net>
> > Cc: Andrew Lunn <andrew@lunn.ch>
> > Cc: Gregory Clement <gregory.clement@free-electrons.com>
> 
> NAK, should be converted to the new usage of ehci library driver. Alan
> Stern already implemented for a few drivers, help is very welcome.

Arnd, please take a look at

	http://marc.info/?l=linux-usb&m=135843716515529&w=2

I can't test it easily, not being set up for cross compilation.  I'm 
waiting to hear from anybody whether it works before submitting it.
(There's also a report of memory corruption involving a similar patch 
for ehci-omap; it hasn't been tracked down yet.)

Alan Stern

[PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist

[Alan Stern]

On Mon, 21 Jan 2013, Felipe Balbi wrote:

> On Mon, Jan 21, 2013 at 05:16:06PM +0000, Arnd Bergmann wrote:
> > In linux-3.8-rc1 it became possible to build the imx and
> > mvebu platforms together in a single kernel, which clashes
> > in the ehci driver.
> > 
> > Manjunath Goudar is already working on a patch to convert
> > both the imx and the mvebu glue drivers (along with all
> > the other ARM specific ones) to the new probing method,
> > but that will be too late to fix v3.8. This patch instead
> > adds yet another hack like the existing ones to allow
> > the ehci driver to load both back-ends.

Pardon me for being confused.  Is this about imx and mvebu (as 
mentioned here) or about orion and mxc (as described in the patch 
title, the error messages below, and the patch itself)?

> > Without this patch, building allyesconfig results in:
> > 
> > drivers/usb/host/ehci-hcd.c:1285:0: error: "PLATFORM_DRIVER" redefined
> > drivers/usb/host/ehci-hcd.c:1255:0: note: this is the location of the previous definition
> > In file included from drivers/usb/host/ehci-hcd.c:1254:0:
> > drivers/usb/host/ehci-mxc.c:280:31: warning: 'ehci_mxc_driver' defined but not used

Was the point here to fix the build error or to allow the two drivers
to coexist?  The first would be eaiser than the second.

> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Alan Stern <stern@rowland.harvard.edu>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: linux-usb at vger.kernel.org
> > Cc: Manjunath Goudar <manjunath.goudar@linaro.org>
> > Cc: Shawn Guo <shawn.guo@linaro.org>
> > Cc: Sascha Hauer <s.hauer@pengutronix.de>
> > Cc: Jason Cooper <jason@lakedaemon.net>
> > Cc: Andrew Lunn <andrew@lunn.ch>
> > Cc: Gregory Clement <gregory.clement@free-electrons.com>
> 
> NAK, should be converted to the new usage of ehci library driver. Alan
> Stern already implemented for a few drivers, help is very welcome.

Arnd, please take a look at

	http://marc.info/?l=linux-usb&m=135843716515529&w=2

I can't test it easily, not being set up for cross compilation.  I'm 
waiting to hear from anybody whether it works before submitting it.
(There's also a report of memory corruption involving a similar patch 
for ehci-omap; it hasn't been tracked down yet.)

Alan Stern

Re: [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist

[Arnd Bergmann]

On Monday 21 January 2013, Felipe Balbi wrote:
> On Mon, Jan 21, 2013 at 05:16:06PM +0000, Arnd Bergmann wrote:
> > Manjunath Goudar is already working on a patch to convert
> > both the imx and the mvebu glue drivers (along with all
> > the other ARM specific ones) to the new probing method,
> > but that will be too late to fix v3.8. This patch instead
> > adds yet another hack like the existing ones to allow
> > the ehci driver to load both back-ends.
> 
> NAK, should be converted to the new usage of ehci library driver. Alan
> Stern already implemented for a few drivers, help is very welcome.

As I explained above, Manjunath already has a patch [1] for that, but I
think it's too late to include that in v3.8 given the regression
potential and size of the patch. Once he submits that patch for 3.9,
my change would get taken out anyway, but it lets us build important
configurations (including allyesconfig build tests) on 3.8.

	Arnd

[1] http://git.linaro.org/gitweb?p=people/manjunathgoudar/usb-refactoring.git;a=commitdiff;h=d9f28dba727212d022605c955796a3a83b3978ae

[PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist

[Arnd Bergmann]

On Monday 21 January 2013, Felipe Balbi wrote:
> On Mon, Jan 21, 2013 at 05:16:06PM +0000, Arnd Bergmann wrote:
> > Manjunath Goudar is already working on a patch to convert
> > both the imx and the mvebu glue drivers (along with all
> > the other ARM specific ones) to the new probing method,
> > but that will be too late to fix v3.8. This patch instead
> > adds yet another hack like the existing ones to allow
> > the ehci driver to load both back-ends.
> 
> NAK, should be converted to the new usage of ehci library driver. Alan
> Stern already implemented for a few drivers, help is very welcome.

As I explained above, Manjunath already has a patch [1] for that, but I
think it's too late to include that in v3.8 given the regression
potential and size of the patch. Once he submits that patch for 3.9,
my change would get taken out anyway, but it lets us build important
configurations (including allyesconfig build tests) on 3.8.

	Arnd

[1] http://git.linaro.org/gitweb?p=people/manjunathgoudar/usb-refactoring.git;a=commitdiff;h=d9f28dba727212d022605c955796a3a83b3978ae

Re: [PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers

[Arnd Bergmann]

On Monday 21 January 2013, Greg Kroah-Hartman wrote:
> On Mon, Jan 21, 2013 at 08:41:38PM +0200, Felipe Balbi wrote:
>
> > NAK, I prefer to see a real fix for the problem (which in fact is
> > already in my fixes branch).
> 
> I'll pull that branch now, sorry for the delay.
> 

Ok, great! Thanks a lot, both of you,

	Arnd

[PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers

[Arnd Bergmann]

On Monday 21 January 2013, Greg Kroah-Hartman wrote:
> On Mon, Jan 21, 2013 at 08:41:38PM +0200, Felipe Balbi wrote:
>
> > NAK, I prefer to see a real fix for the problem (which in fact is
> > already in my fixes branch).
> 
> I'll pull that branch now, sorry for the delay.
> 

Ok, great! Thanks a lot, both of you,

	Arnd

Re: [PATCH 02/15] ARM: mvebu: build coherency_ll.S for arch=armv7-a

[Arnd Bergmann]

On Monday 21 January 2013, Tony Lindgren wrote:
> > 
> > arch/arm/mach-mvebu/coherency_ll.S: Assembler messages:
> > arch/arm/mach-mvebu/coherency_ll.S:45: Error: selected processor does not support ARM mode `dsb'
> 
> This should be already fixed by 72533b (arm: mvebu: Fix compile for
> multiplatform when ARMv6 is selected) in arm-soc fixes branch.
> 

Ok, silly me, I forgot to check my own tree :)

Thanks for looking into it!

	Arnd

[PATCH 02/15] ARM: mvebu: build coherency_ll.S for arch=armv7-a

[Arnd Bergmann]

On Monday 21 January 2013, Tony Lindgren wrote:
> > 
> > arch/arm/mach-mvebu/coherency_ll.S: Assembler messages:
> > arch/arm/mach-mvebu/coherency_ll.S:45: Error: selected processor does not support ARM mode `dsb'
> 
> This should be already fixed by 72533b (arm: mvebu: Fix compile for
> multiplatform when ARMv6 is selected) in arm-soc fixes branch.
> 

Ok, silly me, I forgot to check my own tree :)

Thanks for looking into it!

	Arnd

Re: [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist

[Alan Stern]

On Mon, 21 Jan 2013, Arnd Bergmann wrote:

> On Monday 21 January 2013, Felipe Balbi wrote:
> > On Mon, Jan 21, 2013 at 05:16:06PM +0000, Arnd Bergmann wrote:
> > > Manjunath Goudar is already working on a patch to convert
> > > both the imx and the mvebu glue drivers (along with all
> > > the other ARM specific ones) to the new probing method,
> > > but that will be too late to fix v3.8. This patch instead
> > > adds yet another hack like the existing ones to allow
> > > the ehci driver to load both back-ends.
> > 
> > NAK, should be converted to the new usage of ehci library driver. Alan
> > Stern already implemented for a few drivers, help is very welcome.
> 
> As I explained above, Manjunath already has a patch [1] for that, but I
> think it's too late to include that in v3.8 given the regression
> potential and size of the patch. Once he submits that patch for 3.9,
> my change would get taken out anyway, but it lets us build important
> configurations (including allyesconfig build tests) on 3.8.
> 
> 	Arnd
> 
> [1] http://git.linaro.org/gitweb?p=people/manjunathgoudar/usb-refactoring.git;a=commitdiff;h=d9f28dba727212d022605c955796a3a83b3978ae

Is Manjunath aware of the first patch attached to this email message?

	http://marc.info/?l=linux-usb&m=135843902916416&w=2

Alan Stern

[PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist

[Alan Stern]

On Mon, 21 Jan 2013, Arnd Bergmann wrote:

> On Monday 21 January 2013, Felipe Balbi wrote:
> > On Mon, Jan 21, 2013 at 05:16:06PM +0000, Arnd Bergmann wrote:
> > > Manjunath Goudar is already working on a patch to convert
> > > both the imx and the mvebu glue drivers (along with all
> > > the other ARM specific ones) to the new probing method,
> > > but that will be too late to fix v3.8. This patch instead
> > > adds yet another hack like the existing ones to allow
> > > the ehci driver to load both back-ends.
> > 
> > NAK, should be converted to the new usage of ehci library driver. Alan
> > Stern already implemented for a few drivers, help is very welcome.
> 
> As I explained above, Manjunath already has a patch [1] for that, but I
> think it's too late to include that in v3.8 given the regression
> potential and size of the patch. Once he submits that patch for 3.9,
> my change would get taken out anyway, but it lets us build important
> configurations (including allyesconfig build tests) on 3.8.
> 
> 	Arnd
> 
> [1] http://git.linaro.org/gitweb?p=people/manjunathgoudar/usb-refactoring.git;a=commitdiff;h=d9f28dba727212d022605c955796a3a83b3978ae

Is Manjunath aware of the first patch attached to this email message?

	http://marc.info/?l=linux-usb&m=135843902916416&w=2

Alan Stern

Re: [PATCH 06/15] clk: export __clk_get_name

[Ulf Hansson]

On 21 January 2013 18:15, Arnd Bergmann <arnd@arndb.de> wrote:
> The __clk_get_name is used by drivers that provide their
> own clocks, which have traditionally all been built-in.
> The new imx drm driver however provides clocks but can
> be built as a module, so we need to export __clk_get_name.
>
> While this is only a staging driver, it's likely that
> there will be others like it in the future.
>
> Without this patch, building ARM allmodconfig results in:
>
> ERROR: "__clk_get_name" [drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.ko] undefined!
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Mike Turquette <mturquette@linaro.org>
> ---
>  drivers/clk/clk.c |    1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 251e45d..13b793e 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -263,6 +263,7 @@ inline const char *__clk_get_name(struct clk *clk)
>  {
>         return !clk ? NULL : clk->name;
>  }
> +EXPORT_SYMBOL_GPL(__clk_get_name);
>
>  inline struct clk_hw *__clk_get_hw(struct clk *clk)
>  {
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Acked-by: Ulf Hansson <ulf.hansson@linaro.org>

[PATCH 06/15] clk: export __clk_get_name

[Ulf Hansson]

On 21 January 2013 18:15, Arnd Bergmann <arnd@arndb.de> wrote:
> The __clk_get_name is used by drivers that provide their
> own clocks, which have traditionally all been built-in.
> The new imx drm driver however provides clocks but can
> be built as a module, so we need to export __clk_get_name.
>
> While this is only a staging driver, it's likely that
> there will be others like it in the future.
>
> Without this patch, building ARM allmodconfig results in:
>
> ERROR: "__clk_get_name" [drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.ko] undefined!
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Mike Turquette <mturquette@linaro.org>
> ---
>  drivers/clk/clk.c |    1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 251e45d..13b793e 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -263,6 +263,7 @@ inline const char *__clk_get_name(struct clk *clk)
>  {
>         return !clk ? NULL : clk->name;
>  }
> +EXPORT_SYMBOL_GPL(__clk_get_name);
>
>  inline struct clk_hw *__clk_get_hw(struct clk *clk)
>  {
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Acked-by: Ulf Hansson <ulf.hansson@linaro.org>

Re: [PATCH 11/15] mtd: davinci_nand: fix OF support

[Heiko Schocher]

Hello Arnd,

On 21.01.2013 18:16, Arnd Bergmann wrote:
> The patch cdeadd "mtd: nand: davinci: add OF support for
> davinci nand controller" ironically causes a build error
> when CONFIG_OF is enabled because of a missing ';'
> character:
> 
> drivers/mtd/nand/davinci_nand.c:527:1: error: expected ',' or ';' before 'extern'
> 
> This is the obvious fix.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Heiko Schocher <hs@denx.de>
> Cc: Sekhar Nori <nsekhar@ti.com>
> Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
> Cc: David Woodhouse <David.Woodhouse@intel.com>
> ---
>  drivers/mtd/nand/davinci_nand.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Already fixed here:
http://lists.infradead.org/pipermail/linux-mtd/2013-January/045366.html

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[PATCH 11/15] mtd: davinci_nand: fix OF support

[Heiko Schocher]

Hello Arnd,

On 21.01.2013 18:16, Arnd Bergmann wrote:
> The patch cdeadd "mtd: nand: davinci: add OF support for
> davinci nand controller" ironically causes a build error
> when CONFIG_OF is enabled because of a missing ';'
> character:
> 
> drivers/mtd/nand/davinci_nand.c:527:1: error: expected ',' or ';' before 'extern'
> 
> This is the obvious fix.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Heiko Schocher <hs@denx.de>
> Cc: Sekhar Nori <nsekhar@ti.com>
> Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
> Cc: David Woodhouse <David.Woodhouse@intel.com>
> ---
>  drivers/mtd/nand/davinci_nand.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Already fixed here:
http://lists.infradead.org/pipermail/linux-mtd/2013-January/045366.html

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Re: [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist

[Arnd Bergmann]

On Monday 21 January 2013, Alan Stern wrote:
> On Mon, 21 Jan 2013, Felipe Balbi wrote:
> 
> > On Mon, Jan 21, 2013 at 05:16:06PM +0000, Arnd Bergmann wrote:
> > > In linux-3.8-rc1 it became possible to build the imx and
> > > mvebu platforms together in a single kernel, which clashes
> > > in the ehci driver.
> > > 
> > > Manjunath Goudar is already working on a patch to convert
> > > both the imx and the mvebu glue drivers (along with all
> > > the other ARM specific ones) to the new probing method,
> > > but that will be too late to fix v3.8. This patch instead
> > > adds yet another hack like the existing ones to allow
> > > the ehci driver to load both back-ends.
> 
> Pardon me for being confused.  Is this about imx and mvebu (as 
> mentioned here) or about orion and mxc (as described in the patch 
> title, the error messages below, and the patch itself)?

mxc is the old name for imx: the platform got removed, but some
of the drivers still carry the old name. Similarly, orion was
used before as the name for the superset of various Marvell platforms,
and mvebu is the superset of that and some of the newer ones.

Sorry for the confusion.

> > > Without this patch, building allyesconfig results in:
> > > 
> > > drivers/usb/host/ehci-hcd.c:1285:0: error: "PLATFORM_DRIVER" redefined
> > > drivers/usb/host/ehci-hcd.c:1255:0: note: this is the location of the previous definition
> > > In file included from drivers/usb/host/ehci-hcd.c:1254:0:
> > > drivers/usb/host/ehci-mxc.c:280:31: warning: 'ehci_mxc_driver' defined but not used
> 
> Was the point here to fix the build error or to allow the two drivers
> to coexist?  The first would be eaiser than the second.

Fixing the build error is probably the more important part here, but
we also really want this to work, since people are migrating towards
multiplatform kernels now, and mvebu/orion and imx/mxc are two of the
more important ones.

> > NAK, should be converted to the new usage of ehci library driver. Alan
> > Stern already implemented for a few drivers, help is very welcome.
> 
> Arnd, please take a look at
> 
>         http://marc.info/?l=linux-usb&m=135843716515529&w=2
> 
> I can't test it easily, not being set up for cross compilation.  I'm 
> waiting to hear from anybody whether it works before submitting it.
> (There's also a report of memory corruption involving a similar patch 
> for ehci-omap; it hasn't been tracked down yet.)

Your patch looks good to me, but it also seems to do some other
changes that are not required to fix the problem but could wait
for 3.9 instead. You definitely have my Ack if you are willing
to take it for 3.8 though.

Shawn or Sascha should be able to test it.

	Arnd

[PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist

[Arnd Bergmann]

On Monday 21 January 2013, Alan Stern wrote:
> On Mon, 21 Jan 2013, Felipe Balbi wrote:
> 
> > On Mon, Jan 21, 2013 at 05:16:06PM +0000, Arnd Bergmann wrote:
> > > In linux-3.8-rc1 it became possible to build the imx and
> > > mvebu platforms together in a single kernel, which clashes
> > > in the ehci driver.
> > > 
> > > Manjunath Goudar is already working on a patch to convert
> > > both the imx and the mvebu glue drivers (along with all
> > > the other ARM specific ones) to the new probing method,
> > > but that will be too late to fix v3.8. This patch instead
> > > adds yet another hack like the existing ones to allow
> > > the ehci driver to load both back-ends.
> 
> Pardon me for being confused.  Is this about imx and mvebu (as 
> mentioned here) or about orion and mxc (as described in the patch 
> title, the error messages below, and the patch itself)?

mxc is the old name for imx: the platform got removed, but some
of the drivers still carry the old name. Similarly, orion was
used before as the name for the superset of various Marvell platforms,
and mvebu is the superset of that and some of the newer ones.

Sorry for the confusion.

> > > Without this patch, building allyesconfig results in:
> > > 
> > > drivers/usb/host/ehci-hcd.c:1285:0: error: "PLATFORM_DRIVER" redefined
> > > drivers/usb/host/ehci-hcd.c:1255:0: note: this is the location of the previous definition
> > > In file included from drivers/usb/host/ehci-hcd.c:1254:0:
> > > drivers/usb/host/ehci-mxc.c:280:31: warning: 'ehci_mxc_driver' defined but not used
> 
> Was the point here to fix the build error or to allow the two drivers
> to coexist?  The first would be eaiser than the second.

Fixing the build error is probably the more important part here, but
we also really want this to work, since people are migrating towards
multiplatform kernels now, and mvebu/orion and imx/mxc are two of the
more important ones.

> > NAK, should be converted to the new usage of ehci library driver. Alan
> > Stern already implemented for a few drivers, help is very welcome.
> 
> Arnd, please take a look at
> 
>         http://marc.info/?l=linux-usb&m=135843716515529&w=2
> 
> I can't test it easily, not being set up for cross compilation.  I'm 
> waiting to hear from anybody whether it works before submitting it.
> (There's also a report of memory corruption involving a similar patch 
> for ehci-omap; it hasn't been tracked down yet.)

Your patch looks good to me, but it also seems to do some other
changes that are not required to fix the problem but could wait
for 3.9 instead. You definitely have my Ack if you are willing
to take it for 3.8 though.

Shawn or Sascha should be able to test it.

	Arnd

Re: [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist

[Arnd Bergmann]

On Monday 21 January 2013, Alan Stern wrote:
> Is Manjunath aware of the first patch attached to this email message?
> 
>         http://marc.info/?l=linux-usb&m=135843902916416&w=2
> 

I would not expect so. Manjunath is still learning about the open
source processes, but he has also done a similar patch in his tree,
and one for most of the other ARM based platforms.

Manjunath: following up on the discussions we've had, I would suggest
you take a look at that patch, and do a comparison with your version
(apply it on the same base, then use git-diff to show the differences
between the version) and thing about whether your they are significant
or not.  Since Alan posted his version on the mailing list first, that's
the one that should get merged, but there might be something in it that
you can learn from it and that I did not see.

Alan, one comment about your version: You keep maintaining the
'#if IS_ENABLED' list in the main driver, which I think can actually
get removed now. Since the base driver can be built independent of
the presence of platform glue drivers, there is no need to forbid
it any more, and the #if block will cause merge conflicts for each
patch that converts or adds another platform. I think we can actually
get the same results by turning the Kconfig logic around and making
the platform glue drivers 'select USB_EHCI_HCD' than depending on
it.

	Arnd

[PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist

[Arnd Bergmann]

On Monday 21 January 2013, Alan Stern wrote:
> Is Manjunath aware of the first patch attached to this email message?
> 
>         http://marc.info/?l=linux-usb&m=135843902916416&w=2
> 

I would not expect so. Manjunath is still learning about the open
source processes, but he has also done a similar patch in his tree,
and one for most of the other ARM based platforms.

Manjunath: following up on the discussions we've had, I would suggest
you take a look at that patch, and do a comparison with your version
(apply it on the same base, then use git-diff to show the differences
between the version) and thing about whether your they are significant
or not.  Since Alan posted his version on the mailing list first, that's
the one that should get merged, but there might be something in it that
you can learn from it and that I did not see.

Alan, one comment about your version: You keep maintaining the
'#if IS_ENABLED' list in the main driver, which I think can actually
get removed now. Since the base driver can be built independent of
the presence of platform glue drivers, there is no need to forbid
it any more, and the #if block will cause merge conflicts for each
patch that converts or adds another platform. I think we can actually
get the same results by turning the Kconfig logic around and making
the platform glue drivers 'select USB_EHCI_HCD' than depending on
it.

	Arnd

Re: [PATCH 11/15] mtd: davinci_nand: fix OF support

[Arnd Bergmann]

On Monday 21 January 2013, Heiko Schocher wrote:
> Already fixed here:
> http://lists.infradead.org/pipermail/linux-mtd/2013-January/045366.html
> 

Ok, thanks for the confirmation. I had only checked -rc4, not any newer
snapshot.

	Arnd

[PATCH 11/15] mtd: davinci_nand: fix OF support

[Arnd Bergmann]

On Monday 21 January 2013, Heiko Schocher wrote:
> Already fixed here:
> http://lists.infradead.org/pipermail/linux-mtd/2013-January/045366.html
> 

Ok, thanks for the confirmation. I had only checked -rc4, not any newer
snapshot.

	Arnd

Re: [PATCH 08/15] drm/exynos: fimd and ipp are broken on multiplatform

[Inki Dae]

Checked it out and applied. For ARCH_MULTIPLATFORM support, Such
header files shouldn't be included. And for this, we are planning on
supporting device tree for ipp driver.

Thanks,
Inki Dae

2013/1/22 Arnd Bergmann <arnd@arndb.de>:
> While the exynos DRM support in principle can work on
> multiplatform, the FIMD and IPP sections of it both
> include the plat/map-base.h header file, which is
> not available on multiplatform. Rather than disabling
> the entire driver, we can just conditionally build
> these two parts.
>
> Without this patch, building allyesconfig results in:
>
> drivers/gpu/drm/exynos/exynos_drm_fimc.c:19:27: fatal error: plat/map-base.h: No such file or directory
> drivers/gpu/drm/exynos/exynos_drm_ipp.c:20:27: fatal error: plat/map-base.h: No such file or directory
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Joonyoung Shim <jy0922.shim@samsung.com>
> Cc: Inki Dae <inki.dae@samsung.com>
> Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Cc: David Airlie <airlied@linux.ie>
> Cc: dri-devel@lists.freedesktop.org
> ---
>  drivers/gpu/drm/exynos/Kconfig |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
> index 1d1f1e5..046bcda 100644
> --- a/drivers/gpu/drm/exynos/Kconfig
> +++ b/drivers/gpu/drm/exynos/Kconfig
> @@ -24,7 +24,7 @@ config DRM_EXYNOS_DMABUF
>
>  config DRM_EXYNOS_FIMD
>         bool "Exynos DRM FIMD"
> -       depends on DRM_EXYNOS && !FB_S3C
> +       depends on DRM_EXYNOS && !FB_S3C && !ARCH_MULTIPLATFORM
>         help
>           Choose this option if you want to use Exynos FIMD for DRM.
>
> @@ -48,7 +48,7 @@ config DRM_EXYNOS_G2D
>
>  config DRM_EXYNOS_IPP
>         bool "Exynos DRM IPP"
> -       depends on DRM_EXYNOS
> +       depends on DRM_EXYNOS && !ARCH_MULTIPLATFORM
>         help
>           Choose this option if you want to use IPP feature for DRM.
>
> --
> 1.7.10.4
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 08/15] drm/exynos: fimd and ipp are broken on multiplatform

[Inki Dae]

Checked it out and applied. For ARCH_MULTIPLATFORM support, Such
header files shouldn't be included. And for this, we are planning on
supporting device tree for ipp driver.

Thanks,
Inki Dae

2013/1/22 Arnd Bergmann <arnd@arndb.de>:
> While the exynos DRM support in principle can work on
> multiplatform, the FIMD and IPP sections of it both
> include the plat/map-base.h header file, which is
> not available on multiplatform. Rather than disabling
> the entire driver, we can just conditionally build
> these two parts.
>
> Without this patch, building allyesconfig results in:
>
> drivers/gpu/drm/exynos/exynos_drm_fimc.c:19:27: fatal error: plat/map-base.h: No such file or directory
> drivers/gpu/drm/exynos/exynos_drm_ipp.c:20:27: fatal error: plat/map-base.h: No such file or directory
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Joonyoung Shim <jy0922.shim@samsung.com>
> Cc: Inki Dae <inki.dae@samsung.com>
> Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Cc: David Airlie <airlied@linux.ie>
> Cc: dri-devel at lists.freedesktop.org
> ---
>  drivers/gpu/drm/exynos/Kconfig |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
> index 1d1f1e5..046bcda 100644
> --- a/drivers/gpu/drm/exynos/Kconfig
> +++ b/drivers/gpu/drm/exynos/Kconfig
> @@ -24,7 +24,7 @@ config DRM_EXYNOS_DMABUF
>
>  config DRM_EXYNOS_FIMD
>         bool "Exynos DRM FIMD"
> -       depends on DRM_EXYNOS && !FB_S3C
> +       depends on DRM_EXYNOS && !FB_S3C && !ARCH_MULTIPLATFORM
>         help
>           Choose this option if you want to use Exynos FIMD for DRM.
>
> @@ -48,7 +48,7 @@ config DRM_EXYNOS_G2D
>
>  config DRM_EXYNOS_IPP
>         bool "Exynos DRM IPP"
> -       depends on DRM_EXYNOS
> +       depends on DRM_EXYNOS && !ARCH_MULTIPLATFORM
>         help
>           Choose this option if you want to use IPP feature for DRM.
>
> --
> 1.7.10.4
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist

[Alan Stern]

On Mon, 21 Jan 2013, Arnd Bergmann wrote:

> Alan, one comment about your version: You keep maintaining the
> '#if IS_ENABLED' list in the main driver, which I think can actually
> get removed now.

I considered doing that.  The benefit of keeping it is that it warns 
about configs where the main driver is built but can never be used.

Still, you're right that its purpose is becoming less important.  I had 
planned to remove it when all the glue driver had been converted, but 
in fact it could be removed at any time.

>  Since the base driver can be built independent of
> the presence of platform glue drivers, there is no need to forbid
> it any more, and the #if block will cause merge conflicts for each
> patch that converts or adds another platform.

If the patches are done independently.  There are likely to be some
context conflicts anyway.

>  I think we can actually
> get the same results by turning the Kconfig logic around and making
> the platform glue drivers 'select USB_EHCI_HCD' than depending on
> it.

That's a good idea.  The Kconfig changes would have to be done 
carefully to make sure that the dependency on USB_ARCH_HAS_EHCI still 
applies to all the platform drivers.

Manjunath, would you like to send a patch to do this?

Alan Stern

[PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist

[Alan Stern]

On Mon, 21 Jan 2013, Arnd Bergmann wrote:

> Alan, one comment about your version: You keep maintaining the
> '#if IS_ENABLED' list in the main driver, which I think can actually
> get removed now.

I considered doing that.  The benefit of keeping it is that it warns 
about configs where the main driver is built but can never be used.

Still, you're right that its purpose is becoming less important.  I had 
planned to remove it when all the glue driver had been converted, but 
in fact it could be removed at any time.

>  Since the base driver can be built independent of
> the presence of platform glue drivers, there is no need to forbid
> it any more, and the #if block will cause merge conflicts for each
> patch that converts or adds another platform.

If the patches are done independently.  There are likely to be some
context conflicts anyway.

>  I think we can actually
> get the same results by turning the Kconfig logic around and making
> the platform glue drivers 'select USB_EHCI_HCD' than depending on
> it.

That's a good idea.  The Kconfig changes would have to be done 
carefully to make sure that the dependency on USB_ARCH_HAS_EHCI still 
applies to all the platform drivers.

Manjunath, would you like to send a patch to do this?

Alan Stern

Re: [PATCH 05/15] ASoC: fsl: fiq and dma cannot both be modules

[Shawn Guo]

On Mon, Jan 21, 2013 at 05:15:58PM +0000, Arnd Bergmann wrote:
> The dma and fiq portions of the imx-pcm driver both
> have a module_init() call, of which there can be only
> one in any given module. This changes Kconfig to enforce
> either the driver to be built-in in the kernel, or
> to have only one of the two when building imx-pcm as
> a module.
> 
> Without this patch, we cannot build the ARM 'allmodconfig', or
> we get this error:
> 
> sound/soc/fsl/imx-pcm-dma.o: In function `init_module':
> sound/soc/fsl/imx-pcm-dma.c:177: multiple definition of `init_module'
> sound/soc/fsl/imx-pcm-fiq.o:sound/soc/fsl/imx-pcm-fiq.c:334: first defined here
> sound/soc/fsl/imx-pcm-dma.o: In function `cleanup_module':
> sound/soc/fsl/imx-pcm-dma.c:177: multiple definition of `cleanup_module'
> sound/soc/fsl/imx-pcm-fiq.o:sound/soc/fsl/imx-pcm-fiq.c:334: first defined here
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Liam Girdwood <lrg@ti.com>
> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Cc: alsa-devel@alsa-project.org

I sent a fix [1] for that queued by Mark.

Mark,

Is the patch on the way to 3.8-rc?

Shawn

[1] http://thread.gmane.org/gmane.linux.alsa.devel/104434

Re: [PATCH 05/15] ASoC: fsl: fiq and dma cannot both be modules

[Shawn Guo]

On Mon, Jan 21, 2013 at 05:15:58PM +0000, Arnd Bergmann wrote:
> The dma and fiq portions of the imx-pcm driver both
> have a module_init() call, of which there can be only
> one in any given module. This changes Kconfig to enforce
> either the driver to be built-in in the kernel, or
> to have only one of the two when building imx-pcm as
> a module.
> 
> Without this patch, we cannot build the ARM 'allmodconfig', or
> we get this error:
> 
> sound/soc/fsl/imx-pcm-dma.o: In function `init_module':
> sound/soc/fsl/imx-pcm-dma.c:177: multiple definition of `init_module'
> sound/soc/fsl/imx-pcm-fiq.o:sound/soc/fsl/imx-pcm-fiq.c:334: first defined here
> sound/soc/fsl/imx-pcm-dma.o: In function `cleanup_module':
> sound/soc/fsl/imx-pcm-dma.c:177: multiple definition of `cleanup_module'
> sound/soc/fsl/imx-pcm-fiq.o:sound/soc/fsl/imx-pcm-fiq.c:334: first defined here
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Liam Girdwood <lrg@ti.com>
> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Cc: alsa-devel@alsa-project.org

I sent a fix [1] for that queued by Mark.

Mark,

Is the patch on the way to 3.8-rc?

Shawn

[1] http://thread.gmane.org/gmane.linux.alsa.devel/104434

[PATCH 05/15] ASoC: fsl: fiq and dma cannot both be modules

[Shawn Guo]

On Mon, Jan 21, 2013 at 05:15:58PM +0000, Arnd Bergmann wrote:
> The dma and fiq portions of the imx-pcm driver both
> have a module_init() call, of which there can be only
> one in any given module. This changes Kconfig to enforce
> either the driver to be built-in in the kernel, or
> to have only one of the two when building imx-pcm as
> a module.
> 
> Without this patch, we cannot build the ARM 'allmodconfig', or
> we get this error:
> 
> sound/soc/fsl/imx-pcm-dma.o: In function `init_module':
> sound/soc/fsl/imx-pcm-dma.c:177: multiple definition of `init_module'
> sound/soc/fsl/imx-pcm-fiq.o:sound/soc/fsl/imx-pcm-fiq.c:334: first defined here
> sound/soc/fsl/imx-pcm-dma.o: In function `cleanup_module':
> sound/soc/fsl/imx-pcm-dma.c:177: multiple definition of `cleanup_module'
> sound/soc/fsl/imx-pcm-fiq.o:sound/soc/fsl/imx-pcm-fiq.c:334: first defined here
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Liam Girdwood <lrg@ti.com>
> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Cc: alsa-devel at alsa-project.org

I sent a fix [1] for that queued by Mark.

Mark,

Is the patch on the way to 3.8-rc?

Shawn

[1] http://thread.gmane.org/gmane.linux.alsa.devel/104434

Re: [PATCH 09/15] media: coda: don't build on multiplatform

[Shawn Guo]

On Mon, Jan 21, 2013 at 05:16:02PM +0000, Arnd Bergmann wrote:
> The coda video codec driver depends on a mach-imx or mach-mxs specific
> header file "mach/iram.h". This is not available when building for
> multiplatform, so let us disable this driver for v3.8 when building
> multiplatform, and hopefully find a proper fix for v3.9.
> 
> drivers/media/platform/coda.c:27:23: fatal error: mach/iram.h: No such file or directory
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Javier Martin <javier.martin@vista-silicon.com>
> Cc: Fabio Estevam <fabio.estevam@freescale.com>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Shawn Guo <shawn.guo@linaro.org>

Acked-by: Shawn Guo <shawn.guo@linaro.org>

> Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
> Cc: linux-media@vger.kernel.org
> ---
>  drivers/media/platform/Kconfig |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index 3dcfea6..049d2b2 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -142,7 +142,7 @@ if V4L_MEM2MEM_DRIVERS
>  
>  config VIDEO_CODA
>  	tristate "Chips&Media Coda multi-standard codec IP"
> -	depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_MXC
> +	depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_MXC && !ARCH_MULTIPLATFORM
>  	select VIDEOBUF2_DMA_CONTIG
>  	select V4L2_MEM2MEM_DEV
>  	select IRAM_ALLOC if SOC_IMX53
> -- 
> 1.7.10.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 09/15] media: coda: don't build on multiplatform

[Shawn Guo]

On Mon, Jan 21, 2013 at 05:16:02PM +0000, Arnd Bergmann wrote:
> The coda video codec driver depends on a mach-imx or mach-mxs specific
> header file "mach/iram.h". This is not available when building for
> multiplatform, so let us disable this driver for v3.8 when building
> multiplatform, and hopefully find a proper fix for v3.9.
> 
> drivers/media/platform/coda.c:27:23: fatal error: mach/iram.h: No such file or directory
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Javier Martin <javier.martin@vista-silicon.com>
> Cc: Fabio Estevam <fabio.estevam@freescale.com>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Shawn Guo <shawn.guo@linaro.org>

Acked-by: Shawn Guo <shawn.guo@linaro.org>

> Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
> Cc: linux-media at vger.kernel.org
> ---
>  drivers/media/platform/Kconfig |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index 3dcfea6..049d2b2 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -142,7 +142,7 @@ if V4L_MEM2MEM_DRIVERS
>  
>  config VIDEO_CODA
>  	tristate "Chips&Media Coda multi-standard codec IP"
> -	depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_MXC
> +	depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_MXC && !ARCH_MULTIPLATFORM
>  	select VIDEOBUF2_DMA_CONTIG
>  	select V4L2_MEM2MEM_DEV
>  	select IRAM_ALLOC if SOC_IMX53
> -- 
> 1.7.10.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist

[Manjunath Goudar]

On 22 January 2013 09:09, Alan Stern <stern@rowland.harvard.edu> wrote:

> On Mon, 21 Jan 2013, Arnd Bergmann wrote:
>
> > Alan, one comment about your version: You keep maintaining the
> > '#if IS_ENABLED' list in the main driver, which I think can actually
> > get removed now.
>
> I considered doing that.  The benefit of keeping it is that it warns
> about configs where the main driver is built but can never be used.
>
> Still, you're right that its purpose is becoming less important.  I had
> planned to remove it when all the glue driver had been converted, but
> in fact it could be removed at any time.
>
> >  Since the base driver can be built independent of
> > the presence of platform glue drivers, there is no need to forbid
> > it any more, and the #if block will cause merge conflicts for each
> > patch that converts or adds another platform.
>
> If the patches are done independently.  There are likely to be some
> context conflicts anyway.
>
> >  I think we can actually
> > get the same results by turning the Kconfig logic around and making
> > the platform glue drivers 'select USB_EHCI_HCD' than depending on
> > it.
>
> That's a good idea.  The Kconfig changes would have to be done
> carefully to make sure that the dependency on USB_ARCH_HAS_EHCI still
> applies to all the platform drivers.
>
> Manjunath, would you like to send a patch to do this?
>
> Alan Stern
>
> Ya sure,could you explain little bit  briefly about the Kconfig changes.

Thanks
MAnjunath Goudar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130122/18a62ca8/attachment-0001.html>

Re: [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist

[Shawn Guo]

On Mon, Jan 21, 2013 at 09:37:42PM +0000, Arnd Bergmann wrote:
> > Arnd, please take a look at
> > 
> >         http://marc.info/?l=linux-usb&m=135843716515529&w=2
> > 
> > I can't test it easily, not being set up for cross compilation.  I'm 
> > waiting to hear from anybody whether it works before submitting it.
> > (There's also a report of memory corruption involving a similar patch 
> > for ehci-omap; it hasn't been tracked down yet.)
> 
> Your patch looks good to me, but it also seems to do some other
> changes that are not required to fix the problem but could wait
> for 3.9 instead. You definitely have my Ack if you are willing
> to take it for 3.8 though.
> 
> Shawn or Sascha should be able to test it.
> 
Alan,

Thanks for the patch.  I just gave it try.  The USB Host port still
works for me with a couple of fixes on your changes integrated (one
for compiling and the other for probing).  So you have my ACK with
the changes below rolled into your patch.

Acked-by: Shawn Guo <shawn.guo@linaro.org>

---8<----

diff --git a/drivers/usb/host/ehci-mxc.c b/drivers/usb/host/ehci-mxc.c
index 177b354..a685945 100644
--- a/drivers/usb/host/ehci-mxc.c
+++ b/drivers/usb/host/ehci-mxc.c
@@ -37,7 +37,7 @@

 #define DRIVER_DESC "Freescale On-Chip EHCI Host driver"

-static const char hcd_name[] = "ehci-mxc";
+static const char hcd_name[] = "mxc-ehci";

 #define ULPI_VIEWPORT_OFFSET   0x170

@@ -48,7 +48,7 @@ struct ehci_mxc_priv {
 static struct hc_driver __read_mostly ehci_mxc_hc_driver;

 static const struct ehci_driver_overrides ehci_mxc_overrides __initdata = {
-       .extra_priv_size =      sizeof(struct ehci_mxc_priv);
+       .extra_priv_size =      sizeof(struct ehci_mxc_priv),
 };

 static int ehci_mxc_drv_probe(struct platform_device *pdev)

[PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist

[Shawn Guo]

On Mon, Jan 21, 2013 at 09:37:42PM +0000, Arnd Bergmann wrote:
> > Arnd, please take a look at
> > 
> >         http://marc.info/?l=linux-usb&m=135843716515529&w=2
> > 
> > I can't test it easily, not being set up for cross compilation.  I'm 
> > waiting to hear from anybody whether it works before submitting it.
> > (There's also a report of memory corruption involving a similar patch 
> > for ehci-omap; it hasn't been tracked down yet.)
> 
> Your patch looks good to me, but it also seems to do some other
> changes that are not required to fix the problem but could wait
> for 3.9 instead. You definitely have my Ack if you are willing
> to take it for 3.8 though.
> 
> Shawn or Sascha should be able to test it.
> 
Alan,

Thanks for the patch.  I just gave it try.  The USB Host port still
works for me with a couple of fixes on your changes integrated (one
for compiling and the other for probing).  So you have my ACK with
the changes below rolled into your patch.

Acked-by: Shawn Guo <shawn.guo@linaro.org>

---8<----

diff --git a/drivers/usb/host/ehci-mxc.c b/drivers/usb/host/ehci-mxc.c
index 177b354..a685945 100644
--- a/drivers/usb/host/ehci-mxc.c
+++ b/drivers/usb/host/ehci-mxc.c
@@ -37,7 +37,7 @@

 #define DRIVER_DESC "Freescale On-Chip EHCI Host driver"

-static const char hcd_name[] = "ehci-mxc";
+static const char hcd_name[] = "mxc-ehci";

 #define ULPI_VIEWPORT_OFFSET   0x170

@@ -48,7 +48,7 @@ struct ehci_mxc_priv {
 static struct hc_driver __read_mostly ehci_mxc_hc_driver;

 static const struct ehci_driver_overrides ehci_mxc_overrides __initdata = {
-       .extra_priv_size =      sizeof(struct ehci_mxc_priv);
+       .extra_priv_size =      sizeof(struct ehci_mxc_priv),
 };

 static int ehci_mxc_drv_probe(struct platform_device *pdev)

Re: [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist

[Shawn Guo]

On Tue, Jan 22, 2013 at 02:11:18PM +0800, Shawn Guo wrote:
> Alan,
> 
> Thanks for the patch.  I just gave it try.  The USB Host port still
> works for me with a couple of fixes on your changes integrated (one
> for compiling and the other for probing).  So you have my ACK with
> the changes below rolled into your patch.
> 
> Acked-by: Shawn Guo <shawn.guo@linaro.org>
> 
Sorry.  I meant a Test tag.

Tested-by: Shawn Guo <shawn.guo@linaro.org>

[PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist

[Shawn Guo]

On Tue, Jan 22, 2013 at 02:11:18PM +0800, Shawn Guo wrote:
> Alan,
> 
> Thanks for the patch.  I just gave it try.  The USB Host port still
> works for me with a couple of fixes on your changes integrated (one
> for compiling and the other for probing).  So you have my ACK with
> the changes below rolled into your patch.
> 
> Acked-by: Shawn Guo <shawn.guo@linaro.org>
> 
Sorry.  I meant a Test tag.

Tested-by: Shawn Guo <shawn.guo@linaro.org>

Re: [PATCH 05/15] ASoC: fsl: fiq and dma cannot both be modules

[Mark Brown]

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

On Tue, Jan 22, 2013 at 11:50:30AM +0800, Shawn Guo wrote:
> On Mon, Jan 21, 2013 at 05:15:58PM +0000, Arnd Bergmann wrote:

> > Without this patch, we cannot build the ARM 'allmodconfig', or
> > we get this error:

> > sound/soc/fsl/imx-pcm-dma.o: In function `init_module':
> > sound/soc/fsl/imx-pcm-dma.c:177: multiple definition of `init_module'
> > sound/soc/fsl/imx-pcm-fiq.o:sound/soc/fsl/imx-pcm-fiq.c:334: first defined here
> > sound/soc/fsl/imx-pcm-dma.o: In function `cleanup_module':
> > sound/soc/fsl/imx-pcm-dma.c:177: multiple definition of `cleanup_module'
> > sound/soc/fsl/imx-pcm-fiq.o:sound/soc/fsl/imx-pcm-fiq.c:334: first defined here

> I sent a fix [1] for that queued by Mark.

> Mark,

> Is the patch on the way to 3.8-rc?

Yes, should be.

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

[PATCH 05/15] ASoC: fsl: fiq and dma cannot both be modules

[Mark Brown]

On Tue, Jan 22, 2013 at 11:50:30AM +0800, Shawn Guo wrote:
> On Mon, Jan 21, 2013 at 05:15:58PM +0000, Arnd Bergmann wrote:

> > Without this patch, we cannot build the ARM 'allmodconfig', or
> > we get this error:

> > sound/soc/fsl/imx-pcm-dma.o: In function `init_module':
> > sound/soc/fsl/imx-pcm-dma.c:177: multiple definition of `init_module'
> > sound/soc/fsl/imx-pcm-fiq.o:sound/soc/fsl/imx-pcm-fiq.c:334: first defined here
> > sound/soc/fsl/imx-pcm-dma.o: In function `cleanup_module':
> > sound/soc/fsl/imx-pcm-dma.c:177: multiple definition of `cleanup_module'
> > sound/soc/fsl/imx-pcm-fiq.o:sound/soc/fsl/imx-pcm-fiq.c:334: first defined here

> I sent a fix [1] for that queued by Mark.

> Mark,

> Is the patch on the way to 3.8-rc?

Yes, should be.
-------------- 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/20130122/831a9df6/attachment.sig>

Re: [PATCH 05/15] ASoC: fsl: fiq and dma cannot both be modules

[Arnd Bergmann]

On Tuesday 22 January 2013, Mark Brown wrote:
> On Tue, Jan 22, 2013 at 11:50:30AM +0800, Shawn Guo wrote:
> > I sent a fix [1] for that queued by Mark.

Right, that patch looks good, too.

> > Is the patch on the way to 3.8-rc?
> 
> Yes, should be.

Ok, thanks!

	Arnd

[PATCH 05/15] ASoC: fsl: fiq and dma cannot both be modules

[Arnd Bergmann]

On Tuesday 22 January 2013, Mark Brown wrote:
> On Tue, Jan 22, 2013 at 11:50:30AM +0800, Shawn Guo wrote:
> > I sent a fix [1] for that queued by Mark.

Right, that patch looks good, too.

> > Is the patch on the way to 3.8-rc?
> 
> Yes, should be.

Ok, thanks!

	Arnd

Re: [PATCH 09/15] media: coda: don't build on multiplatform

[Sascha Hauer]

On Mon, Jan 21, 2013 at 05:16:02PM +0000, Arnd Bergmann wrote:
> The coda video codec driver depends on a mach-imx or mach-mxs specific
> header file "mach/iram.h". This is not available when building for
> multiplatform, so let us disable this driver for v3.8 when building
> multiplatform, and hopefully find a proper fix for v3.9.
> 
> drivers/media/platform/coda.c:27:23: fatal error: mach/iram.h: No such file or directory

I just sent a pull request for this with a proper fix.

> 
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index 3dcfea6..049d2b2 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -142,7 +142,7 @@ if V4L_MEM2MEM_DRIVERS
>  
>  config VIDEO_CODA
>  	tristate "Chips&Media Coda multi-standard codec IP"
> -	depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_MXC
> +	depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_MXC && !ARCH_MULTIPLATFORM

This breakage is not multiplatform related at all, it won't compile
without multiplatform support either. So depends on BROKEN would be
more appropriate if you want to go this way.

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH 09/15] media: coda: don't build on multiplatform

[Sascha Hauer]

On Mon, Jan 21, 2013 at 05:16:02PM +0000, Arnd Bergmann wrote:
> The coda video codec driver depends on a mach-imx or mach-mxs specific
> header file "mach/iram.h". This is not available when building for
> multiplatform, so let us disable this driver for v3.8 when building
> multiplatform, and hopefully find a proper fix for v3.9.
> 
> drivers/media/platform/coda.c:27:23: fatal error: mach/iram.h: No such file or directory

I just sent a pull request for this with a proper fix.

> 
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index 3dcfea6..049d2b2 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -142,7 +142,7 @@ if V4L_MEM2MEM_DRIVERS
>  
>  config VIDEO_CODA
>  	tristate "Chips&Media Coda multi-standard codec IP"
> -	depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_MXC
> +	depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_MXC && !ARCH_MULTIPLATFORM

This breakage is not multiplatform related at all, it won't compile
without multiplatform support either. So depends on BROKEN would be
more appropriate if you want to go this way.

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH 06/15] clk: export __clk_get_name

[Fabio Estevam]

On Mon, Jan 21, 2013 at 3:15 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> The __clk_get_name is used by drivers that provide their
> own clocks, which have traditionally all been built-in.
> The new imx drm driver however provides clocks but can
> be built as a module, so we need to export __clk_get_name.
>
> While this is only a staging driver, it's likely that
> there will be others like it in the future.
>
> Without this patch, building ARM allmodconfig results in:
>
> ERROR: "__clk_get_name" [drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.ko] undefined!
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Mike Turquette <mturquette@linaro.org>

A fix from Niels de Vos has already been applied into clk-next:
https://patchwork.kernel.org/patch/1871981/

[PATCH 06/15] clk: export __clk_get_name

[Fabio Estevam]

On Mon, Jan 21, 2013 at 3:15 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> The __clk_get_name is used by drivers that provide their
> own clocks, which have traditionally all been built-in.
> The new imx drm driver however provides clocks but can
> be built as a module, so we need to export __clk_get_name.
>
> While this is only a staging driver, it's likely that
> there will be others like it in the future.
>
> Without this patch, building ARM allmodconfig results in:
>
> ERROR: "__clk_get_name" [drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.ko] undefined!
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Mike Turquette <mturquette@linaro.org>

A fix from Niels de Vos has already been applied into clk-next:
https://patchwork.kernel.org/patch/1871981/

Re: [PATCH 09/15] media: coda: don't build on multiplatform

[Mauro Carvalho Chehab]

Em Tue, 22 Jan 2013 11:54:04 +0800
Shawn Guo <shawn.guo@linaro.org> escreveu:

> On Mon, Jan 21, 2013 at 05:16:02PM +0000, Arnd Bergmann wrote:
> > The coda video codec driver depends on a mach-imx or mach-mxs specific
> > header file "mach/iram.h". This is not available when building for
> > multiplatform, so let us disable this driver for v3.8 when building
> > multiplatform, and hopefully find a proper fix for v3.9.
> > 
> > drivers/media/platform/coda.c:27:23: fatal error: mach/iram.h: No such file or directory
> > 
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Javier Martin <javier.martin@vista-silicon.com>
> > Cc: Fabio Estevam <fabio.estevam@freescale.com>
> > Cc: Sascha Hauer <kernel@pengutronix.de>
> > Cc: Shawn Guo <shawn.guo@linaro.org>
> 
> Acked-by: Shawn Guo <shawn.guo@linaro.org>
> 
> > Cc: Mauro Carvalho Chehab <mchehab@redhat.com>

Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>

> > Cc: linux-media@vger.kernel.org
> > ---
> >  drivers/media/platform/Kconfig |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> > index 3dcfea6..049d2b2 100644
> > --- a/drivers/media/platform/Kconfig
> > +++ b/drivers/media/platform/Kconfig
> > @@ -142,7 +142,7 @@ if V4L_MEM2MEM_DRIVERS
> >  
> >  config VIDEO_CODA
> >  	tristate "Chips&Media Coda multi-standard codec IP"
> > -	depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_MXC
> > +	depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_MXC && !ARCH_MULTIPLATFORM
> >  	select VIDEOBUF2_DMA_CONTIG
> >  	select V4L2_MEM2MEM_DEV
> >  	select IRAM_ALLOC if SOC_IMX53
> > -- 
> > 1.7.10.4
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> 


-- 

Cheers,
Mauro

[PATCH 09/15] media: coda: don't build on multiplatform

[Mauro Carvalho Chehab]

Em Tue, 22 Jan 2013 11:54:04 +0800
Shawn Guo <shawn.guo@linaro.org> escreveu:

> On Mon, Jan 21, 2013 at 05:16:02PM +0000, Arnd Bergmann wrote:
> > The coda video codec driver depends on a mach-imx or mach-mxs specific
> > header file "mach/iram.h". This is not available when building for
> > multiplatform, so let us disable this driver for v3.8 when building
> > multiplatform, and hopefully find a proper fix for v3.9.
> > 
> > drivers/media/platform/coda.c:27:23: fatal error: mach/iram.h: No such file or directory
> > 
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Javier Martin <javier.martin@vista-silicon.com>
> > Cc: Fabio Estevam <fabio.estevam@freescale.com>
> > Cc: Sascha Hauer <kernel@pengutronix.de>
> > Cc: Shawn Guo <shawn.guo@linaro.org>
> 
> Acked-by: Shawn Guo <shawn.guo@linaro.org>
> 
> > Cc: Mauro Carvalho Chehab <mchehab@redhat.com>

Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>

> > Cc: linux-media at vger.kernel.org
> > ---
> >  drivers/media/platform/Kconfig |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> > index 3dcfea6..049d2b2 100644
> > --- a/drivers/media/platform/Kconfig
> > +++ b/drivers/media/platform/Kconfig
> > @@ -142,7 +142,7 @@ if V4L_MEM2MEM_DRIVERS
> >  
> >  config VIDEO_CODA
> >  	tristate "Chips&Media Coda multi-standard codec IP"
> > -	depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_MXC
> > +	depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_MXC && !ARCH_MULTIPLATFORM
> >  	select VIDEOBUF2_DMA_CONTIG
> >  	select V4L2_MEM2MEM_DEV
> >  	select IRAM_ALLOC if SOC_IMX53
> > -- 
> > 1.7.10.4
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> 


-- 

Cheers,
Mauro

Re: [PATCH 09/15] media: coda: don't build on multiplatform

[Mauro Carvalho Chehab]

Em Tue, 22 Jan 2013 10:32:22 -0200
Mauro Carvalho Chehab <mchehab@redhat.com> escreveu:

> Em Tue, 22 Jan 2013 11:54:04 +0800
> Shawn Guo <shawn.guo@linaro.org> escreveu:
> 
> > On Mon, Jan 21, 2013 at 05:16:02PM +0000, Arnd Bergmann wrote:
> > > The coda video codec driver depends on a mach-imx or mach-mxs specific
> > > header file "mach/iram.h". This is not available when building for
> > > multiplatform, so let us disable this driver for v3.8 when building
> > > multiplatform, and hopefully find a proper fix for v3.9.
> > > 
> > > drivers/media/platform/coda.c:27:23: fatal error: mach/iram.h: No such file or directory
> > > 
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > Cc: Javier Martin <javier.martin@vista-silicon.com>
> > > Cc: Fabio Estevam <fabio.estevam@freescale.com>
> > > Cc: Sascha Hauer <kernel@pengutronix.de>
> > > Cc: Shawn Guo <shawn.guo@linaro.org>
> > 
> > Acked-by: Shawn Guo <shawn.guo@linaro.org>
> > 
> > > Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
> 
> Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>

Err... actually, as Sascha has a proper fix for it, it should be used,
instead. So:

Nacked-by: Mauro Carvalho Chehab <mchehab@redhat.com>

Regards,
Mauro

[PATCH 09/15] media: coda: don't build on multiplatform

[Mauro Carvalho Chehab]

Em Tue, 22 Jan 2013 10:32:22 -0200
Mauro Carvalho Chehab <mchehab@redhat.com> escreveu:

> Em Tue, 22 Jan 2013 11:54:04 +0800
> Shawn Guo <shawn.guo@linaro.org> escreveu:
> 
> > On Mon, Jan 21, 2013 at 05:16:02PM +0000, Arnd Bergmann wrote:
> > > The coda video codec driver depends on a mach-imx or mach-mxs specific
> > > header file "mach/iram.h". This is not available when building for
> > > multiplatform, so let us disable this driver for v3.8 when building
> > > multiplatform, and hopefully find a proper fix for v3.9.
> > > 
> > > drivers/media/platform/coda.c:27:23: fatal error: mach/iram.h: No such file or directory
> > > 
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > Cc: Javier Martin <javier.martin@vista-silicon.com>
> > > Cc: Fabio Estevam <fabio.estevam@freescale.com>
> > > Cc: Sascha Hauer <kernel@pengutronix.de>
> > > Cc: Shawn Guo <shawn.guo@linaro.org>
> > 
> > Acked-by: Shawn Guo <shawn.guo@linaro.org>
> > 
> > > Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
> 
> Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>

Err... actually, as Sascha has a proper fix for it, it should be used,
instead. So:

Nacked-by: Mauro Carvalho Chehab <mchehab@redhat.com>

Regards,
Mauro

Re: [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist

[Alan Stern]

On Tue, 22 Jan 2013, Manjunath Goudar wrote:

> > >  I think we can actually
> > > get the same results by turning the Kconfig logic around and making
> > > the platform glue drivers 'select USB_EHCI_HCD' than depending on
> > > it.
> >
> > That's a good idea.  The Kconfig changes would have to be done
> > carefully to make sure that the dependency on USB_ARCH_HAS_EHCI still
> > applies to all the platform drivers.
> >
> > Manjunath, would you like to send a patch to do this?
> >
> > Alan Stern
> >
> > Ya sure,could you explain little bit  briefly about the Kconfig changes.

Suppose you do exactly what Arnd proposed: add "select USB_EHCI_HCD" to
the Kconfig entries for each of the platform glue drivers.  Then
consider what would happen in a build where USB_ARCH_HAS_EHCI is "n"
but one of those glue drivers is enabled.  There would be conflicting
requirements on USB_EHCI_HCD: The new "select" would force it to be on,
but the existing "depends on USB && USB_ARCH_HAS_EHCI" would force it
to be off.  The build would fail.

In order to prevent this, you have to make sure that each glue driver
depends on USB_ARCH_HAS_EHCI.  A simple way to do this is to surround
the Kconfig entries for those drivers with "if USB && 
USB_ARCH_HAS_EHCI" ... "endif".

Come to think of it, the "if USB" part really should protect the entire 
file.

Alan Stern

[PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist

[Alan Stern]

On Tue, 22 Jan 2013, Manjunath Goudar wrote:

> > >  I think we can actually
> > > get the same results by turning the Kconfig logic around and making
> > > the platform glue drivers 'select USB_EHCI_HCD' than depending on
> > > it.
> >
> > That's a good idea.  The Kconfig changes would have to be done
> > carefully to make sure that the dependency on USB_ARCH_HAS_EHCI still
> > applies to all the platform drivers.
> >
> > Manjunath, would you like to send a patch to do this?
> >
> > Alan Stern
> >
> > Ya sure,could you explain little bit  briefly about the Kconfig changes.

Suppose you do exactly what Arnd proposed: add "select USB_EHCI_HCD" to
the Kconfig entries for each of the platform glue drivers.  Then
consider what would happen in a build where USB_ARCH_HAS_EHCI is "n"
but one of those glue drivers is enabled.  There would be conflicting
requirements on USB_EHCI_HCD: The new "select" would force it to be on,
but the existing "depends on USB && USB_ARCH_HAS_EHCI" would force it
to be off.  The build would fail.

In order to prevent this, you have to make sure that each glue driver
depends on USB_ARCH_HAS_EHCI.  A simple way to do this is to surround
the Kconfig entries for those drivers with "if USB && 
USB_ARCH_HAS_EHCI" ... "endif".

Come to think of it, the "if USB" part really should protect the entire 
file.

Alan Stern

Re: [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist

[Alan Stern]

On Tue, 22 Jan 2013, Shawn Guo wrote:

> On Mon, Jan 21, 2013 at 09:37:42PM +0000, Arnd Bergmann wrote:
> > > Arnd, please take a look at
> > > 
> > >         http://marc.info/?l=linux-usb&m=135843716515529&w=2
> > > 
> > > I can't test it easily, not being set up for cross compilation.  I'm 
> > > waiting to hear from anybody whether it works before submitting it.
> > > (There's also a report of memory corruption involving a similar patch 
> > > for ehci-omap; it hasn't been tracked down yet.)
> > 
> > Your patch looks good to me, but it also seems to do some other
> > changes that are not required to fix the problem but could wait
> > for 3.9 instead. You definitely have my Ack if you are willing
> > to take it for 3.8 though.

I think it's not too late to submit this for 3.8.  Thanks for the Ack.

> > Shawn or Sascha should be able to test it.
> > 
> Alan,
> 
> Thanks for the patch.  I just gave it try.  The USB Host port still
> works for me with a couple of fixes on your changes integrated (one
> for compiling and the other for probing).  So you have my ACK with
> the changes below rolled into your patch.

Right, I have merged your changes into the patch.  Will submit shortly.

Alan Stern

[PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist

[Alan Stern]

On Tue, 22 Jan 2013, Shawn Guo wrote:

> On Mon, Jan 21, 2013 at 09:37:42PM +0000, Arnd Bergmann wrote:
> > > Arnd, please take a look at
> > > 
> > >         http://marc.info/?l=linux-usb&m=135843716515529&w=2
> > > 
> > > I can't test it easily, not being set up for cross compilation.  I'm 
> > > waiting to hear from anybody whether it works before submitting it.
> > > (There's also a report of memory corruption involving a similar patch 
> > > for ehci-omap; it hasn't been tracked down yet.)
> > 
> > Your patch looks good to me, but it also seems to do some other
> > changes that are not required to fix the problem but could wait
> > for 3.9 instead. You definitely have my Ack if you are willing
> > to take it for 3.8 though.

I think it's not too late to submit this for 3.8.  Thanks for the Ack.

> > Shawn or Sascha should be able to test it.
> > 
> Alan,
> 
> Thanks for the patch.  I just gave it try.  The USB Host port still
> works for me with a couple of fixes on your changes integrated (one
> for compiling and the other for probing).  So you have my ACK with
> the changes below rolled into your patch.

Right, I have merged your changes into the patch.  Will submit shortly.

Alan Stern

Re: [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist

[Arnd Bergmann]

On Tuesday 22 January 2013, Alan Stern wrote:
> In order to prevent this, you have to make sure that each glue driver
> depends on USB_ARCH_HAS_EHCI.  A simple way to do this is to surround
> the Kconfig entries for those drivers with "if USB && 
> USB_ARCH_HAS_EHCI" ... "endif".

I was actually thinking we could remove the use of USB_ARCH_HAS_EHCI
as well once we have inverted the logic for selecting USB_EHCI_HCD,
but there is another problem with that, because then we still need
something to select USB_ARCH_HAS_HCD, or kill that symbol as well.

	Arnd

[PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist

[Arnd Bergmann]

On Tuesday 22 January 2013, Alan Stern wrote:
> In order to prevent this, you have to make sure that each glue driver
> depends on USB_ARCH_HAS_EHCI.  A simple way to do this is to surround
> the Kconfig entries for those drivers with "if USB && 
> USB_ARCH_HAS_EHCI" ... "endif".

I was actually thinking we could remove the use of USB_ARCH_HAS_EHCI
as well once we have inverted the logic for selecting USB_EHCI_HCD,
but there is another problem with that, because then we still need
something to select USB_ARCH_HAS_HCD, or kill that symbol as well.

	Arnd

Re: [PATCH 09/15] media: coda: don't build on multiplatform

[Arnd Bergmann]

On Tuesday 22 January 2013, Sascha Hauer wrote:
> On Mon, Jan 21, 2013 at 05:16:02PM +0000, Arnd Bergmann wrote:
> > The coda video codec driver depends on a mach-imx or mach-mxs specific
> > header file "mach/iram.h". This is not available when building for
> > multiplatform, so let us disable this driver for v3.8 when building
> > multiplatform, and hopefully find a proper fix for v3.9.
> > 
> > drivers/media/platform/coda.c:27:23: fatal error: mach/iram.h: No such file or directory
> 
> I just sent a pull request for this with a proper fix.

Ok, even better. Thanks for taking care of it!

	Arnd

[PATCH 09/15] media: coda: don't build on multiplatform

[Arnd Bergmann]

On Tuesday 22 January 2013, Sascha Hauer wrote:
> On Mon, Jan 21, 2013 at 05:16:02PM +0000, Arnd Bergmann wrote:
> > The coda video codec driver depends on a mach-imx or mach-mxs specific
> > header file "mach/iram.h". This is not available when building for
> > multiplatform, so let us disable this driver for v3.8 when building
> > multiplatform, and hopefully find a proper fix for v3.9.
> > 
> > drivers/media/platform/coda.c:27:23: fatal error: mach/iram.h: No such file or directory
> 
> I just sent a pull request for this with a proper fix.

Ok, even better. Thanks for taking care of it!

	Arnd

Re: [PATCH 06/15] clk: export __clk_get_name

[Arnd Bergmann]

On Tuesday 22 January 2013, Fabio Estevam wrote:
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Sascha Hauer <s.hauer@pengutronix.de>
> > Cc: Mike Turquette <mturquette@linaro.org>
> 
> A fix from Niels de Vos has already been applied into clk-next:
> https://patchwork.kernel.org/patch/1871981/

Ok, very good. Mike, I saw that the patch is over
a month old. Any reason it hasn't made it into v3.8.rc yet?

	Arnd

[PATCH 06/15] clk: export __clk_get_name

[Arnd Bergmann]

On Tuesday 22 January 2013, Fabio Estevam wrote:
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Sascha Hauer <s.hauer@pengutronix.de>
> > Cc: Mike Turquette <mturquette@linaro.org>
> 
> A fix from Niels de Vos has already been applied into clk-next:
> https://patchwork.kernel.org/patch/1871981/

Ok, very good. Mike, I saw that the patch is over
a month old. Any reason it hasn't made it into v3.8.rc yet?

	Arnd

Re: [PATCH 15/15] staging/omapdrm: don't build on multiplatform

[Greg Kroah-Hartman]

On Mon, Jan 21, 2013 at 12:39:31PM -0600, Rob Clark wrote:
> On 01/21/2013 11:41 AM, Arnd Bergmann wrote:
> >On Monday 21 January 2013, Rob Clark wrote:
> >>Are you sure OMAP2_DSS requires ARCH_OMAP2PLUS?  I don't see this, and
> >>it at least used to not depend on ARCH_OMAP2PLUS.  If it does now, I
> >>think the correct fix would be to remove the dependency in OMAP2_DSS.  I
> >>don't think removing ARCH_MULTIPLATFORM support in omapdrm is the
> >>correct solution.
> >At least it says so in drivers/video/omap2/Kconfig, which contains
> >
> >if ARCH_OMAP2PLUS
> >source drivers/video/omap2/dss/Kconfig
> >endif
> 
> ahh, ok, I see.. the if ARCH_OMAP2PLUS bit looks like it came in
> recently (770b6cb)
> 
> what about changing this to 'if ARCH_OMAP2PLUS || ARCH_MULTIPLATFORM'?

That's what Arnd's patch did.

totally confused,

greg k-h

[PATCH 15/15] staging/omapdrm: don't build on multiplatform

[Greg Kroah-Hartman]

On Mon, Jan 21, 2013 at 12:39:31PM -0600, Rob Clark wrote:
> On 01/21/2013 11:41 AM, Arnd Bergmann wrote:
> >On Monday 21 January 2013, Rob Clark wrote:
> >>Are you sure OMAP2_DSS requires ARCH_OMAP2PLUS?  I don't see this, and
> >>it at least used to not depend on ARCH_OMAP2PLUS.  If it does now, I
> >>think the correct fix would be to remove the dependency in OMAP2_DSS.  I
> >>don't think removing ARCH_MULTIPLATFORM support in omapdrm is the
> >>correct solution.
> >At least it says so in drivers/video/omap2/Kconfig, which contains
> >
> >if ARCH_OMAP2PLUS
> >source drivers/video/omap2/dss/Kconfig
> >endif
> 
> ahh, ok, I see.. the if ARCH_OMAP2PLUS bit looks like it came in
> recently (770b6cb)
> 
> what about changing this to 'if ARCH_OMAP2PLUS || ARCH_MULTIPLATFORM'?

That's what Arnd's patch did.

totally confused,

greg k-h

Re: [PATCH 15/15] staging/omapdrm: don't build on multiplatform

[Rob Clark]

On 01/22/2013 10:53 AM, Greg Kroah-Hartman wrote:
> On Mon, Jan 21, 2013 at 12:39:31PM -0600, Rob Clark wrote:
>> On 01/21/2013 11:41 AM, Arnd Bergmann wrote:
>>> On Monday 21 January 2013, Rob Clark wrote:
>>>> Are you sure OMAP2_DSS requires ARCH_OMAP2PLUS?  I don't see this, and
>>>> it at least used to not depend on ARCH_OMAP2PLUS.  If it does now, I
>>>> think the correct fix would be to remove the dependency in OMAP2_DSS.  I
>>>> don't think removing ARCH_MULTIPLATFORM support in omapdrm is the
>>>> correct solution.
>>> At least it says so in drivers/video/omap2/Kconfig, which contains
>>>
>>> if ARCH_OMAP2PLUS
>>> source drivers/video/omap2/dss/Kconfig
>>> endif
>> ahh, ok, I see.. the if ARCH_OMAP2PLUS bit looks like it came in
>> recently (770b6cb)
>>
>> what about changing this to 'if ARCH_OMAP2PLUS || ARCH_MULTIPLATFORM'?
> That's what Arnd's patch did.

sorry, I was talking about in drivers/video/omap2/Kconfig

Ie. I'd prefer to re-enable omapdss on multi-plat rather than disabling 
omapdrm.  With changes in drm core, it is a bit of a pain to compile 
test all the arm drivers by doing N different builds, so we've been 
trying to get to the point of all arm drm drivers supporting multi-plat

BR,
-R

> totally confused,
>
> greg k-h

[PATCH 15/15] staging/omapdrm: don't build on multiplatform

[Rob Clark]

On 01/22/2013 10:53 AM, Greg Kroah-Hartman wrote:
> On Mon, Jan 21, 2013 at 12:39:31PM -0600, Rob Clark wrote:
>> On 01/21/2013 11:41 AM, Arnd Bergmann wrote:
>>> On Monday 21 January 2013, Rob Clark wrote:
>>>> Are you sure OMAP2_DSS requires ARCH_OMAP2PLUS?  I don't see this, and
>>>> it at least used to not depend on ARCH_OMAP2PLUS.  If it does now, I
>>>> think the correct fix would be to remove the dependency in OMAP2_DSS.  I
>>>> don't think removing ARCH_MULTIPLATFORM support in omapdrm is the
>>>> correct solution.
>>> At least it says so in drivers/video/omap2/Kconfig, which contains
>>>
>>> if ARCH_OMAP2PLUS
>>> source drivers/video/omap2/dss/Kconfig
>>> endif
>> ahh, ok, I see.. the if ARCH_OMAP2PLUS bit looks like it came in
>> recently (770b6cb)
>>
>> what about changing this to 'if ARCH_OMAP2PLUS || ARCH_MULTIPLATFORM'?
> That's what Arnd's patch did.

sorry, I was talking about in drivers/video/omap2/Kconfig

Ie. I'd prefer to re-enable omapdss on multi-plat rather than disabling 
omapdrm.  With changes in drm core, it is a bit of a pain to compile 
test all the arm drivers by doing N different builds, so we've been 
trying to get to the point of all arm drm drivers supporting multi-plat

BR,
-R

> totally confused,
>
> greg k-h

Re: [PATCH 15/15] staging/omapdrm: don't build on multiplatform

[Greg Kroah-Hartman]

On Tue, Jan 22, 2013 at 10:57:44AM -0600, Rob Clark wrote:
> On 01/22/2013 10:53 AM, Greg Kroah-Hartman wrote:
> >On Mon, Jan 21, 2013 at 12:39:31PM -0600, Rob Clark wrote:
> >>On 01/21/2013 11:41 AM, Arnd Bergmann wrote:
> >>>On Monday 21 January 2013, Rob Clark wrote:
> >>>>Are you sure OMAP2_DSS requires ARCH_OMAP2PLUS?  I don't see this, and
> >>>>it at least used to not depend on ARCH_OMAP2PLUS.  If it does now, I
> >>>>think the correct fix would be to remove the dependency in OMAP2_DSS.  I
> >>>>don't think removing ARCH_MULTIPLATFORM support in omapdrm is the
> >>>>correct solution.
> >>>At least it says so in drivers/video/omap2/Kconfig, which contains
> >>>
> >>>if ARCH_OMAP2PLUS
> >>>source drivers/video/omap2/dss/Kconfig
> >>>endif
> >>ahh, ok, I see.. the if ARCH_OMAP2PLUS bit looks like it came in
> >>recently (770b6cb)
> >>
> >>what about changing this to 'if ARCH_OMAP2PLUS || ARCH_MULTIPLATFORM'?
> >That's what Arnd's patch did.
> 
> sorry, I was talking about in drivers/video/omap2/Kconfig

Ah, ok.

> Ie. I'd prefer to re-enable omapdss on multi-plat rather than
> disabling omapdrm.  With changes in drm core, it is a bit of a pain
> to compile test all the arm drivers by doing N different builds, so
> we've been trying to get to the point of all arm drm drivers
> supporting multi-plat

Ok, I'll let you and Arnd fight it out and drop this patch from my
to-apply queue for now...

greg k-h

[PATCH 15/15] staging/omapdrm: don't build on multiplatform

[Greg Kroah-Hartman]

On Tue, Jan 22, 2013 at 10:57:44AM -0600, Rob Clark wrote:
> On 01/22/2013 10:53 AM, Greg Kroah-Hartman wrote:
> >On Mon, Jan 21, 2013 at 12:39:31PM -0600, Rob Clark wrote:
> >>On 01/21/2013 11:41 AM, Arnd Bergmann wrote:
> >>>On Monday 21 January 2013, Rob Clark wrote:
> >>>>Are you sure OMAP2_DSS requires ARCH_OMAP2PLUS?  I don't see this, and
> >>>>it at least used to not depend on ARCH_OMAP2PLUS.  If it does now, I
> >>>>think the correct fix would be to remove the dependency in OMAP2_DSS.  I
> >>>>don't think removing ARCH_MULTIPLATFORM support in omapdrm is the
> >>>>correct solution.
> >>>At least it says so in drivers/video/omap2/Kconfig, which contains
> >>>
> >>>if ARCH_OMAP2PLUS
> >>>source drivers/video/omap2/dss/Kconfig
> >>>endif
> >>ahh, ok, I see.. the if ARCH_OMAP2PLUS bit looks like it came in
> >>recently (770b6cb)
> >>
> >>what about changing this to 'if ARCH_OMAP2PLUS || ARCH_MULTIPLATFORM'?
> >That's what Arnd's patch did.
> 
> sorry, I was talking about in drivers/video/omap2/Kconfig

Ah, ok.

> Ie. I'd prefer to re-enable omapdss on multi-plat rather than
> disabling omapdrm.  With changes in drm core, it is a bit of a pain
> to compile test all the arm drivers by doing N different builds, so
> we've been trying to get to the point of all arm drm drivers
> supporting multi-plat

Ok, I'll let you and Arnd fight it out and drop this patch from my
to-apply queue for now...

greg k-h

Re: [PATCH 15/15] staging/omapdrm: don't build on multiplatform

[Arnd Bergmann]

On Tuesday 22 January 2013, Greg Kroah-Hartman wrote:
> > Ie. I'd prefer to re-enable omapdss on multi-plat rather than
> > disabling omapdrm.  With changes in drm core, it is a bit of a pain
> > to compile test all the arm drivers by doing N different builds, so
> > we've been trying to get to the point of all arm drm drivers
> > supporting multi-plat
> 
> Ok, I'll let you and Arnd fight it out and drop this patch from my
> to-apply queue for now...

If Rob thinks there is no danger in allowing omap2_dss to be built
on all platforms, and Tomi has no objections, I'm fine with that, too.
In general, that is the right solution, I was just trying to be
conservative for the 3.8 cycle.

	Arnd

[PATCH 15/15] staging/omapdrm: don't build on multiplatform

[Arnd Bergmann]

On Tuesday 22 January 2013, Greg Kroah-Hartman wrote:
> > Ie. I'd prefer to re-enable omapdss on multi-plat rather than
> > disabling omapdrm.  With changes in drm core, it is a bit of a pain
> > to compile test all the arm drivers by doing N different builds, so
> > we've been trying to get to the point of all arm drm drivers
> > supporting multi-plat
> 
> Ok, I'll let you and Arnd fight it out and drop this patch from my
> to-apply queue for now...

If Rob thinks there is no danger in allowing omap2_dss to be built
on all platforms, and Tomi has no objections, I'm fine with that, too.
In general, that is the right solution, I was just trying to be
conservative for the 3.8 cycle.

	Arnd

Re: [PATCH 15/15] staging/omapdrm: don't build on multiplatform

[Rob Clark]

On 01/22/2013 11:47 AM, Arnd Bergmann wrote:
> On Tuesday 22 January 2013, Greg Kroah-Hartman wrote:
>>> Ie. I'd prefer to re-enable omapdss on multi-plat rather than
>>> disabling omapdrm.  With changes in drm core, it is a bit of a pain
>>> to compile test all the arm drivers by doing N different builds, so
>>> we've been trying to get to the point of all arm drm drivers
>>> supporting multi-plat
>> Ok, I'll let you and Arnd fight it out and drop this patch from my
>> to-apply queue for now...
> If Rob thinks there is no danger in allowing omap2_dss to be built
> on all platforms, and Tomi has no objections, I'm fine with that, too.
> In general, that is the right solution, I was just trying to be
> conservative for the 3.8 cycle.

I think it should be safe.. or at least it built fine for multi-plat in 
the recent past and shouldn't really do anything if there is no omapdss 
platform device.

Do you want me to make a patch or are you already doing this?

BR,
-R

> 	Arnd

[PATCH 15/15] staging/omapdrm: don't build on multiplatform

[Rob Clark]

On 01/22/2013 11:47 AM, Arnd Bergmann wrote:
> On Tuesday 22 January 2013, Greg Kroah-Hartman wrote:
>>> Ie. I'd prefer to re-enable omapdss on multi-plat rather than
>>> disabling omapdrm.  With changes in drm core, it is a bit of a pain
>>> to compile test all the arm drivers by doing N different builds, so
>>> we've been trying to get to the point of all arm drm drivers
>>> supporting multi-plat
>> Ok, I'll let you and Arnd fight it out and drop this patch from my
>> to-apply queue for now...
> If Rob thinks there is no danger in allowing omap2_dss to be built
> on all platforms, and Tomi has no objections, I'm fine with that, too.
> In general, that is the right solution, I was just trying to be
> conservative for the 3.8 cycle.

I think it should be safe.. or at least it built fine for multi-plat in 
the recent past and shouldn't really do anything if there is no omapdss 
platform device.

Do you want me to make a patch or are you already doing this?

BR,
-R

> 	Arnd

Re: [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist

[Sascha Hauer]

On Tue, Jan 22, 2013 at 03:38:55PM +0000, Arnd Bergmann wrote:
> On Tuesday 22 January 2013, Alan Stern wrote:
> > In order to prevent this, you have to make sure that each glue driver
> > depends on USB_ARCH_HAS_EHCI.  A simple way to do this is to surround
> > the Kconfig entries for those drivers with "if USB && 
> > USB_ARCH_HAS_EHCI" ... "endif".
> 
> I was actually thinking we could remove the use of USB_ARCH_HAS_EHCI
> as well once we have inverted the logic for selecting USB_EHCI_HCD,
> but there is another problem with that, because then we still need
> something to select USB_ARCH_HAS_HCD, or kill that symbol as well.

+1 for killing it. Such symbols get more and more meaningless anyway
with multiarch kernels-

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist

[Sascha Hauer]

On Tue, Jan 22, 2013 at 03:38:55PM +0000, Arnd Bergmann wrote:
> On Tuesday 22 January 2013, Alan Stern wrote:
> > In order to prevent this, you have to make sure that each glue driver
> > depends on USB_ARCH_HAS_EHCI.  A simple way to do this is to surround
> > the Kconfig entries for those drivers with "if USB && 
> > USB_ARCH_HAS_EHCI" ... "endif".
> 
> I was actually thinking we could remove the use of USB_ARCH_HAS_EHCI
> as well once we have inverted the logic for selecting USB_EHCI_HCD,
> but there is another problem with that, because then we still need
> something to select USB_ARCH_HAS_HCD, or kill that symbol as well.

+1 for killing it. Such symbols get more and more meaningless anyway
with multiarch kernels-

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH 15/15] staging/omapdrm: don't build on multiplatform

[Arnd Bergmann]

On Tuesday 22 January 2013, Rob Clark wrote:
> I think it should be safe.. or at least it built fine for multi-plat in 
> the recent past and shouldn't really do anything if there is no omapdss 
> platform device.
> 
> Do you want me to make a patch or are you already doing this?

Please make one. Feel free to reuse my changeset description if needed.

	Arnd

[PATCH 15/15] staging/omapdrm: don't build on multiplatform

[Arnd Bergmann]

On Tuesday 22 January 2013, Rob Clark wrote:
> I think it should be safe.. or at least it built fine for multi-plat in 
> the recent past and shouldn't really do anything if there is no omapdss 
> platform device.
> 
> Do you want me to make a patch or are you already doing this?

Please make one. Feel free to reuse my changeset description if needed.

	Arnd

Re: [PATCH 14/15] samples/seccomp: be less stupid about cross compiling

[Kees Cook]

On Mon, Jan 21, 2013 at 9:16 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> The seccomp filters are currently built for the build
> host, not for the machine that they are going to run
> on, but they are also built for with the -m32 flag
> if the kernel is built for a 32 bit machine, both
> of which seems rather odd.
>
> It broke allyesconfig on my machine, which is x86-64, but
> building for 32 bit ARM, with this error message:
>
> In file included from /usr/include/stdio.h:28:0,
>                  from samples/seccomp/bpf-fancy.c:15:
> /usr/include/features.h:324:26: fatal error: bits/predefs.h: No such file or directory
>
> because there are no 32 bit libc headers installed on
> this machine. We should really be building all the
> samples for the target machine rather than the build
> host, but since the infrastructure for that appears
> to be missing right now, let's be a little bit smarter
> and not pass the '-m32' flag to the HOSTCC when cross-
> compiling.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: James Morris <james.l.morris@oracle.com>

I'm fine with this. Thanks!

Acked-by: Kees Cook <keescook@chromium.org>

-Kees

> ---
>  samples/seccomp/Makefile |    2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/samples/seccomp/Makefile b/samples/seccomp/Makefile
> index bbbd276..7203e66 100644
> --- a/samples/seccomp/Makefile
> +++ b/samples/seccomp/Makefile
> @@ -19,6 +19,7 @@ bpf-direct-objs := bpf-direct.o
>
>  # Try to match the kernel target.
>  ifndef CONFIG_64BIT
> +ifndef CROSS_COMPILE
>
>  # s390 has -m31 flag to build 31 bit binaries
>  ifndef CONFIG_S390
> @@ -35,6 +36,7 @@ HOSTLOADLIBES_bpf-direct += $(MFLAG)
>  HOSTLOADLIBES_bpf-fancy += $(MFLAG)
>  HOSTLOADLIBES_dropper += $(MFLAG)
>  endif
> +endif
>
>  # Tell kbuild to always build the programs
>  always := $(hostprogs-y)
> --
> 1.7.10.4
>



--
Kees Cook
Chrome OS Security

[PATCH 14/15] samples/seccomp: be less stupid about cross compiling

[Kees Cook]

On Mon, Jan 21, 2013 at 9:16 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> The seccomp filters are currently built for the build
> host, not for the machine that they are going to run
> on, but they are also built for with the -m32 flag
> if the kernel is built for a 32 bit machine, both
> of which seems rather odd.
>
> It broke allyesconfig on my machine, which is x86-64, but
> building for 32 bit ARM, with this error message:
>
> In file included from /usr/include/stdio.h:28:0,
>                  from samples/seccomp/bpf-fancy.c:15:
> /usr/include/features.h:324:26: fatal error: bits/predefs.h: No such file or directory
>
> because there are no 32 bit libc headers installed on
> this machine. We should really be building all the
> samples for the target machine rather than the build
> host, but since the infrastructure for that appears
> to be missing right now, let's be a little bit smarter
> and not pass the '-m32' flag to the HOSTCC when cross-
> compiling.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: James Morris <james.l.morris@oracle.com>

I'm fine with this. Thanks!

Acked-by: Kees Cook <keescook@chromium.org>

-Kees

> ---
>  samples/seccomp/Makefile |    2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/samples/seccomp/Makefile b/samples/seccomp/Makefile
> index bbbd276..7203e66 100644
> --- a/samples/seccomp/Makefile
> +++ b/samples/seccomp/Makefile
> @@ -19,6 +19,7 @@ bpf-direct-objs := bpf-direct.o
>
>  # Try to match the kernel target.
>  ifndef CONFIG_64BIT
> +ifndef CROSS_COMPILE
>
>  # s390 has -m31 flag to build 31 bit binaries
>  ifndef CONFIG_S390
> @@ -35,6 +36,7 @@ HOSTLOADLIBES_bpf-direct += $(MFLAG)
>  HOSTLOADLIBES_bpf-fancy += $(MFLAG)
>  HOSTLOADLIBES_dropper += $(MFLAG)
>  endif
> +endif
>
>  # Tell kbuild to always build the programs
>  always := $(hostprogs-y)
> --
> 1.7.10.4
>



--
Kees Cook
Chrome OS Security

Re: [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist

[Alan Stern]

On Tue, 22 Jan 2013, Sascha Hauer wrote:

> On Tue, Jan 22, 2013 at 03:38:55PM +0000, Arnd Bergmann wrote:
> > On Tuesday 22 January 2013, Alan Stern wrote:
> > > In order to prevent this, you have to make sure that each glue driver
> > > depends on USB_ARCH_HAS_EHCI.  A simple way to do this is to surround
> > > the Kconfig entries for those drivers with "if USB && 
> > > USB_ARCH_HAS_EHCI" ... "endif".
> > 
> > I was actually thinking we could remove the use of USB_ARCH_HAS_EHCI
> > as well once we have inverted the logic for selecting USB_EHCI_HCD,
> > but there is another problem with that, because then we still need
> > something to select USB_ARCH_HAS_HCD, or kill that symbol as well.
> 
> +1 for killing it. Such symbols get more and more meaningless anyway
> with multiarch kernels-

I tend to agree.  Anyway, the symbols are named badly.  _Any_
architecture with HAS_IOMEM can in theory aupport host-side USB.  
Maybe some of the platforms don't, but that has nothing to do with the
CPU's architecture.

Furthermore, even platforms that don't support USB host controllers 
can use things like dummy-hcd and usbip, which provide virtual host 
controllers.

Anybody think these symbols should be retained?

Alan Stern

[PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist

[Alan Stern]

On Tue, 22 Jan 2013, Sascha Hauer wrote:

> On Tue, Jan 22, 2013 at 03:38:55PM +0000, Arnd Bergmann wrote:
> > On Tuesday 22 January 2013, Alan Stern wrote:
> > > In order to prevent this, you have to make sure that each glue driver
> > > depends on USB_ARCH_HAS_EHCI.  A simple way to do this is to surround
> > > the Kconfig entries for those drivers with "if USB && 
> > > USB_ARCH_HAS_EHCI" ... "endif".
> > 
> > I was actually thinking we could remove the use of USB_ARCH_HAS_EHCI
> > as well once we have inverted the logic for selecting USB_EHCI_HCD,
> > but there is another problem with that, because then we still need
> > something to select USB_ARCH_HAS_HCD, or kill that symbol as well.
> 
> +1 for killing it. Such symbols get more and more meaningless anyway
> with multiarch kernels-

I tend to agree.  Anyway, the symbols are named badly.  _Any_
architecture with HAS_IOMEM can in theory aupport host-side USB.  
Maybe some of the platforms don't, but that has nothing to do with the
CPU's architecture.

Furthermore, even platforms that don't support USB host controllers 
can use things like dummy-hcd and usbip, which provide virtual host 
controllers.

Anybody think these symbols should be retained?

Alan Stern

Re: [PATCH 14/15] samples/seccomp: be less stupid about cross compiling

[Will Drewry]

On Tue, Jan 22, 2013 at 3:20 PM, Kees Cook <keescook@chromium.org> wrote:
> On Mon, Jan 21, 2013 at 9:16 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> The seccomp filters are currently built for the build
>> host, not for the machine that they are going to run
>> on, but they are also built for with the -m32 flag
>> if the kernel is built for a 32 bit machine, both
>> of which seems rather odd.
>>
>> It broke allyesconfig on my machine, which is x86-64, but
>> building for 32 bit ARM, with this error message:
>>
>> In file included from /usr/include/stdio.h:28:0,
>>                  from samples/seccomp/bpf-fancy.c:15:
>> /usr/include/features.h:324:26: fatal error: bits/predefs.h: No such file or directory
>>
>> because there are no 32 bit libc headers installed on
>> this machine. We should really be building all the
>> samples for the target machine rather than the build
>> host, but since the infrastructure for that appears
>> to be missing right now, let's be a little bit smarter
>> and not pass the '-m32' flag to the HOSTCC when cross-
>> compiling.
>>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
>> Cc: Kees Cook <keescook@chromium.org>
>> Cc: James Morris <james.l.morris@oracle.com>
>
> I'm fine with this. Thanks!
>
> Acked-by: Kees Cook <keescook@chromium.org>

Thanks! This makes a lot of sense and maybe buys a bit more time to
figure out the best way to build these (all?) samples for the target.

Acked-by: Will Drewry <wad@chromium.org>

>
>> ---
>>  samples/seccomp/Makefile |    2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/samples/seccomp/Makefile b/samples/seccomp/Makefile
>> index bbbd276..7203e66 100644
>> --- a/samples/seccomp/Makefile
>> +++ b/samples/seccomp/Makefile
>> @@ -19,6 +19,7 @@ bpf-direct-objs := bpf-direct.o
>>
>>  # Try to match the kernel target.
>>  ifndef CONFIG_64BIT
>> +ifndef CROSS_COMPILE
>>
>>  # s390 has -m31 flag to build 31 bit binaries
>>  ifndef CONFIG_S390
>> @@ -35,6 +36,7 @@ HOSTLOADLIBES_bpf-direct += $(MFLAG)
>>  HOSTLOADLIBES_bpf-fancy += $(MFLAG)
>>  HOSTLOADLIBES_dropper += $(MFLAG)
>>  endif
>> +endif
>>
>>  # Tell kbuild to always build the programs
>>  always := $(hostprogs-y)
>> --
>> 1.7.10.4
>>
>
>
>
> --
> Kees Cook
> Chrome OS Security

[PATCH 14/15] samples/seccomp: be less stupid about cross compiling

[Will Drewry]

On Tue, Jan 22, 2013 at 3:20 PM, Kees Cook <keescook@chromium.org> wrote:
> On Mon, Jan 21, 2013 at 9:16 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> The seccomp filters are currently built for the build
>> host, not for the machine that they are going to run
>> on, but they are also built for with the -m32 flag
>> if the kernel is built for a 32 bit machine, both
>> of which seems rather odd.
>>
>> It broke allyesconfig on my machine, which is x86-64, but
>> building for 32 bit ARM, with this error message:
>>
>> In file included from /usr/include/stdio.h:28:0,
>>                  from samples/seccomp/bpf-fancy.c:15:
>> /usr/include/features.h:324:26: fatal error: bits/predefs.h: No such file or directory
>>
>> because there are no 32 bit libc headers installed on
>> this machine. We should really be building all the
>> samples for the target machine rather than the build
>> host, but since the infrastructure for that appears
>> to be missing right now, let's be a little bit smarter
>> and not pass the '-m32' flag to the HOSTCC when cross-
>> compiling.
>>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
>> Cc: Kees Cook <keescook@chromium.org>
>> Cc: James Morris <james.l.morris@oracle.com>
>
> I'm fine with this. Thanks!
>
> Acked-by: Kees Cook <keescook@chromium.org>

Thanks! This makes a lot of sense and maybe buys a bit more time to
figure out the best way to build these (all?) samples for the target.

Acked-by: Will Drewry <wad@chromium.org>

>
>> ---
>>  samples/seccomp/Makefile |    2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/samples/seccomp/Makefile b/samples/seccomp/Makefile
>> index bbbd276..7203e66 100644
>> --- a/samples/seccomp/Makefile
>> +++ b/samples/seccomp/Makefile
>> @@ -19,6 +19,7 @@ bpf-direct-objs := bpf-direct.o
>>
>>  # Try to match the kernel target.
>>  ifndef CONFIG_64BIT
>> +ifndef CROSS_COMPILE
>>
>>  # s390 has -m31 flag to build 31 bit binaries
>>  ifndef CONFIG_S390
>> @@ -35,6 +36,7 @@ HOSTLOADLIBES_bpf-direct += $(MFLAG)
>>  HOSTLOADLIBES_bpf-fancy += $(MFLAG)
>>  HOSTLOADLIBES_dropper += $(MFLAG)
>>  endif
>> +endif
>>
>>  # Tell kbuild to always build the programs
>>  always := $(hostprogs-y)
>> --
>> 1.7.10.4
>>
>
>
>
> --
> Kees Cook
> Chrome OS Security

Re: [PATCH 05/15] ASoC: fsl: fiq and dma cannot both be modules

[Arnd Bergmann]

On Tuesday 22 January 2013, Mark Brown wrote:
>   Show Details
>   On Tue, Jan 22, 2013 at 11:50:30AM +0800, Shawn Guo wrote:
> > On Mon, Jan 21, 2013 at 05:15:58PM +0000, Arnd Bergmann wrote:
> 
> > > Without this patch, we cannot build the ARM 'allmodconfig', or
> > > we get this error:
> 
> > > sound/soc/fsl/imx-pcm-dma.o: In function `init_module':
> > > sound/soc/fsl/imx-pcm-dma.c:177: multiple definition of `init_module'
> > > sound/soc/fsl/imx-pcm-fiq.o:sound/soc/fsl/imx-pcm-fiq.c:334: first defined here
> > > sound/soc/fsl/imx-pcm-dma.o: In function `cleanup_module':
> > > sound/soc/fsl/imx-pcm-dma.c:177: multiple definition of `cleanup_module'
> > > sound/soc/fsl/imx-pcm-fiq.o:sound/soc/fsl/imx-pcm-fiq.c:334: first defined here
> 
> > I sent a fix [1] for that queued by Mark.
> 
> > Mark,
> 
> > Is the patch on the way to 3.8-rc?
> 
> Yes, should be.
>   

Hmm, I tried building 3.8-rc again, which contains the fix to make
'make allmodconfig' work with this code, but it broke 'make allyesconfig', which
was working before :(

8<----------
Subject: [PATCH] ASoC: fsl: fix allyesconfig build for imx-pcm

Patch 25b8d314 "ASoC: fsl: fix multiple definition of init_module changed
the Makefile for imx-pcm.ko to build two modules that both contain the
imx-pcm.c file, which nicely solves the problem of building both versions
of the driver as modules, but it causes two new problems:

1. Since imx-pcm.c is now used in two different modules, Kbuild no longer
sets the KBUILD_MODNAME symbol when building the object file, which makes
it impossible to use dynamic pr_debug code, resulting in this error

sound/soc/fsl/imx-pcm.c: In function 'snd_imx_pcm_mmap':
sound/soc/fsl/imx-pcm.c:28:121: error: 'KBUILD_MODNAME' undeclared (first use in this function)
sound/soc/fsl/imx-pcm.c:28:121: note: each undeclared identifier is reported only once for each function it appears insound/soc/fsl/snd-soc-imx-pcm-dma.o: In function `imx_pcm_free':

2. If we don't use the dynamic debug code, we get a link error since we now
try to link together the same file into built-in.o twice:

sound/soc/fsl/imx-pcm.c:80: multiple definition of `imx_pcm_free'
sound/soc/fsl/snd-soc-imx-pcm-fiq.o:/sound/soc/fsl/imx-pcm.c:80: first defined here
sound/soc/fsl/snd-soc-imx-pcm-dma.o: In function `snd_imx_pcm_mmap':
sound/soc/fsl/imx-pcm.c:21: multiple definition of `snd_imx_pcm_mmap'
sound/soc/fsl/snd-soc-imx-pcm-fiq.o:/sound/soc/fsl/imx-pcm.c:21: first defined here
sound/soc/fsl/snd-soc-imx-pcm-dma.o: In function `imx_pcm_new':
sound/soc/fsl/imx-pcm.c:52: multiple definition of `imx_pcm_new'
sound/soc/fsl/snd-soc-imx-pcm-fiq.o:/sound/soc/fsl/imx-pcm.c:52: first defined here

I originally suggested disallowing the selection of both the DMA and FIQ
code in the same kernel. That is not very nice, but it resolves the
build error for both built-in and modular code.

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

diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index e24e417..3f20cb7 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -122,7 +122,7 @@ config SND_SOC_IMX_AUDMUX
 config SND_MXC_SOC_WM1133_EV1
 	tristate "Audio on the i.MX31ADS with WM1133-EV1 fitted"
 	depends on MACH_MX31ADS_WM1133_EV1
-	depends on !SND_SOC_IMX_PCM_DMA || SND_IMX_SOC=y
+	depends on !SND_SOC_IMX_PCM_DMA
 	select SND_SOC_WM8350
 	select SND_SOC_IMX_PCM_FIQ
 	select SND_SOC_IMX_AUDMUX
@@ -145,7 +145,7 @@ config SND_SOC_MX27VIS_AIC32X4
 config SND_SOC_PHYCORE_AC97
 	tristate "SoC Audio support for Phytec phyCORE (and phyCARD) boards"
 	depends on MACH_PCM043 || MACH_PCA100
-	depends on !SND_SOC_IMX_PCM_DMA || SND_IMX_SOC=y
+	depends on !SND_SOC_IMX_PCM_DMA
 	select SND_SOC_AC97_BUS
 	select SND_SOC_WM9712
 	select SND_SOC_IMX_PCM_FIQ
@@ -162,7 +162,7 @@ config SND_SOC_EUKREA_TLV320
 		|| MACH_EUKREA_MBIMXSD35_BASEBOARD \
 		|| MACH_EUKREA_MBIMXSD51_BASEBOARD
 	depends on I2C
-	depends on !SND_SOC_IMX_PCM_DMA || SND_IMX_SOC=y
+	depends on !SND_SOC_IMX_PCM_DMA
 	select SND_SOC_TLV320AIC23
 	select SND_SOC_IMX_PCM_FIQ
 	select SND_SOC_IMX_AUDMUX
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index ec14579..ddd9076 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -30,13 +30,6 @@ obj-$(CONFIG_SND_MPC52xx_SOC_EFIKA) += efika-audio-fabric.o
 # i.MX Platform Support
 snd-soc-imx-ssi-objs := imx-ssi.o
 snd-soc-imx-audmux-objs := imx-audmux.o
-snd-soc-imx-pcm-objs := imx-pcm.o
-ifneq ($(CONFIG_SND_SOC_IMX_PCM_FIQ),)
-	snd-soc-imx-pcm-objs += imx-pcm-fiq.o
-endif
-ifneq ($(CONFIG_SND_SOC_IMX_PCM_DMA),)
-	snd-soc-imx-pcm-objs += imx-pcm-dma.o
-endif
 
 obj-$(CONFIG_SND_SOC_IMX_SSI) += snd-soc-imx-ssi.o
 obj-$(CONFIG_SND_SOC_IMX_AUDMUX) += snd-soc-imx-audmux.o

[PATCH 05/15] ASoC: fsl: fiq and dma cannot both be modules

[Arnd Bergmann]

On Tuesday 22 January 2013, Mark Brown wrote:
>   Show Details
>   On Tue, Jan 22, 2013 at 11:50:30AM +0800, Shawn Guo wrote:
> > On Mon, Jan 21, 2013 at 05:15:58PM +0000, Arnd Bergmann wrote:
> 
> > > Without this patch, we cannot build the ARM 'allmodconfig', or
> > > we get this error:
> 
> > > sound/soc/fsl/imx-pcm-dma.o: In function `init_module':
> > > sound/soc/fsl/imx-pcm-dma.c:177: multiple definition of `init_module'
> > > sound/soc/fsl/imx-pcm-fiq.o:sound/soc/fsl/imx-pcm-fiq.c:334: first defined here
> > > sound/soc/fsl/imx-pcm-dma.o: In function `cleanup_module':
> > > sound/soc/fsl/imx-pcm-dma.c:177: multiple definition of `cleanup_module'
> > > sound/soc/fsl/imx-pcm-fiq.o:sound/soc/fsl/imx-pcm-fiq.c:334: first defined here
> 
> > I sent a fix [1] for that queued by Mark.
> 
> > Mark,
> 
> > Is the patch on the way to 3.8-rc?
> 
> Yes, should be.
>   

Hmm, I tried building 3.8-rc again, which contains the fix to make
'make allmodconfig' work with this code, but it broke 'make allyesconfig', which
was working before :(

8<----------
Subject: [PATCH] ASoC: fsl: fix allyesconfig build for imx-pcm

Patch 25b8d314 "ASoC: fsl: fix multiple definition of init_module changed
the Makefile for imx-pcm.ko to build two modules that both contain the
imx-pcm.c file, which nicely solves the problem of building both versions
of the driver as modules, but it causes two new problems:

1. Since imx-pcm.c is now used in two different modules, Kbuild no longer
sets the KBUILD_MODNAME symbol when building the object file, which makes
it impossible to use dynamic pr_debug code, resulting in this error

sound/soc/fsl/imx-pcm.c: In function 'snd_imx_pcm_mmap':
sound/soc/fsl/imx-pcm.c:28:121: error: 'KBUILD_MODNAME' undeclared (first use in this function)
sound/soc/fsl/imx-pcm.c:28:121: note: each undeclared identifier is reported only once for each function it appears insound/soc/fsl/snd-soc-imx-pcm-dma.o: In function `imx_pcm_free':

2. If we don't use the dynamic debug code, we get a link error since we now
try to link together the same file into built-in.o twice:

sound/soc/fsl/imx-pcm.c:80: multiple definition of `imx_pcm_free'
sound/soc/fsl/snd-soc-imx-pcm-fiq.o:/sound/soc/fsl/imx-pcm.c:80: first defined here
sound/soc/fsl/snd-soc-imx-pcm-dma.o: In function `snd_imx_pcm_mmap':
sound/soc/fsl/imx-pcm.c:21: multiple definition of `snd_imx_pcm_mmap'
sound/soc/fsl/snd-soc-imx-pcm-fiq.o:/sound/soc/fsl/imx-pcm.c:21: first defined here
sound/soc/fsl/snd-soc-imx-pcm-dma.o: In function `imx_pcm_new':
sound/soc/fsl/imx-pcm.c:52: multiple definition of `imx_pcm_new'
sound/soc/fsl/snd-soc-imx-pcm-fiq.o:/sound/soc/fsl/imx-pcm.c:52: first defined here

I originally suggested disallowing the selection of both the DMA and FIQ
code in the same kernel. That is not very nice, but it resolves the
build error for both built-in and modular code.

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

diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index e24e417..3f20cb7 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -122,7 +122,7 @@ config SND_SOC_IMX_AUDMUX
 config SND_MXC_SOC_WM1133_EV1
 	tristate "Audio on the i.MX31ADS with WM1133-EV1 fitted"
 	depends on MACH_MX31ADS_WM1133_EV1
-	depends on !SND_SOC_IMX_PCM_DMA || SND_IMX_SOC=y
+	depends on !SND_SOC_IMX_PCM_DMA
 	select SND_SOC_WM8350
 	select SND_SOC_IMX_PCM_FIQ
 	select SND_SOC_IMX_AUDMUX
@@ -145,7 +145,7 @@ config SND_SOC_MX27VIS_AIC32X4
 config SND_SOC_PHYCORE_AC97
 	tristate "SoC Audio support for Phytec phyCORE (and phyCARD) boards"
 	depends on MACH_PCM043 || MACH_PCA100
-	depends on !SND_SOC_IMX_PCM_DMA || SND_IMX_SOC=y
+	depends on !SND_SOC_IMX_PCM_DMA
 	select SND_SOC_AC97_BUS
 	select SND_SOC_WM9712
 	select SND_SOC_IMX_PCM_FIQ
@@ -162,7 +162,7 @@ config SND_SOC_EUKREA_TLV320
 		|| MACH_EUKREA_MBIMXSD35_BASEBOARD \
 		|| MACH_EUKREA_MBIMXSD51_BASEBOARD
 	depends on I2C
-	depends on !SND_SOC_IMX_PCM_DMA || SND_IMX_SOC=y
+	depends on !SND_SOC_IMX_PCM_DMA
 	select SND_SOC_TLV320AIC23
 	select SND_SOC_IMX_PCM_FIQ
 	select SND_SOC_IMX_AUDMUX
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index ec14579..ddd9076 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -30,13 +30,6 @@ obj-$(CONFIG_SND_MPC52xx_SOC_EFIKA) += efika-audio-fabric.o
 # i.MX Platform Support
 snd-soc-imx-ssi-objs := imx-ssi.o
 snd-soc-imx-audmux-objs := imx-audmux.o
-snd-soc-imx-pcm-objs := imx-pcm.o
-ifneq ($(CONFIG_SND_SOC_IMX_PCM_FIQ),)
-	snd-soc-imx-pcm-objs += imx-pcm-fiq.o
-endif
-ifneq ($(CONFIG_SND_SOC_IMX_PCM_DMA),)
-	snd-soc-imx-pcm-objs += imx-pcm-dma.o
-endif
 
 obj-$(CONFIG_SND_SOC_IMX_SSI) += snd-soc-imx-ssi.o
 obj-$(CONFIG_SND_SOC_IMX_AUDMUX) += snd-soc-imx-audmux.o

Re: [PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers

[Arnd Bergmann]

On Monday 21 January 2013, Greg Kroah-Hartman wrote:
> On Mon, Jan 21, 2013 at 08:41:38PM +0200, Felipe Balbi wrote:
> > Hi,
> > 
> > On Mon, Jan 21, 2013 at 05:16:05PM +0000, Arnd Bergmann wrote:
> > > Both the fsl_mxc gadget and the imx_udc gadget drivers fail to build
> > > without the mach/hardware.h file that is not available when building
> > > for multiplatform. Let's disable these drivers for v3.8 in combination
> > > with CONFIG_ARCH_MULTIPLATFORM, and fix them properly in v3.9 unless
> > > someone has an better solution.
> > > 
> > > Without this patch, building allyesconfig results in:
> > > 
> > > drivers/usb/gadget/fsl_mxc_udc.c:21:27: fatal error: mach/hardware.h: No such file or directory
> > > 
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > Cc: Felipe Balbi <balbi@ti.com>
> > > Cc: Shawn Guo <shawn.guo@linaro.org>
> > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > Cc: linux-usb@vger.kernel.org
> > 
> > NAK, I prefer to see a real fix for the problem (which in fact is
> > already in my fixes branch).
> 
> I'll pull that branch now, sorry for the delay.

Apparently it hasn't made it into the upstream kernel yet, and it also doesn't
seem to be in linux-next. Maybe this got lost while you were travelling?

	Arnd

[PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers

[Arnd Bergmann]

On Monday 21 January 2013, Greg Kroah-Hartman wrote:
> On Mon, Jan 21, 2013 at 08:41:38PM +0200, Felipe Balbi wrote:
> > Hi,
> > 
> > On Mon, Jan 21, 2013 at 05:16:05PM +0000, Arnd Bergmann wrote:
> > > Both the fsl_mxc gadget and the imx_udc gadget drivers fail to build
> > > without the mach/hardware.h file that is not available when building
> > > for multiplatform. Let's disable these drivers for v3.8 in combination
> > > with CONFIG_ARCH_MULTIPLATFORM, and fix them properly in v3.9 unless
> > > someone has an better solution.
> > > 
> > > Without this patch, building allyesconfig results in:
> > > 
> > > drivers/usb/gadget/fsl_mxc_udc.c:21:27: fatal error: mach/hardware.h: No such file or directory
> > > 
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > Cc: Felipe Balbi <balbi@ti.com>
> > > Cc: Shawn Guo <shawn.guo@linaro.org>
> > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > Cc: linux-usb at vger.kernel.org
> > 
> > NAK, I prefer to see a real fix for the problem (which in fact is
> > already in my fixes branch).
> 
> I'll pull that branch now, sorry for the delay.

Apparently it hasn't made it into the upstream kernel yet, and it also doesn't
seem to be in linux-next. Maybe this got lost while you were travelling?

	Arnd

[PATCH] ASoC: fsl: fix allyesconfig build for imx-pcm

[Arnd Bergmann]

Patch 25b8d314 "ASoC: fsl: fix multiple definition of init_module changed
the Makefile for imx-pcm.ko to build two modules that both contain the
imx-pcm.c file, which nicely solves the problem of building both versions
of the driver as modules, but it causes two new problems:

1. Since imx-pcm.c is now used in two different modules, Kbuild no longer
sets the KBUILD_MODNAME symbol when building the object file, which makes
it impossible to use dynamic pr_debug code, resulting in this error

sound/soc/fsl/imx-pcm.c: In function 'snd_imx_pcm_mmap':
sound/soc/fsl/imx-pcm.c:28:121: error: 'KBUILD_MODNAME' undeclared (first use in this function)
sound/soc/fsl/imx-pcm.c:28:121: note: each undeclared identifier is reported only once for each function it appears insound/soc/fsl/snd-soc-imx-pcm-dma.o: In function `imx_pcm_free':

2. If we don't use the dynamic debug code, we get a link error since we now
try to link together the same file into built-in.o twice:

sound/soc/fsl/imx-pcm.c:80: multiple definition of `imx_pcm_free'
sound/soc/fsl/snd-soc-imx-pcm-fiq.o:/sound/soc/fsl/imx-pcm.c:80: first defined here
sound/soc/fsl/snd-soc-imx-pcm-dma.o: In function `snd_imx_pcm_mmap':
sound/soc/fsl/imx-pcm.c:21: multiple definition of `snd_imx_pcm_mmap'
sound/soc/fsl/snd-soc-imx-pcm-fiq.o:/sound/soc/fsl/imx-pcm.c:21: first defined here
sound/soc/fsl/snd-soc-imx-pcm-dma.o: In function `imx_pcm_new':
sound/soc/fsl/imx-pcm.c:52: multiple definition of `imx_pcm_new'
sound/soc/fsl/snd-soc-imx-pcm-fiq.o:/sound/soc/fsl/imx-pcm.c:52: first defined here

I originally suggested disallowing the selection of both the DMA and FIQ
code in the same kernel. That is not very nice, but it resolves the
build error for both built-in and modular code.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
----
Sorry, the previous version did not apply, it was on top of my older patch accidentally

diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index a210c8d..3f20cb7 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -122,6 +122,7 @@ config SND_SOC_IMX_AUDMUX
 config SND_MXC_SOC_WM1133_EV1
 	tristate "Audio on the i.MX31ADS with WM1133-EV1 fitted"
 	depends on MACH_MX31ADS_WM1133_EV1
+	depends on !SND_SOC_IMX_PCM_DMA
 	select SND_SOC_WM8350
 	select SND_SOC_IMX_PCM_FIQ
 	select SND_SOC_IMX_AUDMUX
@@ -144,6 +145,7 @@ config SND_SOC_MX27VIS_AIC32X4
 config SND_SOC_PHYCORE_AC97
 	tristate "SoC Audio support for Phytec phyCORE (and phyCARD) boards"
 	depends on MACH_PCM043 || MACH_PCA100
+	depends on !SND_SOC_IMX_PCM_DMA
 	select SND_SOC_AC97_BUS
 	select SND_SOC_WM9712
 	select SND_SOC_IMX_PCM_FIQ
@@ -160,6 +162,7 @@ config SND_SOC_EUKREA_TLV320
 		|| MACH_EUKREA_MBIMXSD35_BASEBOARD \
 		|| MACH_EUKREA_MBIMXSD51_BASEBOARD
 	depends on I2C
+	depends on !SND_SOC_IMX_PCM_DMA
 	select SND_SOC_TLV320AIC23
 	select SND_SOC_IMX_PCM_FIQ
 	select SND_SOC_IMX_AUDMUX
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index ec14579..ddd9076 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -30,13 +30,6 @@ obj-$(CONFIG_SND_MPC52xx_SOC_EFIKA) += efika-audio-fabric.o
 # i.MX Platform Support
 snd-soc-imx-ssi-objs := imx-ssi.o
 snd-soc-imx-audmux-objs := imx-audmux.o
-snd-soc-imx-pcm-objs := imx-pcm.o
-ifneq ($(CONFIG_SND_SOC_IMX_PCM_FIQ),)
-	snd-soc-imx-pcm-objs += imx-pcm-fiq.o
-endif
-ifneq ($(CONFIG_SND_SOC_IMX_PCM_DMA),)
-	snd-soc-imx-pcm-objs += imx-pcm-dma.o
-endif
 
 obj-$(CONFIG_SND_SOC_IMX_SSI) += snd-soc-imx-ssi.o
 obj-$(CONFIG_SND_SOC_IMX_AUDMUX) += snd-soc-imx-audmux.o

[PATCH] ASoC: fsl: fix allyesconfig build for imx-pcm

[Arnd Bergmann]

Patch 25b8d314 "ASoC: fsl: fix multiple definition of init_module changed
the Makefile for imx-pcm.ko to build two modules that both contain the
imx-pcm.c file, which nicely solves the problem of building both versions
of the driver as modules, but it causes two new problems:

1. Since imx-pcm.c is now used in two different modules, Kbuild no longer
sets the KBUILD_MODNAME symbol when building the object file, which makes
it impossible to use dynamic pr_debug code, resulting in this error

sound/soc/fsl/imx-pcm.c: In function 'snd_imx_pcm_mmap':
sound/soc/fsl/imx-pcm.c:28:121: error: 'KBUILD_MODNAME' undeclared (first use in this function)
sound/soc/fsl/imx-pcm.c:28:121: note: each undeclared identifier is reported only once for each function it appears insound/soc/fsl/snd-soc-imx-pcm-dma.o: In function `imx_pcm_free':

2. If we don't use the dynamic debug code, we get a link error since we now
try to link together the same file into built-in.o twice:

sound/soc/fsl/imx-pcm.c:80: multiple definition of `imx_pcm_free'
sound/soc/fsl/snd-soc-imx-pcm-fiq.o:/sound/soc/fsl/imx-pcm.c:80: first defined here
sound/soc/fsl/snd-soc-imx-pcm-dma.o: In function `snd_imx_pcm_mmap':
sound/soc/fsl/imx-pcm.c:21: multiple definition of `snd_imx_pcm_mmap'
sound/soc/fsl/snd-soc-imx-pcm-fiq.o:/sound/soc/fsl/imx-pcm.c:21: first defined here
sound/soc/fsl/snd-soc-imx-pcm-dma.o: In function `imx_pcm_new':
sound/soc/fsl/imx-pcm.c:52: multiple definition of `imx_pcm_new'
sound/soc/fsl/snd-soc-imx-pcm-fiq.o:/sound/soc/fsl/imx-pcm.c:52: first defined here

I originally suggested disallowing the selection of both the DMA and FIQ
code in the same kernel. That is not very nice, but it resolves the
build error for both built-in and modular code.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
----
Sorry, the previous version did not apply, it was on top of my older patch accidentally

diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index a210c8d..3f20cb7 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -122,6 +122,7 @@ config SND_SOC_IMX_AUDMUX
 config SND_MXC_SOC_WM1133_EV1
 	tristate "Audio on the i.MX31ADS with WM1133-EV1 fitted"
 	depends on MACH_MX31ADS_WM1133_EV1
+	depends on !SND_SOC_IMX_PCM_DMA
 	select SND_SOC_WM8350
 	select SND_SOC_IMX_PCM_FIQ
 	select SND_SOC_IMX_AUDMUX
@@ -144,6 +145,7 @@ config SND_SOC_MX27VIS_AIC32X4
 config SND_SOC_PHYCORE_AC97
 	tristate "SoC Audio support for Phytec phyCORE (and phyCARD) boards"
 	depends on MACH_PCM043 || MACH_PCA100
+	depends on !SND_SOC_IMX_PCM_DMA
 	select SND_SOC_AC97_BUS
 	select SND_SOC_WM9712
 	select SND_SOC_IMX_PCM_FIQ
@@ -160,6 +162,7 @@ config SND_SOC_EUKREA_TLV320
 		|| MACH_EUKREA_MBIMXSD35_BASEBOARD \
 		|| MACH_EUKREA_MBIMXSD51_BASEBOARD
 	depends on I2C
+	depends on !SND_SOC_IMX_PCM_DMA
 	select SND_SOC_TLV320AIC23
 	select SND_SOC_IMX_PCM_FIQ
 	select SND_SOC_IMX_AUDMUX
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index ec14579..ddd9076 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -30,13 +30,6 @@ obj-$(CONFIG_SND_MPC52xx_SOC_EFIKA) += efika-audio-fabric.o
 # i.MX Platform Support
 snd-soc-imx-ssi-objs := imx-ssi.o
 snd-soc-imx-audmux-objs := imx-audmux.o
-snd-soc-imx-pcm-objs := imx-pcm.o
-ifneq ($(CONFIG_SND_SOC_IMX_PCM_FIQ),)
-	snd-soc-imx-pcm-objs += imx-pcm-fiq.o
-endif
-ifneq ($(CONFIG_SND_SOC_IMX_PCM_DMA),)
-	snd-soc-imx-pcm-objs += imx-pcm-dma.o
-endif
 
 obj-$(CONFIG_SND_SOC_IMX_SSI) += snd-soc-imx-ssi.o
 obj-$(CONFIG_SND_SOC_IMX_AUDMUX) += snd-soc-imx-audmux.o

Re: [PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers

[Greg Kroah-Hartman]

On Tue, Feb 05, 2013 at 04:27:18PM +0000, Arnd Bergmann wrote:
> On Monday 21 January 2013, Greg Kroah-Hartman wrote:
> > On Mon, Jan 21, 2013 at 08:41:38PM +0200, Felipe Balbi wrote:
> > > Hi,
> > > 
> > > On Mon, Jan 21, 2013 at 05:16:05PM +0000, Arnd Bergmann wrote:
> > > > Both the fsl_mxc gadget and the imx_udc gadget drivers fail to build
> > > > without the mach/hardware.h file that is not available when building
> > > > for multiplatform. Let's disable these drivers for v3.8 in combination
> > > > with CONFIG_ARCH_MULTIPLATFORM, and fix them properly in v3.9 unless
> > > > someone has an better solution.
> > > > 
> > > > Without this patch, building allyesconfig results in:
> > > > 
> > > > drivers/usb/gadget/fsl_mxc_udc.c:21:27: fatal error: mach/hardware.h: No such file or directory
> > > > 
> > > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > > Cc: Felipe Balbi <balbi@ti.com>
> > > > Cc: Shawn Guo <shawn.guo@linaro.org>
> > > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > > Cc: linux-usb@vger.kernel.org
> > > 
> > > NAK, I prefer to see a real fix for the problem (which in fact is
> > > already in my fixes branch).
> > 
> > I'll pull that branch now, sorry for the delay.
> 
> Apparently it hasn't made it into the upstream kernel yet, and it also doesn't
> seem to be in linux-next. Maybe this got lost while you were travelling?

Hm, no, I thought I got Felipe's fixes branch up into Linus's tree
already.  Felipe, did I miss something from you?  If so, please resend
or let me know, as I don't have anything pending on my side.

thanks,

greg k-h

[PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers

[Greg Kroah-Hartman]

On Tue, Feb 05, 2013 at 04:27:18PM +0000, Arnd Bergmann wrote:
> On Monday 21 January 2013, Greg Kroah-Hartman wrote:
> > On Mon, Jan 21, 2013 at 08:41:38PM +0200, Felipe Balbi wrote:
> > > Hi,
> > > 
> > > On Mon, Jan 21, 2013 at 05:16:05PM +0000, Arnd Bergmann wrote:
> > > > Both the fsl_mxc gadget and the imx_udc gadget drivers fail to build
> > > > without the mach/hardware.h file that is not available when building
> > > > for multiplatform. Let's disable these drivers for v3.8 in combination
> > > > with CONFIG_ARCH_MULTIPLATFORM, and fix them properly in v3.9 unless
> > > > someone has an better solution.
> > > > 
> > > > Without this patch, building allyesconfig results in:
> > > > 
> > > > drivers/usb/gadget/fsl_mxc_udc.c:21:27: fatal error: mach/hardware.h: No such file or directory
> > > > 
> > > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > > Cc: Felipe Balbi <balbi@ti.com>
> > > > Cc: Shawn Guo <shawn.guo@linaro.org>
> > > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > > Cc: linux-usb at vger.kernel.org
> > > 
> > > NAK, I prefer to see a real fix for the problem (which in fact is
> > > already in my fixes branch).
> > 
> > I'll pull that branch now, sorry for the delay.
> 
> Apparently it hasn't made it into the upstream kernel yet, and it also doesn't
> seem to be in linux-next. Maybe this got lost while you were travelling?

Hm, no, I thought I got Felipe's fixes branch up into Linus's tree
already.  Felipe, did I miss something from you?  If so, please resend
or let me know, as I don't have anything pending on my side.

thanks,

greg k-h

Re: [PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers

[Felipe Balbi]

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

Hi,

On Tue, Feb 05, 2013 at 09:00:27AM -0800, Greg Kroah-Hartman wrote:
> On Tue, Feb 05, 2013 at 04:27:18PM +0000, Arnd Bergmann wrote:
> > On Monday 21 January 2013, Greg Kroah-Hartman wrote:
> > > On Mon, Jan 21, 2013 at 08:41:38PM +0200, Felipe Balbi wrote:
> > > > Hi,
> > > > 
> > > > On Mon, Jan 21, 2013 at 05:16:05PM +0000, Arnd Bergmann wrote:
> > > > > Both the fsl_mxc gadget and the imx_udc gadget drivers fail to build
> > > > > without the mach/hardware.h file that is not available when building
> > > > > for multiplatform. Let's disable these drivers for v3.8 in combination
> > > > > with CONFIG_ARCH_MULTIPLATFORM, and fix them properly in v3.9 unless
> > > > > someone has an better solution.
> > > > > 
> > > > > Without this patch, building allyesconfig results in:
> > > > > 
> > > > > drivers/usb/gadget/fsl_mxc_udc.c:21:27: fatal error: mach/hardware.h: No such file or directory
> > > > > 
> > > > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > > > Cc: Felipe Balbi <balbi@ti.com>
> > > > > Cc: Shawn Guo <shawn.guo@linaro.org>
> > > > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > > > Cc: linux-usb@vger.kernel.org
> > > > 
> > > > NAK, I prefer to see a real fix for the problem (which in fact is
> > > > already in my fixes branch).
> > > 
> > > I'll pull that branch now, sorry for the delay.
> > 
> > Apparently it hasn't made it into the upstream kernel yet, and it also doesn't
> > seem to be in linux-next. Maybe this got lost while you were travelling?
> 
> Hm, no, I thought I got Felipe's fixes branch up into Linus's tree
> already.  Felipe, did I miss something from you?  If so, please resend
> or let me know, as I don't have anything pending on my side.

I don't have anything pending in my fixes branch:

$ git log fixes ^linus/master

$ git show-branch linus/master
[linus/master] Merge branch 'fix-max-write' of git://git.kernel.org/pub/scm/linux/kernel/git/teigland/linux-dlm

It's building find for me:

$ crossmake drivers/usb/gadget/fsl_udc_core.o \
	drivers/usb/gadget/fsl_mxc_udc.o > /dev/null

(crossmake is an alias to make ARCH=arm)

Arnd, are you maybe missing a merge of v3.8-rc6 ?

I can see that imx_udc.c is broken still, but there are no maintainers
for that driver. I'm adding Sascha to Cc list, maybe he knows someone
who can help, but if this driver isn't fixed in 2 merge windows, I will
schedule for removal from tree and someone else will have to
re-introduce it later without all the bogus includes.

---- build breaks ---

sound/soc/fsl/imx-pcm.c: In function 'snd_imx_pcm_mmap':
sound/soc/fsl/imx-pcm.c:28:2: error: 'KBUILD_MODNAME' undeclared (first use in this function)
sound/soc/fsl/imx-pcm.c:28:2: note: each undeclared identifier is
reported only once for each function it appears in
make[3]: *** [sound/soc/fsl/imx-pcm.o] Error 1

drivers/video/omap2/dss/dss.c: In function 'dss_calc_clock_div':
drivers/video/omap2/dss/dss.c:572:20: error:
'CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK' undeclared (first use in this function)
drivers/video/omap2/dss/dss.c:572:20: note: each undeclared identifier
is reported only once for each function it appears in
make[4]: *** [drivers/video/omap2/dss/dss.o] Error 1

-- 
balbi

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

[PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers

[Felipe Balbi]

Hi,

On Tue, Feb 05, 2013 at 09:00:27AM -0800, Greg Kroah-Hartman wrote:
> On Tue, Feb 05, 2013 at 04:27:18PM +0000, Arnd Bergmann wrote:
> > On Monday 21 January 2013, Greg Kroah-Hartman wrote:
> > > On Mon, Jan 21, 2013 at 08:41:38PM +0200, Felipe Balbi wrote:
> > > > Hi,
> > > > 
> > > > On Mon, Jan 21, 2013 at 05:16:05PM +0000, Arnd Bergmann wrote:
> > > > > Both the fsl_mxc gadget and the imx_udc gadget drivers fail to build
> > > > > without the mach/hardware.h file that is not available when building
> > > > > for multiplatform. Let's disable these drivers for v3.8 in combination
> > > > > with CONFIG_ARCH_MULTIPLATFORM, and fix them properly in v3.9 unless
> > > > > someone has an better solution.
> > > > > 
> > > > > Without this patch, building allyesconfig results in:
> > > > > 
> > > > > drivers/usb/gadget/fsl_mxc_udc.c:21:27: fatal error: mach/hardware.h: No such file or directory
> > > > > 
> > > > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > > > Cc: Felipe Balbi <balbi@ti.com>
> > > > > Cc: Shawn Guo <shawn.guo@linaro.org>
> > > > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > > > Cc: linux-usb at vger.kernel.org
> > > > 
> > > > NAK, I prefer to see a real fix for the problem (which in fact is
> > > > already in my fixes branch).
> > > 
> > > I'll pull that branch now, sorry for the delay.
> > 
> > Apparently it hasn't made it into the upstream kernel yet, and it also doesn't
> > seem to be in linux-next. Maybe this got lost while you were travelling?
> 
> Hm, no, I thought I got Felipe's fixes branch up into Linus's tree
> already.  Felipe, did I miss something from you?  If so, please resend
> or let me know, as I don't have anything pending on my side.

I don't have anything pending in my fixes branch:

$ git log fixes ^linus/master

$ git show-branch linus/master
[linus/master] Merge branch 'fix-max-write' of git://git.kernel.org/pub/scm/linux/kernel/git/teigland/linux-dlm

It's building find for me:

$ crossmake drivers/usb/gadget/fsl_udc_core.o \
	drivers/usb/gadget/fsl_mxc_udc.o > /dev/null

(crossmake is an alias to make ARCH=arm)

Arnd, are you maybe missing a merge of v3.8-rc6 ?

I can see that imx_udc.c is broken still, but there are no maintainers
for that driver. I'm adding Sascha to Cc list, maybe he knows someone
who can help, but if this driver isn't fixed in 2 merge windows, I will
schedule for removal from tree and someone else will have to
re-introduce it later without all the bogus includes.

---- build breaks ---

sound/soc/fsl/imx-pcm.c: In function 'snd_imx_pcm_mmap':
sound/soc/fsl/imx-pcm.c:28:2: error: 'KBUILD_MODNAME' undeclared (first use in this function)
sound/soc/fsl/imx-pcm.c:28:2: note: each undeclared identifier is
reported only once for each function it appears in
make[3]: *** [sound/soc/fsl/imx-pcm.o] Error 1

drivers/video/omap2/dss/dss.c: In function 'dss_calc_clock_div':
drivers/video/omap2/dss/dss.c:572:20: error:
'CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK' undeclared (first use in this function)
drivers/video/omap2/dss/dss.c:572:20: note: each undeclared identifier
is reported only once for each function it appears in
make[4]: *** [drivers/video/omap2/dss/dss.o] Error 1

-- 
balbi
-------------- 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/20130205/aa5f5683/attachment.sig>

Re: [PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers

[Arnd Bergmann]

On Tuesday 05 February 2013, Felipe Balbi wrote:
> [linus/master] Merge branch 'fix-max-write' of git://git.kernel.org/pub/scm/linux/kernel/git/teigland/linux-dlm
> 
> It's building find for me:
> 
> $ crossmake drivers/usb/gadget/fsl_udc_core.o \
>         drivers/usb/gadget/fsl_mxc_udc.o > /dev/null
> 
> (crossmake is an alias to make ARCH=arm)
> 
> Arnd, are you maybe missing a merge of v3.8-rc6 ?
>
> I can see that imx_udc.c is broken still, but there are no maintainers
> for that driver. I'm adding Sascha to Cc list, maybe he knows someone
> who can help, but if this driver isn't fixed in 2 merge windows, I will
> schedule for removal from tree and someone else will have to
> re-introduce it later without all the bogus includes.

Ah, I see what happened now: I submitted a patch that lumped together
two patches, disabling both fsl_mxc_udc and imx_udc. You already had
a fix for the first one, so I dropped my patch, but now I see the
build error for the second one that my patch was avoiding.

The last patch to imx_udc that seems to have seen more than just
build testing was probably "USB: gadget: imx_udc: don't queue more
data when zlp is to be sent", while fsl_mxc_udc looks actively
maintained. It's not completely clear to me whether these
are actually two drivers for the same hardware, of whether
imx_udc is the i.mx1 variant and fsl_mxc_udc is the i.mx2 variant.

What I can say is that no platform in the kernel currently defines
an "imx_udc" platform_device, so it is certainly unused, and has
been since at least e08300043e in 2010.

I would suggest that we mark the imx_udc driver as 'depends on
BROKEN' right away, since no in-tree user needs it, and any
out of tree user is already broken in 3.8. I also wouldn't
mind removing the driver unless the imx maintainers have
a plan for it.

> ---- build breaks ---
> 
> sound/soc/fsl/imx-pcm.c: In function 'snd_imx_pcm_mmap':
> sound/soc/fsl/imx-pcm.c:28:2: error: 'KBUILD_MODNAME' undeclared (first use in this function)
> sound/soc/fsl/imx-pcm.c:28:2: note: each undeclared identifier is
> reported only once for each function it appears in
> make[3]: *** [sound/soc/fsl/imx-pcm.o] Error 1
> 
> drivers/video/omap2/dss/dss.c: In function 'dss_calc_clock_div':
> drivers/video/omap2/dss/dss.c:572:20: error:
> 'CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK' undeclared (first use in this function)
> drivers/video/omap2/dss/dss.c:572:20: note: each undeclared identifier
> is reported only once for each function it appears in
> make[4]: *** [drivers/video/omap2/dss/dss.o] Error 1

Yes, I submitted patches for these, too, and like this case, we decided
to drop my patch in favor of a better fix, which has not yet gone
in. Today I sent emails about these as well, in the hope that we
can find a solution.

	Arnd

[PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers

[Arnd Bergmann]

On Tuesday 05 February 2013, Felipe Balbi wrote:
> [linus/master] Merge branch 'fix-max-write' of git://git.kernel.org/pub/scm/linux/kernel/git/teigland/linux-dlm
> 
> It's building find for me:
> 
> $ crossmake drivers/usb/gadget/fsl_udc_core.o \
>         drivers/usb/gadget/fsl_mxc_udc.o > /dev/null
> 
> (crossmake is an alias to make ARCH=arm)
> 
> Arnd, are you maybe missing a merge of v3.8-rc6 ?
>
> I can see that imx_udc.c is broken still, but there are no maintainers
> for that driver. I'm adding Sascha to Cc list, maybe he knows someone
> who can help, but if this driver isn't fixed in 2 merge windows, I will
> schedule for removal from tree and someone else will have to
> re-introduce it later without all the bogus includes.

Ah, I see what happened now: I submitted a patch that lumped together
two patches, disabling both fsl_mxc_udc and imx_udc. You already had
a fix for the first one, so I dropped my patch, but now I see the
build error for the second one that my patch was avoiding.

The last patch to imx_udc that seems to have seen more than just
build testing was probably "USB: gadget: imx_udc: don't queue more
data when zlp is to be sent", while fsl_mxc_udc looks actively
maintained. It's not completely clear to me whether these
are actually two drivers for the same hardware, of whether
imx_udc is the i.mx1 variant and fsl_mxc_udc is the i.mx2 variant.

What I can say is that no platform in the kernel currently defines
an "imx_udc" platform_device, so it is certainly unused, and has
been since at least e08300043e in 2010.

I would suggest that we mark the imx_udc driver as 'depends on
BROKEN' right away, since no in-tree user needs it, and any
out of tree user is already broken in 3.8. I also wouldn't
mind removing the driver unless the imx maintainers have
a plan for it.

> ---- build breaks ---
> 
> sound/soc/fsl/imx-pcm.c: In function 'snd_imx_pcm_mmap':
> sound/soc/fsl/imx-pcm.c:28:2: error: 'KBUILD_MODNAME' undeclared (first use in this function)
> sound/soc/fsl/imx-pcm.c:28:2: note: each undeclared identifier is
> reported only once for each function it appears in
> make[3]: *** [sound/soc/fsl/imx-pcm.o] Error 1
> 
> drivers/video/omap2/dss/dss.c: In function 'dss_calc_clock_div':
> drivers/video/omap2/dss/dss.c:572:20: error:
> 'CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK' undeclared (first use in this function)
> drivers/video/omap2/dss/dss.c:572:20: note: each undeclared identifier
> is reported only once for each function it appears in
> make[4]: *** [drivers/video/omap2/dss/dss.o] Error 1

Yes, I submitted patches for these, too, and like this case, we decided
to drop my patch in favor of a better fix, which has not yet gone
in. Today I sent emails about these as well, in the hope that we
can find a solution.

	Arnd

Re: [PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers

[Greg Kroah-Hartman]

On Tue, Feb 05, 2013 at 10:54:00PM +0000, Arnd Bergmann wrote:
> On Tuesday 05 February 2013, Felipe Balbi wrote:
> > [linus/master] Merge branch 'fix-max-write' of git://git.kernel.org/pub/scm/linux/kernel/git/teigland/linux-dlm
> > 
> > It's building find for me:
> > 
> > $ crossmake drivers/usb/gadget/fsl_udc_core.o \
> >         drivers/usb/gadget/fsl_mxc_udc.o > /dev/null
> > 
> > (crossmake is an alias to make ARCH=arm)
> > 
> > Arnd, are you maybe missing a merge of v3.8-rc6 ?
> >
> > I can see that imx_udc.c is broken still, but there are no maintainers
> > for that driver. I'm adding Sascha to Cc list, maybe he knows someone
> > who can help, but if this driver isn't fixed in 2 merge windows, I will
> > schedule for removal from tree and someone else will have to
> > re-introduce it later without all the bogus includes.
> 
> Ah, I see what happened now: I submitted a patch that lumped together
> two patches, disabling both fsl_mxc_udc and imx_udc. You already had
> a fix for the first one, so I dropped my patch, but now I see the
> build error for the second one that my patch was avoiding.
> 
> The last patch to imx_udc that seems to have seen more than just
> build testing was probably "USB: gadget: imx_udc: don't queue more
> data when zlp is to be sent", while fsl_mxc_udc looks actively
> maintained. It's not completely clear to me whether these
> are actually two drivers for the same hardware, of whether
> imx_udc is the i.mx1 variant and fsl_mxc_udc is the i.mx2 variant.
> 
> What I can say is that no platform in the kernel currently defines
> an "imx_udc" platform_device, so it is certainly unused, and has
> been since at least e08300043e in 2010.
> 
> I would suggest that we mark the imx_udc driver as 'depends on
> BROKEN' right away, since no in-tree user needs it, and any
> out of tree user is already broken in 3.8. I also wouldn't
> mind removing the driver unless the imx maintainers have
> a plan for it.

Sure, someone just send me a patch for that and I'll be glad to mark it
BROKEN.

thanks,

greg k-h

[PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers

[Greg Kroah-Hartman]

On Tue, Feb 05, 2013 at 10:54:00PM +0000, Arnd Bergmann wrote:
> On Tuesday 05 February 2013, Felipe Balbi wrote:
> > [linus/master] Merge branch 'fix-max-write' of git://git.kernel.org/pub/scm/linux/kernel/git/teigland/linux-dlm
> > 
> > It's building find for me:
> > 
> > $ crossmake drivers/usb/gadget/fsl_udc_core.o \
> >         drivers/usb/gadget/fsl_mxc_udc.o > /dev/null
> > 
> > (crossmake is an alias to make ARCH=arm)
> > 
> > Arnd, are you maybe missing a merge of v3.8-rc6 ?
> >
> > I can see that imx_udc.c is broken still, but there are no maintainers
> > for that driver. I'm adding Sascha to Cc list, maybe he knows someone
> > who can help, but if this driver isn't fixed in 2 merge windows, I will
> > schedule for removal from tree and someone else will have to
> > re-introduce it later without all the bogus includes.
> 
> Ah, I see what happened now: I submitted a patch that lumped together
> two patches, disabling both fsl_mxc_udc and imx_udc. You already had
> a fix for the first one, so I dropped my patch, but now I see the
> build error for the second one that my patch was avoiding.
> 
> The last patch to imx_udc that seems to have seen more than just
> build testing was probably "USB: gadget: imx_udc: don't queue more
> data when zlp is to be sent", while fsl_mxc_udc looks actively
> maintained. It's not completely clear to me whether these
> are actually two drivers for the same hardware, of whether
> imx_udc is the i.mx1 variant and fsl_mxc_udc is the i.mx2 variant.
> 
> What I can say is that no platform in the kernel currently defines
> an "imx_udc" platform_device, so it is certainly unused, and has
> been since at least e08300043e in 2010.
> 
> I would suggest that we mark the imx_udc driver as 'depends on
> BROKEN' right away, since no in-tree user needs it, and any
> out of tree user is already broken in 3.8. I also wouldn't
> mind removing the driver unless the imx maintainers have
> a plan for it.

Sure, someone just send me a patch for that and I'll be glad to mark it
BROKEN.

thanks,

greg k-h

Re: [PATCH] ASoC: fsl: fix allyesconfig build for imx-pcm

[Shawn Guo]

On Tue, Feb 05, 2013 at 04:42:25PM +0000, Arnd Bergmann wrote:
> Patch 25b8d314 "ASoC: fsl: fix multiple definition of init_module changed
> the Makefile for imx-pcm.ko to build two modules that both contain the
> imx-pcm.c file, which nicely solves the problem of building both versions
> of the driver as modules, but it causes two new problems:
> 
It's my fault, Arnd.  The patch 25b8d314 is a crap.  Instead of making
the Kconfig even complexer, I chose to revert the patch and do a little
surgery on the code to make it match the Kconfig rational.  The fix[1]
should be on the way to mainline now.

I'm sorry for messing thing up during -rc time.

Shawn

[1] http://thread.gmane.org/gmane.linux.alsa.devel/105018

Re: [PATCH] ASoC: fsl: fix allyesconfig build for imx-pcm

[Shawn Guo]

On Tue, Feb 05, 2013 at 04:42:25PM +0000, Arnd Bergmann wrote:
> Patch 25b8d314 "ASoC: fsl: fix multiple definition of init_module changed
> the Makefile for imx-pcm.ko to build two modules that both contain the
> imx-pcm.c file, which nicely solves the problem of building both versions
> of the driver as modules, but it causes two new problems:
> 
It's my fault, Arnd.  The patch 25b8d314 is a crap.  Instead of making
the Kconfig even complexer, I chose to revert the patch and do a little
surgery on the code to make it match the Kconfig rational.  The fix[1]
should be on the way to mainline now.

I'm sorry for messing thing up during -rc time.

Shawn

[1] http://thread.gmane.org/gmane.linux.alsa.devel/105018

[PATCH] ASoC: fsl: fix allyesconfig build for imx-pcm

[Shawn Guo]

On Tue, Feb 05, 2013 at 04:42:25PM +0000, Arnd Bergmann wrote:
> Patch 25b8d314 "ASoC: fsl: fix multiple definition of init_module changed
> the Makefile for imx-pcm.ko to build two modules that both contain the
> imx-pcm.c file, which nicely solves the problem of building both versions
> of the driver as modules, but it causes two new problems:
> 
It's my fault, Arnd.  The patch 25b8d314 is a crap.  Instead of making
the Kconfig even complexer, I chose to revert the patch and do a little
surgery on the code to make it match the Kconfig rational.  The fix[1]
should be on the way to mainline now.

I'm sorry for messing thing up during -rc time.

Shawn

[1] http://thread.gmane.org/gmane.linux.alsa.devel/105018

Re: [PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers

[Felipe Balbi]

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

On Tue, Feb 05, 2013 at 05:55:11PM -0800, Greg Kroah-Hartman wrote:
> On Tue, Feb 05, 2013 at 10:54:00PM +0000, Arnd Bergmann wrote:
> > On Tuesday 05 February 2013, Felipe Balbi wrote:
> > > [linus/master] Merge branch 'fix-max-write' of git://git.kernel.org/pub/scm/linux/kernel/git/teigland/linux-dlm
> > > 
> > > It's building find for me:
> > > 
> > > $ crossmake drivers/usb/gadget/fsl_udc_core.o \
> > >         drivers/usb/gadget/fsl_mxc_udc.o > /dev/null
> > > 
> > > (crossmake is an alias to make ARCH=arm)
> > > 
> > > Arnd, are you maybe missing a merge of v3.8-rc6 ?
> > >
> > > I can see that imx_udc.c is broken still, but there are no maintainers
> > > for that driver. I'm adding Sascha to Cc list, maybe he knows someone
> > > who can help, but if this driver isn't fixed in 2 merge windows, I will
> > > schedule for removal from tree and someone else will have to
> > > re-introduce it later without all the bogus includes.
> > 
> > Ah, I see what happened now: I submitted a patch that lumped together
> > two patches, disabling both fsl_mxc_udc and imx_udc. You already had
> > a fix for the first one, so I dropped my patch, but now I see the
> > build error for the second one that my patch was avoiding.
> > 
> > The last patch to imx_udc that seems to have seen more than just
> > build testing was probably "USB: gadget: imx_udc: don't queue more
> > data when zlp is to be sent", while fsl_mxc_udc looks actively
> > maintained. It's not completely clear to me whether these
> > are actually two drivers for the same hardware, of whether
> > imx_udc is the i.mx1 variant and fsl_mxc_udc is the i.mx2 variant.
> > 
> > What I can say is that no platform in the kernel currently defines
> > an "imx_udc" platform_device, so it is certainly unused, and has
> > been since at least e08300043e in 2010.
> > 
> > I would suggest that we mark the imx_udc driver as 'depends on
> > BROKEN' right away, since no in-tree user needs it, and any
> > out of tree user is already broken in 3.8. I also wouldn't
> > mind removing the driver unless the imx maintainers have
> > a plan for it.
> 
> Sure, someone just send me a patch for that and I'll be glad to mark it
> BROKEN.

coming in a minute

-- 
balbi

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

[PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers

[Felipe Balbi]

On Tue, Feb 05, 2013 at 05:55:11PM -0800, Greg Kroah-Hartman wrote:
> On Tue, Feb 05, 2013 at 10:54:00PM +0000, Arnd Bergmann wrote:
> > On Tuesday 05 February 2013, Felipe Balbi wrote:
> > > [linus/master] Merge branch 'fix-max-write' of git://git.kernel.org/pub/scm/linux/kernel/git/teigland/linux-dlm
> > > 
> > > It's building find for me:
> > > 
> > > $ crossmake drivers/usb/gadget/fsl_udc_core.o \
> > >         drivers/usb/gadget/fsl_mxc_udc.o > /dev/null
> > > 
> > > (crossmake is an alias to make ARCH=arm)
> > > 
> > > Arnd, are you maybe missing a merge of v3.8-rc6 ?
> > >
> > > I can see that imx_udc.c is broken still, but there are no maintainers
> > > for that driver. I'm adding Sascha to Cc list, maybe he knows someone
> > > who can help, but if this driver isn't fixed in 2 merge windows, I will
> > > schedule for removal from tree and someone else will have to
> > > re-introduce it later without all the bogus includes.
> > 
> > Ah, I see what happened now: I submitted a patch that lumped together
> > two patches, disabling both fsl_mxc_udc and imx_udc. You already had
> > a fix for the first one, so I dropped my patch, but now I see the
> > build error for the second one that my patch was avoiding.
> > 
> > The last patch to imx_udc that seems to have seen more than just
> > build testing was probably "USB: gadget: imx_udc: don't queue more
> > data when zlp is to be sent", while fsl_mxc_udc looks actively
> > maintained. It's not completely clear to me whether these
> > are actually two drivers for the same hardware, of whether
> > imx_udc is the i.mx1 variant and fsl_mxc_udc is the i.mx2 variant.
> > 
> > What I can say is that no platform in the kernel currently defines
> > an "imx_udc" platform_device, so it is certainly unused, and has
> > been since at least e08300043e in 2010.
> > 
> > I would suggest that we mark the imx_udc driver as 'depends on
> > BROKEN' right away, since no in-tree user needs it, and any
> > out of tree user is already broken in 3.8. I also wouldn't
> > mind removing the driver unless the imx maintainers have
> > a plan for it.
> 
> Sure, someone just send me a patch for that and I'll be glad to mark it
> BROKEN.

coming in a minute

-- 
balbi
-------------- 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/20130206/e23c0aa1/attachment.sig>

Re: [PATCH] ASoC: fsl: fix allyesconfig build for imx-pcm

[Arnd Bergmann]

On Wednesday 06 February 2013, Shawn Guo wrote:
> On Tue, Feb 05, 2013 at 04:42:25PM +0000, Arnd Bergmann wrote:
> > Patch 25b8d314 "ASoC: fsl: fix multiple definition of init_module changed
> > the Makefile for imx-pcm.ko to build two modules that both contain the
> > imx-pcm.c file, which nicely solves the problem of building both versions
> > of the driver as modules, but it causes two new problems:
> > 
> It's my fault, Arnd.  The patch 25b8d314 is a crap.  Instead of making
> the Kconfig even complexer, I chose to revert the patch and do a little
> surgery on the code to make it match the Kconfig rational.  The fix[1]
> should be on the way to mainline now.
> 
> I'm sorry for messing thing up during -rc time.
> 
> Shawn
> 
> [1] http://thread.gmane.org/gmane.linux.alsa.devel/105018
> 

Ok, again you were faster than I was at finding a solution, and the
new one looks good to me.

Thanks for taking care of this already,

	Arnd

[PATCH] ASoC: fsl: fix allyesconfig build for imx-pcm

[Arnd Bergmann]

On Wednesday 06 February 2013, Shawn Guo wrote:
> On Tue, Feb 05, 2013 at 04:42:25PM +0000, Arnd Bergmann wrote:
> > Patch 25b8d314 "ASoC: fsl: fix multiple definition of init_module changed
> > the Makefile for imx-pcm.ko to build two modules that both contain the
> > imx-pcm.c file, which nicely solves the problem of building both versions
> > of the driver as modules, but it causes two new problems:
> > 
> It's my fault, Arnd.  The patch 25b8d314 is a crap.  Instead of making
> the Kconfig even complexer, I chose to revert the patch and do a little
> surgery on the code to make it match the Kconfig rational.  The fix[1]
> should be on the way to mainline now.
> 
> I'm sorry for messing thing up during -rc time.
> 
> Shawn
> 
> [1] http://thread.gmane.org/gmane.linux.alsa.devel/105018
> 

Ok, again you were faster than I was at finding a solution, and the
new one looks good to me.

Thanks for taking care of this already,

	Arnd

Re: [PATCH 06/15] clk: export __clk_get_name

[Arnd Bergmann]

On Tuesday 22 January 2013, Arnd Bergmann wrote:
> On Tuesday 22 January 2013, Fabio Estevam wrote:
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > Cc: Sascha Hauer <s.hauer@pengutronix.de>
> > > Cc: Mike Turquette <mturquette@linaro.org>
> > 
> > A fix from Niels de Vos has already been applied into clk-next:
> > https://patchwork.kernel.org/patch/1871981/
> 
> Ok, very good. Mike, I saw that the patch is over
> a month old. Any reason it hasn't made it into v3.8.rc yet?
> 

I guess we missed this one for 3.8 then, meaning we have no
working allmodconfig :(

	Arnd

[PATCH 06/15] clk: export __clk_get_name

[Arnd Bergmann]

On Tuesday 22 January 2013, Arnd Bergmann wrote:
> On Tuesday 22 January 2013, Fabio Estevam wrote:
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > Cc: Sascha Hauer <s.hauer@pengutronix.de>
> > > Cc: Mike Turquette <mturquette@linaro.org>
> > 
> > A fix from Niels de Vos has already been applied into clk-next:
> > https://patchwork.kernel.org/patch/1871981/
> 
> Ok, very good. Mike, I saw that the patch is over
> a month old. Any reason it hasn't made it into v3.8.rc yet?
> 

I guess we missed this one for 3.8 then, meaning we have no
working allmodconfig :(

	Arnd