aboutsummaryrefslogtreecommitdiffstats
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2019-06-19arm64: dts: sprd: Add Spreadtrum SD host controller supportBaolin Wang1-0/+35
Add one Spreadtrum SD host controller to support eMMC card for Spreadtrum SC9860 platform. Signed-off-by: Baolin Wang <baolin.wang@linaro.org> Signed-off-by: Olof Johansson <olof@lixom.net>
2019-06-19Merge tag 'integrator-dts-v5.3-arm-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator into arm/dtOlof Johansson8-0/+36
DTS updates for the Integrator, target kernel v5.3. * tag 'integrator-dts-v5.3-arm-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator: ARM: dts: vexpress: specify AFS partition ARM: dts: realview: specify AFS partition ARM: dts: versatile: specify AFS partition ARM: dts: integrator: specify AFS partition Signed-off-by: Olof Johansson <olof@lixom.net>
2019-06-19powerpc: enable a 30-bit ZONE_DMA for 32-bit pmacChristoph Hellwig3-1/+10
With the strict dma mask checking introduced with the switch to the generic DMA direct code common wifi chips on 32-bit powerbooks stopped working. Add a 30-bit ZONE_DMA to the 32-bit pmac builds to allow them to reliably allocate dma coherent memory. Fixes: 65a21b71f948 ("powerpc/dma: remove dma_nommu_dma_supported") Reported-by: Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: Christoph Hellwig <hch@lst.de> Tested-by: Larry Finger <Larry.Finger@lwfinger.net> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2019-06-19ARM: dts: gemini Fix up DNS-313 compatible stringLinus Walleij1-1/+1
It's a simple typo in the DNS file, which was pretty serious. No scripts were working properly. Fix it up. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-06-19ARM: dts: Blank D-Link DIR-685 consoleLinus Walleij1-1/+1
Leaving this NAS with display and backlight on heats it up and dissipates power. Turn off the screen after 4 minutes, it comes back on when a user touches the keys. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-06-19Merge branch 'topic/remove-fbcon-notifiers' into drm-misc-nextMaarten Lankhorst1-2/+11
topic/remove-fbcon-notifiers: - remove fbdev notifier usage for fbcon, as prep work to clean up the fbcon locking - assorted locking checks in vt/console code - assorted notifier and cleanups in fbdev and backlight code This is the pull request that was sent out, plus the compile fix for sh4 reported by kbuild. Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2019-06-19powerpc/64s/radix: Enable HAVE_ARCH_HUGE_VMAPNicholas Piggin3-0/+109
This sets the HAVE_ARCH_HUGE_VMAP option, and defines the required page table functions. This enables huge (2MB and 1GB) ioremap mappings. I don't have a benchmark for this change, but huge vmap will be used by a later core kernel change to enable huge vmalloc memory mappings. This improves cached `git diff` performance by about 5% on a 2-node POWER9 with 32MB size dentry cache hash. Profiling git diff dTLB misses with a vanilla kernel: 81.75% git [kernel.vmlinux] [k] __d_lookup_rcu 7.21% git [kernel.vmlinux] [k] strncpy_from_user 1.77% git [kernel.vmlinux] [k] find_get_entry 1.59% git [kernel.vmlinux] [k] kmem_cache_free 40,168 dTLB-miss 0.100342754 seconds time elapsed With powerpc huge vmalloc: 2,987 dTLB-miss 0.095933138 seconds time elapsed Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2019-06-19powerpc/64s/radix: ioremap use ioremap_page_rangeNicholas Piggin4-1/+46
Radix can use ioremap_page_range for ioremap, after slab is available. This makes it possible to enable huge ioremap mapping support. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2019-06-19powerpc/64: __ioremap_at clean up in the error caseNicholas Piggin1-7/+20
__ioremap_at error handling is wonky, it requires caller to clean up after it. Implement a helper that does the map and error cleanup and remove the requirement from the caller. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2019-06-19powerpc/perf: Use cpumask_last() to determine the designated cpu for nest/core units.Anju T Sudhakar1-2/+12
Nest and core IMC (In-Memory Collection counters) assigns a particular cpu as the designated target for counter data collection. During system boot, the first online cpu in a chip gets assigned as the designated cpu for that chip(for nest-imc) and the first online cpu in a core gets assigned as the designated cpu for that core(for core-imc). If the designated cpu goes offline, the next online cpu from the same chip(for nest-imc)/core(for core-imc) is assigned as the next target, and the event context is migrated to the target cpu. Currently, cpumask_any_but() function is used to find the target cpu. Though this function is expected to return a `random` cpu, this always returns the next online cpu. If all cpus in a chip/core is offlined in a sequential manner, starting from the first cpu, the event migration has to happen for all the cpus which goes offline. Since the migration process involves a grace period, the total time taken to offline all the cpus will be significantly high. Example: In a system which has 2 sockets, with NUMA node0 CPU(s): 0-87 NUMA node8 CPU(s): 88-175 Time taken to offline cpu 88-175: real 2m56.099s user 0m0.191s sys 0m0.000s Use cpumask_last() to choose the target cpu, when the designated cpu goes online, so the migration will happen only when the last_cpu in the mask goes offline. This way the time taken to offline all cpus in a chip/core can be reduced. With the patch: Time taken to offline cpu 88-175: real 0m12.207s user 0m0.171s sys 0m0.000s Offlining all cpus in reverse order is also taken care because, cpumask_any_but() is used to find the designated cpu if the last cpu in the mask goes offline. Since cpumask_any_but() always return the first cpu in the mask, that becomes the designated cpu and migration will happen only when the first_cpu in the mask goes offline. Example: With the patch, Time taken to offline cpu from 175-88: real 0m9.330s user 0m0.110s sys 0m0.000s Signed-off-by: Anju T Sudhakar <anju@linux.vnet.ibm.com> Reviewed-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2019-06-19powerpc/64s: Fix misleading SPR and timebase informationShaokun Zhang1-2/+2
pr_info shows SPR and timebase as a decimal value with a '0x' prefix, which is somewhat misleading. Fix it to print hexadecimal, as was intended. Fixes: 10d91611f426 ("powerpc/64s: Reimplement book3s idle code in C") Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Shaokun Zhang <zhangshaokun@hisilicon.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2019-06-19powerpc/pseries: avoid blocking in irq when queuing hotplug eventsNathan Lynch1-4/+4
A couple of bugs in queue_hotplug_event(): 1. Unchecked kmalloc result which could lead to an oops. 2. Use of GFP_KERNEL allocations in interrupt context (this code's only caller is ras_hotplug_interrupt()). Use kmemdup to avoid open-coding the allocation+copy and check for failure; use GFP_ATOMIC for both allocations. Ultimately it probably would be better to avoid or reduce allocations in this path if possible. Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2019-06-19powerpc/watchpoint: Restore NV GPRs while returning from exceptionRavi Bangoria1-2/+7
powerpc hardware triggers watchpoint before executing the instruction. To make trigger-after-execute behavior, kernel emulates the instruction. If the instruction is 'load something into non-volatile register', exception handler should restore emulated register state while returning back, otherwise there will be register state corruption. eg, adding a watchpoint on a list can corrput the list: # cat /proc/kallsyms | grep kthread_create_list c00000000121c8b8 d kthread_create_list Add watchpoint on kthread_create_list->prev: # perf record -e mem:0xc00000000121c8c0 Run some workload such that new kthread gets invoked. eg, I just logged out from console: list_add corruption. next->prev should be prev (c000000001214e00), \ but was c00000000121c8b8. (next=c00000000121c8b8). WARNING: CPU: 59 PID: 309 at lib/list_debug.c:25 __list_add_valid+0xb4/0xc0 CPU: 59 PID: 309 Comm: kworker/59:0 Kdump: loaded Not tainted 5.1.0-rc7+ #69 ... NIP __list_add_valid+0xb4/0xc0 LR __list_add_valid+0xb0/0xc0 Call Trace: __list_add_valid+0xb0/0xc0 (unreliable) __kthread_create_on_node+0xe0/0x260 kthread_create_on_node+0x34/0x50 create_worker+0xe8/0x260 worker_thread+0x444/0x560 kthread+0x160/0x1a0 ret_from_kernel_thread+0x5c/0x70 List corruption happened because it uses 'load into non-volatile register' instruction: Snippet from __kthread_create_on_node: c000000000136be8: addis r29,r2,-19 c000000000136bec: ld r29,31424(r29) if (!__list_add_valid(new, prev, next)) c000000000136bf0: mr r3,r30 c000000000136bf4: mr r5,r28 c000000000136bf8: mr r4,r29 c000000000136bfc: bl c00000000059a2f8 <__list_add_valid+0x8> Register state from WARN_ON(): GPR00: c00000000059a3a0 c000007ff23afb50 c000000001344e00 0000000000000075 GPR04: 0000000000000000 0000000000000000 0000001852af8bc1 0000000000000000 GPR08: 0000000000000001 0000000000000007 0000000000000006 00000000000004aa GPR12: 0000000000000000 c000007ffffeb080 c000000000137038 c000005ff62aaa00 GPR16: 0000000000000000 0000000000000000 c000007fffbe7600 c000007fffbe7370 GPR20: c000007fffbe7320 c000007fffbe7300 c000000001373a00 0000000000000000 GPR24: fffffffffffffef7 c00000000012e320 c000007ff23afcb0 c000000000cb8628 GPR28: c00000000121c8b8 c000000001214e00 c000007fef5b17e8 c000007fef5b17c0 Watchpoint hit at 0xc000000000136bec. addis r29,r2,-19 => r29 = 0xc000000001344e00 + (-19 << 16) => r29 = 0xc000000001214e00 ld r29,31424(r29) => r29 = *(0xc000000001214e00 + 31424) => r29 = *(0xc00000000121c8c0) 0xc00000000121c8c0 is where we placed a watchpoint and thus this instruction was emulated by emulate_step. But because handle_dabr_fault did not restore emulated register state, r29 still contains stale value in above register state. Fixes: 5aae8a5370802 ("powerpc, hw_breakpoints: Implement hw_breakpoints for 64-bit server processors") Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com> Cc: stable@vger.kernel.org # 2.6.36+ Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2019-06-19powerpc/ps3: Use [] to denote a flexible array memberGeert Uytterhoeven1-1/+1
Flexible array members should be denoted using [] instead of [0], else gcc will not warn when they are no longer at the end of the structure. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2019-06-19powerpc/mm/32s: fix condition that is always trueAndreas Schwab1-1/+1
Move a misplaced paren that makes the condition always true. Fixes: 63b2bc619565 ("powerpc/mm/32s: Use BATs for STRICT_KERNEL_RWX") Cc: stable@vger.kernel.org # v5.1+ Signed-off-by: Andreas Schwab <schwab@linux-m68k.org> Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2019-06-19powerpc/32s: fix suspend/resume when IBATs 4-7 are usedChristophe Leroy2-13/+128
Previously, only IBAT1 and IBAT2 were used to map kernel linear mem. Since commit 63b2bc619565 ("powerpc/mm/32s: Use BATs for STRICT_KERNEL_RWX"), we may have all 8 BATs used for mapping kernel text. But the suspend/restore functions only save/restore BATs 0 to 3, and clears BATs 4 to 7. Make suspend and restore functions respectively save and reload the 8 BATs on CPUs having MMU_FTR_USE_HIGH_BATS feature. Reported-by: Andreas Schwab <schwab@linux-m68k.org> Cc: stable@vger.kernel.org Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2019-06-19arm64: dts: ti: k3-j721e: Add the MCU SRAM nodeSuman Anna1-0/+8
Add the on-chip SRAM present within the MCU domain as a mmio-sram node. The K3 J721E SoCs have 1 MB of such memory. Any specific memory range within this RAM needed by a driver/software module ought to be reserved using an appropriate child node. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Tero Kristo <t-kristo@ti.com>
2019-06-19arm64: dts: ti: k3-j721e: Add interrupt controllers in wakeup domainLokesh Vutla1-0/+11
Wakeup domain in J721E SoC has an interrupt router connected to gpio in wakeup domain. Add DT node for this interrupt router. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tero Kristo <t-kristo@ti.com>
2019-06-19arm64: dts: ti: k3-j721e: Add interrupt controllers in main domainLokesh Vutla1-0/+23
Main domain in J721E has the following interrupt controller instances: - Main Domain GPIO Interrupt router connected to gpio in main domain. - Under the Main Domain Navigator Subsystem(NAVSS) - Main Navss Interrupt Router connected to main navss inta and mailboxes. - Main Navss Interrupt Aggregator connected to main domain UDMASS Add DT nodes for the interrupt controllers available in main domain. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tero Kristo <t-kristo@ti.com>
2019-06-19arm64: dts: ti: k3-j721e-main: Add Main NavSS Interrupt controller nodeSuman Anna1-0/+18
Add the Interrupt controller node for the Interrupt Router present within the Main NavSS module. This Interrupt Router can route 192 interrupts to the GIC_SPI in 3 sets of 64 interrupts each. Note that the last set is reserved for the host ID A72_3 for hypervisor usecases, so the node is added only with 2 sets for the Linux kernel context (host id A72_2). This is specified through the ti,sci-rm-range-girq property. Signed-off-by: Suman Anna <s-anna@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tero Kristo <t-kristo@ti.com>
2019-06-19arm64: defconfig: Enable TI's J721E SoC platformNishanth Menon1-0/+1
Enable J721E SoC support from TI. Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Tero Kristo <t-kristo@ti.com>
2019-06-19arm64: dts: ti: Add support for J721E Common Processor BoardNishanth Menon3-0/+81
Add Support for J721E Common Processor board support. The EVM architecture is as follows: +------------------------------------------------------+ | +-------------------------------------------+ | | | | | | | Add-on Card 1 Options | | | | | | | +-------------------------------------------+ | | | | | | +-------------------+ | | | | | | | SOM | | | +--------------+ | | | | | | | | | | | Add-on | +-------------------+ | | | Card 2 | | Power Supply | | Options | | | | | | | | | +--------------+ | <--- +------------------------------------------------------+ Common Processor Board Common Processor board is the baseboard that has most of the actual connectors, power supply etc. A SOM (System on Module) is plugged on to the common processor board and this contains the SoC, PMIC, DDR and basic high speed components necessary for functionality. Add-n card options add further functionality (such as additional Audio, Display, networking options). Note: A) The minimum configuration required to boot up the board is System On Module(SOM) + Common Processor Board. B) Since there is just a single SOM and Common Processor Board, we are maintaining common processor board as the base dts and SOM as the dtsi that we include. In the future as more SOM's appear, we should move common processor board as a dtsi and include configurations as dts. C) All daughter cards beyond the basic boards shall be maintained as overlays. Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Tero Kristo <t-kristo@ti.com>
2019-06-19arm64: dts: ti: Add Support for J721E SoCNishanth Menon3-0/+450
The J721E SoC belongs to the K3 Multicore SoC architecture platform, providing advanced system integration to enable lower system costs of automotive applications such as infotainment, cluster, premium Audio, Gateway, industrial and a range of broad market applications. This SoC is designed around reducing the system cost by eliminating the need of an external system MCU and is targeted towards ASIL-B/C certification/requirements in addition to allowing complex software and system use-cases. Some highlights of this SoC are: * Dual Cortex-A72s in a single cluster, three clusters of lockstep capable dual Cortex-R5F MCUs, Deep-learning Matrix Multiply Accelerator(MMA), C7x floating point Vector DSP, Two C66x floating point DSPs. * 3D GPU PowerVR Rogue 8XE GE8430 * Vision Processing Accelerator (VPAC) with image signal processor and Depth and Motion Processing Accelerator (DMPAC) * Two Gigabit Industrial Communication Subsystems (ICSSG), each with dual PRUs and dual RTUs * Two CSI2.0 4L RX plus one CSI2.0 4L TX, one eDP/DP, One DSI Tx, and up to two DPI interfaces. * Integrated Ethernet switch supporting up to a total of 8 external ports in addition to legacy Ethernet switch of up to 2 ports. * System MMU (SMMU) Version 3.0 and advanced virtualisation capabilities. * Upto 4 PCIe-GEN3 controllers, 2 USB3.0 Dual-role device subsystems, 16 MCANs, 12 McASP, eMMC and SD, UFS, OSPI/HyperBus memory controller, QSPI, I3C and I2C, eCAP/eQEP, eHRPWM, MLB among other peripherals. * Two hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL management. * Configurable L3 Cache and IO-coherent architecture with high data throughput capable distributed DMA architecture under NAVSS * Centralized System Controller for Security, Power, and Resource Management (DMSC) See J721E Technical Reference Manual (SPRUIL1, May 2019) for further details: http://www.ti.com/lit/pdf/spruil1 Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Suman Anna <s-anna@ti.com> Signed-off-by: Tero Kristo <t-kristo@ti.com>
2019-06-19x86/microcode: Fix the microcode load on CPU hotplug for realThomas Gleixner1-5/+10
A recent change moved the microcode loader hotplug callback into the early startup phase which is running with interrupts disabled. It missed that the callbacks invoke sysfs functions which might sleep causing nice 'might sleep' splats with proper debugging enabled. Split the callbacks and only load the microcode in the early startup phase and move the sysfs handling back into the later threaded and preemptible bringup phase where it was before. Fixes: 78f4e932f776 ("x86/microcode, cpuhotplug: Add a microcode loader CPU hotplug callback") Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: stable@vger.kernel.org Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1906182228350.1766@nanos.tec.linutronix.de
2019-06-19arm64: dts: qcom: pm8998: Use qcom,pm8998-pon binding for second gen ponJohn Stultz1-1/+1
This changes pm8998 to use the new qcom,pm8998-pon compatible string for the pon in order to support the gen2 pon functionality properly. Cc: Andy Gross <agross@kernel.org> Cc: David Brown <david.brown@linaro.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Amit Pundir <amit.pundir@linaro.org> Cc: Rob Herring <robh+dt@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Sebastian Reichel <sre@kernel.org> Cc: linux-arm-msm@vger.kernel.org Cc: devicetree@vger.kernel.org Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Andy Gross <agross@kernel.org>
2019-06-19arm64: dts: qcom: msm8996: Enable SMMUsBjorn Andersson1-6/+0
Enable SMMUs on 8996 now that the WRZ workaround in the arm-smmu driver has landed. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Andy Gross <agross@kernel.org>
2019-06-18arm64: dts: qcom: msm8996: Correct apr-domain propertyBjorn Andersson1-1/+1
The domain specifier was changed from using "reg" to "qcom,apr-domain", update the dts accordingly. Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2019-06-18arm64: dts: qcom: Add Dragonboard 845cBjorn Andersson2-0/+558
This adds an initial dts for the Dragonboard 845. Supported functionality includes Debug UART, UFS, USB-C (peripheral), USB-A (host), microSD-card and Bluetooth. Initializing the SMMU is clearing the mapping used for the splash screen framebuffer, which causes the board to reboot. This can be worked around using: fastboot oem select-display-panel none Reviewed-by: Vinod Koul <vkoul@kernel.org> Reviewed-by: Vivek Gautam <vivek.gautam@codeaurora.org> Tested-by: Vinod Koul <vkoul@kernel.org> Tested-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2019-06-18arm64: dts: msm8998-mtp: Add pm8005_s1 regulatorJeffrey Hugo1-0/+17
The pm8005_s1 is VDD_GFX, and needs to be on to enable the GPU. This should be hooked up to the GPU CPR, but we don't have support for that yet, so until then, just turn on the regulator and keep it on so that we can focus on basic GPU bringup. Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-06-18Merge tag 'v5.2-rc4' into regulator-5.3Mark Brown3392-23922/+4732
Linux 5.2-rc4
2019-06-18Merge tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/socLinus Torvalds42-40/+100
Pull ARM SoC fixes from Olof Johansson: "I've been bad at collecting fixes this release cycle, so this is a fairly large batch that's been trickling in for a while. It's the usual mix, more or less. Some of the bigger things fixed: - Voltage fix for MMC on TI DRA7 that sometimes would overvoltage cards - Regression fixes for D_CAN on am355x - i.MX6SX cpuidle fix to deal with wakeup latency (dropped uart chars) - DT fixes for some DRA7 variants that don't share the superset of blocks on the chip plus the usual mix of stuff: minor build/warning fixes, Kconfig dependencies, and some DT fixlets" * tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (28 commits) soc: ixp4xx: npe: Fix an IS_ERR() vs NULL check in probe ARM: ixp4xx: include irqs.h where needed ARM: ixp4xx: mark ixp4xx_irq_setup as __init ARM: ixp4xx: don't select SERIAL_OF_PLATFORM firmware: trusted_foundations: add ARMv7 dependency MAINTAINERS: Change QCOM repo location ARM: davinci: da8xx: specify dma_coherent_mask for lcdc ARM: davinci: da850-evm: call regulator_has_full_constraints() ARM: mvebu_v7_defconfig: fix Ethernet on Clearfog ARM: dts: am335x phytec boards: Fix cd-gpios active level ARM: dts: dra72x: Disable usb4_tm target module arm64: arch_k3: Fix kconfig dependency warning ARM: dts: Drop bogus CLKSEL for timer12 on dra7 MAINTAINERS: Update Stefan Wahren email address ARM: dts: bcm: Add missing device_type = "memory" property soc: bcm: brcmstb: biuctrl: Register writes require a barrier soc: brcmstb: Fix error path for unsupported CPUs ARM: dts: dra71x: Disable usb4_tm target module ARM: dts: dra71x: Disable rtc target module ARM: dts: dra76x: Disable usb4_tm target module ...
2019-06-18KVM: nVMX: shadow pin based execution controlsPaolo Bonzini1-0/+1
The VMX_PREEMPTION_TIMER flag may be toggled frequently, though not *very* frequently. Since it does not affect KVM's dirty logic, e.g. the preemption timer value is loaded from vmcs12 even if vmcs12 is "clean", there is no need to mark vmcs12 dirty when L1 writes pin controls, and shadowing the field achieves that. Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-06-18KVM: VMX: Leave preemption timer running when it's disabledSean Christopherson3-25/+41
VMWRITEs to the major VMCS controls, pin controls included, are deceptively expensive. CPUs with VMCS caching (Westmere and later) also optimize away consistency checks on VM-Entry, i.e. skip consistency checks if the relevant fields have not changed since the last successful VM-Entry (of the cached VMCS). Because uops are a precious commodity, uCode's dirty VMCS field tracking isn't as precise as software would prefer. Notably, writing any of the major VMCS fields effectively marks the entire VMCS dirty, i.e. causes the next VM-Entry to perform all consistency checks, which consumes several hundred cycles. As it pertains to KVM, toggling PIN_BASED_VMX_PREEMPTION_TIMER more than doubles the latency of the next VM-Entry (and again when/if the flag is toggled back). In a non-nested scenario, running a "standard" guest with the preemption timer enabled, toggling the timer flag is uncommon but not rare, e.g. roughly 1 in 10 entries. Disabling the preemption timer can change these numbers due to its use for "immediate exits", even when explicitly disabled by userspace. Nested virtualization in particular is painful, as the timer flag is set for the majority of VM-Enters, but prepare_vmcs02() initializes vmcs02's pin controls to *clear* the flag since its the timer's final state isn't known until vmx_vcpu_run(). I.e. the majority of nested VM-Enters end up unnecessarily writing pin controls *twice*. Rather than toggle the timer flag in pin controls, set the timer value itself to the largest allowed value to put it into a "soft disabled" state, and ignore any spurious preemption timer exits. Sadly, the timer is a 32-bit value and so theoretically it can fire before the head death of the universe, i.e. spurious exits are possible. But because KVM does *not* save the timer value on VM-Exit and because the timer runs at a slower rate than the TSC, the maximuma timer value is still sufficiently large for KVM's purposes. E.g. on a modern CPU with a timer that runs at 1/32 the frequency of a 2.4ghz constant-rate TSC, the timer will fire after ~55 seconds of *uninterrupted* guest execution. In other words, spurious VM-Exits are effectively only possible if the host is completely tickless on the logical CPU, the guest is not using the preemption timer, and the guest is not generating VM-Exits for any other reason. To be safe from bad/weird hardware, disable the preemption timer if its maximum delay is less than ten seconds. Ten seconds is mostly arbitrary and was selected in no small part because it's a nice round number. For simplicity and paranoia, fall back to __kvm_request_immediate_exit() if the preemption timer is disabled by KVM or userspace. Previously KVM continued to use the preemption timer to force immediate exits even when the timer was disabled by userspace. Now that KVM leaves the timer running instead of truly disabling it, allow userspace to kill it entirely in the unlikely event the timer (or KVM) malfunctions. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-06-18arm64/mm: don't initialize pgd_cache twiceMike Rapoport1-2/+1
When PGD_SIZE != PAGE_SIZE, arm64 uses kmem_cache for allocation of PGD memory. That cache was initialized twice: first through pgtable_cache_init() alias and then as an override for weak pgd_cache_init(). Remove the alias from pgtable_cache_init() and keep the only pgd_cache initialization in pgd_cache_init(). Fixes: caa841360134 ("x86/mm: Initialize PGD cache during mm initialization") Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2019-06-18arm64/sve: <uapi/asm/ptrace.h> should not depend on <uapi/linux/prctl.h>Anisse Astier1-5/+3
Pulling linux/prctl.h into asm/ptrace.h in the arm64 UAPI headers causes userspace build issues for any program (e.g. strace and qemu) that includes both <sys/prctl.h> and <linux/ptrace.h> when using musl libc: | error: redefinition of 'struct prctl_mm_map' | struct prctl_mm_map { See https://github.com/foundriesio/meta-lmp/commit/6d4a106e191b5d79c41b9ac78fd321316d3013c0 for a public example of people working around this issue. Although it's a bit grotty, fix this breakage by duplicating the prctl constant definitions. Since these are part of the kernel ABI, they cannot be changed in future and so it's not the end of the world to have them open-coded. Fixes: 43d4da2c45b2 ("arm64/sve: ptrace and ELF coredump support") Cc: stable@vger.kernel.org Acked-by: Dave Martin <Dave.Martin@arm.com> Signed-off-by: Anisse Astier <aastier@freebox.fr> Signed-off-by: Will Deacon <will.deacon@arm.com>
2019-06-18arm64: dts: fsl: librem5: Add a device tree for the Librem5 devkitAngus Ainslie (Purism)2-0/+807
This is for the development kit board for the Librem 5. The current level of support yields a working console and is able to boot userspace from the network or eMMC. Additional subsystems that are active : - Both USB ports - SD card socket - WiFi usdhc - WWAN modem - GNSS - GPIO keys - LEDs - gyro - magnetometer - touchscreen - pwm - backlight - haptic motor Signed-off-by: Angus Ainslie (Purism) <angus@akkea.ca> Reviewed-by: Fabio Estevam <festevam@gmail.com> Reviewed-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-06-18arm64: dts: fsl: ls1028a: Add qDMA nodePeng Ma1-0/+20
Add the qDMA device tree nodes for LS1028A devices Signed-off-by: Peng Ma <peng.ma@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-06-18ARM: ixp4xx: include irqs.h where neededArnd Bergmann5-0/+10
Multiple ixp4xx specific files require macros from irqs.h that were moved out from mach/irqs.h, e.g.: arch/arm/mach-ixp4xx/vulcan-pci.c:41:19: error: this function declaration is not a prototype [-Werror,-Wstrict-prototypes] arch/arm/mach-ixp4xx/vulcan-pci.c:49:10: error: implicit declaration of function 'IXP4XX_GPIO_IRQ' [-Werror,-Wimplicit-function-declaration] return IXP4XX_GPIO_IRQ(INTA); Include this header in all files that failed to build because of that. Fixes: dc8ef8cd3a05 ("ARM: ixp4xx: Convert to SPARSE_IRQ") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Olof Johansson <olof@lixom.net>
2019-06-18ARM: ixp4xx: don't select SERIAL_OF_PLATFORMArnd Bergmann1-1/+0
Platforms should not normally select all the device drivers, leave that up to the user and the defconfig file. In this case, we get a warning for randconfig builds: WARNING: unmet direct dependencies detected for SERIAL_OF_PLATFORM Depends on [n]: TTY [=y] && HAS_IOMEM [=y] && SERIAL_8250 [=n] && OF [=y] Selected by [y]: - MACH_IXP4XX_OF [=y] && ARCH_IXP4XX [=y] Fixes: 9540724ca29d ("ARM: ixp4xx: Add device tree boot support") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Olof Johansson <olof@lixom.net>
2019-06-18arm64: dts: renesas: r8a774a1: Add dynamic power coefficientBiju Das1-0/+2
Describe the dynamic power coefficient of A57 and A53 CPUs. Based on work by Gaku Inami <gaku.inami.xw@bp.renesas.com> and others. Signed-off-by: Biju Das <biju.das@bp.renesas.com> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-06-18arm64: dts: renesas: r8a774a1: Create thermal zone to support IPABiju Das1-1/+24
Setup a thermal zone driven by SoC temperature sensor. Create passive trip points and bind them to CPUFreq cooling device that supports power extension. Based on work by Dien Pham <dien.pham.ry@renesas.com> for r8a7796 SoC. Signed-off-by: Biju Das <biju.das@bp.renesas.com> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-06-18arm64: dts: renesas: r8a774a1: Add CPU capacity-dmips-mhzBiju Das1-0/+6
Set the capacity-dmips-mhz for RZ/G2M(r8a774a1) SoC, that is based on dhrystone. Based on work done by Gaku Inami <gaku.inami.xw@bp.renesas.com> for r8a7796 SoC. The average dhrystone result for 5 iterations is as below: r8a774a1 SoC (CA57x2 + CA53x4) CPU max-freq dhrystone --------------------------------- CA57 1500 MHz 11428571 lps/s CA53 1200 MHz 5000000 lps/s From this, CPU capacity-dmips-mhz for CA57 and CA53 are calculated as follows: r8a774a1 SoC CA57 : 1024 / (11428571 / 1500) * (11428571 / 1500) = 1024 CA53 : 1024 / (11428571 / 1500) * ( 5000000 / 1200) = 560 Since each CPUs have different max frequencies, the final CPU capacities of A53 scaled by the above difference is as below $ cat /sys/devices/system/cpu/cpu*/cpu_capacity 1024 1024 448 448 448 448 Signed-off-by: Biju Das <biju.das@bp.renesas.com> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-06-18arm64: dts: renesas: r8a774a1: Add CPU topology on r8a774a1 SoCBiju Das1-0/+26
This patch adds the "cpu-map" into r8a774a1 composed of multi-cluster. This definition is used to parse the cpu topology. Based on work by Gaku Inami <gaku.inami.xw@bp.renesas.com> for r8a7796 SoC. Signed-off-by: Biju Das <biju.das@bp.renesas.com> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-06-18arm64: dts: renesas: hihope-common: Add LEDs supportFabrizio Castro1-0/+24
This patch adds LEDs support to the HiHope RZ/G2[MN] Main Board common device tree. Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-06-18arm64: dts: renesas: hihope-common: Enable USB3.0Biju Das1-0/+29
This patch enables USB3.0 host/peripheral device node for the HiHope RZ/G2M board. Signed-off-by: Biju Das <biju.das@bp.renesas.com> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-06-18KVM: VMX: Drop hv_timer_armed from 'struct loaded_vmcs'Sean Christopherson3-8/+2
... now that it is fully redundant with the pin controls shadow. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-06-18KVM: nVMX: Preset *DT exiting in vmcs02 when emulating UMIPSean Christopherson1-0/+8
KVM dynamically toggles SECONDARY_EXEC_DESC to intercept (a subset of) instructions that are subject to User-Mode Instruction Prevention, i.e. VMCS.SECONDARY_EXEC_DESC == CR4.UMIP when emulating UMIP. Preset the VMCS control when preparing vmcs02 to avoid unnecessarily VMWRITEs, e.g. KVM will clear VMCS.SECONDARY_EXEC_DESC in prepare_vmcs02_early() and then set it in vmx_set_cr4(). Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-06-18KVM: nVMX: Preserve last USE_MSR_BITMAPS when preparing vmcs02Sean Christopherson1-1/+11
KVM dynamically toggles the CPU_BASED_USE_MSR_BITMAPS execution control for nested guests based on whether or not both L0 and L1 want to pass through the same MSRs to L2. Preserve the last used value from vmcs02 so as to avoid multiple VMWRITEs to (re)set/(re)clear the bit on nested VM-Entry. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-06-18KVM: VMX: Explicitly initialize controls shadow at VMCS allocationSean Christopherson3-15/+12
Or: Don't re-initialize vmcs02's controls on every nested VM-Entry. VMWRITEs to the major VMCS controls are deceptively expensive. Intel CPUs with VMCS caching (Westmere and later) also optimize away consistency checks on VM-Entry, i.e. skip consistency checks if the relevant fields have not changed since the last successful VM-Entry (of the cached VMCS). Because uops are a precious commodity, uCode's dirty VMCS field tracking isn't as precise as software would prefer. Notably, writing any of the major VMCS fields effectively marks the entire VMCS dirty, i.e. causes the next VM-Entry to perform all consistency checks, which consumes several hundred cycles. Zero out the controls' shadow copies during VMCS allocation and use the optimized setter when "initializing" controls. While this technically affects both non-nested and nested virtualization, nested virtualization is the primary beneficiary as avoid VMWRITEs when prepare vmcs02 allows hardware to optimizie away consistency checks. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-06-18KVM: nVMX: Don't reset VMCS controls shadow on VMCS switchSean Christopherson2-9/+0
... now that the shadow copies are per-VMCS. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>