- Nov 03, 2015
-
-
Simon Guinot authored
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:
Simon Guinot <simon.guinot@sequanux.org> Acked-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by:
Jacek Anaszewski <j.anaszewski@samsung.com>
-
Simon Guinot authored
This patch adds DT entries for the LEDs found on the Kirkwood-based LaCie boards 2Big and 5Big Network v2. Signed-off-by:
Simon Guinot <simon.guinot@sequanux.org> Acked-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by:
Jacek Anaszewski <j.anaszewski@samsung.com>
-
Ralf Baechle authored
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:
Ralf 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:
Jacek Anaszewski <j.anaszewski@samsung.com>
-
Alexandre Belloni authored
Signed-off-by:
Alexandre Belloni <alexandre.belloni@free-electrons.com> Acked-by:
Hans-Christian Egtvedt <egtvedt@samfundet.no>
-
Guenter Roeck authored
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:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
Jesper Nilsson <jespern@axis.com>
-
Jesper Nilsson authored
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:
Jesper Nilsson <jesper.nilsson@axis.com>
-
Xunlei Pang authored
- 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:
Xunlei Pang <pang.xunlei@linaro.org> Acked-by:
Rabin Vincent <rabin@rab.in> Signed-off-by:
Jesper Nilsson <jespern@axis.com>
-
Andy Shevchenko authored
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:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Jesper Nilsson <jespern@axis.com>
-
Rabin Vincent authored
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:
Rabin Vincent <rabin@rab.in> Signed-off-by:
Jesper Nilsson <jespern@axis.com>
-
Rabin Vincent authored
Now that we have a gpiolib GPIO driver, the generic i2c-gpio driver provides this functionality. Signed-off-by:
Rabin Vincent <rabin@rab.in> Signed-off-by:
Jesper Nilsson <jespern@axis.com>
-
Rabin Vincent authored
Add a device tree for the Axis P1343 with the ARTPEC-3 SoC and on-board LEDs and RTC. Signed-off-by:
Rabin Vincent <rabin@rab.in> Signed-off-by:
Jesper Nilsson <jespern@axis.com>
-
Rabin Vincent authored
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:
Rabin Vincent <rabin@rab.in> Signed-off-by:
Jesper Nilsson <jespern@axis.com>
-
Rabin Vincent authored
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:
Rabin Vincent <rabin@rab.in> Signed-off-by:
Jesper Nilsson <jespern@axis.com>
-
Rabin Vincent authored
Increase NR_IQRS so we can fit in GPIO interrupts. Signed-off-by:
Rabin Vincent <rabin@rab.in> Signed-off-by:
Jesper Nilsson <jespern@axis.com>
-
Chen Gang authored
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:
Chen Gang <gang.chen.5i5j@gmail.com> Signed-off-by:
Jesper Nilsson <jespern@axis.com>
-
Chen Gang authored
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:
Chen Gang <gang.chen.5i5j@gmail.com> Acked-by:
Hans-Peter Nilsson <hp@axis.com> Signed-off-by:
Jesper Nilsson <jespern@axis.com>
-
Andy Shevchenko authored
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:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
Jesper Nilsson <jespern@axis.com>
-
- Nov 01, 2015
-
-
Wan Zongshun authored
AMD Fam17h processors introduce support for the CLZERO instruction. It zeroes out the 64 byte cache line specified in RAX. Add the bit here to allow /proc/cpuinfo to list the feature. Boris: we're adding this as a separate ->x86_capability leaf because CPUID_80000008_EBX is going to contain more feature bits and it will fill out with time. Signed-off-by:
Wan Zongshun <Vincent.Wan@amd.com> Signed-off-by:
Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com> [ Wrap code in patch form, fix comments. ] Signed-off-by:
Borislav Petkov <bp@suse.de> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Huang Rui <ray.huang@amd.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> Link: http://lkml.kernel.org/r/1446207099-24948-4-git-send-email-bp@alien8.de Signed-off-by:
Ingo Molnar <mingo@kernel.org>
-
Borislav Petkov authored
Caught by building with W= which enable -Wswitch-default also. Signed-off-by:
Borislav 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.de Signed-off-by:
Ingo Molnar <mingo@kernel.org>
-
Aravind Gopalakrishnan authored
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:
Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com> [ Reformat mce_vendor_flags definitions and save indentation levels. Improve comments. ] Signed-off-by:
Borislav 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.de Signed-off-by:
Ingo Molnar <mingo@kernel.org>
-
- Oct 31, 2015
-
-
Andy Lutomirski authored
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:
Andy 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.org Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
- Oct 30, 2015
-
-
Ard Biesheuvel authored
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:
Timur Tabi <timur@codeaurora.org> Tested-by:
Timur Tabi <timur@codeaurora.org> Acked-by:
Mark Rutland <mark.rutland@arm.com> Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Will Deacon <will.deacon@arm.com>
-
- Oct 29, 2015
-
-
H. Nikolaus Schaller authored
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:
Efraim Yawitz <efraim.yawitz@gmail.com> Signed-off-by:
H. Nikolaus Schaller <hns@goldelico.com> Fixes: 8a603f91 ("ARM: 8445/1: fix vdsomunge not to depend on glibc specific byteswap.h") Signed-off-by:
Nathan Lynch <nathan_lynch@mentor.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk>
-
Vineet Gupta authored
This is the first working implementation of 40-bit physical address extension on ARCv2. Signed-off-by:
Alexey Brodkin <abrodkin@synopsys.com> Signed-off-by:
Vineet Gupta <vgupta@synopsys.com>
-
Émeric MASCHINO authored
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#c17 Signed-off-by:
Émeric MASCHINO <emeric.maschino@gmail.com> Signed-off-by:
Tony Luck <tony.luck@intel.com>
-
Will Deacon authored
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:
Will Deacon <will.deacon@arm.com>
-
Lorenzo Pieralisi authored
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:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by:
James Morse <james.morse@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com>
-
Will Deacon authored
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:
Shengjiu Wang <shengjiu.wang@freescale.com> Reported-by:
Vladimir Murzin <vladimir.murzin@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com>
-
- Oct 28, 2015
-
-
Vineet Gupta authored
Signed-off-by:
Vineet Gupta <vgupta@synopsys.com>
-
Vineet Gupta authored
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:
Vineet Gupta <vgupta@synopsys.com>
-
Vineet Gupta authored
Signed-off-by:
Vineet Gupta <vgupta@synopsys.com>
-
Vineet Gupta authored
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:
Alexey Brodkin <abrodkin@synopsys.com> Signed-off-by:
Vineet Gupta <vgupta@synopsys.com>
-
Vineet Gupta authored
Explicit'ify that all memory added so far is low memory Nothing semantical Signed-off-by:
Vineet Gupta <vgupta@synopsys.com>
-
Vineet Gupta authored
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:
Alexey Brodkin <abrodkin@synopsys.com> Signed-off-by:
Vineet Gupta <vgupta@synopsys.com>
-
Alexey Brodkin authored
Signed-off-by:
Alexey Brodkin <abrodkin@synopsys.com> Signed-off-by:
Vineet Gupta <vgupta@synopsys.com>
-
Vineet Gupta authored
- 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:
Vineet Gupta <vgupta@synopsys.com>
-
Ard Biesheuvel authored
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:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by:
Matt 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.org Signed-off-by:
Ingo Molnar <mingo@kernel.org>
-
Vineet Gupta authored
Signed-off-by:
Vineet Gupta <vgupta@synopsys.com>
-
Vineet Gupta authored
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:
Vineet Gupta <vgupta@synopsys.com>
-
Vineet Gupta authored
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:
Vineet Gupta <vgupta@synopsys.com>
-