aboutsummaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2016-03-11powerpc32: Remove one insn in mulhduChristophe Leroy1-6/+5
Remove one instruction in mulhdu Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Scott Wood <[email protected]>
2016-03-11powerpc32: small optimisation in flush_icache_range()Christophe Leroy1-3/+2
Inlining of _dcache_range() functions has shown that the compiler does the same thing a bit better with one insn less Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Scott Wood <[email protected]>
2016-03-11powerpc: Simplify test in __dma_sync()Christophe Leroy1-1/+1
This simplification helps the compiler. We now have only one test instead of two, so it reduces the number of branches. Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Scott Wood <[email protected]>
2016-03-11powerpc32: move xxxxx_dcache_range() functions inlineChristophe Leroy3-68/+51
flush/clean/invalidate _dcache_range() functions are all very similar and are quite short. They are mainly used in __dma_sync() perf_event locate them in the top 3 consumming functions during heavy ethernet activity They are good candidate for inlining, as __dma_sync() does almost nothing but calling them Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Scott Wood <[email protected]>
2016-03-11powerpc32: Remove clear_pages() and define clear_page() inlineChristophe Leroy3-20/+14
clear_pages() is never used expect by clear_page, and PPC32 is the only architecture (still) having this function. Neither PPC64 nor any other architecture has it. This patch removes clear_pages() and moves clear_page() function inline (same as PPC64) as it only is a few isns Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Scott Wood <[email protected]>
2016-03-11powerpc: add inline functions for cache related instructionsChristophe Leroy1-0/+19
This patch adds inline functions to use dcbz, dcbi, dcbf, dcbst from C functions Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Scott Wood <[email protected]>
2016-03-11powerpc/8xx: rewrite flush_instruction_cache() in CChristophe Leroy2-6/+11
On PPC8xx, flushing instruction cache is performed by writing in register SPRN_IC_CST. This registers suffers CPU6 ERRATA. The patch rewrites the fonction in C so that CPU6 ERRATA will be handled transparently Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Scott Wood <[email protected]>
2016-03-11powerpc/8xx: rewrite set_context() in CChristophe Leroy2-44/+34
There is no real need to have set_context() in assembly. Now that we have mtspr() handling CPU6 ERRATA directly, we can rewrite set_context() in C language for easier maintenance. Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Scott Wood <[email protected]>
2016-03-11powerpc/8xx: remove special handling of CPU6 errata in set_dec()Christophe Leroy2-23/+1
CPU6 ERRATA is now handled directly in mtspr(), so we can use the standard set_dec() fonction in all cases. Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Scott Wood <[email protected]>
2016-03-11powerpc/8xx: Handle CPU6 ERRATA directly in mtspr() macroChristophe Leroy2-0/+84
MPC8xx has an ERRATA on the use of mtspr() for some registers This patch includes the ERRATA handling directly into mtspr() macro so that mtspr() users don't need to bother about that errata Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Scott Wood <[email protected]>
2016-03-11powerpc/8xx: Add missing SPRN defines into reg_8xx.hChristophe Leroy2-2/+13
Add missing SPRN defines into reg_8xx.h Some of them are defined in mmu-8xx.h, so we include mmu-8xx.h in reg_8xx.h, for that we remove references to PAGE_SHIFT in mmu-8xx.h to have it self sufficient, as includers of reg_8xx.h don't all include asm/page.h Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Scott Wood <[email protected]>
2016-03-11powerpc32: remove ioremap_baseChristophe Leroy4-14/+2
ioremap_base is not initialised and is nowhere used so remove it Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Scott Wood <[email protected]>
2016-03-11powerpc32: Remove useless/wrong MMU:setio progress messageChristophe Leroy1-4/+0
Commit 771168494719 ("[POWERPC] Remove unused machine call outs") removed the call to setup_io_mappings(), so remove the associated progress line message Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Scott Wood <[email protected]>
2016-03-11powerpc32: refactor x_mapped_by_bats() and x_mapped_by_tlbcam() togetherChristophe Leroy4-42/+22
x_mapped_by_bats() and x_mapped_by_tlbcam() serve the same kind of purpose, and are never defined at the same time. So rename them x_block_mapped() and define them in the relevant places Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Scott Wood <[email protected]>
2016-03-11powerpc32: Fix pte_offset_kernel() to return NULL for bad pagesChristophe Leroy1-1/+2
The fixmap related functions try to map kernel pages that are already mapped through Large TLBs. pte_offset_kernel() has to return NULL for LTLBs, otherwise the caller will try to access level 2 table which doesn't exist Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Scott Wood <[email protected]>
2016-03-11powerpc/8xx: move setup_initial_memory_limit() into 8xx_mmu.cChristophe Leroy2-19/+17
Now we have a 8xx specific .c file for that so put it in there as other powerpc variants do Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Scott Wood <[email protected]>
2016-03-11powerpc/8xx: Map linear kernel RAM with 8M pagesChristophe Leroy4-14/+120
On a live running system (VoIP gateway for Air Trafic Control), over a 10 minutes period (with 277s idle), we get 87 millions DTLB misses and approximatly 35 secondes are spent in DTLB handler. This represents 5.8% of the overall time and even 10.8% of the non-idle time. Among those 87 millions DTLB misses, 15% are on user addresses and 85% are on kernel addresses. And within the kernel addresses, 93% are on addresses from the linear address space and only 7% are on addresses from the virtual address space. MPC8xx has no BATs but it has 8Mb page size. This patch implements mapping of kernel RAM using 8Mb pages, on the same model as what is done on the 40x. In 4k pages mode, each PGD entry maps a 4Mb area: we map every two entries to the same 8Mb physical page. In each second entry, we add 4Mb to the page physical address to ease life of the FixupDAR routine. This is just ignored by HW. In 16k pages mode, each PGD entry maps a 64Mb area: each PGD entry will point to the first page of the area. The DTLB handler adds the 3 bits from EPN to map the correct page. With this patch applied, we now get only 13 millions TLB misses during the 10 minutes period. The idle time has increased to 313s and the overall time spent in DTLB miss handler is 6.3s, which represents 1% of the overall time and 2.2% of non-idle time. Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Scott Wood <[email protected]>
2016-03-11powerpc/8xx: Save r3 all the time in DTLB miss handlerChristophe Leroy1-9/+4
We are spending between 40 and 160 cycles with a mean of 65 cycles in the DTLB handling routine (measured with mftbl) so make it more simple althought it adds one instruction. With this modification, we get three registers available at all time, which will help with following patch. Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Scott Wood <[email protected]>
2016-03-11Merge tag 'armsoc-fixes' of ↵Linus Torvalds12-20/+40
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Pull ARM SoC fixes from Olof Johansson: "Two more fixes for 4.5: - One is a fix for OMAP that is urgently needed to avoid DRA7xx chips from premature aging, by always keeping the Ethernet clock enabled. - The other solves a I/O memory layout issue on Armada, where SROM and PCI memory windows were conflicting in some configurations" * tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: ARM: mvebu: fix overlap of Crypto SRAM with PCIe memory window ARM: dts: dra7: do not gate cpsw clock due to errata i877 ARM: OMAP2+: hwmod: Introduce ti,no-idle dt property
2016-03-11ARM: mvebu: fix overlap of Crypto SRAM with PCIe memory windowThomas Petazzoni9-19/+19
When the Crypto SRAM mappings were added to the Device Tree files describing the Armada XP boards in commit c466d997bb16 ("ARM: mvebu: define crypto SRAM ranges for all armada-xp boards"), the fact that those mappings were overlaping with the PCIe memory aperture was overlooked. Due to this, we currently have for all Armada XP platforms a situation that looks like this: Memory mapping on Armada XP boards with internal registers at 0xf1000000: - 0x00000000 -> 0xf0000000 3.75G RAM - 0xf0000000 -> 0xf1000000 16M NOR flashes (AXP GP / AXP DB) - 0xf1000000 -> 0xf1100000 1M internal registers - 0xf8000000 -> 0xffe0000 126M PCIe memory aperture - 0xf8100000 -> 0xf8110000 64KB Crypto SRAM #0 => OVERLAPS WITH PCIE ! - 0xf8110000 -> 0xf8120000 64KB Crypto SRAM #1 => OVERLAPS WITH PCIE ! - 0xffe00000 -> 0xfff00000 1M PCIe I/O aperture - 0xfff0000 -> 0xffffffff 1M BootROM The overlap means that when PCIe devices are added, depending on their memory window needs, they might or might not be mapped into the physical address space. Indeed, they will not be mapped if the area allocated in the PCIe memory aperture by the PCI core overlaps with one of the Crypto SRAM. Typically, a Intel IGB PCIe NIC that needs 8MB of PCIe memory will see its PCIe memory window allocated from 0xf80000000 for 8MB, which overlaps with the Crypto SRAM windows. Due to this, the PCIe window is not created, and any attempt to access the PCIe window makes the kernel explode: [ 3.302213] igb: Copyright (c) 2007-2014 Intel Corporation. [ 3.307841] pci 0000:00:09.0: enabling device (0140 -> 0143) [ 3.313539] mvebu_mbus: cannot add window '4:f8', conflicts with another window [ 3.320870] mvebu-pcie soc:pcie-controller: Could not create MBus window at [mem 0xf8000000-0xf87fffff]: -22 [ 3.330811] Unhandled fault: external abort on non-linefetch (0x1008) at 0xf08c0018 This problem does not occur on Armada 370 boards, because we use the following memory mapping (for boards that have internal registers at 0xf1000000): - 0x00000000 -> 0xf0000000 3.75G RAM - 0xf0000000 -> 0xf1000000 16M NOR flashes (AXP GP / AXP DB) - 0xf1000000 -> 0xf1100000 1M internal registers - 0xf1100000 -> 0xf1110000 64KB Crypto SRAM #0 => OK ! - 0xf8000000 -> 0xffe0000 126M PCIe memory - 0xffe00000 -> 0xfff00000 1M PCIe I/O - 0xfff0000 -> 0xffffffff 1M BootROM Obviously, the solution is to align the location of the Crypto SRAM mappings of Armada XP to be similar with the ones on Armada 370, i.e have them between the "internal registers" area and the beginning of the PCIe aperture. However, we have a special case with the OpenBlocks AX3-4 platform, which has a 128 MB NOR flash. Currently, this NOR flash is mapped from 0xf0000000 to 0xf8000000. This is possible because on OpenBlocks AX3-4, the internal registers are not at 0xf1000000. And this explains why the Crypto SRAM mappings were not configured at the same place on Armada XP. Hence, the solution is two-fold: (1) Move the NOR flash mapping on Armada XP OpenBlocks AX3-4 from 0xe8000000 to 0xf0000000. This frees the 0xf0000000 -> 0xf80000000 space. (2) Move the Crypto SRAM mappings on Armada XP to be similar to Armada 370 (except of course that Armada XP has two Crypto SRAM and not one). After this patch, the memory mapping on Armada XP boards with registers at 0xf1 is: - 0x00000000 -> 0xf0000000 3.75G RAM - 0xf0000000 -> 0xf1000000 16M NOR flashes (AXP GP / AXP DB) - 0xf1000000 -> 0xf1100000 1M internal registers - 0xf1100000 -> 0xf1110000 64KB Crypto SRAM #0 - 0xf1110000 -> 0xf1120000 64KB Crypto SRAM #1 - 0xf8000000 -> 0xffe0000 126M PCIe memory - 0xffe00000 -> 0xfff00000 1M PCIe I/O - 0xfff0000 -> 0xffffffff 1M BootROM And the memory mapping for the special case of the OpenBlocks AX3-4 (internal registers at 0xd0000000, NOR of 128 MB): - 0x00000000 -> 0xc0000000 3G RAM - 0xd0000000 -> 0xd1000000 1M internal registers - 0xe800000 -> 0xf0000000 128M NOR flash - 0xf1100000 -> 0xf1110000 64KB Crypto SRAM #0 - 0xf1110000 -> 0xf1120000 64KB Crypto SRAM #1 - 0xf8000000 -> 0xffe0000 126M PCIe memory - 0xffe00000 -> 0xfff00000 1M PCIe I/O - 0xfff0000 -> 0xffffffff 1M BootROM Fixes: c466d997bb16 ("ARM: mvebu: define crypto SRAM ranges for all armada-xp boards") Reported-by: Phil Sutter <[email protected]> Cc: Phil Sutter <[email protected]> Cc: <[email protected]> Signed-off-by: Thomas Petazzoni <[email protected]> Acked-by: Gregory CLEMENT <[email protected]> Signed-off-by: Olof Johansson <[email protected]>
2016-03-11arm64: kasan: Fix zero shadow mapping overriding kernel image shadowCatalin Marinas1-8/+5
With the 16KB and 64KB page size configurations, SWAPPER_BLOCK_SIZE is PAGE_SIZE and ARM64_SWAPPER_USES_SECTION_MAPS is 0. Since kimg_shadow_end is not page aligned (_end shifted by KASAN_SHADOW_SCALE_SHIFT), the edges of previously mapped kernel image shadow via vmemmap_populate() may be overridden by subsequent calls to kasan_populate_zero_shadow(), leading to kernel panics like below: ------------------------------------------------------------------------------ Unable to handle kernel paging request at virtual address fffffc100135068c pgd = fffffc8009ac0000 [fffffc100135068c] *pgd=00000009ffee0003, *pud=00000009ffee0003, *pmd=00000009ffee0003, *pte=00e0000081a00793 Internal error: Oops: 9600004f [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.5.0-rc4+ #1984 Hardware name: Juno (DT) task: fffffe09001a0000 ti: fffffe0900200000 task.ti: fffffe0900200000 PC is at __memset+0x4c/0x200 LR is at kasan_unpoison_shadow+0x34/0x50 pc : [<fffffc800846f1cc>] lr : [<fffffc800821ff54>] pstate: 00000245 sp : fffffe0900203db0 x29: fffffe0900203db0 x28: 0000000000000000 x27: 0000000000000000 x26: 0000000000000000 x25: fffffc80099b69d0 x24: 0000000000000001 x23: 0000000000000000 x22: 0000000000002000 x21: dffffc8000000000 x20: 1fffff9001350a8c x19: 0000000000002000 x18: 0000000000000008 x17: 0000000000000147 x16: ffffffffffffffff x15: 79746972100e041d x14: ffffff0000000000 x13: ffff000000000000 x12: 0000000000000000 x11: 0101010101010101 x10: 1fffffc11c000000 x9 : 0000000000000000 x8 : fffffc100135068c x7 : 0000000000000000 x6 : 000000000000003f x5 : 0000000000000040 x4 : 0000000000000004 x3 : fffffc100134f651 x2 : 0000000000000400 x1 : 0000000000000000 x0 : fffffc100135068c Process swapper/0 (pid: 1, stack limit = 0xfffffe0900200020) Call trace: [<fffffc800846f1cc>] __memset+0x4c/0x200 [<fffffc8008220044>] __asan_register_globals+0x5c/0xb0 [<fffffc8008a09d34>] _GLOBAL__sub_I_65535_1_sunrpc_cache_lookup+0x1c/0x28 [<fffffc8008f20d28>] kernel_init_freeable+0x104/0x274 [<fffffc80089e1948>] kernel_init+0x10/0xf8 [<fffffc8008093a00>] ret_from_fork+0x10/0x50 ------------------------------------------------------------------------------ This patch aligns kimg_shadow_start and kimg_shadow_end to SWAPPER_BLOCK_SIZE in all configurations. Fixes: f9040773b7bb ("arm64: move kernel image to base of vmalloc area") Signed-off-by: Catalin Marinas <[email protected]> Acked-by: Mark Rutland <[email protected]> Acked-by: Ard Biesheuvel <[email protected]>
2016-03-11arm64: kasan: Use actual memory node when populating the kernel image shadowCatalin Marinas1-1/+2
With the 16KB or 64KB page configurations, the generic vmemmap_populate() implementation warns on potential offnode page_structs via vmemmap_verify() because the arm64 kasan_init() passes NUMA_NO_NODE instead of the actual node for the kernel image memory. Fixes: f9040773b7bb ("arm64: move kernel image to base of vmalloc area") Signed-off-by: Catalin Marinas <[email protected]> Reported-by: James Morse <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Acked-by: Mark Rutland <[email protected]>
2016-03-11arm64: Update PTE_RDONLY in set_pte_at() for PROT_NONE permissionCatalin Marinas1-1/+2
The set_pte_at() function must update the hardware PTE_RDONLY bit depending on the state of the PTE_WRITE and PTE_DIRTY bits of the given entry value. However, it currently only performs this for pte_valid() entries, ignoring PTE_PROT_NONE. The side-effect is that PROT_NONE mappings would not have the PTE_RDONLY bit set. Without CONFIG_ARM64_HW_AFDBM, this is not an issue since such PROT_NONE pages are not accessible anyway. With commit 2f4b829c625e ("arm64: Add support for hardware updates of the access and dirty pte bits"), the ptep_set_wrprotect() function was re-written to cope with automatic hardware updates of the dirty state. As an optimisation, only PTE_RDONLY is checked to assess the "dirty" status. Since set_pte_at() does not set this bit for PROT_NONE mappings, such pages may be considered "dirty" as a result of ptep_set_wrprotect(). This patch updates the pte_valid() check to pte_present() in set_pte_at(). It also adds PTE_PROT_NONE to the swap entry bits comment. Fixes: 2f4b829c625e ("arm64: Add support for hardware updates of the access and dirty pte bits") Signed-off-by: Catalin Marinas <[email protected]> Reported-by: Ganapatrao Kulkarni <[email protected]> Tested-by: Ganapatrao Kulkarni <[email protected]> Cc: <[email protected]>
2016-03-11ARC: [*defconfig] No need to specify CONFIG_CROSS_COMPILEVineet Gupta12-12/+0
The problem is with CONFIG_CPU_BIG_ENDIAN=y we still needed .config fixup to override the the defconfig prefix to arceb-linux- So remove these from defconfig and let user pass this via CROSS_COMPILE environment var or use the default for ENDIAN (per previous patch) No other arch carries them in defconfigs anyways ! Cc: Noam Camus <[email protected]> Cc: Alexey Brodkin <[email protected]> Cc: Anton Kolesov <[email protected]> Signed-off-by: Vineet Gupta <[email protected]>
2016-03-11ARC: [BE] Select correct CROSS_COMPILE prefixVineet Gupta1-0/+4
This allows CONFIG_CPU_BIG_ENDIAN=y to build correctly out of the box, w/o any other tweaks. Cc: Noam Camus <[email protected]> Cc: Alexey Brodkin <[email protected]> Cc: Anton Kolesov <[email protected]> Signed-off-by: Vineet Gupta <[email protected]>
2016-03-11ARC: bitops: Remove non relevant commentsVineet Gupta1-15/+0
commit 80f420842ff42 removed the ARC bitops microoptimization but failed to prune the comments to same effect Fixes: 80f420842ff42 ("ARC: Make ARC bitops "safer" (add anti-optimization)") Signed-off-by: Vineet Gupta <[email protected]>
2016-03-11ARC: Fix misspellings in comments.Adam Buchbinder8-12/+12
Signed-off-by: Adam Buchbinder <[email protected]> Signed-off-by: Vineet Gupta <[email protected]>
2016-03-11x86/mm/pkeys: Fix mismerge of protection keys CPUID bitsDave Hansen2-4/+4
Kirill Shutemov pointed this out to me. The tip tree currently has commit: dfb4a70f2 [x86/cpufeature, x86/mm/pkeys: Add protection keys related CPUID definitions] whioch added support for two new CPUID bits: X86_FEATURE_PKU and X86_FEATURE_OSPKE. But, those bits were mis-merged and put in cpufeature.h instead of cpufeatures.h. This didn't cause any breakage *except* it keeps the "ospke" and "pku" bits from showing up in cpuinfo. Now cpuinfo has the two new flags: flags : ... pku ospke BTW, is it really wise to have cpufeature.h and cpufeatures.h? It seems like they can only cause confusion and mahem with tab completion. Reported-by: Kirill A. Shutemov <[email protected]> Signed-off-by: Dave Hansen <[email protected]> Acked-by: Borislav Petkov <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Dave Hansen <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2016-03-11xtensa: support hardware breakpoints/watchpointsMax Filippov15-13/+649
Use perf framework to manage hardware instruction and data breakpoints. Add two new ptrace calls: PTRACE_GETHBPREGS and PTRACE_SETHBPREGS to query and set instruction and data breakpoints. Address bit 0 choose instruction (0) or data (1) break register, bits 31..1 are the register number. Both calls transfer two 32-bit words: address (0) and control (1). Instruction breakpoint contorl word is 0 to clear breakpoint, 1 to set. Data breakpoint control word bit 31 is 'trigger on store', bit 30 is 'trigger on load, bits 29..0 are length. Length 0 is used to clear a breakpoint. To set a breakpoint length must be a power of 2 in the range 1..64 and the address must be length-aligned. Introduce new thread_info flag: TIF_DB_DISABLED. Set it if debug exception is raised by the kernel code accessing watched userspace address and disable corresponding data breakpoint. On exit to userspace check that flag and, if set, restore all data breakpoints. Handle debug exceptions raised with PS.EXCM set. This may happen when window overflow/underflow handler or fast exception handler hits data breakpoint, in which case save and disable all data breakpoints, single-step faulting instruction and restore data breakpoints. Signed-off-by: Max Filippov <[email protected]>
2016-03-11xtensa: use context structure for debug exceptionsMax Filippov6-18/+39
With implementation of data breakpoints debug exceptions raised when PS.EXCM is set need to be handled, e.g. window overflow code can write to watched userspace address. Currently debug exception handler uses EXCSAVE and DEPC SRs to save temporary registers, but DEPC may not be available when PS.EXCM is set and more space will be needed to save additional state. Reorganize debug context: create per-CPU structure debug_table instance and store its address in the EXCSAVE<debug level> instead of debug_exception function address. Expand this structure when more save space is needed. Signed-off-by: Max Filippov <[email protected]>
2016-03-11xtensa: remove remaining non-functional KGDB bitsMax Filippov2-20/+0
KGDB is not supported on xtensa, but there are bits of related code under arch/xtensa/kernel. Remove these bits. Signed-off-by: Max Filippov <[email protected]>
2016-03-11xtensa: clear all DBREAKC registers on startMax Filippov1-1/+1
There are XCHAL_NUM_DBREAK registers, clear them all. This also fixes cryptic assembler error message with binutils 2.25 when XCHAL_NUM_DBREAK is 0: as: out of memory allocating 18446744073709551575 bytes after a total of 495616 bytes Cc: [email protected] Signed-off-by: Max Filippov <[email protected]>
2016-03-11xtensa: xtfpga: fix earlycon endiannessMax Filippov2-2/+2
Serial port is attached to XTFPGA boards as native endian device, now that earlycon parameter parser understands mmio32native put it into earlycon kernel parameter. This makes early console functional on both little- and big-endian CPUs with identical kernel command lines. Signed-off-by: Max Filippov <[email protected]>
2016-03-11xtensa: xtfpga: fix i2c controller register width and endiannessMax Filippov1-1/+2
I2C controller is attached to XTFPGA boards as native endian device, mark it as such in DTS. Set register width in DTS to 4, this way it works both for little- and big-endian CPUs. Signed-off-by: Max Filippov <[email protected]>
2016-03-11xtensa: xtfpga: fix ethernet controller endiannessMax Filippov2-0/+2
Ethernet controller is attached to XTFPGA boards as native endian device, mark it as such in DTS and pass correct endianness in platform data. This makes network functional on big-endian CPUs. Signed-off-by: Max Filippov <[email protected]>
2016-03-11xtensa: xtfpga: fix serial port register width and endiannessMax Filippov2-1/+3
Serial port is attached to XTFPGA boards as native endian device, mark it as such in DTS and pass correct endianness in platform data. Set register width in DTS to 4, this way it matches the platform data and works correctly on big-endian CPUs. Signed-off-by: Max Filippov <[email protected]>
2016-03-11xtensa: define CONFIG_CPU_{BIG,LITTLE}_ENDIANMax Filippov1-0/+2
Query compiler for the CPU endianness and add corresponding definition to KBUILD_CPPFLAGS. This allows using 'native-endian' property in DTS. Signed-off-by: Max Filippov <[email protected]>
2016-03-11xtensa: fix preemption in {clear,copy}_user_highpageMax Filippov1-4/+4
Disabling pagefault makes little sense there, preemption disabling is what was meant. Cc: [email protected] Signed-off-by: Max Filippov <[email protected]>
2016-03-11xtensa: ISS: don't hang if stdin EOF is reachedMax Filippov1-4/+6
Simulator stdin may be connected to a file, when its end is reached kernel hangs in infinite loop inside rs_poll, because simc_poll always signals that descriptor 0 is readable and simc_read always returns 0. Check simc_read return value and exit loop if it's not positive. Also don't rewind polling timer if it's zero. Cc: [email protected] Signed-off-by: Max Filippov <[email protected]>
2016-03-11x86/mm/32: Enable full randomization on i386 and X86_32Hector Marco-Gisbert1-13/+1
Currently on i386 and on X86_64 when emulating X86_32 in legacy mode, only the stack and the executable are randomized but not other mmapped files (libraries, vDSO, etc.). This patch enables randomization for the libraries, vDSO and mmap requests on i386 and in X86_32 in legacy mode. By default on i386 there are 8 bits for the randomization of the libraries, vDSO and mmaps which only uses 1MB of VA. This patch preserves the original randomness, using 1MB of VA out of 3GB or 4GB. We think that 1MB out of 3GB is not a big cost for having the ASLR. The first obvious security benefit is that all objects are randomized (not only the stack and the executable) in legacy mode which highly increases the ASLR effectiveness, otherwise the attackers may use these non-randomized areas. But also sensitive setuid/setgid applications are more secure because currently, attackers can disable the randomization of these applications by setting the ulimit stack to "unlimited". This is a very old and widely known trick to disable the ASLR in i386 which has been allowed for too long. Another trick used to disable the ASLR was to set the ADDR_NO_RANDOMIZE personality flag, but fortunately this doesn't work on setuid/setgid applications because there is security checks which clear Security-relevant flags. This patch always randomizes the mmap_legacy_base address, removing the possibility to disable the ASLR by setting the stack to "unlimited". Signed-off-by: Hector Marco-Gisbert <[email protected]> Acked-by: Ismael Ripoll Ripoll <[email protected]> Acked-by: Kees Cook <[email protected]> Acked-by: Arjan van de Ven <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Cc: kees Cook <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2016-03-11Merge branch 'topic/mprofile-kernel' into nextMichael Ellerman16-127/+546
Merge the ftrace changes to support -mprofile-kernel on ppc64le. This is a prerequisite for live patching, the support for which will be merged via the livepatch tree based on this topic branch.
2016-03-10x86/PCI: VMD: Attach VMD resources to parent domain's resource treeJon Derrick1-0/+16
Attach the new VMD domain's resources to the VMD device's resources. This allows /proc/iomem to display a more complete picture. Before: c0000000-c1ffffff : 0000:5d:05.5 c2000000-c3ffffff : 0000:5d:05.5 c2010000-c2013fff : nvme c4000000-c40fffff : 0000:5d:05.5 After: c0000000-c1ffffff : 0000:5d:05.5 c2000000-c3ffffff : 0000:5d:05.5 c2000000-c3ffffff : VMD MEMBAR1 c2000000-c22fffff : PCI Bus 10000:01 c2000000-c200ffff : 10000:01:00.0 c2010000-c2013fff : 10000:01:00.0 c2010000-c2013fff : nvme c2300000-c24fffff : PCI Bus 10000:01 c4000000-c40fffff : 0000:5d:05.5 c4002000-c40fffff : VMD MEMBAR2 Signed-off-by: Jon Derrick <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Keith Busch <[email protected]>
2016-03-10x86/PCI: VMD: Set bus resource start to 0Keith Busch1-1/+1
The bus always starts at 0. Due to alignment and down-casting, this happened to work before, but looked alarmingly incorrect in kernel logs. Signed-off-by: Keith Busch <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
2016-03-10x86/PCI: VMD: Document code for maintainabilityKeith Busch1-0/+17
Comment the less obvious portion of the code for setting up memory windows, and the platform dependency for initializing the h/w with appropriate resources. Signed-off-by: Keith Busch <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
2016-03-10ARC: Add PCI supportJoao Pinto7-0/+92
Add PCI support to ARC and update drivers/pci Makefile enabling the ARC arch to use the generic PCI setup functions. [bhelgaas: fold in Joao's pci-dma-compat.h & pci-bridge.h build fix (I should have caught this myself, sorry] Signed-off-by: Joao Pinto <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Acked-by: Vineet Gupta <[email protected]>
2016-03-10Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds4-15/+48
Pull KVM fixes from Paolo Bonzini: "A few simple fixes for ARM, x86, PPC and generic code. The x86 MMU fix is a bit larger because the surrounding code needed a cleanup, but nothing worrisome" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: KVM: MMU: fix reserved bit check for ept=0/CR0.WP=0/CR4.SMEP=1/EFER.NX=0 KVM: MMU: fix ept=0/pte.u=1/pte.w=0/CR0.WP=0/CR4.SMEP=1/EFER.NX=0 combo kvm: cap halt polling at exactly halt_poll_ns KVM: s390: correct fprs on SIGP (STOP AND) STORE STATUS KVM: VMX: disable PEBS before a guest entry KVM: PPC: Book3S HV: Sanitize special-purpose register values on guest exit
2016-03-10Merge tag 'arm64-fixes' of ↵Linus Torvalds2-16/+3
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fixes from Will Deacon: "I thought we were done for 4.5, but then the 64k-page chaps came crawling out of the woodwork. *sigh* The vmemmap fix I sent for -rc7 caused a regression with 64k pages and sparsemem and at some point during the release cycle the new hugetlb code using contiguous ptes started failing the libhugetlbfs tests with 64k pages enabled. So here are a couple of patches that fix the vmemmap alignment and disable the new hugetlb page sizes whilst a proper fix is being developed: - Temporarily disable huge pages built using contiguous ptes - Ensure vmemmap region is sufficiently aligned for sparsemem sections" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: hugetlb: partial revert of 66b3923a1a0f arm64: account for sparsemem section alignment when choosing vmemmap offset
2016-03-10Merge branch 'for-linus' of ↵Linus Torvalds3-11/+31
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 fixes from Martin Schwidefsky: "Three bug fixes: - The fix for the page table corruption (CVE-2016-2143) - The diagnose statistics introduced a regression for the dasd diag driver - Boot crash on systems without the set-program-parameters facility" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/mm: four page table levels vs. fork s390/cpumf: Fix lpp detection s390/dasd: fix diag 0x250 inline assembly
2016-03-10x86/entry/traps: Show unhandled signal for i386 in do_trap()Jianyu Zhan1-2/+0
Commit abd4f7505baf ("x86: i386-show-unhandled-signals-v3") did turn on the showing-unhandled-signal behaviour for i386 for some exception handlers, but for no reason do_trap() is left out (my naive guess is because turning it on for do_trap() would be too noisy since do_trap() is shared by several exceptions). And since the same commit make "show_unhandled_signals" a debug tunable(in /proc/sys/debug/exception-trace), and x86 by default turning it on. So it would be strange for i386 users who turing it on manually and expect seeing the unhandled signal output in log, but nothing. This patch turns it on for i386 in do_trap() as well. Signed-off-by: Jianyu Zhan <[email protected]> Reviewed-by: Jan Beulich <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Brian Gerst <[email protected]> Cc: Denys Vlasenko <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2016-03-10Merge tag 'kvm-s390-next-4.6-2' of ↵Paolo Bonzini6-71/+209
git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into HEAD KVM: s390: Fixes and features for kvm/next (4.6) part 2 - add watchdog diagnose to trace event decoder - better handle the cpu timer when not inside the guest - only provide STFLE if the CPU model has STFLE - reduce DMA page usage
Powered by cgit, Gruvboxed by Blaster4385.