All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 00/21] more arm build fixes
@ 2013-04-25 17:28 ` Arnd Bergmann
  0 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:28 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: linux-kernel, Arnd Bergmann, James E.J. Bottomley,
	Benjamin Herrenschmidt, David Airlie, Felipe Balbi, Grant Likely,
	Greg Kroah-Hartman, Inki Dae, Jason Cooper, Joerg Roedel,
	Nicolas Pitre, Rafael J. Wysocki, Rob Herring, Russell King,
	Simon Horman, Thomas Gleixner, Viresh Kumar, Will Deacon,
	alsa-devel, dri-devel, linux-atm-general, linux-scsi, linux-usb,
	netdev

Hi subsystem maintainers,

Here is another set of patches that resulted from build testing on
linux-next. Please apply directly into your trees if you agree,
or let me know if I made a mistake.

I can take whatever remains through the arm-soc tree if you prefer
that or I don't hear back.

	Arnd


Arnd Bergmann (21):
  ARM: topology: export cpu_topology
  ARM: default machine descriptor for multiplatform
  ARM: shmobile: don't call irqchip_init unconditionally
  ARM: orion5x: include linux/cpu.h
  atm: he: use mdelay instead of large udelay constants
  ALSA: ali5451: use mdelay instead of large udelay constants
  oss/dmabuf: use dma_map_single
  drm/nouveau: use mdelay instead of large udelay constants
  drm: export drm_vm_open_locked
  [SCSI] nsp32: use mdelay instead of large udelay constants
  irqdomain: export irq_domain_add_simple
  irqchip: s3c24xx: add missing __init annotations
  iommu: tegra: print dma_addr_t using %lld
  cpufreq: pxa2xx: initialize variables
  thermal: cooling: avoid uninitialied used gcc warning
  OF: remove #ifdef from linux/of_platform.h
  X.509: do not emit any informational output
  USB: ehci-msm: USB_MSM_OTG needs USB_PHY
  USB: lpc32xx: ISP1301 needs USB_PHY
  USB: OMAP: ISP1301 needs USB_PHY
  USB: OHCI: avoid conflicting platform drivers

 arch/arm/Kconfig                                   |   1 -
 arch/arm/configs/lpc32xx_defconfig                 |   1 +
 arch/arm/configs/msm_defconfig                     |   1 +
 arch/arm/configs/omap1_defconfig                   |   1 +
 arch/arm/kernel/devtree.c                          |   7 ++
 arch/arm/kernel/setup.c                            |  11 +-
 arch/arm/kernel/topology.c                         |   1 +
 arch/arm/mach-orion5x/common.c                     |   1 +
 arch/arm/mach-shmobile/intc-r8a7740.c              |  13 +-
 drivers/atm/he.c                                   |   2 +-
 drivers/cpufreq/pxa2xx-cpufreq.c                   |   5 +-
 drivers/gpu/drm/drm_vm.c                           |   1 +
 drivers/gpu/drm/nouveau/core/engine/disp/dacnv50.c |   3 +-
 drivers/iommu/tegra-gart.c                         |   3 +-
 drivers/iommu/tegra-smmu.c                         |   2 +-
 drivers/irqchip/irq-s3c24xx.c                      |   4 +-
 drivers/scsi/nsp32.c                               |   2 +-
 drivers/thermal/cpu_cooling.c                      |  17 +--
 drivers/usb/gadget/Kconfig                         |   2 +
 drivers/usb/host/Kconfig                           |   1 +
 drivers/usb/host/ohci-hcd.c                        | 136 ++++++++++++++++++---
 drivers/usb/phy/Makefile                           |   2 +-
 include/linux/of_platform.h                        |  13 +-
 kernel/irq/irqdomain.c                             |   1 +
 lib/build_OID_registry                             |   2 -
 sound/oss/dmabuf.c                                 |   3 +-
 sound/pci/ali5451/ali5451.c                        |   8 +-
 27 files changed, 187 insertions(+), 57 deletions(-)

-- 
1.8.1.2

Cc: "James E.J. Bottomley" <JBottomley@parallels.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: David Airlie <airlied@linux.ie>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Nicolas Pitre <nico@linaro.org>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Rob Herring <robherring2@gmail.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Simon Horman <horms+renesas@verge.net.au>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Will Deacon <will.deacon@arm.com>
Cc: alsa-devel@alsa-project.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-atm-general@lists.sourceforge.net
Cc: linux-scsi@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Cc: netdev@vger.kernel.org

^ permalink raw reply	[flat|nested] 131+ messages in thread

* [PATCH 00/21] more arm build fixes
@ 2013-04-25 17:28 ` Arnd Bergmann
  0 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:28 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: linux-kernel, Arnd Bergmann, James E.J. Bottomley,
	Benjamin Herrenschmidt, David Airlie, Felipe Balbi, Grant Likely,
	Greg Kroah-Hartman, Inki Dae, Jason Cooper, Joerg Roedel,
	Nicolas Pitre, Rafael J. Wysocki, Rob Herring, Russell King,
	Simon Horman, Thomas Gleixner, Viresh Kumar, Will Deacon,
	alsa-devel, dri-devel, linux-atm-general, linux-scsi, linux-usb

Hi subsystem maintainers,

Here is another set of patches that resulted from build testing on
linux-next. Please apply directly into your trees if you agree,
or let me know if I made a mistake.

I can take whatever remains through the arm-soc tree if you prefer
that or I don't hear back.

	Arnd


Arnd Bergmann (21):
  ARM: topology: export cpu_topology
  ARM: default machine descriptor for multiplatform
  ARM: shmobile: don't call irqchip_init unconditionally
  ARM: orion5x: include linux/cpu.h
  atm: he: use mdelay instead of large udelay constants
  ALSA: ali5451: use mdelay instead of large udelay constants
  oss/dmabuf: use dma_map_single
  drm/nouveau: use mdelay instead of large udelay constants
  drm: export drm_vm_open_locked
  [SCSI] nsp32: use mdelay instead of large udelay constants
  irqdomain: export irq_domain_add_simple
  irqchip: s3c24xx: add missing __init annotations
  iommu: tegra: print dma_addr_t using %lld
  cpufreq: pxa2xx: initialize variables
  thermal: cooling: avoid uninitialied used gcc warning
  OF: remove #ifdef from linux/of_platform.h
  X.509: do not emit any informational output
  USB: ehci-msm: USB_MSM_OTG needs USB_PHY
  USB: lpc32xx: ISP1301 needs USB_PHY
  USB: OMAP: ISP1301 needs USB_PHY
  USB: OHCI: avoid conflicting platform drivers

 arch/arm/Kconfig                                   |   1 -
 arch/arm/configs/lpc32xx_defconfig                 |   1 +
 arch/arm/configs/msm_defconfig                     |   1 +
 arch/arm/configs/omap1_defconfig                   |   1 +
 arch/arm/kernel/devtree.c                          |   7 ++
 arch/arm/kernel/setup.c                            |  11 +-
 arch/arm/kernel/topology.c                         |   1 +
 arch/arm/mach-orion5x/common.c                     |   1 +
 arch/arm/mach-shmobile/intc-r8a7740.c              |  13 +-
 drivers/atm/he.c                                   |   2 +-
 drivers/cpufreq/pxa2xx-cpufreq.c                   |   5 +-
 drivers/gpu/drm/drm_vm.c                           |   1 +
 drivers/gpu/drm/nouveau/core/engine/disp/dacnv50.c |   3 +-
 drivers/iommu/tegra-gart.c                         |   3 +-
 drivers/iommu/tegra-smmu.c                         |   2 +-
 drivers/irqchip/irq-s3c24xx.c                      |   4 +-
 drivers/scsi/nsp32.c                               |   2 +-
 drivers/thermal/cpu_cooling.c                      |  17 +--
 drivers/usb/gadget/Kconfig                         |   2 +
 drivers/usb/host/Kconfig                           |   1 +
 drivers/usb/host/ohci-hcd.c                        | 136 ++++++++++++++++++---
 drivers/usb/phy/Makefile                           |   2 +-
 include/linux/of_platform.h                        |  13 +-
 kernel/irq/irqdomain.c                             |   1 +
 lib/build_OID_registry                             |   2 -
 sound/oss/dmabuf.c                                 |   3 +-
 sound/pci/ali5451/ali5451.c                        |   8 +-
 27 files changed, 187 insertions(+), 57 deletions(-)

-- 
1.8.1.2

Cc: "James E.J. Bottomley" <JBottomley@parallels.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: David Airlie <airlied@linux.ie>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Nicolas Pitre <nico@linaro.org>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Rob Herring <robherring2@gmail.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Simon Horman <horms+renesas@verge.net.au>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Will Deacon <will.deacon@arm.com>
Cc: alsa-devel@alsa-project.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-atm-general@lists.sourceforge.net
Cc: linux-scsi@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Cc: netdev@vger.kernel.org

^ permalink raw reply	[flat|nested] 131+ messages in thread

* [PATCH 00/21] more arm build fixes
@ 2013-04-25 17:28 ` Arnd Bergmann
  0 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:28 UTC (permalink / raw)
  To: linux-arm-kernel

Hi subsystem maintainers,

Here is another set of patches that resulted from build testing on
linux-next. Please apply directly into your trees if you agree,
or let me know if I made a mistake.

I can take whatever remains through the arm-soc tree if you prefer
that or I don't hear back.

	Arnd


Arnd Bergmann (21):
  ARM: topology: export cpu_topology
  ARM: default machine descriptor for multiplatform
  ARM: shmobile: don't call irqchip_init unconditionally
  ARM: orion5x: include linux/cpu.h
  atm: he: use mdelay instead of large udelay constants
  ALSA: ali5451: use mdelay instead of large udelay constants
  oss/dmabuf: use dma_map_single
  drm/nouveau: use mdelay instead of large udelay constants
  drm: export drm_vm_open_locked
  [SCSI] nsp32: use mdelay instead of large udelay constants
  irqdomain: export irq_domain_add_simple
  irqchip: s3c24xx: add missing __init annotations
  iommu: tegra: print dma_addr_t using %lld
  cpufreq: pxa2xx: initialize variables
  thermal: cooling: avoid uninitialied used gcc warning
  OF: remove #ifdef from linux/of_platform.h
  X.509: do not emit any informational output
  USB: ehci-msm: USB_MSM_OTG needs USB_PHY
  USB: lpc32xx: ISP1301 needs USB_PHY
  USB: OMAP: ISP1301 needs USB_PHY
  USB: OHCI: avoid conflicting platform drivers

 arch/arm/Kconfig                                   |   1 -
 arch/arm/configs/lpc32xx_defconfig                 |   1 +
 arch/arm/configs/msm_defconfig                     |   1 +
 arch/arm/configs/omap1_defconfig                   |   1 +
 arch/arm/kernel/devtree.c                          |   7 ++
 arch/arm/kernel/setup.c                            |  11 +-
 arch/arm/kernel/topology.c                         |   1 +
 arch/arm/mach-orion5x/common.c                     |   1 +
 arch/arm/mach-shmobile/intc-r8a7740.c              |  13 +-
 drivers/atm/he.c                                   |   2 +-
 drivers/cpufreq/pxa2xx-cpufreq.c                   |   5 +-
 drivers/gpu/drm/drm_vm.c                           |   1 +
 drivers/gpu/drm/nouveau/core/engine/disp/dacnv50.c |   3 +-
 drivers/iommu/tegra-gart.c                         |   3 +-
 drivers/iommu/tegra-smmu.c                         |   2 +-
 drivers/irqchip/irq-s3c24xx.c                      |   4 +-
 drivers/scsi/nsp32.c                               |   2 +-
 drivers/thermal/cpu_cooling.c                      |  17 +--
 drivers/usb/gadget/Kconfig                         |   2 +
 drivers/usb/host/Kconfig                           |   1 +
 drivers/usb/host/ohci-hcd.c                        | 136 ++++++++++++++++++---
 drivers/usb/phy/Makefile                           |   2 +-
 include/linux/of_platform.h                        |  13 +-
 kernel/irq/irqdomain.c                             |   1 +
 lib/build_OID_registry                             |   2 -
 sound/oss/dmabuf.c                                 |   3 +-
 sound/pci/ali5451/ali5451.c                        |   8 +-
 27 files changed, 187 insertions(+), 57 deletions(-)

-- 
1.8.1.2

Cc: "James E.J. Bottomley" <JBottomley@parallels.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: David Airlie <airlied@linux.ie>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Nicolas Pitre <nico@linaro.org>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Rob Herring <robherring2@gmail.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Simon Horman <horms+renesas@verge.net.au>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Will Deacon <will.deacon@arm.com>
Cc: alsa-devel at alsa-project.org
Cc: dri-devel at lists.freedesktop.org
Cc: linux-atm-general at lists.sourceforge.net
Cc: linux-scsi at vger.kernel.org
Cc: linux-usb at vger.kernel.org
Cc: netdev at vger.kernel.org

^ permalink raw reply	[flat|nested] 131+ messages in thread

* [PATCH 01/21] ARM: topology: export cpu_topology
  2013-04-25 17:28 ` Arnd Bergmann
@ 2013-04-25 17:28   ` Arnd Bergmann
  -1 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:28 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: linux-kernel, Arnd Bergmann, Russell King, Will Deacon,
	Nicolas Pitre, Vincent Guittot

The cpu_topology symbol is required by any driver using the topology
interfaces, which leads to a couple of build errors:

ERROR: "cpu_topology" [drivers/net/ethernet/sfc/sfc.ko] undefined!
ERROR: "cpu_topology" [drivers/cpufreq/arm_big_little.ko] undefined!
ERROR: "cpu_topology" [drivers/block/mtip32xx/mtip32xx.ko] undefined!

The obvious solution is to export this symbol.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Nicolas Pitre <nico@linaro.org>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
---
 arch/arm/kernel/topology.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
index f10316b..7ac5714 100644
--- a/arch/arm/kernel/topology.c
+++ b/arch/arm/kernel/topology.c
@@ -200,6 +200,7 @@ static inline void update_cpu_power(unsigned int cpuid, unsigned int mpidr) {}
  * cpu topology table
  */
 struct cputopo_arm cpu_topology[NR_CPUS];
+EXPORT_SYMBOL_GPL(cpu_topology);
 
 const struct cpumask *cpu_coregroup_mask(int cpu)
 {
-- 
1.8.1.2


^ permalink raw reply related	[flat|nested] 131+ messages in thread

* [PATCH 01/21] ARM: topology: export cpu_topology
@ 2013-04-25 17:28   ` Arnd Bergmann
  0 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:28 UTC (permalink / raw)
  To: linux-arm-kernel

The cpu_topology symbol is required by any driver using the topology
interfaces, which leads to a couple of build errors:

ERROR: "cpu_topology" [drivers/net/ethernet/sfc/sfc.ko] undefined!
ERROR: "cpu_topology" [drivers/cpufreq/arm_big_little.ko] undefined!
ERROR: "cpu_topology" [drivers/block/mtip32xx/mtip32xx.ko] undefined!

The obvious solution is to export this symbol.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Nicolas Pitre <nico@linaro.org>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
---
 arch/arm/kernel/topology.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
index f10316b..7ac5714 100644
--- a/arch/arm/kernel/topology.c
+++ b/arch/arm/kernel/topology.c
@@ -200,6 +200,7 @@ static inline void update_cpu_power(unsigned int cpuid, unsigned int mpidr) {}
  * cpu topology table
  */
 struct cputopo_arm cpu_topology[NR_CPUS];
+EXPORT_SYMBOL_GPL(cpu_topology);
 
 const struct cpumask *cpu_coregroup_mask(int cpu)
 {
-- 
1.8.1.2

^ permalink raw reply related	[flat|nested] 131+ messages in thread

* [PATCH 02/21] ARM: default machine descriptor for multiplatform
  2013-04-25 17:28 ` Arnd Bergmann
@ 2013-04-25 17:28   ` Arnd Bergmann
  -1 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:28 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: linux-kernel, Arnd Bergmann, Russell King - ARM Linux, Rob Herring

Since we now have default implementations for init_time and init_irq,
the init_machine callback is the only one that is not yet optional,
but since simple DT based platforms all have the same
of_platform_populate function call in there, we can consolidate them
as well, and then actually boot with a completely empty machine_desc.
Unofortunately we cannot just default to an empty init_machine: We
cannot call of_platform_populate before init_machine because that
does not work in case of auxdata, and we cannot call it after
init_machine either because the machine might need to run code
after adding the devices.

To take the final step, this adds support for booting without defining
any machine_desc whatsoever.

For the case that CONFIG_MULTIPLATFORM is enabled, it adds a
global machine descriptor that never matches any machine but is
used as a fallback if nothing else matches. We assume that without
CONFIG_MULTIPLATFORM, we only want to boot on the systems that the kernel
is built for, so we still retain the build-time warning for missing
machine descriptors and the run-time warning when the platform does not
match in that case.

In the case that we run on a multiplatform kernel and the machine
provides a fully populated device tree, we attempt to keep booting,
hoping that no machine specific callbacks are necessary.

Finally, this also removes the misguided "select ARCH_VEXPRESS" that
was only added to avoid a build error for allnoconfig kernels.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Nicolas Pitre <nico@linaro.org>
Acked-by: Olof Johansson <olof@lixom.net>
Cc: "Russell King - ARM Linux" <linux@arm.linux.org.uk>
Cc: Rob Herring <robherring2@gmail.com>
---
 arch/arm/Kconfig          |  1 -
 arch/arm/kernel/devtree.c |  7 +++++++
 arch/arm/kernel/setup.c   | 11 ++++++++++-
 3 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a0d58a6..8c33760 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -890,7 +890,6 @@ config ARCH_MULTI_V7
 	bool "ARMv7 based platforms (Cortex-A, PJ4, Scorpion, Krait)"
 	default y
 	select ARCH_MULTI_V6_V7
-	select ARCH_VEXPRESS
 	select CPU_V7
 
 config ARCH_MULTI_V6_V7
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 70f1bde..5af04f6 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -180,6 +180,13 @@ struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
 	unsigned long dt_root;
 	const char *model;
 
+#ifdef CONFIG_ARCH_MULTIPLATFORM
+	DT_MACHINE_START(GENERIC_DT, "Generic DT based system")
+	MACHINE_END
+
+	mdesc_best = (struct machine_desc *)&__mach_desc_GENERIC_DT;
+#endif
+
 	if (!dt_phys)
 		return NULL;
 
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 408f446..d039623 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -18,6 +18,7 @@
 #include <linux/bootmem.h>
 #include <linux/seq_file.h>
 #include <linux/screen_info.h>
+#include <linux/of_platform.h>
 #include <linux/init.h>
 #include <linux/kexec.h>
 #include <linux/of_fdt.h>
@@ -672,9 +673,17 @@ struct screen_info screen_info = {
 
 static int __init customize_machine(void)
 {
-	/* customizes platform devices, or adds new ones */
+	/*
+	 * customizes platform devices, or adds new ones
+	 * On DT based machines, we fall back to populating the
+	 * machine from the device tree, if no callback is provided,
+	 * otherwise we would always need an init_machine callback.
+	 */
 	if (machine_desc->init_machine)
 		machine_desc->init_machine();
+	else
+		of_platform_populate(NULL, of_default_bus_match_table,
+					NULL, NULL);
 	return 0;
 }
 arch_initcall(customize_machine);
-- 
1.8.1.2


^ permalink raw reply related	[flat|nested] 131+ messages in thread

* [PATCH 02/21] ARM: default machine descriptor for multiplatform
@ 2013-04-25 17:28   ` Arnd Bergmann
  0 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:28 UTC (permalink / raw)
  To: linux-arm-kernel

Since we now have default implementations for init_time and init_irq,
the init_machine callback is the only one that is not yet optional,
but since simple DT based platforms all have the same
of_platform_populate function call in there, we can consolidate them
as well, and then actually boot with a completely empty machine_desc.
Unofortunately we cannot just default to an empty init_machine: We
cannot call of_platform_populate before init_machine because that
does not work in case of auxdata, and we cannot call it after
init_machine either because the machine might need to run code
after adding the devices.

To take the final step, this adds support for booting without defining
any machine_desc whatsoever.

For the case that CONFIG_MULTIPLATFORM is enabled, it adds a
global machine descriptor that never matches any machine but is
used as a fallback if nothing else matches. We assume that without
CONFIG_MULTIPLATFORM, we only want to boot on the systems that the kernel
is built for, so we still retain the build-time warning for missing
machine descriptors and the run-time warning when the platform does not
match in that case.

In the case that we run on a multiplatform kernel and the machine
provides a fully populated device tree, we attempt to keep booting,
hoping that no machine specific callbacks are necessary.

Finally, this also removes the misguided "select ARCH_VEXPRESS" that
was only added to avoid a build error for allnoconfig kernels.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Nicolas Pitre <nico@linaro.org>
Acked-by: Olof Johansson <olof@lixom.net>
Cc: "Russell King - ARM Linux" <linux@arm.linux.org.uk>
Cc: Rob Herring <robherring2@gmail.com>
---
 arch/arm/Kconfig          |  1 -
 arch/arm/kernel/devtree.c |  7 +++++++
 arch/arm/kernel/setup.c   | 11 ++++++++++-
 3 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a0d58a6..8c33760 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -890,7 +890,6 @@ config ARCH_MULTI_V7
 	bool "ARMv7 based platforms (Cortex-A, PJ4, Scorpion, Krait)"
 	default y
 	select ARCH_MULTI_V6_V7
-	select ARCH_VEXPRESS
 	select CPU_V7
 
 config ARCH_MULTI_V6_V7
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 70f1bde..5af04f6 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -180,6 +180,13 @@ struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
 	unsigned long dt_root;
 	const char *model;
 
+#ifdef CONFIG_ARCH_MULTIPLATFORM
+	DT_MACHINE_START(GENERIC_DT, "Generic DT based system")
+	MACHINE_END
+
+	mdesc_best = (struct machine_desc *)&__mach_desc_GENERIC_DT;
+#endif
+
 	if (!dt_phys)
 		return NULL;
 
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 408f446..d039623 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -18,6 +18,7 @@
 #include <linux/bootmem.h>
 #include <linux/seq_file.h>
 #include <linux/screen_info.h>
+#include <linux/of_platform.h>
 #include <linux/init.h>
 #include <linux/kexec.h>
 #include <linux/of_fdt.h>
@@ -672,9 +673,17 @@ struct screen_info screen_info = {
 
 static int __init customize_machine(void)
 {
-	/* customizes platform devices, or adds new ones */
+	/*
+	 * customizes platform devices, or adds new ones
+	 * On DT based machines, we fall back to populating the
+	 * machine from the device tree, if no callback is provided,
+	 * otherwise we would always need an init_machine callback.
+	 */
 	if (machine_desc->init_machine)
 		machine_desc->init_machine();
+	else
+		of_platform_populate(NULL, of_default_bus_match_table,
+					NULL, NULL);
 	return 0;
 }
 arch_initcall(customize_machine);
-- 
1.8.1.2

^ permalink raw reply related	[flat|nested] 131+ messages in thread

* [PATCH 03/21] ARM: shmobile: don't call irqchip_init unconditionally
  2013-04-25 17:28 ` Arnd Bergmann
@ 2013-04-25 17:28   ` Arnd Bergmann
  -1 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:28 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: linux-kernel, Arnd Bergmann, Bastian Hecht, Simon Horman,
	Kuninori Morimoto

The irqchip_init function is only available when building
with CONFIG_OF enabled, which causes this build failure for
bonito_defconfig:

arch/arm/mach-shmobile/built-in.o: In function `r8a7740_init_irq_of':
:(.init.text+0x580): undefined reference to `irqchip_init'

This makes both the OF and the ATAGS portion of the driver
conditional, which avoids the build error and also results
in smaller object code if not both are enabled, without the
need for an #ifdef.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Bastian Hecht <hechtb+renesas@gmail.com>
Cc: Simon Horman <horms+renesas@verge.net.au>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
 arch/arm/mach-shmobile/intc-r8a7740.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-shmobile/intc-r8a7740.c b/arch/arm/mach-shmobile/intc-r8a7740.c
index 8871f77..5dc57f1 100644
--- a/arch/arm/mach-shmobile/intc-r8a7740.c
+++ b/arch/arm/mach-shmobile/intc-r8a7740.c
@@ -53,14 +53,23 @@ static void __init r8a7740_init_irq_common(void)
 
 void __init r8a7740_init_irq_of(void)
 {
+	if (!IS_ENABLED(CONFIG_OF))
+		return;
+
 	irqchip_init();
 	r8a7740_init_irq_common();
 }
 
 void __init r8a7740_init_irq(void)
 {
-	void __iomem *gic_dist_base = ioremap_nocache(0xc2800000, 0x1000);
-	void __iomem *gic_cpu_base = ioremap_nocache(0xc2000000, 0x1000);
+	void __iomem *gic_dist_base;
+	void __iomem *gic_cpu_base;
+
+	if (!IS_ENABLED(CONFIG_ATAGS))
+		return;
+
+	gic_dist_base = ioremap_nocache(0xc2800000, 0x1000);
+	gic_cpu_base = ioremap_nocache(0xc2000000, 0x1000);
 
 	/* initialize the Generic Interrupt Controller PL390 r0p0 */
 	gic_init(0, 29, gic_dist_base, gic_cpu_base);
-- 
1.8.1.2


^ permalink raw reply related	[flat|nested] 131+ messages in thread

* [PATCH 03/21] ARM: shmobile: don't call irqchip_init unconditionally
@ 2013-04-25 17:28   ` Arnd Bergmann
  0 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:28 UTC (permalink / raw)
  To: linux-arm-kernel

The irqchip_init function is only available when building
with CONFIG_OF enabled, which causes this build failure for
bonito_defconfig:

arch/arm/mach-shmobile/built-in.o: In function `r8a7740_init_irq_of':
:(.init.text+0x580): undefined reference to `irqchip_init'

This makes both the OF and the ATAGS portion of the driver
conditional, which avoids the build error and also results
in smaller object code if not both are enabled, without the
need for an #ifdef.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Bastian Hecht <hechtb+renesas@gmail.com>
Cc: Simon Horman <horms+renesas@verge.net.au>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
 arch/arm/mach-shmobile/intc-r8a7740.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-shmobile/intc-r8a7740.c b/arch/arm/mach-shmobile/intc-r8a7740.c
index 8871f77..5dc57f1 100644
--- a/arch/arm/mach-shmobile/intc-r8a7740.c
+++ b/arch/arm/mach-shmobile/intc-r8a7740.c
@@ -53,14 +53,23 @@ static void __init r8a7740_init_irq_common(void)
 
 void __init r8a7740_init_irq_of(void)
 {
+	if (!IS_ENABLED(CONFIG_OF))
+		return;
+
 	irqchip_init();
 	r8a7740_init_irq_common();
 }
 
 void __init r8a7740_init_irq(void)
 {
-	void __iomem *gic_dist_base = ioremap_nocache(0xc2800000, 0x1000);
-	void __iomem *gic_cpu_base = ioremap_nocache(0xc2000000, 0x1000);
+	void __iomem *gic_dist_base;
+	void __iomem *gic_cpu_base;
+
+	if (!IS_ENABLED(CONFIG_ATAGS))
+		return;
+
+	gic_dist_base = ioremap_nocache(0xc2800000, 0x1000);
+	gic_cpu_base = ioremap_nocache(0xc2000000, 0x1000);
 
 	/* initialize the Generic Interrupt Controller PL390 r0p0 */
 	gic_init(0, 29, gic_dist_base, gic_cpu_base);
-- 
1.8.1.2

^ permalink raw reply related	[flat|nested] 131+ messages in thread

* [PATCH 04/21] ARM: orion5x: include linux/cpu.h
  2013-04-25 17:28 ` Arnd Bergmann
@ 2013-04-25 17:28   ` Arnd Bergmann
  -1 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:28 UTC (permalink / raw)
  To: linux-arm-kernel; +Cc: linux-kernel, Arnd Bergmann, Jason Cooper, Andrew Lunn

The linux/cpu.h header is no longer implictly included in this
file, so we need to an #include statement to avoid this build
warning:

arch/arm/mach-orion5x/common.c:339:3: error: implicit declaration of function 'cpu_idle_poll_ctrl' [-Werror=implicit-function-declaration]

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

diff --git a/arch/arm/mach-orion5x/common.c b/arch/arm/mach-orion5x/common.c
index 664c97d..b97fd67 100644
--- a/arch/arm/mach-orion5x/common.c
+++ b/arch/arm/mach-orion5x/common.c
@@ -19,6 +19,7 @@
 #include <linux/ata_platform.h>
 #include <linux/delay.h>
 #include <linux/clk-provider.h>
+#include <linux/cpu.h>
 #include <net/dsa.h>
 #include <asm/page.h>
 #include <asm/setup.h>
-- 
1.8.1.2


^ permalink raw reply related	[flat|nested] 131+ messages in thread

* [PATCH 04/21] ARM: orion5x: include linux/cpu.h
@ 2013-04-25 17:28   ` Arnd Bergmann
  0 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:28 UTC (permalink / raw)
  To: linux-arm-kernel

The linux/cpu.h header is no longer implictly included in this
file, so we need to an #include statement to avoid this build
warning:

arch/arm/mach-orion5x/common.c:339:3: error: implicit declaration of function 'cpu_idle_poll_ctrl' [-Werror=implicit-function-declaration]

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

diff --git a/arch/arm/mach-orion5x/common.c b/arch/arm/mach-orion5x/common.c
index 664c97d..b97fd67 100644
--- a/arch/arm/mach-orion5x/common.c
+++ b/arch/arm/mach-orion5x/common.c
@@ -19,6 +19,7 @@
 #include <linux/ata_platform.h>
 #include <linux/delay.h>
 #include <linux/clk-provider.h>
+#include <linux/cpu.h>
 #include <net/dsa.h>
 #include <asm/page.h>
 #include <asm/setup.h>
-- 
1.8.1.2

^ permalink raw reply related	[flat|nested] 131+ messages in thread

* [PATCH 05/21] atm: he: use mdelay instead of large udelay constants
  2013-04-25 17:28 ` Arnd Bergmann
@ 2013-04-25 17:28   ` Arnd Bergmann
  -1 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:28 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: linux-kernel, Arnd Bergmann, Chas Williams, linux-atm-general, netdev

ARM cannot handle udelay for more than 2 miliseconds, so we
should use mdelay instead for those.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Chas Williams <chas@cmf.nrl.navy.mil>
Cc: linux-atm-general@lists.sourceforge.net
Cc: netdev@vger.kernel.org
---
 drivers/atm/he.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/atm/he.c b/drivers/atm/he.c
index d689126..7700061 100644
--- a/drivers/atm/he.c
+++ b/drivers/atm/he.c
@@ -1055,7 +1055,7 @@ static int he_start(struct atm_dev *dev)
 	he_writel(he_dev, 0x0, RESET_CNTL);
 	he_writel(he_dev, 0xff, RESET_CNTL);
 
-	udelay(16*1000);	/* 16 ms */
+	mdelay(16);	/* 16 ms */
 	status = he_readl(he_dev, RESET_CNTL);
 	if ((status & BOARD_RST_STATUS) == 0) {
 		hprintk("reset failed\n");
-- 
1.8.1.2


^ permalink raw reply related	[flat|nested] 131+ messages in thread

* [PATCH 05/21] atm: he: use mdelay instead of large udelay constants
@ 2013-04-25 17:28   ` Arnd Bergmann
  0 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:28 UTC (permalink / raw)
  To: linux-arm-kernel

ARM cannot handle udelay for more than 2 miliseconds, so we
should use mdelay instead for those.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Chas Williams <chas@cmf.nrl.navy.mil>
Cc: linux-atm-general at lists.sourceforge.net
Cc: netdev at vger.kernel.org
---
 drivers/atm/he.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/atm/he.c b/drivers/atm/he.c
index d689126..7700061 100644
--- a/drivers/atm/he.c
+++ b/drivers/atm/he.c
@@ -1055,7 +1055,7 @@ static int he_start(struct atm_dev *dev)
 	he_writel(he_dev, 0x0, RESET_CNTL);
 	he_writel(he_dev, 0xff, RESET_CNTL);
 
-	udelay(16*1000);	/* 16 ms */
+	mdelay(16);	/* 16 ms */
 	status = he_readl(he_dev, RESET_CNTL);
 	if ((status & BOARD_RST_STATUS) == 0) {
 		hprintk("reset failed\n");
-- 
1.8.1.2

^ permalink raw reply related	[flat|nested] 131+ messages in thread

* [PATCH 06/21] ALSA: ali5451: use mdelay instead of large udelay constants
  2013-04-25 17:28 ` Arnd Bergmann
@ 2013-04-25 17:28   ` Arnd Bergmann
  -1 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:28 UTC (permalink / raw)
  To: linux-arm-kernel; +Cc: linux-kernel, Arnd Bergmann, Takashi Iwai, alsa-devel

ARM cannot handle udelay for more than 2 miliseconds, so we
should use mdelay instead for those.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@alsa-project.org
---
 sound/pci/ali5451/ali5451.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/sound/pci/ali5451/ali5451.c b/sound/pci/ali5451/ali5451.c
index e760af9..53754f5 100644
--- a/sound/pci/ali5451/ali5451.c
+++ b/sound/pci/ali5451/ali5451.c
@@ -451,10 +451,10 @@ static int snd_ali_reset_5451(struct snd_ali *codec)
 	if (pci_dev) {
 		pci_read_config_dword(pci_dev, 0x7c, &dwVal);
 		pci_write_config_dword(pci_dev, 0x7c, dwVal | 0x08000000);
-		udelay(5000);
+		mdelay(5);
 		pci_read_config_dword(pci_dev, 0x7c, &dwVal);
 		pci_write_config_dword(pci_dev, 0x7c, dwVal & 0xf7ffffff);
-		udelay(5000);
+		mdelay(5);
 	}
 	
 	pci_dev = codec->pci;
@@ -463,14 +463,14 @@ static int snd_ali_reset_5451(struct snd_ali *codec)
 	udelay(500);
 	pci_read_config_dword(pci_dev, 0x44, &dwVal);
 	pci_write_config_dword(pci_dev, 0x44, dwVal & 0xfffbffff);
-	udelay(5000);
+	mdelay(5);
 	
 	wCount = 200;
 	while(wCount--) {
 		wReg = snd_ali_codec_peek(codec, 0, AC97_POWERDOWN);
 		if ((wReg & 0x000f) == 0x000f)
 			return 0;
-		udelay(5000);
+		mdelay(5);
 	}
 
 	/* non-fatal if you have a non PM capable codec */
-- 
1.8.1.2


^ permalink raw reply related	[flat|nested] 131+ messages in thread

* [PATCH 06/21] ALSA: ali5451: use mdelay instead of large udelay constants
@ 2013-04-25 17:28   ` Arnd Bergmann
  0 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:28 UTC (permalink / raw)
  To: linux-arm-kernel

ARM cannot handle udelay for more than 2 miliseconds, so we
should use mdelay instead for those.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel at alsa-project.org
---
 sound/pci/ali5451/ali5451.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/sound/pci/ali5451/ali5451.c b/sound/pci/ali5451/ali5451.c
index e760af9..53754f5 100644
--- a/sound/pci/ali5451/ali5451.c
+++ b/sound/pci/ali5451/ali5451.c
@@ -451,10 +451,10 @@ static int snd_ali_reset_5451(struct snd_ali *codec)
 	if (pci_dev) {
 		pci_read_config_dword(pci_dev, 0x7c, &dwVal);
 		pci_write_config_dword(pci_dev, 0x7c, dwVal | 0x08000000);
-		udelay(5000);
+		mdelay(5);
 		pci_read_config_dword(pci_dev, 0x7c, &dwVal);
 		pci_write_config_dword(pci_dev, 0x7c, dwVal & 0xf7ffffff);
-		udelay(5000);
+		mdelay(5);
 	}
 	
 	pci_dev = codec->pci;
@@ -463,14 +463,14 @@ static int snd_ali_reset_5451(struct snd_ali *codec)
 	udelay(500);
 	pci_read_config_dword(pci_dev, 0x44, &dwVal);
 	pci_write_config_dword(pci_dev, 0x44, dwVal & 0xfffbffff);
-	udelay(5000);
+	mdelay(5);
 	
 	wCount = 200;
 	while(wCount--) {
 		wReg = snd_ali_codec_peek(codec, 0, AC97_POWERDOWN);
 		if ((wReg & 0x000f) == 0x000f)
 			return 0;
-		udelay(5000);
+		mdelay(5);
 	}
 
 	/* non-fatal if you have a non PM capable codec */
-- 
1.8.1.2

^ permalink raw reply related	[flat|nested] 131+ messages in thread

* [PATCH 07/21] oss/dmabuf: use dma_map_single
  2013-04-25 17:28 ` Arnd Bergmann
@ 2013-04-25 17:28   ` Arnd Bergmann
  -1 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:28 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: linux-kernel, Arnd Bergmann, Jaroslav Kysela, Takashi Iwai, alsa-devel

The virt_to_bus/bus_to_virt functions have been deprecated
for as long as I can remember, and they are used in very
few remaining instances, usually in obscure ISA device
drivers. The OSS sound drivers are the only ones that are
still used on the ARM architecture, and only on some of
the earliest StrongARM machines.

The problem for converting the OSS subsystem to use
dma_map_single instead is that the caller of virt_to_bus
does not have a device pointer, since the subsystem has
never been ported to use the common device infrastructure.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@alsa-project.org
---
 sound/oss/dmabuf.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/sound/oss/dmabuf.c b/sound/oss/dmabuf.c
index bcc3e8e..a59c888 100644
--- a/sound/oss/dmabuf.c
+++ b/sound/oss/dmabuf.c
@@ -114,7 +114,7 @@ static int sound_alloc_dmap(struct dma_buffparms *dmap)
 		}
 	}
 	dmap->raw_buf = start_addr;
-	dmap->raw_buf_phys = virt_to_bus(start_addr);
+	dmap->raw_buf_phys = dma_map_single(NULL, start_addr, dmap->buffsize, DMA_BIDIRECTIONAL);
 
 	for (page = virt_to_page(start_addr); page <= virt_to_page(end_addr); page++)
 		SetPageReserved(page);
@@ -139,6 +139,7 @@ static void sound_free_dmap(struct dma_buffparms *dmap)
 	for (page = virt_to_page(start_addr); page <= virt_to_page(end_addr); page++)
 		ClearPageReserved(page);
 
+	dma_unmap_single(NULL, dmap->raw_buf_phys, dmap->buffsize, DMA_BIDIRECTIONAL);
 	free_pages((unsigned long) dmap->raw_buf, sz);
 	dmap->raw_buf = NULL;
 }
-- 
1.8.1.2


^ permalink raw reply related	[flat|nested] 131+ messages in thread

* [PATCH 07/21] oss/dmabuf: use dma_map_single
@ 2013-04-25 17:28   ` Arnd Bergmann
  0 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:28 UTC (permalink / raw)
  To: linux-arm-kernel

The virt_to_bus/bus_to_virt functions have been deprecated
for as long as I can remember, and they are used in very
few remaining instances, usually in obscure ISA device
drivers. The OSS sound drivers are the only ones that are
still used on the ARM architecture, and only on some of
the earliest StrongARM machines.

The problem for converting the OSS subsystem to use
dma_map_single instead is that the caller of virt_to_bus
does not have a device pointer, since the subsystem has
never been ported to use the common device infrastructure.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel at alsa-project.org
---
 sound/oss/dmabuf.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/sound/oss/dmabuf.c b/sound/oss/dmabuf.c
index bcc3e8e..a59c888 100644
--- a/sound/oss/dmabuf.c
+++ b/sound/oss/dmabuf.c
@@ -114,7 +114,7 @@ static int sound_alloc_dmap(struct dma_buffparms *dmap)
 		}
 	}
 	dmap->raw_buf = start_addr;
-	dmap->raw_buf_phys = virt_to_bus(start_addr);
+	dmap->raw_buf_phys = dma_map_single(NULL, start_addr, dmap->buffsize, DMA_BIDIRECTIONAL);
 
 	for (page = virt_to_page(start_addr); page <= virt_to_page(end_addr); page++)
 		SetPageReserved(page);
@@ -139,6 +139,7 @@ static void sound_free_dmap(struct dma_buffparms *dmap)
 	for (page = virt_to_page(start_addr); page <= virt_to_page(end_addr); page++)
 		ClearPageReserved(page);
 
+	dma_unmap_single(NULL, dmap->raw_buf_phys, dmap->buffsize, DMA_BIDIRECTIONAL);
 	free_pages((unsigned long) dmap->raw_buf, sz);
 	dmap->raw_buf = NULL;
 }
-- 
1.8.1.2

^ permalink raw reply related	[flat|nested] 131+ messages in thread

* [PATCH 08/21] drm/nouveau: use mdelay instead of large udelay constants
  2013-04-25 17:28 ` Arnd Bergmann
  (?)
@ 2013-04-25 17:28   ` Arnd Bergmann
  -1 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:28 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: linux-kernel, Arnd Bergmann, David Airlie, Ben Skeggs, dri-devel

ARM cannot handle udelay for more than 2 miliseconds, so we
should use mdelay instead for those.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: David Airlie <airlied@linux.ie>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: dri-devel@lists.freedesktop.org
---
 drivers/gpu/drm/nouveau/core/engine/disp/dacnv50.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/dacnv50.c b/drivers/gpu/drm/nouveau/core/engine/disp/dacnv50.c
index d0817d9..ed7415e 100644
--- a/drivers/gpu/drm/nouveau/core/engine/disp/dacnv50.c
+++ b/drivers/gpu/drm/nouveau/core/engine/disp/dacnv50.c
@@ -51,7 +51,8 @@ nv50_dac_sense(struct nv50_disp_priv *priv, int or, u32 loadval)
 	const u32 doff = (or * 0x800);
 	int load = -EINVAL;
 	nv_wr32(priv, 0x61a00c + doff, 0x00100000 | loadval);
-	udelay(9500);
+	mdelay(9);
+	udelay(500);
 	nv_wr32(priv, 0x61a00c + doff, 0x80000000);
 	load = (nv_rd32(priv, 0x61a00c + doff) & 0x38000000) >> 27;
 	nv_wr32(priv, 0x61a00c + doff, 0x00000000);
-- 
1.8.1.2


^ permalink raw reply related	[flat|nested] 131+ messages in thread

* [PATCH 08/21] drm/nouveau: use mdelay instead of large udelay constants
@ 2013-04-25 17:28   ` Arnd Bergmann
  0 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:28 UTC (permalink / raw)
  To: linux-arm-kernel

ARM cannot handle udelay for more than 2 miliseconds, so we
should use mdelay instead for those.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: David Airlie <airlied@linux.ie>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: dri-devel at lists.freedesktop.org
---
 drivers/gpu/drm/nouveau/core/engine/disp/dacnv50.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/dacnv50.c b/drivers/gpu/drm/nouveau/core/engine/disp/dacnv50.c
index d0817d9..ed7415e 100644
--- a/drivers/gpu/drm/nouveau/core/engine/disp/dacnv50.c
+++ b/drivers/gpu/drm/nouveau/core/engine/disp/dacnv50.c
@@ -51,7 +51,8 @@ nv50_dac_sense(struct nv50_disp_priv *priv, int or, u32 loadval)
 	const u32 doff = (or * 0x800);
 	int load = -EINVAL;
 	nv_wr32(priv, 0x61a00c + doff, 0x00100000 | loadval);
-	udelay(9500);
+	mdelay(9);
+	udelay(500);
 	nv_wr32(priv, 0x61a00c + doff, 0x80000000);
 	load = (nv_rd32(priv, 0x61a00c + doff) & 0x38000000) >> 27;
 	nv_wr32(priv, 0x61a00c + doff, 0x00000000);
-- 
1.8.1.2

^ permalink raw reply related	[flat|nested] 131+ messages in thread

* [PATCH 08/21] drm/nouveau: use mdelay instead of large udelay constants
@ 2013-04-25 17:28   ` Arnd Bergmann
  0 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:28 UTC (permalink / raw)
  To: linux-arm-kernel; +Cc: dri-devel, linux-kernel, Arnd Bergmann, Ben Skeggs

ARM cannot handle udelay for more than 2 miliseconds, so we
should use mdelay instead for those.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: David Airlie <airlied@linux.ie>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: dri-devel@lists.freedesktop.org
---
 drivers/gpu/drm/nouveau/core/engine/disp/dacnv50.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/dacnv50.c b/drivers/gpu/drm/nouveau/core/engine/disp/dacnv50.c
index d0817d9..ed7415e 100644
--- a/drivers/gpu/drm/nouveau/core/engine/disp/dacnv50.c
+++ b/drivers/gpu/drm/nouveau/core/engine/disp/dacnv50.c
@@ -51,7 +51,8 @@ nv50_dac_sense(struct nv50_disp_priv *priv, int or, u32 loadval)
 	const u32 doff = (or * 0x800);
 	int load = -EINVAL;
 	nv_wr32(priv, 0x61a00c + doff, 0x00100000 | loadval);
-	udelay(9500);
+	mdelay(9);
+	udelay(500);
 	nv_wr32(priv, 0x61a00c + doff, 0x80000000);
 	load = (nv_rd32(priv, 0x61a00c + doff) & 0x38000000) >> 27;
 	nv_wr32(priv, 0x61a00c + doff, 0x00000000);
-- 
1.8.1.2

^ permalink raw reply related	[flat|nested] 131+ messages in thread

* [PATCH 09/21] drm: export drm_vm_open_locked
  2013-04-25 17:28 ` Arnd Bergmann
  (?)
@ 2013-04-25 17:28   ` Arnd Bergmann
  -1 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:28 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: linux-kernel, Arnd Bergmann, David Airlie, dri-devel, Inki Dae,
	Joonyoung Shim, Seung-Woo Kim, Kyungmin Park

The EXYNOS DRM driver uses drm_vm_open_locked in its mmap() function,
and it can be built as a loadable module, which currently fails.
This exports the symbol from the DRM core to avoid

ERROR: "drm_vm_open_locked" [drivers/gpu/drm/exynos/exynosdrm.ko] undefined!

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

diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
index db7bd29..1d4f7c9 100644
--- a/drivers/gpu/drm/drm_vm.c
+++ b/drivers/gpu/drm/drm_vm.c
@@ -422,6 +422,7 @@ void drm_vm_open_locked(struct drm_device *dev,
 		list_add(&vma_entry->head, &dev->vmalist);
 	}
 }
+EXPORT_SYMBOL_GPL(drm_vm_open_locked);
 
 static void drm_vm_open(struct vm_area_struct *vma)
 {
-- 
1.8.1.2


^ permalink raw reply related	[flat|nested] 131+ messages in thread

* [PATCH 09/21] drm: export drm_vm_open_locked
@ 2013-04-25 17:28   ` Arnd Bergmann
  0 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:28 UTC (permalink / raw)
  To: linux-arm-kernel

The EXYNOS DRM driver uses drm_vm_open_locked in its mmap() function,
and it can be built as a loadable module, which currently fails.
This exports the symbol from the DRM core to avoid

ERROR: "drm_vm_open_locked" [drivers/gpu/drm/exynos/exynosdrm.ko] undefined!

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

diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
index db7bd29..1d4f7c9 100644
--- a/drivers/gpu/drm/drm_vm.c
+++ b/drivers/gpu/drm/drm_vm.c
@@ -422,6 +422,7 @@ void drm_vm_open_locked(struct drm_device *dev,
 		list_add(&vma_entry->head, &dev->vmalist);
 	}
 }
+EXPORT_SYMBOL_GPL(drm_vm_open_locked);
 
 static void drm_vm_open(struct vm_area_struct *vma)
 {
-- 
1.8.1.2

^ permalink raw reply related	[flat|nested] 131+ messages in thread

* [PATCH 09/21] drm: export drm_vm_open_locked
@ 2013-04-25 17:28   ` Arnd Bergmann
  0 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:28 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: Arnd Bergmann, Seung-Woo Kim, linux-kernel, dri-devel, Kyungmin Park

The EXYNOS DRM driver uses drm_vm_open_locked in its mmap() function,
and it can be built as a loadable module, which currently fails.
This exports the symbol from the DRM core to avoid

ERROR: "drm_vm_open_locked" [drivers/gpu/drm/exynos/exynosdrm.ko] undefined!

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

diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
index db7bd29..1d4f7c9 100644
--- a/drivers/gpu/drm/drm_vm.c
+++ b/drivers/gpu/drm/drm_vm.c
@@ -422,6 +422,7 @@ void drm_vm_open_locked(struct drm_device *dev,
 		list_add(&vma_entry->head, &dev->vmalist);
 	}
 }
+EXPORT_SYMBOL_GPL(drm_vm_open_locked);
 
 static void drm_vm_open(struct vm_area_struct *vma)
 {
-- 
1.8.1.2

^ permalink raw reply related	[flat|nested] 131+ messages in thread

* [PATCH 10/21] [SCSI] nsp32: use mdelay instead of large udelay constants
  2013-04-25 17:28 ` Arnd Bergmann
@ 2013-04-25 17:28   ` Arnd Bergmann
  -1 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:28 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: linux-kernel, Arnd Bergmann, GOTO Masanori, YOKOTA Hiroshi,
	James E.J. Bottomley, linux-scsi

ARM cannot handle udelay for more than 2 miliseconds, so we
should use mdelay instead for those.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: GOTO Masanori <gotom@debian.or.jp>
Cc: YOKOTA Hiroshi <yokota@netlab.is.tsukuba.ac.jp>
Cc: "James E.J. Bottomley" <JBottomley@parallels.com>
Cc: linux-scsi@vger.kernel.org
---
 drivers/scsi/nsp32.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/nsp32.c b/drivers/scsi/nsp32.c
index 1e3879d..0665f9c 100644
--- a/drivers/scsi/nsp32.c
+++ b/drivers/scsi/nsp32.c
@@ -2899,7 +2899,7 @@ static void nsp32_do_bus_reset(nsp32_hw_data *data)
 	 * reset SCSI bus
 	 */
 	nsp32_write1(base, SCSI_BUS_CONTROL, BUSCTL_RST);
-	udelay(RESET_HOLD_TIME);
+	mdelay(RESET_HOLD_TIME / 1000);
 	nsp32_write1(base, SCSI_BUS_CONTROL, 0);
 	for(i = 0; i < 5; i++) {
 		intrdat = nsp32_read2(base, IRQ_STATUS); /* dummy read */
-- 
1.8.1.2


^ permalink raw reply related	[flat|nested] 131+ messages in thread

* [PATCH 10/21] [SCSI] nsp32: use mdelay instead of large udelay constants
@ 2013-04-25 17:28   ` Arnd Bergmann
  0 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:28 UTC (permalink / raw)
  To: linux-arm-kernel

ARM cannot handle udelay for more than 2 miliseconds, so we
should use mdelay instead for those.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: GOTO Masanori <gotom@debian.or.jp>
Cc: YOKOTA Hiroshi <yokota@netlab.is.tsukuba.ac.jp>
Cc: "James E.J. Bottomley" <JBottomley@parallels.com>
Cc: linux-scsi at vger.kernel.org
---
 drivers/scsi/nsp32.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/nsp32.c b/drivers/scsi/nsp32.c
index 1e3879d..0665f9c 100644
--- a/drivers/scsi/nsp32.c
+++ b/drivers/scsi/nsp32.c
@@ -2899,7 +2899,7 @@ static void nsp32_do_bus_reset(nsp32_hw_data *data)
 	 * reset SCSI bus
 	 */
 	nsp32_write1(base, SCSI_BUS_CONTROL, BUSCTL_RST);
-	udelay(RESET_HOLD_TIME);
+	mdelay(RESET_HOLD_TIME / 1000);
 	nsp32_write1(base, SCSI_BUS_CONTROL, 0);
 	for(i = 0; i < 5; i++) {
 		intrdat = nsp32_read2(base, IRQ_STATUS); /* dummy read */
-- 
1.8.1.2

^ permalink raw reply related	[flat|nested] 131+ messages in thread

* [PATCH 11/21] irqdomain: export irq_domain_add_simple
  2013-04-25 17:28 ` Arnd Bergmann
@ 2013-04-25 17:28   ` Arnd Bergmann
  -1 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:28 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: linux-kernel, Arnd Bergmann, Benjamin Herrenschmidt,
	Grant Likely, Thomas Gleixner, Simon Horman, Laurent Pinchart,
	Magnus Damm

All other irq_domain_add_* functions are exported already, and apparently
this one got left out by mistake, which causes build errors for ARM
allmodconfig kernels:

ERROR: "irq_domain_add_simple" [drivers/gpio/gpio-rcar.ko] undefined!
ERROR: "irq_domain_add_simple" [drivers/gpio/gpio-em.ko] undefined!

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Simon Horman <horms+renesas@verge.net.au>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Cc: Magnus Damm <damm@opensource.se>
---
 kernel/irq/irqdomain.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 059a280..c532c15 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -194,6 +194,7 @@ struct irq_domain *irq_domain_add_simple(struct device_node *of_node,
 	/* A linear domain is the default */
 	return irq_domain_add_linear(of_node, size, ops, host_data);
 }
+EXPORT_SYMBOL_GPL(irq_domain_add_simple);
 
 /**
  * irq_domain_add_legacy() - Allocate and register a legacy revmap irq_domain.
-- 
1.8.1.2


^ permalink raw reply related	[flat|nested] 131+ messages in thread

* [PATCH 11/21] irqdomain: export irq_domain_add_simple
@ 2013-04-25 17:28   ` Arnd Bergmann
  0 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:28 UTC (permalink / raw)
  To: linux-arm-kernel

All other irq_domain_add_* functions are exported already, and apparently
this one got left out by mistake, which causes build errors for ARM
allmodconfig kernels:

ERROR: "irq_domain_add_simple" [drivers/gpio/gpio-rcar.ko] undefined!
ERROR: "irq_domain_add_simple" [drivers/gpio/gpio-em.ko] undefined!

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Simon Horman <horms+renesas@verge.net.au>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Cc: Magnus Damm <damm@opensource.se>
---
 kernel/irq/irqdomain.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 059a280..c532c15 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -194,6 +194,7 @@ struct irq_domain *irq_domain_add_simple(struct device_node *of_node,
 	/* A linear domain is the default */
 	return irq_domain_add_linear(of_node, size, ops, host_data);
 }
+EXPORT_SYMBOL_GPL(irq_domain_add_simple);
 
 /**
  * irq_domain_add_legacy() - Allocate and register a legacy revmap irq_domain.
-- 
1.8.1.2

^ permalink raw reply related	[flat|nested] 131+ messages in thread

* [PATCH 12/21] irqchip: s3c24xx: add missing __init annotations
  2013-04-25 17:28 ` Arnd Bergmann
@ 2013-04-25 17:28   ` Arnd Bergmann
  -1 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:28 UTC (permalink / raw)
  To: linux-arm-kernel; +Cc: linux-kernel, Arnd Bergmann, Heiko Stuebner, Kukjin Kim

The s3c24xx_init_intc and s3c2412_init_irq functions are only called
at init time, and they call functions already marked __init, so they
should be marked in the same way. This was reported as

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

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: Kukjin Kim <kgene.kim@samsung.com>
---
 drivers/irqchip/irq-s3c24xx.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-s3c24xx.c b/drivers/irqchip/irq-s3c24xx.c
index c8afd7b..bbcc944 100644
--- a/drivers/irqchip/irq-s3c24xx.c
+++ b/drivers/irqchip/irq-s3c24xx.c
@@ -535,7 +535,7 @@ static void s3c24xx_clear_intc(struct s3c_irq_intc *intc)
 	}
 }
 
-static struct s3c_irq_intc *s3c24xx_init_intc(struct device_node *np,
+static struct s3c_irq_intc * __init s3c24xx_init_intc(struct device_node *np,
 				       struct s3c_irq_data *irq_data,
 				       struct s3c_irq_intc *parent,
 				       unsigned long address)
@@ -795,7 +795,7 @@ static struct s3c_irq_data init_s3c2412subint[32] = {
 	{ .type = S3C_IRQTYPE_LEVEL, .parent_irq = 21 }, /* CF */
 };
 
-void s3c2412_init_irq(void)
+void __init s3c2412_init_irq(void)
 {
 	pr_info("S3C2412: IRQ Support\n");
 
-- 
1.8.1.2


^ permalink raw reply related	[flat|nested] 131+ messages in thread

* [PATCH 12/21] irqchip: s3c24xx: add missing __init annotations
@ 2013-04-25 17:28   ` Arnd Bergmann
  0 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:28 UTC (permalink / raw)
  To: linux-arm-kernel

The s3c24xx_init_intc and s3c2412_init_irq functions are only called
at init time, and they call functions already marked __init, so they
should be marked in the same way. This was reported as

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

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: Kukjin Kim <kgene.kim@samsung.com>
---
 drivers/irqchip/irq-s3c24xx.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-s3c24xx.c b/drivers/irqchip/irq-s3c24xx.c
index c8afd7b..bbcc944 100644
--- a/drivers/irqchip/irq-s3c24xx.c
+++ b/drivers/irqchip/irq-s3c24xx.c
@@ -535,7 +535,7 @@ static void s3c24xx_clear_intc(struct s3c_irq_intc *intc)
 	}
 }
 
-static struct s3c_irq_intc *s3c24xx_init_intc(struct device_node *np,
+static struct s3c_irq_intc * __init s3c24xx_init_intc(struct device_node *np,
 				       struct s3c_irq_data *irq_data,
 				       struct s3c_irq_intc *parent,
 				       unsigned long address)
@@ -795,7 +795,7 @@ static struct s3c_irq_data init_s3c2412subint[32] = {
 	{ .type = S3C_IRQTYPE_LEVEL, .parent_irq = 21 }, /* CF */
 };
 
-void s3c2412_init_irq(void)
+void __init s3c2412_init_irq(void)
 {
 	pr_info("S3C2412: IRQ Support\n");
 
-- 
1.8.1.2

^ permalink raw reply related	[flat|nested] 131+ messages in thread

* [PATCH 13/21] iommu: tegra: print dma_addr_t using %lld
  2013-04-25 17:28 ` Arnd Bergmann
@ 2013-04-25 17:28   ` Arnd Bergmann
  -1 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:28 UTC (permalink / raw)
  To: linux-arm-kernel; +Cc: linux-kernel, Arnd Bergmann, Varun Sethi, Joerg Roedel

The code was recently changed to work for builds with a 64 bit
dma_addr_t, but the printk unconditionally uses a format
string for an "long" variable, which is always wrong as
the dma_add_t is now either 'unsigned int' or 'unsigned long long'
depending on configuration.

The easiest solution is to cast the variable to u64 and print
it as a 64 bit value.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Varun Sethi <Varun.Sethi@freescale.com>
Cc: Joerg Roedel <joro@8bytes.org>
---
 drivers/iommu/tegra-gart.c | 3 ++-
 drivers/iommu/tegra-smmu.c | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/tegra-gart.c b/drivers/iommu/tegra-gart.c
index 4aec8be..ebbdd82 100644
--- a/drivers/iommu/tegra-gart.c
+++ b/drivers/iommu/tegra-gart.c
@@ -295,7 +295,8 @@ static phys_addr_t gart_iommu_iova_to_phys(struct iommu_domain *domain,
 
 	pa = (pte & GART_PAGE_MASK);
 	if (!pfn_valid(__phys_to_pfn(pa))) {
-		dev_err(gart->dev, "No entry for %08lx:%08x\n", iova, pa);
+		dev_err(gart->dev, "No entry for %08llx:%pa\n",
+				(u64)iova, &pa);
 		gart_dump_table(gart);
 		return -EINVAL;
 	}
diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
index bc9b599..ef2a120 100644
--- a/drivers/iommu/tegra-smmu.c
+++ b/drivers/iommu/tegra-smmu.c
@@ -772,7 +772,7 @@ static phys_addr_t smmu_iommu_iova_to_phys(struct iommu_domain *domain,
 	pfn = *pte & SMMU_PFN_MASK;
 	WARN_ON(!pfn_valid(pfn));
 	dev_dbg(as->smmu->dev,
-		"iova:%08lx pfn:%08lx asid:%d\n", iova, pfn, as->asid);
+		"iova:%08llx pfn:%08lx asid:%d\n", (u64)iova, pfn, as->asid);
 
 	spin_unlock_irqrestore(&as->lock, flags);
 	return PFN_PHYS(pfn);
-- 
1.8.1.2


^ permalink raw reply related	[flat|nested] 131+ messages in thread

* [PATCH 13/21] iommu: tegra: print dma_addr_t using %lld
@ 2013-04-25 17:28   ` Arnd Bergmann
  0 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:28 UTC (permalink / raw)
  To: linux-arm-kernel

The code was recently changed to work for builds with a 64 bit
dma_addr_t, but the printk unconditionally uses a format
string for an "long" variable, which is always wrong as
the dma_add_t is now either 'unsigned int' or 'unsigned long long'
depending on configuration.

The easiest solution is to cast the variable to u64 and print
it as a 64 bit value.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Varun Sethi <Varun.Sethi@freescale.com>
Cc: Joerg Roedel <joro@8bytes.org>
---
 drivers/iommu/tegra-gart.c | 3 ++-
 drivers/iommu/tegra-smmu.c | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/tegra-gart.c b/drivers/iommu/tegra-gart.c
index 4aec8be..ebbdd82 100644
--- a/drivers/iommu/tegra-gart.c
+++ b/drivers/iommu/tegra-gart.c
@@ -295,7 +295,8 @@ static phys_addr_t gart_iommu_iova_to_phys(struct iommu_domain *domain,
 
 	pa = (pte & GART_PAGE_MASK);
 	if (!pfn_valid(__phys_to_pfn(pa))) {
-		dev_err(gart->dev, "No entry for %08lx:%08x\n", iova, pa);
+		dev_err(gart->dev, "No entry for %08llx:%pa\n",
+				(u64)iova, &pa);
 		gart_dump_table(gart);
 		return -EINVAL;
 	}
diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
index bc9b599..ef2a120 100644
--- a/drivers/iommu/tegra-smmu.c
+++ b/drivers/iommu/tegra-smmu.c
@@ -772,7 +772,7 @@ static phys_addr_t smmu_iommu_iova_to_phys(struct iommu_domain *domain,
 	pfn = *pte & SMMU_PFN_MASK;
 	WARN_ON(!pfn_valid(pfn));
 	dev_dbg(as->smmu->dev,
-		"iova:%08lx pfn:%08lx asid:%d\n", iova, pfn, as->asid);
+		"iova:%08llx pfn:%08lx asid:%d\n", (u64)iova, pfn, as->asid);
 
 	spin_unlock_irqrestore(&as->lock, flags);
 	return PFN_PHYS(pfn);
-- 
1.8.1.2

^ permalink raw reply related	[flat|nested] 131+ messages in thread

* [PATCH 14/21] cpufreq: pxa2xx: initialize variables
  2013-04-25 17:28 ` Arnd Bergmann
@ 2013-04-25 17:28   ` Arnd Bergmann
  -1 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:28 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: linux-kernel, Arnd Bergmann, Viresh Kumar, Rafael J. Wysocki

gcc-3.8 correctly found that the variables set by find_freq_tables()
are not initialized if this function is called on something other
than a pxa2xx or pxa3xx:

pxa2xx-cpufreq.c: In function 'pxa_verify_policy':
pxa2xx-cpufreq.c:272:6: warning: 'pxa_freqs_table' may be used uninitialized in this function [-Wmaybe-uninitialized]
pxa2xx-cpufreq.c: In function 'pxa_set_target':
pxa2xx-cpufreq.c:345:23: warning: 'pxa_freq_settings' may be used uninitialized in this function [-Wmaybe-uninitialized]

Rather than adding a bogus initialization that would let us
get a little further before crashing, add an explicit BUG().
We know that this code is designed to run on only these cpus,
so this will fix the build warning and give a more helpful
diagnostic if the code ever changes to run on other machines.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
 drivers/cpufreq/pxa2xx-cpufreq.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/cpufreq/pxa2xx-cpufreq.c b/drivers/cpufreq/pxa2xx-cpufreq.c
index fe4c55b..9e5bc8e 100644
--- a/drivers/cpufreq/pxa2xx-cpufreq.c
+++ b/drivers/cpufreq/pxa2xx-cpufreq.c
@@ -221,10 +221,11 @@ static void find_freq_tables(struct cpufreq_frequency_table **freq_table,
 			*pxa_freqs = pxa255_turbo_freqs;
 			*freq_table = pxa255_turbo_freq_table;
 		}
-	}
-	if (cpu_is_pxa27x()) {
+	} else if (cpu_is_pxa27x()) {
 		*pxa_freqs = pxa27x_freqs;
 		*freq_table = pxa27x_freq_table;
+	} else {
+		BUG();
 	}
 }
 
-- 
1.8.1.2


^ permalink raw reply related	[flat|nested] 131+ messages in thread

* [PATCH 14/21] cpufreq: pxa2xx: initialize variables
@ 2013-04-25 17:28   ` Arnd Bergmann
  0 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:28 UTC (permalink / raw)
  To: linux-arm-kernel

gcc-3.8 correctly found that the variables set by find_freq_tables()
are not initialized if this function is called on something other
than a pxa2xx or pxa3xx:

pxa2xx-cpufreq.c: In function 'pxa_verify_policy':
pxa2xx-cpufreq.c:272:6: warning: 'pxa_freqs_table' may be used uninitialized in this function [-Wmaybe-uninitialized]
pxa2xx-cpufreq.c: In function 'pxa_set_target':
pxa2xx-cpufreq.c:345:23: warning: 'pxa_freq_settings' may be used uninitialized in this function [-Wmaybe-uninitialized]

Rather than adding a bogus initialization that would let us
get a little further before crashing, add an explicit BUG().
We know that this code is designed to run on only these cpus,
so this will fix the build warning and give a more helpful
diagnostic if the code ever changes to run on other machines.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
 drivers/cpufreq/pxa2xx-cpufreq.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/cpufreq/pxa2xx-cpufreq.c b/drivers/cpufreq/pxa2xx-cpufreq.c
index fe4c55b..9e5bc8e 100644
--- a/drivers/cpufreq/pxa2xx-cpufreq.c
+++ b/drivers/cpufreq/pxa2xx-cpufreq.c
@@ -221,10 +221,11 @@ static void find_freq_tables(struct cpufreq_frequency_table **freq_table,
 			*pxa_freqs = pxa255_turbo_freqs;
 			*freq_table = pxa255_turbo_freq_table;
 		}
-	}
-	if (cpu_is_pxa27x()) {
+	} else if (cpu_is_pxa27x()) {
 		*pxa_freqs = pxa27x_freqs;
 		*freq_table = pxa27x_freq_table;
+	} else {
+		BUG();
 	}
 }
 
-- 
1.8.1.2

^ permalink raw reply related	[flat|nested] 131+ messages in thread

* [PATCH 15/21] thermal: cooling: avoid uninitialied used gcc warning
  2013-04-25 17:28 ` Arnd Bergmann
@ 2013-04-25 17:28   ` Arnd Bergmann
  -1 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:28 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: linux-kernel, Arnd Bergmann, Zhang Rui, Amit Daniel kachhap

The newly rewritten get_property() function causes a bogus warning
from gcc-3.8, which cannot figure out that "level" is always
initialized at the point where it gets evaluated:

drivers/thermal/cpu_cooling.c: In function 'get_property':
drivers/thermal/cpu_cooling.c:189:37: warning: 'level' may be used uninitialized in this function [-Wmaybe-uninitialized]
   if (property == GET_FREQ && level == j) {
                                     ^

Slightly rearranging the code makes this more obvious and
avoids the warning.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Amit Daniel kachhap <amit.daniel@samsung.com>
---
 drivers/thermal/cpu_cooling.c | 17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
index 768b508..34878e6 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -165,10 +165,6 @@ static int get_property(unsigned int cpu, unsigned long input,
 		return 0;
 	}
 
-	if (property == GET_FREQ)
-		level = descend ? input : (max_level - input -1);
-
-
 	for (i = 0, j = 0; table[i].frequency != CPUFREQ_TABLE_END; i++) {
 		/* ignore invalid entry */
 		if (table[i].frequency == CPUFREQ_ENTRY_INVALID)
@@ -186,10 +182,15 @@ static int get_property(unsigned int cpu, unsigned long input,
 			*output = descend ? j : (max_level - j - 1);
 			return 0;
 		}
-		if (property == GET_FREQ && level == j) {
-			/* get frequency by level */
-			*output = freq;
-			return 0;
+
+		if (property == GET_FREQ) {
+			level = descend ? input : (max_level - input -1);
+
+			if (level == j) {
+				/* get frequency by level */
+				*output = freq;
+				return 0;
+			}
 		}
 		j++;
 	}
-- 
1.8.1.2


^ permalink raw reply related	[flat|nested] 131+ messages in thread

* [PATCH 15/21] thermal: cooling: avoid uninitialied used gcc warning
@ 2013-04-25 17:28   ` Arnd Bergmann
  0 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:28 UTC (permalink / raw)
  To: linux-arm-kernel

The newly rewritten get_property() function causes a bogus warning
from gcc-3.8, which cannot figure out that "level" is always
initialized at the point where it gets evaluated:

drivers/thermal/cpu_cooling.c: In function 'get_property':
drivers/thermal/cpu_cooling.c:189:37: warning: 'level' may be used uninitialized in this function [-Wmaybe-uninitialized]
   if (property == GET_FREQ && level == j) {
                                     ^

Slightly rearranging the code makes this more obvious and
avoids the warning.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Amit Daniel kachhap <amit.daniel@samsung.com>
---
 drivers/thermal/cpu_cooling.c | 17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
index 768b508..34878e6 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -165,10 +165,6 @@ static int get_property(unsigned int cpu, unsigned long input,
 		return 0;
 	}
 
-	if (property == GET_FREQ)
-		level = descend ? input : (max_level - input -1);
-
-
 	for (i = 0, j = 0; table[i].frequency != CPUFREQ_TABLE_END; i++) {
 		/* ignore invalid entry */
 		if (table[i].frequency == CPUFREQ_ENTRY_INVALID)
@@ -186,10 +182,15 @@ static int get_property(unsigned int cpu, unsigned long input,
 			*output = descend ? j : (max_level - j - 1);
 			return 0;
 		}
-		if (property == GET_FREQ && level == j) {
-			/* get frequency by level */
-			*output = freq;
-			return 0;
+
+		if (property == GET_FREQ) {
+			level = descend ? input : (max_level - input -1);
+
+			if (level == j) {
+				/* get frequency by level */
+				*output = freq;
+				return 0;
+			}
 		}
 		j++;
 	}
-- 
1.8.1.2

^ permalink raw reply related	[flat|nested] 131+ messages in thread

* [PATCH 16/21] OF: remove #ifdef from linux/of_platform.h
  2013-04-25 17:28 ` Arnd Bergmann
@ 2013-04-25 17:28   ` Arnd Bergmann
  -1 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:28 UTC (permalink / raw)
  To: linux-arm-kernel; +Cc: linux-kernel, Arnd Bergmann, Grant Likely, Rob Herring

A lot of code uses the functions from of_platform.h when built for
devicetree-enabled platforms but can also be built without them.
In order to avoid using #ifdef everywhere in drivers, this
makes all the function declarations visible, which means we
can use "if (IS_ENABLED(CONFIG_OF))" in driver code and get build
coverage over the code but let the compiler drop the reference
in the object code.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <rob.herring@calxeda.com>
---
 include/linux/of_platform.h | 13 +++----------
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/include/linux/of_platform.h b/include/linux/of_platform.h
index 2a93b64..ff83462 100644
--- a/include/linux/of_platform.h
+++ b/include/linux/of_platform.h
@@ -14,7 +14,6 @@
 #include <linux/device.h>
 #include <linux/mod_devicetable.h>
 
-#ifdef CONFIG_OF_DEVICE
 #include <linux/pm.h>
 #include <linux/of_device.h>
 #include <linux/platform_device.h>
@@ -82,7 +81,6 @@ extern struct platform_device *of_device_alloc(struct device_node *np,
 					 struct device *parent);
 extern struct platform_device *of_find_device_by_node(struct device_node *np);
 
-#ifdef CONFIG_OF_ADDRESS /* device reg helpers depend on OF_ADDRESS */
 /* Platform devices and busses creation */
 extern struct platform_device *of_platform_device_create(struct device_node *np,
 						   const char *bus_id,
@@ -91,17 +89,12 @@ extern struct platform_device *of_platform_device_create(struct device_node *np,
 extern int of_platform_bus_probe(struct device_node *root,
 				 const struct of_device_id *matches,
 				 struct device *parent);
+#ifdef CONFIG_OF_ADDRESS
 extern int of_platform_populate(struct device_node *root,
 				const struct of_device_id *matches,
 				const struct of_dev_auxdata *lookup,
 				struct device *parent);
-#endif /* CONFIG_OF_ADDRESS */
-
-#endif /* CONFIG_OF_DEVICE */
-
-#if !defined(CONFIG_OF_ADDRESS)
-struct of_dev_auxdata;
-struct device_node;
+#else
 static inline int of_platform_populate(struct device_node *root,
 					const struct of_device_id *matches,
 					const struct of_dev_auxdata *lookup,
@@ -109,6 +102,6 @@ static inline int of_platform_populate(struct device_node *root,
 {
 	return -ENODEV;
 }
-#endif /* !CONFIG_OF_ADDRESS */
+#endif
 
 #endif	/* _LINUX_OF_PLATFORM_H */
-- 
1.8.1.2


^ permalink raw reply related	[flat|nested] 131+ messages in thread

* [PATCH 16/21] OF: remove #ifdef from linux/of_platform.h
@ 2013-04-25 17:28   ` Arnd Bergmann
  0 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:28 UTC (permalink / raw)
  To: linux-arm-kernel

A lot of code uses the functions from of_platform.h when built for
devicetree-enabled platforms but can also be built without them.
In order to avoid using #ifdef everywhere in drivers, this
makes all the function declarations visible, which means we
can use "if (IS_ENABLED(CONFIG_OF))" in driver code and get build
coverage over the code but let the compiler drop the reference
in the object code.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <rob.herring@calxeda.com>
---
 include/linux/of_platform.h | 13 +++----------
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/include/linux/of_platform.h b/include/linux/of_platform.h
index 2a93b64..ff83462 100644
--- a/include/linux/of_platform.h
+++ b/include/linux/of_platform.h
@@ -14,7 +14,6 @@
 #include <linux/device.h>
 #include <linux/mod_devicetable.h>
 
-#ifdef CONFIG_OF_DEVICE
 #include <linux/pm.h>
 #include <linux/of_device.h>
 #include <linux/platform_device.h>
@@ -82,7 +81,6 @@ extern struct platform_device *of_device_alloc(struct device_node *np,
 					 struct device *parent);
 extern struct platform_device *of_find_device_by_node(struct device_node *np);
 
-#ifdef CONFIG_OF_ADDRESS /* device reg helpers depend on OF_ADDRESS */
 /* Platform devices and busses creation */
 extern struct platform_device *of_platform_device_create(struct device_node *np,
 						   const char *bus_id,
@@ -91,17 +89,12 @@ extern struct platform_device *of_platform_device_create(struct device_node *np,
 extern int of_platform_bus_probe(struct device_node *root,
 				 const struct of_device_id *matches,
 				 struct device *parent);
+#ifdef CONFIG_OF_ADDRESS
 extern int of_platform_populate(struct device_node *root,
 				const struct of_device_id *matches,
 				const struct of_dev_auxdata *lookup,
 				struct device *parent);
-#endif /* CONFIG_OF_ADDRESS */
-
-#endif /* CONFIG_OF_DEVICE */
-
-#if !defined(CONFIG_OF_ADDRESS)
-struct of_dev_auxdata;
-struct device_node;
+#else
 static inline int of_platform_populate(struct device_node *root,
 					const struct of_device_id *matches,
 					const struct of_dev_auxdata *lookup,
@@ -109,6 +102,6 @@ static inline int of_platform_populate(struct device_node *root,
 {
 	return -ENODEV;
 }
-#endif /* !CONFIG_OF_ADDRESS */
+#endif
 
 #endif	/* _LINUX_OF_PLATFORM_H */
-- 
1.8.1.2

^ permalink raw reply related	[flat|nested] 131+ messages in thread

* [PATCH 17/21] X.509: do not emit any informational output
  2013-04-25 17:28 ` Arnd Bergmann
@ 2013-04-25 17:29   ` Arnd Bergmann
  -1 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:29 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: linux-kernel, Arnd Bergmann, David Howells, Rusty Russell

When building a kernel using 'make -s', I expect to see an empty output,
except for build warnings and errors. The build_OID_registry code
always prints one line when run, which is not helpful to most people
building the kernels, and which makes it harder to automatically
check for build warnings.

Let's just remove the one line output.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: David Howells <dhowells@redhat.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
---
 lib/build_OID_registry | 2 --
 1 file changed, 2 deletions(-)

diff --git a/lib/build_OID_registry b/lib/build_OID_registry
index dfbdaab..5d98272 100755
--- a/lib/build_OID_registry
+++ b/lib/build_OID_registry
@@ -50,8 +50,6 @@ my @indices = ();
 my @lengths = ();
 my $total_length = 0;
 
-print "Compiling ", $#names + 1, " OIDs\n";
-
 for (my $i = 0; $i <= $#names; $i++) {
     my $name = $names[$i];
     my $oid = $oids[$i];
-- 
1.8.1.2


^ permalink raw reply related	[flat|nested] 131+ messages in thread

* [PATCH 17/21] X.509: do not emit any informational output
@ 2013-04-25 17:29   ` Arnd Bergmann
  0 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:29 UTC (permalink / raw)
  To: linux-arm-kernel

When building a kernel using 'make -s', I expect to see an empty output,
except for build warnings and errors. The build_OID_registry code
always prints one line when run, which is not helpful to most people
building the kernels, and which makes it harder to automatically
check for build warnings.

Let's just remove the one line output.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: David Howells <dhowells@redhat.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
---
 lib/build_OID_registry | 2 --
 1 file changed, 2 deletions(-)

diff --git a/lib/build_OID_registry b/lib/build_OID_registry
index dfbdaab..5d98272 100755
--- a/lib/build_OID_registry
+++ b/lib/build_OID_registry
@@ -50,8 +50,6 @@ my @indices = ();
 my @lengths = ();
 my $total_length = 0;
 
-print "Compiling ", $#names + 1, " OIDs\n";
-
 for (my $i = 0; $i <= $#names; $i++) {
     my $name = $names[$i];
     my $oid = $oids[$i];
-- 
1.8.1.2

^ permalink raw reply related	[flat|nested] 131+ messages in thread

* [PATCH 18/21] USB: ehci-msm: USB_MSM_OTG needs USB_PHY
  2013-04-25 17:28 ` Arnd Bergmann
@ 2013-04-25 17:29   ` Arnd Bergmann
  -1 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:29 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: linux-kernel, Arnd Bergmann, linux-usb, Greg Kroah-Hartman,
	Felipe Balbi, Pavankumar Kondeti

The Kconfig entry for USB_EHCI_MSM unconditionally selects USB_MSM_OTG,
which is now only visible when USB_PHY is also enabled.

This adds an appropriate dependency and enables USB_PHY in the msm
defconfig, avoiding the Kbuild warning:

warning: (USB_EHCI_MSM) selects USB_MSM_OTG which has unmet direct dependencies (USB_SUPPORT && USB_PHY && (USB || USB_GADGET) && ARCH_MSM)

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: linux-usb@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Pavankumar Kondeti <pkondeti@codeaurora.org>
---
 arch/arm/configs/msm_defconfig | 1 +
 drivers/usb/host/Kconfig       | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/arm/configs/msm_defconfig b/arch/arm/configs/msm_defconfig
index 44f9291..690b5f9 100644
--- a/arch/arm/configs/msm_defconfig
+++ b/arch/arm/configs/msm_defconfig
@@ -101,6 +101,7 @@ CONFIG_SND_DYNAMIC_MINORS=y
 CONFIG_SND_SOC=y
 CONFIG_HID_BATTERY_STRENGTH=y
 CONFIG_USB=y
+CONFIG_USB_PHY=y
 CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
 CONFIG_USB_MON=y
 CONFIG_USB_EHCI_HCD=y
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index c558472..de94f26 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -188,6 +188,7 @@ config USB_EHCI_HCD_AT91
 config USB_EHCI_MSM
 	tristate "Support for Qualcomm QSD/MSM on-chip EHCI USB controller"
 	depends on ARCH_MSM
+	depends on USB_PHY
 	select USB_EHCI_ROOT_HUB_TT
 	select USB_MSM_OTG
 	---help---
-- 
1.8.1.2


^ permalink raw reply related	[flat|nested] 131+ messages in thread

* [PATCH 18/21] USB: ehci-msm: USB_MSM_OTG needs USB_PHY
@ 2013-04-25 17:29   ` Arnd Bergmann
  0 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:29 UTC (permalink / raw)
  To: linux-arm-kernel

The Kconfig entry for USB_EHCI_MSM unconditionally selects USB_MSM_OTG,
which is now only visible when USB_PHY is also enabled.

This adds an appropriate dependency and enables USB_PHY in the msm
defconfig, avoiding the Kbuild warning:

warning: (USB_EHCI_MSM) selects USB_MSM_OTG which has unmet direct dependencies (USB_SUPPORT && USB_PHY && (USB || USB_GADGET) && ARCH_MSM)

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: linux-usb at vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Pavankumar Kondeti <pkondeti@codeaurora.org>
---
 arch/arm/configs/msm_defconfig | 1 +
 drivers/usb/host/Kconfig       | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/arm/configs/msm_defconfig b/arch/arm/configs/msm_defconfig
index 44f9291..690b5f9 100644
--- a/arch/arm/configs/msm_defconfig
+++ b/arch/arm/configs/msm_defconfig
@@ -101,6 +101,7 @@ CONFIG_SND_DYNAMIC_MINORS=y
 CONFIG_SND_SOC=y
 CONFIG_HID_BATTERY_STRENGTH=y
 CONFIG_USB=y
+CONFIG_USB_PHY=y
 CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
 CONFIG_USB_MON=y
 CONFIG_USB_EHCI_HCD=y
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index c558472..de94f26 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -188,6 +188,7 @@ config USB_EHCI_HCD_AT91
 config USB_EHCI_MSM
 	tristate "Support for Qualcomm QSD/MSM on-chip EHCI USB controller"
 	depends on ARCH_MSM
+	depends on USB_PHY
 	select USB_EHCI_ROOT_HUB_TT
 	select USB_MSM_OTG
 	---help---
-- 
1.8.1.2

^ permalink raw reply related	[flat|nested] 131+ messages in thread

* [PATCH 19/21] USB: lpc32xx: ISP1301 needs USB_PHY
  2013-04-25 17:28 ` Arnd Bergmann
@ 2013-04-25 17:29   ` Arnd Bergmann
  -1 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:29 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: linux-kernel, Arnd Bergmann, linux-usb, Greg Kroah-Hartman,
	Felipe Balbi, Roland Stigge

The Kconfig entry for USB_LPC32XX unconditionally selects USB_ISP1301,
which is now only visible when USB_PHY is also enabled.

This adds an appropriate dependency and enables USB_PHY in the msm
defconfig, avoiding these build errors:

warning: (USB_LPC32XX) selects USB_ISP1301 which has unmet direct dependencies (USB_SUPPORT && USB_PHY && (USB || USB_GADGET) && I2C)
drivers/built-in.o: In function `usb_hcd_nxp_probe':
drivers/usb/host/ohci-nxp.c:224: undefined reference to `isp1301_get_client'
drivers/built-in.o: In function `lpc32xx_udc_probe':
drivers/usb/gadget/lpc32xx_udc.c:3071: undefined reference to `isp1301_get_client'

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: linux-usb@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Roland Stigge <stigge@antcom.de>
---
 arch/arm/configs/lpc32xx_defconfig | 1 +
 drivers/usb/gadget/Kconfig         | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/arm/configs/lpc32xx_defconfig b/arch/arm/configs/lpc32xx_defconfig
index 8fee514..398a367 100644
--- a/arch/arm/configs/lpc32xx_defconfig
+++ b/arch/arm/configs/lpc32xx_defconfig
@@ -146,6 +146,7 @@ CONFIG_SND_DEBUG_VERBOSE=y
 # CONFIG_SND_SPI is not set
 CONFIG_SND_SOC=y
 CONFIG_USB=y
+CONFIG_USB_PHY=y
 CONFIG_USB_OHCI_HCD=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_GADGET=y
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index a61d981..f85b427 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -144,6 +144,7 @@ config USB_AT91
 config USB_LPC32XX
 	tristate "LPC32XX USB Peripheral Controller"
 	depends on ARCH_LPC32XX
+	depends on USB_PHY
 	select USB_ISP1301
 	select USB_OTG_UTILS
 	help
-- 
1.8.1.2


^ permalink raw reply related	[flat|nested] 131+ messages in thread

* [PATCH 19/21] USB: lpc32xx: ISP1301 needs USB_PHY
@ 2013-04-25 17:29   ` Arnd Bergmann
  0 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:29 UTC (permalink / raw)
  To: linux-arm-kernel

The Kconfig entry for USB_LPC32XX unconditionally selects USB_ISP1301,
which is now only visible when USB_PHY is also enabled.

This adds an appropriate dependency and enables USB_PHY in the msm
defconfig, avoiding these build errors:

warning: (USB_LPC32XX) selects USB_ISP1301 which has unmet direct dependencies (USB_SUPPORT && USB_PHY && (USB || USB_GADGET) && I2C)
drivers/built-in.o: In function `usb_hcd_nxp_probe':
drivers/usb/host/ohci-nxp.c:224: undefined reference to `isp1301_get_client'
drivers/built-in.o: In function `lpc32xx_udc_probe':
drivers/usb/gadget/lpc32xx_udc.c:3071: undefined reference to `isp1301_get_client'

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: linux-usb at vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Roland Stigge <stigge@antcom.de>
---
 arch/arm/configs/lpc32xx_defconfig | 1 +
 drivers/usb/gadget/Kconfig         | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/arm/configs/lpc32xx_defconfig b/arch/arm/configs/lpc32xx_defconfig
index 8fee514..398a367 100644
--- a/arch/arm/configs/lpc32xx_defconfig
+++ b/arch/arm/configs/lpc32xx_defconfig
@@ -146,6 +146,7 @@ CONFIG_SND_DEBUG_VERBOSE=y
 # CONFIG_SND_SPI is not set
 CONFIG_SND_SOC=y
 CONFIG_USB=y
+CONFIG_USB_PHY=y
 CONFIG_USB_OHCI_HCD=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_GADGET=y
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index a61d981..f85b427 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -144,6 +144,7 @@ config USB_AT91
 config USB_LPC32XX
 	tristate "LPC32XX USB Peripheral Controller"
 	depends on ARCH_LPC32XX
+	depends on USB_PHY
 	select USB_ISP1301
 	select USB_OTG_UTILS
 	help
-- 
1.8.1.2

^ permalink raw reply related	[flat|nested] 131+ messages in thread

* [PATCH 20/21] USB: OMAP: ISP1301 needs USB_PHY
  2013-04-25 17:28 ` Arnd Bergmann
@ 2013-04-25 17:29   ` Arnd Bergmann
  -1 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:29 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: linux-kernel, Arnd Bergmann, linux-usb, Greg Kroah-Hartman, Felipe Balbi

The Kconfig entry for USB_OMAP unconditionally selects USB_ISP1301,
which is now only visible when USB_PHY is also enabled.

This adds an appropriate dependency and enables USB_PHY in the omap1
defconfig, avoiding these build warnings:

warning: (USB_OHCI_HCD && USB_OMAP) selects ISP1301_OMAP which has unmet direct dependencies (USB_SUPPORT && USB_PHY && I2C && ARCH_OMAP_OTG)

Also fix a Makefile typo while we're at it.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: linux-usb@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Felipe Balbi <balbi@ti.com>
---
 arch/arm/configs/omap1_defconfig | 1 +
 drivers/usb/gadget/Kconfig       | 1 +
 drivers/usb/phy/Makefile         | 2 +-
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/configs/omap1_defconfig b/arch/arm/configs/omap1_defconfig
index 2280d9d..a1ee534 100644
--- a/arch/arm/configs/omap1_defconfig
+++ b/arch/arm/configs/omap1_defconfig
@@ -196,6 +196,7 @@ CONFIG_SND_SOC=y
 CONFIG_SND_OMAP_SOC=y
 # CONFIG_USB_HID is not set
 CONFIG_USB=y
+CONFIG_USB_PHY=y
 CONFIG_USB_DEBUG=y
 CONFIG_USB_DEVICEFS=y
 # CONFIG_USB_DEVICE_CLASS is not set
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index f85b427..83300d9 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -196,6 +196,7 @@ config USB_FUSB300
 config USB_OMAP
 	tristate "OMAP USB Device Controller"
 	depends on ARCH_OMAP1
+	depends on USB_PHY
 	select ISP1301_OMAP if MACH_OMAP_H2 || MACH_OMAP_H3 || MACH_OMAP_H4_OTG
 	help
 	   Many Texas Instruments OMAP processors have flexible full
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index 33863c0..a9169cb 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -11,7 +11,7 @@ obj-$(CONFIG_USB_PHY)			+= phy.o
 obj-$(CONFIG_AB8500_USB)		+= phy-ab8500-usb.o
 phy-fsl-usb2-objs			:= phy-fsl-usb.o phy-fsm-usb.o
 obj-$(CONFIG_FSL_USB2_OTG)		+= phy-fsl-usb2.o
-obj-$(CONFIG_ISP1301_OMAP)		+= phy-isp1301.omap.o
+obj-$(CONFIG_ISP1301_OMAP)		+= phy-isp1301-omap.o
 obj-$(CONFIG_MV_U3D_PHY)		+= phy-mv-u3d-usb.o
 obj-$(CONFIG_NOP_USB_XCEIV)		+= phy-nop.o
 obj-$(CONFIG_OMAP_CONTROL_USB)		+= phy-omap-control.o
-- 
1.8.1.2


^ permalink raw reply related	[flat|nested] 131+ messages in thread

* [PATCH 20/21] USB: OMAP: ISP1301 needs USB_PHY
@ 2013-04-25 17:29   ` Arnd Bergmann
  0 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:29 UTC (permalink / raw)
  To: linux-arm-kernel

The Kconfig entry for USB_OMAP unconditionally selects USB_ISP1301,
which is now only visible when USB_PHY is also enabled.

This adds an appropriate dependency and enables USB_PHY in the omap1
defconfig, avoiding these build warnings:

warning: (USB_OHCI_HCD && USB_OMAP) selects ISP1301_OMAP which has unmet direct dependencies (USB_SUPPORT && USB_PHY && I2C && ARCH_OMAP_OTG)

Also fix a Makefile typo while we're at it.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: linux-usb at vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Felipe Balbi <balbi@ti.com>
---
 arch/arm/configs/omap1_defconfig | 1 +
 drivers/usb/gadget/Kconfig       | 1 +
 drivers/usb/phy/Makefile         | 2 +-
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/configs/omap1_defconfig b/arch/arm/configs/omap1_defconfig
index 2280d9d..a1ee534 100644
--- a/arch/arm/configs/omap1_defconfig
+++ b/arch/arm/configs/omap1_defconfig
@@ -196,6 +196,7 @@ CONFIG_SND_SOC=y
 CONFIG_SND_OMAP_SOC=y
 # CONFIG_USB_HID is not set
 CONFIG_USB=y
+CONFIG_USB_PHY=y
 CONFIG_USB_DEBUG=y
 CONFIG_USB_DEVICEFS=y
 # CONFIG_USB_DEVICE_CLASS is not set
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index f85b427..83300d9 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -196,6 +196,7 @@ config USB_FUSB300
 config USB_OMAP
 	tristate "OMAP USB Device Controller"
 	depends on ARCH_OMAP1
+	depends on USB_PHY
 	select ISP1301_OMAP if MACH_OMAP_H2 || MACH_OMAP_H3 || MACH_OMAP_H4_OTG
 	help
 	   Many Texas Instruments OMAP processors have flexible full
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index 33863c0..a9169cb 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -11,7 +11,7 @@ obj-$(CONFIG_USB_PHY)			+= phy.o
 obj-$(CONFIG_AB8500_USB)		+= phy-ab8500-usb.o
 phy-fsl-usb2-objs			:= phy-fsl-usb.o phy-fsm-usb.o
 obj-$(CONFIG_FSL_USB2_OTG)		+= phy-fsl-usb2.o
-obj-$(CONFIG_ISP1301_OMAP)		+= phy-isp1301.omap.o
+obj-$(CONFIG_ISP1301_OMAP)		+= phy-isp1301-omap.o
 obj-$(CONFIG_MV_U3D_PHY)		+= phy-mv-u3d-usb.o
 obj-$(CONFIG_NOP_USB_XCEIV)		+= phy-nop.o
 obj-$(CONFIG_OMAP_CONTROL_USB)		+= phy-omap-control.o
-- 
1.8.1.2

^ permalink raw reply related	[flat|nested] 131+ messages in thread

* [PATCH 21/21] USB: OHCI: avoid conflicting platform drivers
  2013-04-25 17:28 ` Arnd Bergmann
@ 2013-04-25 17:29   ` Arnd Bergmann
  -1 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:29 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: linux-kernel, Arnd Bergmann, linux-usb, Greg Kroah-Hartman

Like the EHCI driver, OHCI supports a large number of different platform
glue drivers by directly including them, which causes problems with
conflicting macro definitions in some cases. As more ARM architecture
specific back-ends are required to coexist in a single build, we should
split those out into separate drivers. Unfortunately, the infrastructure
for that is still under development, so to give us more time, this uses
a separate *_PLATFORM_DRIVER macro for each ARM specific OHCI backend,
just like we already do on PowerPC and some of the other ARM platforms.

In linux-3.10, only the SPEAr and CNS3xxx back-ends would actually conflict
without this patch, but over time we would get more of them, so this
is a way to avoid having to patch the driver every time it breaks. We
should still split out all back-ends into separate loadable modules,
but that work is only needed to improve code size and cleanliness after
this patch, not for correctness.

While we're here, this fixes the incorrectly sorted error path
for the OMAP1 and OMAP3 backends to ensure we always unregister
the exact set of drivers that were registered before erroring out.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: linux-usb@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/usb/host/ohci-hcd.c | 136 ++++++++++++++++++++++++++++++++++++++------
 1 file changed, 118 insertions(+), 18 deletions(-)

diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 180a2b0..9e6de95 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1102,12 +1102,12 @@ MODULE_LICENSE ("GPL");
 
 #if defined(CONFIG_ARCH_S3C24XX) || defined(CONFIG_ARCH_S3C64XX)
 #include "ohci-s3c2410.c"
-#define PLATFORM_DRIVER		ohci_hcd_s3c2410_driver
+#define S3C2410_PLATFORM_DRIVER	ohci_hcd_s3c2410_driver
 #endif
 
 #ifdef CONFIG_USB_OHCI_EXYNOS
 #include "ohci-exynos.c"
-#define PLATFORM_DRIVER		exynos_ohci_driver
+#define EXYNOS_PLATFORM_DRIVER	exynos_ohci_driver
 #endif
 
 #ifdef CONFIG_USB_OHCI_HCD_OMAP1
@@ -1127,25 +1127,24 @@ MODULE_LICENSE ("GPL");
 
 #ifdef CONFIG_ARCH_EP93XX
 #include "ohci-ep93xx.c"
-#define PLATFORM_DRIVER		ohci_hcd_ep93xx_driver
+#define EP93XX_PLATFORM_DRIVER	ohci_hcd_ep93xx_driver
 #endif
 
 #ifdef CONFIG_ARCH_AT91
 #include "ohci-at91.c"
-#define PLATFORM_DRIVER		ohci_hcd_at91_driver
+#define AT91_PLATFORM_DRIVER	ohci_hcd_at91_driver
 #endif
 
 #ifdef CONFIG_ARCH_LPC32XX
 #include "ohci-nxp.c"
-#define PLATFORM_DRIVER		usb_hcd_nxp_driver
+#define NXP_PLATFORM_DRIVER	usb_hcd_nxp_driver
 #endif
 
 #ifdef CONFIG_ARCH_DAVINCI_DA8XX
 #include "ohci-da8xx.c"
-#define PLATFORM_DRIVER		ohci_hcd_da8xx_driver
+#define DAVINCI_PLATFORM_DRIVER	ohci_hcd_da8xx_driver
 #endif
 
-
 #ifdef CONFIG_USB_OHCI_HCD_PPC_OF
 #include "ohci-ppc-of.c"
 #define OF_PLATFORM_DRIVER	ohci_hcd_ppc_of_driver
@@ -1153,7 +1152,7 @@ MODULE_LICENSE ("GPL");
 
 #ifdef CONFIG_PLAT_SPEAR
 #include "ohci-spear.c"
-#define PLATFORM_DRIVER		spear_ohci_hcd_driver
+#define SPEAR_PLATFORM_DRIVER	spear_ohci_hcd_driver
 #endif
 
 #ifdef CONFIG_PPC_PS3
@@ -1199,7 +1198,14 @@ MODULE_LICENSE ("GPL");
 	!defined(SA1111_DRIVER) &&	\
 	!defined(PS3_SYSTEM_BUS_DRIVER) && \
 	!defined(SM501_OHCI_DRIVER) && \
-	!defined(TMIO_OHCI_DRIVER)
+	!defined(TMIO_OHCI_DRIVER) && \
+	!defined(S3C2410_PLATFORM_DRIVER) && \
+	!defined(EXYNOS_PLATFORM_DRIVER) && \
+	!defined(EP93XX_PLATFORM_DRIVER) && \
+	!defined(AT91_PLATFORM_DRIVER) && \
+	!defined(NXP_PLATFORM_DRIVER) && \
+	!defined(DAVINCI_PLATFORM_DRIVER) && \
+	!defined(SPEAR_PLATFORM_DRIVER)
 #error "missing bus glue for ohci-hcd"
 #endif
 
@@ -1277,9 +1283,79 @@ static int __init ohci_hcd_mod_init(void)
 		goto error_tmio;
 #endif
 
+#ifdef S3C2410_PLATFORM_DRIVER
+	retval = platform_driver_register(&S3C2410_PLATFORM_DRIVER);
+	if (retval < 0)
+		goto error_s3c2410;
+#endif
+
+#ifdef EXYNOS_PLATFORM_DRIVER
+	retval = platform_driver_register(&EXYNOS_PLATFORM_DRIVER);
+	if (retval < 0)
+		goto error_exynos;
+#endif
+
+#ifdef EP93XX_PLATFORM_DRIVER
+	retval = platform_driver_register(&EP93XX_PLATFORM_DRIVER);
+	if (retval < 0)
+		goto error_ep93xx;
+#endif
+
+#ifdef AT91_PLATFORM_DRIVER
+	retval = platform_driver_register(&AT91_PLATFORM_DRIVER);
+	if (retval < 0)
+		goto error_at91;
+#endif
+
+#ifdef NXP_PLATFORM_DRIVER
+	retval = platform_driver_register(&NXP_PLATFORM_DRIVER);
+	if (retval < 0)
+		goto error_nxp;
+#endif
+
+#ifdef DAVINCI_PLATFORM_DRIVER
+	retval = platform_driver_register(&DAVINCI_PLATFORM_DRIVER);
+	if (retval < 0)
+		goto error_davinci;
+#endif
+
+#ifdef SPEAR_PLATFORM_DRIVER
+	retval = platform_driver_register(&SPEAR_PLATFORM_DRIVER);
+	if (retval < 0)
+		goto error_spear;
+#endif
+
 	return retval;
 
 	/* Error path */
+#ifdef SPEAR_PLATFORM_DRIVER
+	platform_driver_unregister(&SPEAR_PLATFORM_DRIVER);
+ error_spear:
+#endif
+#ifdef DAVINCI_PLATFORM_DRIVER
+	platform_driver_unregister(&DAVINCI_PLATFORM_DRIVER);
+ error_davinci:
+#endif
+#ifdef NXP_PLATFORM_DRIVER
+	platform_driver_unregister(&NXP_PLATFORM_DRIVER);
+ error_nxp:
+#endif
+#ifdef AT91_PLATFORM_DRIVER
+	platform_driver_unregister(&AT91_PLATFORM_DRIVER);
+ error_at91:
+#endif
+#ifdef EP93XX_PLATFORM_DRIVER
+	platform_driver_unregister(&EP93XX_PLATFORM_DRIVER);
+ error_ep93xx:
+#endif
+#ifdef EXYNOS_PLATFORM_DRIVER
+	platform_driver_unregister(&EXYNOS_PLATFORM_DRIVER);
+ error_exynos:
+#endif
+#ifdef S3C2410_PLATFORM_DRIVER
+	platform_driver_unregister(&S3C2410_PLATFORM_DRIVER);
+ error_s3c2410:
+#endif
 #ifdef TMIO_OHCI_DRIVER
 	platform_driver_unregister(&TMIO_OHCI_DRIVER);
  error_tmio:
@@ -1300,17 +1376,17 @@ static int __init ohci_hcd_mod_init(void)
 	platform_driver_unregister(&OF_PLATFORM_DRIVER);
  error_of_platform:
 #endif
-#ifdef PLATFORM_DRIVER
-	platform_driver_unregister(&PLATFORM_DRIVER);
- error_platform:
+#ifdef OMAP3_PLATFORM_DRIVER
+	platform_driver_unregister(&OMAP3_PLATFORM_DRIVER);
+ error_omap3_platform:
 #endif
 #ifdef OMAP1_PLATFORM_DRIVER
 	platform_driver_unregister(&OMAP1_PLATFORM_DRIVER);
  error_omap1_platform:
 #endif
-#ifdef OMAP3_PLATFORM_DRIVER
-	platform_driver_unregister(&OMAP3_PLATFORM_DRIVER);
- error_omap3_platform:
+#ifdef PLATFORM_DRIVER
+	platform_driver_unregister(&PLATFORM_DRIVER);
+ error_platform:
 #endif
 #ifdef PS3_SYSTEM_BUS_DRIVER
 	ps3_ohci_driver_unregister(&PS3_SYSTEM_BUS_DRIVER);
@@ -1329,6 +1405,27 @@ module_init(ohci_hcd_mod_init);
 
 static void __exit ohci_hcd_mod_exit(void)
 {
+#ifdef SPEAR_PLATFORM_DRIVER
+	platform_driver_unregister(&SPEAR_PLATFORM_DRIVER);
+#endif
+#ifdef DAVINCI_PLATFORM_DRIVER
+	platform_driver_unregister(&DAVINCI_PLATFORM_DRIVER);
+#endif
+#ifdef NXP_PLATFORM_DRIVER
+	platform_driver_unregister(&NXP_PLATFORM_DRIVER);
+#endif
+#ifdef AT91_PLATFORM_DRIVER
+	platform_driver_unregister(&AT91_PLATFORM_DRIVER);
+#endif
+#ifdef EP93XX_PLATFORM_DRIVER
+	platform_driver_unregister(&EP93XX_PLATFORM_DRIVER);
+#endif
+#ifdef EXYNOS_PLATFORM_DRIVER
+	platform_driver_unregister(&EXYNOS_PLATFORM_DRIVER);
+#endif
+#ifdef S3C2410_PLATFORM_DRIVER
+	platform_driver_unregister(&S3C2410_PLATFORM_DRIVER);
+#endif
 #ifdef TMIO_OHCI_DRIVER
 	platform_driver_unregister(&TMIO_OHCI_DRIVER);
 #endif
@@ -1344,12 +1441,15 @@ static void __exit ohci_hcd_mod_exit(void)
 #ifdef OF_PLATFORM_DRIVER
 	platform_driver_unregister(&OF_PLATFORM_DRIVER);
 #endif
-#ifdef PLATFORM_DRIVER
-	platform_driver_unregister(&PLATFORM_DRIVER);
-#endif
 #ifdef OMAP3_PLATFORM_DRIVER
 	platform_driver_unregister(&OMAP3_PLATFORM_DRIVER);
 #endif
+#ifdef OMAP1_PLATFORM_DRIVER
+	platform_driver_unregister(&OMAP1_PLATFORM_DRIVER);
+#endif
+#ifdef PLATFORM_DRIVER
+	platform_driver_unregister(&PLATFORM_DRIVER);
+#endif
 #ifdef PS3_SYSTEM_BUS_DRIVER
 	ps3_ohci_driver_unregister(&PS3_SYSTEM_BUS_DRIVER);
 #endif
-- 
1.8.1.2


^ permalink raw reply related	[flat|nested] 131+ messages in thread

* [PATCH 21/21] USB: OHCI: avoid conflicting platform drivers
@ 2013-04-25 17:29   ` Arnd Bergmann
  0 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 17:29 UTC (permalink / raw)
  To: linux-arm-kernel

Like the EHCI driver, OHCI supports a large number of different platform
glue drivers by directly including them, which causes problems with
conflicting macro definitions in some cases. As more ARM architecture
specific back-ends are required to coexist in a single build, we should
split those out into separate drivers. Unfortunately, the infrastructure
for that is still under development, so to give us more time, this uses
a separate *_PLATFORM_DRIVER macro for each ARM specific OHCI backend,
just like we already do on PowerPC and some of the other ARM platforms.

In linux-3.10, only the SPEAr and CNS3xxx back-ends would actually conflict
without this patch, but over time we would get more of them, so this
is a way to avoid having to patch the driver every time it breaks. We
should still split out all back-ends into separate loadable modules,
but that work is only needed to improve code size and cleanliness after
this patch, not for correctness.

While we're here, this fixes the incorrectly sorted error path
for the OMAP1 and OMAP3 backends to ensure we always unregister
the exact set of drivers that were registered before erroring out.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: linux-usb at vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/usb/host/ohci-hcd.c | 136 ++++++++++++++++++++++++++++++++++++++------
 1 file changed, 118 insertions(+), 18 deletions(-)

diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 180a2b0..9e6de95 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1102,12 +1102,12 @@ MODULE_LICENSE ("GPL");
 
 #if defined(CONFIG_ARCH_S3C24XX) || defined(CONFIG_ARCH_S3C64XX)
 #include "ohci-s3c2410.c"
-#define PLATFORM_DRIVER		ohci_hcd_s3c2410_driver
+#define S3C2410_PLATFORM_DRIVER	ohci_hcd_s3c2410_driver
 #endif
 
 #ifdef CONFIG_USB_OHCI_EXYNOS
 #include "ohci-exynos.c"
-#define PLATFORM_DRIVER		exynos_ohci_driver
+#define EXYNOS_PLATFORM_DRIVER	exynos_ohci_driver
 #endif
 
 #ifdef CONFIG_USB_OHCI_HCD_OMAP1
@@ -1127,25 +1127,24 @@ MODULE_LICENSE ("GPL");
 
 #ifdef CONFIG_ARCH_EP93XX
 #include "ohci-ep93xx.c"
-#define PLATFORM_DRIVER		ohci_hcd_ep93xx_driver
+#define EP93XX_PLATFORM_DRIVER	ohci_hcd_ep93xx_driver
 #endif
 
 #ifdef CONFIG_ARCH_AT91
 #include "ohci-at91.c"
-#define PLATFORM_DRIVER		ohci_hcd_at91_driver
+#define AT91_PLATFORM_DRIVER	ohci_hcd_at91_driver
 #endif
 
 #ifdef CONFIG_ARCH_LPC32XX
 #include "ohci-nxp.c"
-#define PLATFORM_DRIVER		usb_hcd_nxp_driver
+#define NXP_PLATFORM_DRIVER	usb_hcd_nxp_driver
 #endif
 
 #ifdef CONFIG_ARCH_DAVINCI_DA8XX
 #include "ohci-da8xx.c"
-#define PLATFORM_DRIVER		ohci_hcd_da8xx_driver
+#define DAVINCI_PLATFORM_DRIVER	ohci_hcd_da8xx_driver
 #endif
 
-
 #ifdef CONFIG_USB_OHCI_HCD_PPC_OF
 #include "ohci-ppc-of.c"
 #define OF_PLATFORM_DRIVER	ohci_hcd_ppc_of_driver
@@ -1153,7 +1152,7 @@ MODULE_LICENSE ("GPL");
 
 #ifdef CONFIG_PLAT_SPEAR
 #include "ohci-spear.c"
-#define PLATFORM_DRIVER		spear_ohci_hcd_driver
+#define SPEAR_PLATFORM_DRIVER	spear_ohci_hcd_driver
 #endif
 
 #ifdef CONFIG_PPC_PS3
@@ -1199,7 +1198,14 @@ MODULE_LICENSE ("GPL");
 	!defined(SA1111_DRIVER) &&	\
 	!defined(PS3_SYSTEM_BUS_DRIVER) && \
 	!defined(SM501_OHCI_DRIVER) && \
-	!defined(TMIO_OHCI_DRIVER)
+	!defined(TMIO_OHCI_DRIVER) && \
+	!defined(S3C2410_PLATFORM_DRIVER) && \
+	!defined(EXYNOS_PLATFORM_DRIVER) && \
+	!defined(EP93XX_PLATFORM_DRIVER) && \
+	!defined(AT91_PLATFORM_DRIVER) && \
+	!defined(NXP_PLATFORM_DRIVER) && \
+	!defined(DAVINCI_PLATFORM_DRIVER) && \
+	!defined(SPEAR_PLATFORM_DRIVER)
 #error "missing bus glue for ohci-hcd"
 #endif
 
@@ -1277,9 +1283,79 @@ static int __init ohci_hcd_mod_init(void)
 		goto error_tmio;
 #endif
 
+#ifdef S3C2410_PLATFORM_DRIVER
+	retval = platform_driver_register(&S3C2410_PLATFORM_DRIVER);
+	if (retval < 0)
+		goto error_s3c2410;
+#endif
+
+#ifdef EXYNOS_PLATFORM_DRIVER
+	retval = platform_driver_register(&EXYNOS_PLATFORM_DRIVER);
+	if (retval < 0)
+		goto error_exynos;
+#endif
+
+#ifdef EP93XX_PLATFORM_DRIVER
+	retval = platform_driver_register(&EP93XX_PLATFORM_DRIVER);
+	if (retval < 0)
+		goto error_ep93xx;
+#endif
+
+#ifdef AT91_PLATFORM_DRIVER
+	retval = platform_driver_register(&AT91_PLATFORM_DRIVER);
+	if (retval < 0)
+		goto error_at91;
+#endif
+
+#ifdef NXP_PLATFORM_DRIVER
+	retval = platform_driver_register(&NXP_PLATFORM_DRIVER);
+	if (retval < 0)
+		goto error_nxp;
+#endif
+
+#ifdef DAVINCI_PLATFORM_DRIVER
+	retval = platform_driver_register(&DAVINCI_PLATFORM_DRIVER);
+	if (retval < 0)
+		goto error_davinci;
+#endif
+
+#ifdef SPEAR_PLATFORM_DRIVER
+	retval = platform_driver_register(&SPEAR_PLATFORM_DRIVER);
+	if (retval < 0)
+		goto error_spear;
+#endif
+
 	return retval;
 
 	/* Error path */
+#ifdef SPEAR_PLATFORM_DRIVER
+	platform_driver_unregister(&SPEAR_PLATFORM_DRIVER);
+ error_spear:
+#endif
+#ifdef DAVINCI_PLATFORM_DRIVER
+	platform_driver_unregister(&DAVINCI_PLATFORM_DRIVER);
+ error_davinci:
+#endif
+#ifdef NXP_PLATFORM_DRIVER
+	platform_driver_unregister(&NXP_PLATFORM_DRIVER);
+ error_nxp:
+#endif
+#ifdef AT91_PLATFORM_DRIVER
+	platform_driver_unregister(&AT91_PLATFORM_DRIVER);
+ error_at91:
+#endif
+#ifdef EP93XX_PLATFORM_DRIVER
+	platform_driver_unregister(&EP93XX_PLATFORM_DRIVER);
+ error_ep93xx:
+#endif
+#ifdef EXYNOS_PLATFORM_DRIVER
+	platform_driver_unregister(&EXYNOS_PLATFORM_DRIVER);
+ error_exynos:
+#endif
+#ifdef S3C2410_PLATFORM_DRIVER
+	platform_driver_unregister(&S3C2410_PLATFORM_DRIVER);
+ error_s3c2410:
+#endif
 #ifdef TMIO_OHCI_DRIVER
 	platform_driver_unregister(&TMIO_OHCI_DRIVER);
  error_tmio:
@@ -1300,17 +1376,17 @@ static int __init ohci_hcd_mod_init(void)
 	platform_driver_unregister(&OF_PLATFORM_DRIVER);
  error_of_platform:
 #endif
-#ifdef PLATFORM_DRIVER
-	platform_driver_unregister(&PLATFORM_DRIVER);
- error_platform:
+#ifdef OMAP3_PLATFORM_DRIVER
+	platform_driver_unregister(&OMAP3_PLATFORM_DRIVER);
+ error_omap3_platform:
 #endif
 #ifdef OMAP1_PLATFORM_DRIVER
 	platform_driver_unregister(&OMAP1_PLATFORM_DRIVER);
  error_omap1_platform:
 #endif
-#ifdef OMAP3_PLATFORM_DRIVER
-	platform_driver_unregister(&OMAP3_PLATFORM_DRIVER);
- error_omap3_platform:
+#ifdef PLATFORM_DRIVER
+	platform_driver_unregister(&PLATFORM_DRIVER);
+ error_platform:
 #endif
 #ifdef PS3_SYSTEM_BUS_DRIVER
 	ps3_ohci_driver_unregister(&PS3_SYSTEM_BUS_DRIVER);
@@ -1329,6 +1405,27 @@ module_init(ohci_hcd_mod_init);
 
 static void __exit ohci_hcd_mod_exit(void)
 {
+#ifdef SPEAR_PLATFORM_DRIVER
+	platform_driver_unregister(&SPEAR_PLATFORM_DRIVER);
+#endif
+#ifdef DAVINCI_PLATFORM_DRIVER
+	platform_driver_unregister(&DAVINCI_PLATFORM_DRIVER);
+#endif
+#ifdef NXP_PLATFORM_DRIVER
+	platform_driver_unregister(&NXP_PLATFORM_DRIVER);
+#endif
+#ifdef AT91_PLATFORM_DRIVER
+	platform_driver_unregister(&AT91_PLATFORM_DRIVER);
+#endif
+#ifdef EP93XX_PLATFORM_DRIVER
+	platform_driver_unregister(&EP93XX_PLATFORM_DRIVER);
+#endif
+#ifdef EXYNOS_PLATFORM_DRIVER
+	platform_driver_unregister(&EXYNOS_PLATFORM_DRIVER);
+#endif
+#ifdef S3C2410_PLATFORM_DRIVER
+	platform_driver_unregister(&S3C2410_PLATFORM_DRIVER);
+#endif
 #ifdef TMIO_OHCI_DRIVER
 	platform_driver_unregister(&TMIO_OHCI_DRIVER);
 #endif
@@ -1344,12 +1441,15 @@ static void __exit ohci_hcd_mod_exit(void)
 #ifdef OF_PLATFORM_DRIVER
 	platform_driver_unregister(&OF_PLATFORM_DRIVER);
 #endif
-#ifdef PLATFORM_DRIVER
-	platform_driver_unregister(&PLATFORM_DRIVER);
-#endif
 #ifdef OMAP3_PLATFORM_DRIVER
 	platform_driver_unregister(&OMAP3_PLATFORM_DRIVER);
 #endif
+#ifdef OMAP1_PLATFORM_DRIVER
+	platform_driver_unregister(&OMAP1_PLATFORM_DRIVER);
+#endif
+#ifdef PLATFORM_DRIVER
+	platform_driver_unregister(&PLATFORM_DRIVER);
+#endif
 #ifdef PS3_SYSTEM_BUS_DRIVER
 	ps3_ohci_driver_unregister(&PS3_SYSTEM_BUS_DRIVER);
 #endif
-- 
1.8.1.2

^ permalink raw reply related	[flat|nested] 131+ messages in thread

* Re: [PATCH 04/21] ARM: orion5x: include linux/cpu.h
  2013-04-25 17:28   ` Arnd Bergmann
@ 2013-04-25 17:34     ` Jason Cooper
  -1 siblings, 0 replies; 131+ messages in thread
From: Jason Cooper @ 2013-04-25 17:34 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: linux-arm-kernel, linux-kernel, Andrew Lunn

On Thu, Apr 25, 2013 at 07:28:47PM +0200, Arnd Bergmann wrote:
> The linux/cpu.h header is no longer implictly included in this
> file, so we need to an #include statement to avoid this build
> warning:
> 
> arch/arm/mach-orion5x/common.c:339:3: error: implicit declaration of function 'cpu_idle_poll_ctrl' [-Werror=implicit-function-declaration]
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Andrew Lunn <andrew@lunn.ch>
> ---
>  arch/arm/mach-orion5x/common.c | 1 +
>  1 file changed, 1 insertion(+)

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

I imagine it's easiest for you to take this through a branch you already
have set up, so have it.

thx,

Jason.

^ permalink raw reply	[flat|nested] 131+ messages in thread

* [PATCH 04/21] ARM: orion5x: include linux/cpu.h
@ 2013-04-25 17:34     ` Jason Cooper
  0 siblings, 0 replies; 131+ messages in thread
From: Jason Cooper @ 2013-04-25 17:34 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, Apr 25, 2013 at 07:28:47PM +0200, Arnd Bergmann wrote:
> The linux/cpu.h header is no longer implictly included in this
> file, so we need to an #include statement to avoid this build
> warning:
> 
> arch/arm/mach-orion5x/common.c:339:3: error: implicit declaration of function 'cpu_idle_poll_ctrl' [-Werror=implicit-function-declaration]
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Andrew Lunn <andrew@lunn.ch>
> ---
>  arch/arm/mach-orion5x/common.c | 1 +
>  1 file changed, 1 insertion(+)

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

I imagine it's easiest for you to take this through a branch you already
have set up, so have it.

thx,

Jason.

^ permalink raw reply	[flat|nested] 131+ messages in thread

* RE: [PATCH 13/21] iommu: tegra: print dma_addr_t using %lld
  2013-04-25 17:28   ` Arnd Bergmann
@ 2013-04-25 17:42     ` Sethi Varun-B16395
  -1 siblings, 0 replies; 131+ messages in thread
From: Sethi Varun-B16395 @ 2013-04-25 17:42 UTC (permalink / raw)
  To: Arnd Bergmann, linux-arm-kernel; +Cc: linux-kernel, Joerg Roedel

Hi Arnd,
I already submitted a patch to fix this.
http://permalink.gmane.org/gmane.linux.kernel.iommu/2036

Regards
Varun

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd@arndb.de]
> Sent: Thursday, April 25, 2013 10:59 PM
> To: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org; Arnd Bergmann; Sethi Varun-B16395;
> Joerg Roedel
> Subject: [PATCH 13/21] iommu: tegra: print dma_addr_t using %lld
> 
> The code was recently changed to work for builds with a 64 bit
> dma_addr_t, but the printk unconditionally uses a format string for an
> "long" variable, which is always wrong as the dma_add_t is now either
> 'unsigned int' or 'unsigned long long'
> depending on configuration.
> 
> The easiest solution is to cast the variable to u64 and print it as a 64
> bit value.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Varun Sethi <Varun.Sethi@freescale.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> ---
>  drivers/iommu/tegra-gart.c | 3 ++-
>  drivers/iommu/tegra-smmu.c | 2 +-
>  2 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/iommu/tegra-gart.c b/drivers/iommu/tegra-gart.c
> index 4aec8be..ebbdd82 100644
> --- a/drivers/iommu/tegra-gart.c
> +++ b/drivers/iommu/tegra-gart.c
> @@ -295,7 +295,8 @@ static phys_addr_t gart_iommu_iova_to_phys(struct
> iommu_domain *domain,
> 
>  	pa = (pte & GART_PAGE_MASK);
>  	if (!pfn_valid(__phys_to_pfn(pa))) {
> -		dev_err(gart->dev, "No entry for %08lx:%08x\n", iova, pa);
> +		dev_err(gart->dev, "No entry for %08llx:%pa\n",
> +				(u64)iova, &pa);
>  		gart_dump_table(gart);
>  		return -EINVAL;
>  	}
> diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
> index bc9b599..ef2a120 100644
> --- a/drivers/iommu/tegra-smmu.c
> +++ b/drivers/iommu/tegra-smmu.c
> @@ -772,7 +772,7 @@ static phys_addr_t smmu_iommu_iova_to_phys(struct
> iommu_domain *domain,
>  	pfn = *pte & SMMU_PFN_MASK;
>  	WARN_ON(!pfn_valid(pfn));
>  	dev_dbg(as->smmu->dev,
> -		"iova:%08lx pfn:%08lx asid:%d\n", iova, pfn, as->asid);
> +		"iova:%08llx pfn:%08lx asid:%d\n", (u64)iova, pfn, as->asid);
> 
>  	spin_unlock_irqrestore(&as->lock, flags);
>  	return PFN_PHYS(pfn);
> --
> 1.8.1.2
> 



^ permalink raw reply	[flat|nested] 131+ messages in thread

* [PATCH 13/21] iommu: tegra: print dma_addr_t using %lld
@ 2013-04-25 17:42     ` Sethi Varun-B16395
  0 siblings, 0 replies; 131+ messages in thread
From: Sethi Varun-B16395 @ 2013-04-25 17:42 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Arnd,
I already submitted a patch to fix this.
http://permalink.gmane.org/gmane.linux.kernel.iommu/2036

Regards
Varun

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: Thursday, April 25, 2013 10:59 PM
> To: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org; Arnd Bergmann; Sethi Varun-B16395;
> Joerg Roedel
> Subject: [PATCH 13/21] iommu: tegra: print dma_addr_t using %lld
> 
> The code was recently changed to work for builds with a 64 bit
> dma_addr_t, but the printk unconditionally uses a format string for an
> "long" variable, which is always wrong as the dma_add_t is now either
> 'unsigned int' or 'unsigned long long'
> depending on configuration.
> 
> The easiest solution is to cast the variable to u64 and print it as a 64
> bit value.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Varun Sethi <Varun.Sethi@freescale.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> ---
>  drivers/iommu/tegra-gart.c | 3 ++-
>  drivers/iommu/tegra-smmu.c | 2 +-
>  2 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/iommu/tegra-gart.c b/drivers/iommu/tegra-gart.c
> index 4aec8be..ebbdd82 100644
> --- a/drivers/iommu/tegra-gart.c
> +++ b/drivers/iommu/tegra-gart.c
> @@ -295,7 +295,8 @@ static phys_addr_t gart_iommu_iova_to_phys(struct
> iommu_domain *domain,
> 
>  	pa = (pte & GART_PAGE_MASK);
>  	if (!pfn_valid(__phys_to_pfn(pa))) {
> -		dev_err(gart->dev, "No entry for %08lx:%08x\n", iova, pa);
> +		dev_err(gart->dev, "No entry for %08llx:%pa\n",
> +				(u64)iova, &pa);
>  		gart_dump_table(gart);
>  		return -EINVAL;
>  	}
> diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
> index bc9b599..ef2a120 100644
> --- a/drivers/iommu/tegra-smmu.c
> +++ b/drivers/iommu/tegra-smmu.c
> @@ -772,7 +772,7 @@ static phys_addr_t smmu_iommu_iova_to_phys(struct
> iommu_domain *domain,
>  	pfn = *pte & SMMU_PFN_MASK;
>  	WARN_ON(!pfn_valid(pfn));
>  	dev_dbg(as->smmu->dev,
> -		"iova:%08lx pfn:%08lx asid:%d\n", iova, pfn, as->asid);
> +		"iova:%08llx pfn:%08lx asid:%d\n", (u64)iova, pfn, as->asid);
> 
>  	spin_unlock_irqrestore(&as->lock, flags);
>  	return PFN_PHYS(pfn);
> --
> 1.8.1.2
> 

^ permalink raw reply	[flat|nested] 131+ messages in thread

* Re: [PATCH 18/21] USB: ehci-msm: USB_MSM_OTG needs USB_PHY
  2013-04-25 17:29   ` Arnd Bergmann
@ 2013-04-25 17:59     ` Greg Kroah-Hartman
  -1 siblings, 0 replies; 131+ messages in thread
From: Greg Kroah-Hartman @ 2013-04-25 17:59 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: linux-arm-kernel, linux-kernel, linux-usb, Felipe Balbi,
	Pavankumar Kondeti

On Thu, Apr 25, 2013 at 07:29:01PM +0200, Arnd Bergmann wrote:
> The Kconfig entry for USB_EHCI_MSM unconditionally selects USB_MSM_OTG,
> which is now only visible when USB_PHY is also enabled.
> 
> This adds an appropriate dependency and enables USB_PHY in the msm
> defconfig, avoiding the Kbuild warning:
> 
> warning: (USB_EHCI_MSM) selects USB_MSM_OTG which has unmet direct dependencies (USB_SUPPORT && USB_PHY && (USB || USB_GADGET) && ARCH_MSM)
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: linux-usb@vger.kernel.org
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Felipe Balbi <balbi@ti.com>
> Cc: Pavankumar Kondeti <pkondeti@codeaurora.org>
> ---
>  arch/arm/configs/msm_defconfig | 1 +
>  drivers/usb/host/Kconfig       | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/arch/arm/configs/msm_defconfig b/arch/arm/configs/msm_defconfig
> index 44f9291..690b5f9 100644
> --- a/arch/arm/configs/msm_defconfig
> +++ b/arch/arm/configs/msm_defconfig
> @@ -101,6 +101,7 @@ CONFIG_SND_DYNAMIC_MINORS=y
>  CONFIG_SND_SOC=y
>  CONFIG_HID_BATTERY_STRENGTH=y
>  CONFIG_USB=y
> +CONFIG_USB_PHY=y
>  CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
>  CONFIG_USB_MON=y
>  CONFIG_USB_EHCI_HCD=y

This part of the patch doesn't apply to my tree, so I can't take it.

> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index c558472..de94f26 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -188,6 +188,7 @@ config USB_EHCI_HCD_AT91
>  config USB_EHCI_MSM
>  	tristate "Support for Qualcomm QSD/MSM on-chip EHCI USB controller"
>  	depends on ARCH_MSM
> +	depends on USB_PHY
>  	select USB_EHCI_ROOT_HUB_TT
>  	select USB_MSM_OTG
>  	---help---

But this does, and I'm guessing that it's the more important part, so
I'll just edit it and only take this hunk, ok?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 131+ messages in thread

* [PATCH 18/21] USB: ehci-msm: USB_MSM_OTG needs USB_PHY
@ 2013-04-25 17:59     ` Greg Kroah-Hartman
  0 siblings, 0 replies; 131+ messages in thread
From: Greg Kroah-Hartman @ 2013-04-25 17:59 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, Apr 25, 2013 at 07:29:01PM +0200, Arnd Bergmann wrote:
> The Kconfig entry for USB_EHCI_MSM unconditionally selects USB_MSM_OTG,
> which is now only visible when USB_PHY is also enabled.
> 
> This adds an appropriate dependency and enables USB_PHY in the msm
> defconfig, avoiding the Kbuild warning:
> 
> warning: (USB_EHCI_MSM) selects USB_MSM_OTG which has unmet direct dependencies (USB_SUPPORT && USB_PHY && (USB || USB_GADGET) && ARCH_MSM)
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: linux-usb at vger.kernel.org
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Felipe Balbi <balbi@ti.com>
> Cc: Pavankumar Kondeti <pkondeti@codeaurora.org>
> ---
>  arch/arm/configs/msm_defconfig | 1 +
>  drivers/usb/host/Kconfig       | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/arch/arm/configs/msm_defconfig b/arch/arm/configs/msm_defconfig
> index 44f9291..690b5f9 100644
> --- a/arch/arm/configs/msm_defconfig
> +++ b/arch/arm/configs/msm_defconfig
> @@ -101,6 +101,7 @@ CONFIG_SND_DYNAMIC_MINORS=y
>  CONFIG_SND_SOC=y
>  CONFIG_HID_BATTERY_STRENGTH=y
>  CONFIG_USB=y
> +CONFIG_USB_PHY=y
>  CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
>  CONFIG_USB_MON=y
>  CONFIG_USB_EHCI_HCD=y

This part of the patch doesn't apply to my tree, so I can't take it.

> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index c558472..de94f26 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -188,6 +188,7 @@ config USB_EHCI_HCD_AT91
>  config USB_EHCI_MSM
>  	tristate "Support for Qualcomm QSD/MSM on-chip EHCI USB controller"
>  	depends on ARCH_MSM
> +	depends on USB_PHY
>  	select USB_EHCI_ROOT_HUB_TT
>  	select USB_MSM_OTG
>  	---help---

But this does, and I'm guessing that it's the more important part, so
I'll just edit it and only take this hunk, ok?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 131+ messages in thread

* Re: [PATCH 14/21] cpufreq: pxa2xx: initialize variables
  2013-04-25 17:28   ` Arnd Bergmann
@ 2013-04-25 18:14     ` Rafael J. Wysocki
  -1 siblings, 0 replies; 131+ messages in thread
From: Rafael J. Wysocki @ 2013-04-25 18:14 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: linux-arm-kernel, linux-kernel, Viresh Kumar

On 4/25/2013 7:28 PM, Arnd Bergmann wrote:
> gcc-3.8 correctly found that the variables set by find_freq_tables()
> are not initialized if this function is called on something other
> than a pxa2xx or pxa3xx:
>
> pxa2xx-cpufreq.c: In function 'pxa_verify_policy':
> pxa2xx-cpufreq.c:272:6: warning: 'pxa_freqs_table' may be used uninitialized in this function [-Wmaybe-uninitialized]
> pxa2xx-cpufreq.c: In function 'pxa_set_target':
> pxa2xx-cpufreq.c:345:23: warning: 'pxa_freq_settings' may be used uninitialized in this function [-Wmaybe-uninitialized]
>
> Rather than adding a bogus initialization that would let us
> get a little further before crashing, add an explicit BUG().
> We know that this code is designed to run on only these cpus,
> so this will fix the build warning and give a more helpful
> diagnostic if the code ever changes to run on other machines.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Viresh Kumar <viresh.kumar@linaro.org>
> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

OK, applied.

Can you please CC future cpufreq changes to linux-pm@vger.kernel.org?  
That'd make the handling of them much easier.

Thanks,
Rafael


> ---
>   drivers/cpufreq/pxa2xx-cpufreq.c | 5 +++--
>   1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/cpufreq/pxa2xx-cpufreq.c b/drivers/cpufreq/pxa2xx-cpufreq.c
> index fe4c55b..9e5bc8e 100644
> --- a/drivers/cpufreq/pxa2xx-cpufreq.c
> +++ b/drivers/cpufreq/pxa2xx-cpufreq.c
> @@ -221,10 +221,11 @@ static void find_freq_tables(struct cpufreq_frequency_table **freq_table,
>   			*pxa_freqs = pxa255_turbo_freqs;
>   			*freq_table = pxa255_turbo_freq_table;
>   		}
> -	}
> -	if (cpu_is_pxa27x()) {
> +	} else if (cpu_is_pxa27x()) {
>   		*pxa_freqs = pxa27x_freqs;
>   		*freq_table = pxa27x_freq_table;
> +	} else {
> +		BUG();
>   	}
>   }
>   

---------------------------------------------------------------------
Intel Technology Poland sp. z o.o.
z siedziba w Gdansku
ul. Slowackiego 173
80-298 Gdansk

Sad Rejonowy Gdansk Polnoc w Gdansku, 
VII Wydzial Gospodarczy Krajowego Rejestru Sadowego, 
numer KRS 101882

NIP 957-07-52-316
Kapital zakladowy 200.000 zl

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


^ permalink raw reply	[flat|nested] 131+ messages in thread

* [PATCH 14/21] cpufreq: pxa2xx: initialize variables
@ 2013-04-25 18:14     ` Rafael J. Wysocki
  0 siblings, 0 replies; 131+ messages in thread
From: Rafael J. Wysocki @ 2013-04-25 18:14 UTC (permalink / raw)
  To: linux-arm-kernel

On 4/25/2013 7:28 PM, Arnd Bergmann wrote:
> gcc-3.8 correctly found that the variables set by find_freq_tables()
> are not initialized if this function is called on something other
> than a pxa2xx or pxa3xx:
>
> pxa2xx-cpufreq.c: In function 'pxa_verify_policy':
> pxa2xx-cpufreq.c:272:6: warning: 'pxa_freqs_table' may be used uninitialized in this function [-Wmaybe-uninitialized]
> pxa2xx-cpufreq.c: In function 'pxa_set_target':
> pxa2xx-cpufreq.c:345:23: warning: 'pxa_freq_settings' may be used uninitialized in this function [-Wmaybe-uninitialized]
>
> Rather than adding a bogus initialization that would let us
> get a little further before crashing, add an explicit BUG().
> We know that this code is designed to run on only these cpus,
> so this will fix the build warning and give a more helpful
> diagnostic if the code ever changes to run on other machines.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Viresh Kumar <viresh.kumar@linaro.org>
> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

OK, applied.

Can you please CC future cpufreq changes to linux-pm at vger.kernel.org?  
That'd make the handling of them much easier.

Thanks,
Rafael


> ---
>   drivers/cpufreq/pxa2xx-cpufreq.c | 5 +++--
>   1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/cpufreq/pxa2xx-cpufreq.c b/drivers/cpufreq/pxa2xx-cpufreq.c
> index fe4c55b..9e5bc8e 100644
> --- a/drivers/cpufreq/pxa2xx-cpufreq.c
> +++ b/drivers/cpufreq/pxa2xx-cpufreq.c
> @@ -221,10 +221,11 @@ static void find_freq_tables(struct cpufreq_frequency_table **freq_table,
>   			*pxa_freqs = pxa255_turbo_freqs;
>   			*freq_table = pxa255_turbo_freq_table;
>   		}
> -	}
> -	if (cpu_is_pxa27x()) {
> +	} else if (cpu_is_pxa27x()) {
>   		*pxa_freqs = pxa27x_freqs;
>   		*freq_table = pxa27x_freq_table;
> +	} else {
> +		BUG();
>   	}
>   }
>   

---------------------------------------------------------------------
Intel Technology Poland sp. z o.o.
z siedziba w Gdansku
ul. Slowackiego 173
80-298 Gdansk

Sad Rejonowy Gdansk Polnoc w Gdansku, 
VII Wydzial Gospodarczy Krajowego Rejestru Sadowego, 
numer KRS 101882

NIP 957-07-52-316
Kapital zakladowy 200.000 zl

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

^ permalink raw reply	[flat|nested] 131+ messages in thread

* Re: [PATCH 04/21] ARM: orion5x: include linux/cpu.h
  2013-04-25 17:34     ` Jason Cooper
@ 2013-04-25 18:27       ` Jason Cooper
  -1 siblings, 0 replies; 131+ messages in thread
From: Jason Cooper @ 2013-04-25 18:27 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: Andrew Lunn, linux-kernel, linux-arm-kernel

On Thu, Apr 25, 2013 at 01:34:45PM -0400, Jason Cooper wrote:
> On Thu, Apr 25, 2013 at 07:28:47PM +0200, Arnd Bergmann wrote:
> > The linux/cpu.h header is no longer implictly included in this
> > file, so we need to an #include statement to avoid this build
> > warning:
> > 
> > arch/arm/mach-orion5x/common.c:339:3: error: implicit declaration of function 'cpu_idle_poll_ctrl' [-Werror=implicit-function-declaration]
> > 
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Jason Cooper <jason@lakedaemon.net>
> > Cc: Andrew Lunn <andrew@lunn.ch>
> > ---
> >  arch/arm/mach-orion5x/common.c | 1 +
> >  1 file changed, 1 insertion(+)
> 
> Acked-by: Jason Cooper <jason@lakedaemon.net>
> 
> I imagine it's easiest for you to take this through a branch you already
> have set up, so have it.

s/have it/have at it/  :)

thx,

Jason.

^ permalink raw reply	[flat|nested] 131+ messages in thread

* [PATCH 04/21] ARM: orion5x: include linux/cpu.h
@ 2013-04-25 18:27       ` Jason Cooper
  0 siblings, 0 replies; 131+ messages in thread
From: Jason Cooper @ 2013-04-25 18:27 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, Apr 25, 2013 at 01:34:45PM -0400, Jason Cooper wrote:
> On Thu, Apr 25, 2013 at 07:28:47PM +0200, Arnd Bergmann wrote:
> > The linux/cpu.h header is no longer implictly included in this
> > file, so we need to an #include statement to avoid this build
> > warning:
> > 
> > arch/arm/mach-orion5x/common.c:339:3: error: implicit declaration of function 'cpu_idle_poll_ctrl' [-Werror=implicit-function-declaration]
> > 
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Jason Cooper <jason@lakedaemon.net>
> > Cc: Andrew Lunn <andrew@lunn.ch>
> > ---
> >  arch/arm/mach-orion5x/common.c | 1 +
> >  1 file changed, 1 insertion(+)
> 
> Acked-by: Jason Cooper <jason@lakedaemon.net>
> 
> I imagine it's easiest for you to take this through a branch you already
> have set up, so have it.

s/have it/have at it/  :)

thx,

Jason.

^ permalink raw reply	[flat|nested] 131+ messages in thread

* Re: [PATCH 19/21] USB: lpc32xx: ISP1301 needs USB_PHY
  2013-04-25 17:29   ` Arnd Bergmann
@ 2013-04-25 19:50     ` Roland Stigge
  -1 siblings, 0 replies; 131+ messages in thread
From: Roland Stigge @ 2013-04-25 19:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: linux-arm-kernel, linux-kernel, linux-usb, Greg Kroah-Hartman,
	Felipe Balbi

On 25/04/13 19:29, Arnd Bergmann wrote:
> The Kconfig entry for USB_LPC32XX unconditionally selects USB_ISP1301,
> which is now only visible when USB_PHY is also enabled.
> 
> This adds an appropriate dependency and enables USB_PHY in the msm
> defconfig, avoiding these build errors:
> 
> warning: (USB_LPC32XX) selects USB_ISP1301 which has unmet direct dependencies (USB_SUPPORT && USB_PHY && (USB || USB_GADGET) && I2C)
> drivers/built-in.o: In function `usb_hcd_nxp_probe':
> drivers/usb/host/ohci-nxp.c:224: undefined reference to `isp1301_get_client'
> drivers/built-in.o: In function `lpc32xx_udc_probe':
> drivers/usb/gadget/lpc32xx_udc.c:3071: undefined reference to `isp1301_get_client'
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: linux-usb@vger.kernel.org
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Felipe Balbi <balbi@ti.com>
> Cc: Roland Stigge <stigge@antcom.de>

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

> ---
>  arch/arm/configs/lpc32xx_defconfig | 1 +
>  drivers/usb/gadget/Kconfig         | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/arch/arm/configs/lpc32xx_defconfig b/arch/arm/configs/lpc32xx_defconfig
> index 8fee514..398a367 100644
> --- a/arch/arm/configs/lpc32xx_defconfig
> +++ b/arch/arm/configs/lpc32xx_defconfig
> @@ -146,6 +146,7 @@ CONFIG_SND_DEBUG_VERBOSE=y
>  # CONFIG_SND_SPI is not set
>  CONFIG_SND_SOC=y
>  CONFIG_USB=y
> +CONFIG_USB_PHY=y
>  CONFIG_USB_OHCI_HCD=y
>  CONFIG_USB_STORAGE=y
>  CONFIG_USB_GADGET=y
> diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
> index a61d981..f85b427 100644
> --- a/drivers/usb/gadget/Kconfig
> +++ b/drivers/usb/gadget/Kconfig
> @@ -144,6 +144,7 @@ config USB_AT91
>  config USB_LPC32XX
>  	tristate "LPC32XX USB Peripheral Controller"
>  	depends on ARCH_LPC32XX
> +	depends on USB_PHY
>  	select USB_ISP1301
>  	select USB_OTG_UTILS
>  	help


^ permalink raw reply	[flat|nested] 131+ messages in thread

* [PATCH 19/21] USB: lpc32xx: ISP1301 needs USB_PHY
@ 2013-04-25 19:50     ` Roland Stigge
  0 siblings, 0 replies; 131+ messages in thread
From: Roland Stigge @ 2013-04-25 19:50 UTC (permalink / raw)
  To: linux-arm-kernel

On 25/04/13 19:29, Arnd Bergmann wrote:
> The Kconfig entry for USB_LPC32XX unconditionally selects USB_ISP1301,
> which is now only visible when USB_PHY is also enabled.
> 
> This adds an appropriate dependency and enables USB_PHY in the msm
> defconfig, avoiding these build errors:
> 
> warning: (USB_LPC32XX) selects USB_ISP1301 which has unmet direct dependencies (USB_SUPPORT && USB_PHY && (USB || USB_GADGET) && I2C)
> drivers/built-in.o: In function `usb_hcd_nxp_probe':
> drivers/usb/host/ohci-nxp.c:224: undefined reference to `isp1301_get_client'
> drivers/built-in.o: In function `lpc32xx_udc_probe':
> drivers/usb/gadget/lpc32xx_udc.c:3071: undefined reference to `isp1301_get_client'
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: linux-usb at vger.kernel.org
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Felipe Balbi <balbi@ti.com>
> Cc: Roland Stigge <stigge@antcom.de>

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

> ---
>  arch/arm/configs/lpc32xx_defconfig | 1 +
>  drivers/usb/gadget/Kconfig         | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/arch/arm/configs/lpc32xx_defconfig b/arch/arm/configs/lpc32xx_defconfig
> index 8fee514..398a367 100644
> --- a/arch/arm/configs/lpc32xx_defconfig
> +++ b/arch/arm/configs/lpc32xx_defconfig
> @@ -146,6 +146,7 @@ CONFIG_SND_DEBUG_VERBOSE=y
>  # CONFIG_SND_SPI is not set
>  CONFIG_SND_SOC=y
>  CONFIG_USB=y
> +CONFIG_USB_PHY=y
>  CONFIG_USB_OHCI_HCD=y
>  CONFIG_USB_STORAGE=y
>  CONFIG_USB_GADGET=y
> diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
> index a61d981..f85b427 100644
> --- a/drivers/usb/gadget/Kconfig
> +++ b/drivers/usb/gadget/Kconfig
> @@ -144,6 +144,7 @@ config USB_AT91
>  config USB_LPC32XX
>  	tristate "LPC32XX USB Peripheral Controller"
>  	depends on ARCH_LPC32XX
> +	depends on USB_PHY
>  	select USB_ISP1301
>  	select USB_OTG_UTILS
>  	help

^ permalink raw reply	[flat|nested] 131+ messages in thread

* Re: [PATCH 15/21] thermal: cooling: avoid uninitialied used gcc warning
  2013-04-25 17:28   ` Arnd Bergmann
@ 2013-04-25 20:07     ` edubezval at gmail.com
  -1 siblings, 0 replies; 131+ messages in thread
From: edubezval @ 2013-04-25 20:07 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: linux-arm-kernel, linux-kernel, Zhang Rui, Amit Daniel kachhap,
	Valentin, Eduardo

Arnd,

On Thu, Apr 25, 2013 at 1:28 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> The newly rewritten get_property() function causes a bogus warning
> from gcc-3.8, which cannot figure out that "level" is always
> initialized at the point where it gets evaluated:
>
> drivers/thermal/cpu_cooling.c: In function 'get_property':
> drivers/thermal/cpu_cooling.c:189:37: warning: 'level' may be used uninitialized in this function [-Wmaybe-uninitialized]
>    if (property == GET_FREQ && level == j) {
>                                      ^
>
> Slightly rearranging the code makes this more obvious and
> avoids the warning.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Zhang Rui <rui.zhang@intel.com>
> Cc: Amit Daniel kachhap <amit.daniel@samsung.com>

Rui has merged a patch that removes this bogus compiler warning:
http://git.kernel.org/cgit/linux/kernel/git/rzhang/linux.git/commit/?h=next&id=4469b99743d296e24aefc5f8ed7df1bc9cfbbac8

Though, as not as elegant as your patch, it does the trick. :-)

> ---
>  drivers/thermal/cpu_cooling.c | 17 +++++++++--------
>  1 file changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
> index 768b508..34878e6 100644
> --- a/drivers/thermal/cpu_cooling.c
> +++ b/drivers/thermal/cpu_cooling.c
> @@ -165,10 +165,6 @@ static int get_property(unsigned int cpu, unsigned long input,
>                 return 0;
>         }
>
> -       if (property == GET_FREQ)
> -               level = descend ? input : (max_level - input -1);
> -
> -
>         for (i = 0, j = 0; table[i].frequency != CPUFREQ_TABLE_END; i++) {
>                 /* ignore invalid entry */
>                 if (table[i].frequency == CPUFREQ_ENTRY_INVALID)
> @@ -186,10 +182,15 @@ static int get_property(unsigned int cpu, unsigned long input,
>                         *output = descend ? j : (max_level - j - 1);
>                         return 0;
>                 }
> -               if (property == GET_FREQ && level == j) {
> -                       /* get frequency by level */
> -                       *output = freq;
> -                       return 0;
> +
> +               if (property == GET_FREQ) {
> +                       level = descend ? input : (max_level - input -1);
> +
> +                       if (level == j) {
> +                               /* get frequency by level */
> +                               *output = freq;
> +                               return 0;
> +                       }
>                 }
>                 j++;
>         }
> --
> 1.8.1.2
>
> --
> 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/



-- 
Eduardo Bezerra Valentin

^ permalink raw reply	[flat|nested] 131+ messages in thread

* [PATCH 15/21] thermal: cooling: avoid uninitialied used gcc warning
@ 2013-04-25 20:07     ` edubezval at gmail.com
  0 siblings, 0 replies; 131+ messages in thread
From: edubezval at gmail.com @ 2013-04-25 20:07 UTC (permalink / raw)
  To: linux-arm-kernel

Arnd,

On Thu, Apr 25, 2013 at 1:28 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> The newly rewritten get_property() function causes a bogus warning
> from gcc-3.8, which cannot figure out that "level" is always
> initialized at the point where it gets evaluated:
>
> drivers/thermal/cpu_cooling.c: In function 'get_property':
> drivers/thermal/cpu_cooling.c:189:37: warning: 'level' may be used uninitialized in this function [-Wmaybe-uninitialized]
>    if (property == GET_FREQ && level == j) {
>                                      ^
>
> Slightly rearranging the code makes this more obvious and
> avoids the warning.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Zhang Rui <rui.zhang@intel.com>
> Cc: Amit Daniel kachhap <amit.daniel@samsung.com>

Rui has merged a patch that removes this bogus compiler warning:
http://git.kernel.org/cgit/linux/kernel/git/rzhang/linux.git/commit/?h=next&id=4469b99743d296e24aefc5f8ed7df1bc9cfbbac8

Though, as not as elegant as your patch, it does the trick. :-)

> ---
>  drivers/thermal/cpu_cooling.c | 17 +++++++++--------
>  1 file changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
> index 768b508..34878e6 100644
> --- a/drivers/thermal/cpu_cooling.c
> +++ b/drivers/thermal/cpu_cooling.c
> @@ -165,10 +165,6 @@ static int get_property(unsigned int cpu, unsigned long input,
>                 return 0;
>         }
>
> -       if (property == GET_FREQ)
> -               level = descend ? input : (max_level - input -1);
> -
> -
>         for (i = 0, j = 0; table[i].frequency != CPUFREQ_TABLE_END; i++) {
>                 /* ignore invalid entry */
>                 if (table[i].frequency == CPUFREQ_ENTRY_INVALID)
> @@ -186,10 +182,15 @@ static int get_property(unsigned int cpu, unsigned long input,
>                         *output = descend ? j : (max_level - j - 1);
>                         return 0;
>                 }
> -               if (property == GET_FREQ && level == j) {
> -                       /* get frequency by level */
> -                       *output = freq;
> -                       return 0;
> +
> +               if (property == GET_FREQ) {
> +                       level = descend ? input : (max_level - input -1);
> +
> +                       if (level == j) {
> +                               /* get frequency by level */
> +                               *output = freq;
> +                               return 0;
> +                       }
>                 }
>                 j++;
>         }
> --
> 1.8.1.2
>
> --
> 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/



-- 
Eduardo Bezerra Valentin

^ permalink raw reply	[flat|nested] 131+ messages in thread

* Re: [PATCH 15/21] thermal: cooling: avoid uninitialied used gcc warning
  2013-04-25 20:07     ` edubezval at gmail.com
@ 2013-04-25 21:09       ` Arnd Bergmann
  -1 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 21:09 UTC (permalink / raw)
  To: edubezval
  Cc: linux-arm-kernel, linux-kernel, Zhang Rui, Amit Daniel kachhap,
	Valentin, Eduardo

On Thursday 25 April 2013, edubezval@gmail.com wrote:
> Rui has merged a patch that removes this bogus compiler warning:
> http://git.kernel.org/cgit/linux/kernel/git/rzhang/linux.git/commit/?h=next&amp;id=4469b99743d296e24aefc5f8ed7df1bc9cfbbac8
> 
> Though, as not as elegant as your patch, it does the trick. :-)

Ok, works for me.

Looking at the patch however tells me that it has the potential to hide real
bugs if the code is ever changed to actually do an uninitialized access.
It's not very likely in this case, but I generally recommend not to add
any variables at declaration time unless the initialization is to a
meaningful value that the code later uses.

	Arnd

^ permalink raw reply	[flat|nested] 131+ messages in thread

* [PATCH 15/21] thermal: cooling: avoid uninitialied used gcc warning
@ 2013-04-25 21:09       ` Arnd Bergmann
  0 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 21:09 UTC (permalink / raw)
  To: linux-arm-kernel

On Thursday 25 April 2013, edubezval at gmail.com wrote:
> Rui has merged a patch that removes this bogus compiler warning:
> http://git.kernel.org/cgit/linux/kernel/git/rzhang/linux.git/commit/?h=next&amp;id=4469b99743d296e24aefc5f8ed7df1bc9cfbbac8
> 
> Though, as not as elegant as your patch, it does the trick. :-)

Ok, works for me.

Looking at the patch however tells me that it has the potential to hide real
bugs if the code is ever changed to actually do an uninitialized access.
It's not very likely in this case, but I generally recommend not to add
any variables at declaration time unless the initialization is to a
meaningful value that the code later uses.

	Arnd

^ permalink raw reply	[flat|nested] 131+ messages in thread

* Re: [PATCH 14/21] cpufreq: pxa2xx: initialize variables
  2013-04-25 18:14     ` Rafael J. Wysocki
@ 2013-04-25 21:09       ` Arnd Bergmann
  -1 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 21:09 UTC (permalink / raw)
  To: Rafael J. Wysocki; +Cc: linux-arm-kernel, linux-kernel, Viresh Kumar

On Thursday 25 April 2013, Rafael J. Wysocki wrote:
> On 4/25/2013 7:28 PM, Arnd Bergmann wrote:
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Viresh Kumar <viresh.kumar@linaro.org>
> > Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> 
> OK, applied.
> 
> Can you please CC future cpufreq changes to linux-pm@vger.kernel.org?  
> That'd make the handling of them much easier.

Sure, I'll try to rembember next time. Thanks for applying it
anyway.

	Arnd

^ permalink raw reply	[flat|nested] 131+ messages in thread

* [PATCH 14/21] cpufreq: pxa2xx: initialize variables
@ 2013-04-25 21:09       ` Arnd Bergmann
  0 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 21:09 UTC (permalink / raw)
  To: linux-arm-kernel

On Thursday 25 April 2013, Rafael J. Wysocki wrote:
> On 4/25/2013 7:28 PM, Arnd Bergmann wrote:
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Viresh Kumar <viresh.kumar@linaro.org>
> > Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> 
> OK, applied.
> 
> Can you please CC future cpufreq changes to linux-pm at vger.kernel.org?  
> That'd make the handling of them much easier.

Sure, I'll try to rembember next time. Thanks for applying it
anyway.

	Arnd

^ permalink raw reply	[flat|nested] 131+ messages in thread

* Re: [PATCH 18/21] USB: ehci-msm: USB_MSM_OTG needs USB_PHY
  2013-04-25 17:59     ` Greg Kroah-Hartman
@ 2013-04-25 21:12       ` Arnd Bergmann
  -1 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 21:12 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: linux-arm-kernel, linux-kernel, linux-usb, Felipe Balbi,
	Pavankumar Kondeti

On Thursday 25 April 2013, Greg Kroah-Hartman wrote:
> > diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> > index c558472..de94f26 100644
> > --- a/drivers/usb/host/Kconfig
> > +++ b/drivers/usb/host/Kconfig
> > @@ -188,6 +188,7 @@ config USB_EHCI_HCD_AT91
> >  config USB_EHCI_MSM
> >       tristate "Support for Qualcomm QSD/MSM on-chip EHCI USB controller"
> >       depends on ARCH_MSM
> > +     depends on USB_PHY
> >       select USB_EHCI_ROOT_HUB_TT
> >       select USB_MSM_OTG
> >       ---help---
> 
> But this does, and I'm guessing that it's the more important part, so
> I'll just edit it and only take this hunk, ok?

Ok, thanks! Sorry for bothering you with the hand editing. I'll apply
the defconfig change to arm-soc then.

	Arnd

^ permalink raw reply	[flat|nested] 131+ messages in thread

* [PATCH 18/21] USB: ehci-msm: USB_MSM_OTG needs USB_PHY
@ 2013-04-25 21:12       ` Arnd Bergmann
  0 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-25 21:12 UTC (permalink / raw)
  To: linux-arm-kernel

On Thursday 25 April 2013, Greg Kroah-Hartman wrote:
> > diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> > index c558472..de94f26 100644
> > --- a/drivers/usb/host/Kconfig
> > +++ b/drivers/usb/host/Kconfig
> > @@ -188,6 +188,7 @@ config USB_EHCI_HCD_AT91
> >  config USB_EHCI_MSM
> >       tristate "Support for Qualcomm QSD/MSM on-chip EHCI USB controller"
> >       depends on ARCH_MSM
> > +     depends on USB_PHY
> >       select USB_EHCI_ROOT_HUB_TT
> >       select USB_MSM_OTG
> >       ---help---
> 
> But this does, and I'm guessing that it's the more important part, so
> I'll just edit it and only take this hunk, ok?

Ok, thanks! Sorry for bothering you with the hand editing. I'll apply
the defconfig change to arm-soc then.

	Arnd

^ permalink raw reply	[flat|nested] 131+ messages in thread

* Re: [PATCH 10/21] [SCSI] nsp32: use mdelay instead of large udelay constants
  2013-04-25 17:28   ` Arnd Bergmann
@ 2013-04-26  0:42     ` Masanori Goto
  -1 siblings, 0 replies; 131+ messages in thread
From: Masanori Goto @ 2013-04-26  0:42 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: linux-arm-kernel, linux-kernel, YOKOTA Hiroshi,
	James E.J. Bottomley, linux-scsi

2013/4/25 Arnd Bergmann <arnd@arndb.de>
>
> ARM cannot handle udelay for more than 2 miliseconds, so we
> should use mdelay instead for those.
>

Singed-off-by: GOTO Masanori <gotom@debian.or.jp>

> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: GOTO Masanori <gotom@debian.or.jp>
> Cc: YOKOTA Hiroshi <yokota@netlab.is.tsukuba.ac.jp>
> Cc: "James E.J. Bottomley" <JBottomley@parallels.com>
> Cc: linux-scsi@vger.kernel.org
> ---
>  drivers/scsi/nsp32.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/nsp32.c b/drivers/scsi/nsp32.c
> index 1e3879d..0665f9c 100644
> --- a/drivers/scsi/nsp32.c
> +++ b/drivers/scsi/nsp32.c
> @@ -2899,7 +2899,7 @@ static void nsp32_do_bus_reset(nsp32_hw_data *data)
>          * reset SCSI bus
>          */
>         nsp32_write1(base, SCSI_BUS_CONTROL, BUSCTL_RST);
> -       udelay(RESET_HOLD_TIME);
> +       mdelay(RESET_HOLD_TIME / 1000);
>         nsp32_write1(base, SCSI_BUS_CONTROL, 0);
>         for(i = 0; i < 5; i++) {
>                 intrdat = nsp32_read2(base, IRQ_STATUS); /* dummy read */
> --
> 1.8.1.2
>

^ permalink raw reply	[flat|nested] 131+ messages in thread

* [PATCH 10/21] [SCSI] nsp32: use mdelay instead of large udelay constants
@ 2013-04-26  0:42     ` Masanori Goto
  0 siblings, 0 replies; 131+ messages in thread
From: Masanori Goto @ 2013-04-26  0:42 UTC (permalink / raw)
  To: linux-arm-kernel

2013/4/25 Arnd Bergmann <arnd@arndb.de>
>
> ARM cannot handle udelay for more than 2 miliseconds, so we
> should use mdelay instead for those.
>

Singed-off-by: GOTO Masanori <gotom@debian.or.jp>

> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: GOTO Masanori <gotom@debian.or.jp>
> Cc: YOKOTA Hiroshi <yokota@netlab.is.tsukuba.ac.jp>
> Cc: "James E.J. Bottomley" <JBottomley@parallels.com>
> Cc: linux-scsi at vger.kernel.org
> ---
>  drivers/scsi/nsp32.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/nsp32.c b/drivers/scsi/nsp32.c
> index 1e3879d..0665f9c 100644
> --- a/drivers/scsi/nsp32.c
> +++ b/drivers/scsi/nsp32.c
> @@ -2899,7 +2899,7 @@ static void nsp32_do_bus_reset(nsp32_hw_data *data)
>          * reset SCSI bus
>          */
>         nsp32_write1(base, SCSI_BUS_CONTROL, BUSCTL_RST);
> -       udelay(RESET_HOLD_TIME);
> +       mdelay(RESET_HOLD_TIME / 1000);
>         nsp32_write1(base, SCSI_BUS_CONTROL, 0);
>         for(i = 0; i < 5; i++) {
>                 intrdat = nsp32_read2(base, IRQ_STATUS); /* dummy read */
> --
> 1.8.1.2
>

^ permalink raw reply	[flat|nested] 131+ messages in thread

* Re: [PATCH 03/21] ARM: shmobile: don't call irqchip_init unconditionally
  2013-04-25 17:28   ` Arnd Bergmann
@ 2013-04-26  0:48     ` Simon Horman
  -1 siblings, 0 replies; 131+ messages in thread
From: Simon Horman @ 2013-04-26  0:48 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: linux-arm-kernel, linux-kernel, Bastian Hecht, Kuninori Morimoto

On Thu, Apr 25, 2013 at 07:28:46PM +0200, Arnd Bergmann wrote:
> The irqchip_init function is only available when building
> with CONFIG_OF enabled, which causes this build failure for
> bonito_defconfig:
> 
> arch/arm/mach-shmobile/built-in.o: In function `r8a7740_init_irq_of':
> :(.init.text+0x580): undefined reference to `irqchip_init'
> 
> This makes both the OF and the ATAGS portion of the driver
> conditional, which avoids the build error and also results
> in smaller object code if not both are enabled, without the
> need for an #ifdef.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Bastian Hecht <hechtb+renesas@gmail.com>
> Cc: Simon Horman <horms+renesas@verge.net.au>
> Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> ---
>  arch/arm/mach-shmobile/intc-r8a7740.c | 13 +++++++++++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-shmobile/intc-r8a7740.c b/arch/arm/mach-shmobile/intc-r8a7740.c
> index 8871f77..5dc57f1 100644
> --- a/arch/arm/mach-shmobile/intc-r8a7740.c
> +++ b/arch/arm/mach-shmobile/intc-r8a7740.c
> @@ -53,14 +53,23 @@ static void __init r8a7740_init_irq_common(void)
>  
>  void __init r8a7740_init_irq_of(void)
>  {
> +	if (!IS_ENABLED(CONFIG_OF))
> +		return;
> +

In other parts of the shmobile I believe that such code is
guarded by #ifdef CONFIG_OF and I believe not guarding this code in
some way was an oversight.

The above change seems fine to me.

>  	irqchip_init();
>  	r8a7740_init_irq_common();
>  }
>  
>  void __init r8a7740_init_irq(void)
>  {
> -	void __iomem *gic_dist_base = ioremap_nocache(0xc2800000, 0x1000);
> -	void __iomem *gic_cpu_base = ioremap_nocache(0xc2000000, 0x1000);
> +	void __iomem *gic_dist_base;
> +	void __iomem *gic_cpu_base;
> +
> +	if (!IS_ENABLED(CONFIG_ATAGS))
> +		return;
> +
> +	gic_dist_base = ioremap_nocache(0xc2800000, 0x1000);
> +	gic_cpu_base = ioremap_nocache(0xc2000000, 0x1000);
>  
>  	/* initialize the Generic Interrupt Controller PL390 r0p0 */
>  	gic_init(0, 29, gic_dist_base, gic_cpu_base);

This one seems broken as the armadillo800eva board currently uses
it to initialise GIC even if CONFIG_ATAGS is not defined.

I did test the above change on the armadillo800eva board
with the above change and CONFIG_ATAGS disabled, the result was
a boot failure. With the change reverted booting seems fine.

^ permalink raw reply	[flat|nested] 131+ messages in thread

* [PATCH 03/21] ARM: shmobile: don't call irqchip_init unconditionally
@ 2013-04-26  0:48     ` Simon Horman
  0 siblings, 0 replies; 131+ messages in thread
From: Simon Horman @ 2013-04-26  0:48 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, Apr 25, 2013 at 07:28:46PM +0200, Arnd Bergmann wrote:
> The irqchip_init function is only available when building
> with CONFIG_OF enabled, which causes this build failure for
> bonito_defconfig:
> 
> arch/arm/mach-shmobile/built-in.o: In function `r8a7740_init_irq_of':
> :(.init.text+0x580): undefined reference to `irqchip_init'
> 
> This makes both the OF and the ATAGS portion of the driver
> conditional, which avoids the build error and also results
> in smaller object code if not both are enabled, without the
> need for an #ifdef.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Bastian Hecht <hechtb+renesas@gmail.com>
> Cc: Simon Horman <horms+renesas@verge.net.au>
> Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> ---
>  arch/arm/mach-shmobile/intc-r8a7740.c | 13 +++++++++++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-shmobile/intc-r8a7740.c b/arch/arm/mach-shmobile/intc-r8a7740.c
> index 8871f77..5dc57f1 100644
> --- a/arch/arm/mach-shmobile/intc-r8a7740.c
> +++ b/arch/arm/mach-shmobile/intc-r8a7740.c
> @@ -53,14 +53,23 @@ static void __init r8a7740_init_irq_common(void)
>  
>  void __init r8a7740_init_irq_of(void)
>  {
> +	if (!IS_ENABLED(CONFIG_OF))
> +		return;
> +

In other parts of the shmobile I believe that such code is
guarded by #ifdef CONFIG_OF and I believe not guarding this code in
some way was an oversight.

The above change seems fine to me.

>  	irqchip_init();
>  	r8a7740_init_irq_common();
>  }
>  
>  void __init r8a7740_init_irq(void)
>  {
> -	void __iomem *gic_dist_base = ioremap_nocache(0xc2800000, 0x1000);
> -	void __iomem *gic_cpu_base = ioremap_nocache(0xc2000000, 0x1000);
> +	void __iomem *gic_dist_base;
> +	void __iomem *gic_cpu_base;
> +
> +	if (!IS_ENABLED(CONFIG_ATAGS))
> +		return;
> +
> +	gic_dist_base = ioremap_nocache(0xc2800000, 0x1000);
> +	gic_cpu_base = ioremap_nocache(0xc2000000, 0x1000);
>  
>  	/* initialize the Generic Interrupt Controller PL390 r0p0 */
>  	gic_init(0, 29, gic_dist_base, gic_cpu_base);

This one seems broken as the armadillo800eva board currently uses
it to initialise GIC even if CONFIG_ATAGS is not defined.

I did test the above change on the armadillo800eva board
with the above change and CONFIG_ATAGS disabled, the result was
a boot failure. With the change reverted booting seems fine.

^ permalink raw reply	[flat|nested] 131+ messages in thread

* Re: [PATCH 11/21] irqdomain: export irq_domain_add_simple
  2013-04-25 17:28   ` Arnd Bergmann
@ 2013-04-26  0:50     ` Simon Horman
  -1 siblings, 0 replies; 131+ messages in thread
From: Simon Horman @ 2013-04-26  0:50 UTC (permalink / raw)
  To: Arnd Bergmann, Grant Likely
  Cc: linux-arm-kernel, linux-kernel, Benjamin Herrenschmidt,
	Thomas Gleixner, Laurent Pinchart, Magnus Damm

On Thu, Apr 25, 2013 at 07:28:54PM +0200, Arnd Bergmann wrote:
> All other irq_domain_add_* functions are exported already, and apparently
> this one got left out by mistake, which causes build errors for ARM
> allmodconfig kernels:
> 
> ERROR: "irq_domain_add_simple" [drivers/gpio/gpio-rcar.ko] undefined!
> ERROR: "irq_domain_add_simple" [drivers/gpio/gpio-em.ko] undefined!
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Grant Likely <grant.likely@linaro.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Simon Horman <horms+renesas@verge.net.au>
> Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> Cc: Magnus Damm <damm@opensource.se>

Acked-by: Simon Horman <horms+renesas@verge.net.au>

Grant, could consider taking this one?

> ---
>  kernel/irq/irqdomain.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
> index 059a280..c532c15 100644
> --- a/kernel/irq/irqdomain.c
> +++ b/kernel/irq/irqdomain.c
> @@ -194,6 +194,7 @@ struct irq_domain *irq_domain_add_simple(struct device_node *of_node,
>  	/* A linear domain is the default */
>  	return irq_domain_add_linear(of_node, size, ops, host_data);
>  }
> +EXPORT_SYMBOL_GPL(irq_domain_add_simple);
>  
>  /**
>   * irq_domain_add_legacy() - Allocate and register a legacy revmap irq_domain.
> -- 
> 1.8.1.2
> 

^ permalink raw reply	[flat|nested] 131+ messages in thread

* [PATCH 11/21] irqdomain: export irq_domain_add_simple
@ 2013-04-26  0:50     ` Simon Horman
  0 siblings, 0 replies; 131+ messages in thread
From: Simon Horman @ 2013-04-26  0:50 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, Apr 25, 2013 at 07:28:54PM +0200, Arnd Bergmann wrote:
> All other irq_domain_add_* functions are exported already, and apparently
> this one got left out by mistake, which causes build errors for ARM
> allmodconfig kernels:
> 
> ERROR: "irq_domain_add_simple" [drivers/gpio/gpio-rcar.ko] undefined!
> ERROR: "irq_domain_add_simple" [drivers/gpio/gpio-em.ko] undefined!
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Grant Likely <grant.likely@linaro.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Simon Horman <horms+renesas@verge.net.au>
> Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> Cc: Magnus Damm <damm@opensource.se>

Acked-by: Simon Horman <horms+renesas@verge.net.au>

Grant, could consider taking this one?

> ---
>  kernel/irq/irqdomain.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
> index 059a280..c532c15 100644
> --- a/kernel/irq/irqdomain.c
> +++ b/kernel/irq/irqdomain.c
> @@ -194,6 +194,7 @@ struct irq_domain *irq_domain_add_simple(struct device_node *of_node,
>  	/* A linear domain is the default */
>  	return irq_domain_add_linear(of_node, size, ops, host_data);
>  }
> +EXPORT_SYMBOL_GPL(irq_domain_add_simple);
>  
>  /**
>   * irq_domain_add_legacy() - Allocate and register a legacy revmap irq_domain.
> -- 
> 1.8.1.2
> 

^ permalink raw reply	[flat|nested] 131+ messages in thread

* Re: [PATCH 09/21] drm: export drm_vm_open_locked
  2013-04-25 17:28   ` Arnd Bergmann
  (?)
  (?)
@ 2013-04-26  4:55   ` Inki Dae
  -1 siblings, 0 replies; 131+ messages in thread
From: Inki Dae @ 2013-04-26  4:55 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Kyungmin Park, DRI mailing list, Seung-Woo Kim, linux-kernel,
	linux-arm-kernel


[-- Attachment #1.1: Type: text/plain, Size: 1376 bytes --]

2013/4/26 Arnd Bergmann <arnd@arndb.de>

> The EXYNOS DRM driver uses drm_vm_open_locked in its mmap() function,
> and it can be built as a loadable module, which currently fails.
> This exports the symbol from the DRM core to avoid
>
> ERROR: "drm_vm_open_locked" [drivers/gpu/drm/exynos/exynosdrm.ko]
> undefined!
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: David Airlie <airlied@linux.ie>
> Cc: dri-devel@lists.freedesktop.org
> Cc: Inki Dae <inki.dae@samsung.com>
> Cc: Joonyoung Shim <jy0922.shim@samsung.com>
> Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> ---
>  drivers/gpu/drm/drm_vm.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
> index db7bd29..1d4f7c9 100644
> --- a/drivers/gpu/drm/drm_vm.c
> +++ b/drivers/gpu/drm/drm_vm.c
> @@ -422,6 +422,7 @@ void drm_vm_open_locked(struct drm_device *dev,
>                 list_add(&vma_entry->head, &dev->vmalist);
>         }
>  }
> +EXPORT_SYMBOL_GPL(drm_vm_open_locked);
>
>
Checked it out.

Acked-by: Inki Dae <inki.dae@samsung.com>

Thanks,
Inki Dae

 static void drm_vm_open(struct vm_area_struct *vma)
>  {
> --
> 1.8.1.2
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[-- Attachment #1.2: Type: text/html, Size: 2602 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 131+ messages in thread

* Re: [PATCH 06/21] ALSA: ali5451: use mdelay instead of large udelay constants
  2013-04-25 17:28   ` Arnd Bergmann
  (?)
@ 2013-04-26  5:40     ` Takashi Iwai
  -1 siblings, 0 replies; 131+ messages in thread
From: Takashi Iwai @ 2013-04-26  5:40 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: linux-arm-kernel, linux-kernel, alsa-devel

At Thu, 25 Apr 2013 19:28:49 +0200,
Arnd Bergmann wrote:
> 
> ARM cannot handle udelay for more than 2 miliseconds, so we
> should use mdelay instead for those.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Takashi Iwai <tiwai@suse.de>
> Cc: alsa-devel@alsa-project.org

Thanks, applied to sound git tree.


Takashi


> ---
>  sound/pci/ali5451/ali5451.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/sound/pci/ali5451/ali5451.c b/sound/pci/ali5451/ali5451.c
> index e760af9..53754f5 100644
> --- a/sound/pci/ali5451/ali5451.c
> +++ b/sound/pci/ali5451/ali5451.c
> @@ -451,10 +451,10 @@ static int snd_ali_reset_5451(struct snd_ali *codec)
>  	if (pci_dev) {
>  		pci_read_config_dword(pci_dev, 0x7c, &dwVal);
>  		pci_write_config_dword(pci_dev, 0x7c, dwVal | 0x08000000);
> -		udelay(5000);
> +		mdelay(5);
>  		pci_read_config_dword(pci_dev, 0x7c, &dwVal);
>  		pci_write_config_dword(pci_dev, 0x7c, dwVal & 0xf7ffffff);
> -		udelay(5000);
> +		mdelay(5);
>  	}
>  	
>  	pci_dev = codec->pci;
> @@ -463,14 +463,14 @@ static int snd_ali_reset_5451(struct snd_ali *codec)
>  	udelay(500);
>  	pci_read_config_dword(pci_dev, 0x44, &dwVal);
>  	pci_write_config_dword(pci_dev, 0x44, dwVal & 0xfffbffff);
> -	udelay(5000);
> +	mdelay(5);
>  	
>  	wCount = 200;
>  	while(wCount--) {
>  		wReg = snd_ali_codec_peek(codec, 0, AC97_POWERDOWN);
>  		if ((wReg & 0x000f) == 0x000f)
>  			return 0;
> -		udelay(5000);
> +		mdelay(5);
>  	}
>  
>  	/* non-fatal if you have a non PM capable codec */
> -- 
> 1.8.1.2
> 

^ permalink raw reply	[flat|nested] 131+ messages in thread

* Re: [PATCH 06/21] ALSA: ali5451: use mdelay instead of large udelay constants
@ 2013-04-26  5:40     ` Takashi Iwai
  0 siblings, 0 replies; 131+ messages in thread
From: Takashi Iwai @ 2013-04-26  5:40 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: alsa-devel, linux-kernel, linux-arm-kernel

At Thu, 25 Apr 2013 19:28:49 +0200,
Arnd Bergmann wrote:
> 
> ARM cannot handle udelay for more than 2 miliseconds, so we
> should use mdelay instead for those.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Takashi Iwai <tiwai@suse.de>
> Cc: alsa-devel@alsa-project.org

Thanks, applied to sound git tree.


Takashi


> ---
>  sound/pci/ali5451/ali5451.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/sound/pci/ali5451/ali5451.c b/sound/pci/ali5451/ali5451.c
> index e760af9..53754f5 100644
> --- a/sound/pci/ali5451/ali5451.c
> +++ b/sound/pci/ali5451/ali5451.c
> @@ -451,10 +451,10 @@ static int snd_ali_reset_5451(struct snd_ali *codec)
>  	if (pci_dev) {
>  		pci_read_config_dword(pci_dev, 0x7c, &dwVal);
>  		pci_write_config_dword(pci_dev, 0x7c, dwVal | 0x08000000);
> -		udelay(5000);
> +		mdelay(5);
>  		pci_read_config_dword(pci_dev, 0x7c, &dwVal);
>  		pci_write_config_dword(pci_dev, 0x7c, dwVal & 0xf7ffffff);
> -		udelay(5000);
> +		mdelay(5);
>  	}
>  	
>  	pci_dev = codec->pci;
> @@ -463,14 +463,14 @@ static int snd_ali_reset_5451(struct snd_ali *codec)
>  	udelay(500);
>  	pci_read_config_dword(pci_dev, 0x44, &dwVal);
>  	pci_write_config_dword(pci_dev, 0x44, dwVal & 0xfffbffff);
> -	udelay(5000);
> +	mdelay(5);
>  	
>  	wCount = 200;
>  	while(wCount--) {
>  		wReg = snd_ali_codec_peek(codec, 0, AC97_POWERDOWN);
>  		if ((wReg & 0x000f) == 0x000f)
>  			return 0;
> -		udelay(5000);
> +		mdelay(5);
>  	}
>  
>  	/* non-fatal if you have a non PM capable codec */
> -- 
> 1.8.1.2
> 

^ permalink raw reply	[flat|nested] 131+ messages in thread

* [PATCH 06/21] ALSA: ali5451: use mdelay instead of large udelay constants
@ 2013-04-26  5:40     ` Takashi Iwai
  0 siblings, 0 replies; 131+ messages in thread
From: Takashi Iwai @ 2013-04-26  5:40 UTC (permalink / raw)
  To: linux-arm-kernel

At Thu, 25 Apr 2013 19:28:49 +0200,
Arnd Bergmann wrote:
> 
> ARM cannot handle udelay for more than 2 miliseconds, so we
> should use mdelay instead for those.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Takashi Iwai <tiwai@suse.de>
> Cc: alsa-devel at alsa-project.org

Thanks, applied to sound git tree.


Takashi


> ---
>  sound/pci/ali5451/ali5451.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/sound/pci/ali5451/ali5451.c b/sound/pci/ali5451/ali5451.c
> index e760af9..53754f5 100644
> --- a/sound/pci/ali5451/ali5451.c
> +++ b/sound/pci/ali5451/ali5451.c
> @@ -451,10 +451,10 @@ static int snd_ali_reset_5451(struct snd_ali *codec)
>  	if (pci_dev) {
>  		pci_read_config_dword(pci_dev, 0x7c, &dwVal);
>  		pci_write_config_dword(pci_dev, 0x7c, dwVal | 0x08000000);
> -		udelay(5000);
> +		mdelay(5);
>  		pci_read_config_dword(pci_dev, 0x7c, &dwVal);
>  		pci_write_config_dword(pci_dev, 0x7c, dwVal & 0xf7ffffff);
> -		udelay(5000);
> +		mdelay(5);
>  	}
>  	
>  	pci_dev = codec->pci;
> @@ -463,14 +463,14 @@ static int snd_ali_reset_5451(struct snd_ali *codec)
>  	udelay(500);
>  	pci_read_config_dword(pci_dev, 0x44, &dwVal);
>  	pci_write_config_dword(pci_dev, 0x44, dwVal & 0xfffbffff);
> -	udelay(5000);
> +	mdelay(5);
>  	
>  	wCount = 200;
>  	while(wCount--) {
>  		wReg = snd_ali_codec_peek(codec, 0, AC97_POWERDOWN);
>  		if ((wReg & 0x000f) == 0x000f)
>  			return 0;
> -		udelay(5000);
> +		mdelay(5);
>  	}
>  
>  	/* non-fatal if you have a non PM capable codec */
> -- 
> 1.8.1.2
> 

^ permalink raw reply	[flat|nested] 131+ messages in thread

* Re: [PATCH 07/21] oss/dmabuf: use dma_map_single
  2013-04-25 17:28   ` Arnd Bergmann
  (?)
@ 2013-04-26  5:41     ` Takashi Iwai
  -1 siblings, 0 replies; 131+ messages in thread
From: Takashi Iwai @ 2013-04-26  5:41 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: linux-arm-kernel, linux-kernel, Jaroslav Kysela, alsa-devel

At Thu, 25 Apr 2013 19:28:50 +0200,
Arnd Bergmann wrote:
> 
> The virt_to_bus/bus_to_virt functions have been deprecated
> for as long as I can remember, and they are used in very
> few remaining instances, usually in obscure ISA device
> drivers. The OSS sound drivers are the only ones that are
> still used on the ARM architecture, and only on some of
> the earliest StrongARM machines.
> 
> The problem for converting the OSS subsystem to use
> dma_map_single instead is that the caller of virt_to_bus
> does not have a device pointer, since the subsystem has
> never been ported to use the common device infrastructure.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Jaroslav Kysela <perex@perex.cz>
> Cc: Takashi Iwai <tiwai@suse.de>
> Cc: alsa-devel@alsa-project.org

Applied now, but the only problem is that it's difficult to test it :)
Let's see.


Thanks!

Takashi

> ---
>  sound/oss/dmabuf.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/sound/oss/dmabuf.c b/sound/oss/dmabuf.c
> index bcc3e8e..a59c888 100644
> --- a/sound/oss/dmabuf.c
> +++ b/sound/oss/dmabuf.c
> @@ -114,7 +114,7 @@ static int sound_alloc_dmap(struct dma_buffparms *dmap)
>  		}
>  	}
>  	dmap->raw_buf = start_addr;
> -	dmap->raw_buf_phys = virt_to_bus(start_addr);
> +	dmap->raw_buf_phys = dma_map_single(NULL, start_addr, dmap->buffsize, DMA_BIDIRECTIONAL);
>  
>  	for (page = virt_to_page(start_addr); page <= virt_to_page(end_addr); page++)
>  		SetPageReserved(page);
> @@ -139,6 +139,7 @@ static void sound_free_dmap(struct dma_buffparms *dmap)
>  	for (page = virt_to_page(start_addr); page <= virt_to_page(end_addr); page++)
>  		ClearPageReserved(page);
>  
> +	dma_unmap_single(NULL, dmap->raw_buf_phys, dmap->buffsize, DMA_BIDIRECTIONAL);
>  	free_pages((unsigned long) dmap->raw_buf, sz);
>  	dmap->raw_buf = NULL;
>  }
> -- 
> 1.8.1.2
> 

^ permalink raw reply	[flat|nested] 131+ messages in thread

* Re: [PATCH 07/21] oss/dmabuf: use dma_map_single
@ 2013-04-26  5:41     ` Takashi Iwai
  0 siblings, 0 replies; 131+ messages in thread
From: Takashi Iwai @ 2013-04-26  5:41 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: alsa-devel, linux-kernel, linux-arm-kernel, Jaroslav Kysela

At Thu, 25 Apr 2013 19:28:50 +0200,
Arnd Bergmann wrote:
> 
> The virt_to_bus/bus_to_virt functions have been deprecated
> for as long as I can remember, and they are used in very
> few remaining instances, usually in obscure ISA device
> drivers. The OSS sound drivers are the only ones that are
> still used on the ARM architecture, and only on some of
> the earliest StrongARM machines.
> 
> The problem for converting the OSS subsystem to use
> dma_map_single instead is that the caller of virt_to_bus
> does not have a device pointer, since the subsystem has
> never been ported to use the common device infrastructure.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Jaroslav Kysela <perex@perex.cz>
> Cc: Takashi Iwai <tiwai@suse.de>
> Cc: alsa-devel@alsa-project.org

Applied now, but the only problem is that it's difficult to test it :)
Let's see.


Thanks!

Takashi

> ---
>  sound/oss/dmabuf.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/sound/oss/dmabuf.c b/sound/oss/dmabuf.c
> index bcc3e8e..a59c888 100644
> --- a/sound/oss/dmabuf.c
> +++ b/sound/oss/dmabuf.c
> @@ -114,7 +114,7 @@ static int sound_alloc_dmap(struct dma_buffparms *dmap)
>  		}
>  	}
>  	dmap->raw_buf = start_addr;
> -	dmap->raw_buf_phys = virt_to_bus(start_addr);
> +	dmap->raw_buf_phys = dma_map_single(NULL, start_addr, dmap->buffsize, DMA_BIDIRECTIONAL);
>  
>  	for (page = virt_to_page(start_addr); page <= virt_to_page(end_addr); page++)
>  		SetPageReserved(page);
> @@ -139,6 +139,7 @@ static void sound_free_dmap(struct dma_buffparms *dmap)
>  	for (page = virt_to_page(start_addr); page <= virt_to_page(end_addr); page++)
>  		ClearPageReserved(page);
>  
> +	dma_unmap_single(NULL, dmap->raw_buf_phys, dmap->buffsize, DMA_BIDIRECTIONAL);
>  	free_pages((unsigned long) dmap->raw_buf, sz);
>  	dmap->raw_buf = NULL;
>  }
> -- 
> 1.8.1.2
> 

^ permalink raw reply	[flat|nested] 131+ messages in thread

* [PATCH 07/21] oss/dmabuf: use dma_map_single
@ 2013-04-26  5:41     ` Takashi Iwai
  0 siblings, 0 replies; 131+ messages in thread
From: Takashi Iwai @ 2013-04-26  5:41 UTC (permalink / raw)
  To: linux-arm-kernel

At Thu, 25 Apr 2013 19:28:50 +0200,
Arnd Bergmann wrote:
> 
> The virt_to_bus/bus_to_virt functions have been deprecated
> for as long as I can remember, and they are used in very
> few remaining instances, usually in obscure ISA device
> drivers. The OSS sound drivers are the only ones that are
> still used on the ARM architecture, and only on some of
> the earliest StrongARM machines.
> 
> The problem for converting the OSS subsystem to use
> dma_map_single instead is that the caller of virt_to_bus
> does not have a device pointer, since the subsystem has
> never been ported to use the common device infrastructure.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Jaroslav Kysela <perex@perex.cz>
> Cc: Takashi Iwai <tiwai@suse.de>
> Cc: alsa-devel at alsa-project.org

Applied now, but the only problem is that it's difficult to test it :)
Let's see.


Thanks!

Takashi

> ---
>  sound/oss/dmabuf.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/sound/oss/dmabuf.c b/sound/oss/dmabuf.c
> index bcc3e8e..a59c888 100644
> --- a/sound/oss/dmabuf.c
> +++ b/sound/oss/dmabuf.c
> @@ -114,7 +114,7 @@ static int sound_alloc_dmap(struct dma_buffparms *dmap)
>  		}
>  	}
>  	dmap->raw_buf = start_addr;
> -	dmap->raw_buf_phys = virt_to_bus(start_addr);
> +	dmap->raw_buf_phys = dma_map_single(NULL, start_addr, dmap->buffsize, DMA_BIDIRECTIONAL);
>  
>  	for (page = virt_to_page(start_addr); page <= virt_to_page(end_addr); page++)
>  		SetPageReserved(page);
> @@ -139,6 +139,7 @@ static void sound_free_dmap(struct dma_buffparms *dmap)
>  	for (page = virt_to_page(start_addr); page <= virt_to_page(end_addr); page++)
>  		ClearPageReserved(page);
>  
> +	dma_unmap_single(NULL, dmap->raw_buf_phys, dmap->buffsize, DMA_BIDIRECTIONAL);
>  	free_pages((unsigned long) dmap->raw_buf, sz);
>  	dmap->raw_buf = NULL;
>  }
> -- 
> 1.8.1.2
> 

^ permalink raw reply	[flat|nested] 131+ messages in thread

* Re: [PATCH 15/21] thermal: cooling: avoid uninitialied used gcc warning
  2013-04-25 17:28   ` Arnd Bergmann
@ 2013-04-26  8:10     ` Zhang Rui
  -1 siblings, 0 replies; 131+ messages in thread
From: Zhang Rui @ 2013-04-26  8:10 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: linux-arm-kernel, linux-kernel, Amit Daniel kachhap, eduardo

On Thu, 2013-04-25 at 19:28 +0200, Arnd Bergmann wrote:
> The newly rewritten get_property() function causes a bogus warning
> from gcc-3.8, which cannot figure out that "level" is always
> initialized at the point where it gets evaluated:
> 
> drivers/thermal/cpu_cooling.c: In function 'get_property':
> drivers/thermal/cpu_cooling.c:189:37: warning: 'level' may be used uninitialized in this function [-Wmaybe-uninitialized]
>    if (property == GET_FREQ && level == j) {
>                                      ^
> 
> Slightly rearranging the code makes this more obvious and
> avoids the warning.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Zhang Rui <rui.zhang@intel.com>
> Cc: Amit Daniel kachhap <amit.daniel@samsung.com>

we already have a fix for this.
please refer to
https://patchwork.kernel.org/patch/2454891/

thanks for your patch, Arnd!

-rui
> ---
>  drivers/thermal/cpu_cooling.c | 17 +++++++++--------
>  1 file changed, 9 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
> index 768b508..34878e6 100644
> --- a/drivers/thermal/cpu_cooling.c
> +++ b/drivers/thermal/cpu_cooling.c
> @@ -165,10 +165,6 @@ static int get_property(unsigned int cpu, unsigned long input,
>  		return 0;
>  	}
>  
> -	if (property == GET_FREQ)
> -		level = descend ? input : (max_level - input -1);
> -
> -
>  	for (i = 0, j = 0; table[i].frequency != CPUFREQ_TABLE_END; i++) {
>  		/* ignore invalid entry */
>  		if (table[i].frequency == CPUFREQ_ENTRY_INVALID)
> @@ -186,10 +182,15 @@ static int get_property(unsigned int cpu, unsigned long input,
>  			*output = descend ? j : (max_level - j - 1);
>  			return 0;
>  		}
> -		if (property == GET_FREQ && level == j) {
> -			/* get frequency by level */
> -			*output = freq;
> -			return 0;
> +
> +		if (property == GET_FREQ) {
> +			level = descend ? input : (max_level - input -1);
> +
> +			if (level == j) {
> +				/* get frequency by level */
> +				*output = freq;
> +				return 0;
> +			}
>  		}
>  		j++;
>  	}



^ permalink raw reply	[flat|nested] 131+ messages in thread

* [PATCH 15/21] thermal: cooling: avoid uninitialied used gcc warning
@ 2013-04-26  8:10     ` Zhang Rui
  0 siblings, 0 replies; 131+ messages in thread
From: Zhang Rui @ 2013-04-26  8:10 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, 2013-04-25 at 19:28 +0200, Arnd Bergmann wrote:
> The newly rewritten get_property() function causes a bogus warning
> from gcc-3.8, which cannot figure out that "level" is always
> initialized at the point where it gets evaluated:
> 
> drivers/thermal/cpu_cooling.c: In function 'get_property':
> drivers/thermal/cpu_cooling.c:189:37: warning: 'level' may be used uninitialized in this function [-Wmaybe-uninitialized]
>    if (property == GET_FREQ && level == j) {
>                                      ^
> 
> Slightly rearranging the code makes this more obvious and
> avoids the warning.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Zhang Rui <rui.zhang@intel.com>
> Cc: Amit Daniel kachhap <amit.daniel@samsung.com>

we already have a fix for this.
please refer to
https://patchwork.kernel.org/patch/2454891/

thanks for your patch, Arnd!

-rui
> ---
>  drivers/thermal/cpu_cooling.c | 17 +++++++++--------
>  1 file changed, 9 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
> index 768b508..34878e6 100644
> --- a/drivers/thermal/cpu_cooling.c
> +++ b/drivers/thermal/cpu_cooling.c
> @@ -165,10 +165,6 @@ static int get_property(unsigned int cpu, unsigned long input,
>  		return 0;
>  	}
>  
> -	if (property == GET_FREQ)
> -		level = descend ? input : (max_level - input -1);
> -
> -
>  	for (i = 0, j = 0; table[i].frequency != CPUFREQ_TABLE_END; i++) {
>  		/* ignore invalid entry */
>  		if (table[i].frequency == CPUFREQ_ENTRY_INVALID)
> @@ -186,10 +182,15 @@ static int get_property(unsigned int cpu, unsigned long input,
>  			*output = descend ? j : (max_level - j - 1);
>  			return 0;
>  		}
> -		if (property == GET_FREQ && level == j) {
> -			/* get frequency by level */
> -			*output = freq;
> -			return 0;
> +
> +		if (property == GET_FREQ) {
> +			level = descend ? input : (max_level - input -1);
> +
> +			if (level == j) {
> +				/* get frequency by level */
> +				*output = freq;
> +				return 0;
> +			}
>  		}
>  		j++;
>  	}

^ permalink raw reply	[flat|nested] 131+ messages in thread

* RE: [PATCH 05/21] atm: he: use mdelay instead of large udelay constants
  2013-04-25 17:28   ` Arnd Bergmann
@ 2013-04-26  8:21     ` David Laight
  -1 siblings, 0 replies; 131+ messages in thread
From: David Laight @ 2013-04-26  8:21 UTC (permalink / raw)
  To: Arnd Bergmann, linux-arm-kernel
  Cc: linux-kernel, Chas Williams, linux-atm-general, netdev

> ARM cannot handle udelay for more than 2 miliseconds, so we
> should use mdelay instead for those.
...
> @@ -1055,7 +1055,7 @@ static int he_start(struct atm_dev *dev)
>  	he_writel(he_dev, 0x0, RESET_CNTL);
>  	he_writel(he_dev, 0xff, RESET_CNTL);
> 
> -	udelay(16*1000);	/* 16 ms */
> +	mdelay(16);	/* 16 ms */
>  	status = he_readl(he_dev, RESET_CNTL);

16ms seems a long time to spin.
I'd have thought a sleep would be more appropriate.
Since this looks like timing a hardware reset pulse
it can't matter if it is somewhat longer.

	David




^ permalink raw reply	[flat|nested] 131+ messages in thread

* [PATCH 05/21] atm: he: use mdelay instead of large udelay constants
@ 2013-04-26  8:21     ` David Laight
  0 siblings, 0 replies; 131+ messages in thread
From: David Laight @ 2013-04-26  8:21 UTC (permalink / raw)
  To: linux-arm-kernel

> ARM cannot handle udelay for more than 2 miliseconds, so we
> should use mdelay instead for those.
...
> @@ -1055,7 +1055,7 @@ static int he_start(struct atm_dev *dev)
>  	he_writel(he_dev, 0x0, RESET_CNTL);
>  	he_writel(he_dev, 0xff, RESET_CNTL);
> 
> -	udelay(16*1000);	/* 16 ms */
> +	mdelay(16);	/* 16 ms */
>  	status = he_readl(he_dev, RESET_CNTL);

16ms seems a long time to spin.
I'd have thought a sleep would be more appropriate.
Since this looks like timing a hardware reset pulse
it can't matter if it is somewhat longer.

	David

^ permalink raw reply	[flat|nested] 131+ messages in thread

* Re: [PATCH 03/21] ARM: shmobile: don't call irqchip_init unconditionally
  2013-04-26  0:48     ` Simon Horman
@ 2013-04-26  8:52       ` Bastian Hecht
  -1 siblings, 0 replies; 131+ messages in thread
From: Bastian Hecht @ 2013-04-26  8:52 UTC (permalink / raw)
  To: Simon Horman
  Cc: Arnd Bergmann, linux-arm-kernel, linux-kernel, Bastian Hecht,
	Kuninori Morimoto

Hello Simon and Arnd,

2013/4/26 Simon Horman <horms@verge.net.au>:
> On Thu, Apr 25, 2013 at 07:28:46PM +0200, Arnd Bergmann wrote:
>> The irqchip_init function is only available when building
>> with CONFIG_OF enabled, which causes this build failure for
>> bonito_defconfig:
>>
>> arch/arm/mach-shmobile/built-in.o: In function `r8a7740_init_irq_of':
>> :(.init.text+0x580): undefined reference to `irqchip_init'
>>
>> This makes both the OF and the ATAGS portion of the driver
>> conditional, which avoids the build error and also results
>> in smaller object code if not both are enabled, without the
>> need for an #ifdef.
>>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> Cc: Bastian Hecht <hechtb+renesas@gmail.com>
>> Cc: Simon Horman <horms+renesas@verge.net.au>
>> Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>> ---
>>  arch/arm/mach-shmobile/intc-r8a7740.c | 13 +++++++++++--
>>  1 file changed, 11 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-shmobile/intc-r8a7740.c b/arch/arm/mach-shmobile/intc-r8a7740.c
>> index 8871f77..5dc57f1 100644
>> --- a/arch/arm/mach-shmobile/intc-r8a7740.c
>> +++ b/arch/arm/mach-shmobile/intc-r8a7740.c
>> @@ -53,14 +53,23 @@ static void __init r8a7740_init_irq_common(void)
>>
>>  void __init r8a7740_init_irq_of(void)
>>  {
>> +     if (!IS_ENABLED(CONFIG_OF))
>> +             return;
>> +
>
> In other parts of the shmobile I believe that such code is
> guarded by #ifdef CONFIG_OF and I believe not guarding this code in
> some way was an oversight.

Yes, sorry, I haven't thought about the dependency of irqchip_init and
CONFIG_OF.

> The above change seems fine to me.
>
>>       irqchip_init();
>>       r8a7740_init_irq_common();
>>  }
>>
>>  void __init r8a7740_init_irq(void)
>>  {
>> -     void __iomem *gic_dist_base = ioremap_nocache(0xc2800000, 0x1000);
>> -     void __iomem *gic_cpu_base = ioremap_nocache(0xc2000000, 0x1000);
>> +     void __iomem *gic_dist_base;
>> +     void __iomem *gic_cpu_base;
>> +
>> +     if (!IS_ENABLED(CONFIG_ATAGS))
>> +             return;
>> +
>> +     gic_dist_base = ioremap_nocache(0xc2800000, 0x1000);
>> +     gic_cpu_base = ioremap_nocache(0xc2000000, 0x1000);
>>
>>       /* initialize the Generic Interrupt Controller PL390 r0p0 */
>>       gic_init(0, 29, gic_dist_base, gic_cpu_base);
>
> This one seems broken as the armadillo800eva board currently uses
> it to initialise GIC even if CONFIG_ATAGS is not defined.
>
> I did test the above change on the armadillo800eva board
> with the above change and CONFIG_ATAGS disabled, the result was
> a boot failure. With the change reverted booting seems fine.

CONFIG_ATAGS and CONFIG_ARM_APPENDED_DTB are two ways to pass the
device tree information, right?
So we run into trouble when we use the later but disable the first.
Is there a reason why you wanted to avoid using two times just "if
(!IS_ENABLED(CONFIG_OF))", Arnd?

Thanks,

 Bastian

^ permalink raw reply	[flat|nested] 131+ messages in thread

* [PATCH 03/21] ARM: shmobile: don't call irqchip_init unconditionally
@ 2013-04-26  8:52       ` Bastian Hecht
  0 siblings, 0 replies; 131+ messages in thread
From: Bastian Hecht @ 2013-04-26  8:52 UTC (permalink / raw)
  To: linux-arm-kernel

Hello Simon and Arnd,

2013/4/26 Simon Horman <horms@verge.net.au>:
> On Thu, Apr 25, 2013 at 07:28:46PM +0200, Arnd Bergmann wrote:
>> The irqchip_init function is only available when building
>> with CONFIG_OF enabled, which causes this build failure for
>> bonito_defconfig:
>>
>> arch/arm/mach-shmobile/built-in.o: In function `r8a7740_init_irq_of':
>> :(.init.text+0x580): undefined reference to `irqchip_init'
>>
>> This makes both the OF and the ATAGS portion of the driver
>> conditional, which avoids the build error and also results
>> in smaller object code if not both are enabled, without the
>> need for an #ifdef.
>>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> Cc: Bastian Hecht <hechtb+renesas@gmail.com>
>> Cc: Simon Horman <horms+renesas@verge.net.au>
>> Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>> ---
>>  arch/arm/mach-shmobile/intc-r8a7740.c | 13 +++++++++++--
>>  1 file changed, 11 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-shmobile/intc-r8a7740.c b/arch/arm/mach-shmobile/intc-r8a7740.c
>> index 8871f77..5dc57f1 100644
>> --- a/arch/arm/mach-shmobile/intc-r8a7740.c
>> +++ b/arch/arm/mach-shmobile/intc-r8a7740.c
>> @@ -53,14 +53,23 @@ static void __init r8a7740_init_irq_common(void)
>>
>>  void __init r8a7740_init_irq_of(void)
>>  {
>> +     if (!IS_ENABLED(CONFIG_OF))
>> +             return;
>> +
>
> In other parts of the shmobile I believe that such code is
> guarded by #ifdef CONFIG_OF and I believe not guarding this code in
> some way was an oversight.

Yes, sorry, I haven't thought about the dependency of irqchip_init and
CONFIG_OF.

> The above change seems fine to me.
>
>>       irqchip_init();
>>       r8a7740_init_irq_common();
>>  }
>>
>>  void __init r8a7740_init_irq(void)
>>  {
>> -     void __iomem *gic_dist_base = ioremap_nocache(0xc2800000, 0x1000);
>> -     void __iomem *gic_cpu_base = ioremap_nocache(0xc2000000, 0x1000);
>> +     void __iomem *gic_dist_base;
>> +     void __iomem *gic_cpu_base;
>> +
>> +     if (!IS_ENABLED(CONFIG_ATAGS))
>> +             return;
>> +
>> +     gic_dist_base = ioremap_nocache(0xc2800000, 0x1000);
>> +     gic_cpu_base = ioremap_nocache(0xc2000000, 0x1000);
>>
>>       /* initialize the Generic Interrupt Controller PL390 r0p0 */
>>       gic_init(0, 29, gic_dist_base, gic_cpu_base);
>
> This one seems broken as the armadillo800eva board currently uses
> it to initialise GIC even if CONFIG_ATAGS is not defined.
>
> I did test the above change on the armadillo800eva board
> with the above change and CONFIG_ATAGS disabled, the result was
> a boot failure. With the change reverted booting seems fine.

CONFIG_ATAGS and CONFIG_ARM_APPENDED_DTB are two ways to pass the
device tree information, right?
So we run into trouble when we use the later but disable the first.
Is there a reason why you wanted to avoid using two times just "if
(!IS_ENABLED(CONFIG_OF))", Arnd?

Thanks,

 Bastian

^ permalink raw reply	[flat|nested] 131+ messages in thread

* Re: [PATCH 01/21] ARM: topology: export cpu_topology
  2013-04-25 17:28   ` Arnd Bergmann
@ 2013-04-26  8:53     ` Will Deacon
  -1 siblings, 0 replies; 131+ messages in thread
From: Will Deacon @ 2013-04-26  8:53 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: linux-arm-kernel, linux-kernel, Russell King, Nicolas Pitre,
	Vincent Guittot

On Thu, Apr 25, 2013 at 06:28:44PM +0100, Arnd Bergmann wrote:
> The cpu_topology symbol is required by any driver using the topology
> interfaces, which leads to a couple of build errors:
> 
> ERROR: "cpu_topology" [drivers/net/ethernet/sfc/sfc.ko] undefined!
> ERROR: "cpu_topology" [drivers/cpufreq/arm_big_little.ko] undefined!

Are these first two in mainline?

> ERROR: "cpu_topology" [drivers/block/mtip32xx/mtip32xx.ko] undefined!
> 
> The obvious solution is to export this symbol.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Russell King <rmk+kernel@arm.linux.org.uk>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Nicolas Pitre <nico@linaro.org>
> Cc: Vincent Guittot <vincent.guittot@linaro.org>
> ---
>  arch/arm/kernel/topology.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
> index f10316b..7ac5714 100644
> --- a/arch/arm/kernel/topology.c
> +++ b/arch/arm/kernel/topology.c
> @@ -200,6 +200,7 @@ static inline void update_cpu_power(unsigned int cpuid, unsigned int mpidr) {}
>   * cpu topology table
>   */
>  struct cputopo_arm cpu_topology[NR_CPUS];
> +EXPORT_SYMBOL_GPL(cpu_topology);


Make sense:

  Acked-by: Will Deacon <will.deacon@arm.com>

Probably best to put it in the patch system.

Will

^ permalink raw reply	[flat|nested] 131+ messages in thread

* [PATCH 01/21] ARM: topology: export cpu_topology
@ 2013-04-26  8:53     ` Will Deacon
  0 siblings, 0 replies; 131+ messages in thread
From: Will Deacon @ 2013-04-26  8:53 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, Apr 25, 2013 at 06:28:44PM +0100, Arnd Bergmann wrote:
> The cpu_topology symbol is required by any driver using the topology
> interfaces, which leads to a couple of build errors:
> 
> ERROR: "cpu_topology" [drivers/net/ethernet/sfc/sfc.ko] undefined!
> ERROR: "cpu_topology" [drivers/cpufreq/arm_big_little.ko] undefined!

Are these first two in mainline?

> ERROR: "cpu_topology" [drivers/block/mtip32xx/mtip32xx.ko] undefined!
> 
> The obvious solution is to export this symbol.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Russell King <rmk+kernel@arm.linux.org.uk>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Nicolas Pitre <nico@linaro.org>
> Cc: Vincent Guittot <vincent.guittot@linaro.org>
> ---
>  arch/arm/kernel/topology.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
> index f10316b..7ac5714 100644
> --- a/arch/arm/kernel/topology.c
> +++ b/arch/arm/kernel/topology.c
> @@ -200,6 +200,7 @@ static inline void update_cpu_power(unsigned int cpuid, unsigned int mpidr) {}
>   * cpu topology table
>   */
>  struct cputopo_arm cpu_topology[NR_CPUS];
> +EXPORT_SYMBOL_GPL(cpu_topology);


Make sense:

  Acked-by: Will Deacon <will.deacon@arm.com>

Probably best to put it in the patch system.

Will

^ permalink raw reply	[flat|nested] 131+ messages in thread

* Re: [PATCH 12/21] irqchip: s3c24xx: add missing __init annotations
  2013-04-25 17:28   ` Arnd Bergmann
@ 2013-04-26 10:39     ` Heiko Stübner
  -1 siblings, 0 replies; 131+ messages in thread
From: Heiko Stübner @ 2013-04-26 10:39 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: linux-arm-kernel, linux-kernel, Kukjin Kim

Am Donnerstag, 25. April 2013, 19:28:55 schrieb Arnd Bergmann:
> The s3c24xx_init_intc and s3c2412_init_irq functions are only called
> at init time, and they call functions already marked __init, so they
> should be marked in the same way. This was reported as
> 
> WARNING: vmlinux.o(.text+0x19e0b4): Section mismatch in reference from the
> function s3c2412_init_irq() to the function
> .init.text:s3c24xx_init_intc.constprop.8() The function s3c2412_init_irq()
> references
> the function __init s3c24xx_init_intc.constprop.8().
> This is often because s3c2412_init_irq lacks a __init
> annotation or the annotation of s3c24xx_init_intc.constprop.8 is wrong.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Heiko Stuebner <heiko@sntech.de>
> Cc: Kukjin Kim <kgene.kim@samsung.com>

Yeah, it seems "someone" forgot these, thanks for catching this.

Acked-by: Heiko Stuebner <heiko@sntech.de>


> ---
>  drivers/irqchip/irq-s3c24xx.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/irqchip/irq-s3c24xx.c b/drivers/irqchip/irq-s3c24xx.c
> index c8afd7b..bbcc944 100644
> --- a/drivers/irqchip/irq-s3c24xx.c
> +++ b/drivers/irqchip/irq-s3c24xx.c
> @@ -535,7 +535,7 @@ static void s3c24xx_clear_intc(struct s3c_irq_intc
> *intc) }
>  }
> 
> -static struct s3c_irq_intc *s3c24xx_init_intc(struct device_node *np,
> +static struct s3c_irq_intc * __init s3c24xx_init_intc(struct device_node
> *np, struct s3c_irq_data *irq_data,
>  				       struct s3c_irq_intc *parent,
>  				       unsigned long address)
> @@ -795,7 +795,7 @@ static struct s3c_irq_data init_s3c2412subint[32] = {
>  	{ .type = S3C_IRQTYPE_LEVEL, .parent_irq = 21 }, /* CF */
>  };
> 
> -void s3c2412_init_irq(void)
> +void __init s3c2412_init_irq(void)
>  {
>  	pr_info("S3C2412: IRQ Support\n");


^ permalink raw reply	[flat|nested] 131+ messages in thread

* [PATCH 12/21] irqchip: s3c24xx: add missing __init annotations
@ 2013-04-26 10:39     ` Heiko Stübner
  0 siblings, 0 replies; 131+ messages in thread
From: Heiko Stübner @ 2013-04-26 10:39 UTC (permalink / raw)
  To: linux-arm-kernel

Am Donnerstag, 25. April 2013, 19:28:55 schrieb Arnd Bergmann:
> The s3c24xx_init_intc and s3c2412_init_irq functions are only called
> at init time, and they call functions already marked __init, so they
> should be marked in the same way. This was reported as
> 
> WARNING: vmlinux.o(.text+0x19e0b4): Section mismatch in reference from the
> function s3c2412_init_irq() to the function
> .init.text:s3c24xx_init_intc.constprop.8() The function s3c2412_init_irq()
> references
> the function __init s3c24xx_init_intc.constprop.8().
> This is often because s3c2412_init_irq lacks a __init
> annotation or the annotation of s3c24xx_init_intc.constprop.8 is wrong.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Heiko Stuebner <heiko@sntech.de>
> Cc: Kukjin Kim <kgene.kim@samsung.com>

Yeah, it seems "someone" forgot these, thanks for catching this.

Acked-by: Heiko Stuebner <heiko@sntech.de>


> ---
>  drivers/irqchip/irq-s3c24xx.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/irqchip/irq-s3c24xx.c b/drivers/irqchip/irq-s3c24xx.c
> index c8afd7b..bbcc944 100644
> --- a/drivers/irqchip/irq-s3c24xx.c
> +++ b/drivers/irqchip/irq-s3c24xx.c
> @@ -535,7 +535,7 @@ static void s3c24xx_clear_intc(struct s3c_irq_intc
> *intc) }
>  }
> 
> -static struct s3c_irq_intc *s3c24xx_init_intc(struct device_node *np,
> +static struct s3c_irq_intc * __init s3c24xx_init_intc(struct device_node
> *np, struct s3c_irq_data *irq_data,
>  				       struct s3c_irq_intc *parent,
>  				       unsigned long address)
> @@ -795,7 +795,7 @@ static struct s3c_irq_data init_s3c2412subint[32] = {
>  	{ .type = S3C_IRQTYPE_LEVEL, .parent_irq = 21 }, /* CF */
>  };
> 
> -void s3c2412_init_irq(void)
> +void __init s3c2412_init_irq(void)
>  {
>  	pr_info("S3C2412: IRQ Support\n");

^ permalink raw reply	[flat|nested] 131+ messages in thread

* Re: [PATCH 05/21] atm: he: use mdelay instead of large udelay constants
  2013-04-26  8:21     ` David Laight
  (?)
@ 2013-04-26 13:12       ` chas williams - CONTRACTOR
  -1 siblings, 0 replies; 131+ messages in thread
From: chas williams - CONTRACTOR @ 2013-04-26 13:12 UTC (permalink / raw)
  To: David Laight
  Cc: Arnd Bergmann, linux-arm-kernel, linux-kernel, linux-atm-general, netdev

On Fri, 26 Apr 2013 09:21:59 +0100
"David Laight" <David.Laight@ACULAB.COM> wrote:

> > ARM cannot handle udelay for more than 2 miliseconds, so we
> > should use mdelay instead for those.
> ...
> > @@ -1055,7 +1055,7 @@ static int he_start(struct atm_dev *dev)
> >  	he_writel(he_dev, 0x0, RESET_CNTL);
> >  	he_writel(he_dev, 0xff, RESET_CNTL);
> > 
> > -	udelay(16*1000);	/* 16 ms */
> > +	mdelay(16);	/* 16 ms */
> >  	status = he_readl(he_dev, RESET_CNTL);
> 
> 16ms seems a long time to spin.
> I'd have thought a sleep would be more appropriate.
> Since this looks like timing a hardware reset pulse
> it can't matter if it is somewhat longer.

Yes, I wrote this bit some time ago when I was less wise. The
programmer's guide doesn't say how long to sleep, so the value isn't
critical.  It just has to be "long enough".  An msleep() would be fine
here.

^ permalink raw reply	[flat|nested] 131+ messages in thread

* Re: [PATCH 05/21] atm: he: use mdelay instead of large udelay constants
@ 2013-04-26 13:12       ` chas williams - CONTRACTOR
  0 siblings, 0 replies; 131+ messages in thread
From: chas williams - CONTRACTOR @ 2013-04-26 13:12 UTC (permalink / raw)
  To: David Laight
  Cc: netdev, linux-atm-general, linux-arm-kernel, Arnd Bergmann, linux-kernel

On Fri, 26 Apr 2013 09:21:59 +0100
"David Laight" <David.Laight@ACULAB.COM> wrote:

> > ARM cannot handle udelay for more than 2 miliseconds, so we
> > should use mdelay instead for those.
> ...
> > @@ -1055,7 +1055,7 @@ static int he_start(struct atm_dev *dev)
> >  	he_writel(he_dev, 0x0, RESET_CNTL);
> >  	he_writel(he_dev, 0xff, RESET_CNTL);
> > 
> > -	udelay(16*1000);	/* 16 ms */
> > +	mdelay(16);	/* 16 ms */
> >  	status = he_readl(he_dev, RESET_CNTL);
> 
> 16ms seems a long time to spin.
> I'd have thought a sleep would be more appropriate.
> Since this looks like timing a hardware reset pulse
> it can't matter if it is somewhat longer.

Yes, I wrote this bit some time ago when I was less wise. The
programmer's guide doesn't say how long to sleep, so the value isn't
critical.  It just has to be "long enough".  An msleep() would be fine
here.

^ permalink raw reply	[flat|nested] 131+ messages in thread

* [PATCH 05/21] atm: he: use mdelay instead of large udelay constants
@ 2013-04-26 13:12       ` chas williams - CONTRACTOR
  0 siblings, 0 replies; 131+ messages in thread
From: chas williams - CONTRACTOR @ 2013-04-26 13:12 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, 26 Apr 2013 09:21:59 +0100
"David Laight" <David.Laight@ACULAB.COM> wrote:

> > ARM cannot handle udelay for more than 2 miliseconds, so we
> > should use mdelay instead for those.
> ...
> > @@ -1055,7 +1055,7 @@ static int he_start(struct atm_dev *dev)
> >  	he_writel(he_dev, 0x0, RESET_CNTL);
> >  	he_writel(he_dev, 0xff, RESET_CNTL);
> > 
> > -	udelay(16*1000);	/* 16 ms */
> > +	mdelay(16);	/* 16 ms */
> >  	status = he_readl(he_dev, RESET_CNTL);
> 
> 16ms seems a long time to spin.
> I'd have thought a sleep would be more appropriate.
> Since this looks like timing a hardware reset pulse
> it can't matter if it is somewhat longer.

Yes, I wrote this bit some time ago when I was less wise. The
programmer's guide doesn't say how long to sleep, so the value isn't
critical.  It just has to be "long enough".  An msleep() would be fine
here.

^ permalink raw reply	[flat|nested] 131+ messages in thread

* Re: [PATCH 01/21] ARM: topology: export cpu_topology
  2013-04-26  8:53     ` Will Deacon
@ 2013-04-26 15:07       ` Arnd Bergmann
  -1 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-26 15:07 UTC (permalink / raw)
  To: Will Deacon
  Cc: linux-arm-kernel, linux-kernel, Russell King, Nicolas Pitre,
	Vincent Guittot

On Friday 26 April 2013, Will Deacon wrote:
> On Thu, Apr 25, 2013 at 06:28:44PM +0100, Arnd Bergmann wrote:
> > The cpu_topology symbol is required by any driver using the topology
> > interfaces, which leads to a couple of build errors:
> > 
> > ERROR: "cpu_topology" [drivers/net/ethernet/sfc/sfc.ko] undefined!
> > ERROR: "cpu_topology" [drivers/cpufreq/arm_big_little.ko] undefined!
> 
> Are these first two in mainline?

I think they are both newly added in linux-next.

	Arnd

^ permalink raw reply	[flat|nested] 131+ messages in thread

* [PATCH 01/21] ARM: topology: export cpu_topology
@ 2013-04-26 15:07       ` Arnd Bergmann
  0 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-26 15:07 UTC (permalink / raw)
  To: linux-arm-kernel

On Friday 26 April 2013, Will Deacon wrote:
> On Thu, Apr 25, 2013 at 06:28:44PM +0100, Arnd Bergmann wrote:
> > The cpu_topology symbol is required by any driver using the topology
> > interfaces, which leads to a couple of build errors:
> > 
> > ERROR: "cpu_topology" [drivers/net/ethernet/sfc/sfc.ko] undefined!
> > ERROR: "cpu_topology" [drivers/cpufreq/arm_big_little.ko] undefined!
> 
> Are these first two in mainline?

I think they are both newly added in linux-next.

	Arnd

^ permalink raw reply	[flat|nested] 131+ messages in thread

* Re: [PATCH 03/21] ARM: shmobile: don't call irqchip_init unconditionallyA
  2013-04-26  8:52       ` Bastian Hecht
@ 2013-04-29 12:58         ` Arnd Bergmann
  -1 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-29 12:58 UTC (permalink / raw)
  To: Bastian Hecht
  Cc: Simon Horman, linux-arm-kernel, linux-kernel, Bastian Hecht,
	Kuninori Morimoto

On Friday 26 April 2013, Bastian Hecht wrote:
> > This one seems broken as the armadillo800eva board currently uses
> > it to initialise GIC even if CONFIG_ATAGS is not defined.
> >
> > I did test the above change on the armadillo800eva board
> > with the above change and CONFIG_ATAGS disabled, the result was
> > a boot failure. With the change reverted booting seems fine.
> 
> CONFIG_ATAGS and CONFIG_ARM_APPENDED_DTB are two ways to pass the
> device tree information, right?

No, the two are methods alternative methods for booting from a legacy
boot loader. CONFIG_ATAGS is the old boot method without a DT, using
a board file and a MACHINE_START() macro. ARM_APPENDED_DTB means you
have a DT linked into the kernel but pass ATAGS to the kernel which
uses the passed data to modify the DT.

> So we run into trouble when we use the later but disable the first.
> Is there a reason why you wanted to avoid using two times just "if
> (!IS_ENABLED(CONFIG_OF))", Arnd?

I incorrectly assumed that the second one was only used without DT,
since it uses hardcoded MMIO locations rather than using of_iomap().

	Arnd

^ permalink raw reply	[flat|nested] 131+ messages in thread

* [PATCH 03/21] ARM: shmobile: don't call irqchip_init unconditionallyA
@ 2013-04-29 12:58         ` Arnd Bergmann
  0 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-29 12:58 UTC (permalink / raw)
  To: linux-arm-kernel

On Friday 26 April 2013, Bastian Hecht wrote:
> > This one seems broken as the armadillo800eva board currently uses
> > it to initialise GIC even if CONFIG_ATAGS is not defined.
> >
> > I did test the above change on the armadillo800eva board
> > with the above change and CONFIG_ATAGS disabled, the result was
> > a boot failure. With the change reverted booting seems fine.
> 
> CONFIG_ATAGS and CONFIG_ARM_APPENDED_DTB are two ways to pass the
> device tree information, right?

No, the two are methods alternative methods for booting from a legacy
boot loader. CONFIG_ATAGS is the old boot method without a DT, using
a board file and a MACHINE_START() macro. ARM_APPENDED_DTB means you
have a DT linked into the kernel but pass ATAGS to the kernel which
uses the passed data to modify the DT.

> So we run into trouble when we use the later but disable the first.
> Is there a reason why you wanted to avoid using two times just "if
> (!IS_ENABLED(CONFIG_OF))", Arnd?

I incorrectly assumed that the second one was only used without DT,
since it uses hardcoded MMIO locations rather than using of_iomap().

	Arnd

^ permalink raw reply	[flat|nested] 131+ messages in thread

* [PATCH v2 05/21] atm: he: use msleep instead of large udelay constants
  2013-04-26 13:12       ` chas williams - CONTRACTOR
@ 2013-04-29 13:13         ` Arnd Bergmann
  -1 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-29 13:13 UTC (permalink / raw)
  To: chas williams - CONTRACTOR
  Cc: David Laight, linux-arm-kernel, linux-kernel, linux-atm-general, netdev

>From a0ddf082821b064cc2d6a9bb90861f9b81a559a5 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@arndb.de>
Date: Thu, 14 Mar 2013 15:21:36 +0100
Subject: [PATCH] atm: he: use mdelay instead of large udelay constants

ARM cannot handle udelay for more than 2 miliseconds, and
it is rather bad style to block the cpu for 16ms anyway,
so let's use msleep instead.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Chas Williams <chas@cmf.nrl.navy.mil>
Cc: linux-atm-general@lists.sourceforge.net
Cc: netdev@vger.kernel.org
---
diff --git a/drivers/atm/he.c b/drivers/atm/he.c
index d689126..507362a 100644
--- a/drivers/atm/he.c
+++ b/drivers/atm/he.c
@@ -1055,7 +1055,7 @@ static int he_start(struct atm_dev *dev)
 	he_writel(he_dev, 0x0, RESET_CNTL);
 	he_writel(he_dev, 0xff, RESET_CNTL);
 
-	udelay(16*1000);	/* 16 ms */
+	msleep(16);	/* 16 ms */
 	status = he_readl(he_dev, RESET_CNTL);
 	if ((status & BOARD_RST_STATUS) == 0) {
 		hprintk("reset failed\n");

^ permalink raw reply related	[flat|nested] 131+ messages in thread

* [PATCH v2 05/21] atm: he: use msleep instead of large udelay constants
@ 2013-04-29 13:13         ` Arnd Bergmann
  0 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-29 13:13 UTC (permalink / raw)
  To: linux-arm-kernel

>From a0ddf082821b064cc2d6a9bb90861f9b81a559a5 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@arndb.de>
Date: Thu, 14 Mar 2013 15:21:36 +0100
Subject: [PATCH] atm: he: use mdelay instead of large udelay constants

ARM cannot handle udelay for more than 2 miliseconds, and
it is rather bad style to block the cpu for 16ms anyway,
so let's use msleep instead.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Chas Williams <chas@cmf.nrl.navy.mil>
Cc: linux-atm-general at lists.sourceforge.net
Cc: netdev at vger.kernel.org
---
diff --git a/drivers/atm/he.c b/drivers/atm/he.c
index d689126..507362a 100644
--- a/drivers/atm/he.c
+++ b/drivers/atm/he.c
@@ -1055,7 +1055,7 @@ static int he_start(struct atm_dev *dev)
 	he_writel(he_dev, 0x0, RESET_CNTL);
 	he_writel(he_dev, 0xff, RESET_CNTL);
 
-	udelay(16*1000);	/* 16 ms */
+	msleep(16);	/* 16 ms */
 	status = he_readl(he_dev, RESET_CNTL);
 	if ((status & BOARD_RST_STATUS) == 0) {
 		hprintk("reset failed\n");

^ permalink raw reply related	[flat|nested] 131+ messages in thread

* Re: [PATCH 10/21] [SCSI] nsp32: use mdelay instead of large udelay constants
  2013-04-26  0:42     ` Masanori Goto
  (?)
@ 2013-04-29 13:21       ` Arnd Bergmann
  -1 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-29 13:21 UTC (permalink / raw)
  To: Masanori Goto
  Cc: linux-arm-kernel, linux-kernel, YOKOTA Hiroshi,
	James E.J. Bottomley, linux-scsi

On Friday 26 April 2013, Masanori Goto wrote:
> 2013/4/25 Arnd Bergmann <arnd@arndb.de>
> >
> > ARM cannot handle udelay for more than 2 miliseconds, so we
> > should use mdelay instead for those.
> >
> 
> Singed-off-by: GOTO Masanori <gotom@debian.or.jp>

Thanks. I assume you mean "Acked-by", not "Singed-off" as in "burnt"
or "Signed-off" as a notification that you have applied it to your
own git tree.

I'll keep the patch with an your "Acked-by" line in my tree unless
James wants to apply to the scsi tree.

	Arnd

^ permalink raw reply	[flat|nested] 131+ messages in thread

* Re: [PATCH 10/21] [SCSI] nsp32: use mdelay instead of large udelay constants
@ 2013-04-29 13:21       ` Arnd Bergmann
  0 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-29 13:21 UTC (permalink / raw)
  To: Masanori Goto
  Cc: YOKOTA Hiroshi, James E.J. Bottomley, linux-kernel,
	linux-arm-kernel, linux-scsi

On Friday 26 April 2013, Masanori Goto wrote:
> 2013/4/25 Arnd Bergmann <arnd@arndb.de>
> >
> > ARM cannot handle udelay for more than 2 miliseconds, so we
> > should use mdelay instead for those.
> >
> 
> Singed-off-by: GOTO Masanori <gotom@debian.or.jp>

Thanks. I assume you mean "Acked-by", not "Singed-off" as in "burnt"
or "Signed-off" as a notification that you have applied it to your
own git tree.

I'll keep the patch with an your "Acked-by" line in my tree unless
James wants to apply to the scsi tree.

	Arnd

^ permalink raw reply	[flat|nested] 131+ messages in thread

* [PATCH 10/21] [SCSI] nsp32: use mdelay instead of large udelay constants
@ 2013-04-29 13:21       ` Arnd Bergmann
  0 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-29 13:21 UTC (permalink / raw)
  To: linux-arm-kernel

On Friday 26 April 2013, Masanori Goto wrote:
> 2013/4/25 Arnd Bergmann <arnd@arndb.de>
> >
> > ARM cannot handle udelay for more than 2 miliseconds, so we
> > should use mdelay instead for those.
> >
> 
> Singed-off-by: GOTO Masanori <gotom@debian.or.jp>

Thanks. I assume you mean "Acked-by", not "Singed-off" as in "burnt"
or "Signed-off" as a notification that you have applied it to your
own git tree.

I'll keep the patch with an your "Acked-by" line in my tree unless
James wants to apply to the scsi tree.

	Arnd

^ permalink raw reply	[flat|nested] 131+ messages in thread

* Re: [PATCH 03/21] ARM: shmobile: don't call irqchip_init unconditionally
  2013-04-26  0:48     ` Simon Horman
@ 2013-04-29 14:49       ` Arnd Bergmann
  -1 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-29 14:49 UTC (permalink / raw)
  To: Simon Horman
  Cc: linux-arm-kernel, linux-kernel, Bastian Hecht, Kuninori Morimoto

On Friday 26 April 2013, Simon Horman wrote:
> > diff --git a/arch/arm/mach-shmobile/intc-r8a7740.c b/arch/arm/mach-shmobile/intc-r8a7740.c
> > index 8871f77..5dc57f1 100644
> > --- a/arch/arm/mach-shmobile/intc-r8a7740.c
> > +++ b/arch/arm/mach-shmobile/intc-r8a7740.c
> > @@ -53,14 +53,23 @@ static void __init r8a7740_init_irq_common(void)
> >  
> >  void __init r8a7740_init_irq_of(void)
> >  {
> > +     if (!IS_ENABLED(CONFIG_OF))
> > +             return;
> > +
> 
> In other parts of the shmobile I believe that such code is
> guarded by #ifdef CONFIG_OF and I believe not guarding this code in
> some way was an oversight.
> 
> The above change seems fine to me.

Ok. The change that broke the code is only present in linux-next from
one of your trees, but is not in arm-soc. Could you include the change
in your tree, either by folding into one of your patches or adapting
my patch appropriately?

> > +
> > +     gic_dist_base = ioremap_nocache(0xc2800000, 0x1000);
> > +     gic_cpu_base = ioremap_nocache(0xc2000000, 0x1000);
> >  
> >       /* initialize the Generic Interrupt Controller PL390 r0p0 */
> >       gic_init(0, 29, gic_dist_base, gic_cpu_base);
> 
> This one seems broken as the armadillo800eva board currently uses
> it to initialise GIC even if CONFIG_ATAGS is not defined.
> 
> I did test the above change on the armadillo800eva board
> with the above change and CONFIG_ATAGS disabled, the result was
> a boot failure. With the change reverted booting seems fine.

Yes, I see my mistake now. The second change was clearly wrong
as this function is also used for DT boards, not for ATAGS boards.

	Arnd

^ permalink raw reply	[flat|nested] 131+ messages in thread

* [PATCH 03/21] ARM: shmobile: don't call irqchip_init unconditionally
@ 2013-04-29 14:49       ` Arnd Bergmann
  0 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-04-29 14:49 UTC (permalink / raw)
  To: linux-arm-kernel

On Friday 26 April 2013, Simon Horman wrote:
> > diff --git a/arch/arm/mach-shmobile/intc-r8a7740.c b/arch/arm/mach-shmobile/intc-r8a7740.c
> > index 8871f77..5dc57f1 100644
> > --- a/arch/arm/mach-shmobile/intc-r8a7740.c
> > +++ b/arch/arm/mach-shmobile/intc-r8a7740.c
> > @@ -53,14 +53,23 @@ static void __init r8a7740_init_irq_common(void)
> >  
> >  void __init r8a7740_init_irq_of(void)
> >  {
> > +     if (!IS_ENABLED(CONFIG_OF))
> > +             return;
> > +
> 
> In other parts of the shmobile I believe that such code is
> guarded by #ifdef CONFIG_OF and I believe not guarding this code in
> some way was an oversight.
> 
> The above change seems fine to me.

Ok. The change that broke the code is only present in linux-next from
one of your trees, but is not in arm-soc. Could you include the change
in your tree, either by folding into one of your patches or adapting
my patch appropriately?

> > +
> > +     gic_dist_base = ioremap_nocache(0xc2800000, 0x1000);
> > +     gic_cpu_base = ioremap_nocache(0xc2000000, 0x1000);
> >  
> >       /* initialize the Generic Interrupt Controller PL390 r0p0 */
> >       gic_init(0, 29, gic_dist_base, gic_cpu_base);
> 
> This one seems broken as the armadillo800eva board currently uses
> it to initialise GIC even if CONFIG_ATAGS is not defined.
> 
> I did test the above change on the armadillo800eva board
> with the above change and CONFIG_ATAGS disabled, the result was
> a boot failure. With the change reverted booting seems fine.

Yes, I see my mistake now. The second change was clearly wrong
as this function is also used for DT boards, not for ATAGS boards.

	Arnd

^ permalink raw reply	[flat|nested] 131+ messages in thread

* Re: [PATCH v2 05/21] atm: he: use msleep instead of large udelay constants
  2013-04-29 13:13         ` Arnd Bergmann
@ 2013-04-29 17:27           ` David Miller
  -1 siblings, 0 replies; 131+ messages in thread
From: David Miller @ 2013-04-29 17:27 UTC (permalink / raw)
  To: arnd
  Cc: chas, David.Laight, linux-arm-kernel, linux-kernel,
	linux-atm-general, netdev

From: Arnd Bergmann <arnd@arndb.de>
Date: Mon, 29 Apr 2013 15:13:26 +0200

> From a0ddf082821b064cc2d6a9bb90861f9b81a559a5 Mon Sep 17 00:00:00 2001
> From: Arnd Bergmann <arnd@arndb.de>
> Date: Thu, 14 Mar 2013 15:21:36 +0100
> Subject: [PATCH] atm: he: use mdelay instead of large udelay constants
> 
> ARM cannot handle udelay for more than 2 miliseconds, and
> it is rather bad style to block the cpu for 16ms anyway,
> so let's use msleep instead.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Applied, thanks.

^ permalink raw reply	[flat|nested] 131+ messages in thread

* [PATCH v2 05/21] atm: he: use msleep instead of large udelay constants
@ 2013-04-29 17:27           ` David Miller
  0 siblings, 0 replies; 131+ messages in thread
From: David Miller @ 2013-04-29 17:27 UTC (permalink / raw)
  To: linux-arm-kernel

From: Arnd Bergmann <arnd@arndb.de>
Date: Mon, 29 Apr 2013 15:13:26 +0200

> From a0ddf082821b064cc2d6a9bb90861f9b81a559a5 Mon Sep 17 00:00:00 2001
> From: Arnd Bergmann <arnd@arndb.de>
> Date: Thu, 14 Mar 2013 15:21:36 +0100
> Subject: [PATCH] atm: he: use mdelay instead of large udelay constants
> 
> ARM cannot handle udelay for more than 2 miliseconds, and
> it is rather bad style to block the cpu for 16ms anyway,
> so let's use msleep instead.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Applied, thanks.

^ permalink raw reply	[flat|nested] 131+ messages in thread

* Re: [PATCH 10/21] [SCSI] nsp32: use mdelay instead of large udelay constants
  2013-04-29 13:21       ` Arnd Bergmann
  (?)
@ 2013-04-29 21:41         ` Masanori Goto
  -1 siblings, 0 replies; 131+ messages in thread
From: Masanori Goto @ 2013-04-29 21:41 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: linux-arm-kernel, linux-kernel, YOKOTA Hiroshi,
	James E.J. Bottomley, linux-scsi

Oops, you're absolutely correct.  Thanks for the follow up!  Please
change it as follow as you mentioned:

Acked-by: GOTO Masanori <gotom@debian.or.jp>

Best regrads,
-- gotom

2013/4/29 Arnd Bergmann <arnd@arndb.de>:
> On Friday 26 April 2013, Masanori Goto wrote:
>> 2013/4/25 Arnd Bergmann <arnd@arndb.de>
>> >
>> > ARM cannot handle udelay for more than 2 miliseconds, so we
>> > should use mdelay instead for those.
>> >
>>
>> Singed-off-by: GOTO Masanori <gotom@debian.or.jp>
>
> Thanks. I assume you mean "Acked-by", not "Singed-off" as in "burnt"
> or "Signed-off" as a notification that you have applied it to your
> own git tree.
>
> I'll keep the patch with an your "Acked-by" line in my tree unless
> James wants to apply to the scsi tree.
>
>         Arnd
>

^ permalink raw reply	[flat|nested] 131+ messages in thread

* Re: [PATCH 10/21] [SCSI] nsp32: use mdelay instead of large udelay constants
@ 2013-04-29 21:41         ` Masanori Goto
  0 siblings, 0 replies; 131+ messages in thread
From: Masanori Goto @ 2013-04-29 21:41 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: YOKOTA Hiroshi, James E.J. Bottomley, linux-kernel,
	linux-arm-kernel, linux-scsi

Oops, you're absolutely correct.  Thanks for the follow up!  Please
change it as follow as you mentioned:

Acked-by: GOTO Masanori <gotom@debian.or.jp>

Best regrads,
-- gotom

2013/4/29 Arnd Bergmann <arnd@arndb.de>:
> On Friday 26 April 2013, Masanori Goto wrote:
>> 2013/4/25 Arnd Bergmann <arnd@arndb.de>
>> >
>> > ARM cannot handle udelay for more than 2 miliseconds, so we
>> > should use mdelay instead for those.
>> >
>>
>> Singed-off-by: GOTO Masanori <gotom@debian.or.jp>
>
> Thanks. I assume you mean "Acked-by", not "Singed-off" as in "burnt"
> or "Signed-off" as a notification that you have applied it to your
> own git tree.
>
> I'll keep the patch with an your "Acked-by" line in my tree unless
> James wants to apply to the scsi tree.
>
>         Arnd
>

^ permalink raw reply	[flat|nested] 131+ messages in thread

* [PATCH 10/21] [SCSI] nsp32: use mdelay instead of large udelay constants
@ 2013-04-29 21:41         ` Masanori Goto
  0 siblings, 0 replies; 131+ messages in thread
From: Masanori Goto @ 2013-04-29 21:41 UTC (permalink / raw)
  To: linux-arm-kernel

Oops, you're absolutely correct.  Thanks for the follow up!  Please
change it as follow as you mentioned:

Acked-by: GOTO Masanori <gotom@debian.or.jp>

Best regrads,
-- gotom

2013/4/29 Arnd Bergmann <arnd@arndb.de>:
> On Friday 26 April 2013, Masanori Goto wrote:
>> 2013/4/25 Arnd Bergmann <arnd@arndb.de>
>> >
>> > ARM cannot handle udelay for more than 2 miliseconds, so we
>> > should use mdelay instead for those.
>> >
>>
>> Singed-off-by: GOTO Masanori <gotom@debian.or.jp>
>
> Thanks. I assume you mean "Acked-by", not "Singed-off" as in "burnt"
> or "Signed-off" as a notification that you have applied it to your
> own git tree.
>
> I'll keep the patch with an your "Acked-by" line in my tree unless
> James wants to apply to the scsi tree.
>
>         Arnd
>

^ permalink raw reply	[flat|nested] 131+ messages in thread

* Re: [PATCH 03/21] ARM: shmobile: don't call irqchip_init unconditionally
  2013-04-29 14:49       ` Arnd Bergmann
@ 2013-04-30  1:58         ` Simon Horman
  -1 siblings, 0 replies; 131+ messages in thread
From: Simon Horman @ 2013-04-30  1:58 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: linux-arm-kernel, linux-kernel, Bastian Hecht, Kuninori Morimoto

On Mon, Apr 29, 2013 at 04:49:07PM +0200, Arnd Bergmann wrote:
> On Friday 26 April 2013, Simon Horman wrote:
> > > diff --git a/arch/arm/mach-shmobile/intc-r8a7740.c b/arch/arm/mach-shmobile/intc-r8a7740.c
> > > index 8871f77..5dc57f1 100644
> > > --- a/arch/arm/mach-shmobile/intc-r8a7740.c
> > > +++ b/arch/arm/mach-shmobile/intc-r8a7740.c
> > > @@ -53,14 +53,23 @@ static void __init r8a7740_init_irq_common(void)
> > >  
> > >  void __init r8a7740_init_irq_of(void)
> > >  {
> > > +     if (!IS_ENABLED(CONFIG_OF))
> > > +             return;
> > > +
> > 
> > In other parts of the shmobile I believe that such code is
> > guarded by #ifdef CONFIG_OF and I believe not guarding this code in
> > some way was an oversight.
> > 
> > The above change seems fine to me.
> 
> Ok. The change that broke the code is only present in linux-next from
> one of your trees, but is not in arm-soc. Could you include the change
> in your tree, either by folding into one of your patches or adapting
> my patch appropriately?

Yes, or of course. I'll queue-up your patch with
the second hunk (below) removed.

> > > +
> > > +     gic_dist_base = ioremap_nocache(0xc2800000, 0x1000);
> > > +     gic_cpu_base = ioremap_nocache(0xc2000000, 0x1000);
> > >  
> > >       /* initialize the Generic Interrupt Controller PL390 r0p0 */
> > >       gic_init(0, 29, gic_dist_base, gic_cpu_base);
> > 
> > This one seems broken as the armadillo800eva board currently uses
> > it to initialise GIC even if CONFIG_ATAGS is not defined.
> > 
> > I did test the above change on the armadillo800eva board
> > with the above change and CONFIG_ATAGS disabled, the result was
> > a boot failure. With the change reverted booting seems fine.
> 
> Yes, I see my mistake now. The second change was clearly wrong
> as this function is also used for DT boards, not for ATAGS boards.
> 
> 	Arnd
> 

^ permalink raw reply	[flat|nested] 131+ messages in thread

* [PATCH 03/21] ARM: shmobile: don't call irqchip_init unconditionally
@ 2013-04-30  1:58         ` Simon Horman
  0 siblings, 0 replies; 131+ messages in thread
From: Simon Horman @ 2013-04-30  1:58 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, Apr 29, 2013 at 04:49:07PM +0200, Arnd Bergmann wrote:
> On Friday 26 April 2013, Simon Horman wrote:
> > > diff --git a/arch/arm/mach-shmobile/intc-r8a7740.c b/arch/arm/mach-shmobile/intc-r8a7740.c
> > > index 8871f77..5dc57f1 100644
> > > --- a/arch/arm/mach-shmobile/intc-r8a7740.c
> > > +++ b/arch/arm/mach-shmobile/intc-r8a7740.c
> > > @@ -53,14 +53,23 @@ static void __init r8a7740_init_irq_common(void)
> > >  
> > >  void __init r8a7740_init_irq_of(void)
> > >  {
> > > +     if (!IS_ENABLED(CONFIG_OF))
> > > +             return;
> > > +
> > 
> > In other parts of the shmobile I believe that such code is
> > guarded by #ifdef CONFIG_OF and I believe not guarding this code in
> > some way was an oversight.
> > 
> > The above change seems fine to me.
> 
> Ok. The change that broke the code is only present in linux-next from
> one of your trees, but is not in arm-soc. Could you include the change
> in your tree, either by folding into one of your patches or adapting
> my patch appropriately?

Yes, or of course. I'll queue-up your patch with
the second hunk (below) removed.

> > > +
> > > +     gic_dist_base = ioremap_nocache(0xc2800000, 0x1000);
> > > +     gic_cpu_base = ioremap_nocache(0xc2000000, 0x1000);
> > >  
> > >       /* initialize the Generic Interrupt Controller PL390 r0p0 */
> > >       gic_init(0, 29, gic_dist_base, gic_cpu_base);
> > 
> > This one seems broken as the armadillo800eva board currently uses
> > it to initialise GIC even if CONFIG_ATAGS is not defined.
> > 
> > I did test the above change on the armadillo800eva board
> > with the above change and CONFIG_ATAGS disabled, the result was
> > a boot failure. With the change reverted booting seems fine.
> 
> Yes, I see my mistake now. The second change was clearly wrong
> as this function is also used for DT boards, not for ATAGS boards.
> 
> 	Arnd
> 

^ permalink raw reply	[flat|nested] 131+ messages in thread

* Re: [PATCH 03/21] ARM: shmobile: don't call irqchip_init unconditionally
  2013-04-30  1:58         ` Simon Horman
@ 2013-04-30  2:25           ` Simon Horman
  -1 siblings, 0 replies; 131+ messages in thread
From: Simon Horman @ 2013-04-30  2:25 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Kuninori Morimoto, Bastian Hecht, linux-kernel, linux-arm-kernel

On Tue, Apr 30, 2013 at 10:58:40AM +0900, Simon Horman wrote:
> On Mon, Apr 29, 2013 at 04:49:07PM +0200, Arnd Bergmann wrote:
> > On Friday 26 April 2013, Simon Horman wrote:
> > > > diff --git a/arch/arm/mach-shmobile/intc-r8a7740.c b/arch/arm/mach-shmobile/intc-r8a7740.c
> > > > index 8871f77..5dc57f1 100644
> > > > --- a/arch/arm/mach-shmobile/intc-r8a7740.c
> > > > +++ b/arch/arm/mach-shmobile/intc-r8a7740.c
> > > > @@ -53,14 +53,23 @@ static void __init r8a7740_init_irq_common(void)
> > > >  
> > > >  void __init r8a7740_init_irq_of(void)
> > > >  {
> > > > +     if (!IS_ENABLED(CONFIG_OF))
> > > > +             return;
> > > > +
> > > 
> > > In other parts of the shmobile I believe that such code is
> > > guarded by #ifdef CONFIG_OF and I believe not guarding this code in
> > > some way was an oversight.
> > > 
> > > The above change seems fine to me.
> > 
> > Ok. The change that broke the code is only present in linux-next from
> > one of your trees, but is not in arm-soc. Could you include the change
> > in your tree, either by folding into one of your patches or adapting
> > my patch appropriately?
> 
> Yes, or of course. I'll queue-up your patch with
> the second hunk (below) removed.
> 
> > > > +
> > > > +     gic_dist_base = ioremap_nocache(0xc2800000, 0x1000);
> > > > +     gic_cpu_base = ioremap_nocache(0xc2000000, 0x1000);
> > > >  
> > > >       /* initialize the Generic Interrupt Controller PL390 r0p0 */
> > > >       gic_init(0, 29, gic_dist_base, gic_cpu_base);
> > > 
> > > This one seems broken as the armadillo800eva board currently uses
> > > it to initialise GIC even if CONFIG_ATAGS is not defined.
> > > 
> > > I did test the above change on the armadillo800eva board
> > > with the above change and CONFIG_ATAGS disabled, the result was
> > > a boot failure. With the change reverted booting seems fine.
> > 
> > Yes, I see my mistake now. The second change was clearly wrong
> > as this function is also used for DT boards, not for ATAGS boards.
> > 
> > 	Arnd

I have queued-up the following in the soc-r8a7740 branch of the
renesas tree and will push it shortly. It should subsequently arrive
in linux-next.

>From ea19ad39e1d2b095fe867103fdf7c8dd8240a832 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@arndb.de>
Date: Thu, 25 Apr 2013 19:28:46 +0200
Subject: [PATCH] ARM: shmobile: don't call irqchip_init unconditionally

The irqchip_init function is only available when building
with CONFIG_OF enabled, which causes this build failure for
bonito_defconfig:

arch/arm/mach-shmobile/built-in.o: In function `r8a7740_init_irq_of':
:(.init.text+0x580): undefined reference to `irqchip_init'

This makes the OF portion of the driver conditional, which avoids
the build error and also results in smaller object code OF is disabled,
without the need for an #ifdef.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Bastian Hecht <hechtb+renesas@gmail.com>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
[horms+renesas@verge.net.au: Remove ATAGS portion which causes boot failure]
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/mach-shmobile/intc-r8a7740.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-shmobile/intc-r8a7740.c b/arch/arm/mach-shmobile/intc-r8a7740.c
index 8871f77..61e2a21 100644
--- a/arch/arm/mach-shmobile/intc-r8a7740.c
+++ b/arch/arm/mach-shmobile/intc-r8a7740.c
@@ -53,6 +53,9 @@ static void __init r8a7740_init_irq_common(void)
 
 void __init r8a7740_init_irq_of(void)
 {
+	if (!IS_ENABLED(CONFIG_OF))
+		return;
+
 	irqchip_init();
 	r8a7740_init_irq_common();
 }
-- 
1.8.2.1


^ permalink raw reply related	[flat|nested] 131+ messages in thread

* [PATCH 03/21] ARM: shmobile: don't call irqchip_init unconditionally
@ 2013-04-30  2:25           ` Simon Horman
  0 siblings, 0 replies; 131+ messages in thread
From: Simon Horman @ 2013-04-30  2:25 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Apr 30, 2013 at 10:58:40AM +0900, Simon Horman wrote:
> On Mon, Apr 29, 2013 at 04:49:07PM +0200, Arnd Bergmann wrote:
> > On Friday 26 April 2013, Simon Horman wrote:
> > > > diff --git a/arch/arm/mach-shmobile/intc-r8a7740.c b/arch/arm/mach-shmobile/intc-r8a7740.c
> > > > index 8871f77..5dc57f1 100644
> > > > --- a/arch/arm/mach-shmobile/intc-r8a7740.c
> > > > +++ b/arch/arm/mach-shmobile/intc-r8a7740.c
> > > > @@ -53,14 +53,23 @@ static void __init r8a7740_init_irq_common(void)
> > > >  
> > > >  void __init r8a7740_init_irq_of(void)
> > > >  {
> > > > +     if (!IS_ENABLED(CONFIG_OF))
> > > > +             return;
> > > > +
> > > 
> > > In other parts of the shmobile I believe that such code is
> > > guarded by #ifdef CONFIG_OF and I believe not guarding this code in
> > > some way was an oversight.
> > > 
> > > The above change seems fine to me.
> > 
> > Ok. The change that broke the code is only present in linux-next from
> > one of your trees, but is not in arm-soc. Could you include the change
> > in your tree, either by folding into one of your patches or adapting
> > my patch appropriately?
> 
> Yes, or of course. I'll queue-up your patch with
> the second hunk (below) removed.
> 
> > > > +
> > > > +     gic_dist_base = ioremap_nocache(0xc2800000, 0x1000);
> > > > +     gic_cpu_base = ioremap_nocache(0xc2000000, 0x1000);
> > > >  
> > > >       /* initialize the Generic Interrupt Controller PL390 r0p0 */
> > > >       gic_init(0, 29, gic_dist_base, gic_cpu_base);
> > > 
> > > This one seems broken as the armadillo800eva board currently uses
> > > it to initialise GIC even if CONFIG_ATAGS is not defined.
> > > 
> > > I did test the above change on the armadillo800eva board
> > > with the above change and CONFIG_ATAGS disabled, the result was
> > > a boot failure. With the change reverted booting seems fine.
> > 
> > Yes, I see my mistake now. The second change was clearly wrong
> > as this function is also used for DT boards, not for ATAGS boards.
> > 
> > 	Arnd

I have queued-up the following in the soc-r8a7740 branch of the
renesas tree and will push it shortly. It should subsequently arrive
in linux-next.

>From ea19ad39e1d2b095fe867103fdf7c8dd8240a832 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@arndb.de>
Date: Thu, 25 Apr 2013 19:28:46 +0200
Subject: [PATCH] ARM: shmobile: don't call irqchip_init unconditionally

The irqchip_init function is only available when building
with CONFIG_OF enabled, which causes this build failure for
bonito_defconfig:

arch/arm/mach-shmobile/built-in.o: In function `r8a7740_init_irq_of':
:(.init.text+0x580): undefined reference to `irqchip_init'

This makes the OF portion of the driver conditional, which avoids
the build error and also results in smaller object code OF is disabled,
without the need for an #ifdef.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Bastian Hecht <hechtb+renesas@gmail.com>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
[horms+renesas at verge.net.au: Remove ATAGS portion which causes boot failure]
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/mach-shmobile/intc-r8a7740.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-shmobile/intc-r8a7740.c b/arch/arm/mach-shmobile/intc-r8a7740.c
index 8871f77..61e2a21 100644
--- a/arch/arm/mach-shmobile/intc-r8a7740.c
+++ b/arch/arm/mach-shmobile/intc-r8a7740.c
@@ -53,6 +53,9 @@ static void __init r8a7740_init_irq_common(void)
 
 void __init r8a7740_init_irq_of(void)
 {
+	if (!IS_ENABLED(CONFIG_OF))
+		return;
+
 	irqchip_init();
 	r8a7740_init_irq_common();
 }
-- 
1.8.2.1

^ permalink raw reply related	[flat|nested] 131+ messages in thread

* Re: [PATCH 10/21] [SCSI] nsp32: use mdelay instead of large udelay constants
  2013-04-29 13:21       ` Arnd Bergmann
@ 2013-05-01 13:55         ` James Bottomley
  -1 siblings, 0 replies; 131+ messages in thread
From: James Bottomley @ 2013-05-01 13:55 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Masanori Goto, linux-arm-kernel, linux-kernel, YOKOTA Hiroshi,
	linux-scsi


On Mon, 2013-04-29 at 15:21 +0200, Arnd Bergmann wrote:
> On Friday 26 April 2013, Masanori Goto wrote:
> > 2013/4/25 Arnd Bergmann <arnd@arndb.de>
> > >
> > > ARM cannot handle udelay for more than 2 miliseconds, so we
> > > should use mdelay instead for those.
> > >
> > 
> > Singed-off-by: GOTO Masanori <gotom@debian.or.jp>
> 
> Thanks. I assume you mean "Acked-by", not "Singed-off" as in "burnt"
> or "Signed-off" as a notification that you have applied it to your
> own git tree.
> 
> I'll keep the patch with an your "Acked-by" line in my tree unless
> James wants to apply to the scsi tree.

I can, certainly.  I'll be sending the first scsi set today, but I'll be
doing another one for just before the close of the merge window.

Goto-san, while I have your attention, is the nsp_cs driver orphaned? I
know it's not your driver, but you did once work with its author (YOKOTA
Hiroshi <yokota@netlab.is.tsukuba.ac.jp>) and I'm trying to get some
cleanup on the static functions in the header files.

Thanks,

James












^ permalink raw reply	[flat|nested] 131+ messages in thread

* [PATCH 10/21] [SCSI] nsp32: use mdelay instead of large udelay constants
@ 2013-05-01 13:55         ` James Bottomley
  0 siblings, 0 replies; 131+ messages in thread
From: James Bottomley @ 2013-05-01 13:55 UTC (permalink / raw)
  To: linux-arm-kernel


On Mon, 2013-04-29 at 15:21 +0200, Arnd Bergmann wrote:
> On Friday 26 April 2013, Masanori Goto wrote:
> > 2013/4/25 Arnd Bergmann <arnd@arndb.de>
> > >
> > > ARM cannot handle udelay for more than 2 miliseconds, so we
> > > should use mdelay instead for those.
> > >
> > 
> > Singed-off-by: GOTO Masanori <gotom@debian.or.jp>
> 
> Thanks. I assume you mean "Acked-by", not "Singed-off" as in "burnt"
> or "Signed-off" as a notification that you have applied it to your
> own git tree.
> 
> I'll keep the patch with an your "Acked-by" line in my tree unless
> James wants to apply to the scsi tree.

I can, certainly.  I'll be sending the first scsi set today, but I'll be
doing another one for just before the close of the merge window.

Goto-san, while I have your attention, is the nsp_cs driver orphaned? I
know it's not your driver, but you did once work with its author (YOKOTA
Hiroshi <yokota@netlab.is.tsukuba.ac.jp>) and I'm trying to get some
cleanup on the static functions in the header files.

Thanks,

James

^ permalink raw reply	[flat|nested] 131+ messages in thread

* Re: [PATCH 03/21] ARM: shmobile: don't call irqchip_init unconditionally
  2013-04-25 17:28   ` Arnd Bergmann
@ 2013-05-01 15:54     ` Rob Herring
  -1 siblings, 0 replies; 131+ messages in thread
From: Rob Herring @ 2013-05-01 15:54 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: linux-arm-kernel, Simon Horman, Kuninori Morimoto, Bastian Hecht,
	linux-kernel

On Thu, Apr 25, 2013 at 12:28 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> The irqchip_init function is only available when building
> with CONFIG_OF enabled, which causes this build failure for
> bonito_defconfig:
>
> arch/arm/mach-shmobile/built-in.o: In function `r8a7740_init_irq_of':
> :(.init.text+0x580): undefined reference to `irqchip_init'
>
> This makes both the OF and the ATAGS portion of the driver
> conditional, which avoids the build error and also results
> in smaller object code if not both are enabled, without the
> need for an #ifdef.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Bastian Hecht <hechtb+renesas@gmail.com>
> Cc: Simon Horman <horms+renesas@verge.net.au>
> Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> ---
>  arch/arm/mach-shmobile/intc-r8a7740.c | 13 +++++++++++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-shmobile/intc-r8a7740.c b/arch/arm/mach-shmobile/intc-r8a7740.c
> index 8871f77..5dc57f1 100644
> --- a/arch/arm/mach-shmobile/intc-r8a7740.c
> +++ b/arch/arm/mach-shmobile/intc-r8a7740.c
> @@ -53,14 +53,23 @@ static void __init r8a7740_init_irq_common(void)
>
>  void __init r8a7740_init_irq_of(void)
>  {
> +       if (!IS_ENABLED(CONFIG_OF))
> +               return;
> +
>         irqchip_init();

Why not have an empty irqchip_init? I'd guess we'll need this on other
platforms and your default mach.

Rob

^ permalink raw reply	[flat|nested] 131+ messages in thread

* [PATCH 03/21] ARM: shmobile: don't call irqchip_init unconditionally
@ 2013-05-01 15:54     ` Rob Herring
  0 siblings, 0 replies; 131+ messages in thread
From: Rob Herring @ 2013-05-01 15:54 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, Apr 25, 2013 at 12:28 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> The irqchip_init function is only available when building
> with CONFIG_OF enabled, which causes this build failure for
> bonito_defconfig:
>
> arch/arm/mach-shmobile/built-in.o: In function `r8a7740_init_irq_of':
> :(.init.text+0x580): undefined reference to `irqchip_init'
>
> This makes both the OF and the ATAGS portion of the driver
> conditional, which avoids the build error and also results
> in smaller object code if not both are enabled, without the
> need for an #ifdef.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Bastian Hecht <hechtb+renesas@gmail.com>
> Cc: Simon Horman <horms+renesas@verge.net.au>
> Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> ---
>  arch/arm/mach-shmobile/intc-r8a7740.c | 13 +++++++++++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-shmobile/intc-r8a7740.c b/arch/arm/mach-shmobile/intc-r8a7740.c
> index 8871f77..5dc57f1 100644
> --- a/arch/arm/mach-shmobile/intc-r8a7740.c
> +++ b/arch/arm/mach-shmobile/intc-r8a7740.c
> @@ -53,14 +53,23 @@ static void __init r8a7740_init_irq_common(void)
>
>  void __init r8a7740_init_irq_of(void)
>  {
> +       if (!IS_ENABLED(CONFIG_OF))
> +               return;
> +
>         irqchip_init();

Why not have an empty irqchip_init? I'd guess we'll need this on other
platforms and your default mach.

Rob

^ permalink raw reply	[flat|nested] 131+ messages in thread

* Re: [PATCH 03/21] ARM: shmobile: don't call irqchip_init unconditionally
  2013-05-01 15:54     ` Rob Herring
@ 2013-05-01 22:57       ` Simon Horman
  -1 siblings, 0 replies; 131+ messages in thread
From: Simon Horman @ 2013-05-01 22:57 UTC (permalink / raw)
  To: Rob Herring
  Cc: Arnd Bergmann, Bastian Hecht, Kuninori Morimoto,
	linux-arm-kernel, linux-kernel

On Wed, May 01, 2013 at 10:54:30AM -0500, Rob Herring wrote:
> On Thu, Apr 25, 2013 at 12:28 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > The irqchip_init function is only available when building
> > with CONFIG_OF enabled, which causes this build failure for
> > bonito_defconfig:
> >
> > arch/arm/mach-shmobile/built-in.o: In function `r8a7740_init_irq_of':
> > :(.init.text+0x580): undefined reference to `irqchip_init'
> >
> > This makes both the OF and the ATAGS portion of the driver
> > conditional, which avoids the build error and also results
> > in smaller object code if not both are enabled, without the
> > need for an #ifdef.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Bastian Hecht <hechtb+renesas@gmail.com>
> > Cc: Simon Horman <horms+renesas@verge.net.au>
> > Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> > ---
> >  arch/arm/mach-shmobile/intc-r8a7740.c | 13 +++++++++++--
> >  1 file changed, 11 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/mach-shmobile/intc-r8a7740.c b/arch/arm/mach-shmobile/intc-r8a7740.c
> > index 8871f77..5dc57f1 100644
> > --- a/arch/arm/mach-shmobile/intc-r8a7740.c
> > +++ b/arch/arm/mach-shmobile/intc-r8a7740.c
> > @@ -53,14 +53,23 @@ static void __init r8a7740_init_irq_common(void)
> >
> >  void __init r8a7740_init_irq_of(void)
> >  {
> > +       if (!IS_ENABLED(CONFIG_OF))
> > +               return;
> > +
> >         irqchip_init();
> 
> Why not have an empty irqchip_init? I'd guess we'll need this on other
> platforms and your default mach.

Thanks, I think that could work.

I will see about making it so.

^ permalink raw reply	[flat|nested] 131+ messages in thread

* [PATCH 03/21] ARM: shmobile: don't call irqchip_init unconditionally
@ 2013-05-01 22:57       ` Simon Horman
  0 siblings, 0 replies; 131+ messages in thread
From: Simon Horman @ 2013-05-01 22:57 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, May 01, 2013 at 10:54:30AM -0500, Rob Herring wrote:
> On Thu, Apr 25, 2013 at 12:28 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > The irqchip_init function is only available when building
> > with CONFIG_OF enabled, which causes this build failure for
> > bonito_defconfig:
> >
> > arch/arm/mach-shmobile/built-in.o: In function `r8a7740_init_irq_of':
> > :(.init.text+0x580): undefined reference to `irqchip_init'
> >
> > This makes both the OF and the ATAGS portion of the driver
> > conditional, which avoids the build error and also results
> > in smaller object code if not both are enabled, without the
> > need for an #ifdef.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Bastian Hecht <hechtb+renesas@gmail.com>
> > Cc: Simon Horman <horms+renesas@verge.net.au>
> > Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> > ---
> >  arch/arm/mach-shmobile/intc-r8a7740.c | 13 +++++++++++--
> >  1 file changed, 11 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/mach-shmobile/intc-r8a7740.c b/arch/arm/mach-shmobile/intc-r8a7740.c
> > index 8871f77..5dc57f1 100644
> > --- a/arch/arm/mach-shmobile/intc-r8a7740.c
> > +++ b/arch/arm/mach-shmobile/intc-r8a7740.c
> > @@ -53,14 +53,23 @@ static void __init r8a7740_init_irq_common(void)
> >
> >  void __init r8a7740_init_irq_of(void)
> >  {
> > +       if (!IS_ENABLED(CONFIG_OF))
> > +               return;
> > +
> >         irqchip_init();
> 
> Why not have an empty irqchip_init? I'd guess we'll need this on other
> platforms and your default mach.

Thanks, I think that could work.

I will see about making it so.

^ permalink raw reply	[flat|nested] 131+ messages in thread

* Re: [PATCH 03/21] ARM: shmobile: don't call irqchip_init unconditionally
  2013-05-01 22:57       ` Simon Horman
@ 2013-05-08 12:16         ` Arnd Bergmann
  -1 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-05-08 12:16 UTC (permalink / raw)
  To: Simon Horman
  Cc: Rob Herring, Bastian Hecht, Kuninori Morimoto, linux-arm-kernel,
	linux-kernel

On Thursday 02 May 2013, Simon Horman wrote:
> > > diff --git a/arch/arm/mach-shmobile/intc-r8a7740.c b/arch/arm/mach-shmobile/intc-r8a7740.c
> > > index 8871f77..5dc57f1 100644
> > > --- a/arch/arm/mach-shmobile/intc-r8a7740.c
> > > +++ b/arch/arm/mach-shmobile/intc-r8a7740.c
> > > @@ -53,14 +53,23 @@ static void __init r8a7740_init_irq_common(void)
> > >
> > >  void __init r8a7740_init_irq_of(void)
> > >  {
> > > +       if (!IS_ENABLED(CONFIG_OF))
> > > +               return;
> > > +
> > >         irqchip_init();
> > 
> > Why not have an empty irqchip_init? I'd guess we'll need this on other
> > platforms and your default mach.
> 
> Thanks, I think that could work.
> 
> I will see about making it so.

Ping

Linux-next is still broken for me. There is also anothe shmobile build bug,
I'll send a separate patch for that, which also needs to go into your tree.

	Arnd

^ permalink raw reply	[flat|nested] 131+ messages in thread

* [PATCH 03/21] ARM: shmobile: don't call irqchip_init unconditionally
@ 2013-05-08 12:16         ` Arnd Bergmann
  0 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-05-08 12:16 UTC (permalink / raw)
  To: linux-arm-kernel

On Thursday 02 May 2013, Simon Horman wrote:
> > > diff --git a/arch/arm/mach-shmobile/intc-r8a7740.c b/arch/arm/mach-shmobile/intc-r8a7740.c
> > > index 8871f77..5dc57f1 100644
> > > --- a/arch/arm/mach-shmobile/intc-r8a7740.c
> > > +++ b/arch/arm/mach-shmobile/intc-r8a7740.c
> > > @@ -53,14 +53,23 @@ static void __init r8a7740_init_irq_common(void)
> > >
> > >  void __init r8a7740_init_irq_of(void)
> > >  {
> > > +       if (!IS_ENABLED(CONFIG_OF))
> > > +               return;
> > > +
> > >         irqchip_init();
> > 
> > Why not have an empty irqchip_init? I'd guess we'll need this on other
> > platforms and your default mach.
> 
> Thanks, I think that could work.
> 
> I will see about making it so.

Ping

Linux-next is still broken for me. There is also anothe shmobile build bug,
I'll send a separate patch for that, which also needs to go into your tree.

	Arnd

^ permalink raw reply	[flat|nested] 131+ messages in thread

* Re: [PATCH 03/21] ARM: shmobile: don't call irqchip_init unconditionally
  2013-05-08 12:16         ` Arnd Bergmann
@ 2013-05-08 13:22           ` Bastian Hecht
  -1 siblings, 0 replies; 131+ messages in thread
From: Bastian Hecht @ 2013-05-08 13:22 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Simon Horman, Rob Herring, Bastian Hecht, Kuninori Morimoto,
	linux-arm-kernel, linux-kernel

Hi,

2013/5/8 Arnd Bergmann <arnd@arndb.de>:
> On Thursday 02 May 2013, Simon Horman wrote:
>> > > diff --git a/arch/arm/mach-shmobile/intc-r8a7740.c b/arch/arm/mach-shmobile/intc-r8a7740.c
>> > > index 8871f77..5dc57f1 100644
>> > > --- a/arch/arm/mach-shmobile/intc-r8a7740.c
>> > > +++ b/arch/arm/mach-shmobile/intc-r8a7740.c
>> > > @@ -53,14 +53,23 @@ static void __init r8a7740_init_irq_common(void)
>> > >
>> > >  void __init r8a7740_init_irq_of(void)
>> > >  {
>> > > +       if (!IS_ENABLED(CONFIG_OF))
>> > > +               return;
>> > > +
>> > >         irqchip_init();
>> >
>> > Why not have an empty irqchip_init? I'd guess we'll need this on other
>> > platforms and your default mach.
>>
>> Thanks, I think that could work.
>>
>> I will see about making it so.
>
> Ping

I have sent out a patch adding an empty irqchip_init() when
CONFIG_IRQCHIP is not set with the subject
[PATCH] irqchip: Add irqchip_init dummy function

> Linux-next is still broken for me. There is also anothe shmobile build bug,
> I'll send a separate patch for that, which also needs to go into your tree.

Oh thanks Arnd for this fix!

Cheers,

 Bastian

^ permalink raw reply	[flat|nested] 131+ messages in thread

* [PATCH 03/21] ARM: shmobile: don't call irqchip_init unconditionally
@ 2013-05-08 13:22           ` Bastian Hecht
  0 siblings, 0 replies; 131+ messages in thread
From: Bastian Hecht @ 2013-05-08 13:22 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

2013/5/8 Arnd Bergmann <arnd@arndb.de>:
> On Thursday 02 May 2013, Simon Horman wrote:
>> > > diff --git a/arch/arm/mach-shmobile/intc-r8a7740.c b/arch/arm/mach-shmobile/intc-r8a7740.c
>> > > index 8871f77..5dc57f1 100644
>> > > --- a/arch/arm/mach-shmobile/intc-r8a7740.c
>> > > +++ b/arch/arm/mach-shmobile/intc-r8a7740.c
>> > > @@ -53,14 +53,23 @@ static void __init r8a7740_init_irq_common(void)
>> > >
>> > >  void __init r8a7740_init_irq_of(void)
>> > >  {
>> > > +       if (!IS_ENABLED(CONFIG_OF))
>> > > +               return;
>> > > +
>> > >         irqchip_init();
>> >
>> > Why not have an empty irqchip_init? I'd guess we'll need this on other
>> > platforms and your default mach.
>>
>> Thanks, I think that could work.
>>
>> I will see about making it so.
>
> Ping

I have sent out a patch adding an empty irqchip_init() when
CONFIG_IRQCHIP is not set with the subject
[PATCH] irqchip: Add irqchip_init dummy function

> Linux-next is still broken for me. There is also anothe shmobile build bug,
> I'll send a separate patch for that, which also needs to go into your tree.

Oh thanks Arnd for this fix!

Cheers,

 Bastian

^ permalink raw reply	[flat|nested] 131+ messages in thread

* Re: [PATCH 03/21] ARM: shmobile: don't call irqchip_init unconditionally
  2013-05-08 13:22           ` Bastian Hecht
@ 2013-05-08 13:34             ` Arnd Bergmann
  -1 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-05-08 13:34 UTC (permalink / raw)
  To: Bastian Hecht
  Cc: Simon Horman, Rob Herring, Bastian Hecht, Kuninori Morimoto,
	linux-arm-kernel, linux-kernel

On Wednesday 08 May 2013, Bastian Hecht wrote:
> 
> 2013/5/8 Arnd Bergmann <arnd@arndb.de>:
> 
> I have sent out a patch adding an empty irqchip_init() when
> CONFIG_IRQCHIP is not set with the subject
> [PATCH] irqchip: Add irqchip_init dummy function

Ah, I missed that one. Is it already in linux-next?

	Arnd

^ permalink raw reply	[flat|nested] 131+ messages in thread

* [PATCH 03/21] ARM: shmobile: don't call irqchip_init unconditionally
@ 2013-05-08 13:34             ` Arnd Bergmann
  0 siblings, 0 replies; 131+ messages in thread
From: Arnd Bergmann @ 2013-05-08 13:34 UTC (permalink / raw)
  To: linux-arm-kernel

On Wednesday 08 May 2013, Bastian Hecht wrote:
> 
> 2013/5/8 Arnd Bergmann <arnd@arndb.de>:
> 
> I have sent out a patch adding an empty irqchip_init() when
> CONFIG_IRQCHIP is not set with the subject
> [PATCH] irqchip: Add irqchip_init dummy function

Ah, I missed that one. Is it already in linux-next?

	Arnd

^ permalink raw reply	[flat|nested] 131+ messages in thread

* Re: [PATCH 03/21] ARM: shmobile: don't call irqchip_init unconditionally
  2013-05-08 13:22           ` Bastian Hecht
@ 2013-05-09  3:38             ` Simon Horman
  -1 siblings, 0 replies; 131+ messages in thread
From: Simon Horman @ 2013-05-09  3:38 UTC (permalink / raw)
  To: Bastian Hecht
  Cc: Arnd Bergmann, Rob Herring, Bastian Hecht, Kuninori Morimoto,
	linux-arm-kernel, linux-kernel

On Wed, May 08, 2013 at 03:22:22PM +0200, Bastian Hecht wrote:
> Hi,
> 
> 2013/5/8 Arnd Bergmann <arnd@arndb.de>:
> > On Thursday 02 May 2013, Simon Horman wrote:
> >> > > diff --git a/arch/arm/mach-shmobile/intc-r8a7740.c b/arch/arm/mach-shmobile/intc-r8a7740.c
> >> > > index 8871f77..5dc57f1 100644
> >> > > --- a/arch/arm/mach-shmobile/intc-r8a7740.c
> >> > > +++ b/arch/arm/mach-shmobile/intc-r8a7740.c
> >> > > @@ -53,14 +53,23 @@ static void __init r8a7740_init_irq_common(void)
> >> > >
> >> > >  void __init r8a7740_init_irq_of(void)
> >> > >  {
> >> > > +       if (!IS_ENABLED(CONFIG_OF))
> >> > > +               return;
> >> > > +
> >> > >         irqchip_init();
> >> >
> >> > Why not have an empty irqchip_init? I'd guess we'll need this on other
> >> > platforms and your default mach.
> >>
> >> Thanks, I think that could work.
> >>
> >> I will see about making it so.
> >
> > Ping
> 
> I have sent out a patch adding an empty irqchip_init() when
> CONFIG_IRQCHIP is not set with the subject
> [PATCH] irqchip: Add irqchip_init dummy function

Thanks.

> > Linux-next is still broken for me. There is also anothe shmobile build bug,
> > I'll send a separate patch for that, which also needs to go into your tree.

Sorry about that. I though I had pushed your fix (the first hunk of the
patch that started this thread), but it seems that I did not.

> Oh thanks Arnd for this fix!
> 
> Cheers,
> 
>  Bastian

^ permalink raw reply	[flat|nested] 131+ messages in thread

* [PATCH 03/21] ARM: shmobile: don't call irqchip_init unconditionally
@ 2013-05-09  3:38             ` Simon Horman
  0 siblings, 0 replies; 131+ messages in thread
From: Simon Horman @ 2013-05-09  3:38 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, May 08, 2013 at 03:22:22PM +0200, Bastian Hecht wrote:
> Hi,
> 
> 2013/5/8 Arnd Bergmann <arnd@arndb.de>:
> > On Thursday 02 May 2013, Simon Horman wrote:
> >> > > diff --git a/arch/arm/mach-shmobile/intc-r8a7740.c b/arch/arm/mach-shmobile/intc-r8a7740.c
> >> > > index 8871f77..5dc57f1 100644
> >> > > --- a/arch/arm/mach-shmobile/intc-r8a7740.c
> >> > > +++ b/arch/arm/mach-shmobile/intc-r8a7740.c
> >> > > @@ -53,14 +53,23 @@ static void __init r8a7740_init_irq_common(void)
> >> > >
> >> > >  void __init r8a7740_init_irq_of(void)
> >> > >  {
> >> > > +       if (!IS_ENABLED(CONFIG_OF))
> >> > > +               return;
> >> > > +
> >> > >         irqchip_init();
> >> >
> >> > Why not have an empty irqchip_init? I'd guess we'll need this on other
> >> > platforms and your default mach.
> >>
> >> Thanks, I think that could work.
> >>
> >> I will see about making it so.
> >
> > Ping
> 
> I have sent out a patch adding an empty irqchip_init() when
> CONFIG_IRQCHIP is not set with the subject
> [PATCH] irqchip: Add irqchip_init dummy function

Thanks.

> > Linux-next is still broken for me. There is also anothe shmobile build bug,
> > I'll send a separate patch for that, which also needs to go into your tree.

Sorry about that. I though I had pushed your fix (the first hunk of the
patch that started this thread), but it seems that I did not.

> Oh thanks Arnd for this fix!
> 
> Cheers,
> 
>  Bastian

^ permalink raw reply	[flat|nested] 131+ messages in thread

* Re: [PATCH 03/21] ARM: shmobile: don't call irqchip_init unconditionally
  2013-05-09  3:38             ` Simon Horman
@ 2013-05-09  4:22               ` Simon Horman
  -1 siblings, 0 replies; 131+ messages in thread
From: Simon Horman @ 2013-05-09  4:22 UTC (permalink / raw)
  To: Bastian Hecht
  Cc: Arnd Bergmann, Kuninori Morimoto, Bastian Hecht, linux-kernel,
	linux-arm-kernel

On Thu, May 09, 2013 at 12:38:19PM +0900, Simon Horman wrote:
> On Wed, May 08, 2013 at 03:22:22PM +0200, Bastian Hecht wrote:
> > Hi,
> > 
> > 2013/5/8 Arnd Bergmann <arnd@arndb.de>:
> > > On Thursday 02 May 2013, Simon Horman wrote:
> > >> > > diff --git a/arch/arm/mach-shmobile/intc-r8a7740.c b/arch/arm/mach-shmobile/intc-r8a7740.c
> > >> > > index 8871f77..5dc57f1 100644
> > >> > > --- a/arch/arm/mach-shmobile/intc-r8a7740.c
> > >> > > +++ b/arch/arm/mach-shmobile/intc-r8a7740.c
> > >> > > @@ -53,14 +53,23 @@ static void __init r8a7740_init_irq_common(void)
> > >> > >
> > >> > >  void __init r8a7740_init_irq_of(void)
> > >> > >  {
> > >> > > +       if (!IS_ENABLED(CONFIG_OF))
> > >> > > +               return;
> > >> > > +
> > >> > >         irqchip_init();
> > >> >
> > >> > Why not have an empty irqchip_init? I'd guess we'll need this on other
> > >> > platforms and your default mach.
> > >>
> > >> Thanks, I think that could work.
> > >>
> > >> I will see about making it so.
> > >
> > > Ping
> > 
> > I have sent out a patch adding an empty irqchip_init() when
> > CONFIG_IRQCHIP is not set with the subject
> > [PATCH] irqchip: Add irqchip_init dummy function
> 
> Thanks.
> 
> > > Linux-next is still broken for me. There is also anothe shmobile build bug,
> > > I'll send a separate patch for that, which also needs to go into your tree.
> 
> Sorry about that. I though I had pushed your fix (the first hunk of the
> patch that started this thread), but it seems that I did not.

Sorry once again for the delay in addressing this.
I have pushed a refreshed next branch which includes
both Bastian's fix for irqchip_init() and the patch
that Arnd posted relating to symbol renames.

These changes should appear in linux-next in the not to distant future.

^ permalink raw reply	[flat|nested] 131+ messages in thread

* [PATCH 03/21] ARM: shmobile: don't call irqchip_init unconditionally
@ 2013-05-09  4:22               ` Simon Horman
  0 siblings, 0 replies; 131+ messages in thread
From: Simon Horman @ 2013-05-09  4:22 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, May 09, 2013 at 12:38:19PM +0900, Simon Horman wrote:
> On Wed, May 08, 2013 at 03:22:22PM +0200, Bastian Hecht wrote:
> > Hi,
> > 
> > 2013/5/8 Arnd Bergmann <arnd@arndb.de>:
> > > On Thursday 02 May 2013, Simon Horman wrote:
> > >> > > diff --git a/arch/arm/mach-shmobile/intc-r8a7740.c b/arch/arm/mach-shmobile/intc-r8a7740.c
> > >> > > index 8871f77..5dc57f1 100644
> > >> > > --- a/arch/arm/mach-shmobile/intc-r8a7740.c
> > >> > > +++ b/arch/arm/mach-shmobile/intc-r8a7740.c
> > >> > > @@ -53,14 +53,23 @@ static void __init r8a7740_init_irq_common(void)
> > >> > >
> > >> > >  void __init r8a7740_init_irq_of(void)
> > >> > >  {
> > >> > > +       if (!IS_ENABLED(CONFIG_OF))
> > >> > > +               return;
> > >> > > +
> > >> > >         irqchip_init();
> > >> >
> > >> > Why not have an empty irqchip_init? I'd guess we'll need this on other
> > >> > platforms and your default mach.
> > >>
> > >> Thanks, I think that could work.
> > >>
> > >> I will see about making it so.
> > >
> > > Ping
> > 
> > I have sent out a patch adding an empty irqchip_init() when
> > CONFIG_IRQCHIP is not set with the subject
> > [PATCH] irqchip: Add irqchip_init dummy function
> 
> Thanks.
> 
> > > Linux-next is still broken for me. There is also anothe shmobile build bug,
> > > I'll send a separate patch for that, which also needs to go into your tree.
> 
> Sorry about that. I though I had pushed your fix (the first hunk of the
> patch that started this thread), but it seems that I did not.

Sorry once again for the delay in addressing this.
I have pushed a refreshed next branch which includes
both Bastian's fix for irqchip_init() and the patch
that Arnd posted relating to symbol renames.

These changes should appear in linux-next in the not to distant future.

^ permalink raw reply	[flat|nested] 131+ messages in thread

* Re: [PATCH 11/21] irqdomain: export irq_domain_add_simple
  2013-04-26  0:50     ` Simon Horman
@ 2013-05-31 22:37       ` Grant Likely
  -1 siblings, 0 replies; 131+ messages in thread
From: Grant Likely @ 2013-05-31 22:37 UTC (permalink / raw)
  To: Simon Horman, Arnd Bergmann
  Cc: linux-arm-kernel, linux-kernel, Benjamin Herrenschmidt,
	Thomas Gleixner, Laurent Pinchart, Magnus Damm

On Fri, 26 Apr 2013 09:50:12 +0900, Simon Horman <horms@verge.net.au> wrote:
> On Thu, Apr 25, 2013 at 07:28:54PM +0200, Arnd Bergmann wrote:
> > All other irq_domain_add_* functions are exported already, and apparently
> > this one got left out by mistake, which causes build errors for ARM
> > allmodconfig kernels:
> > 
> > ERROR: "irq_domain_add_simple" [drivers/gpio/gpio-rcar.ko] undefined!
> > ERROR: "irq_domain_add_simple" [drivers/gpio/gpio-em.ko] undefined!
> > 
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > Cc: Grant Likely <grant.likely@linaro.org>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Cc: Simon Horman <horms+renesas@verge.net.au>
> > Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> > Cc: Magnus Damm <damm@opensource.se>
> 
> Acked-by: Simon Horman <horms+renesas@verge.net.au>
> 
> Grant, could consider taking this one?
> 

Applied, thanks. I'll push out to Linus shortly.

g.

^ permalink raw reply	[flat|nested] 131+ messages in thread

* [PATCH 11/21] irqdomain: export irq_domain_add_simple
@ 2013-05-31 22:37       ` Grant Likely
  0 siblings, 0 replies; 131+ messages in thread
From: Grant Likely @ 2013-05-31 22:37 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, 26 Apr 2013 09:50:12 +0900, Simon Horman <horms@verge.net.au> wrote:
> On Thu, Apr 25, 2013 at 07:28:54PM +0200, Arnd Bergmann wrote:
> > All other irq_domain_add_* functions are exported already, and apparently
> > this one got left out by mistake, which causes build errors for ARM
> > allmodconfig kernels:
> > 
> > ERROR: "irq_domain_add_simple" [drivers/gpio/gpio-rcar.ko] undefined!
> > ERROR: "irq_domain_add_simple" [drivers/gpio/gpio-em.ko] undefined!
> > 
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > Cc: Grant Likely <grant.likely@linaro.org>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Cc: Simon Horman <horms+renesas@verge.net.au>
> > Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> > Cc: Magnus Damm <damm@opensource.se>
> 
> Acked-by: Simon Horman <horms+renesas@verge.net.au>
> 
> Grant, could consider taking this one?
> 

Applied, thanks. I'll push out to Linus shortly.

g.

^ permalink raw reply	[flat|nested] 131+ messages in thread

end of thread, other threads:[~2013-05-31 22:37 UTC | newest]

Thread overview: 131+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-04-25 17:28 [PATCH 00/21] more arm build fixes Arnd Bergmann
2013-04-25 17:28 ` Arnd Bergmann
2013-04-25 17:28 ` Arnd Bergmann
2013-04-25 17:28 ` [PATCH 01/21] ARM: topology: export cpu_topology Arnd Bergmann
2013-04-25 17:28   ` Arnd Bergmann
2013-04-26  8:53   ` Will Deacon
2013-04-26  8:53     ` Will Deacon
2013-04-26 15:07     ` Arnd Bergmann
2013-04-26 15:07       ` Arnd Bergmann
2013-04-25 17:28 ` [PATCH 02/21] ARM: default machine descriptor for multiplatform Arnd Bergmann
2013-04-25 17:28   ` Arnd Bergmann
2013-04-25 17:28 ` [PATCH 03/21] ARM: shmobile: don't call irqchip_init unconditionally Arnd Bergmann
2013-04-25 17:28   ` Arnd Bergmann
2013-04-26  0:48   ` Simon Horman
2013-04-26  0:48     ` Simon Horman
2013-04-26  8:52     ` Bastian Hecht
2013-04-26  8:52       ` Bastian Hecht
2013-04-29 12:58       ` [PATCH 03/21] ARM: shmobile: don't call irqchip_init unconditionallyA Arnd Bergmann
2013-04-29 12:58         ` Arnd Bergmann
2013-04-29 14:49     ` [PATCH 03/21] ARM: shmobile: don't call irqchip_init unconditionally Arnd Bergmann
2013-04-29 14:49       ` Arnd Bergmann
2013-04-30  1:58       ` Simon Horman
2013-04-30  1:58         ` Simon Horman
2013-04-30  2:25         ` Simon Horman
2013-04-30  2:25           ` Simon Horman
2013-05-01 15:54   ` Rob Herring
2013-05-01 15:54     ` Rob Herring
2013-05-01 22:57     ` Simon Horman
2013-05-01 22:57       ` Simon Horman
2013-05-08 12:16       ` Arnd Bergmann
2013-05-08 12:16         ` Arnd Bergmann
2013-05-08 13:22         ` Bastian Hecht
2013-05-08 13:22           ` Bastian Hecht
2013-05-08 13:34           ` Arnd Bergmann
2013-05-08 13:34             ` Arnd Bergmann
2013-05-09  3:38           ` Simon Horman
2013-05-09  3:38             ` Simon Horman
2013-05-09  4:22             ` Simon Horman
2013-05-09  4:22               ` Simon Horman
2013-04-25 17:28 ` [PATCH 04/21] ARM: orion5x: include linux/cpu.h Arnd Bergmann
2013-04-25 17:28   ` Arnd Bergmann
2013-04-25 17:34   ` Jason Cooper
2013-04-25 17:34     ` Jason Cooper
2013-04-25 18:27     ` Jason Cooper
2013-04-25 18:27       ` Jason Cooper
2013-04-25 17:28 ` [PATCH 05/21] atm: he: use mdelay instead of large udelay constants Arnd Bergmann
2013-04-25 17:28   ` Arnd Bergmann
2013-04-26  8:21   ` David Laight
2013-04-26  8:21     ` David Laight
2013-04-26 13:12     ` chas williams - CONTRACTOR
2013-04-26 13:12       ` chas williams - CONTRACTOR
2013-04-26 13:12       ` chas williams - CONTRACTOR
2013-04-29 13:13       ` [PATCH v2 05/21] atm: he: use msleep " Arnd Bergmann
2013-04-29 13:13         ` Arnd Bergmann
2013-04-29 17:27         ` David Miller
2013-04-29 17:27           ` David Miller
2013-04-25 17:28 ` [PATCH 06/21] ALSA: ali5451: use mdelay " Arnd Bergmann
2013-04-25 17:28   ` Arnd Bergmann
2013-04-26  5:40   ` Takashi Iwai
2013-04-26  5:40     ` Takashi Iwai
2013-04-26  5:40     ` Takashi Iwai
2013-04-25 17:28 ` [PATCH 07/21] oss/dmabuf: use dma_map_single Arnd Bergmann
2013-04-25 17:28   ` Arnd Bergmann
2013-04-26  5:41   ` Takashi Iwai
2013-04-26  5:41     ` Takashi Iwai
2013-04-26  5:41     ` Takashi Iwai
2013-04-25 17:28 ` [PATCH 08/21] drm/nouveau: use mdelay instead of large udelay constants Arnd Bergmann
2013-04-25 17:28   ` Arnd Bergmann
2013-04-25 17:28   ` Arnd Bergmann
2013-04-25 17:28 ` [PATCH 09/21] drm: export drm_vm_open_locked Arnd Bergmann
2013-04-25 17:28   ` Arnd Bergmann
2013-04-25 17:28   ` Arnd Bergmann
2013-04-26  4:55   ` Inki Dae
2013-04-25 17:28 ` [PATCH 10/21] [SCSI] nsp32: use mdelay instead of large udelay constants Arnd Bergmann
2013-04-25 17:28   ` Arnd Bergmann
2013-04-26  0:42   ` Masanori Goto
2013-04-26  0:42     ` Masanori Goto
2013-04-29 13:21     ` Arnd Bergmann
2013-04-29 13:21       ` Arnd Bergmann
2013-04-29 13:21       ` Arnd Bergmann
2013-04-29 21:41       ` Masanori Goto
2013-04-29 21:41         ` Masanori Goto
2013-04-29 21:41         ` Masanori Goto
2013-05-01 13:55       ` James Bottomley
2013-05-01 13:55         ` James Bottomley
2013-04-25 17:28 ` [PATCH 11/21] irqdomain: export irq_domain_add_simple Arnd Bergmann
2013-04-25 17:28   ` Arnd Bergmann
2013-04-26  0:50   ` Simon Horman
2013-04-26  0:50     ` Simon Horman
2013-05-31 22:37     ` Grant Likely
2013-05-31 22:37       ` Grant Likely
2013-04-25 17:28 ` [PATCH 12/21] irqchip: s3c24xx: add missing __init annotations Arnd Bergmann
2013-04-25 17:28   ` Arnd Bergmann
2013-04-26 10:39   ` Heiko Stübner
2013-04-26 10:39     ` Heiko Stübner
2013-04-25 17:28 ` [PATCH 13/21] iommu: tegra: print dma_addr_t using %lld Arnd Bergmann
2013-04-25 17:28   ` Arnd Bergmann
2013-04-25 17:42   ` Sethi Varun-B16395
2013-04-25 17:42     ` Sethi Varun-B16395
2013-04-25 17:28 ` [PATCH 14/21] cpufreq: pxa2xx: initialize variables Arnd Bergmann
2013-04-25 17:28   ` Arnd Bergmann
2013-04-25 18:14   ` Rafael J. Wysocki
2013-04-25 18:14     ` Rafael J. Wysocki
2013-04-25 21:09     ` Arnd Bergmann
2013-04-25 21:09       ` Arnd Bergmann
2013-04-25 17:28 ` [PATCH 15/21] thermal: cooling: avoid uninitialied used gcc warning Arnd Bergmann
2013-04-25 17:28   ` Arnd Bergmann
2013-04-25 20:07   ` edubezval
2013-04-25 20:07     ` edubezval at gmail.com
2013-04-25 21:09     ` Arnd Bergmann
2013-04-25 21:09       ` Arnd Bergmann
2013-04-26  8:10   ` Zhang Rui
2013-04-26  8:10     ` Zhang Rui
2013-04-25 17:28 ` [PATCH 16/21] OF: remove #ifdef from linux/of_platform.h Arnd Bergmann
2013-04-25 17:28   ` Arnd Bergmann
2013-04-25 17:29 ` [PATCH 17/21] X.509: do not emit any informational output Arnd Bergmann
2013-04-25 17:29   ` Arnd Bergmann
2013-04-25 17:29 ` [PATCH 18/21] USB: ehci-msm: USB_MSM_OTG needs USB_PHY Arnd Bergmann
2013-04-25 17:29   ` Arnd Bergmann
2013-04-25 17:59   ` Greg Kroah-Hartman
2013-04-25 17:59     ` Greg Kroah-Hartman
2013-04-25 21:12     ` Arnd Bergmann
2013-04-25 21:12       ` Arnd Bergmann
2013-04-25 17:29 ` [PATCH 19/21] USB: lpc32xx: ISP1301 " Arnd Bergmann
2013-04-25 17:29   ` Arnd Bergmann
2013-04-25 19:50   ` Roland Stigge
2013-04-25 19:50     ` Roland Stigge
2013-04-25 17:29 ` [PATCH 20/21] USB: OMAP: " Arnd Bergmann
2013-04-25 17:29   ` Arnd Bergmann
2013-04-25 17:29 ` [PATCH 21/21] USB: OHCI: avoid conflicting platform drivers Arnd Bergmann
2013-04-25 17:29   ` Arnd Bergmann

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.