linux-stable.git/arch/arm, branch v3.8

Merge tag 'highbank-fixes-for-3.8' of git://sources.calxeda.com/kernel/linux into fixes

2013-02-10T04:55:03+00:00

From Rob Herring:
highbank fixes for 3.8

-Compile fix for !SMP
-More cpu cluster id related fixes

* tag 'highbank-fixes-for-3.8' of git://sources.calxeda.com/kernel/linux:
  ARM: highbank: mask cluster id from cpu_logical_map
  ARM: scu: mask cluster id from cpu_logical_map
  ARM: scu: add empty scu_enable for !CONFIG_SMP

Merge branch 'fixes' of git://git.linaro.org/people/rmk/linux-arm

2013-02-08T21:01:18+00:00

Pull ARM fixes from Russell King:
 "I was going to hold these off until v3.8 was out, and send them with a
  stable tag, but as everyone else is pushing much bigger fixes which
  Linus is accepting, let's save people from the hastle of having to
  patch v3.8 back into working or use a stable kernel.

  Looking at the diffstat, this really is high value for its size; this
  is miniscule compared to how the -rc6 to tip diffstat currently looks.

  So, four patches in this set:
   - Punit Agrawal reports that the kernel no longer boots on MPCore due
     to a new assumption made in the GIC code which isn't true of
     earlier GIC designs.  This is the biggest change in this set.
   - Punit's boot log also revealed a bunch of WARN_ON() dumps caused by
     the DT-ification of the GIC support without fixing up non-DT
     Realview - which now sees a greater number of interrupts than it
     did before.
   - A fix for the DMA coherent code from Marek which uses the wrong
     check for atomic allocations; this can result in spinlock lockups
     or other nasty effects.
   - A fix from Will, which will affect all Android based platforms if
     not applied (which use the 2G:2G VM split) - this causes
     particularly 'make' to misbehave unless this bug is fixed."

* 'fixes' of git://git.linaro.org/people/rmk/linux-arm:
  ARM: 7641/1: memory: fix broken mmap by ensuring TASK_UNMAPPED_BASE is aligned
  ARM: DMA mapping: fix bad atomic test
  ARM: realview: ensure that we have sufficient IRQs available
  ARM: GIC: fix GIC cpumask initialization

ARM: 7641/1: memory: fix broken mmap by ensuring TASK_UNMAPPED_BASE is aligned

2013-02-08T12:21:07+00:00

We have received multiple reports of mmap failures when running with a
2:2 vm split. These manifest as either -EINVAL with a non page-aligned
address (ending 0xaaa) or a SEGV, depending on the application. The
issue is commonly observed in children of make, which appears to use
bottom-up mmap (assumedly because it changes the stack rlimit).

Further investigation reveals that this regression was triggered by
394ef6403abc ("mm: use vm_unmapped_area() on arm architecture"), whereby
TASK_UNMAPPED_BASE is no longer page-aligned for bottom-up mmap, causing
get_unmapped_area to choke on misaligned addressed.

This patch fixes the problem by defining TASK_UNMAPPED_BASE in terms of
TASK_SIZE and explicitly aligns the result to 16M, matching the other
end of the heap.

Acked-by: Nicolas Pitre 
Reported-by: Steve Capper 
Reported-by: Jean-Francois Moine 
Reported-by: Christoffer Dall 
Signed-off-by: Will Deacon 
Signed-off-by: Russell King

ARM: DMA mapping: fix bad atomic test

2013-02-08T10:25:23+00:00

Realview fails to boot with this warning:
BUG: spinlock lockup suspected on CPU#0, init/1
 lock: 0xcf8bde10, .magic: dead4ead, .owner: init/1, .owner_cpu: 0
Backtrace:
[] (dump_backtrace+0x0/0x10c) from [] (dump_stack+0x18/0x1c) r6:cf8bde10 r5:cf83d1c0 r4:cf8bde10 r3:cf83d1c0
[] (dump_stack+0x0/0x1c) from [] (spin_dump+0x84/0x98)
[] (spin_dump+0x0/0x98) from [] (do_raw_spin_lock+0x100/0x198)
[] (do_raw_spin_lock+0x0/0x198) from [] (_raw_spin_lock+0x3c/0x44)
[] (_raw_spin_lock+0x0/0x44) from [] (pl011_console_write+0xe8/0x11c)
[] (pl011_console_write+0x0/0x11c) from [] (call_console_drivers.clone.7+0xdc/0x104)
[] (call_console_drivers.clone.7+0x0/0x104) from [] (console_unlock+0x2e8/0x454)
[] (console_unlock+0x0/0x454) from [] (vprintk_emit+0x2d8/0x594)
[] (vprintk_emit+0x0/0x594) from [] (printk+0x3c/0x44)
[] (printk+0x0/0x44) from [] (warn_slowpath_common+0x28/0x6c)
[] (warn_slowpath_common+0x0/0x6c) from [] (warn_slowpath_null+0x24/0x2c)
[] (warn_slowpath_null+0x0/0x2c) from [] (lockdep_trace_alloc+0xd8/0xf0)
[] (lockdep_trace_alloc+0x0/0xf0) from [] (kmem_cache_alloc+0x24/0x11c)
[] (kmem_cache_alloc+0x0/0x11c) from [] (__get_vm_area_node.clone.24+0x7c/0x16c)
[] (__get_vm_area_node.clone.24+0x0/0x16c) from [] (get_vm_area_caller+0x48/0x54)
[] (get_vm_area_caller+0x0/0x54) from [] (__alloc_remap_buffer.clone.15+0x38/0xb8)
[] (__alloc_remap_buffer.clone.15+0x0/0xb8) from [] (__dma_alloc+0x160/0x2c8)
[] (__dma_alloc+0x0/0x2c8) from [] (arm_dma_alloc+0x88/0xa0)[] (arm_dma_alloc+0x0/0xa0) from [] (dma_pool_alloc+0xcc/0x1a8)
[] (dma_pool_alloc+0x0/0x1a8) from [] (pl08x_fill_llis_for_desc+0x28/0x568)
[] (pl08x_fill_llis_for_desc+0x0/0x568) from [] (pl08x_prep_slave_sg+0x258/0x3b0)
[] (pl08x_prep_slave_sg+0x0/0x3b0) from [] (pl011_dma_tx_refill+0x140/0x288)
[] (pl011_dma_tx_refill+0x0/0x288) from [] (pl011_start_tx+0xe4/0x120)
[] (pl011_start_tx+0x0/0x120) from [] (__uart_start+0x48/0x4c)
[] (__uart_start+0x0/0x4c) from [] (uart_start+0x2c/0x3c)
[] (uart_start+0x0/0x3c) from [] (uart_write+0xcc/0xf4)
[] (uart_write+0x0/0xf4) from [] (n_tty_write+0x1c0/0x3e4)
[] (n_tty_write+0x0/0x3e4) from [] (tty_write+0x144/0x240)
[] (tty_write+0x0/0x240) from [] (redirected_tty_write+0x98/0xac)
[] (redirected_tty_write+0x0/0xac) from [] (vfs_write+0xbc/0x150)
[] (vfs_write+0x0/0x150) from [] (sys_write+0x4c/0x78)
[] (sys_write+0x0/0x78) from [] (ret_fast_syscall+0x0/0x3c)

This happens because the DMA allocation code is not respecting atomic
allocations correctly.

GFP flags should not be tested for GFP_ATOMIC to determine if an
atomic allocation is being requested.  GFP_ATOMIC is not a flag but
a value.  The GFP bitmask flags are all prefixed with __GFP_.

The rest of the kernel tests for __GFP_WAIT not being set to indicate
an atomic allocation.  We need to do the same.

Signed-off-by: Russell King

ARM: realview: ensure that we have sufficient IRQs available

2013-02-08T10:23:32+00:00

Realview EB with a rev B MPcore tile results in lots of warnings at
boot because it can't allocate enough IRQs.  Fix this by increasing
the number of available IRQs.

WARNING: at /home/rmk/git/linux-rmk/arch/arm/common/gic.c:757 gic_init_bases+0x12c/0x2ec()
Cannot allocate irq_descs @ IRQ96, assuming pre-allocated
Modules linked in:
Backtrace:
[] (dump_backtrace+0x0/0x10c) from [] (dump_stack+0x18/0x1c) r6:000002f5 r5:c042c62c r4:c044ff40 r3:c045f240
[] (dump_stack+0x0/0x1c) from [] (warn_slowpath_common+0x54/0x6c)
[] (warn_slowpath_common+0x0/0x6c) from [] (warn_slowpath_fmt+0x38/0x40)
[] (warn_slowpath_fmt+0x0/0x40) from [] (gic_init_bases+0x12c/0x2ec)
[] (gic_init_bases+0x0/0x2ec) from [] (gic_init_irq+0x8c/0xd8)
[] (gic_init_irq+0x0/0xd8) from [] (init_IRQ+0x1c/0x24)
[] (init_IRQ+0x0/0x24) from [] (start_kernel+0x1a4/0x300)
[] (start_kernel+0x0/0x300) from [<70008070>] (0x70008070)
---[ end trace 1b75b31a2719ed1c ]---
------------[ cut here ]------------
WARNING: at /home/rmk/git/linux-rmk/kernel/irq/irqdomain.c:234 irq_domain_add_legacy+0x80/0x140()
Modules linked in:
Backtrace:
[] (dump_backtrace+0x0/0x10c) from [] (dump_stack+0x18/0x1c) r6:000000ea r5:c0081a38 r4:00000000 r3:c045f240
[] (dump_stack+0x0/0x1c) from [] (warn_slowpath_common+0x54/0x6c)
[] (warn_slowpath_common+0x0/0x6c) from [] (warn_slowpath_null+0x24/0x2c)
[] (warn_slowpath_null+0x0/0x2c) from [] (irq_domain_add_legacy+0x80/0x140)
[] (irq_domain_add_legacy+0x0/0x140) from [] (gic_init_bases+0x14c/0x2ec)
[] (gic_init_bases+0x0/0x2ec) from [] (gic_init_irq+0x8c/0xd8)
[] (gic_init_irq+0x0/0xd8) from [] (init_IRQ+0x1c/0x24)
[] (init_IRQ+0x0/0x24) from [] (start_kernel+0x1a4/0x300)
[] (start_kernel+0x0/0x300) from [<70008070>] (0x70008070)
---[ end trace 1b75b31a2719ed1d ]---
------------[ cut here ]------------
WARNING: at /home/rmk/git/linux-rmk/arch/arm/common/gic.c:762 gic_init_bases+0x170/0x2ec()
Modules linked in:
Backtrace:
[] (dump_backtrace+0x0/0x10c) from [] (dump_stack+0x18/0x1c) r6:000002fa r5:c042c670 r4:00000000 r3:c045f240
[] (dump_stack+0x0/0x1c) from [] (warn_slowpath_common+0x54/0x6c)
[] (warn_slowpath_common+0x0/0x6c) from [] (warn_slowpath_null+0x24/0x2c)
[] (warn_slowpath_null+0x0/0x2c) from [] (gic_init_bases+0x170/0x2ec)
[] (gic_init_bases+0x0/0x2ec) from [] (gic_init_irq+0x8c/0xd8)
[] (gic_init_irq+0x0/0xd8) from [] (init_IRQ+0x1c/0x24)
[] (init_IRQ+0x0/0x24) from [] (start_kernel+0x1a4/0x300)
[] (start_kernel+0x0/0x300) from [<70008070>] (0x70008070)
---[ end trace 1b75b31a2719ed1e ]---

Signed-off-by: Russell King

ARM: GIC: fix GIC cpumask initialization

2013-02-08T10:17:22+00:00

Punit Agrawal reports:
> I was trying to boot 3.8-rc5 on Realview EB 11MPCore using
> realview-smp_defconfig as a starting point but the kernel failed to
> progress past the log below (config attached).
>
> Pawel suggested I try reverting 384a290283f - "ARM: gic: use a private
> mapping for CPU target interfaces" that you've authored. With this
> commit reverted the kernel boots.
>
> I am not quite sure why the commit breaks 11MPCore but Pawel (cc'd)
> might be able to shed light on that.

Some early GIC implementations return zero for the first distributor
CPU routing register.  This means we can't rely on that telling us
which CPU interface we're connected to.  We know that these platforms
implement PPIs for IRQs 29-31 - but we shouldn't assume that these
will always be populated.

So, instead, scan for a non-zero CPU routing register in the first
32 IRQs and use that as our CPU mask.

Reported-by: Punit Agrawal 
Reviewed-by: Nicolas Pitre 
Signed-off-by: Russell King

pinctrl: exynos: change PINCTRL_EXYNOS option

2013-02-05T14:27:39+00:00

Since pinctrl-exynos can support exynos4 and exynos5 so changed
the option name to PINCTRL_EXYNOS for more clarity.

Cc: Thomas Abraham 
Cc: Linus Walleij 
Cc: Grant Likely 
Signed-off-by: Kukjin Kim 
Signed-off-by: Linus Walleij

ARM: highbank: mask cluster id from cpu_logical_map

2013-01-31T19:54:30+00:00

With commit a0ae0240 (ARM: kernel: add device tree init map function),
the cpu id value may include the cluster id and is no longer 0-3, so we
need to mask it now to get the right hard cpu index.

Signed-off-by: Rob Herring

ARM: scu: mask cluster id from cpu_logical_map

2013-01-31T19:54:16+00:00

With commit a0ae0240 (ARM: kernel: add device tree init map function),
the cpu id value may include the cluster id and is no longer 0-3, so we
need to mask it in scu_power_mode to get the local cpu number. Since we
are only dealing with the cpu we are running on, the cluster id should
not ever be needed.

Signed-off-by: Rob Herring

ARM: scu: add empty scu_enable for !CONFIG_SMP

2013-01-31T19:06:50+00:00

Add an empty version of scu_enable for !SMP builds. This fixes
compile error for highbank suspend code on !SMP builds.

Signed-off-by: Rob Herring