Since DT support is now available for the LEDs found on the LaCie
netxbig boards (Kirkwood-based), then the old-fashion netxbig board
setup file is no longer needed. This patch removes this file.
Signed-off-by: NSimon Guinot <simon.guinot@sequanux.org>
Acked-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

This patch adds DT entries for the LEDs found on the Kirkwood-based
LaCie boards 2Big and 5Big Network v2.
Signed-off-by: NSimon Guinot <simon.guinot@sequanux.org>
Acked-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

Fixes the following randconfig problem

leds-sead3.c:(.text+0x7dc): undefined reference to `led_classdev_unregister'
leds-sead3.c:(.text+0x7e8): undefined reference to `led_classdev_unregister'
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
Cc: Bryan Wu <cooloney@gmail.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Markos Chandras <markos.chandras@imgtec.com>
Cc: linux-leds@vger.kernel.org
Cc: linux-mips@linux-mips.org
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: NHans-Christian Egtvedt <egtvedt@samfundet.no>

Function get_cmos_time() was removed with commit 657926a83df9 ("cris:
time: Cleanup of persistent clock stuff"). The remaining reference to
it may cause the following build error.

arch/cris/kernel/built-in.o:(___ksymtab+get_cmos_time+0x0):
	undefined reference to `get_cmos_time'
Makefile:946: recipe for target 'vmlinux' failed

Fixes: 657926a83df9 ("cris: time: Cleanup of persistent clock stuff")
Cc: Xunlei Pang <pang.xunlei@linaro.org>
Cc: Rabin Vincent <rabin@rab.in>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NJesper Nilsson <jespern@axis.com>

Drop all code related to Kconfigs that don't exist.
Fix one Kconfig where it was actually typo:ed (ETRAX_KGB_PORT2)
Drop content related to CRIS v32 SoCs from etraxgpio.h headerfile,
all use of GPIO for both ETRAX FS and ARTPEC-3 should now be through
standard gpiolib instead.
Signed-off-by: NJesper Nilsson <jesper.nilsson@axis.com>

- Remove update_persistent_clock(), as it does nothing now.
- Remove read_persistent_clock(), let it fall back to the weak version.

Cc: Mikael Starvik <starvik@axis.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: NXunlei Pang <pang.xunlei@linaro.org>
Acked-by: NRabin Vincent <rabin@rab.in>
Signed-off-by: NJesper Nilsson <jespern@axis.com>

There are native helpers such as print_hex_byte() and %*ph specifier to dump
data in hex format. Re-use them instead of a custom approach.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NJesper Nilsson <jespern@axis.com>

Since we now have a gpiolib driver, remove this code:

The gpio-etraxfs driver (along with things like gpio-keys-polled for
polling support) replaces the GIO driver implementations in mach-a3 and
mach-fs.  The various generic external chip drivers replace the "virtual
gpio" parts.

The generic gpio-leds driver replaces the LED handling.
Signed-off-by: NRabin Vincent <rabin@rab.in>
Signed-off-by: NJesper Nilsson <jespern@axis.com>

Now that we have a gpiolib GPIO driver, the generic i2c-gpio driver
provides this functionality.
Signed-off-by: NRabin Vincent <rabin@rab.in>
Signed-off-by: NJesper Nilsson <jespern@axis.com>

Add a device tree for the Axis P1343 with the ARTPEC-3 SoC and on-board
LEDs and RTC.
Signed-off-by: NRabin Vincent <rabin@rab.in>
Signed-off-by: NJesper Nilsson <jespern@axis.com>

Add the GPIO driver to the device tree and, using it, support for the
LEDs and the RTC chip (via I2C-GPIO), as well as the temperature sensor
(via SPI-GPIO).
Signed-off-by: NRabin Vincent <rabin@rab.in>
Signed-off-by: NJesper Nilsson <jespern@axis.com>

Add a dt-bindings symlink to get DT include files, as on other
architectures.  See c58299aa ("kbuild: create an "include chroot" for DT
bindings") for the details.
Signed-off-by: NRabin Vincent <rabin@rab.in>
Signed-off-by: NJesper Nilsson <jespern@axis.com>

Increase NR_IQRS so we can fit in GPIO interrupts.
Signed-off-by: NRabin Vincent <rabin@rab.in>
Signed-off-by: NJesper Nilsson <jespern@axis.com>

Within one C file, current gcc can optimize the global static variables
according to the C code, but it will skip assembly code -- it will pass
them to gas directly.

if the static variable is used between C code and assembly code in one C
file (e.g. is_dyn_brkp in kgdb.c), it needs '__used' to let gcc know it
should be still used, or gcc may remove it for optimization.

The related error in this case:

    LD      init/built-in.o
  arch/cris/arch-v10/kernel/built-in.o: In function `kgdb_handle_breakpoint':
  (.text+0x2aca): undefined reference to `is_dyn_brkp'
  arch/cris/arch-v10/kernel/built-in.o: In function `is_static':
  kgdb.c:(.text+0x2ada): undefined reference to `is_dyn_brkp'
Signed-off-by: NChen Gang <gang.chen.5i5j@gmail.com>
Signed-off-by: NJesper Nilsson <jespern@axis.com>

For arch-v10, there is no DTP0 register, and at present, assembler know
BAR, so use BAR instead of DTP0, the related error (with allmodconfig):

    CC      arch/cris/arch-v10/kernel/kgdb.o
  {standard input}: Assembler messages:
  {standard input}:6: Error: Illegal operands
  {standard input}:6: Error: Illegal operands
Signed-off-by: NChen Gang <gang.chen.5i5j@gmail.com>
Acked-by: NHans-Peter Nilsson <hp@axis.com>
Signed-off-by: NJesper Nilsson <jespern@axis.com>

There are kernel native helpers to convert hex ascii to the binary format:
hex_to_bin() and hex2bin(). Thus, no need to reimplement them customly.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NJesper Nilsson <jespern@axis.com>

Caught by building with W= which enable -Wswitch-default also.
Signed-off-by: NBorislav Petkov <bp@suse.de>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Link: http://lkml.kernel.org/r/1446207099-24948-3-git-send-email-bp@alien8.deSigned-off-by: NIngo Molnar <mingo@kernel.org>

Scalable MCA (SMCA) is a new feature in AMD Fam17h processors
which indicates presence of MCA extensions.

MCA extensions expands existing register space for the MCE banks
and also introduces a new MSR range to accommodate new banks.

Add the detection bit.
Signed-off-by: NAravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>
[ Reformat mce_vendor_flags definitions and save indentation levels. Improve comments. ]
Signed-off-by: NBorislav Petkov <bp@suse.de>
Cc: Ashok Raj <ashok.raj@intel.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Link: http://lkml.kernel.org/r/1446207099-24948-2-git-send-email-bp@alien8.deSigned-off-by: NIngo Molnar <mingo@kernel.org>

thread.vm86 points to per-task information -- the pointer should not
be copied on clone.

Fixes: d4ce0f26 ("x86/vm86: Move fields from 'struct kernel_vm86_struct' to 'struct vm86'")
Signed-off-by: NAndy Lutomirski <luto@kernel.org>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Stas Sergeev <stsp@list.ru>
Link: http://lkml.kernel.org/r/71c5d6985d70ec8197c8d72f003823c81b7dcf99.1446270067.git.luto@kernel.orgSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

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: e38457c3 ("arm64: efi: prefer AllocatePages() over efi_low_alloc() for vmlinux")
Reported-by: NTimur Tabi <timur@codeaurora.org>
Tested-by: NTimur Tabi <timur@codeaurora.org>
Acked-by: NMark Rutland <mark.rutland@arm.com>
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NWill Deacon <will.deacon@arm.com>

Commit 8a603f91 ("ARM: 8445/1: fix vdsomunge not to depend on
glibc specific byteswap.h") unfortunately introduced a bug created but
not found during discussion and patch simplification.
Reported-by: NEfraim Yawitz <efraim.yawitz@gmail.com>
Signed-off-by: NH. Nikolaus Schaller <hns@goldelico.com>
Fixes: 8a603f91 ("ARM: 8445/1: fix vdsomunge not to depend on glibc specific byteswap.h")
Signed-off-by: NNathan Lynch <nathan_lynch@mentor.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This is the first working implementation of 40-bit physical address
extension on ARCv2.
Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

systemd > 218 fails to compile on ia64 with:

     error: ‘__NR_kcmp’ undeclared [1].

I've been told that this is because the kcmp syscall hasn't been wired up
for the ia64 arch [2].

The proposed patch thus wire up the kcmp syscall for the ia64 arch.

[1] https://bugs.gentoo.org/show_bug.cgi?id=560492
[2] https://bugs.gentoo.org/show_bug.cgi?id=560492#c17Signed-off-by: NÉmeric MASCHINO <emeric.maschino@gmail.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

This reverts commit e306dfd0.

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: <stable@vger.kernel.org>
Signed-off-by: NWill Deacon <will.deacon@arm.com>

Commit dd006da2 ("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 dd006da2 ("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: <stable@vger.kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Fixes: dd006da2 ("arm64: mm: increase VA range of identity map")
Acked-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NJames Morse <james.morse@arm.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>

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: <stable@vger.kernel.org>
Fixes: bd35a4ad ("arm64: Port SWP/SWPB emulation support from arm")
Reported-by: NShengjiu Wang <shengjiu.wang@freescale.com>
Reported-by: NVladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>

Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

That way a single flip of phys_addr_t to 64 bit ensures all places
dealing with physical addresses get correct data
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

Implement kmap* API for ARC.

This enables
 - permanent kernel maps (pkmaps): :kmap() API
 - fixmap : kmap_atomic()

We use a very simple/uniform approach for both (unlike some of the other
arches). So fixmap doesn't use the customary compile time address stuff.
The important semantic is sleep'ability (pkmap) vs. not (fixmap) which
the API guarantees.

Note that this patch only enables highmem for subsequent PAE40 support
as there is no real highmem for ARC in pure 32-bit paradigm as explained
below.

ARC has 2:2 address split of the 32-bit address space with lower half
being translated (virtual) while upper half unstranslated
(0x8000_0000 to 0xFFFF_FFFF). kernel itself is linked at base of
unstranslated space (i.e. 0x8000_0000 onwards), which is mapped to say
DDR 0x0 by external Bus Glue logic (outside the core). So kernel can
potentially access 1.75G worth of memory directly w/o need for highmem.
(the top 256M is taken by uncached peripheral space from 0xF000_0000 to
0xFFFF_FFFF)

In PAE40, hardware can address memory beyond 4G (0x1_0000_0000) while
the logical/virtual addresses remain 32-bits. Thus highmem is required
for kernel proper to be able to access these pages for it's own purposes
(user space is agnostic to this anyways).
Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

Explicit'ify that all memory added so far is low memory
Nothing semantical
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

Before we plug in highmem support, some of code needs to be ready for it
 - copy_user_highpage() needs to be using the kmap_atomic API
 - mk_pte() can't assume page_address()
 - do_page_fault() can't assume VMALLOC_END is end of kernel vaddr space
Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

 - Move the verbosity knob from .data to .bss by using inverted logic
 - No need to readout PD1 descriptor
 - clip the non pfn bits of PD0 to avoid clipping inside the loop
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

We have been getting away with using a void* for the physical
address of the UEFI memory map, since, even on 32-bit platforms
with 64-bit physical addresses, no truncation takes place if the
memory map has been allocated by the firmware (which only uses
1:1 virtually addressable memory), which is usually the case.

However, commit:

  0f96a99d ("efi: Add "efi_fake_mem" boot option")

adds code that clones and modifies the UEFI memory map, and the
clone may live above 4 GB on 32-bit platforms.

This means our use of void* for struct efi_memory_map::phys_map has
graduated from 'incorrect but working' to 'incorrect and
broken', and we need to fix it.

So redefine struct efi_memory_map::phys_map as phys_addr_t, and
get rid of a bunch of casts that are now unneeded.
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: NMatt Fleming <matt@codeblueprint.co.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: izumi.taku@jp.fujitsu.com
Cc: kamezawa.hiroyu@jp.fujitsu.com
Cc: linux-efi@vger.kernel.org
Cc: matt.fleming@intel.com
Link: http://lkml.kernel.org/r/1445593697-1342-1-git-send-email-ard.biesheuvel@linaro.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>

Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

With prev fixes, all cores now start via common entry point @stext which
already calls EARLY_CPU_SETUP for all cores - so no need to invoke it
again
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

MCIP now registers it's own per cpu setup routine (for IPI IRQ request)
using smp_ops.init_irq_cpu().

So no need for platforms to do that. This now completely decouples
platforms from MCIP.
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

Note this is not part of platform owned static machine_desc,
but more of device owned plat_smp_ops (rather misnamed) which a IPI
provider or some such typically defines.

This will help us seperate out the IPI registration from platform
specific init_cpu_smp() into device specific init_irq_cpu()
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>