linux-toradex.git/arch/arm64, branch v4.3.1

xen/events: Always allocate legacy interrupts on PV guests

2015-12-09T19:34:43+00:00

commit b4ff8389ed14b849354b59ce9b360bdefcdbf99c upstream.

After commit 8c058b0b9c34 ("x86/irq: Probe for PIC presence before
allocating descs for legacy IRQs") early_irq_init() will no longer
preallocate descriptors for legacy interrupts if PIC does not
exist, which is the case for Xen PV guests.

Therefore we may need to allocate those descriptors ourselves.

Signed-off-by: Boris Ostrovsky 
Suggested-by: Thomas Gleixner 
Signed-off-by: David Vrabel 
Cc: Vitaly Kuznetsov 
Signed-off-by: Greg Kroah-Hartman

arm64: page-align sections for DEBUG_RODATA

2015-12-09T19:34:31+00:00

commit cb083816ab5ac3d10a9417527f07fc5962cc3808 upstream.

A kernel built with DEBUG_RO_DATA && !CONFIG_DEBUG_ALIGN_RODATA doesn't
have .text aligned to a page boundary, though fixup_executable works at
page-granularity thanks to its use of create_mapping. If .text is not
page-aligned, the first page it exists in may be marked non-executable,
leading to failures when an attempt is made to execute code in said
page.

This patch upgrades ALIGN_DEBUG_RO and ALIGN_DEBUG_RO_MIN to force page
alignment for DEBUG_RO_DATA && !CONFIG_DEBUG_ALIGN_RODATA kernels,
ensuring that all sections with specific RWX permission requirements are
mapped with the correct permissions.

Signed-off-by: Mark Rutland 
Reported-by: Jeremy Linton 
Reviewed-by: Laura Abbott 
Acked-by: Ard Biesheuvel 
Cc: Suzuki Poulose 
Cc: Will Deacon 
Fixes: da141706aea52c1a ("arm64: add better page protections to arm64")
Signed-off-by: Catalin Marinas 
Signed-off-by: Greg Kroah-Hartman

arm64: Fix compat register mappings

2015-12-09T19:34:31+00:00

commit 5accd17d0eb523350c9ef754d655e379c9bb93b3 upstream.

For reasons not entirely apparent, but now enshrined in history, the
architectural mapping of AArch32 banked registers to AArch64 registers
actually orders SP_ and LR_ backwards compared to the
intuitive r13/r14 order, for all modes except FIQ.

Fix the compat__ macros accordingly, in the hope of avoiding
subtle bugs with KVM and AArch32 guests.

Signed-off-by: Robin Murphy 
Acked-by: Will Deacon 
Signed-off-by: Catalin Marinas 
Signed-off-by: Greg Kroah-Hartman

Merge tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc

2015-11-01T04:36:07+00:00

Pull ARM SoC fixes from Olof Johansson:
 "This should be our final batch of fixes for 4.3:

   - A patch from Sudeep Holla that fixes annotation of wakeup sources
     properly, old unused format seems to have spread through copying.

   - Two patches from Tony for OMAP.  One dealing with MUSB setup
     problems due to runtime PM being enabled too early on the parent
     device.  The other fixes IRQ numbering for OMAP1"

* tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
  usb: musb: omap2430: Fix regression caused by driver core change
  ARM: OMAP1: fix incorrect INT_DMA_LCD
  ARM: dts: fix gpio-keys wakeup-source property

arm64/efi: do not assume DRAM base is aligned to 2 MB

2015-10-29T16:10:58+00:00

The current arm64 Image relocation code in the UEFI stub assumes that
the dram_base argument it receives is always a multiple of 2 MB. In
reality, it is simply the lowest start address of all RAM entries in
the UEFI memory map, which means it could be any multiple of 4 KB.

Since the arm64 kernel Image needs to reside TEXT_OFFSET bytes beyond
a 2 MB aligned base, or it will fail to boot, make sure we round dram_base
to 2 MB before using it to calculate the relocation address.

Fixes: e38457c361b30c5a ("arm64: efi: prefer AllocatePages() over efi_low_alloc() for vmlinux")
Reported-by: Timur Tabi 
Tested-by: Timur Tabi 
Acked-by: Mark Rutland 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Will Deacon

Revert "ARM64: unwind: Fix PC calculation"

2015-10-28T17:07:07+00:00

This reverts commit e306dfd06fcb44d21c80acb8e5a88d55f3d1cf63.

With this patch applied, we were the only architecture making this sort
of adjustment to the PC calculation in the unwinder. This causes
problems for ftrace, where the PC values are matched against the
contents of the stack frames in the callchain and fail to match any
records after the address adjustment.

Whilst there has been some effort to change ftrace to workaround this,
those patches are not yet ready for mainline and, since we're the odd
architecture in this regard, let's just step in line with other
architectures (like arch/arm/) for now.

Cc: 
Signed-off-by: Will Deacon

arm64: kernel: fix tcr_el1.t0sz restore on systems with extended idmap

2015-10-28T17:07:07+00:00

Commit dd006da21646 ("arm64: mm: increase VA range of identity map")
introduced a mechanism to extend the virtual memory map range
to support arm64 systems with system RAM located at very high offset,
where the identity mapping used to enable/disable the MMU requires
additional translation levels to map the physical memory at an equal
virtual offset.

The kernel detects at boot time the tcr_el1.t0sz value required by the
identity mapping and sets-up the tcr_el1.t0sz register field accordingly,
any time the identity map is required in the kernel (ie when enabling the
MMU).

After enabling the MMU, in the cold boot path the kernel resets the
tcr_el1.t0sz to its default value (ie the actual configuration value for
the system virtual address space) so that after enabling the MMU the
memory space translated by ttbr0_el1 is restored as expected.

Commit dd006da21646 ("arm64: mm: increase VA range of identity map")
also added code to set-up the tcr_el1.t0sz value when the kernel resumes
from low-power states with the MMU off through cpu_resume() in order to
effectively use the identity mapping to enable the MMU but failed to add
the code required to restore the tcr_el1.t0sz to its default value, when
the core returns to the kernel with the MMU enabled, so that the kernel
might end up running with tcr_el1.t0sz value set-up for the identity
mapping which can be lower than the value required by the actual virtual
address space, resulting in an erroneous set-up.

This patchs adds code in the resume path that restores the tcr_el1.t0sz
default value upon core resume, mirroring this way the cold boot path
behaviour therefore fixing the issue.

Cc: 
Cc: Catalin Marinas 
Fixes: dd006da21646 ("arm64: mm: increase VA range of identity map")
Acked-by: Ard Biesheuvel 
Signed-off-by: Lorenzo Pieralisi 
Signed-off-by: James Morse 
Signed-off-by: Will Deacon

arm64: compat: fix stxr failure case in SWP emulation

2015-10-28T17:06:35+00:00

If the STXR instruction fails in the SWP emulation code, we leave *data
overwritten with the loaded value, therefore corrupting the data written
by a subsequent, successful attempt.

This patch re-jigs the code so that we only write back to *data once we
know that the update has happened.

Cc: 
Fixes: bd35a4adc413 ("arm64: Port SWP/SWPB emulation support from arm")
Reported-by: Shengjiu Wang 
Reported-by: Vladimir Murzin 
Signed-off-by: Will Deacon

ARM: dts: fix gpio-keys wakeup-source property

2015-10-22T16:53:57+00:00

The keyboard driver for GPIO buttons(gpio-keys) checks for one of the
two boolean properties to enable gpio buttons as wakeup source:
1. "wakeup-source" or
2. the legacy "gpio-key,wakeup"

However juno, ste-snowball and emev2-kzm9d dts file have a undetected
"wakeup" property to indictate the wakeup source.

This patch fixes it by making use of "wakeup-source" property.

Cc: Magnus Damm 
Acked-by: Simon Horman 
Reviewed-by: Linus Walleij 
Signed-off-by: Sudeep Holla 
Signed-off-by: Olof Johansson

arm64: compat: wire up new syscalls

2015-10-14T12:51:41+00:00

Commit 208473c1f3ac ("ARM: wire up new syscalls") hooked up the new
userfaultfd and membarrier syscalls for ARM, so do the same for our
compat syscall table in arm64.

Signed-off-by: Will Deacon