- 24 2月, 2012 10 次提交
-
-
由 Bjorn Helgaas 提交于
pci_probe_only is set on ppc64 to prevent resource re-allocation by the core. It's meant to be used in very specific circumstances such as when operating under a hypervisor that may prevent such re-allocation. Instead of default to 1, we make it default to 0 and explicitly set it in the few cases where we need it. This fixes FSL PCI which wants it clear among others. Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Bjorn Helgaas 提交于
We never assign anything other than PCI_ASSIGN_ALL_BUSSES to pci_probe, so just remove the indirection. If configurability is required in the future, please use the pci_flags/PCI_REASSIGN_ALL_BUS functionality as is done for powerpc. CC: Ralf Baechle <ralf@linux-mips.org> CC: linux-mips@linux-mips.org Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Bjorn Helgaas 提交于
Some architectures (alpha, mips, powerpc) have an arch-specific "pci_probe_only" flag. Others use PCI_PROBE_ONLY in pci_flags for the same purpose. This moves mips to the pci_flags approach so generic code can use the same test across all architectures. CC: Ralf Baechle <ralf@linux-mips.org> CC: linux-mips@linux-mips.org Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Bjorn Helgaas 提交于
pci_flags is initialized to zero and never modified (I think this was just copied from powerpc). Therefore, "(pci_flags & XX)" is always false and "!(pci_flags & XX)" is always true, and we can remove all references to pci_flags. CC: Michal Simek <monstr@monstr.eu> CC: microblaze-uclinux@itee.uq.edu.au Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Bjorn Helgaas 提交于
CC: Russell King <linux@arm.linux.org.uk> CC: linux-arm-kernel@lists.infradead.org Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Bjorn Helgaas 提交于
The PCI core provides a pci_flags definition (currently __weak), so drop the arm definition in favor of that. We EXPORT_SYMBOL(pci_flags) as arm did previously. I'm dubious about this: no other architecture exports it, and I didn't see any modules in the tree that reference it. CC: Rob Herring <rob.herring@calxeda.com> CC: Russell King <linux@arm.linux.org.uk> CC: linux-arm-kernel@lists.infradead.org Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Bjorn Helgaas 提交于
Some architectures (alpha, mips, powerpc) have an arch-specific "pci_probe_only" flag. Others use PCI_PROBE_ONLY in pci_flags for the same purpose. This moves alpha to the pci_flags approach so generic code can use the same test across all architectures. CC: linux-alpha@vger.kernel.org Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Alan Cox 提交于
The PCI fixups get executed based upon whether they are linked in. We need to avoid executing them if we boot a dual SoC/PC type kernel on a PC class system. Signed-off-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Jacob Pan 提交于
ATOMISP on Medfield is a real PCI device which should be handled differently than the fake PCI devices on south complex. PCI type 1 access is used for accessing config space this also has other impact such as PM D3 delay. There shouldn't be any need for reading base address from IUNIT via msg bus. Signed-off-by: NJacob Pan <jacob.jun.pan@linux.intel.com> Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Jacob Pan 提交于
Langwell devices are not true pci devices, they are not subject to the 10 ms d3 to d0 delay required by pci spec. This patch assigns d3_delay to 0 for all langwell pci devices. We can also power off devices that are not really used by the OS Signed-off-by: NJacob Pan <jacob.jun.pan@linux.intel.com> Signed-off-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 15 2月, 2012 3 次提交
-
-
由 Bjorn Helgaas 提交于
Host bridges that lead to things like the Uncore need not have any I/O port or MMIO apertures. For example, in this case: ACPI: PCI Root Bridge [UNC1] (domain 0000 [bus ff]) PCI: root bus ff: using default resources PCI host bridge to bus 0000:ff pci_bus 0000:ff: root bus resource [io 0x0000-0xffff] pci_bus 0000:ff: root bus resource [mem 0x00000000-0x3fffffffffff] we should not pretend those default resources are available on bus ff. CC: Yinghai Lu <yinghai@kernel.org> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Myron Stowe 提交于
This patch converts the underlying maintenance aspects of FW-assigned BIOS BAR values from a statically allocated array within struct pci_dev to a list of temporary, stand alone, entries. Signed-off-by: NMyron Stowe <myron.stowe@redhat.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Myron Stowe 提交于
Commit 58c84eda introduced functionality to try and reinstate the original BIOS BAR addresses of a PCI device when normal resource assignment attempts fail. To keep track of the BIOS BAR addresses, struct pci_dev was augmented with an array to hold the BAR addresses of the PCI device: 'resource_size_t fw_addr[DEVICE_COUNT_RESOURCE]'. The reinstatement of BAR addresses is an uncommon event leaving the 'fw_addr' array unused under normal circumstances. This functionality is also currently architecture specific with an implementation limited to x86. As the use of struct pci_dev is so prevalent, having the 'fw_addr' array residing within such seems somewhat wasteful. This patch introduces a stand alone data structure and interfacing routines for maintaining a list of FW-assigned BIOS BAR value entries. Signed-off-by: NMyron Stowe <myron.stowe@redhat.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 26 1月, 2012 6 次提交
-
-
由 Andreas Herrmann 提交于
We've decided to provide CPU family specific container files (starting with CPU family 15h). E.g. for family 15h we have to load microcode_amd_fam15h.bin instead of microcode_amd.bin Rationale is that starting with family 15h patch size is larger than 2KB which was hard coded as maximum patch size in various microcode loaders (not just Linux). Container files which include patches larger than 2KB cause different kinds of trouble with such old patch loaders. Thus we have to ensure that the default container file provides only patches with size less than 2KB. Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com> Cc: Borislav Petkov <borislav.petkov@amd.com> Cc: <stable@kernel.org> Link: http://lkml.kernel.org/r/20120120164412.GD24508@alberich.amd.com [ documented the naming convention and tidied the code a bit. ] Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Andreas Herrmann 提交于
That is the last one missing for those CPUs. Others were recently added with commits fb215366 (KVM: expose latest Intel cpu new features (BMI1/BMI2/FMA/AVX2) to guest) and commit 969df4b8 (x86: Report cpb and eff_freq_ro flags correctly) Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com> Link: http://lkml.kernel.org/r/20120120163823.GC24508@alberich.amd.comSigned-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Jesper Juhl 提交于
We allocate memory with malloc(), but neglect to free it before the variable 'phdrs' goes out of scope --> leak. Signed-off-by: NJesper Juhl <jj@chaosbits.net> Link: http://lkml.kernel.org/r/alpine.LNX.2.00.1201232332590.8772@swampdragon.chaosbits.net [ Mostly harmless. ] Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Daniel J Blueman 提交于
EDAC detection no longer crashes multi-node systems, so don't conflict on it with NumaChip. Signed-off-by: NDaniel J Blueman <daniel@numascale-asia.com> Cc: Steffen Persvold <sp@numascale.com> Link: http://lkml.kernel.org/r/1327473349-28395-1-git-send-email-daniel@numascale-asia.comSigned-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Cliff Wickman 提交于
Initialize two spinlocks in tlb_uv.c and also properly define/initialize the uv_irq_lock. The lack of explicit initialization seems to be functionally harmless, but it is diagnosed when these are turned on: CONFIG_DEBUG_SPINLOCK=y CONFIG_DEBUG_MUTEXES=y CONFIG_DEBUG_LOCK_ALLOC=y CONFIG_LOCKDEP=y Signed-off-by: NCliff Wickman <cpw@sgi.com> Cc: <stable@kernel.org> Cc: Dimitri Sivanich <sivanich@sgi.com> Link: http://lkml.kernel.org/r/E1RnXd1-0003wU-PM@eag09.americas.sgi.com [ Added the uv_irq_lock initialization fix by Dimitri Sivanich ] Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Russ Anderson 提交于
uv_gpa_to_soc_phys_ram() was inadvertently ignoring the shift values. This fix takes the shift into account. Signed-off-by: NRuss Anderson <rja@sgi.com> Cc: <stable@kernel.org> Link: http://lkml.kernel.org/r/20120119020753.GA7228@sgi.comSigned-off-by: NIngo Molnar <mingo@elte.hu>
-
- 25 1月, 2012 4 次提交
-
-
由 Benjamin Herrenschmidt 提交于
Commit 9deaa53a broke build on platforms that use legacy_serial.c without also having CONFIG_SERIAL_8250_FSL enabled due to an unconditional code to a routine in that module. Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Benjamin Herrenschmidt 提交于
Recent changes to the handling of PCI resources for host bridges are breaking the PowerNV code for assigning resources on IODA. The root of the problem is that the pci_bus attached to a host bridge no longer has its "legacy" resource pointers populated but only uses the newer list instead. Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Christian Kujau 提交于
I could not find cpus_in_crash anywhere in the sourcetree, except for arch/powerpc/kernel/crash.c. Moving the definition into the CONFIG_SMP fixes it. Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Deepthi Dharwar 提交于
As pointed out, asm/system.h has empty inline implementations for update_smt_snooze_delay and pseries_notify_cpuidle_add_cpu, which are used when CONFIG_PSERIES_IDLE is undefined. Since those two functions are used in core power architecture functions (store_smt_snooze_delay at kernel/sysfs.c and smp_xics_setup_cpu at platforms/pseries/smp.c), Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 24 1月, 2012 2 次提交
-
-
由 Dan Rosenberg 提交于
If the provided system call number is equal to __NR_syscalls, the current check will pass and a function pointer just after the system call table may be called, since sys_call_table is an array with total size __NR_syscalls. Whether or not this is a security bug depends on what the compiler puts immediately after the system call table. It's likely that this won't do anything bad because there is an additional NULL check on the syscall entry, but if there happens to be a non-NULL value immediately after the system call table, this may result in local privilege escalation. Signed-off-by: NDan Rosenberg <drosenberg@vsecurity.com> Cc: <stable@vger.kernel.org> Cc: Chen Liqin <liqin.chen@sunplusct.com> Cc: Lennox Wu <lennox.wu@gmail.com> Cc: Eugene Teo <eugeneteo@kernel.sg> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Michael Holzheu 提交于
kdump only allocates memory for the prstatus ELF note. For s390x, besides of prstatus multiple ELF notes for various different register types are stored. Therefore the currently allocated memory is not sufficient. With this patch the KEXEC_NOTE_BYTES macro can be defined by architecture code and for s390x it is set to the correct size now. Signed-off-by: NMichael Holzheu <holzheu@linux.vnet.ibm.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Vivek Goyal <vgoyal@redhat.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Reviewed-by: NSimon Horman <horms@verge.net.au> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 22 1月, 2012 2 次提交
-
-
由 Andreas Schwab 提交于
Passing the address of a variable as an operand to an asm statement doesn't mark the value of this variable as used, so gcc may optimize its initialisation away. Fix this by using the "m" constraint instead. Signed-off-by: NAndreas Schwab <schwab@linux-m68k.org> Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org> Cc: stable@vger.kernel.org
-
由 Geert Uytterhoeven 提交于
The m68k core irq code stopped honoring these flags during the irq restructuring in 2006. Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
-
- 20 1月, 2012 1 次提交
-
-
由 H. Peter Anvin 提交于
In checkin 303395ac x86: Generate system call tables and unistd_*.h from tables the feature macros in <asm/unistd.h> were unified between 32 and 64 bits. Unfortunately 32 bits requires __ARCH_WANT_SYS_IPC and this was inadvertently dropped. Reported-by: NDmitry Kasatkin <dmitry.kasatkin@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NH. Peter Anvin <hpa@zytor.com> Link: http://lkml.kernel.org/r/CALLzPKbeXN5gdngo8uYYU8mAow=XhrwBFBhKfG811f37BubQOg@mail.gmail.com
-
- 19 1月, 2012 2 次提交
-
-
由 Linus Torvalds 提交于
Randy Dunlap reports that we get arch/x86/um/shared/sysdep/ptrace.h:7:20: error: redefinition of 'regs_return_value' arch/x86/um/shared/sysdep/ptrace.h:7:20: note: previous definition of 'regs_return_value' was here when compiling UML for x86-64. Stephen Rothwell root-caused it and says: "Caused by commit d7e7528b ("Audit: push audit success and retcode into arch ptrace.h") (another patch that was never in linux-next :-(). This file now needs protection against double inclusion." so let's do as the man says. Reported-by: NRandy Dunlap <rdunlap@xenotime.net> Analyzed-by: NStephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Eric Dumazet 提交于
Several problems fixed in this patch : 1) Target of the conditional jump in case a divide by 0 is performed by a bpf is wrong. 2) Must 'generate' the full function prologue/epilogue at pass=0, or else we can stop too early in pass=1 if the proglen doesnt change. (if the increase of prologue/epilogue equals decrease of all instructions length because some jumps are converted to near jumps) 3) Change the wrong length detection at the end of code generation to issue a more explicit message, no need for a full stack trace. Reported-by: NPhil Oester <kernel@linuxace.com> Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 18 1月, 2012 10 次提交
-
-
由 Ramneek Mehresh 提交于
Add usb2 controller node for P1020RDB, P2020RDB, P2020DS, P1021MDS Signed-off-by: NRamneek Mehresh <ramneek.mehresh@freescale.com> Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
-
由 Ramneek Mehresh 提交于
Enable USB2 controller node for P1020RDB. USB2 controller is used only when board boots from SPI or SD as it is muxed with eLBC Signed-off-by: NRamneek Mehresh <ramneek.mehresh@freescale.com> Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
-
由 Jerry Huang 提交于
According to latest kernel, the auto-cmd12 property should be "sdhci,auto-cmd12", and according to the SDHC binding and the workaround for the special chip, add the chip compatible for eSDHC: "fsl,p1022-esdhc", "fsl,mpc8536-esdhc", "fsl,p1020-esdhc", "fsl,p2020-esdhc" and "fsl,p1010-esdhc". Signed-off-by: NJerry Huang <Chang-Ming.Huang@freescale.com> Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
-
由 Al Viro 提交于
JONGMAN HEO reports: With current linus git (commit a25a2b84), I got following build error, arch/x86/kernel/vm86_32.c: In function 'do_sys_vm86': arch/x86/kernel/vm86_32.c:340: error: implicit declaration of function '__audit_syscall_exit' make[3]: *** [arch/x86/kernel/vm86_32.o] Error 1 OK, I can reproduce it (32bit allmodconfig with AUDIT=y, AUDITSYSCALL=n) It's due to commit d7e7528b: "Audit: push audit success and retcode into arch ptrace.h". Reported-by: NJONGMAN HEO <jongman.heo@samsung.com> Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Linus Torvalds 提交于
pit_expect_msb() returns success wrongly in the below SMI scenario: a. pit_verify_msb() has not yet seen the MSB transition. b. we are close to the MSB transition though and got a SMI immediately after returning from pit_verify_msb() which didn't see the MSB transition. PIT MSB transition has happened somewhere during SMI execution. c. returned from SMI and we noted down the 'tsc', saw the pit MSB change now and exited the loop to calculate 'deltatsc'. Instead of noting the TSC at the MSB transition, we are way off because of the SMI. And as the SMI happened between the pit_verify_msb() and before the 'tsc' is recorded in the for loop, 'delattsc' (d1/d2 in quick_pit_calibrate()) will be small and quick_pit_calibrate() will not notice this error. Depending on whether SMI disturbance happens while computing d1 or d2, we will see the TSC calibrated value smaller or bigger than the expected value. As a result, in a cluster we were seeing a variation of approximately +/- 20MHz in the calibrated values, resulting in NTP failures. [ As far as the SMI source is concerned, this is a periodic SMI that gets disabled after ACPI is enabled by the OS. But the TSC calibration happens before the ACPI is enabled. ] To address this, change pit_expect_msb() so that - the 'tsc' is the TSC in between the two reads that read the MSB change from the PIT (same as before) - the 'delta' is the difference in TSC from *before* the MSB changed to *after* the MSB changed. Now the delta is twice as big as before (it covers four PIT accesses, roughly 4us) and quick_pit_calibrate() will loop a bit longer to get the calibrated value with in the 500ppm precision. As the delta (d1/d2) covers four PIT accesses, actual calibrated result might be closer to 250ppm precision. As the loop now takes longer to stabilize, double MAX_QUICK_PIT_MS to 50. SMI disturbance will showup as much larger delta's and the loop will take longer than usual for the result to be with in the accepted precision. Or will fallback to slow PIT calibration if it takes more than 50msec. Also while we are at this, remove the calibration correction that aims to get the result to the middle of the error bars. We really don't know which direction to correct into, so remove it. Reported-and-tested-by: NSuresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com> Link: http://lkml.kernel.org/r/1326843337.5291.4.camel@sbsiddha-mobl2Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
-
由 Nathaniel Husted 提交于
This patch provides functionality to audit system call events on the ARM platform. The implementation was based off the structure of the MIPS platform and information in this (http://lists.fedoraproject.org/pipermail/arm/2009-October/000382.html) mailing list thread. The required audit_syscall_exit and audit_syscall_entry checks were added to ptrace using the standard registers for system call values (r0 through r3). A thread information flag was added for auditing (TIF_SYSCALL_AUDIT) and a meta-flag was added (_TIF_SYSCALL_WORK) to simplify modifications to the syscall entry/exit. Now, if either the TRACE flag is set or the AUDIT flag is set, the syscall_trace function will be executed. The prober changes were made to Kconfig to allow CONFIG_AUDITSYSCALL to be enabled. Due to platform availability limitations, this patch was only tested on the Android platform running the modified "android-goldfish-2.6.29" kernel. A test compile was performed using Code Sourcery's cross-compilation toolset and the current linux-3.0 stable kernel. The changes compile without error. I'm hoping, due to the simple modifications, the patch is "obviously correct". Signed-off-by: NNathaniel Husted <nhusted@gmail.com> Signed-off-by: NEric Paris <eparis@redhat.com>
-
由 Eric Paris 提交于
Every arch calls: if (unlikely(current->audit_context)) audit_syscall_entry() which requires knowledge about audit (the existance of audit_context) in the arch code. Just do it all in static inline in audit.h so that arch's can remain blissfully ignorant. Signed-off-by: NEric Paris <eparis@redhat.com>
-
由 Eric Paris 提交于
In the ia32entry syscall exit audit fastpath we have assembly code which calls __audit_syscall_exit directly. This code was, however, zeroes the upper 32 bits of the return code. It then proceeded to call code which expects longs to be 64bits long. In order to handle code which expects longs to be 64bit we sign extend the return code if that code is an error. Thus the __audit_syscall_exit function can correctly handle using the values in snprintf("%ld"). This fixes the regression introduced in 5cbf1565. Old record: type=SYSCALL msg=audit(1306197182.256:281): arch=40000003 syscall=192 success=no exit=4294967283 New record: type=SYSCALL msg=audit(1306197182.256:281): arch=40000003 syscall=192 success=no exit=-13 Signed-off-by: NEric Paris <eparis@redhat.com> Acked-by: NH. Peter Anvin <hpa@zytor.com>
-
由 Eric Paris 提交于
The audit system previously expected arches calling to audit_syscall_exit to supply as arguments if the syscall was a success and what the return code was. Audit also provides a helper AUDITSC_RESULT which was supposed to simplify things by converting from negative retcodes to an audit internal magic value stating success or failure. This helper was wrong and could indicate that a valid pointer returned to userspace was a failed syscall. The fix is to fix the layering foolishness. We now pass audit_syscall_exit a struct pt_reg and it in turns calls back into arch code to collect the return value and to determine if the syscall was a success or failure. We also define a generic is_syscall_success() macro which determines success/failure based on if the value is < -MAX_ERRNO. This works for arches like x86 which do not use a separate mechanism to indicate syscall failure. We make both the is_syscall_success() and regs_return_value() static inlines instead of macros. The reason is because the audit function must take a void* for the regs. (uml calls theirs struct uml_pt_regs instead of just struct pt_regs so audit_syscall_exit can't take a struct pt_regs). Since the audit function takes a void* we need to use static inlines to cast it back to the arch correct structure to dereference it. The other major change is that on some arches, like ia64, MIPS and ppc, we change regs_return_value() to give us the negative value on syscall failure. THE only other user of this macro, kretprobe_example.c, won't notice and it makes the value signed consistently for the audit functions across all archs. In arch/sh/kernel/ptrace_64.c I see that we were using regs[9] in the old audit code as the return value. But the ptrace_64.h code defined the macro regs_return_value() as regs[3]. I have no idea which one is correct, but this patch now uses the regs_return_value() function, so it now uses regs[3]. For powerpc we previously used regs->result but now use the regs_return_value() function which uses regs->gprs[3]. regs->gprs[3] is always positive so the regs_return_value(), much like ia64 makes it negative before calling the audit code when appropriate. Signed-off-by: NEric Paris <eparis@redhat.com> Acked-by: H. Peter Anvin <hpa@zytor.com> [for x86 portion] Acked-by: Tony Luck <tony.luck@intel.com> [for ia64] Acked-by: Richard Weinberger <richard@nod.at> [for uml] Acked-by: David S. Miller <davem@davemloft.net> [for sparc] Acked-by: Ralf Baechle <ralf@linux-mips.org> [for mips] Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> [for ppc]
-
由 Ulrich Drepper 提交于
The Intel documentation at http://software.intel.com/file/36945 shows the ANDN opcode and Group 17 with encoding f2 and f3 encoding respectively. The current version of x86-opcode-map.txt shows them with f3 and f4. Unless someone can point to documentation which shows the currently used encoding the following patch be applied. Signed-off-by: NUlrich Drepper <drepper@gmail.com> Link: http://lkml.kernel.org/r/CAOPLpQdq5SuVo9=023CYhbFLAX9rONyjmYq7jJkqc5xwctW5eA@mail.gmail.comSigned-off-by: NH. Peter Anvin <hpa@zytor.com>
-