summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2017-10-22powerpc/64s: Move the two FAST_ENDIAN macros next to each otherMichael Ellerman
So we can #ifdef them in the next patch. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-10-22powerpc/xmon: Add kstack base to paca dumpMichael Ellerman
When dumping the paca in xmon we currently show kstack. Although it's not hard it's a bit fiddly to work out what the bounds of the kernel stack should be based on the kstack value. To make life easier and "kstack_base" which is the base (lowest address) of the kernel stack, eg: kstack = 0xc0000000f1a7be30 (0x258) kstack_base = 0xc0000000f1a78000 Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-10-22powerpc/configs: Enable I2C_CHARDEV for pseries and powernvAndrew Donnellan
i2c-dev provides an interface for userspace programs to interact with I2C devices, and is very helpful for I2C-related debugging. Enable it in pseries_defconfig and powernv_defconfig. It's already enabled in many other powerpc defconfigs. Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-10-22powerpc/mm/radix: Drop unneeded NULL checkMichael Ellerman
We call these functions with non-NULL mm or vma. Hence we can skip the NULL check in these functions. We also remove now unused function __local_flush_hugetlb_page(). Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> [mpe: Drop the checks with is_vm_hugetlb_page() as noticed by Nick] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-10-22powerpc/xmon: Check before calling xive functionsBreno Leitao
Currently xmon could call XIVE functions from OPAL even if the XIVE is disabled or does not exist in the system, as in POWER8 machines. This causes the following exception: 1:mon> dx cpu 0x1: Vector: 700 (Program Check) at [c000000423c93450] pc: c00000000009cfa4: opal_xive_dump+0x50/0x68 lr: c0000000000997b8: opal_return+0x0/0x50 This patch simply checks if XIVE is enabled before calling XIVE functions. Fixes: 243e25112d06 ("powerpc/xive: Native exploitation of the XIVE interrupt controller") Suggested-by: Guilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com> Signed-off-by: Breno Leitao <leitao@debian.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-10-21ARM: dts: rockchip: enable the hdmi output on the rk3288-firefly-reloadHans Verkuil
The vdd10_lcd and vcc18_lcd regulators need to be enabled for HDMI output to work, so add 'regulator-always-on', just as is done in rk3288-firefly.dtsi. Also enable i2c5, the hdmi block and configure the correc cec pin. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-10-21ARM: dts: rockchip: define the two possible rk3288 CEC pinsHans Verkuil
The CEC line can be routed to two possible pins. Define those pins. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-10-21ARM: dts: rockchip: add the cec clk for dw-hdmi on rk3288Hans Verkuil
The dw-hdmi block needs the cec clk for the rk3288. Add it. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-10-21x86/intel_rdt: Fix potential deadlock during resctrl mountReinette Chatre
Sai reported a warning during some MBA tests: [ 236.755559] ====================================================== [ 236.762443] WARNING: possible circular locking dependency detected [ 236.769328] 4.14.0-rc4-yocto-standard #8 Not tainted [ 236.774857] ------------------------------------------------------ [ 236.781738] mount/10091 is trying to acquire lock: [ 236.787071] (cpu_hotplug_lock.rw_sem){++++}, at: [<ffffffff8117f892>] static_key_enable+0x12/0x30 [ 236.797058] but task is already holding lock: [ 236.803552] (&type->s_umount_key#37/1){+.+.}, at: [<ffffffff81208b2f>] sget_userns+0x32f/0x520 [ 236.813247] which lock already depends on the new lock. [ 236.822353] the existing dependency chain (in reverse order) is: [ 236.830686] -> #4 (&type->s_umount_key#37/1){+.+.}: [ 236.837756] __lock_acquire+0x1100/0x11a0 [ 236.842799] lock_acquire+0xdf/0x1d0 [ 236.847363] down_write_nested+0x46/0x80 [ 236.852310] sget_userns+0x32f/0x520 [ 236.856873] kernfs_mount_ns+0x7e/0x1f0 [ 236.861728] rdt_mount+0x30c/0x440 [ 236.866096] mount_fs+0x38/0x150 [ 236.870262] vfs_kern_mount+0x67/0x150 [ 236.875015] do_mount+0x1df/0xd50 [ 236.879286] SyS_mount+0x95/0xe0 [ 236.883464] entry_SYSCALL_64_fastpath+0x18/0xad [ 236.889183] -> #3 (rdtgroup_mutex){+.+.}: [ 236.895292] __lock_acquire+0x1100/0x11a0 [ 236.900337] lock_acquire+0xdf/0x1d0 [ 236.904899] __mutex_lock+0x80/0x8f0 [ 236.909459] mutex_lock_nested+0x1b/0x20 [ 236.914407] intel_rdt_online_cpu+0x3b/0x4a0 [ 236.919745] cpuhp_invoke_callback+0xce/0xb80 [ 236.925177] cpuhp_thread_fun+0x1c5/0x230 [ 236.930222] smpboot_thread_fn+0x11a/0x1e0 [ 236.935362] kthread+0x152/0x190 [ 236.939536] ret_from_fork+0x27/0x40 [ 236.944097] -> #2 (cpuhp_state-up){+.+.}: [ 236.950199] __lock_acquire+0x1100/0x11a0 [ 236.955241] lock_acquire+0xdf/0x1d0 [ 236.959800] cpuhp_issue_call+0x12e/0x1c0 [ 236.964845] __cpuhp_setup_state_cpuslocked+0x13b/0x2f0 [ 236.971242] __cpuhp_setup_state+0xa7/0x120 [ 236.976483] page_writeback_init+0x43/0x67 [ 236.981623] pagecache_init+0x38/0x3b [ 236.986281] start_kernel+0x3c6/0x41a [ 236.990931] x86_64_start_reservations+0x2a/0x2c [ 236.996650] x86_64_start_kernel+0x72/0x75 [ 237.001793] verify_cpu+0x0/0xfb [ 237.005966] -> #1 (cpuhp_state_mutex){+.+.}: [ 237.012364] __lock_acquire+0x1100/0x11a0 [ 237.017408] lock_acquire+0xdf/0x1d0 [ 237.021969] __mutex_lock+0x80/0x8f0 [ 237.026527] mutex_lock_nested+0x1b/0x20 [ 237.031475] __cpuhp_setup_state_cpuslocked+0x54/0x2f0 [ 237.037777] __cpuhp_setup_state+0xa7/0x120 [ 237.043013] page_alloc_init+0x28/0x30 [ 237.047769] start_kernel+0x148/0x41a [ 237.052425] x86_64_start_reservations+0x2a/0x2c [ 237.058145] x86_64_start_kernel+0x72/0x75 [ 237.063284] verify_cpu+0x0/0xfb [ 237.067456] -> #0 (cpu_hotplug_lock.rw_sem){++++}: [ 237.074436] check_prev_add+0x401/0x800 [ 237.079286] __lock_acquire+0x1100/0x11a0 [ 237.084330] lock_acquire+0xdf/0x1d0 [ 237.088890] cpus_read_lock+0x42/0x90 [ 237.093548] static_key_enable+0x12/0x30 [ 237.098496] rdt_mount+0x406/0x440 [ 237.102862] mount_fs+0x38/0x150 [ 237.107035] vfs_kern_mount+0x67/0x150 [ 237.111787] do_mount+0x1df/0xd50 [ 237.116058] SyS_mount+0x95/0xe0 [ 237.120233] entry_SYSCALL_64_fastpath+0x18/0xad [ 237.125952] other info that might help us debug this: [ 237.134867] Chain exists of: cpu_hotplug_lock.rw_sem --> rdtgroup_mutex --> &type->s_umount_key#37/1 [ 237.148425] Possible unsafe locking scenario: [ 237.155015] CPU0 CPU1 [ 237.160057] ---- ---- [ 237.165100] lock(&type->s_umount_key#37/1); [ 237.169952] lock(rdtgroup_mutex); [ 237.176641] lock(&type->s_umount_key#37/1); [ 237.184287] lock(cpu_hotplug_lock.rw_sem); [ 237.189041] *** DEADLOCK *** When the resctrl filesystem is mounted the locks must be acquired in the same order as was done when the cpus came online: cpu_hotplug_lock before rdtgroup_mutex. This also requires to switch the static_branch_enable() calls to the _cpulocked variant because now cpu hotplug lock is held already. [ tglx: Switched to cpus_read_[un]lock ] Reported-by: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Tested-by: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com> Acked-by: Vikas Shivappa <vikas.shivappa@linux.intel.com> Cc: fenghua.yu@intel.com Cc: tony.luck@intel.com Link: https://lkml.kernel.org/r/9c41b91bc2f47d9e95b62b213ecdb45623c47a9f.1508490116.git.reinette.chatre@intel.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2017-10-21x86/intel_rdt: Fix potential deadlock during resctrl unmountReinette Chatre
Lockdep warns about a potential deadlock: [ 66.782842] ====================================================== [ 66.782888] WARNING: possible circular locking dependency detected [ 66.782937] 4.14.0-rc2-test-test+ #48 Not tainted [ 66.782983] ------------------------------------------------------ [ 66.783052] umount/336 is trying to acquire lock: [ 66.783117] (cpu_hotplug_lock.rw_sem){++++}, at: [<ffffffff81032395>] rdt_kill_sb+0x215/0x390 [ 66.783193] but task is already holding lock: [ 66.783244] (rdtgroup_mutex){+.+.}, at: [<ffffffff810321b6>] rdt_kill_sb+0x36/0x390 [ 66.783305] which lock already depends on the new lock. [ 66.783364] the existing dependency chain (in reverse order) is: [ 66.783419] -> #3 (rdtgroup_mutex){+.+.}: [ 66.783467] __lock_acquire+0x1293/0x13f0 [ 66.783509] lock_acquire+0xaf/0x220 [ 66.783543] __mutex_lock+0x71/0x9b0 [ 66.783575] mutex_lock_nested+0x1b/0x20 [ 66.783610] intel_rdt_online_cpu+0x3b/0x430 [ 66.783649] cpuhp_invoke_callback+0xab/0x8e0 [ 66.783687] cpuhp_thread_fun+0x7a/0x150 [ 66.783722] smpboot_thread_fn+0x1cc/0x270 [ 66.783764] kthread+0x16e/0x190 [ 66.783794] ret_from_fork+0x27/0x40 [ 66.783825] -> #2 (cpuhp_state){+.+.}: [ 66.783870] __lock_acquire+0x1293/0x13f0 [ 66.783906] lock_acquire+0xaf/0x220 [ 66.783938] cpuhp_issue_call+0x102/0x170 [ 66.783974] __cpuhp_setup_state_cpuslocked+0x154/0x2a0 [ 66.784023] __cpuhp_setup_state+0xc7/0x170 [ 66.784061] page_writeback_init+0x43/0x67 [ 66.784097] pagecache_init+0x43/0x4a [ 66.784131] start_kernel+0x3ad/0x3f7 [ 66.784165] x86_64_start_reservations+0x2a/0x2c [ 66.784204] x86_64_start_kernel+0x72/0x75 [ 66.784241] verify_cpu+0x0/0xfb [ 66.784270] -> #1 (cpuhp_state_mutex){+.+.}: [ 66.784319] __lock_acquire+0x1293/0x13f0 [ 66.784355] lock_acquire+0xaf/0x220 [ 66.784387] __mutex_lock+0x71/0x9b0 [ 66.784419] mutex_lock_nested+0x1b/0x20 [ 66.784454] __cpuhp_setup_state_cpuslocked+0x52/0x2a0 [ 66.784497] __cpuhp_setup_state+0xc7/0x170 [ 66.784535] page_alloc_init+0x28/0x30 [ 66.784569] start_kernel+0x148/0x3f7 [ 66.784602] x86_64_start_reservations+0x2a/0x2c [ 66.784642] x86_64_start_kernel+0x72/0x75 [ 66.784678] verify_cpu+0x0/0xfb [ 66.784707] -> #0 (cpu_hotplug_lock.rw_sem){++++}: [ 66.784759] check_prev_add+0x32f/0x6e0 [ 66.784794] __lock_acquire+0x1293/0x13f0 [ 66.784830] lock_acquire+0xaf/0x220 [ 66.784863] cpus_read_lock+0x3d/0xb0 [ 66.784896] rdt_kill_sb+0x215/0x390 [ 66.784930] deactivate_locked_super+0x3e/0x70 [ 66.784968] deactivate_super+0x40/0x60 [ 66.785003] cleanup_mnt+0x3f/0x80 [ 66.785034] __cleanup_mnt+0x12/0x20 [ 66.785070] task_work_run+0x8b/0xc0 [ 66.785103] exit_to_usermode_loop+0x94/0xa0 [ 66.786804] syscall_return_slowpath+0xe8/0x150 [ 66.788502] entry_SYSCALL_64_fastpath+0xab/0xad [ 66.790194] other info that might help us debug this: [ 66.795139] Chain exists of: cpu_hotplug_lock.rw_sem --> cpuhp_state --> rdtgroup_mutex [ 66.800035] Possible unsafe locking scenario: [ 66.803267] CPU0 CPU1 [ 66.804867] ---- ---- [ 66.806443] lock(rdtgroup_mutex); [ 66.808002] lock(cpuhp_state); [ 66.809565] lock(rdtgroup_mutex); [ 66.811110] lock(cpu_hotplug_lock.rw_sem); [ 66.812608] *** DEADLOCK *** [ 66.816983] 2 locks held by umount/336: [ 66.818418] #0: (&type->s_umount_key#35){+.+.}, at: [<ffffffff81229738>] deactivate_super+0x38/0x60 [ 66.819922] #1: (rdtgroup_mutex){+.+.}, at: [<ffffffff810321b6>] rdt_kill_sb+0x36/0x390 When the resctrl filesystem is unmounted the locks should be obtain in the locks in the same order as was done when the cpus came online: cpu_hotplug_lock before rdtgroup_mutex. This also requires to switch the static_branch_disable() calls to the _cpulocked variant because now cpu hotplug lock is held already. [ tglx: Switched to cpus_read_[un]lock ] Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com> Acked-by: Vikas Shivappa <vikas.shivappa@linux.intel.com> Acked-by: Fenghua Yu <fenghua.yu@intel.com> Acked-by: Tony Luck <tony.luck@intel.com> Link: https://lkml.kernel.org/r/cc292e76be073f7260604651711c47b09fd0dc81.1508490116.git.reinette.chatre@intel.com
2017-10-21x86/intel_rdt: Initialize bitmask of shareable resource if CDP enabledReinette Chatre
The platform informs via CPUID.(EAX=0x10, ECX=res#):EBX[31:0] (valid res# are only 1 for L3 and 2 for L2) which unit of the allocation may be used by other entities in the platform. This information is valid whether CDP (Code and Data Prioritization) is enabled or not. Ensure that the bitmask of shareable resource is initialized when CDP is enabled. Fixes: 0dd2d7494cd8 ("x86/intel_rdt: Show bitmask of shareable resource with other executing units" Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Fenghua Yu <fenghua.yu@intel.com> Acked-by: Vikas Shivappa <vikas.shivappa@linux.intel.com> Acked-by: Tony Luck <tony.luck@intel.com> Link: https://lkml.kernel.org/r/815747bddc820ca221a8924edaf4d1a7324547e4.1508490116.git.reinette.chatre@intel.com
2017-10-21arm/arm64: kvm: Disable branch profiling in HYP codeJulien Thierry
When HYP code runs into branch profiling code, it attempts to jump to unmapped memory, causing a HYP Panic. Disable the branch profiling for code designed to run at HYP mode. Signed-off-by: Julien Thierry <julien.thierry@arm.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Cc: Christoffer Dall <christoffer.dall@linaro.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Russell King <linux@armlinux.org.uk> Cc: <stable@vger.kernel.org> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
2017-10-21arm/arm64: KVM: set right LR register value for 32 bit guest when inject abortDongjiu Geng
When a exception is trapped to EL2, hardware uses ELR_ELx to hold the current fault instruction address. If KVM wants to inject a abort to 32 bit guest, it needs to set the LR register for the guest to emulate this abort happened in the guest. Because ARM32 architecture is pipelined execution, so the LR value has an offset to the fault instruction address. The offsets applied to Link value for exceptions as shown below, which should be added for the ARM32 link register(LR). Table taken from ARMv8 ARM DDI0487B-B, table G1-10: Exception Offset, for PE state of: A32 T32 Undefined Instruction +4 +2 Prefetch Abort +4 +4 Data Abort +8 +8 IRQ or FIQ +4 +4 [ Removed unused variables in inject_abt to avoid compile warnings. -- Christoffer ] Cc: <stable@vger.kernel.org> Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com> Tested-by: Haibin Zhang <zhanghaibin7@huawei.com> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <cdall@linaro.org>
2017-10-21powerpc/tm: P9 disable transactionally suspended sigcontextsMichael Neuling
Unfortunately userspace can construct a sigcontext which enables suspend. Thus userspace can force Linux into a path where trechkpt is executed. This patch blocks this from happening on POWER9 by sanity checking sigcontexts passed in. ptrace doesn't have this problem as only MSR SE and BE can be changed via ptrace. This patch also adds a number of WARN_ON()s in case we ever enter suspend when we shouldn't. This should not happen, but if it does the symptoms are soft lockup warnings which are not obviously TM related, so the WARN_ON()s should make it obvious what's happening. Signed-off-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Cyril Bur <cyrilbur@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-10-21powerpc/powernv: Enable TM without suspend if possibleMichael Ellerman
Some Power9 revisions can run in a mode where TM operates without suspended state. If we find ourself on a CPU that might be in this mode, we query OPAL to check, and if so we reenable TM in CPU features, and enable a new user feature to signal to userspace that we are in this mode. We do not enable the "normal" user feature, PPC_FEATURE2_HTM, but we do enable PPC_FEATURE2_HTM_NOSC because that indicates to userspace that the kernel will abort transactions on syscall entry, which is true regardless of the suspend mode. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-10-20Merge branch 'fixes' of git://git.armlinux.org.uk/~rmk/linux-armLinus Torvalds
Pull ARM fixes from Russell King: "Three fixes this time around: - ensure sparse realises that we're building for a 32-bit arch on 64-bit hosts. - use the correct instruction for semihosting on v7m (nommu) CPUs. - reserve address 0 to prevent the first page of memory being used on nommu systems" * 'fixes' of git://git.armlinux.org.uk/~rmk/linux-arm: ARM: 8704/1: semihosting: use proper instruction on v7m processors ARM: 8701/1: fix sparse flags for build on 64bit machines ARM: 8700/1: nommu: always reserve address 0 away
2017-10-20Merge tag 'armsoc-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Pull ARM SoC fixes from Arnd Bergmann: "Here is another set of bugfixes for ARM SoCs, mostly harmless: - a boot regression fix on ux500 - PCIe interrupts on NXP i.MX7 and on Marvell Armada 7K/8K were wired up wrong, in different ways - Armada XP support for large memory never worked - the socfpga reset controller now builds on 64-bit - minor device tree corrections on gemini, mvebu, r-pi 3, rockchip and at91" * tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: ARM: ux500: Fix regression while init PM domains ARM: dts: fix PCLK name on Gemini and MOXA ART arm64: dts: rockchip: fix typo in iommu nodes arm64: dts: rockchip: correct vqmmc voltage for rk3399 platforms ARM: dts: imx7d: Invert legacy PCI irq mapping bus: mbus: fix window size calculation for 4GB windows ARM: dts: at91: sama5d2: add ADC hw trigger edge type ARM: dts: at91: sama5d2_xplained: enable ADTRG pin ARM: dts: at91: at91-sama5d27_som1: fix PHY ID ARM: dts: bcm283x: Fix console path on RPi3 reset: socfpga: fix for 64-bit compilation ARM: dts: Fix I2C repeated start issue on Armada-38x arm64: dts: marvell: fix interrupt-map property for Armada CP110 PCIe controller arm64: dts: salvator-common: add 12V regulator to backlight ARM: dts: sun6i: Fix endpoint IDs in second display pipeline arm64: allwinner: a64: pine64: Use dcdc1 regulator for mmc0
2017-10-20Merge tag 'sunxi-fixes-for-4.14' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into fixes Pull "Allwinner fixes for 4.14" from Maxime Ripard: Two fixes, one for the A31 DRM binding, and one for a missing regulator on the pine MMC controller. * tag 'sunxi-fixes-for-4.14' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux: ARM: dts: sun6i: Fix endpoint IDs in second display pipeline arm64: allwinner: a64: pine64: Use dcdc1 regulator for mmc0
2017-10-21arm64: dts: uniphier: add STDMAC clock to EHCI nodesMasahiro Yamada
Without the STDMAC clock enabled, the USB 2.0 hosts do not work. This clock must be explicitly listed in the "clocks" property because it is independent of the other clocks. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-10-21ARM: dts: uniphier: add STDMAC clock to EHCI nodesMasahiro Yamada
Without the STDMAC clock enabled, the USB 2.0 hosts do not work. This clock must be explicitly listed in the "clocks" property because it is independent of the other clocks. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-10-20KVM: X86: #GP when guest attempts to write MCi_STATUS register w/o 0Wanpeng Li
Both Intel SDM and AMD APM mentioned that MCi_STATUS, when the register is implemented, this register can be cleared by explicitly writing 0s to this register. Writing 1s to this register will cause a general-protection exception. The mce is emulated in qemu, so just the guest attempts to write 1 to this register should cause a #GP, this patch does it. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: Jim Mattson <jmattson@google.com> Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com> Reviewed-by: Jim Mattson <jmattson@google.com> Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
2017-10-20KVM: VMX: Fix VPID capability detectionWanpeng Li
In my setup, EPT is not exposed to L1, the VPID capability is exposed and can be observed by vmxcap tool in L1: INVVPID supported yes Individual-address INVVPID yes Single-context INVVPID yes All-context INVVPID yes Single-context-retaining-globals INVVPID yes However, the module parameter of VPID observed in L1 is always N, the cpu_has_vmx_invvpid() check in L1 KVM fails since vmx_capability.vpid is 0 and it is not read from MSR due to EPT is not exposed. The VPID can be used to tag linear mappings when EPT is not enabled. However, current logic just detects VPID capability if EPT is enabled, this patch fixes it. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: Jim Mattson <jmattson@google.com> Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com> Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
2017-10-20KVM: nVMX: Fix EPT switching advertisingWanpeng Li
I can use vmxcap tool to observe "EPTP Switching yes" even if EPT is not exposed to L1. EPT switching is advertised unconditionally since it is emulated, however, it can be treated as an extended feature for EPT and it should not be advertised if EPT itself is not exposed. This patch fixes it. Reviewed-by: David Hildenbrand <david@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: Jim Mattson <jmattson@google.com> Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com> Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
2017-10-20arm64: mediatek: cleanup message for platform selectionSean Wang
The latest kernel tree already can support more MediaTek platforms such as MT2712 and MT7622, so additional descriptions for those platforms are added and certain cleanups are also being made here. Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2017-10-20x86/xen: Drop 5-level paging support code from the XEN_PV codeKirill A. Shutemov
It was decided 5-level paging is not going to be supported in XEN_PV. Let's drop the dead code from the XEN_PV code. Tested-by: Juergen Gross <jgross@suse.com> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Reviewed-by: Juergen Gross <jgross@suse.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Borislav Petkov <bp@suse.de> Cc: Cyrill Gorcunov <gorcunov@openvz.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/20170929140821.37654-6-kirill.shutemov@linux.intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-10-20x86/xen: Provide pre-built page tables only for CONFIG_XEN_PV=y and ↵Kirill A. Shutemov
CONFIG_XEN_PVH=y Looks like we only need pre-built page tables in the CONFIG_XEN_PV=y and CONFIG_XEN_PVH=y cases. Let's not provide them for other configurations. Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Reviewed-by: Juergen Gross <jgross@suse.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Borislav Petkov <bp@suse.de> Cc: Cyrill Gorcunov <gorcunov@openvz.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/20170929140821.37654-5-kirill.shutemov@linux.intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-10-20x86/kasan: Use the same shadow offset for 4- and 5-level pagingAndrey Ryabinin
We are going to support boot-time switching between 4- and 5-level paging. For KASAN it means we cannot have different KASAN_SHADOW_OFFSET for different paging modes: the constant is passed to gcc to generate code and cannot be changed at runtime. This patch changes KASAN code to use 0xdffffc0000000000 as shadow offset for both 4- and 5-level paging. For 5-level paging it means that shadow memory region is not aligned to PGD boundary anymore and we have to handle unaligned parts of the region properly. In addition, we have to exclude paravirt code from KASAN instrumentation as we now use set_pgd() before KASAN is fully ready. [kirill.shutemov@linux.intel.com: clenaup, changelog message] Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Borislav Petkov <bp@suse.de> Cc: Cyrill Gorcunov <gorcunov@openvz.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/20170929140821.37654-4-kirill.shutemov@linux.intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-10-20arm64: dts: renesas: salvator-common: add dr_mode property for USB2.0 channel 0Yoshihiro Shimoda
Since Salvator-X[S] have a USB2.0 dual-role channel (CN9), this patch adds dr_mode property for USB2.0 channel 0 (EHCI/OHCI and HS-USB) as "otg". Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2017-10-20Merge branch 'perf/urgent' into perf/core, to pick up fixesIngo Molnar
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-10-20x86/entry: Use SYSCALL_DEFINE() macros for sys_modify_ldt()Dave Hansen
We do not have tracepoints for sys_modify_ldt() because we define it directly instead of using the normal SYSCALL_DEFINEx() macros. However, there is a reason sys_modify_ldt() does not use the macros: it has an 'int' return type instead of 'unsigned long'. This is a bug, but it's a bug cemented in the ABI. What does this mean? If we return -EINVAL from a function that returns 'int', we have 0x00000000ffffffea in %rax. But, if we return -EINVAL from a function returning 'unsigned long', we end up with 0xffffffffffffffea in %rax, which is wrong. To work around this and maintain the 'int' behavior while using the SYSCALL_DEFINEx() macros, so we add a cast to 'unsigned int' in both implementations of sys_modify_ldt(). Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: Andy Lutomirski <luto@kernel.org> Reviewed-by: Brian Gerst <brgerst@gmail.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/20171018172107.1A79C532@viggo.jf.intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-10-20ARM: sun8i: r40: enable USB host for Banana Pi M2 UltraIcenowy Zheng
Banana Pi M2 Ultra board features two USB host ports, connected to the two USB host ports on the SoC. Add support for them. Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Acked-by: Chen-Yu Tsai <wens@csie.org>
2017-10-20ARM: sun8i: v40: add 5V regulator for Banana Pi M2 BerryIcenowy Zheng
On the Banana Pi M2 Berry board, the 5V power output (used by HDMI, SATA and USB) is controlled via a GPIO. Add regulator node for it. Signed-off-by: Icenowy Zheng <icenowy@aosc.io> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Acked-by: Chen-Yu Tsai <wens@csie.org>
2017-10-20ARM: sun8i: r40: add 5V regulator for Banana Pi M2 UltraIcenowy Zheng
On newer revisions of the Banana Pi M2 Ultra boards, the 5V power output (used by HDMI, SATA and USB) is controller via a GPIO. Add the regulator node for it. Older revisions just have the 5V power output always on, and the GPIO is reserved on these boards. So it won't affect the older revisions. Signed-off-by: Icenowy Zheng <icenowy@aosc.io> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Acked-by: Chen-Yu Tsai <wens@csie.org>
2017-10-20ARM: sun8i: r40: add USB host port nodes for R40Icenowy Zheng
Allwinner R40 SoC features a USB OTG port and two USB HOST ports. Add support for the host ports in the DTSI file. The OTG controller still cannot work with existing compatibles, and needs more investigation. So it's not added yet. Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Acked-by: Chen-Yu Tsai <wens@csie.org>
2017-10-20x86/mm: Limit mmap() of /dev/mem to valid physical addressesCraig Bergstrom
Currently, it is possible to mmap() any offset from /dev/mem. If a program mmaps() /dev/mem offsets outside of the addressable limits of a system, the page table can be corrupted by setting reserved bits. For example if you mmap() offset 0x0001000000000000 of /dev/mem on an x86_64 system with a 48-bit bus, the page fault handler will be called with error_code set to RSVD. The kernel then crashes with a page table corruption error. This change prevents this page table corruption on x86 by refusing to mmap offsets higher than the highest valid address in the system. Signed-off-by: Craig Bergstrom <craigb@google.com> Cc: Andrew Morton <akpm@linux-foundation.org> 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: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Luis R. Rodriguez <mcgrof@suse.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Toshi Kani <toshi.kani@hp.com> Cc: dsafonov@virtuozzo.com Cc: kirill.shutemov@linux.intel.com Cc: mhocko@suse.com Cc: oleg@redhat.com Link: http://lkml.kernel.org/r/20171019192856.39672-1-craigb@google.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-10-20kprobes: Use synchronize_rcu_tasks() for optprobe with CONFIG_PREEMPT=yMasami Hiramatsu
We want to wait for all potentially preempted kprobes trampoline execution to have completed. This guarantees that any freed trampoline memory is not in use by any task in the system anymore. synchronize_rcu_tasks() gives such a guarantee, so use it. Also, this guarantees to wait for all potentially preempted tasks on the instructions which will be replaced with a jump. Since this becomes a problem only when CONFIG_PREEMPT=y, enable CONFIG_TASKS_RCU=y for synchronize_rcu_tasks() in that case. Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Naveen N . Rao <naveen.n.rao@linux.vnet.ibm.com> Cc: Paul E . McKenney <paulmck@linux.vnet.ibm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/150845661962.5443.17724352636247312231.stgit@devbox Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-10-20powerpc: Add PPC_FEATURE2_HTM_NO_SUSPENDMichael Ellerman
Some CPUs can operate in a mode where TM (Transactional Memory) is enabled but the suspended state of TM is disabled. In this mode tsuspend does not enter suspended state, instead the transaction is aborted. Similarly any other event that would lead to suspended state instead aborts the transaction. There is also an ABI change, in that in this mode processes are not allowed to sigreturn with an MSR that would lead to suspended state, Linux will instead return an error to the sigreturn syscall. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-10-20powerpc/tm: Add commandline option to disable hardware transactional memoryCyril Bur
Currently the kernel relies on firmware to inform it whether or not the CPU supports HTM and as long as the kernel was built with CONFIG_PPC_TRANSACTIONAL_MEM=y then it will allow userspace to make use of the facility. There may be situations where it would be advantageous for the kernel to not allow userspace to use HTM, currently the only way to achieve this is to recompile the kernel with CONFIG_PPC_TRANSACTIONAL_MEM=n. This patch adds a simple commandline option so that HTM can be disabled at boot time. Signed-off-by: Cyril Bur <cyrilbur@gmail.com> [mpe: Simplify to a bool, move to prom.c, put doco in the right place. Always disable, regardless of initial state, to avoid user confusion.] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-10-20Merge branch 'topic/ppc-kvm' into nextMichael Ellerman
Bring in some KVM commits we need (the TM one in particular).
2017-10-20KVM: PPC: Tie KVM_CAP_PPC_HTM to the user-visible TM featureMichael Ellerman
Currently we use CPU_FTR_TM to decide if the CPU/kernel can support TM (Transactional Memory), and if it's true we advertise that to Qemu (or similar) via KVM_CAP_PPC_HTM. PPC_FEATURE2_HTM is the user-visible feature bit, which indicates that the CPU and kernel can support TM. Currently CPU_FTR_TM and PPC_FEATURE2_HTM always have the same value, either true or false, so using the former for KVM_CAP_PPC_HTM is correct. However some Power9 CPUs can operate in a mode where TM is enabled but TM suspended state is disabled. In this mode CPU_FTR_TM is true, but PPC_FEATURE2_HTM is false. Instead a different PPC_FEATURE2 bit is set, to indicate that this different mode of TM is available. It is not safe to let guests use TM as-is, when the CPU is in this mode. So to prevent that from happening, use PPC_FEATURE2_HTM to determine the value of KVM_CAP_PPC_HTM. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-10-20Merge tag 'omap-for-v4.15/dt-signed' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into next/dt Pull "device tree changes for omaps for v4.15 merge window" from Tony Lindgren: Device tree changes for omaps for v4.15 merge window to improve support for omap35xx-evm, am34xx-epos-evm and dra7: - A series of changes to fix support for omap35xx-evm - A series of changes to add earlycon support for n8x0, pandaboard and omap5 boards - A series of changes for am43xx-epos-evm pinctrl modes for default and sleep states - A series of changes to correct pbias regulator voltage for dra7 from 3V to 3.3V - Use microchip compatible instead of deprecated mcp compatible for mcp23017 * tag 'omap-for-v4.15/dt-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: (22 commits) ARM: dts: omap3: Replace deprecated mcp prefix ARM: dts: dra7-evm: Move pcie RC node to common file ARM: dts: omap5: Increase max-voltage of pbias regulator ARM: dts: dra7: Increase max-voltage of pbias regulator ARM: dts: am43xx-epos-evm: Add default pinmux for unused pins ARM: dts: am43xx-epos-evm: Add default and sleep pinmux for usb2_phy1 and usb2_phy2 ARM: dts: am43xx-epos-evm: Add default and sleep pinmux for uart0 ARM: dts: am43xx-epos-evm: Add default and sleep pinmux for matrix_keypad0 ARM: dts: am43xx-epos-evm: Add sleep pinmux for mmc1 ARM: dts: am43xx-epos-evm: Add sleep pinmux for pixcir_ts ARM: dts: am43xx-epos-evm: Add sleep pinmux for gpmc ARM: dts: am43xx-epos-evm: Add sleep pinmux for ecap0 ARM: dts: am43xx-epos-evm: Add sleep pinmux for qspi1 ARM: dts: am43xx-epos-evm: Add sleep pinmux for spi0 and spi1 ARM: dts: am43xx: Introduce additional pinmux definitions for DS0 ARM: dts: Configure earlycon for omap5-common ARM: dts: Configure earlycon for pandaboard ARM: dts: Configure earlycon for n8x0 ARM: dts: omap3-evm: Add DSS {vdds_dsi,vdda_video}-supply references ARM: dts: omap3: Add Sharp LS037V7DW01 'envdd' supply ...
2017-10-20Merge tag 'omap-for-v4.15/ti-sysc-signed' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into next/soc Pull "more soc changes for omaps for v4.15 merge window" from Tony Lindgren: Drop omap legacy platform data for IRQ, DMA and IO resources. With the dts files fixed up to contain the necessary data for basic resources, we can drop the related platform data. Note that this branch depends on the "omap-for-v4.15/fixes-dt-signed" branch and the patches with dependencies are based on a merge with that branch. These patches first ensure things keep working for the legacy "ti,hwmods" property when we start making it optional, then adds a minimal TI sysc interconnect target device driver to handle the new generic "ti,sysc" compatible property. And then we can finally drop the legacy platform data for IRQ, DMA and IO resources as seen in the diffstats. * tag 'omap-for-v4.15/ti-sysc-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: (25 commits) bus: ti-sysc: Fix unbalanced pm_runtime_enable by adding remove bus: ti-sysc: mark PM functions as __maybe_unused ARM: OMAP2+: omap_device: fix error return code in omap_device_copy_resources() ARM: OMAP2+: Drop legacy struct omap_hwmod_addr_space ARM: OMAP2+: Drop omap_hwmod_dma_info ARM: OMAP2+: Drop omap_hwmod_irq_info ARM: OMAP4: Remove legacy IRQ for PRM ARM: OMAP3: Remove legacy IRQ for PRM bus: ti-sysc: Add minimal TI sysc interconnect target driver ARM: OMAP2+: Populate legacy resources for dma and smartreflex ARM: OMAP2+: Parse module IO range from dts for legacy "ti,hwmods" support ARM: dts: Configure SmartReflex only to idle the interconnect target module ARM: dts: Add nodes for missing omap4 interconnect target modules dt-bindings: bus: Minimal TI sysc interconnect target module binding ARM: dts: Add missing hwmod related properties for dra7 ARM: dts: Add missing hwmod related nodes for am33xx ARM: dts: Add missing dma hwmod property for omap5 ARM: dts: Add missing wdt3 node for omap4 ARM: dts: Add missing hsi node for omap4 ARM: dts: Add missing onewire node for omap4 ...
2017-10-20Merge tag 'omap-for-v4.15/fixes-dt-signed' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into next/soc Pull "non-urgent device tree fixes for omaps for v4.15 merge window" from Tony Lindgren Non-urgent device tree fixes for omaps that can all wait for v4.15 merge window. Turns out that we have many devices working just because we have the legacy platform data still around. This is mostly an issue for omap4, other SoCs just have minimal fixes needed. As many of the missing device tree nodes and properties are for devices that have no drivers in the mainline kernel, such as slimbus, iss, mcasp, aess, fdif and gpu, we might as well start using the new "ti,sysc" interconnect target module binding for them so we can get the devices with no child device drivers idled. This also makes it possible to drop unnecessary platform data in later patches. * tag 'omap-for-v4.15/fixes-dt-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: ARM: dts: Fix typo for omap4 mcasp rx path ARM: dts: Configure SmartReflex only to idle the interconnect target module ARM: dts: Add nodes for missing omap4 interconnect target modules dt-bindings: bus: Minimal TI sysc interconnect target module binding ARM: dts: Add missing hwmod related properties for dra7 ARM: dts: Add missing hwmod related nodes for am33xx ARM: dts: Add missing dma hwmod property for omap5 ARM: dts: Add missing wdt3 node for omap4 ARM: dts: Add missing hsi node for omap4 ARM: dts: Add missing onewire node for omap4 ARM: dts: Add missing smartreflex node and binding for omap4 ARM: dts: Add missing hwmods property for omap4 dma ARM: dts: Add missing properties for omap4 control modules ARM: dts: Configure pmu without interrupt for omap4430 ARM: dts: Add missing dma hwmods property for omap3
2017-10-20Merge tag 'v4.15-rockchip-dts64-1' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into next/soc Pull "Rockchip dts64 updates for 4.15 part1" from Heiko Stübner: The biggest step forward is probably the enablement of display support on the rk3399-firefly, which got its default serial set as well and got cec support as well. Gru boards got their touchpad support refined to actually mark the button correctly and also git their rt5514 dsp added. And finally the rk3328 eval board got its cpu regulator and mmc nodes. * tag 'v4.15-rockchip-dts64-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip: arm64: dts: rockchip: enable cec pin for rk3399 firefly arm64: dts: rockchip: add the cec clk for dw-mipi-hdmi on rk3399 arm64: dts: rockchip: default serial for Firefly-RK3399 arm64: dts: rockchip: enable touchpad button for rk3399-gru-kevin arm64: dts: rockchip: enable display subsystem on rk3399-firefly arm64: dts: rockchip: Add rt5514 dsp for rk3399 gru arm64: dts: rockchip: add cpu regulator for rk3328 evaluation board arm64: dts: rockchip: add mmc nodes for rk3328 evaluation board
2017-10-20Merge tag 'v4.15-rockchip-dts32-1' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into next/soc Pull "Rockchip dts32 updates for 4.15 part1" from Heiko Stübner: One new board the Vyasa from Amarula Solutions using a rk3288 and core lvds node for the newly added driver+binding. Also bindings + nodes for the Mali-Utgard GPUs found on some Rockchip socs like rk3036 and rk3188. With the recently revived Lima project they can even render a red triangle to a png file. * tag 'v4.15-rockchip-dts32-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip: ARM: dts: rockchip: Enable thermal on rk3288-vyasa board ARM: dts: rockchip: fix mali400 ppmmu interrupt names ARM: dts: rockchip: Enable mali GPU node on rk3288-vyasa ARM: dts: rockchip: enable gpu on rk3188-radxarock ARM: dts: rockchip: add gpu nodes on rk3066/rk3188 ARM: dts: rockchip: add rk322x gpu node ARM: dts: rockchip: enable the gpu on rk3036-kylin boards ARM: dts: rockchip: add rk3036 gpu node dt-bindings: gpu: mali-utgard: add optional power-domain reference dt-bindings: gpu: mali-utgard: add optional supply regulator dt-bindings: gpu: mali-utgard: Add Rockchip Utgard Malis ARM: dts: rockchip: enable vops and hdmi output on rk3288-vyasa ARM: dts: rockchip: Add rk3288 vyasa board dt-bindings: Add vendor prefix for Amarula Solutions ARM: dts: rockchip: add LVDS node for rk3288
2017-10-20Merge tag 'stm32-dt-for-v4.15-1' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32 into next/soc Pull "STM32 DT updates for v4.15, round 1" from Alexandre Torgue: Highlights: ---------- -Add I2C1 support on STM32F746 SoC -Enable I2C1 on STM32F746 eval board -Add Timers support on STM32F746 SoC -Add USB HS and FS supports on STM32F746 Soc -Enable USB HS on STM32F746 disco and eval boards -Enable USB FS en STM32F746 disco board -Add Vrefbuf to STM32H743 SoC -Add LPTIMERS support on STM32H743 SoC -Add DMAMUX support on STM32H743 SoC -Enable STM32H743 clock driver -Add MDMA support on STM32H743 SoC -Change pinctrl pinmux entries for all SoC. * tag 'stm32-dt-for-v4.15-1' of git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32: ARM: dts: stm32: Add MDMA support for STM32H743 SoC ARM: dts: stm32: Enable USB FS on stm32f746-disco ARM: dts: stm32: Add USB FS support for STM32F746 MCU ARM: dts: stm32: Enable USB HS on stm32f746-disco ARM: dts: stm32: Enable USB HS on stm32746g-eval ARM: dts: stm32: Add USB HS support for STM32F746 MCU ARM: dts: stm32: change pinctrl bindings definition ARM: dts: stm32: Enable STM32H743 clock driver ARM: dts: stm32: fix hse clock frequency on STM32H743 Eval board ARM: dts: stm32: add Timers driver for stm32f746 MCU ARM: dts: stm32: Add DMAMUX support for STM32H743 SoC ARM: dts: stm32: Add lptimer definitions to stm32h743 ARM: dts: stm32: add vrefbuf to stm32h743 ARM: dts: stm32: Add I2C1 support for STM32F746 eval board ARM: dts: stm32: Add I2C1 support for STM32F746 SoC
2017-10-20Merge tag 'qcom-dts-for-4.15' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux into next/soc Pull "Qualcomm Device Tree Changes for v4.15" from Andy Gross: * Add Support for MSM8974 based Fairphone 2 phone * Add support for MSM8974 based Sony Xperia Z2 Tablet * Add MSM8660 GSBI6/7 nodes * Disable GSBI6 at APQ8064 platform level * Fix phy cells on APQ8064 * tag 'qcom-dts-for-4.15' of git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux: ARM: dts: msm8974-FP2: Add USB node ARM: dts: msm8974-FP2: Add sdhci1 node ARM: dts: msm8974-FP2: Add regulator nodes for FP2 ARM: dts: msm8974-FP2: Introduce gpio-keys nodes ARM: dts: qcom: Add initial DTS file for Fairphone 2 phone ARM: dts: qcom: add MSM8660 GSBI6 and GSBI7 ARM: dts: qcom: msm8974: Add Sony Xperia Z2 Tablet ARM: dts: qcom-apq8064: disable gsbi6 i2c by default at soc dtsi ARM: dts: qcom-apq8064: Fix dsi and hdmi phy cells
2017-10-20Merge tag 'qcom-arm64-for-4.15' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux into next/soc Pull "Qualcomm ARM64 Updates for v4.15" from Andy Gross: * Add PCIE support to relevant MSM8996 based boards * Add RPM clock controller node on MSM8996 * Add dload address on MSM8916 and MSM8996 * Add MBHC button support on APQ8016 SBC * Add RTMFS specific compatible for rmtfs memory node * Fixups for MSM8916 GPIO line names and MDP address length * tag 'qcom-arm64-for-4.15' of git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux: arm64: dts: msm8916: Mark rmtfs node as qcom, rmtfs-mem compatible arm64: dts: msm8996: Add the rpm clock controller node arm64: dts: qcom: sbc: Name GPIO lines arm64: dts: qcom: msm8916: Shrink mdp address length for msm8916 arm64: dts: apq8016-sbc: add mbhc buttons support arm64: dts: qcom: Specify dload address for msm8916 and msm8996 arm64: dts: apq8096-db820c: never disable regulator on LS expansion arm64: dts: apq8096-db820c: Enable on board 3 pcie root complex arm64: dts: qcom: msm8996: add support to pcie
2017-10-20Merge tag 'zynq-dt-for-4.15' of https://github.com/Xilinx/linux-xlnx into ↵Arnd Bergmann
next/soc Pull "arm: Xilinx ZynqMP DT changes for v4.15" from Michal Simek: - Change 24c08 compatible string * tag 'zynq-dt-for-4.15' of https://github.com/Xilinx/linux-xlnx: ARM: dts: zynq: Add generic compatible string for I2C EEPROM
2017-10-20Merge tag 'samsung-dt-4.15' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into next/soc Pull "Samsung DTS ARM changes for 4.15" from Krzysztof Kozłowski: 1. Add new board: Hardkernel Odroid HC1. 2. Fix incomplete Odroid-XU3/4 thermal-zones definition leading to possible overheat if first pair of A7+A15 cores is idle but rest of CPUs are busy. 3. Add capacity-dmips-mhz properties for CPUs of octa-core SoCs. 4. Add power button to Odroid XU3/4. 5. Improvements in Gscaler, HDMI and Mixer blocks on Exynos5. 6. Add suspend quirk to DWC3 USB controller to fix enumeration of SuperSpeed devices on Odroid XU4. 7. Add HDMI and MHL to Trats2. 8. Cleanups (redundant properties and nodes). * tag 'samsung-dt-4.15' of git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux: dt-bindings: samsung: Document binding for new Odroid HC1 board ARM: dts: exynos: Add HDMI and Sil9234 to Trats2 board ARM: dts: exynos: Add support for Hardkernel's Odroid HC1 board ARM: dts: exynos: Move audio clocks configuration to odroidxu3-audio.dtsi ARM: dts: exynos: Add dwc3 SUSPHY quirk ARM: dts: exynos: Add status property to Exynos 542x Mixer nodes ARM: dts: exynos: Add status property to Exynos 5250 HDMI and Mixer nodes ARM: dts: exynos: Cleanup HDMI DCC definitions on Exynos5250 and Exynos542x boards ARM: dts: exynos: Move HDMI PHY node from boards to exynos5250.dtsi ARM: dts: exynos: Use specific compatibles for proper Gscaler limits on Exynos5250 and Exynos5420 ARM: dts: exynos: Remove redundant interrupt properties in gpio-keys on Odroid boards ARM: dts: exynos: Add power button for Odroid XU3/4 ARM: dts: exynos: Remove the display-timing and delay from Rinato ARM: dts: exynos: add exynos5422 cpu capacity-dmips-mhz information ARM: dts: exynos: add exynos5420 cpu capacity-dmips-mhz information ARM: dts: exynos: fix incomplete Odroid-XU3/4 thermal-zones definition