- 05 4月, 2014 9 次提交
-
-
由 Chen Gang 提交于
Need include generic "vga.h", or can not pass compiling with allmodconfig, the related error: CC [M] drivers/gpu/drm/drm_irq.o In file included from include/linux/vgaarb.h:34:0, from drivers/gpu/drm/drm_irq.c:42: include/video/vga.h:22:21: fatal error: asm/vga.h: No such file or directory Also move "preempt.h" upper to match sort order. Signed-off-by: NChen Gang <gang.chen.5i5j@gmail.com> Signed-off-by: NRichard Kuo <rkuo@codeaurora.org>
-
由 Chen Gang 提交于
Add "serial.h" in Kbuild, or can not pass compiling with allmodconfig, the related error: CC [M] drivers/staging/speakup/speakup_acntpc.o In file included from drivers/staging/speakup/speakup_acntpc.c:33:0: drivers/staging/speakup/serialio.h:7:24: fatal error: asm/serial.h: No such file or directory Signed-off-by: NChen Gang <gang.chen.5i5j@gmail.com> Signed-off-by: NRichard Kuo <rkuo@codeaurora.org>
-
由 Chen Gang 提交于
Define dummy '__init' instead of include "linux/init.h" if !__KERNEL__, or can not pass checking. The related error (with allmodconfig under hexagon): CHECK include/asm (34 files) usr/include/asm/setup.h:22: included file 'linux/init.h' is not exported Signed-off-by: NChen Gang <gang.chen.5i5j@gmail.com> Signed-off-by: NRichard Kuo <rkuo@codeaurora.org>
-
由 Chen Gang 提交于
Append "hvmc_" or "hvmi_" to all related enum members (which are too common to make conflict with another sub-systems). The related error with allmodconfig: CC [M] drivers/md/raid1.o drivers/md/raid1.c:1440:13: error: 'status' redeclared as different kind of symbol arch/hexagon/include/asm/hexagon_vm.h:76:2: note: previous definition of 'status' was here Also use 'affinity' instead of 'locdis' for __vmintop_affinity(). Signed-off-by: NChen Gang <gang.chen.5i5j@gmail.com> Signed-off-by: NRichard Kuo <rkuo@codeaurora.org>
-
由 Chen Gang 提交于
arch: hexagon: Kconfig: add HAVE_DMA_ATTR in Kconfig and remove "linux/dma-mapping.h" from "asm/dma-mapping.h" When HAS_DMA, and also need use generic implementation, HAVE_DMA_ATTR must be enabled, or can not pass compiling with allmodconfig, the related error: CC [M] drivers/ata/libata-core.o drivers/ata/libata-core.c: In function 'ata_sg_clean': drivers/ata/libata-core.c:4598:3: error: implicit declaration of function 'dma_unmap_sg' [-Werror=implicit-function-declaration] drivers/ata/libata-core.c: In function 'ata_sg_setup': drivers/ata/libata-core.c:4708:2: error: implicit declaration of function 'dma_map_sg' [-Werror=implicit-function-declaration] "linux/dma-mapping.h" will include "asm/dma-mapping.h", so need remove "linux/dma-mapping.h" from "asm/dma-mapping.h", Signed-off-by: NChen Gang <gang.chen.5i5j@gmail.com> Signed-off-by: NRichard Kuo <rkuo@codeaurora.org>
-
由 Chen Gang 提交于
Need add __delay() implementation, or can not pass allmodconfig in next-20131118 tree. The related error: CC kernel/locking/spinlock_debug.o kernel/locking/spinlock_debug.c: In function '__spin_lock_debug': kernel/locking/spinlock_debug.c:114:3: error: implicit declaration of function '__delay' [-Werror=implicit-function-declaration] Signed-off-by: NChen Gang <gang.chen.5i5j@gmail.com> Signed-off-by: NRichard Kuo <rkuo@codeaurora.org>
-
由 Chen Gang 提交于
Need extend maximized number for "cs0/1", the related warning (with allmodconfig for v4): arch/hexagon/kernel/kgdb.c:79: warning: excess elements in array initializer arch/hexagon/kernel/kgdb.c:79: warning: (near initialization for 'dbg_reg_def') arch/hexagon/kernel/kgdb.c:80: warning: excess elements in array initializer arch/hexagon/kernel/kgdb.c:80: warning: (near initialization for 'dbg_reg_def') Signed-off-by: NChen Gang <gang.chen@asianux.com> Signed-off-by: NRichard Kuo <rkuo@codeaurora.org>
-
由 Chen Gang 提交于
Need include related headers for pass compiling, the related error (with allmodconfig for v4): CC arch/hexagon/kernel/kgdb.o arch/hexagon/kernel/kgdb.c:30: error: invalid use of undefined type 'struct pt_regs' arch/hexagon/kernel/kgdb.c:31: error: invalid use of undefined type 'struct pt_regs' ... arch/hexagon/kernel/kgdb.c:220: error: implicit declaration of function 'local_irq_save' arch/hexagon/kernel/kgdb.c:222: error: implicit declaration of function 'local_irq_restore' ... Signed-off-by: NChen Gang <gang.chen@asianux.com> Signed-off-by: NRichard Kuo <rkuo@codeaurora.org>
-
由 Chen Gang 提交于
Remove them, since they are useless. The related warnings (with allmodconfig for v4): CC arch/hexagon/kernel/time.o arch/hexagon/kernel/time.c: In function 'time_init_deferred': arch/hexagon/kernel/time.c:196: warning: unused variable 'err' arch/hexagon/kernel/time.c:195: warning: unused variable 'r' arch/hexagon/kernel/time.c:194: warning: unused variable 'dn' Signed-off-by: NChen Gang <gang.chen@asianux.com> Signed-off-by: NRichard Kuo <rkuo@codeaurora.org>
-
- 29 3月, 2014 1 次提交
-
-
由 Artem Fetishev 提交于
On x86 uniprocessor systems topology_physical_package_id() returns -1 which causes rapl_cpu_prepare() to leave rapl_pmu variable uninitialized which leads to GPF in rapl_pmu_init(). See arch/x86/kernel/cpu/perf_event_intel_rapl.c. It turns out that physical_package_id and core_id can actually be retreived for uniprocessor systems too. Enabling them also fixes rapl_pmu code. Signed-off-by: NArtem Fetishev <artem_fetishev@epam.com> Cc: Stephane Eranian <eranian@google.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: <stable@vger.kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 25 3月, 2014 2 次提交
-
-
由 David Vrabel 提交于
This reverts commit a9c8e4be. PTEs in Xen PV guests must contain machine addresses if _PAGE_PRESENT is set and pseudo-physical addresses is _PAGE_PRESENT is clear. This is because during a domain save/restore (migration) the page table entries are "canonicalised" and uncanonicalised". i.e., MFNs are converted to PFNs during domain save so that on a restore the page table entries may be rewritten with the new MFNs on the destination. This canonicalisation is only done for PTEs that are present. This change resulted in writing PTEs with MFNs if _PAGE_PROTNONE (or _PAGE_NUMA) was set but _PAGE_PRESENT was clear. These PTEs would be migrated as-is which would result in unexpected behaviour in the destination domain. Either a) the MFN would be translated to the wrong PFN/page; b) setting the _PAGE_PRESENT bit would clear the PTE because the MFN is no longer owned by the domain; or c) the present bit would not get set. Symptoms include "Bad page" reports when munmapping after migrating a domain. Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com> Acked-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: <stable@vger.kernel.org> [3.12+]
-
由 David S. Miller 提交于
In arch_cpu_idle() we must enable %pil based interrupts before potentially invoking the hypervisor cpu yield call. As per the Hypervisor API documentation for cpu_yield: Interrupts which are blocked by some mechanism other that pstate.ie (for example %pil) are not guaranteed to cause a return from this service. It seems that only first generation Niagara chips are hit by this bug. My best guess is that later chips implement this in hardware and wake up anyways from %pil events, whereas in first generation chips the yield is implemented completely in hypervisor code and requires %pil to be enabled in order to wake properly from this call. Fixes: 87fa05ae ("sparc: Use generic idle loop") Reported-by: NFabio M. Di Nitto <fabbione@fabbione.net> Reported-by: NJan Engelhardt <jengelh@inai.de> Tested-by: NJan Engelhardt <jengelh@inai.de> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 24 3月, 2014 1 次提交
-
-
由 Will Deacon 提交于
Now that the arch_{spin,read,write}_relax macros default to cpu_relax(), remove the redundant definitions for parisc. Cc: Helge Deller <deller@gmx.de> Signed-off-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NHelge Deller <deller@gmx.de>
-
- 23 3月, 2014 2 次提交
-
-
由 Helge Deller 提交于
We seem to be nearly the only platform which does not provide the sys_utimes syscall. Adding it now makes our life much easier with userspace applications (like dietlibc and e2fsprogs) since we then behave like all other platforms too and don't need extra patches which are hard to get upstream anyway because we are not a mainstream architecture. Signed-off-by: NHelge Deller <deller@gmx.de> Cc: stable@vger.kernel.org # v3.13
-
由 John David Anglin 提交于
The attached change removes the unused and experimental CONFIG_PARISC_TMPALIAS code. It doesn't work and I don't believe it will ever be used. Signed-off-by: NJohn David Anglin <dave.anglin@bell.net> Signed-off-by: NHelge Deller <deller@gmx.de>
-
- 20 3月, 2014 3 次提交
-
-
由 Jim Quinlan 提交于
For non-mipsr2 processors, the local_irq_disable contains an mfc0-mtc0 pair with instructions inbetween. With preemption enabled, this sequence may get preempted and effect a stale value of CP0_STATUS when executing the mtc0 instruction. This commit avoids this scenario by incrementing the preempt count before the mfc0 and decrementing it after the mtc9. [ralf@linux-mips.org: This patch is sorting out the part that were missed by e97c5b60 [MIPS: Make irqflags.h functions preempt-safe for non-mipsr2 cpus.] I also re-enabled the inclusion of <asm/asm-offsets.h> at the top of <asm/asmmacro.h>]. Signed-off-by: NJim Quinlan <jim2101024@gmail.com> Cc: linux-mips@linux-mips.org Cc: cernekee@gmail.com Patchwork: https://patchwork.linux-mips.org/patch/6164/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Andreas Herrmann 提交于
Starting with commit 3da52787 (of/irq: Rework of_irq_count()) the following warning is triggered on octeon cn3xxx: [ 0.887281] WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x228/0x230() [ 0.895642] Modules linked in: [ 0.898689] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.14.0-rc7-00012-g9ae51f2-dirty #41 [ 0.906860] Stack : c8b439581166d96e ffffffff816b0000 0000000040808000 ffffffff81185ddc [ 0.906860] 0000000000000000 0000000000000000 0000000000000000 000000000000000b [ 0.906860] 000000000000000a 000000000000000a 0000000000000000 0000000000000000 [ 0.906860] ffffffff81740000 ffffffff81720000 ffffffff81615900 ffffffff816b0177 [ 0.906860] ffffffff81727d10 800000041f868fb0 0000000000000001 0000000000000000 [ 0.906860] 0000000000000000 0000000000000038 0000000000000001 ffffffff81568484 [ 0.906860] 800000041f86faa8 ffffffff81145ddc 0000000000000000 ffffffff811873f4 [ 0.906860] 800000041f868b88 800000041f86f9c0 0000000000000000 ffffffff81569c9c [ 0.906860] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 0.906860] 0000000000000000 ffffffff811205e0 0000000000000000 0000000000000000 [ 0.906860] ... [ 0.971695] Call Trace: [ 0.974139] [<ffffffff811205e0>] show_stack+0x68/0x80 [ 0.979183] [<ffffffff81569c9c>] dump_stack+0x8c/0xe0 [ 0.984196] [<ffffffff81145efc>] warn_slowpath_common+0x84/0xb8 [ 0.990110] [<ffffffff81436888>] of_device_alloc+0x228/0x230 [ 0.995726] [<ffffffff814368d8>] of_platform_device_create_pdata+0x48/0xd0 [ 1.002593] [<ffffffff81436a94>] of_platform_bus_create+0x134/0x1e8 [ 1.008837] [<ffffffff81436af8>] of_platform_bus_create+0x198/0x1e8 [ 1.015064] [<ffffffff81436cc4>] of_platform_bus_probe+0xa4/0x100 [ 1.021149] [<ffffffff81100570>] do_one_initcall+0xd8/0x128 [ 1.026701] [<ffffffff816e2a10>] kernel_init_freeable+0x144/0x210 [ 1.032753] [<ffffffff81564bc4>] kernel_init+0x14/0x110 [ 1.037973] [<ffffffff8111bb44>] ret_from_kernel_thread+0x14/0x1c With this commit the kernel starts mapping the interrupts listed for gpio-controller node. irq_domain_ops for CIU (octeon_irq_ciu_map and octeon_irq_ciu_xlat) refuse to handle the GPIO lines (returning -EINVAL) and this is causing above warning in of_device_alloc(). Modify irq_domain_ops for CIU and CIU2 to "gracefully handle" GPIO lines (neither return error code nor call octeon_irq_set_ciu_mapping for it). This should avoid the warning. (As before the real setup for GPIO lines will happen using irq_domain_ops of gpio-controller.) This patch is based on Wei's patch v2 (see http://marc.info/?l=linux-mips&m=139511814813247). Signed-off-by: NAndreas Herrmann <andreas.herrmann@caviumnetworks.com> Reported-by: NYang Wei <wei.yang@windriver.com> Acked-by: NDavid Daney <david.daney@cavium.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/6624/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Viller Hsiao 提交于
Due to name collision in ftrace safe_load and safe_store macros, these macros cannot take expressions as operands. For example, compiler will complain for a macro call like the following: safe_store_code(new_code2, ip + 4, faulted); arch/mips/include/asm/ftrace.h:61:6: note: in definition of macro 'safe_store' : [dst] "r" (dst), [src] "r" (src)\ ^ arch/mips/kernel/ftrace.c:118:2: note: in expansion of macro 'safe_store_code' safe_store_code(new_code2, ip + 4, faulted); ^ arch/mips/kernel/ftrace.c:118:32: error: undefined named operand 'ip + 4' safe_store_code(new_code2, ip + 4, faulted); ^ arch/mips/include/asm/ftrace.h:61:6: note: in definition of macro 'safe_store' : [dst] "r" (dst), [src] "r" (src)\ ^ arch/mips/kernel/ftrace.c:118:2: note: in expansion of macro 'safe_store_code' safe_store_code(new_code2, ip + 4, faulted); ^ This build error is triggered by a4671094 [MIPS: ftrace: Fix icache flush range error]. Tweak variable naming in those macros to allow flexible operands. Signed-off-by: NViller Hsiao <villerhsiao@gmail.com> Cc: linux-mips@linux-mips.org Cc: rostedt@goodmis.org Cc: fweisbec@gmail.com Cc: mingo@redhat.com Cc: Qais.Yousef@imgtec.com Patchwork: https://patchwork.linux-mips.org/patch/6622/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
- 19 3月, 2014 2 次提交
-
-
由 Rafał Miłecki 提交于
Broadcom boards support 32 GPIOs and NVRAM may have entires for higher ones too. Example: gpio23=wombo_reset Signed-off-by: NRafa? Mi?ecki <zajec5@gmail.com> Acked-by: NHauke Mehrtens <hauke@hauke-m.de> Cc: linux-mips@linux-mips.org Cc: Rafał Miłecki <zajec5@gmail.com> Patchwork: https://patchwork.linux-mips.org/patch/6547/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Bjorn Helgaas 提交于
This reverts commit 56dd669a, which makes the GART visible in /proc/iomem. This fixes a regression: e501b3d8 ("agp: Support 64-bit APBASE") exposed an existing problem with a conflict between the GART region and a PCI BAR region. The GART addresses are bus addresses, not CPU addresses, and therefore should not be inserted in iomem_resource. On many machines, the GART region is addressable by the CPU as well as by an AGP master, but CPU addressability is not required by the spec. On some of these machines, the GART is mapped by a PCI BAR, and in that case, the PCI core automatically inserts it into iomem_resource, just as it does for all BARs. Inserting it here means we'll have a conflict if the PCI core later tries to claim the GART region, so let's drop the insertion here. The conflict indirectly causes X failures, as reported by Jouni in the bugzilla below. We detected the conflict even before e501b3d8, but after it the AGP code (fix_northbridge()) uses the PCI resource (which is zeroed because of the conflict) instead of reading the BAR again. Conflicts: arch/x86_64/kernel/aperture.c Fixes: e501b3d8 agp: Support 64-bit APBASE Link: https://bugzilla.kernel.org/show_bug.cgi?id=72201Reported-and-tested-by: NJouni Mettälä <jtmettala@gmail.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 18 3月, 2014 3 次提交
-
-
由 Alex Smith 提交于
If CONFIG_TRANSPARENT_HUGEPAGE is enabled, but CONFIG_HUGETLB_PAGE is not, it is possible to end up with a configuration that fails to build with the following error: include/linux/huge_mm.h:125:2: error: #error "hugepages can't be allocated by the buddy allocator" This is due to CONFIG_FORCE_MAX_ZONEORDER defaulting to 11. It already has ranges that change the valid values when HUGETLB_PAGE is enabled, but this is not done for TRANSPARENT_HUGEPAGE. Fix by changing the HUGETLB_PAGE dependencies to MIPS_HUGE_TLB_SUPPORT, which includes both TRANSPARENT_HUGEPAGE and HUGETLB_PAGE. Signed-off-by: NAlex Smith <alex.smith@imgtec.com> Reviewed-by: NMarkos Chandras <markos.chandras@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/6391/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Doug Wilson 提交于
This is a small patch which uses ARRAY_SIZE macro rather than a number to make code readability better. Signed-off-by: NDoug Wilson <doug.lkml@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Dave Kleikamp 提交于
When checking a system call return code for an error, linux_sparc_syscall was sign-extending the lower 32-bit value and comparing it to -ERESTART_RESTARTBLOCK. lseek can return valid return codes whose lower 32-bits alone would indicate a failure (such as 4G-1). Use the whole 64-bit value to check for errors. Only the 32-bit path should sign extend the lower 32-bit value. Signed-off-by: NDave Kleikamp <dave.kleikamp@oracle.com> Acked-by: NBob Picco <bob.picco@oracle.com> Acked-by: NAllen Pais <allen.pais@oracle.com> Cc: David S. Miller <davem@davemloft.net> Cc: sparclinux@vger.kernel.org Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 17 3月, 2014 4 次提交
-
-
由 Paul Burton 提交于
Commit 597ce172 "MIPS: Support for 64-bit FP with O32 binaries" introduced support for setting Status.FR=1 for O32 binaries with the EF_MIPS_FP64 ELF header flag set. Whilst this flag is currently supported by binutils it does introduce an ABI break within userland. Objects built with EF_MIPS_FP64 cannot be safely linked with those built without it since code in either object may assume behaviour specific to a value of FR. More recently there has been discussion around avoiding further fragmentation of the O32 ABI whilst still allowing the use of FR=1 and features such as MSA which depend upon it. Details of the plan to allow this are still being worked on, and whilst the kernel will need the ability to handle FR=1 with O32 tasks it is unclear what else it may need to provide to a userland which seeks to avoid another ABI break. In order to prevent the proliferation of userland which may rely upon the current EF_MIPS_FP64 behaviour this patch marks the kernel support for it experimental & disables it by default. Under current proposals it is likely that this support can simply be enabled again later, but possibly after the introduction of further interfaces with userland and support for the MIPS R5 UFR feature. Signed-off-by: NPaul Burton <paul.burton@imgtec.com> Cc: Matthew Fortune <matthew.fortune@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Paul Burton <paul.burton@imgtec.com> Patchwork: https://patchwork.linux-mips.org/patch/6549/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Viller Hsiao 提交于
In 32-bit mode, the start address passed to flush_icache_range is shifted by 4 bytes before the second safe_store_code() call. This causes system crash from time to time because the first 4 bytes might not be flushed properly. This bug exists since linux-3.8. Also remove obsoleted comment while at it. Signed-off-by: NViller Hsiao <villerhsiao@gmail.com> Cc: linux-mips@linux-mips.org Cc: rostedt@goodmis.org Cc: fweisbec@gmail.com Cc: mingo@redhat.com Cc: Qais.Yousef@imgtec.com Patchwork: https://patchwork.linux-mips.org/patch/6586/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Lars Persson 提交于
Fix pointer computation for stack-based arguments. Signed-off-by: NLars Persson <larper@axis.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/6620/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Markos Chandras 提交于
The syscall_get_arguments function expects the arguments to be copied to the '*args' argument but instead a local variable was used to hold the system call argument. As a result of which, this variable was never passed to the filter and any filter testing the system call arguments would fail. This is fixed by passing the '*args' variable as the destination memory for the system call arguments. Signed-off-by: NMarkos Chandras <markos.chandras@imgtec.com> Reviewed-by: NPaul Burton <paul.burton@imgtec.com> Reviewed-by: NJames Hogan <james.hogan@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/6402/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
- 15 3月, 2014 3 次提交
-
-
由 Colin Ian King 提交于
Bar type OCTEON_DMA_BAR_TYPE_SMALL assigns lo and hi addresses and then falls through to OCTEON_DMA_BAR_TYPE_BIG that re-assignes lo and hi addresses with totally different values. Add a break so we don't fall through. Signed-off-by: NColin Ian King <colin.king@canonical.com> Acked-by: NDavid Daney <ddaney@caviumnetworks.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/6529/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Huacai Chen 提交于
In _restore_fp_context/_restore_fp_context32, t0 is used for both CP0_Status and CP1_FCSR. This is a mistake and cause FP exeception on boot, so fix it. Signed-off-by: NHuacai Chen <chenhc@lemote.com> Tested-by: NAaro Koskinen <aaro.koskinen@iki.fi> Tested-by: NAndreas Barth <aba@ayous.org> Cc: John Crispin <john@phrozen.org> Cc: Steven J. Hill <Steven.Hill@imgtec.com> Cc: Aurelien Jarno <aurelien@aurel32.net> Cc: linux-mips@linux-mips.org Cc: Fuxin Zhang <zhangfx@lemote.com> Cc: Zhangjin Wu <wuzhangjin@gmail.com> Patchwork: https://patchwork.linux-mips.org/patch/6507/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Paul Bolle 提交于
Commit 597ce172 ("MIPS: Support for 64-bit FP with O32 binaries") introduced references to two undefined Kconfig macros. CONFIG_MIPS32_R2 should clearly be replaced with CONFIG_CPU_MIPS32_R2. And CONFIG_MIPS64 should be replaced with CONFIG_64BIT. Signed-off-by: NPaul Bolle <pebolle@tiscali.nl> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/6522/Tested-by: NAaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
- 14 3月, 2014 1 次提交
-
-
由 Daniel J Blueman 提交于
For systems with multiple servers and routed fabric, all northbridges get assigned to the first server. Fix this by also using the node reported from the PCI bus. For single-fabric systems, the northbriges are on PCI bus 0 by definition, which are on NUMA node 0 by definition, so this is invarient on most systems. Tested on fam10h and fam15h single and multi-fabric systems and candidate for stable. Signed-off-by: NDaniel J Blueman <daniel@numascale.com> Acked-by: NSteffen Persvold <sp@numascale.com> Acked-by: NBorislav Petkov <bp@suse.de> Cc: <stable@vger.kernel.org> Link: http://lkml.kernel.org/r/1394710981-3596-1-git-send-email-daniel@numascale.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
- 13 3月, 2014 3 次提交
-
-
由 Paul Mackerras 提交于
Commit 595e4f7e ("KVM: PPC: Book3S HV: Use load/store_fp_state functions in HV guest entry/exit") changed the register usage in kvmppc_save_fp() and kvmppc_load_fp() but omitted changing the instructions that load and save VRSAVE. The result is that the VRSAVE value was loaded from a constant address, and saved to a location past the end of the vcpu struct, causing host kernel memory corruption and various kinds of host kernel crashes. This fixes the problem by using register r31, which contains the vcpu pointer, instead of r3 and r4. Signed-off-by: NPaul Mackerras <paulus@samba.org> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Paul Mackerras 提交于
Commit 7b490411 ("KVM: PPC: Book3S HV: Add new state for transactional memory") incorrectly added some duplicate code to the guest exit path because I didn't manage to clean up after a rebase correctly. This removes the extraneous material. The presence of this extraneous code causes host crashes whenever a guest is run. Signed-off-by: NPaul Mackerras <paulus@samba.org> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Radim Krčmář 提交于
We always disable cr8 intercept in its handler, but only re-enable it if handling KVM_REQ_EVENT, so there can be a window where we do not intercept cr8 writes, which allows an interrupt to disrupt a higher priority task. Fix this by disabling intercepts in the same function that re-enables them when needed. This fixes BSOD in Windows 2008. Cc: <stable@vger.kernel.org> Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com> Reviewed-by: NMarcelo Tosatti <mtosatti@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
- 12 3月, 2014 5 次提交
-
-
由 Alexei Starovoitov 提交于
Commit a998d434 claimed to introduce negative offset support to x86 jit, but it couldn't be working, since at the time of the execution of LD+ABS or LD+IND instructions via call into bpf_internal_load_pointer_neg_helper() the %edx (3rd argument of this func) had junk value instead of access size in bytes (1 or 2 or 4). Store size into %edx instead of %ecx (what original commit intended to do) Fixes: a998d434 ("bpf jit: Let the x86 jit handle negative offsets") Signed-off-by: NAlexei Starovoitov <ast@plumgrid.com> Cc: Jan Seiffert <kaffeemonster@googlemail.com> Cc: Eric Dumazet <edumazet@google.com> Acked-by: NEric Dumazet <edumazet@google.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Deng-Cheng Zhu 提交于
When running applications which contain the instruction "prefx" on FPU-less CPUs, a message "Illegal instruction" will be seen. This instruction is supposed to be ignored by the FPU emulator. However, its current detection and function field encoding are incorrect. This patch fix the issue. Signed-off-by: NDeng-Cheng Zhu <dengcheng.zhu@imgtec.com> Reviewed-by: NLeonid Yegoshin <Leonid.Yegoshin@imgtec.com> Reviewed-by: NPaul Burton <paul.burton@imgtec.com> Acked-by: NDavid Daney <david.daney@cavium.com> Cc: linux-mips@linux-mips.org Cc: Steven.Hill@imgtec.com Patchwork: https://patchwork.linux-mips.org/patch/6608/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Boris BREZILLON 提交于
On the newly introduced sama5d36, Gigabit and 10/100 Ethernet network interfaces are probed in a different order than for the sama5d35. Moreover, users are accustomed to this order in bootloaders and backports for older kernel revisions. So this patch switches DT node order as it is done for the other dual-Ethernet sama5d3 SoC. Better interface numbering which does not depend on DT node order is being developed for stronger interface identification. Signed-off-by: NBoris BREZILLON <b.brezillon.dev@gmail.com> Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: NOlof Johansson <olof@lixom.net>
-
由 Suresh Siddha 提交于
For non-eager fpu mode, thread's fpu state is allocated during the first fpu usage (in the context of device not available exception). This (math_state_restore()) can be a blocking call and hence we enable interrupts (which were originally disabled when the exception happened), allocate memory and disable interrupts etc. But the eager-fpu mode, call's the same math_state_restore() from kernel_fpu_end(). The assumption being that tsk_used_math() is always set for the eager-fpu mode and thus avoid the code path of enabling interrupts, allocating fpu state using blocking call and disable interrupts etc. But the below issue was noticed by Maarten Baert, Nate Eldredge and few others: If a user process dumps core on an ecrypt fs while aesni-intel is loaded, we get a BUG() in __find_get_block() complaining that it was called with interrupts disabled; then all further accesses to our ecrypt fs hang and we have to reboot. The aesni-intel code (encrypting the core file that we are writing) needs the FPU and quite properly wraps its code in kernel_fpu_{begin,end}(), the latter of which calls math_state_restore(). So after kernel_fpu_end(), interrupts may be disabled, which nobody seems to expect, and they stay that way until we eventually get to __find_get_block() which barfs. For eager fpu, most the time, tsk_used_math() is true. At few instances during thread exit, signal return handling etc, tsk_used_math() might be false. In kernel_fpu_end(), for eager-fpu, call math_state_restore() only if tsk_used_math() is set. Otherwise, don't bother. Kernel code path which cleared tsk_used_math() knows what needs to be done with the fpu state. Reported-by: NMaarten Baert <maarten-baert@hotmail.com> Reported-by: NNate Eldredge <nate@thatsmathematics.com> Suggested-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NSuresh Siddha <sbsiddha@gmail.com> Link: http://lkml.kernel.org/r/1391410583.3801.6.camel@europa Cc: George Spelvin <linux@horizon.com> Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
-
由 Dave Jones 提交于
This was an optimization that made memcpy type benchmarks a little faster on ancient (Circa 1998) IDT Winchip CPUs. In real-life workloads, it wasn't even noticable, and I doubt anyone is running benchmarks on 16 year old silicon any more. Given this code has likely seen very little use over the last decade, let's just remove it. Signed-off-by: NDave Jones <davej@fedoraproject.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 11 3月, 2014 1 次提交
-
-
由 Dave Jones 提交于
The error path of uncore_type_init() frees up any allocations that were made along the way, but it relies upon type->pmus being set, which only happens if the function succeeds. As type->pmus remains null in this case, the call to uncore_type_exit will do nothing. Moving the assignment earlier will allow us to actually free those allocations should something go awry. Signed-off-by: NDave Jones <davej@fedoraproject.org> Acked-by: NPeter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/20140306172028.GA552@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
-