summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2020-03-14Merge tag 'arc-5.6-rc6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc Pull ARC fixes from Vineet Gupta: - Fix __ALIGN_STR and __ALIGN to not use default junk padding - Misc Kconfig cleanups, header updates * tag 'arc-5.6-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc: ARC: define __ALIGN_STR and __ALIGN symbols for ARC ARC: show_regs: reduce lines of output ARC: Replace <linux/clk-provider.h> by <linux/of_clk.h> ARC: fpu: fix randconfig build error reported by 0-day test service ARC: fix some Kconfig typos ARC: Cleanup old Kconfig IO scheduler options
2020-03-14Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds
Pull kvm fixes from Paolo Bonzini: "Bugfixes for x86 and s390" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: KVM: nVMX: avoid NULL pointer dereference with incorrect EVMCS GPAs KVM: x86: Initializing all kvm_lapic_irq fields in ioapic_write_indirect KVM: VMX: Condition ENCLS-exiting enabling on CPU support for SGX1 KVM: s390: Also reset registers in sync regs for initial cpu reset KVM: fix Kconfig menu text for -Werror KVM: x86: remove stale comment from struct x86_emulate_ctxt KVM: x86: clear stale x86_emulate_ctxt->intercept value KVM: SVM: Fix the svm vmexit code for WRMSR KVM: X86: Fix dereference null cpufreq policy
2020-03-14Merge branch 'kvm-null-pointer-fix' into kvm-masterPaolo Bonzini
2020-03-14KVM: nVMX: avoid NULL pointer dereference with incorrect EVMCS GPAsVitaly Kuznetsov
When an EVMCS enabled L1 guest on KVM will tries doing enlightened VMEnter with EVMCS GPA = 0 the host crashes because the evmcs_gpa != vmx->nested.hv_evmcs_vmptr condition in nested_vmx_handle_enlightened_vmptrld() will evaluate to false (as nested.hv_evmcs_vmptr is zeroed after init). The crash will happen on vmx->nested.hv_evmcs pointer dereference. Another problematic EVMCS ptr value is '-1' but it only causes host crash after nested_release_evmcs() invocation. The problem is exactly the same as with '0', we mistakenly think that the EVMCS pointer hasn't changed and thus nested.hv_evmcs_vmptr is valid. Resolve the issue by adding an additional !vmx->nested.hv_evmcs check to nested_vmx_handle_enlightened_vmptrld(), this way we will always be trying kvm_vcpu_map() when nested.hv_evmcs is NULL and this is supposed to catch all invalid EVMCS GPAs. Also, initialize hv_evmcs_vmptr to '0' in nested_release_evmcs() to be consistent with initialization where we don't currently set hv_evmcs_vmptr to '-1'. Cc: stable@vger.kernel.org Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-14Merge tag 'kvm-s390-master-5.6-1' of ↵Paolo Bonzini
git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into kvm-master KVM: s390: Fully do the CPU resets as intended With 7de3f1423ff9 ("KVM: s390: Add new reset vcpu API") we clarified the meaning of the reset ioctl to fully reset the CPU and not only the parts that can not be handled by userspace. Turns out that we missed some parts.
2020-03-14KVM: x86: Initializing all kvm_lapic_irq fields in ioapic_write_indirectNitesh Narayan Lal
Previously all fields of structure kvm_lapic_irq were not initialized before it was passed to kvm_bitmap_or_dest_vcpus(). Which will cause an issue when any of those fields are used for processing a request. For example not initializing the msi_redir_hint field before passing to the kvm_bitmap_or_dest_vcpus(), may lead to a misbehavior of kvm_apic_map_get_dest_lapic(). This will specifically happen when the kvm_lowest_prio_delivery() returns TRUE due to a non-zero garbage value of msi_redir_hint, which should not happen as the request belongs to APIC fixed delivery mode and we do not want to deliver the interrupt only to the lowest priority candidate. This patch initializes all the fields of kvm_lapic_irq based on the values of ioapic redirect_entry object before passing it on to kvm_bitmap_or_dest_vcpus(). Fixes: 7ee30bc132c6 ("KVM: x86: deliver KVM IOAPIC scan request to target vCPUs") Signed-off-by: Nitesh Narayan Lal <nitesh@redhat.com> Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com> [Set level to false since the value doesn't really matter. Suggested by Vitaly Kuznetsov. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-14acpi/x86: ignore unspecified bit positions in the ACPI global lock fieldJan Engelhardt
The value in "new" is constructed from "old" such that all bits defined as reserved by the ACPI spec[1] are left untouched. But if those bits do not happen to be all zero, "new < 3" will not evaluate to true. The firmware of the laptop(s) Medion MD63490 / Akoya P15648 comes with garbage inside the "FACS" ACPI table. The starting value is old=0x4944454d, therefore new=0x4944454e, which is >= 3. Mask off the reserved bits. [1] https://uefi.org/sites/default/files/resources/ACPI_6_2.pdf Link: https://bugzilla.kernel.org/show_bug.cgi?id=206553 Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Jan Engelhardt <jengelh@inai.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-03-14acpi/x86: add a kernel parameter to disable ACPI BGRTAlex Hung
BGRT is for displaying seamless OEM logo from booting to login screen; however, this mechanism does not always work well on all configurations and the OEM logo can be displayed multiple times. This looks worse than without BGRT enabled. This patch adds a kernel parameter to disable BGRT in boot time. This is easier than re-compiling a kernel with CONFIG_ACPI_BGRT disabled. Signed-off-by: Alex Hung <alex.hung@canonical.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-03-14KVM: VMX: Condition ENCLS-exiting enabling on CPU support for SGX1Sean Christopherson
Enable ENCLS-exiting (and thus set vmcs.ENCLS_EXITING_BITMAP) only if the CPU supports SGX1. Per Intel's SDM, all ENCLS leafs #UD if SGX1 is not supported[*], i.e. intercepting ENCLS to inject a #UD is unnecessary. Avoiding ENCLS-exiting even when it is reported as supported by the CPU works around a reported issue where SGX is "hard" disabled after an S3 suspend/resume cycle, i.e. CPUID.0x7.SGX=0 and the VMCS field/control are enumerated as unsupported. While the root cause of the S3 issue is unknown, it's definitely _not_ a KVM (or kernel) bug, i.e. this is a workaround for what is most likely a hardware or firmware issue. As a bonus side effect, KVM saves a VMWRITE when first preparing vmcs01 and vmcs02. Note, SGX must be disabled in BIOS to take advantage of this workaround [*] The additional ENCLS CPUID check on SGX1 exists so that SGX can be globally "soft" disabled post-reset, e.g. if #MC bits in MCi_CTL are cleared. Soft disabled meaning disabling SGX without clearing the primary CPUID bit (in leaf 0x7) and without poking into non-SGX CPU paths, e.g. for the VMCS controls. Fixes: 0b665d304028 ("KVM: vmx: Inject #UD for SGX ENCLS instruction in guest") Reported-by: Toni Spets <toni.spets@iki.fi> Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-14x86/acpi: make "asmlinkage" part first thing in the function definitionAlexey Dobriyan
g++ insists that function declaration must start with extern "C" (which asmlinkage expands to). gcc doesn't care. Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-03-13Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-nextDavid S. Miller
Daniel Borkmann says: ==================== pull-request: bpf-next 2020-03-13 The following pull-request contains BPF updates for your *net-next* tree. We've added 86 non-merge commits during the last 12 day(s) which contain a total of 107 files changed, 5771 insertions(+), 1700 deletions(-). The main changes are: 1) Add modify_return attach type which allows to attach to a function via BPF trampoline and is run after the fentry and before the fexit programs and can pass a return code to the original caller, from KP Singh. 2) Generalize BPF's kallsyms handling and add BPF trampoline and dispatcher objects to be visible in /proc/kallsyms so they can be annotated in stack traces, from Jiri Olsa. 3) Extend BPF sockmap to allow for UDP next to existing TCP support in order in order to enable this for BPF based socket dispatch, from Lorenz Bauer. 4) Introduce a new bpftool 'prog profile' command which attaches to existing BPF programs via fentry and fexit hooks and reads out hardware counters during that period, from Song Liu. Example usage: bpftool prog profile id 337 duration 3 cycles instructions llc_misses 4228 run_cnt 3403698 cycles (84.08%) 3525294 instructions # 1.04 insn per cycle (84.05%) 13 llc_misses # 3.69 LLC misses per million isns (83.50%) 5) Batch of improvements to libbpf, bpftool and BPF selftests. Also addition of a new bpf_link abstraction to keep in particular BPF tracing programs attached even when the applicaion owning them exits, from Andrii Nakryiko. 6) New bpf_get_current_pid_tgid() helper for tracing to perform PID filtering and which returns the PID as seen by the init namespace, from Carlos Neira. 7) Refactor of RISC-V JIT code to move out common pieces and addition of a new RV32G BPF JIT compiler, from Luke Nelson. 8) Add gso_size context member to __sk_buff in order to be able to know whether a given skb is GSO or not, from Willem de Bruijn. 9) Add a new bpf_xdp_output() helper which reuses XDP's existing perf RB output implementation but can be called from tracepoint programs, from Eelco Chaudron. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-13ia64: replace setup_irq() by request_irq()afzal mohammed
request_irq() is preferred over setup_irq(). Invocations of setup_irq() occur after memory allocators are ready. Per tglx[1], setup_irq() existed in olden days when allocators were not ready by the time early interrupts were initialized. Hence replace setup_irq() by request_irq(). Changing 'ia64_native_register_percpu_irq' decleration to include 'irq_handler_t' as an argument type in arch/ia64/include/asm/hw_irq.h was causing build error - 'unknown type name 'irq_handler_t'' This was due to below header file sequence, + include/interrupt.h + include/hardirq.h + asm/hardirq.h + include/irq.h + asm/hw_irq.h [ 'ia64_native_register_percpu_irq' declared w/ 'irq_handler_t'] [ 'irq_handler_t' typedef'ed here in 'include/interrupt.h'] 'register_percpu_irq' defined to 'ia64_native_register_percpu_irq' is the one invoked by the caller, not the latter directly. This was done to support paravirtualization which was removed around 4 years back. And 'register_percpu_irq' is invoked only inside 'arch/ia64/kernel'. So 'register_percpu_irq' define to 'ia64_native_register_percpu_irq' is removed, instead 'ia64_native_register_percpu_irq' is renamed to 'register_precpu_irq()' & it is directly invoked. Also, 'register_precpu_irq()' is declared in a new header file 'irq.h' inside 'arch/ia64/kernel/', this header file is included by C files invoking 'register_percpu_irq()'. [1] https://lkml.kernel.org/r/alpine.DEB.2.20.1710191609480.1971@nanos Signed-off-by: afzal mohammed <afzal.mohd.ma@gmail.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2020-03-13arm: mach-dove: Mark dove_io_desc as __maybe_unusedVincenzo Frascino
Without this, we get the warnings below when CONFIG_MMU is disabled: linux/arch/arm/mach-dove/common.c:51:24: warning: ‘dove_io_desc’ defined but not used [-Wunused-variable] static struct map_desc dove_io_desc[] __initdata = { ^~~~~~~~~~~~ Cc: Jason Cooper <jason@lakedaemon.net> Cc: Andrew Lunn <andrew@lunn.ch> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Cc: Gregory Clement <gregory.clement@bootlin.com> Cc: Russell King <linux@armlinux.org.uk> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2020-03-13ARM: orion: replace setup_irq() by request_irq()afzal mohammed
request_irq() is preferred over setup_irq(). Invocations of setup_irq() occur after memory allocators are ready. Per tglx[1], setup_irq() existed in olden days when allocators were not ready by the time early interrupts were initialized. Hence replace setup_irq() by request_irq(). [1] https://lkml.kernel.org/r/alpine.DEB.2.20.1710191609480.1971@nanos Signed-off-by: afzal mohammed <afzal.mohd.ma@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2020-03-13arm64: dts: marvell: espressobin: add ethernet aliasTomasz Maciej Nowak
The maker of this board and its variants, stores MAC address in U-Boot environment. Add alias for bootloader to recognise, to which ethernet node inject the factory MAC address. Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2020-03-13arm64: dts: mcbin: support 2W SFP modulesRussell King
Allow the SFP cages to be used with 2W SFP modules. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2020-03-13arm64: dts: clearfog-gt-8k: set gigabit PHY reset deassert delayRussell King
If the mv88e6xxx DSA driver is built as a module, it causes the ethernet driver to re-probe when it's loaded. This in turn causes the gigabit PHY to be momentarily reset and reprogrammed. However, we attempt to reprogram the PHY immediately after deasserting reset, and the PHY ignores the writes. This results in the PHY operating in the wrong mode, and the copper link states down. Set a reset deassert delay of 10ms for the gigabit PHY to avoid this. Fixes: babc5544c293 ("arm64: dts: clearfog-gt-8k: 1G eth PHY reset signal") Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Acked-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2020-03-13x86/mm: Rename is_kernel_text to __is_kernel_textJiri Olsa
The kbuild test robot reported compile issue on x86 in one of the following patches that adds <linux/kallsyms.h> include into <linux/bpf.h>, which is picked up by init_32.c object. The problem is that <linux/kallsyms.h> defines global function is_kernel_text which colides with the static function of the same name defined in init_32.c: $ make ARCH=i386 ... >> arch/x86/mm/init_32.c:241:19: error: redefinition of 'is_kernel_text' static inline int is_kernel_text(unsigned long addr) ^~~~~~~~~~~~~~ In file included from include/linux/bpf.h:21:0, from include/linux/bpf-cgroup.h:5, from include/linux/cgroup-defs.h:22, from include/linux/cgroup.h:28, from include/linux/hugetlb.h:9, from arch/x86/mm/init_32.c:18: include/linux/kallsyms.h:31:19: note: previous definition of 'is_kernel_text' was here static inline int is_kernel_text(unsigned long addr) Renaming the init_32.c is_kernel_text function to __is_kernel_text. Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Jiri Olsa <jolsa@kernel.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Song Liu <songliubraving@fb.com> Link: https://lore.kernel.org/bpf/20200312195610.346362-2-jolsa@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2020-03-13Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpfDavid S. Miller
Alexei Starovoitov says: ==================== pull-request: bpf 2020-03-12 The following pull-request contains BPF updates for your *net* tree. We've added 12 non-merge commits during the last 8 day(s) which contain a total of 12 files changed, 161 insertions(+), 15 deletions(-). The main changes are: 1) Andrii fixed two bugs in cgroup-bpf. 2) John fixed sockmap. 3) Luke fixed x32 jit. 4) Martin fixed two issues in struct_ops. 5) Yonghong fixed bpf_send_signal. 6) Yoshiki fixed BTF enum. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-13arm64: kvm: hyp: use cpus_have_final_cap()Mark Rutland
The KVM hyp code is only run after system capabilities have been finalized, and thus all const cap checks have been patched. This is noted in in __cpu_init_hyp_mode(), where we BUG() if called too early: | /* | * Call initialization code, and switch to the full blown HYP code. | * If the cpucaps haven't been finalized yet, something has gone very | * wrong, and hyp will crash and burn when it uses any | * cpus_have_const_cap() wrapper. | */ Given this, the hyp code can use cpus_have_final_cap() and avoid generating code to check the cpu_hwcaps array, which would be unsafe to run in hyp context. This patch migrate the KVM hyp code to cpus_have_final_cap(), avoiding this redundant code generation, and making it possible to detect if we accidentally invoke this code too early. In the latter case, the BUG() in cpus_have_final_cap() will cause a hyp panic. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Reviewed-by: Marc Zyngier <maz@kernel.org> Cc: James Morse <james.morse@arm.com> Cc: Julien Thierry <julien.thierry.kdev@gmail.com> Cc: Suzuki Poulouse <suzuki.poulose@arm.com> Cc: Will Deacon <will@kernel.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2020-03-13arm64: cpufeature: add cpus_have_final_cap()Mark Rutland
When cpus_have_const_cap() was originally introduced it was intended to be safe in hyp context, where it is not safe to access the cpu_hwcaps array as cpus_have_cap() did. For more details see commit: a4023f682739439b ("arm64: Add hypervisor safe helper for checking constant capabilities") We then made use of cpus_have_const_cap() throughout the kernel. Subsequently, we had to defer updating the static_key associated with each capability in order to avoid lockdep complaints. To avoid breaking kernel-wide usage of cpus_have_const_cap(), this was updated to fall back to the cpu_hwcaps array if called before the static_keys were updated. As the kvm hyp code was only called later than this, the fallback is redundant but not functionally harmful. For more details, see commit: 63a1e1c95e60e798 ("arm64/cpufeature: don't use mutex in bringup path") Today we have more users of cpus_have_const_cap() which are only called once the relevant static keys are initialized, and it would be beneficial to avoid the redundant code. To that end, this patch adds a new cpus_have_final_cap(), helper which is intend to be used in code which is only run once capabilities have been finalized, and will never check the cpus_hwcap array. This helps the compiler to generate better code as it no longer needs to generate code to address and test the cpus_hwcap array. To help catch misuse, cpus_have_final_cap() will BUG() if called before capabilities are finalized. In hyp context, BUG() will result in a hyp panic, but the specific BUG() instance will not be identified in the usual way. Comments are added to the various cpus_have_*_cap() helpers to describe the constraints on when they can be used. For clarity cpus_have_cap() is moved above the other helpers. Similarly the helpers are updated to use system_capabilities_finalized() consistently, and this is made __always_inline as required by its new callers. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Reviewed-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: Will Deacon <will@kernel.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2020-03-13ARM: debug: stm32: add UART early console support for STM32MP1Erwan Le Ray
Add support of early console for STM32MP1. Default UART instance is UART4, but other UART instances can be configured by setting physical and virtual base addresses in menuconfig. Signed-off-by: Erwan Le Ray <erwan.leray@st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2020-03-13ARM: debug: stm32: add UART early console support for STM32H7Erwan Le Ray
Add support of early console for STM32H7. Default UART instance is USART1, but other UART instances can be configured by setting physical and virtual base addresses in menuconfig. Signed-off-by: Erwan Le Ray <erwan.leray@st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2020-03-13ARM: debug: stm32: add UART early console configuration for STM32F7Erwan Le Ray
Early console is hardcoded on USART1 in current implementation. With this patch, default UART instance is USART1, but other UART instances can be configured by setting physical and virtual base addresses in menuconfig. Signed-off-by: Erwan Le Ray <erwan.leray@st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2020-03-13ARM: debug: stm32: add UART early console configuration for STM32F4Erwan Le Ray
Early console is hardcoded on USART1 in current implementation. With this patch, default UART instance is USART1, but other UART instances can be configured by setting physical and virtual base addresses in menuconfig. Signed-off-by: Erwan Le Ray <erwan.leray@st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2020-03-13ARM: dts: stm32: use correct vqmmc regu for eMMC on stm32mp1 ED1/EV1 boardsYann Gautier
On those boards, as stated in schematics files, the regulator used for IOs is VDD. It was wrongly set to v3v3. Signed-off-by: Yann Gautier <yann.gautier@st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2020-03-13ARM: dts: stm32: add disable-wp property for SD-card on STM32MP1 boardsYann Gautier
On STM32MP1 DK1, DK2, ED1 and EV1 boards, there is only a micro SD socket. This is also the case on Avenger board. They don't support the Write Protect pin. The disable-wp is then added in the SD-cards sdmmc1 nodes. This avoids executing some code and a warning during driver probe. Signed-off-by: Yann Gautier <yann.gautier@st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2020-03-13ARM: dts: stm32: add cd-gpios properties for SD-cards on STM32MP1 boardsYann Gautier
The broken-cd properties are replaced with cd-gpios, with the correct GPIO to detect the card insertion. The GPIO lines require a pull-up. Signed-off-by: Yann Gautier <yann.gautier@st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2020-03-13ARM: dts: stm32: Do clean up in stmpic nodes on stm32mp15 boardsBenjamin Gaignard
Remove unused properties from stpmic node. The issues have been detected by running dtbs_check. Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2020-03-13ARM: dts: stm32: Rename stmfx joystick pins on stm32mp157c-ev1Benjamin Gaignard
Rename stmfx joystick pins names according to yaml description. Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2020-03-13ARM: dts: stm32: add cpu clock-frequency property on stm32mp15xAhmad Fatoum
All of the STM32MP151[1], STM32MP153[2] and STM32MP157[3] have their Cortex-A7 cores running at 650 MHz. Add the clock-frequency property to CPU nodes to avoid warnings about them missing. [1]: https://www.st.com/en/microcontrollers-microprocessors/stm32mp151.html [2]: https://www.st.com/en/microcontrollers-microprocessors/stm32mp153.html [3]: https://www.st.com/en/microcontrollers-microprocessors/stm32mp157.html Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2020-03-13ARM: dts: stm32: add wakeup-source in all I2C nodes of stm32mp157cAlain Volmat
Add the wakeup-source property in all i2c nodes of the SoC stm32mp157c so that those I2C controllers can become wakeup-source. Signed-off-by: Alain Volmat <alain.volmat@st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2020-03-13ARM: dts: stm32: add i2c4 sleep pinctrl on stm32mp157c-ed1Alain Volmat
Add the sleep state pinctrl entry for the i2c4 node of the stm32mp157c-ed1 board. Signed-off-by: Alain Volmat <alain.volmat@st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2020-03-13ARM: dts: dra7: Add bus_dma_limit for L3 busRoger Quadros
The L3 interconnect's memory map is from 0x0 to 0xffffffff. Out of this, System memory (SDRAM) can be accessed from 0x80000000 to 0xffffffff (2GB) DRA7 does support 4GB of SDRAM but upper 2GB can only be accessed by the MPU subsystem. Add the dma-ranges property to reflect the physical address limit of the L3 bus. Issues ere observed only with SATA on DRA7-EVM with 4GB RAM and CONFIG_ARM_LPAE enabled. This is because the controller supports 64-bit DMA and its driver sets the dma_mask to 64-bit thus resulting in DMA accesses beyond L3 limit of 2G. Setting the correct bus_dma_limit fixes the issue. Signed-off-by: Roger Quadros <rogerq@ti.com> Cc: stable@kernel.org Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-13x86/vector: Remove warning on managed interrupt migrationPeter Xu
The vector management code assumes that managed interrupts cannot be migrated away from an online CPU. free_moved_vector() has a WARN_ON_ONCE() which triggers when a managed interrupt vector association on a online CPU is cleared. The CPU offline code uses a different mechanism which cannot trigger this. This assumption is not longer correct because the new CPU isolation feature which affects the placement of managed interrupts must be able to move a managed interrupt away from an online CPU. There are two reasons why this can happen: 1) When the interrupt is activated the affinity mask which was established in irq_create_affinity_masks() is handed in to the vector allocation code. This mask contains all CPUs to which the interrupt can be made affine to, but this does not take the CPU isolation 'managed_irq' mask into account. When the interrupt is finally requested by the device driver then the affinity is checked again and the CPU isolation 'managed_irq' mask is taken into account, which moves the interrupt to a non-isolated CPU if possible. 2) The interrupt can be affine to an isolated CPU because the non-isolated CPUs in the calculated affinity mask are not online. Once a non-isolated CPU which is in the mask comes online the interrupt is migrated to this non-isolated CPU In both cases the regular online migration mechanism is used which triggers the WARN_ON_ONCE() in free_moved_vector(). Case #1 could have been addressed by taking the isolation mask into account, but that would require a massive code change in the activation logic and the eventual migration event was accepted as a reasonable tradeoff when the isolation feature was developed. But even if #1 would be addressed, #2 would still trigger it. Of course the warning in free_moved_vector() was overlooked at that time and the above two cases which have been discussed during patch review have obviously never been tested before the final submission. So keep it simple and remove the warning. [ tglx: Rewrote changelog and added a comment to free_moved_vector() ] Fixes: 11ea68f553e2 ("genirq, sched/isolation: Isolate from handling managed interrupts") Signed-off-by: Peter Xu <peterx@redhat.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Ming Lei <ming.lei@redhat.com> Link: https://lkml.kernel.org/r/20200312205830.81796-1-peterx@redhat.com
2020-03-13ARM: dts: Add devicetree for Samsung GT-S7710Linus Walleij
The Samsung GT-S7710 also known as XCover 2 or Skomer is a Ux500-based mobile phone. In the source code release from Samsung's open source site it is referred to as "Skomer". Reviewed-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20200307193627.4092-1-linus.walleij@linaro.org [Typographic fixups when applying] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-03-13ARM: dts: stm32: add i2c2/i2c5 sleep pinctrl on stm32mp157c-ev1Alain Volmat
Add the sleep state pinctrl entry for the i2c2 and i2c5 nodes of the stm32mp157c-ev1 board. Signed-off-by: Alain Volmat <alain.volmat@st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2020-03-13ARM: dts: stm32: add i2c4 sleep pinctrl on stm32mp15xx-dkxAlain Volmat
Add the sleep state pinctrl entry for the i2c4 node of the stm32mp15xx-dkx.dtsi Signed-off-by: Alain Volmat <alain.volmat@st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2020-03-13ARM: dts: stm32: set i2c4 bus freq to 400KHz on stm32mp15 DK boardsAlain Volmat
On DK boards, all I2C4 bus slaves supports I2C Fast Mode hence setting the bus frequency to 400 KHz. Signed-off-by: Alain Volmat <alain.volmat@st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2020-03-13ARM: dts: stm32: set i2c4 bus freq to 400KHz on stm32mp157c-ed1Alain Volmat
On this board, the I2C4 bus has only a single slave (pmic) which supports I2C Fast Mode hence setting bus frequency to 400 KHz. Signed-off-by: Alain Volmat <alain.volmat@st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
2020-03-13cpuidle: tegra: Squash Tegra114 driver into the common driverDmitry Osipenko
Tegra20/30/114/124 SoCs have common idling states, thus there is no much point in having separate drivers for a similar hardware. This patch moves Tegra114/124 arch/ drivers into the common driver without any functional changes. The CC6 state is kept disabled on Tegra114/124 because the core Tegra PM code needs some more work in order to support that state. Acked-by: Peter De Schrijver <pdeschrijver@nvidia.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-03-13cpuidle: tegra: Squash Tegra30 driver into the common driverDmitry Osipenko
Tegra20 and Terga30 SoCs have common C1 and CC6 idling states and thus share the same code paths, there is no point in having separate drivers for a similar hardware. This patch merely moves functionality of the old driver into the new, although the CC6 state is kept disabled for now since old driver had a rudimentary support for this state (allowing to enter into CC6 only when secondary CPUs are put offline), while new driver can provide a full-featured support. The new feature will be enabled by another patch. Acked-by: Peter De Schrijver <pdeschrijver@nvidia.com> Tested-by: Peter Geis <pgwipeout@gmail.com> Tested-by: Jasper Korten <jja2000@gmail.com> Tested-by: David Heidelberg <david@ixit.cz> Tested-by: Nicolas Chauvet <kwizart@gmail.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-03-13cpuidle: Refactor and move out NVIDIA Tegra20 driver into drivers/cpuidleDmitry Osipenko
The driver's code is refactored in a way that will make it easy to support Tegra30/114/124 SoCs by this unified driver later on. The current functionality is equal to the old Tegra20 driver, only the code's structure changed a tad. This is also a proper platform driver now. Acked-by: Peter De Schrijver <pdeschrijver@nvidia.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-03-13ARM: tegra: Update sound node clocks in device treeSowjanya Komatineni
clk_out_1, clk_out_2, and clk_out_3 are part of Tegra PMC block but were previously erroneously provided by the clock and reset controller. clk_out_1 is dedicated for audio mclk on Tegra30 through Tegra210. This patch updates device tree sound node to use clk_out_1 from the PMC provider as mclk and uses assigned-clock properties to specify clock parents for clk_out_1 and extern1. Tested-by: Dmitry Osipenko <digetx@gmail.com> Reviewed-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-03-13ARM: tegra: Add clock-cells property to PMCSowjanya Komatineni
Tegra PMC has clk_out_1, clk_out_2, clk_out_3, and blink clock. These clocks were erroneously provided by the clock and reset controller and are now provided by the PMC instead because that's where the primary controls are. This patch adds #clock-cells property with 1 clock specifier to the Tegra PMC node in device tree. Tested-by: Dmitry Osipenko <digetx@gmail.com> Reviewed-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-03-13ARM: tegra: Remove USB 2-0 port from Jetson TK1 padctlNagarjuna Kristam
On Jetson TK1 USB 2-0 port is controlled by phy-tegra-usb driver rather than padctl driver. Remove the entry for the same. Signed-off-by: Nagarjuna Kristam <nkristam@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-03-13ARM: tegra: cpuidle: Remove unnecessary memory barrierDmitry Osipenko
There is no good justification for smp_rmb() after returning from LP2 because there are no memory operations that require SMP synchronization. Thus remove the confusing barrier. Acked-by: Peter De Schrijver <pdeschrijver@nvidia.com> Tested-by: Peter Geis <pgwipeout@gmail.com> Tested-by: Jasper Korten <jja2000@gmail.com> Tested-by: David Heidelberg <david@ixit.cz> Tested-by: Nicolas Chauvet <kwizart@gmail.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-03-13ARM: tegra: cpuidle: Make abort_flag atomicDmitry Osipenko
Replace memory accessors with atomic API just to make code consistent with the abort_barrier. The new variant may be even more correct now since atomic_read() will prevent compiler from generating wrong things like carrying abort_flag value in a register instead of re-fetching it from memory. Acked-by: Peter De Schrijver <pdeschrijver@nvidia.com> Tested-by: Peter Geis <pgwipeout@gmail.com> Tested-by: Jasper Korten <jja2000@gmail.com> Tested-by: David Heidelberg <david@ixit.cz> Tested-by: Nicolas Chauvet <kwizart@gmail.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-03-13ARM: tegra: cpuidle: Handle case where secondary CPU hangs on entering LP2Dmitry Osipenko
It is possible that something may go wrong with the secondary CPU, in that case it is much nicer to get a dump of the flow-controller state before hanging machine. Acked-by: Peter De Schrijver <pdeschrijver@nvidia.com> Tested-by: Peter Geis <pgwipeout@gmail.com> Tested-by: Jasper Korten <jja2000@gmail.com> Tested-by: David Heidelberg <david@ixit.cz> Tested-by: Nicolas Chauvet <kwizart@gmail.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-03-13ARM: tegra: Make outer_disable() open-codedDmitry Osipenko
The outer_disable() of Tegra's suspend code is open-coded now since that helper produces spurious warning message about secondary CPUs being online when CPU enters into LP2 from cpuidle. The secondaries are actually halted by the cpuidle driver on entering into LP2 idle-state, but the online status is not touched by the cpuidle. This fixes a storm of warnings once LP2 idling state is enabled on Tegra30. The outer_disable() helper has sanity checks for interrupts and secondary CPUs being disabled and we are pretty confident about the interrupts state during of CPU idling / system suspend. The rail-off status check is added in this patch as equivalent for the "num_online_cpus() > 1". Acked-by: Peter De Schrijver <pdeschrijver@nvidia.com> Tested-by: Peter Geis <pgwipeout@gmail.com> Tested-by: Jasper Korten <jja2000@gmail.com> Tested-by: David Heidelberg <david@ixit.cz> Tested-by: Nicolas Chauvet <kwizart@gmail.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>