summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2017-04-19Merge tag 'davinci-for-v4.12/dt-2' of ↵Olof Johansson
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci into next/dt A clean-up device-tree patch to ensure pinmux entry reuse. * tag 'davinci-for-v4.12/dt-2' of git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci: ARM: dts: da850: move spi0_cs3_pin pinconf node Signed-off-by: Olof Johansson <olof@lixom.net>
2017-04-19Merge tag 'davinci-for-v4.12/soc-2' of ↵Olof Johansson
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci into next/soc Add platform support needed for the newly introduced PalmChip PATA driver. * tag 'davinci-for-v4.12/soc-2' of git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci: ARM: davinci: add pata_bk3710 libata driver support Signed-off-by: Olof Johansson <olof@lixom.net>
2017-04-19Merge tag 'stm32-defconfig-for-v4.12-1' of ↵Olof Johansson
git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32 into next/defconfig STM32 defconfig updates for v4.12, round 1. Highlights: ---------- - Enable I2C - Add config fragment for RAM start point * tag 'stm32-defconfig-for-v4.12-1' of git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32: ARM: configs: Add new config fragment to change RAM start point ARM: configs: stm32: Add I2C support Signed-off-by: Olof Johansson <olof@lixom.net>
2017-04-19Merge tag 'stm32-soc-for-v4.12-1' of ↵Olof Johansson
git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32 into next/soc STM32 SOC updates for v4.12, round 1. Highlights: ---------- - Create a dedicated Kconfig for STM32 machine - Add support of STM32H743 MCU * tag 'stm32-soc-for-v4.12-1' of git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32: ARM: stm32: Add a new SOC - STM32H743 ARM: stm32: Introduce MACH_STM32H743 flag ARM: stm32: create dedicated kconfig for STM32 machine Signed-off-by: Olof Johansson <olof@lixom.net>
2017-04-19Merge tag 'stm32-dt-for-v4.12-1' of ↵Olof Johansson
git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32 into next/dt STM32 DT updates for v4.12, round 1 Highlights: ---------- - ADD RTC support on STM32F746 MCU - Enable RTC on STM32F746 Eval board - Enable clocks on STM32F746 MCU - Enable DMA, pwm1 and pwm3 on STM32F429I Eval - Add support of STM32H743 MCU and his Eval board - Enable USB HS and FS on STM32F469 Disco board * tag 'stm32-dt-for-v4.12-1' of git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32: dt-bindings: Document the STM32 USB OTG DWC2 core binding ARM: dts: stm32: Enable USB HS in FS mode (embedded phy) on stm32f429-disco ARM: dts: stm32: Enable USB FS on stm32f469-disco ARM: dts: stm32: Add USB FS support for STM32F429 MCU ARM: dts: stm32: Add STM32H743 MCU and STM32H743i-EVAL board ARM: dts: stm32: Enable pwm1 and pwm3 on stm32f429i-eval ARM: dts: stm32: Enable dma by default on stm32f4 adc ARM: dts: stm32: enable RTC on stm32746g-eval ARM: dts: stm32: Add RTC support for STM32F746 MCU ARM: dts: stm32: set HSE_RTC clock frequency to 1 MHz on stm32f746 dt-bindings: mfd: Add STM32F7 RCC numeric constants into DT include file ARM: dts: stm32: Enable clocks for STM32F746 MCU Signed-off-by: Olof Johansson <olof@lixom.net>
2017-04-19multi_v7_defconfig: make Rockchip usb2-phy built-inHeiko Stuebner
The phy is necessary for the dwc2 controllers driving the usb ports on all arm32 Rockchip socs. Both the dwc2 as well as usb downstream drivers (mass-storage as well as usb networking) are already built-in, so only the phy is missing to allow booting from usb-devices without to much hassle. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Olof Johansson <olof@lixom.net>
2017-04-19Merge branch 'sti-dt-for-v4.12-round1' of ↵Olof Johansson
git://git.kernel.org/pub/scm/linux/kernel/git/pchotard/sti into next/dt * 'sti-dt-for-v4.12-round1' of git://git.kernel.org/pub/scm/linux/kernel/git/pchotard/sti: ARM: dts: STiH407-family: update rproc node names to avoid conflict ARM: dts: STiH407-family: fix spi nodes Signed-off-by: Olof Johansson <olof@lixom.net>
2017-04-19arm64: dts: juno: add information about L1 and L2 cachesSudeep Holla
Commit a8d4636f96ad ("arm64: cacheinfo: Remove CCSIDR-based cache information probing") removed mechanism to extract cache information based on CCSIDR register as the architecture explicitly states no inference about the actual sizes of caches based on CCSIDR registers. Commit 9a802431c527 ("arm64: cacheinfo: add support to override cache levels via device tree") had already provided options to override cache information from the device tree. This patch adds the information about L1 and L2 caches on all variants of Juno platform. Cc: Will Deacon <will.deacon@arm.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2017-04-19arm64: dts: juno: fix few unit address format warningsSudeep Holla
This patch fixes the following set of warnings on juno. smb@08000000 unit name should not have leading 0s sysctl@020000 simple-bus unit address format error, expected "20000" apbregs@010000 simple-bus unit address format error, expected "10000" mmci@050000 simple-bus unit address format error, expected "50000" kmi@060000 simple-bus unit address format error, expected "60000" kmi@070000 simple-bus unit address format error, expected "70000" wdt@0f0000 simple-bus unit address format error, expected "f0000" Acked-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2017-04-19ARM: dts: vexpress: fix few unit address format warningsSudeep Holla
This patch fixes the following set of warnings on vexpress platforms: sysreg@010000 simple-bus unit address format error, expected "10000" sysctl@020000 simple-bus unit address format error, expected "20000" i2c@030000 simple-bus unit address format error, expected "30000" aaci@040000 simple-bus unit address format error, expected "40000" mmci@050000 simple-bus unit address format error, expected "50000" kmi@060000 simple-bus unit address format error, expected "60000" kmi@070000 simple-bus unit address format error, expected "70000" uart@090000 simple-bus unit address format error, expected "90000" uart@0a0000 simple-bus unit address format error, expected "a0000" uart@0b0000 simple-bus unit address format error, expected "b0000" uart@0c0000 simple-bus unit address format error, expected "c0000" wdt@0f0000 simple-bus unit address format error, expected "f0000" Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2017-04-19powerpc/64s: Remove SAO feature from Power9 DD1Nicholas Piggin
Power9 DD1 does not implement SAO. Although it's not widely used, its presence or absence is visible to user space via arch_validate_prot() so it's moderately important that we get the value right. Fixes: 7dccfbc325bb ("powerpc/book3s: Add a cpu table entry for different POWER9 revs") Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-04-19powerpc/64s: Remove ICSWX feature from Power9Nicholas Piggin
Power9 does not implement the icswx instruction. This CPU feature is not visible to userspace and is only used in the CONFIG_PPC_ICSWX code, which is generally not enabled, and can only be triggered by other code using icswx, which should not happen on Power9 systems in the first place. So impact should be minimal. Fixes: c3ab300ea5 ("powerpc: Add POWER9 cputable entry") Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-04-19x86/mce: Check MCi_STATUS[MISCV] for usable addr on Intel onlyBorislav Petkov
mce_usable_address() does a bunch of basic sanity checks to verify whether the address reported with the error is usable for further processing. However, we do check MCi_STATUS[MISCV] and that is not needed on AMD as that bit says that there's additional information about the logged error in the MCi_MISCj banks. But we don't need that to know whether the address is usable - we only need to know whether the physical address is valid - i.e., ADDRV. On Intel the MISCV bit is needed to perform additional checks to determine whether the reported address is a physical one, etc. Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Yazen Ghannam <yazen.ghannam@amd.com> Cc: Tony Luck <tony.luck@intel.com> Cc: linux-edac <linux-edac@vger.kernel.org> Link: http://lkml.kernel.org/r/20170418183924.6agjkebilwqj26or@pd.tnic Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2017-04-19powerpc/perf: Add Power8 mem_access event to sysfsMadhavan Srinivasan
Patch add "mem_access" event to sysfs. This as-is not a raw event supported by Power8 pmu. Instead, it is formed based on raw event encoding specificed in isa207-common.h. Primary PMU event used here is PM_MRK_INST_CMPL. This event tracks only the completed marked instructions. Random sampling mode (MMCRA[SM]) with Random Instruction Sampling (RIS) is enabled to mark type of instructions. With Random sampling in RLS mode with PM_MRK_INST_CMPL event, the LDST /DATA_SRC fields in SIER identifies the memory hierarchy level (eg: L1, L2 etc) statisfied a data-cache miss for a marked instruction. Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-04-19powerpc/perf: Support to export SIERs bit in Power9Madhavan Srinivasan
Patch to export SIER bits to userspace via perf_mem_data_src and perf_sample_data struct. Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-04-19powerpc/perf: Support to export SIERs bit in Power8Madhavan Srinivasan
Patch to export SIER bits to userspace via perf_mem_data_src and perf_sample_data struct. Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-04-19powerpc/perf: Support to export MMCRA[TEC*] field to userspaceMadhavan Srinivasan
Threshold feature when used with MMCRA [Threshold Event Counter Event], MMCRA[Threshold Start event] and MMCRA[Threshold End event] will update MMCRA[Threashold Event Counter Exponent] and MMCRA[Threshold Event Counter Multiplier] with the corresponding threshold event count values. Patch to export MMCRA[TECX/TECM] to userspace in 'weight' field of struct perf_sample_data. Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-04-19powerpc/perf: Export memory hierarchy info to user spaceMadhavan Srinivasan
The LDST field and DATA_SRC in SIER identifies the memory hierarchy level (eg: L1, L2 etc), from which a data-cache miss for a marked instruction was satisfied. Use the 'perf_mem_data_src' object to export this hierarchy level to user space. Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-04-19powerpc/iommu: Do not call PageTransHuge() on tail pagesAlexey Kardashevskiy
The CMA pages migration code does not support compound pages at the moment so it performs few tests before proceeding to actual page migration. One of the tests - PageTransHuge() - has VM_BUG_ON_PAGE(PageTail()) as it is designed to be called on head pages only. Since we also test for PageCompound(), and it contains PageTail() and PageHead(), we can simplify the check by leaving just PageCompound() and therefore avoid possible VM_BUG_ON_PAGE. Fixes: 2e5bbb5461f1 ("KVM: PPC: Book3S HV: Migrate pinned pages out of CMA") Cc: stable@vger.kernel.org # v4.9+ Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Acked-by: Balbir Singh <bsingharora@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-04-19powerpc/mmap: Any hint > 128TB searches the full VA spaceAneesh Kumar K.V
As part of the new large address space support, processes start out life with a 128TB virtual address space. However when calling mmap() a process can pass a hint address, and if that hint is > 128TB the kernel will use the full 512TB address space to try and satisfy the mmap() request. Currently we have a check that the hint is > 128TB and < 512TB (TASK_SIZE), which was added as an optimisation to avoid updating addr_limit unnecessarily and also to avoid calling slice_flush_segments() on all CPUs more than necessary. However this has the user-visible side effect that an mmap() hint above 512TB does not search the full address space unless a preceding mmap() used a hint value > 128TB && < 512TB. So fix it to treat any hint above 128TB as a hint to search the full address space, instead of checking the hint against TASK_SIZE, we instead check if the addr_limit is already == TASK_SIZE. This also brings the ABI in-line with what is proposed on x86. ie, that a hint address above 128TB up to and including (2^64)-1 is an indication to search the full address space. Fixes: f4ea6dcb08ea2c (powerpc/mm: Enable mappings above 128TB) Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-04-19powerpc/64s: Minor fix for MCE TLB flush for radixNicholas Piggin
The TLB flush for radix first flushes TLB for radix configuration, then flushes for hash configuration. The second flush is unnecessary but does not affect correctness. Fixes: 1a472c9dba6b9 ("powerpc/mm/radix: Add tlbflush routines") Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-04-19powerpc/mm/radix: Use mm->task_size for boundary checking instead of addr_limitAneesh Kumar K.V
We don't init addr_limit correctly for 32 bit applications. So default to using mm->task_size for boundary condition checking. We use addr_limit to only control free space search. This makes sure that we do the right thing with 32 bit applications. We should consolidate the usage of TASK_SIZE/mm->task_size and mm->context.addr_limit later. This partially reverts commit fbfef9027c2a7ad (powerpc/mm: Switch some TASK_SIZE checks to use mm_context addr_limit). Fixes: fbfef9027c2a ("powerpc/mm: Switch some TASK_SIZE checks to use mm_context addr_limit") Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-04-19powerpc/64s: Revert setting of LPCR[LPES] on POWER9Nicholas Piggin
The XIVE enablement patches included a change to set the LPES (Logical Partitioning Environment Selector) bit (bit # 3) in LPCR (Logical Partitioning Control Register) on POWER9 hosts. This bit sets external interrupts to guest delivery mode, which uses SRR0/1. The host's EE interrupt handler is written to expect HSRR0/1 (for earlier CPUs). This should be fine because XIVE is configured not to deliver EEs to the host (Hypervisor Virtulization Interrupt is used instead) so the EE handler should never be executed. However a bug in interrupt controller code, hardware, or odd configuration of a simulator could result in the host getting an EE incorrectly. Keeping the EE delivery mode matching the host EE handler prevents strange crashes due to using the wrong exception registers. KVM will configure the LPCR to set LPES prior to running a guest so that EEs are delivered to the guest using SRR0/1. Fixes: 08a1e650cc ("powerpc: Fixup LPCR:PECE and HEIC setting on POWER9") Signed-off-by: Nicholas Piggin <npiggin@gmail.com> [mpe: Massage change log to avoid referring to LPES0 which is now renamed LPES] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-04-19x86/unwind: Remove unused 'sp' parameter in unwind_dump()Josh Poimboeuf
The 'sp' parameter to unwind_dump() is unused. Remove it. Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/08cb36b004629f6bbcf44c267ae4a609242ebd0b.1492520933.git.jpoimboe@redhat.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-04-19x86/unwind: Prepend hex mask value with '0x' in unwind_dump()Josh Poimboeuf
In unwind_dump(), the stack mask value is printed in hex, but is confusingly not prepended with '0x'. Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/e7fe41be19d73c9f99f53082486473febfe08ffa.1492520933.git.jpoimboe@redhat.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-04-19x86/unwind: Properly zero-pad 32-bit values in unwind_dump()Josh Poimboeuf
On x86-32, 32-bit stack values printed by unwind_dump() are confusingly zero-padded to 16 characters (64 bits): unwind stack type:0 next_sp: (null) mask:a graph_idx:0 f50cdebc: 00000000f50cdec4 (0xf50cdec4) f50cdec0: 00000000c40489b7 (irq_exit+0x87/0xa0) ... Instead, base the field width on the size of a long integer so that it looks right on both x86-32 and x86-64. x86-32: unwind stack type:1 next_sp: (null) mask:0x2 graph_idx:0 c0ee9d98: c0ee9de0 (init_thread_union+0x1de0/0x2000) c0ee9d9c: c043fd90 (__save_stack_trace+0x50/0xe0) ... x86-64: unwind stack type:1 next_sp: (null) mask:0x2 graph_idx:0 ffffffff81e03b88: ffffffff81e03c10 (init_thread_union+0x3c10/0x4000) ffffffff81e03b90: ffffffff81048f8e (__save_stack_trace+0x5e/0x100) ... Reported-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/36b743812e7eb291d74af4e5067736736622daad.1492520933.git.jpoimboe@redhat.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-04-19x86/build: convert function graph '-Os' error to warningJosh Poimboeuf
For pre-4.6.0 versions of GCC, which don't have '-mfentry', the '-maccumulate-outgoing-args' option is required for function graph tracing in order to avoid GCC bug 42109. However, GCC ignores '-maccumulate-outgoing-args' when '-Os' is also set. Currently we force a build error to prevent that scenario, but that breaks randconfigs. So change the error to a warning which also disables CONFIG_CC_OPTIMIZE_FOR_SIZE. Reported-by: Andi Kleen <andi@firstfloor.org> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: kbuild test robot <fengguang.wu@intel.com> Cc: kbuild-all@01.org Link: http://lkml.kernel.org/r/20170418214429.o7fbwbmf4nqosezy@treble Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-04-19Merge tag 'v4.11-rc7' into drm-nextDave Airlie
Backmerge Linux 4.11-rc7 from Linus tree, to fix some conflicts that were causing problems with the rerere cache in drm-tip.
2017-04-18x86/mce: Make the MCE notifier a blocking oneVishal Verma
The NFIT MCE handler callback (for handling media errors on NVDIMMs) takes a mutex to add the location of a memory error to a list. But since the notifier call chain for machine checks (x86_mce_decoder_chain) is atomic, we get a lockdep splat like: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:620 in_atomic(): 1, irqs_disabled(): 0, pid: 4, name: kworker/0:0 [..] Call Trace: dump_stack ___might_sleep __might_sleep mutex_lock_nested ? __lock_acquire nfit_handle_mce notifier_call_chain atomic_notifier_call_chain ? atomic_notifier_call_chain mce_gen_pool_process Convert the notifier to a blocking one which gets to run only in process context. Boris: remove the notifier call in atomic context in print_mce(). For now, let's print the MCE on the atomic path so that we can make sure they go out and get logged at least. Fixes: 6839a6d96f4e ("nfit: do an ARS scrub on hitting a latent media error") Reported-by: Ross Zwisler <ross.zwisler@linux.intel.com> Signed-off-by: Vishal Verma <vishal.l.verma@intel.com> Acked-by: Tony Luck <tony.luck@intel.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: linux-edac <linux-edac@vger.kernel.org> Cc: x86-ml <x86@kernel.org> Cc: <stable@vger.kernel.org> Link: http://lkml.kernel.org/r/20170411224457.24777-1-vishal.l.verma@intel.com Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2017-04-18sparc64: Fix hugepage page table freeNitin Gupta
Make sure the start adderess is aligned to PMD_SIZE boundary when freeing page table backing a hugepage region. The issue was causing segfaults when a region backed by 64K pages was unmapped since such a region is in general not PMD_SIZE aligned. Signed-off-by: Nitin Gupta <nitin.m.gupta@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-18sparc64: Use LOCKDEP_SMALL, not PROVE_LOCKING_SMALLDaniel Jordan
CONFIG_PROVE_LOCKING_SMALL shrinks the memory usage of lockdep so the kernel text, data, and bss fit in the required 32MB limit, but this option is not set for every config that enables lockdep. A 4.10 kernel fails to boot with the console output Kernel: Using 8 locked TLB entries for main kernel image. hypervisor_tlb_lock[2000000:0:8000000071c007c3:1]: errors with f Program terminated with these config options CONFIG_LOCKDEP=y CONFIG_LOCK_STAT=y CONFIG_PROVE_LOCKING=n To fix, rename CONFIG_PROVE_LOCKING_SMALL to CONFIG_LOCKDEP_SMALL, and enable this option with CONFIG_LOCKDEP=y so we get the reduced memory usage every time lockdep is turned on. Tested that CONFIG_LOCKDEP_SMALL is set to 'y' if and only if CONFIG_LOCKDEP is set to 'y'. When other lockdep-related config options that select CONFIG_LOCKDEP are enabled (e.g. CONFIG_LOCK_STAT or CONFIG_PROVE_LOCKING), verified that CONFIG_LOCKDEP_SMALL is also enabled. Fixes: e6b5f1be7afe ("config: Adding the new config parameter CONFIG_PROVE_LOCKING_SMALL for sparc") Signed-off-by: Daniel Jordan <daniel.m.jordan@oracle.com> Reviewed-by: Babu Moger <babu.moger@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-18cma: Store a name in the cma structureLaura Abbott
Frameworks that may want to enumerate CMA heaps (e.g. Ion) will find it useful to have an explicit name attached to each region. Store the name in each CMA structure. Signed-off-by: Laura Abbott <labbott@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-04-18ARM: pxa/raumfeld: fix compile error in rotary controller resourcesDmitry Torokhov
When switching rotary controlelr from plain IRQ number to IRQ resource, I messed up the syntax. Fixes: d422be5f62ef ("Input: eeti_ts - expect platform code to set ... ") Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2017-04-18rcu: Make arch select smp_mb__after_unlock_lock() strengthPaul E. McKenney
The definition of smp_mb__after_unlock_lock() is currently smp_mb() for CONFIG_PPC and a no-op otherwise. It would be better to instead provide an architecture-selectable Kconfig option, and select the strength of smp_mb__after_unlock_lock() based on that option. This commit therefore creates ARCH_WEAK_RELEASE_ACQUIRE, has PPC select it, and bases the definition of smp_mb__after_unlock_lock() on this new ARCH_WEAK_RELEASE_ACQUIRE Kconfig option. Reported-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Will Deacon <will.deacon@arm.com> Cc: Boqun Feng <boqun.feng@linux.vnet.ibm.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Acked-by: Michael Ellerman <mpe@ellerman.id.au> Cc: <linuxppc-dev@lists.ozlabs.org> Reviewed-by: Josh Triplett <josh@joshtriplett.org>
2017-04-18PCI: Add arch_can_pci_mmap_io() on architectures which can mmap() I/O spaceDavid Woodhouse
This is relatively esoteric, and knowing that we don't have it makes life easier in some cases rather than just an eventual -EINVAL from pci_mmap_page_range(). Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2017-04-18PCI: Move multiple declarations of pci_mmap_page_range() to <linux/pci.h>David Woodhouse
We can declare it <linux/pci.h> even on platforms where it isn't going to be defined. There's no need to have it littered through the various <asm/pci.h> files. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2017-04-18PCI: Add arch_can_pci_mmap_wc() macroDavid Woodhouse
Most of the almost-identical versions of pci_mmap_page_range() silently ignore the 'write_combine' argument and give uncached mappings. Yet we allow the PCIIOC_WRITE_COMBINE ioctl in /proc/bus/pci, expose the 'resourceX_wc' file in sysfs, and allow an attempted mapping to apparently succeed. To fix this, introduce a macro arch_can_pci_mmap_wc() which indicates whether the platform can do a write-combining mapping. On x86 this ends up being pat_enabled(), while the few other platforms that support it can just set it to a literal '1'. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2017-04-18xtensa/PCI: Do not mmap PCI BARs to userspace as write-throughDavid Woodhouse
These should be uncached, not write-through. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2017-04-19frv: Use OFFSET macro in DEF_*REG()Matthias Kaehlcke
Avoid code duplication by using OFFSET() in DEF_*REG() instead of replicating the macro. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: David Howells <dhowells@redhat.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-04-18powerpc/64: Fix HMI exception on LE with CONFIG_RELOCATABLE=yMichael Ellerman
Prior to commit 2337d207288f ("powerpc/64: CONFIG_RELOCATABLE support for hmi interrupts"), the branch from hmi_exception_early() to hmi_exception_realmode() was just a bl hmi_exception_realmode, which the linker would turn into a bl to the local entry point of hmi_exception_realmode. This was broken when CONFIG_RELOCATABLE=y because hmi_exception_realmode() is not in the low part of the kernel text that is copied down to 0x0. But in fixing that, we added a new bug on little endian kernels. Because the branch is now a bctrl when CONFIG_RELOCATABLE=y, we branch to the global entry point of hmi_exception_realmode(). The global entry point must be called with r12 containing the address of hmi_exception_realmode(), because it uses that value to calculate the TOC value (r2). This may manifest as a checkstop, because we take a junk value from r12 which came from HSRR1, add a small constant to it and then use that as the TOC pointer. The HSRR1 value will have 0x9 as the top nibble, which puts it above RAM and somewhere in MMIO space. Fix it by changing the BRANCH_LINK_TO_FAR() macro to always use r12 to load the label we're branching to. This means r12 will be setup correctly on LE, fixing this bug, and r12 is also volatile across function calls on BE so it's a good choice anyway. Fixes: 2337d207288f ("powerpc/64: CONFIG_RELOCATABLE support for hmi interrupts") Reported-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Acked-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-04-18powerpc/kprobe: Fix oops when kprobed on 'stdu' instructionRavi Bangoria
If we set a kprobe on a 'stdu' instruction on powerpc64, we see a kernel OOPS: Bad kernel stack pointer cd93c840 at c000000000009868 Oops: Bad kernel stack pointer, sig: 6 [#1] ... GPR00: c000001fcd93cb30 00000000cd93c840 c0000000015c5e00 00000000cd93c840 ... NIP [c000000000009868] resume_kernel+0x2c/0x58 LR [c000000000006208] program_check_common+0x108/0x180 On a 64-bit system when the user probes on a 'stdu' instruction, the kernel does not emulate actual store in emulate_step() because it may corrupt the exception frame. So the kernel does the actual store operation in exception return code i.e. resume_kernel(). resume_kernel() loads the saved stack pointer from memory using lwz, which only loads the low 32-bits of the address, causing the kernel crash. Fix this by loading the 64-bit value instead. Fixes: be96f63375a1 ("powerpc: Split out instruction analysis part of emulate_step()") Cc: stable@vger.kernel.org # v3.18+ Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com> Reviewed-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Reviewed-by: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com> [mpe: Change log massage, add stable tag] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-04-18x86: Enable KASLR by defaultIngo Molnar
KASLR is mature (and important) enough to be enabled by default on x86. Also enable it by default in the defconfigs. Acked-by: Thomas Gleixner <tglx@linutronix.de> Cc: Baoquan He <bhe@redhat.com> Cc: Borislav Petkov <bp@suse.de> Cc: Kees Cook <keescook@chromium.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Yinghai Lu <yinghai@kernel.org> Cc: dan.j.williams@intel.com Cc: dave.jiang@intel.com Cc: dyoung@redhat.com Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: linux-kernel@vger.kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-04-18x86/unwind: Ensure stack pointer is alignedJosh Poimboeuf
With frame pointers disabled, on some older versions of GCC (like 4.8.3), it's possible for the stack pointer to get aligned at a half-word boundary: 00000000000004d0 <fib_table_lookup>: 4d0: 41 57 push %r15 4d2: 41 56 push %r14 4d4: 41 55 push %r13 4d6: 41 54 push %r12 4d8: 55 push %rbp 4d9: 53 push %rbx 4da: 48 83 ec 24 sub $0x24,%rsp In such a case, the unwinder ends up reading the entire stack at the wrong alignment. Then the last read goes past the end of the stack, hitting the stack guard page: BUG: stack guard page was hit at ffffc900217c4000 (stack is ffffc900217c0000..ffffc900217c3fff) kernel stack overflow (page fault): 0000 [#1] SMP ... Fix it by ensuring the stack pointer is properly aligned before unwinding. Reported-by: Jirka Hladky <jhladky@redhat.com> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Fixes: 7c7900f89770 ("x86/unwind: Add new unwind interface and implementations") Link: http://lkml.kernel.org/r/cff33847cc9b02fa548625aa23268ac574460d8d.1492436590.git.jpoimboe@redhat.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-04-18x86/mce: Update notifier priority checkBorislav Petkov
Update the check which enforces the registration of MCE decoder notifier callbacks with valid priority only, to include mcelog's priority. Reported-by: kernel test robot <xiaolong.ye@intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tony Luck <tony.luck@intel.com> Cc: linux-edac <linux-edac@vger.kernel.org> Cc: lkp@01.org Link: http://lkml.kernel.org/r/20170418073820.i6kl5tggcntwlisa@pd.tnic Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-04-17ia64: Remove unused IA64_TASK_SIGHAND_OFFSET and IA64_SIGHAND_SIGLOCK_OFFSETEric W. Biederman
These defines are never used so remove them to make it clear there is not assembly code that needs to be updated that uses those fields. Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2017-04-17Merge branch 'i2c/for-INT33FE'Darren Hart (VMware)
Merge branch 'i2c/for-INT33FE' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git to prepare for an incoming INT33FE driver. Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
2017-04-17Merge branch 'parisc-4.11-5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux Pull parisc fix from Helge Deller: "One patch which fixes get_user() for 64-bit values on 32-bit kernels. Up to now we lost the upper 32-bits of the returned 64-bit value" * 'parisc-4.11-5' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc: Fix get_user() for 64-bit value on 32-bit kernel
2017-04-17Merge branch 'for-upstream' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next Johan Hedberg says: ==================== pull request: bluetooth-next 2017-04-14 Here's the main batch of Bluetooth & 802.15.4 patches for the 4.12 kernel. - Many fixes to 6LoWPAN, in particular for BLE - New CA8210 IEEE 802.15.4 device driver (accounting for most of the lines of code added in this pull request) - Added Nokia Bluetooth (UART) HCI driver - Some serdev & TTY changes that are dependencies for the Nokia driver (with acks from relevant maintainers and an agreement that these come through the bluetooth tree) - Support for new Intel Bluetooth device - Various other minor cleanups/fixes here and there Please let me know if there are any issues pulling. Thanks. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-17Remove compat_sys_getdents64()Al Viro
Unlike normal compat syscall variants, it is needed only for biarch architectures that have different alignement requirements for u64 in 32bit and 64bit ABI *and* have __put_user() that won't handle a store of 64bit value at 32bit-aligned address. We used to have one such (ia64), but its biarch support has been gone since 2010 (after being broken in 2008, which went unnoticed since nobody had been using it). It had escaped removal at the same time only because back in 2004 a patch that switched several syscalls on amd64 from private wrappers to generic compat ones had switched to use of compat_sys_getdents64(), which hadn't needed (or used) a compat wrapper on amd64. Let's bury it - it's at least 7 years overdue. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2017-04-17x86/kbuild: Use cc-option to enable -falign-{jumps/loops}Matthias Kaehlcke
clang currently does not support these optimizations, only enable them when they are available. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Cc: Greg Hackmann <ghackmann@google.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Michael Davidson <md@google.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: grundler@chromium.org Link: http://lkml.kernel.org/r/20170413172609.118122-1-mka@chromium.org Signed-off-by: Ingo Molnar <mingo@kernel.org>