01 Feb, 2013
1 commit
-
Pull MIPS updates from Ralf Baechle:
"A number of fixes all across the MIPS tree. No area is particularly
standing out and things have cooled down quite nicely for a release."* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
MIPS: Function tracer: Fix broken function tracing
mips: Move __virt_addr_valid() to a place for MIPS 64
MIPS: Netlogic: Fix UP compilation on XLR
MIPS: AR71xx: Fix AR71XX_PCI_MEM_SIZE
MIPS: AR724x: Fix AR724X_PCI_MEM_SIZE
MIPS: Lantiq: Fix cp0_perfcount_irq mapping
MIPS: DSP: Fix DSP mask for registers.
MIPS: Fix build failure by adding definition of pfn_pmd().
MIPS: Octeon: Fix warning.
MIPS: delay.c: Check BITS_PER_LONG instead of __SIZEOF_LONG__
MIPS: PNX833x: Fix comment.
MIPS: Add struct p_format to union mips_instruction.
MIPS: Export .
MIPS: BCM47xx: Enable SSB prerequisite SSB_DRIVER_PCICORE.
MIPS: BCM47xx: Select GPIOLIB for BCMA on bcm47xx platform
MIPS: vpe.c: Fix null pointer dereference in print arguments.
31 Jan, 2013
10 commits
-
Function tracing is currently broken for all 32 bit MIPS platforms.
When tracing is enabled, the kernel immediately hangs on boot.
This is a result of commit b732d439cb43336cd6d7e804ecb2c81193ef63b0
that changes the kernel/trace/Kconfig file so that is no longer
forces FRAME_POINTER when FUNCTION_TRACING is enabled.MIPS frame pointers are generally considered to be useless because
they cannot be used to unwind the stack. Unfortunately the MIPS
function tracing code has bugs that are masked by the use of frame
pointers. This commit fixes the bugs so that MIPS frame pointers
don't need to be enabled.The bugs are a result of the odd calling sequence used to call the trace
routine. This calling sequence is inserted into every traceable function
when the tracing CONFIG option is enabled. This sequence is generated
for 32bit MIPS platforms by the compiler via the "-pg" flag.Part of the sequence is "addiu sp,sp,-8" in the delay slot after every
call to the trace routine "_mcount" (some legacy thing where 2 arguments
used to be pushed on the stack). The _mcount routine is expected to
adjust the sp by +8 before returning. So when not disabled, the original
jalr and addiu will be there, so _mcount has to adjust sp.The problem is that when tracing is disabled for a function, the
"jalr _mcount" instruction is replaced with a nop, but the
"addiu sp,sp,-8" is still executed and the stack pointer is left
trashed. When frame pointers are enabled the problem is masked
because any access to the stack is done through the frame
pointer and the stack pointer is restored from the frame pointer when
the function returns.This patch writes two nops starting at the address of the "jalr _mcount"
instruction whenever tracing is disabled. This means that the
"addiu sp,sp.-8" will be converted to a nop along with the "jalr". When
disabled, there will be two nops.This is SMP safe because the first time this happens is during
ftrace_init() which is before any other processor has been started.
Subsequent calls to enable/disable tracing when other CPUs ARE running
will still be safe because the enable will only change the first nop
to a "jalr" and the disable, while writing 2 nops, will only be changing
the "jalr". This patch also stops using stop_machine() to call the
tracer enable/disable routines and calls them directly because the
routines are SMP safe.When the kernel first boots we have to be able to handle the gcc
generated jalr, addui sequence until ftrace_init gets a chance to run
and change the sequence. At this point mcount just adjusts the stack
and returns. When ftrace_init runs, we convert the jalr/addui to nops.
Then whenever tracing is enabled we convert the first nop to a "jalr
mcount+8". The mcount+8 entry point skips the stack adjust.[ralf@linux-mips.org: Folded in Steven Rostedt's build fix.]
Signed-off-by: Al Cooper
Cc: rostedt@goodmis.org
Cc: ddaney.cavm@gmail.com
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/4806/
Patchwork: https://patchwork.linux-mips.org/patch/4841/
Signed-off-by: Ralf Baechle -
Commit d3ce88431892 "MIPS: Fix modpost error in modules attepting to use
virt_addr_valid()" moved __virt_addr_valid() from a macro in a header
file to a function in ioremap.c. But ioremap.c is only compiled for MIPS
32, and not for MIPS 64.When compiling for my yeeloong2, which supposedly supports hibernation,
which compiles kernel/power/snapshot.c which calls virt_addr_valid(), I
got this error:LD init/built-in.o
kernel/built-in.o: In function `memory_bm_free':
snapshot.c:(.text+0x4c9c4): undefined reference to `__virt_addr_valid'
snapshot.c:(.text+0x4ca58): undefined reference to `__virt_addr_valid'
kernel/built-in.o: In function `snapshot_write_next':
(.text+0x4e44c): undefined reference to `__virt_addr_valid'
kernel/built-in.o: In function `snapshot_write_next':
(.text+0x4e890): undefined reference to `__virt_addr_valid'
make[1]: *** [vmlinux] Error 1
make: *** [sub-make] Error 2I suspect that __virt_addr_valid() is fine for mips 64. I moved it to
mmap.c such that it gets compiled for mips 64 and 32.Signed-off-by: Steven Rostedt
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/4842/
Signed-off-by: Ralf Baechle -
Pull x86 EFI fixes from Peter Anvin:
"This is a collection of fixes for the EFI support. The controversial
bit here is a set of patches which bumps the boot protocol version as
part of fixing some serious problems with the EFI handover protocol,
used when booting under EFI using a bootloader as opposed to directly
from EFI. These changes should also make it a lot saner to support
cross-mode 32/64-bit EFI booting in the future. Getting these changes
into 3.8 means we avoid presenting an inconsistent ABI to bootloaders.Other changes are display detection and fixing efivarfs."
* 'x86-efi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86, efi: remove attribute check from setup_efi_pci
x86, build: Dynamically find entry points in compressed startup code
x86, efi: Fix PCI ROM handing in EFI boot stub, in 32-bit mode
x86, efi: Fix 32-bit EFI handover protocol entry point
x86, efi: Fix display detection in EFI boot stub
x86, boot: Define the 2.12 bzImage boot protocol
x86/boot: Fix minor fd leakage in tools/relocs.c
x86, efi: Set runtime_version to the EFI spec revision
x86, efi: fix 32-bit warnings in setup_efi_pci()
efivarfs: Delete dentry from dcache in efivarfs_file_write()
efivarfs: Never return ENOENT from firmware
efi, x86: Pass a proper identity mapping in efi_call_phys_prelog
efivarfs: Drop link count of the right inode -
Pull x86 fixes from Peter Anvin:
"This is a collection of miscellaneous fixes, the most important one is
the fix for the Samsung laptop bricking issue (auto-blacklisting the
samsung-laptop driver); the efi_enabled() changes you see below are
prerequisites for that fix.The other issues fixed are booting on OLPC XO-1.5, an UV fix, NMI
debugging, and requiring CAP_SYS_RAWIO for MSR references, just as
with I/O port references."* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
samsung-laptop: Disable on EFI hardware
efi: Make 'efi_enabled' a function to query EFI facilities
smp: Fix SMP function call empty cpu mask race
x86/msr: Add capabilities check
x86/dma-debug: Bump PREALLOC_DMA_DEBUG_ENTRIES
x86/olpc: Fix olpc-xo1-sci.c build errors
arch/x86/platform/uv: Fix incorrect tlb flush all issue
x86-64: Fix unwind annotations in recent NMI changes
x86-32: Start out cr0 clean, disable paging before modifying cr3/4 -
Various urgent EFI fixes and some warning cleanups for v3.8
* EFI boot stub fix for Macbook Pro's from Maarten Lankhorst
* Fix an oops in efivarfs from Lingzhu Xiang
* 32-bit warning cleanups from Jan Beulich
* Patch to Boot on >512GB RAM systems from Nathan Zimmer
* Set efi.runtime_version correctly
* efivarfs updatesSigned-off-by: H. Peter Anvin
-
The commit 2a37b1a "MIPS: Netlogic: Move from u32 cpumask to cpumask_t"
breaks uniprocessor compilation on XLR with:arch/mips/netlogic/xlr/setup.c: In function 'prom_init':
arch/mips/netlogic/xlr/setup.c:196:6: error: unused variable 'i'Fix by defining 'i' only when CONFIG_SMP is defined.
Signed-off-by: Jayachandran C
Patchwork: http://patchwork.linux-mips.org/patch/4760/
Signed-off-by: John Crispin
Signed-off-by: Ralf Baechle -
The base address of the PCI memory is 0x10000000 and the base address of the
PCI configuration space is 0x17000000 on the AR71xx SoCs.The AR71XX_PCI_MEM_SIZE is defined as 0x08000000 which is wrong because that
overlaps with the configuration space. This patch fixes the value of the
AR71XX_PCI_MEM_SIZE constant, in order to avoid this resource conflicts.Signed-off-by: Gabor Juhos
Patchwork: http://patchwork.linux-mips.org/patch/4873/
Signed-off-by: John Crispin
Signed-off-by: Ralf Baechle -
The base address of the PCI memory is
0x10000000 and the base address of the
PCI configuration space is 0x14000000
on the AR724x SoCs.The AR724X_PCI_MEM_SIZE is defined as
0x08000000 which is wrong because that
overlaps with the configuration space.The patch fixes the value of the
AR724X_PCI_MEM_SIZE constant, in order
to avoid this resource conflicts.Signed-off-by: Gabor Juhos
Patchwork: http://patchwork.linux-mips.org/patch/4872/
Signed-off-by: John Crispin
Signed-off-by: Ralf Baechle -
The introduction of the OF support broke the cp0_perfcount_irq mapping. This
resulted in oprofile not working anymore.Offending commit is :
commit 3645da0276ae9f6938ff29b13904b803ecb68424
Author: John Crispin
Date: Tue Apr 17 10:18:32 2012 +0200OF: MIPS: lantiq: implement irq_domain support
Signed-off-by: Conor O'Gorman
Signed-off-by: John Crispin
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/4875/
Signed-off-by: Ralf Baechle -
Originally 'efi_enabled' indicated whether a kernel was booted from
EFI firmware. Over time its semantics have changed, and it now
indicates whether or not we are booted on an EFI machine with
bit-native firmware, e.g. 64-bit kernel with 64-bit firmware.The immediate motivation for this patch is the bug report at,
https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557
which details how running a platform driver on an EFI machine that is
designed to run under BIOS can cause the machine to become
bricked. Also, the following report,https://bugzilla.kernel.org/show_bug.cgi?id=47121
details how running said driver can also cause Machine Check
Exceptions. Drivers need a new means of detecting whether they're
running on an EFI machine, as sadly the expression,if (!efi_enabled)
hasn't been a sufficient condition for quite some time.
Users actually want to query 'efi_enabled' for different reasons -
what they really want access to is the list of available EFI
facilities.For instance, the x86 reboot code needs to know whether it can invoke
the ResetSystem() function provided by the EFI runtime services, while
the ACPI OSL code wants to know whether the EFI config tables were
mapped successfully. There are also checks in some of the platform
driver code to simply see if they're running on an EFI machine (which
would make it a bad idea to do BIOS-y things).This patch is a prereq for the samsung-laptop fix patch.
Cc: David Airlie
Cc: Corentin Chary
Cc: Matthew Garrett
Cc: Dave Jiang
Cc: Olof Johansson
Cc: Peter Jones
Cc: Colin Ian King
Cc: Steve Langasek
Cc: Tony Luck
Cc: Konrad Rzeszutek Wilk
Cc: Rafael J. Wysocki
Cc:
Signed-off-by: Matt Fleming
Signed-off-by: H. Peter Anvin
30 Jan, 2013
2 commits
-
Pull one s390 fix from Martin Schwidefsky:
"Another transparent huge page fix, we need to define a s390 variant
for pmdp_set_wrprotect to flush the TLB for the huge page correctly."* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
s390/thp: implement pmdp_set_wrprotect() -
It looks like the original commit that copied the rom contents from
efi always copied the rom, and the fixup in setup_efi_pci from commit
886d751a2ea99a160 ("x86, efi: correct precedence of operators in
setup_efi_pci") broke that.This resulted in macbook pro's no longer finding the rom images, and
thus not being able to use the radeon card any more.The solution is to just remove the check for now, and always copy the
rom if available.Reported-by: Vitaly Budovski
Cc: Dan Carpenter
Cc: Seth Forshee
Acked-by: Matthew Garrett
Cc: Bjorn Helgaas
Cc: Sasha Levin
Signed-off-by: Maarten Lankhorst
Signed-off-by: Matt Fleming
29 Jan, 2013
6 commits
-
With lazy interrupt, we always call __check_irq_replaysome with
decrementers_next_tb to check if we need to replay timer interrupt.
So in hotplug case we also need to set decrementers_next_tb as MAX
to make sure __check_irq_replay don't replay timer interrupt
when return as we expect, otherwise we'll trap here infinitely.Signed-off-by: Tiejun Chen
Signed-off-by: Benjamin Herrenschmidt -
the variable backup_current_thread_info isn't freed before existing the
function.Signed-off-by: Cong Ding
Signed-off-by: Benjamin Herrenschmidt -
In preempt case current arch_local_irq_restore() from
preempt_schedule_irq() may enable hard interrupt but we really
should disable interrupts when we return from the interrupt,
and so that we don't get interrupted after loading SRR0/1.Signed-off-by: Tiejun Chen
CC:
Signed-off-by: Benjamin Herrenschmidt -
The calculation for the left shift of the mask OPROFILE_PM_PMCSEL_MSK has an
error. The calculation is should be to shift left by (max_cntrs - cntr) times
the width of the pmsel field width. However, the #define OPROFILE_MAX_PMC_NUM
was used instead of OPROFILE_PMSEL_FIELD_WIDTH. This patch fixes the
calculation.Signed-off-by: Carl Love
Acked-by: Paul Mackerras
Signed-off-by: Benjamin Herrenschmidt -
commit f96972f2dc "kernel/sys.c: call disable_nonboot_cpus() in
kernel_restart()"added a call to disable_nonboot_cpus() on kernel_restart(), which tries
to shutdown all the CPUs except the first one. The issue with the PA
Semi, is that it does not support CPU hotplug.When the call is made to __cpu_down(), it calls the notifiers
CPU_DOWN_PREPARE, and then tries to take the CPU down.One of the notifiers to the CPU hotplug code, is the cpufreq. The
DOWN_PREPARE will call __cpufreq_remove_dev() which calls
cpufreq_driver->exit. The PA Semi exit handler unmaps regions of I/O
that is used by an interrupt that goes off constantly
(system_reset_common, but it goes off during normal system operations
too). I'm not sure exactly what this interrupt does.Running a simple function trace, you can see it goes off quite a bit:
# tracer: function
#
# TASK-PID CPU# TIMESTAMP FUNCTION
# | | | | |
-0 [001] 1558.859363: .pasemi_system_reset_exception -0 [000] 1558.860112: .pasemi_system_reset_exception -0 [000] 1558.861109: .pasemi_system_reset_exception -0 [001] 1558.861361: .pasemi_system_reset_exception -0 [000] 1558.861437: .pasemi_system_reset_exception CR: 24000088 XER: 00000000
SOFTE: 0
DAR: d0000800903a0100, DSISR: 42000000
TASK = c0000000010e9008[0] 'swapper/0' THREAD: c000000001214000 CPU: 0
GPR00: d0000800903a0000 c000000001217850 c0000000012167e0 0000000000000000
GPR04: 0000000000000000 0000000000000724 0000000000000724 0000000000000000
GPR08: 0000000000000000 0000000000000000 0000000000000001 0000000000a70000
GPR12: 0000000024000080 c00000000fff0000 ffffffffffffffff 000000003ffffae0
GPR16: ffffffffffffffff 0000000000a21198 0000000000000060 0000000000000000
GPR20: 00000000008fdd35 0000000000a21258 000000003ffffaf0 0000000000000417
GPR24: 0000000000a226d0 c000000000000000 0000000000000000 0000000000000000
GPR28: c00000000138b358 0000000000000000 c000000001144818 d0000800903a0100
NIP [c000000000055fcc] .set_astate+0x5c/0xa4
LR [c000000000055fb4] .set_astate+0x44/0xa4
Call Trace:
[c000000001217850] [c000000000055fb4] .set_astate+0x44/0xa4 (unreliable)
[c0000000012178f0] [c00000000005647c] .restore_astate+0x2c/0x34
[c000000001217980] [c000000000054668] .pasemi_system_reset_exception+0x6c/0x88
[c000000001217a00] [c000000000019ef0] .system_reset_exception+0x48/0x84
[c000000001217a80] [c000000000001e40] system_reset_common+0x140/0x180Signed-off-by: Benjamin Herrenschmidt
-
This patch fixes MAX_STACK_TRACE_ENTRIES too low warning for ppc32,
which is similar to commit 12660b17.Reported-by: Christian Kujau
Signed-off-by: Li Zhong
Tested-by: Christian Kujau
Signed-off-by: Benjamin Herrenschmidt
28 Jan, 2013
6 commits
-
We have historically hard-coded entry points in head.S just so it's easy
to build the executable/bzImage headers with references to them.Unfortunately, this leads to boot loaders abusing these "known" addresses
even when they are *explicitly* told that they "should look at the ELF
header to find this address, as it may change in the future". And even
when the address in question *has* actually been changed in the past,
without fanfare or thought to compatibility.Thus we have bootloaders doing stunningly broken things like jumping
to offset 0x200 in the kernel startup code in 64-bit mode, *hoping*
that startup_64 is still there (it has moved at least once
before). And hoping that it's actually a 64-bit kernel despite the
fact that we don't give them any indication of that fact.This patch should hopefully remove the temptation to abuse internal
addresses in future, where sternly worded comments have not sufficed.
Instead of having hard-coded addresses and saying "please don't abuse
these", we actually pull the addresses out of the ELF payload into
zoffset.h, and make build.c shove them back into the right places in
the bzImage header.Rather than including zoffset.h into build.c and thus having to rebuild
the tool for every kernel build, we parse it instead. The parsing code
is small and simple.This patch doesn't actually move any of the interesting entry points, so
any offending bootloader will still continue to "work" after this patch
is applied. For some version of "work" which includes jumping into the
compressed payload and crashing, if the bzImage it's given is a 32-bit
kernel. No change there then.[ hpa: some of the issues in the description are addressed or
retconned by the 2.12 boot protocol. This patch has been edited to
only remove fixed addresses that were *not* thus retconned. ]Signed-off-by: David Woodhouse
Link: http://lkml.kernel.org/r/1358513837.2397.247.camel@shinybook.infradead.org
Signed-off-by: H. Peter Anvin
Cc: Matt Fleming -
The 'Attributes' argument to pci->Attributes() function is 64-bit. So
when invoking in 32-bit mode it takes two registers, not just one.This fixes memory corruption when booting via the 32-bit EFI boot stub.
Signed-off-by: David Woodhouse
Cc:
Link: http://lkml.kernel.org/r/1358513837.2397.247.camel@shinybook.infradead.org
Signed-off-by: H. Peter Anvin
Cc: Matt Fleming -
If the bootloader calls the EFI handover entry point as a standard function
call, then it'll have a return address on the stack. We need to pop that
before calling efi_main(), or the arguments will all be out of position on
the stack.Signed-off-by: David Woodhouse
Cc:
Link: http://lkml.kernel.org/r/1358513837.2397.247.camel@shinybook.infradead.org
Signed-off-by: H. Peter Anvin
Cc: Matt Fleming -
When booting under OVMF we have precisely one GOP device, and it
implements the ConOut protocol.We break out of the loop when we look at it... and then promptly abort
because 'first_gop' never gets set. We should set first_gop *before*
breaking out of the loop. Yes, it doesn't really mean "first" any more,
but that doesn't matter. It's only a flag to indicate that a suitable
GOP was found.In fact, we'd do just as well to initialise 'width' to zero in this
function, then just check *that* instead of first_gop. But I'll do the
minimal fix for now (and for stable@).Signed-off-by: David Woodhouse
Cc:
Link: http://lkml.kernel.org/r/1358513837.2397.247.camel@shinybook.infradead.org
Signed-off-by: H. Peter Anvin
Cc: Matt Fleming -
Define the 2.12 bzImage boot protocol: add xloadflags and additional
fields to allow the command line, initramfs and struct boot_params to
live above the 4 GiB mark.The xloadflags now communicates if this is a 64-bit kernel with the
legacy 64-bit entry point and which of the EFI handover entry points
are supported.Avoid adding new read flags to loadflags because of claimed
bootloaders testing the whole byte for == 1 to determine bzImageness
at least until the issue can be researched further.This is based on patches by Yinghai Lu and David Woodhouse.
Originally-by: Yinghai Lu
Originally-by: David Woodhouse
Acked-by: Yinghai Lu
Acked-by: David Woodhouse
Acked-by: Matt Fleming
Signed-off-by: H. Peter Anvin
Link: http://lkml.kernel.org/r/1359058816-7615-26-git-send-email-yinghai@kernel.org
Cc: Rob Landley
Cc: Gokul Caushik
Cc: Josh Triplett
Cc: Joe Millenbach -
The opened file should be closed.
Signed-off-by: Cong Ding
Cc: Kusanagi Kouichi
Cc: Jarkko Sakkinen
Cc: Jiri Kosina
Cc: Matt Fleming
Link: http://lkml.kernel.org/r/1358183628-27784-1-git-send-email-dinggnu@gmail.com
Signed-off-by: Ingo Molnar
25 Jan, 2013
8 commits
-
efi.runtime_version is erroneously being set to the value of the
vendor's firmware revision instead of that of the implemented EFI
specification. We can't deduce which EFI functions are available based
on the revision of the vendor's firmware since the version scheme is
likely to be unique to each vendor.What we really need to know is the revision of the implemented EFI
specification, which is available in the EFI System Table header.Cc: Seiji Aguchi
Cc: Matthew Garrett
Cc: stable@vger.kernel.org # 3.7.x
Signed-off-by: Matt Fleming -
Fix four similar build warnings on 32-bit (casts between different
size pointers and integers).Signed-off-by: Jan Beulich
Cc: Borislav Petkov
Cc: Stefan Hasko
Signed-off-by: Matt Fleming -
Pull kvm fixlet from Marcelo Tosatti.
* git://git.kernel.org/pub/scm/virt/kvm/kvm:
KVM: PPC: Emulate dcbf -
Pull ARM fixes from Russell King:
"A number of fixes:Patrik found a problem with preempt counting in the VFP assembly
functions which can cause the preempt count to be upset.Nicolas fixed a problem with the parsing of the DT when it straddles a
1MB boundary.Subhash Jadavani reported a problem with sparsemem and our highmem
support for cache maintanence for DMA areas, and TI found a bug in
their strongly ordered memory mapping type.Also, three fixes by way of Will Deacon's tree from Dave Martin for
instruction compatibility and Marc Zyngier to fix hypervisor boot mode
issues."* 'fixes' of git://git.linaro.org/people/rmk/linux-arm:
ARM: 7629/1: mm: Fix missing XN flag for for MT_MEMORY_SO
ARM: DMA: Fix struct page iterator in dma_cache_maint() to work with sparsemem
ARM: 7628/1: head.S: map one extra section for the ATAG/DTB area
ARM: 7627/1: Predicate preempt logic on PREEMP_COUNT not PREEMPT alone
ARM: virt: simplify __hyp_stub_install epilog
ARM: virt: boot secondary CPUs through the right entry point
ARM: virt: Avoid bx instruction for compatibility with <=ARMv4 -
Pull ARM SoC fixes from Olof Johansson:
"Here's a long-pending fixes pull request for arm-soc (I didn't send
one in the -rc4 cycle).The larger deltas are from:
- A fixup of error paths in the mvsdio driver
- Header file move for a driver that hadn't been properly converted
to multiplatform on i.MX, which was causing build failures when
included- Device tree updates for at91 dealing mostly with their new pinctrl
setup merged in 3.8 and mistakes in those initial configsThe rest are the normal mix of small fixes all over the place; sunxi,
omap, imx, mvebu, etc, etc."* tag 'fixes-for-linus2' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (40 commits)
mfd: vexpress-sysreg: Don't skip initialization on probe
ARM: vexpress: Enable A7 cores in V2P-CA15_A7's Device Tree
ARM: vexpress: extend the MPIDR range used for pen release check
ARM: at91/dts: correct comment in at91sam9x5.dtsi for mii
ARM: at91/at91_dt_defconfig: add at91sam9n12 SoC to DT defconfig
ARM: at91/at91_dt_defconfig: remove memory specification to cmdline
ARM: at91/dts: add macb mii pinctrl config for kizbox
ARM: at91: rm9200: remake the BGA as default version
ARM: at91: fix gpios on i2c-gpio for RM9200 DT
ARM: at91/at91sam9x5 DTS: add SCK USART pins
ARM: at91/at91sam9x5 DTS: correct wrong PIO BANK values on u(s)arts
ARM: at91/at91-pinctrl documentation: fix typo and add some details
ARM: kirkwood: fix missing #interrupt-cells property
mmc: mvsdio: use devm_ API to simplify/correct error paths.
clk: mvebu/clk-cpu.c: fix memory leakage
ARM: OMAP2+: omap4-panda: add UART2 muxing for WiLink shared transport
ARM: OMAP2+: DT node Timer iteration fix
ARM: OMAP2+: Fix section warning for omap_init_ocp2scp()
ARM: OMAP2+: fix build break for omapdrm
ARM: OMAP2: Fix missing omap2xxx_clkt_vps_late_init function calls
... -
At the moment the MSR driver only relies upon file system
checks. This means that anything as root with any capability set
can write to MSRs. Historically that wasn't very interesting but
on modern processors the MSRs are such that writing to them
provides several ways to execute arbitary code in kernel space.
Sample code and documentation on doing this is circulating and
MSR attacks are used on Windows 64bit rootkits already.In the Linux case you still need to be able to open the device
file so the impact is fairly limited and reduces the security of
some capability and security model based systems down towards
that of a generic "root owns the box" setup.Therefore they should require CAP_SYS_RAWIO to prevent an
elevation of capabilities. The impact of this is fairly minimal
on most setups because they don't have heavy use of
capabilities. Those using SELinux, SMACK or AppArmor rules might
want to consider if their rulesets on the MSR driver could be
tighter.Signed-off-by: Alan Cox
Cc: Linus Torvalds
Cc: Andrew Morton
Cc: Peter Zijlstra
Cc: Horses
Signed-off-by: Ingo Molnar -
I ran out of free entries when I had CONFIG_DMA_API_DEBUG
enabled. Some other archs seem to default to 65536, so increase
this limit for x86 too.Signed-off-by: Maarten Lankhorst
Cc: Bjorn Helgaas
Link: http://lkml.kernel.org/r/50A612AA.7040206@canonical.com
Signed-off-by: Ingo Molnar
---- -
From Pawel Moll:
- makes the V2P-CA15_A7 (a.k.a. TC2) work with 3.8 kernels
- improves vexpress-sysreg.c behaviour on arm64 platforms* 'vexpress/fixes' of git://git.linaro.org/people/pawelmoll/linux:
mfd: vexpress-sysreg: Don't skip initialization on probe
ARM: vexpress: Enable A7 cores in V2P-CA15_A7's Device Tree
ARM: vexpress: extend the MPIDR range used for pen release check
24 Jan, 2013
7 commits
-
From Nicolas Ferre:
Here are fixes for AT91 that are mainly related to device tree.
One RM9200 setup option is the only C code change.
Some documentation changes can clarify the pinctrl use.
Then, some defconfig modifications are allowing the affected platforms
to boot.* tag 'at91-fixes' of git://github.com/at91linux/linux-at91:
ARM: at91/dts: correct comment in at91sam9x5.dtsi for mii
ARM: at91/at91_dt_defconfig: add at91sam9n12 SoC to DT defconfig
ARM: at91/at91_dt_defconfig: remove memory specification to cmdline
ARM: at91/dts: add macb mii pinctrl config for kizbox
ARM: at91: rm9200: remake the BGA as default version
ARM: at91: fix gpios on i2c-gpio for RM9200 DT
ARM: at91/at91sam9x5 DTS: add SCK USART pins
ARM: at91/at91sam9x5 DTS: correct wrong PIO BANK values on u(s)arts
ARM: at91/at91-pinctrl documentation: fix typo and add some details -
Fix build errors when CONFIG_INPUT=m. This is not pretty, but
all of the OLPC kconfig options are bool instead of tristate.arch/x86/built-in.o: In function `send_lid_state':
olpc-xo1-sci.c:(.text+0x1d323): undefined reference to `input_event'
olpc-xo1-sci.c:(.text+0x1d338): undefined reference to `input_event'
...In the long run, fixing this driver kconfig to be tristate
instead of bool would be a very good change.Signed-off-by: Randy Dunlap
Cc: Andres Salomon
Cc: Chris Ball
Cc: Jon Nettleton
Cc: Daniel Drake
Cc: "H. Peter Anvin"
Signed-off-by: Andrew Morton
Signed-off-by: Ingo Molnar -
The flush tlb optimization code has logical issue on UV
platform. It doesn't flush the full range at all, since it
simply ignores its 'end' parameter (and hence also the "all"
indicator) in uv_flush_tlb_others() function.Cliff's notes:
| I tested the patch on a UV. It has the effect of either
| clearing 1 or all TLBs in a cpu. I added some debugging to
| test for the cases when clearing all TLBs is overkill, and in
| practice it happens very seldom.Reported-by: Jan Beulich
Signed-off-by: Alex Shi
Signed-off-by: Cliff Wickman
Tested-by: Cliff Wickman
Cc: "H. Peter Anvin"
Signed-off-by: Andrew Morton
Signed-off-by: Ingo Molnar -
The DSP bit mask for the RDDSP and WRDSP instructions was wrong.
[ralf@linux-mips.org: The mask field of the RDDSP and WRDSP instructions
is 10 bits long. DSP_MASK had all these fields which according to the
architecture specification may result in UNPREDICTABLE operation.]Signed-off-by: Steven J. Hill
Cc: linux-mips@linux-mips.org
Patchwork: http://patchwork.linux-mips.org/patch/4683/
Signed-off-by: Ralf Baechle -
As the kernel is able to cope with multiple clusters,
uncomment the A7 cores in the Device Tree for V2P-CA15_A7
tile, making all 5 cores available to the user.Signed-off-by: Pawel Moll
-
In ARM multi-cluster systems the MPIDR affinity level 0 cannot be used as a
single cpu identifier, affinity levels 1 and 2 must be taken into account as
well.
This patch extends the MPIDR usage to affinity levels 1 and 2 in versatile
secondary cores start up code in order to compare the passed pen_release
value with the full-blown affinity mask.Signed-off-by: Lorenzo Pieralisi
Signed-off-by: Liviu Dudau
Acked-by: Nicolas Pitre
Signed-off-by: Pawel Moll -
While in one case a plain annotation is necessary, in the other
case the stack adjustment can simply be folded into the
immediately preceding RESTORE_ALL, thus getting the correct
annotation for free.Signed-off-by: Jan Beulich
Cc: Steven Rostedt
Cc: Linus Torvalds
Cc: Alexander van Heukelum
Link: http://lkml.kernel.org/r/51010C9302000078000B9045@nat28.tlf.novell.com
Signed-off-by: Ingo Molnar
