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

ARM: mvebu: DT: fix OpenBlocks AX3-4 RAM size

2014-07-01T03:14:01+00:00

commit e47043aea3853a74a9aa5726a1faa916d7462ab7 upstream.

The OpenBlocks AX3-4 has a non-DT bootloader.  It also comes with 1GB of
soldered on RAM, and a DIMM slot for expansion.

Unfortunately, atags_to_fdt() doesn't work in big-endian mode, so we see
the following failure when attempting to boot a big-endian kernel:

  686 slab pages
  17 pages shared
  0 pages swap cached
  [ pid ]   uid  tgid total_vm      rss nr_ptes swapents oom_score_adj name
  Kernel panic - not syncing: Out of memory and no killable processes...

  CPU: 1 PID: 351 Comm: kworker/u4:0 Not tainted 3.15.0-rc8-next-20140603 #1
  [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
  [] (show_stack) from [] (dump_stack+0x78/0x94)
  [] (dump_stack) from [] (panic+0x90/0x21c)
  [] (panic) from [] (out_of_memory+0x320/0x340)
  [] (out_of_memory) from [] (__alloc_pages_nodemask+0x874/0x930)
  [] (__alloc_pages_nodemask) from [] (handle_mm_fault+0x744/0x96c)
  [] (handle_mm_fault) from [] (__get_user_pages+0xd0/0x4c0)
  [] (__get_user_pages) from [] (get_arg_page+0x54/0xbc)
  [] (get_arg_page) from [] (copy_strings+0x278/0x29c)
  [] (copy_strings) from [] (copy_strings_kernel+0x20/0x28)
  [] (copy_strings_kernel) from [] (do_execve+0x3a8/0x4c8)
  [] (do_execve) from [] (____call_usermodehelper+0x15c/0x194)
  [] (____call_usermodehelper) from [] (ret_from_fork+0x14/0x3c)
  CPU0: stopping
  CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.15.0-rc8-next-20140603 #1
  [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
  [] (show_stack) from [] (dump_stack+0x78/0x94)
  [] (dump_stack) from [] (handle_IPI+0x138/0x174)
  [] (handle_IPI) from [] (armada_370_xp_handle_irq+0xb0/0xcc)
  [] (armada_370_xp_handle_irq) from [] (__irq_svc+0x40/0x50)
  Exception stack(0xc0b6bf68 to 0xc0b6bfb0)
  bf60:                   e9fad598 00000000 00f509a3 00000000 c0b6a000 c0b724c4
  bf80: c0b72458 c0b6a000 00000000 00000000 c0b66da0 c0b6a000 00000000 c0b6bfb0
  bfa0: c027bb94 c027bb24 60000313 ffffffff
  [] (__irq_svc) from [] (cpu_startup_entry+0x54/0x214)
  [] (cpu_startup_entry) from [] (start_kernel+0x318/0x37c)
  [] (start_kernel) from [<00208078>] (0x208078)
  ---[ end Kernel panic - not syncing: Out of memory and no killable processes...

A similar failure will also occur if ARM_ATAG_DTB_COMPAT isn't selected.

Fix this by setting a sane default (1 GB) in the dts file.

Signed-off-by: Jason Cooper 
Tested-by: Kevin Hilman 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

ARM: OMAP2+: gpmc: enable BCH_HW ecc-scheme for AM43xx platforms

2014-07-01T03:13:59+00:00

commit 2e091d13e65d26f21159323b95b426e5bc42670c upstream.

Fixes: commit 0611c41934ab35ce84dea34ab291897ad3cbc7be
ARM: OMAP2+: gpmc: update gpmc_hwecc_bch_capable() for new platforms and ECC schemes

Though the commit log of above commit mentions AM43xx platforms, but code change
missed AM43xx. This patch adds AM43xx to list of those SoC which have built-in
ELM hardware engine, so that BCH ecc-schemes with hardware error-correction can
be enabled on AM43xx devices.

Reported-by: Roger Quadros 
Signed-off-by: Pekon Gupta 
Signed-off-by: Tony Lindgren 
Signed-off-by: Greg Kroah-Hartman

ARM: 8037/1: mm: support big-endian page tables

2014-07-01T03:13:59+00:00

commit 86f40622af7329375e38f282f6c0aab95f3e5f72 upstream.

When enable LPAE and big-endian in a hisilicon board, while specify
mem=384M mem=512M@7680M, will get bad page state:

Freeing unused kernel memory: 180K (c0466000 - c0493000)
BUG: Bad page state in process init  pfn:fa442
page:c7749840 count:0 mapcount:-1 mapping:  (null) index:0x0
page flags: 0x40000400(reserved)
Modules linked in:
CPU: 0 PID: 1 Comm: init Not tainted 3.10.27+ #66
[] (unwind_backtrace+0x0/0x11c) from [] (show_stack+0x10/0x14)
[] (show_stack+0x10/0x14) from [] (bad_page+0xd4/0x104)
[] (bad_page+0xd4/0x104) from [] (free_pages_prepare+0xa8/0x14c)
[] (free_pages_prepare+0xa8/0x14c) from [] (free_hot_cold_page+0x18/0xf0)
[] (free_hot_cold_page+0x18/0xf0) from [] (handle_pte_fault+0xcf4/0xdc8)
[] (handle_pte_fault+0xcf4/0xdc8) from [] (handle_mm_fault+0xf4/0x120)
[] (handle_mm_fault+0xf4/0x120) from [] (do_page_fault+0xfc/0x354)
[] (do_page_fault+0xfc/0x354) from [] (do_DataAbort+0x2c/0x90)
[] (do_DataAbort+0x2c/0x90) from [] (__dabt_usr+0x34/0x40)

The bad pfn:fa442 is not system memory(mem=384M mem=512M@7680M), after debugging,
I find in page fault handler, will get wrong pfn from pte just after set pte,
as follow:
do_anonymous_page()
{
	...
	set_pte_at(mm, address, page_table, entry);

	//debug code
	pfn = pte_pfn(entry);
	pr_info("pfn:0x%lx, pte:0x%llxn", pfn, pte_val(entry));

	//read out the pte just set
	new_pte = pte_offset_map(pmd, address);
	new_pfn = pte_pfn(*new_pte);
	pr_info("new pfn:0x%lx, new pte:0x%llxn", pfn, pte_val(entry));
	...
}

pfn:   0x1fa4f5,     pte:0xc00001fa4f575f
new_pfn:0xfa4f5, new_pte:0xc00000fa4f5f5f	//new pfn/pte is wrong.

The bug is happened in cpu_v7_set_pte_ext(ptep, pte):
An LPAE PTE is a 64bit quantity, passed to cpu_v7_set_pte_ext in the r2 and r3 registers.
On an LE kernel, r2 contains the LSB of the PTE, and r3 the MSB.
On a BE kernel, the assignment is reversed.

Unfortunately, the current code always assumes the LE case,
leading to corruption of the PTE when clearing/setting bits.

This patch fixes this issue much like it has been done already in the
cpu_v7_switch_mm case.

Signed-off-by: Jianguo Wu 
Acked-by: Marc Zyngier 
Acked-by: Will Deacon 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: stacktrace: avoid listing stacktrace functions in stacktrace

2014-07-01T03:13:59+00:00

commit 3683f44c42e991d313dc301504ee0fca1aeb8580 upstream.

While debugging the FEC ethernet driver using stacktrace, it was noticed
that the stacktraces always begin as follows:

 [] save_stack_trace_tsk+0x0/0x98
 [] save_stack_trace+0x24/0x28
 ...

This is because the stack trace code includes the stack frames for itself.
This is incorrect behaviour, and also leads to "skip" doing the wrong
thing (which is the number of stack frames to avoid recording.)

Perversely, it does the right thing when passed a non-current thread.  Fix
this by ensuring that we have a known constant number of frames above the
main stack trace function, and always skip these.

Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

hugetlb: restrict hugepage_migration_support() to x86_64

2014-07-01T03:13:54+00:00

commit c177c81e09e517bbf75b67762cdab1b83aba6976 upstream.

Currently hugepage migration is available for all archs which support
pmd-level hugepage, but testing is done only for x86_64 and there're
bugs for other archs.  So to avoid breaking such archs, this patch
limits the availability strictly to x86_64 until developers of other
archs get interested in enabling this feature.

Simply disabling hugepage migration on non-x86_64 archs is not enough to
fix the reported problem where sys_move_pages() hits the BUG_ON() in
follow_page(FOLL_GET), so let's fix this by checking if hugepage
migration is supported in vma_migratable().

Signed-off-by: Naoya Horiguchi 
Reported-by: Michael Ellerman 
Tested-by: Michael Ellerman 
Acked-by: Hugh Dickins 
Cc: Benjamin Herrenschmidt 
Cc: Tony Luck 
Cc: Russell King 
Cc: Martin Schwidefsky 
Cc: James Hogan 
Cc: Ralf Baechle 
Cc: David Miller 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

ARM: OMAP: replace checks for CONFIG_USB_GADGET_OMAP

2014-07-01T03:13:54+00:00

commit 77c2f02edbeda9409a7cf3fd66233015820c213a upstream.

Commit 193ab2a60700 ("usb: gadget: allow multiple gadgets to be built")
apparently required that checks for CONFIG_USB_GADGET_OMAP would be
replaced with checks for CONFIG_USB_OMAP. Do so now for the remaining
checks for CONFIG_USB_GADGET_OMAP, even though these checks have
basically been broken since v3.1.

And, since we're touching this code, use the IS_ENABLED() macro, so
things will now (hopefully) also work if USB_OMAP is modular.

Fixes: 193ab2a60700 ("usb: gadget: allow multiple gadgets to be built")
Signed-off-by: Paul Bolle 
Signed-off-by: Tony Lindgren 
Signed-off-by: Greg Kroah-Hartman

ARM: at91: fix at91_sysirq_mask_rtc for sam9x5 SoCs

2014-06-26T19:17:34+00:00

commit 9dcc87fec8947308e0111c65dcd881e6aa5b1673 upstream.

sam9x5 SoCs have the following errata:
 "RTC: Interrupt Mask Register cannot be used
  Interrupt Mask Register read always returns 0."

Hence we should not rely on what IMR claims about already masked IRQs
and just disable all IRQs.

Signed-off-by: Boris BREZILLON 
Reported-by: Bryan Evenson 
Reviewed-by: Johan Hovold 
Acked-by: Nicolas Ferre 
Cc: Bryan Evenson 
Cc: Andrew Victor 
Cc: Jean-Christophe Plagniol-Villard 
Cc: Alessandro Zummo 
Cc: Mark Roszko 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

Merge branch 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm

2014-05-30T01:31:09+00:00

Pull ARM fixes from Russell King:
 "The usual random collection of relatively small ARM fixes"

* 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm:
  ARM: 8063/1: bL_switcher: fix individual online status reporting of removed CPUs
  ARM: 8064/1: fix v7-M signal return
  ARM: 8057/1: amba: Add Qualcomm vendor ID.
  ARM: 8052/1: unwind: Fix handling of "Pop r4-r[4+nnn],r14" opcode
  ARM: 8051/1: put_user: fix possible data corruption in put_user
  ARM: 8048/1: fix v7-M setup stack location

ARM: 8063/1: bL_switcher: fix individual online status reporting of removed CPUs

2014-05-28T15:33:02+00:00

The content of /sys/devices/system/cpu/cpu*/online  is still 1 for those
CPUs that the switcher has removed even though the global state in
/sys/devices/system/cpu/online is updated correctly.

It turns out that commit 0902a9044f ("Driver core: Use generic
offline/online for CPU offline/online") has changed the way those files
retrieve their content by relying on on the generic attribute handling
code.  The switcher, by calling cpu_down() directly, bypasses this
handling and the attribute value doesn't get updated.

Fix this by calling device_offline()/device_online() instead.

Signed-off-by: Nicolas Pitre 
Signed-off-by: Russell King

ARM: 8064/1: fix v7-M signal return

2014-05-25T22:44:27+00:00

According to the ARM ARM, the behaviour is UNPREDICTABLE if the PC read
from the exception return stack is not half word aligned.  See the
pseudo code for ExceptionReturn() and PopStack().

The signal handler's address has the bit 0 set, and setup_return()
directly writes this to regs->ARM_pc.  Current hardware happens to
discard this bit, but QEMU's emulation doesn't and this makes processes
crash.  Mask out bit 0 before the exception return in order to get
predictable behaviour.

Fixes: 19c4d593f0b4 ("ARM: ARMv7-M: Add support for exception handling")

Cc: stable@kernel.org
Acked-by: Uwe Kleine-König 
Signed-off-by: Rabin Vincent 
Signed-off-by: Russell King