- 04 8月, 2015 2 次提交
-
-
由 Vineet Gupta 提交于
Extended testing of quad core configuration revealed that this fix was insufficient. Specifically LTP open posix shm_op/23-1 would cause the hardware livelock in llock/scond loop in update_cpu_load_active() So remove this and make way for a proper workaround This reverts commit a5c8b52a. Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
-
由 Vineet Gupta 提交于
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
-
- 03 8月, 2015 1 次提交
-
-
由 Vineet Gupta 提交于
With HS 2.1 release, the peripheral space register no longer contains the uncached space specifics, causing the kernel to panic early on. So read the newer NON VOLATILE AUX register to get that info. Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
-
- 23 7月, 2015 1 次提交
-
-
由 Alexey Brodkin 提交于
MMUv4 also supports the configurable page size as MMUv3. Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com> Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
-
- 20 7月, 2015 4 次提交
-
-
由 Vineet Gupta 提交于
There are configurations which may not have LDD/STD Signed-off-by: NClaudiu Zissulescu <claziss@synopsys.com> Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com> Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
-
由 Vineet Gupta 提交于
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
-
由 Alexey Brodkin 提交于
Being highly configurable core ARC HS among other features might be configured with or without DIV_REM_OPTION (hardware divider). That option when enabled adds following instructions: div, divu, rem, remu. By default ARC HS38 has this option enabled. So we add here possibility to disable usage of hardware divider by compiler. Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com> Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
-
由 Viresh Kumar 提交于
Migrate arc driver to the new 'set-state' interface provided by clockevents core, the earlier 'set-mode' interface is marked obsolete now. This also enables us to implement callbacks for new states of clockevent devices, for example: ONESHOT_STOPPED. Cc: Vineet Gupta <vgupta@synopsys.com> Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org> Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
-
- 19 7月, 2015 2 次提交
-
-
由 Markos Chandras 提交于
Commit 6134d949 ("MIPS: asm: fpu: Allow 64-bit FPU on MIPS32 R6") added support for 64-bit FPU on a 32-bit MIPS R6 processor but it missed the 64-bit CPU case leading to FPU failures when requesting FR=1 mode (which is always the case for MIPS R6 userland) when running a 32-bit kernel on a 64-bit CPU. We also fix the MIPS R2 case. Signed-off-by: NMarkos Chandras <markos.chandras@imgtec.com> Fixes: 6134d949 ("MIPS: asm: fpu: Allow 64-bit FPU on MIPS32 R6") Reviewed-by: NPaul Burton <paul.burton@imgtec.com> Cc: <stable@vger.kernel.org> # 4.0+ Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/10734/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Christophe Jaillet 提交于
Commit 0e0da48d ("parisc: mm: don't count preallocated pmds") introduced a memory leak. After this commit, the 'return' statement in pmd_free is executed in all cases. Even for pmd that are not attached to the pgd. So 'free_pages' can never be called anymore, leading to a memory leak. Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com> Acked-by: NMikulas Patocka <mpatocka@redhat.com> Acked-by: NHelge Deller <deller@gmx.de> Cc: stable@vger.kernel.org # v4.0+ Signed-off-by: NHelge Deller <deller@gmx.de>
-
- 18 7月, 2015 8 次提交
-
-
由 Ingo Molnar 提交于
Don't burden architectures without dynamic task_struct sizing with the overhead of dynamic sizing. Also optimize the x86 code a bit by caching task_struct_size. Acked-and-Tested-by: NDave Hansen <dave.hansen@linux.intel.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Dave Hansen <dave@sr71.net> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/1437128892-9831-3-git-send-email-mingo@kernel.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Dave Hansen 提交于
The FPU rewrite removed the dynamic allocations of 'struct fpu'. But, this potentially wastes massive amounts of memory (2k per task on systems that do not have AVX-512 for instance). Instead of having a separate slab, this patch just appends the space that we need to the 'task_struct' which we dynamically allocate already. This saves from doing an extra slab allocation at fork(). The only real downside here is that we have to stick everything and the end of the task_struct. But, I think the BUILD_BUG_ON()s I stuck in there should keep that from being too fragile. Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Dave Hansen <dave@sr71.net> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/1437128892-9831-2-git-send-email-mingo@kernel.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Laurent Dufour 提交于
Commit 2ae416b1 ("mm: new mm hook framework") introduced an empty header file (mm-arch-hooks.h) for every architecture, even those which doesn't need to define mm hooks. As suggested by Geert Uytterhoeven, this could be cleaned through the use of a generic header file included via each per architecture asm/include/Kbuild file. The PowerPC architecture is not impacted here since this architecture has to defined the arch_remap MM hook. Signed-off-by: NLaurent Dufour <ldufour@linux.vnet.ibm.com> Suggested-by: NGeert Uytterhoeven <geert@linux-m68k.org> Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org> Acked-by: NVineet Gupta <vgupta@synopsys.com> Cc: Oleg Nesterov <oleg@redhat.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Viresh Kumar 提交于
Switch to my kernel.org alias instead of a badly named gmail address, which I rarely use. Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Dominik Dingel 提交于
On s390 we only can enable hugepages if the underlying hardware/hypervisor also does support this. Common code now would assume this to be signaled by setting HPAGE_SHIFT to 0. But on s390, where we only support one hugepage size, there is a link between HPAGE_SHIFT and pageblock_order. So instead of setting HPAGE_SHIFT to 0, we will implement the check for the hardware capability. Signed-off-by: NDominik Dingel <dingel@linux.vnet.ibm.com> Acked-by: NMartin Schwidefsky <schwidefsky@de.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: Michael Holzheu <holzheu@linux.vnet.ibm.com> Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Dominik Dingel 提交于
Heiko noticed that the current check for hugepage support on s390 is a little bit too harsh as systems which do not support will crash. The reason is that pageblock_order can now get negative when we set HPAGE_SHIFT to 0. To avoid all this and to avoid opening another can of worms with enabling HUGETLB_PAGE_SIZE_VARIABLE I think it would be best to simply allow architectures to define their own hugepages_supported(). Revert bea41197 ("s390/mm: make hugepages_supported a boot time decision") in preparation. Signed-off-by: NDominik Dingel <dingel@linux.vnet.ibm.com> Acked-by: NMartin Schwidefsky <schwidefsky@de.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: Michael Holzheu <holzheu@linux.vnet.ibm.com> Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Dominik Dingel 提交于
Heiko noticed that the current check for hugepage support on s390 is a little bit too harsh as systems which do not support will crash. The reason is that pageblock_order can now get negative when we set HPAGE_SHIFT to 0. To avoid all this and to avoid opening another can of worms with enabling HUGETLB_PAGE_SIZE_VARIABLE I think it would be best to simply allow architectures to define their own hugepages_supported(). This patch (of 4): revert commit cf54e2fc ("s390/mm: change HPAGE_SHIFT type to int") in preparation. Signed-off-by: NDominik Dingel <dingel@linux.vnet.ibm.com> Acked-by: NMartin Schwidefsky <schwidefsky@de.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: Michael Holzheu <holzheu@linux.vnet.ibm.com> Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Andrew Morton 提交于
openrisc-allnoconfig: kernel/uid16.c: In function 'SYSC_setgroups16': kernel/uid16.c:184:2: error: implicit declaration of function 'groups_alloc' kernel/uid16.c:184:13: warning: assignment makes pointer from integer without a cast openrisc shouldn't be setting CONFIG_UID16 when CONFIG_MULTIUSER=n. Fixes: 2813893f ("kernel: conditionally support non-root users, groups and capabilities") Reported-by: NFengguang Wu <fengguang.wu@gmail.com> Cc: Iulia Manda <iulia.manda21@gmail.com> Cc: Josh Triplett <josh@joshtriplett.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 17 7月, 2015 17 次提交
-
-
由 Russell King 提交于
Fengguang Wu reports that building ARM with !MMU results in the following build error: arch/arm/kernel/built-in.o: In function `__soft_restart': >> :(.text+0x1624): undefined reference to `arch_virt_to_idmap' Fix this by adding an appropriate IS_ENABLED(CONFIG_MMU) into the __virt_to_idmap() inline function. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
We must invalidate the L1 cache before enabling coherency, otherwise secondary CPUs can inject invalid cache lines into the coherent CPU cluster, which could then be migrated to other CPUs. This fixes a recent regression with SoCFPGA randomly failing to boot. Fixes: 02b4e275 ("ARM: v7 setup function should invalidate L1 cache") Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Marek Szyprowski 提交于
nr_bitmaps member of mapping structure stores the number of already allocated bitmaps and it is interpreted as loop iterator (it starts from 0 not from 1), so a comparison against number of possible bitmap extensions should include this fact. This patch fixes this by changing the extension failure condition. This issue has been introduced by commit 4d852ef8 ("arm: dma-mapping: Add support to extend DMA IOMMU mappings"). Reported-by: NHyungwon Hwang <human.hwang@samsung.com> Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: NHyungwon Hwang <human.hwang@samsung.com> Cc: stable@vger.kernel.org # v3.15+ Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Stephen Boyd 提交于
It's possible, albeit unlikely, that using the of_node here will reference freed memory. Call of_node_put() after printing the name to be safe. Signed-off-by: NStephen Boyd <sboyd@codeaurora.org> Signed-off-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Vitaly Andrianov 提交于
This patch is to get correct physical address of the reset function for PAE systems, which use aliased physical memory for booting. See the "ARM: mm: Introduce virt_to_idmap() with an arch hook" for details. Signed-off-by: NVitaly Andrianov <vitalya@ti.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Andy Lutomirski 提交于
It turns out to be rather tedious to test the NMI nesting code. Make it easier: add a new CONFIG_DEBUG_ENTRY option that causes the NMI handler to pre-emptively unmask NMIs. With this option set, errors in the repeat_nmi logic or failures to detect that we're in a nested NMI will result in quick panics under perf (especially if multiple counters are running at high frequency) instead of requiring an unusual workload that generates page faults or breakpoints inside NMIs. I called it CONFIG_DEBUG_ENTRY instead of CONFIG_DEBUG_NMI_ENTRY because I want to add new non-NMI checks elsewhere in the entry code in the future, and I'd rather not add too many new config options or add this option and then immediately rename it. Signed-off-by: NAndy Lutomirski <luto@kernel.org> Reviewed-by: NSteven Rostedt <rostedt@goodmis.org> Cc: Borislav Petkov <bp@suse.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Andy Lutomirski 提交于
Currently, "NMI executing" is one the first time an outermost NMI hits repeat_nmi and zero thereafter. Change it to be zero each time for consistency. This is intended to help NMI handling fail harder if it's buggy. Signed-off-by: NAndy Lutomirski <luto@kernel.org> Reviewed-by: NSteven Rostedt <rostedt@goodmis.org> Cc: Borislav Petkov <bp@suse.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Andy Lutomirski 提交于
Replace LEA; MOV with an equivalent SUB. This saves one instruction. Signed-off-by: NAndy Lutomirski <luto@kernel.org> Reviewed-by: NSteven Rostedt <rostedt@goodmis.org> Cc: Borislav Petkov <bp@suse.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Andy Lutomirski 提交于
We have a tricky bug in the nested NMI code: if we see RSP pointing to the NMI stack on NMI entry from kernel mode, we assume that we are executing a nested NMI. This isn't quite true. A malicious userspace program can point RSP at the NMI stack, issue SYSCALL, and arrange for an NMI to happen while RSP is still pointing at the NMI stack. Fix it with a sneaky trick. Set DF in the region of code that the RSP check is intended to detect. IRET will clear DF atomically. ( Note: other than paravirt, there's little need for all this complexity. We could check RIP instead of RSP. ) Signed-off-by: NAndy Lutomirski <luto@kernel.org> Reviewed-by: NSteven Rostedt <rostedt@goodmis.org> Cc: Borislav Petkov <bp@suse.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Signed-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Andy Lutomirski 提交于
Check the repeat_nmi .. end_repeat_nmi special case first. The next patch will rework the RSP check and, as a side effect, the RSP check will no longer detect repeat_nmi .. end_repeat_nmi, so we'll need this ordering of the checks. Note: this is more subtle than it appears. The check for repeat_nmi .. end_repeat_nmi jumps straight out of the NMI code instead of adjusting the "iret" frame to force a repeat. This is necessary, because the code between repeat_nmi and end_repeat_nmi sets "NMI executing" and then writes to the "iret" frame itself. If a nested NMI comes in and modifies the "iret" frame while repeat_nmi is also modifying it, we'll end up with garbage. The old code got this right, as does the new code, but the new code is a bit more explicit. If we were to move the check right after the "NMI executing" check, then we'd get it wrong and have random crashes. ( Because the "NMI executing" check would jump to the code that would modify the "iret" frame without checking if the interrupted NMI was currently modifying it. ) Signed-off-by: NAndy Lutomirski <luto@kernel.org> Reviewed-by: NSteven Rostedt <rostedt@goodmis.org> Cc: Borislav Petkov <bp@suse.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Signed-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Andy Lutomirski 提交于
I found the nested NMI documentation to be difficult to follow. Improve the comments. Signed-off-by: NAndy Lutomirski <luto@kernel.org> Reviewed-by: NSteven Rostedt <rostedt@goodmis.org> Cc: Borislav Petkov <bp@suse.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Signed-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Andy Lutomirski 提交于
Returning to userspace is tricky: IRET can fail, and ESPFIX can rearrange the stack prior to IRET. The NMI nesting fixup relies on a precise stack layout and atomic IRET. Rather than trying to teach the NMI nesting fixup to handle ESPFIX and failed IRET, punt: run NMIs that came from user mode on the normal kernel stack. This will make some nested NMIs visible to C code, but the C code is okay with that. As a side effect, this should speed up perf: it eliminates an RDMSR when NMIs come from user mode. Signed-off-by: NAndy Lutomirski <luto@kernel.org> Reviewed-by: NSteven Rostedt <rostedt@goodmis.org> Reviewed-by: NBorislav Petkov <bp@suse.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Signed-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Andy Lutomirski 提交于
Now that do_nmi saves CR2, we don't need to save it in asm. Signed-off-by: NAndy Lutomirski <luto@kernel.org> Reviewed-by: NSteven Rostedt <rostedt@goodmis.org> Acked-by: NBorislav Petkov <bp@suse.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Signed-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Andy Lutomirski 提交于
32-bit kernels handle nested NMIs in C. Enable the exact same handling on 64-bit kernels as well. This isn't currently necessary, but it will become necessary once the asm code starts allowing limited nesting. Signed-off-by: NAndy Lutomirski <luto@kernel.org> Reviewed-by: NSteven Rostedt <rostedt@goodmis.org> Cc: Borislav Petkov <bp@suse.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Signed-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Murali Karicheri 提交于
Now that PCIe DT binding is disabled in SoC specific DTS, we need a way to override it in a board specific DTS. So rename the PCIe nodes accordingly. Signed-off-by: NMurali Karicheri <m-karicheri2@ti.com> Signed-off-by: NSantosh Shilimkar <ssantosh@kernel.org>
-
由 Murali Karicheri 提交于
Currently PCIe DT bindings are broken. PCIe driver can't function without having a SerDes driver that provide the phy configuration. On K2E EVM, this causes problem since the EVM has Marvell SATA controller present and with default values in the SerDes register, it seems to pass the PCIe link check, but causes issues since the configuration is not correct. The manifestation is that when EVM is booted with NFS rootfs, the boot hangs. We shouldn't enable PCIe on this EVM since to work, SerDes driver has to be present as well. So by default, the PCIe DT binding should be disabled in SoC specific DTS. It can be enabled in the board specific DTS when the SerDes device driver is also present. So fix the status of PCIe DT bindings in the SoC specific DTS to "disabled". To enable PCIe, the status should be set to "ok" in the EVM DTS file when SerDes driver support becomes available in the upstream tree. Signed-off-by: NMurali Karicheri <m-karicheri2@ti.com> Signed-off-by: NSantosh Shilimkar <ssantosh@kernel.org>
-
由 Robert Jarzmik 提交于
Since dm9000 driver added support for a vcc regulator, platform data based platforms have their ethernet broken, as the regulator claiming returns -EPROBE_DEFER and prevents dm9000 loading. This patch fixes this for all pxa boards using dm9000, by using the specific regulator_has_full_constraints() function. This was discovered and tested on the cm-x300 board. Fixes: 7994fe55 ("dm9000: Add regulator and reset support to dm9000") Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr> Acked-by: NIgor Grinberg <grinberg@compulab.co.il>
-
- 15 7月, 2015 4 次提交
-
-
由 Adam YH Lee 提交于
Audio-in was incorrectly routed to Line In. It should be Mic3L as per schematic. Using mic-bias voltage at 2.0v (<0x1>) does not work for some reason. There is no voltage seen on micbias (R127). Mic-bias voltage of 2.5v (<0x2>) works. I see voltage of 2.475v across GND and micbias. With these changes, I can record audio with a pair of proliferate TRRS earbuds. Signed-off-by: NAdam YH Lee <adam.yh.lee@gmail.com> Acked-by: NAsh Charles <ashcharles@gmail.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Dave Gerlach 提交于
CONFIG_HAVE_ARM_SCU only gets selected if CONFIG_SMP is selected in an OMAP system, however AM43XX needs this option regardless of CONFIG_SMP and also for an AM43XX only build as it is important for controlling power in the SoC. Without this we cannot suspend the CPU for SoC suspend or cpuidle. The ARM Cortex A9 needs SCU CPU Power Status bits to be set to off mode in order for the PRCM to transition the MPU to low power modes. Signed-off-by: NDave Gerlach <d-gerlach@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Thomas Gleixner 提交于
Boris reported that the sparse_irq protection around __cpu_up() in the generic code causes a regression on Xen. Xen allocates interrupts and some more in the xen_cpu_up() function, so it deadlocks on the sparse_irq_lock. There is no simple fix for this and we really should have the protection for all architectures, but for now the only solution is to move it to x86 where actual wreckage due to the lack of protection has been observed. Reported-and-tested-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com> Fixes: a8994181 'hotplug: Prevent alloc/free of irq descriptors during cpu up/down' Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: xiao jin <jin.xiao@intel.com> Cc: Joerg Roedel <jroedel@suse.de> Cc: Borislav Petkov <bp@suse.de> Cc: Yanmin Zhang <yanmin_zhang@linux.intel.com> Cc: xen-devel <xen-devel@lists.xenproject.org>
-
由 Ralf Baechle 提交于
Pass 1 parts had a number of significant erratas and were only available in small numbers and under NDA. Full support also required the use of a special toolchain that kept branches properly aligned. These workarounds were never upstreamed and the only toolchain known to have them is Montavista's GCC 3.0-based toolchain which completly obsoleted if not useless these days. So now that automated testing has tripped over the user of the -msb1-pass1-workarounds option, rather than fixing it remove support for pass 1 parts. Probably nobody will notice. I seem to own the last know pass 1 board and I haven't noticed another one in the wild in the past decade, at least. Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
- 14 7月, 2015 1 次提交
-
-
由 Paul Burton 提交于
MIPS32r6 code requires FP64 (ie. FR=1) support. Building a kernel with support for MIPS32r6 binaries but without support for O32 with FP64 is therefore a problem which can lead to incorrectly executed userland. CONFIG_MIPS_O32_FP64_SUPPORT is already selected when the kernel is configured for MIPS32r6, but not when the kernel is configured for MIPS64r6 with O32 compat support. Select CONFIG_MIPS_O32_FP64_SUPPORT in such configurations to prevent building kernels which execute MIPS32r6 userland incorrectly. Signed-off-by: NPaul Burton <paul.burton@imgtec.com> Cc: Markos Chandras <markos.chandras@imgtec.com> Cc: <stable@vger.kernel.org> # v4.0- Cc: linux-mips@linux-mips.org Cc: Matthew Fortune <matthew.fortune@imgtec.com> Cc: stable@vger.kernel.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/10674/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-