summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2022-12-04ARM: mmp: fix timer_read delayDoug Brown
timer_read() was using an empty 100-iteration loop to wait for the TMR_CVWR register to capture the latest timer counter value. The delay wasn't long enough. This resulted in CPU idle time being extremely underreported on PXA168 with CONFIG_NO_HZ_IDLE=y. Switch to the approach used in the vendor kernel, which implements the capture delay by reading TMR_CVWR a few times instead. Fixes: 49cbe78637eb ("[ARM] pxa: add base support for Marvell's PXA168 processor line") Signed-off-by: Doug Brown <doug@schmorgal.com> Link: https://lore.kernel.org/r/20221204005117.53452-3-doug@schmorgal.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-12-04ARM: dts: pxa168: add timer reset and clockDoug Brown
The timer was missing the clock and reset like the other peripherals. Add them to allow the timer to continue working after boot completes. Signed-off-by: Doug Brown <doug@schmorgal.com> Link: https://lore.kernel.org/r/20221204005117.53452-2-doug@schmorgal.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-12-04Merge tag 'dt-cleanup-6.2-2' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-dt into soc/dt Minor improvements in ARM DTS for v6.2, part two Few cleanups which should not have any functional impact: 1. Trim addresses in "reg" to 8 digits. 2. Align LED node names with dtschema. 3. omap: echo: Use preferred enable-gpios property for LP5523 LED. * tag 'dt-cleanup-6.2-2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-dt: ARM: dts: sti: align LED node names with dtschema ARM: dts: am335x: align LED node names with dtschema ARM: dts: omap: echo: use preferred enable-gpios for LP5523 LED ARM: dts: omap: align LED node names with dtschema ARM: dts: logicpd: align LED node names with dtschema ARM: dts: lpc32xx: trim addresses to 8 digits ARM: dts: imx: trim addresses to 8 digits ARM: dts: omap: trim addresses to 8 digits Link: https://lore.kernel.org/r/20221204082909.5649-1-krzysztof.kozlowski@linaro.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-12-04Merge tag 'asahi-soc-dt-6.2-v2' of https://github.com/AsahiLinux/linux into ↵Arnd Bergmann
soc/dt Apple SoC DT updates for 6.2 (v2). This includes: * L1/L2 cache topology for t600x * CPUfreq nodes for t8103/t600x * DT binding for CPUfreq * Associated MAINTAINERS update The CPUfreq driver was already merged for 6.2 via its tree. * tag 'asahi-soc-dt-6.2-v2' of https://github.com/AsahiLinux/linux: arm64: dts: apple: Add CPU topology & cpufreq nodes for t600x arm64: dts: apple: Add CPU topology & cpufreq nodes for t8103 dt-bindings: cpufreq: apple,soc-cpufreq: Add binding for Apple SoC cpufreq MAINTAINERS: Add entries for Apple SoC cpufreq driver arm64: dts: apple: Add t600x L1/L2 cache properties and nodes Link: https://lore.kernel.org/r/a9353121-7fed-fde7-6f40-939a65bfeefb@marcan.st Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-12-04arm64: dts: apple: Add CPU topology & cpufreq nodes for t600xHector Martin
Add the missing CPU topology/capacity information and the cpufreq nodes, so we can have CPU frequency scaling and the scheduler has the information it needs to make the correct decisions. As with t8103, boost states are commented out pending PSCI/etc support for deep sleep states. Reviewed-by: Sven Peter <sven@svenpeter.dev> Signed-off-by: Hector Martin <marcan@marcan.st>
2022-12-03x86/microcode/intel: Do not print microcode revision and processor flagsAshok Raj
collect_cpu_info() is used to collect the current microcode revision and processor flags on every CPU. It had a weird mechanism to try to mimick a "once" functionality in the sense that, that information should be issued only when it is differing from the previous CPU. However (1): the new calling sequence started doing that in parallel: microcode_init() |-> schedule_on_each_cpu(setup_online_cpu) |-> collect_cpu_info() resulting in multiple redundant prints: microcode: sig=0x50654, pf=0x80, revision=0x2006e05 microcode: sig=0x50654, pf=0x80, revision=0x2006e05 microcode: sig=0x50654, pf=0x80, revision=0x2006e05 However (2): dumping this here is not that important because the kernel does not support mixed silicon steppings microcode. Finally! Besides, there is already a pr_info() in microcode_reload_late() that shows both the old and new revisions. What is more, the CPU signature (sig=0x50654) and Processor Flags (pf=0x80) above aren't that useful to the end user, they are available via /proc/cpuinfo and they don't change anyway. Remove the redundant pr_info(). [ bp: Heavily massage. ] Fixes: b6f86689d5b7 ("x86/microcode: Rip out the subsys interface gunk") Reported-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20221103175901.164783-2-ashok.raj@intel.com
2022-12-02Merge patch series "Support VMCOREINFO export for RISCV64"Palmer Dabbelt
Add arch_crash_save_vmcoreinfo(), which exports VM layout(MODULES, VMALLOC, VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram base for vmcore. * b4-shazam-merge: Documentation: kdump: describe VMCOREINFO export for RISCV64 RISC-V: Add arch_crash_save_vmcoreinfo support Link: https://lore.kernel.org/r/20221026144208.373504-1-xianting.tian@linux.alibaba.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-12-02RISC-V: Add arch_crash_save_vmcoreinfo supportXianting Tian
Add arch_crash_save_vmcoreinfo(), which exports VM layout(MODULES, VMALLOC, VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram base for vmcore. Default pagetable levels and PAGE_OFFSET aren't same for different kernel version as below. For pagetable levels, it sets sv57 by default and falls back to setting sv48 at boot time if sv57 is not supported by the hardware. For ram base, the default value is 0x80200000 for qemu riscv64 env and, for example, is 0x200000 on the XuanTie 910 CPU. * Linux Kernel 5.18 ~ * PGTABLE_LEVELS = 5 * PAGE_OFFSET = 0xff60000000000000 * Linux Kernel 5.17 ~ * PGTABLE_LEVELS = 4 * PAGE_OFFSET = 0xffffaf8000000000 * Linux Kernel 4.19 ~ * PGTABLE_LEVELS = 3 * PAGE_OFFSET = 0xffffffe000000000 Since these configurations change from time to time and version to version, it is preferable to export them via vmcoreinfo than to change the crash's code frequently, it can simplify the development of crash tool. Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com> Tested-by: Deepak Gupta <debug@rivosinc.com> Tested-by: Guo Ren <guoren@kernel.org> Acked-by: Baoquan He <bhe@redhat.com> Link: https://lore.kernel.org/r/20221026144208.373504-2-xianting.tian@linux.alibaba.com [Palmer: wrap commit text] Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-12-02Merge tag 'riscv-for-linus-6.1-rc8' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull RISC-V fixes from Palmer Dabbelt: - build fix for the NR_CPUS Kconfig SBI version dependency - fixes to early memory initialization, to fix page permissions in EFI and post-initmem-free - build fix for the VDSO, to avoid trying to profile the VDSO functions - fixes for kexec crash handling, to fix multi-core and interrupt related initialization inside the crash kernel - fix for a race condition when handling multiple concurrect kernel stack overflows * tag 'riscv-for-linus-6.1-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: riscv: kexec: Fixup crash_smp_send_stop without multi cores riscv: kexec: Fixup irq controller broken in kexec crash path riscv: mm: Proper page permissions after initmem free riscv: vdso: fix section overlapping under some conditions riscv: fix race when vmap stack overflow riscv: Sync efi page table's kernel mappings before switching riscv: Fix NR_CPUS range conditions
2022-12-02x86/bugs: Make sure MSR_SPEC_CTRL is updated properly upon resume from S3Pawan Gupta
The "force" argument to write_spec_ctrl_current() is currently ambiguous as it does not guarantee the MSR write. This is due to the optimization that writes to the MSR happen only when the new value differs from the cached value. This is fine in most cases, but breaks for S3 resume when the cached MSR value gets out of sync with the hardware MSR value due to S3 resetting it. When x86_spec_ctrl_current is same as x86_spec_ctrl_base, the MSR write is skipped. Which results in SPEC_CTRL mitigations not getting restored. Move the MSR write from write_spec_ctrl_current() to a new function that unconditionally writes to the MSR. Update the callers accordingly and rename functions. [ bp: Rework a bit. ] Fixes: caa0ff24d5d0 ("x86/bugs: Keep a per-CPU IA32_SPEC_CTRL value") Suggested-by: Borislav Petkov <bp@alien8.de> Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Cc: <stable@kernel.org> Link: https://lore.kernel.org/r/806d39b0bfec2fe8f50dc5446dff20f5bb24a959.1669821572.git.pawan.kumar.gupta@linux.intel.com Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-12-02Merge tag 'mm-hotfixes-stable-2022-12-02' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull misc hotfixes from Andrew Morton: "15 hotfixes, 11 marked cc:stable. Only three or four of the latter address post-6.0 issues, which is hopefully a sign that things are converging" * tag 'mm-hotfixes-stable-2022-12-02' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: revert "kbuild: fix -Wimplicit-function-declaration in license_is_gpl_compatible" Kconfig.debug: provide a little extra FRAME_WARN leeway when KASAN is enabled drm/amdgpu: temporarily disable broken Clang builds due to blown stack-frame mm/khugepaged: invoke MMU notifiers in shmem/file collapse paths mm/khugepaged: fix GUP-fast interaction by sending IPI mm/khugepaged: take the right locks for page table retraction mm: migrate: fix THP's mapcount on isolation mm: introduce arch_has_hw_nonleaf_pmd_young() mm: add dummy pmd_young() for architectures not having it mm/damon/sysfs: fix wrong empty schemes assumption under online tuning in damon_sysfs_set_schemes() tools/vm/slabinfo-gnuplot: use "grep -E" instead of "egrep" nilfs2: fix NULL pointer dereference in nilfs_palloc_commit_free_entry() hugetlb: don't delete vma_lock in hugetlb MADV_DONTNEED processing madvise: use zap_page_range_single for madvise dontneed mm: replace VM_WARN_ON to pr_warn if the node is offline with __GFP_THISNODE
2022-12-02um: virt-pci: Avoid GCC non-NULL warningKees Cook
GCC gets confused about the return value of get_cpu_var() possibly being NULL, so explicitly test for it before calls to memcpy() and memset(). Avoids warnings like this: arch/um/drivers/virt-pci.c: In function 'um_pci_send_cmd': include/linux/fortify-string.h:48:33: warning: argument 1 null where non-null expected [-Wnonnull] 48 | #define __underlying_memcpy __builtin_memcpy | ^ include/linux/fortify-string.h:438:9: note: in expansion of macro '__underlying_memcpy' 438 | __underlying_##op(p, q, __fortify_size); \ | ^~~~~~~~~~~~~ include/linux/fortify-string.h:483:26: note: in expansion of macro '__fortify_memcpy_chk' 483 | #define memcpy(p, q, s) __fortify_memcpy_chk(p, q, s, \ | ^~~~~~~~~~~~~~~~~~~~ arch/um/drivers/virt-pci.c:100:9: note: in expansion of macro 'memcpy' 100 | memcpy(buf, cmd, cmd_size); | ^~~~~~ While at it, avoid literal "8" and use stored sizeof(buf->data) in memset() and um_pci_send_cmd(). Reported-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/lkml/202211271212.SUZSC9f9-lkp@intel.com Fixes: ba38961a069b ("um: Enable FORTIFY_SOURCE") Cc: Richard Weinberger <richard@nod.at> Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com> Cc: Johannes Berg <johannes@sipsolutions.net> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Xiu Jianfeng <xiujianfeng@huawei.com> Cc: Vincent Whitchurch <vincent.whitchurch@axis.com> Cc: linux-um@lists.infradead.org Cc: stable@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org>
2022-12-02riscv: add riscv rethook implementationBinglei Wang
Implement the kretprobes on riscv arch by using rethook machenism which abstracts general kretprobe info into a struct rethook_node to be embedded in the struct kretprobe_instance. Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by: Binglei Wang <l3b2w1@gmail.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20221025151831.1097417-1-conor@kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-12-02riscv/mm: add arch hook arch_clear_hugepage_flagsTong Tiangen
With the PG_arch_1 we keep track if the page's data cache is clean, architecture rely on this property to treat new pages as dirty with respect to the data cache and perform the flushing before mapping the pages into userspace. This patch adds a new architecture hook, arch_clear_hugepage_flags,so that architectures which rely on the page flags being in a particular state for fresh allocations can adjust the flags accordingly when a page is freed into the pool. Fixes: 9e953cda5cdf ("riscv: Introduce huge page support for 32/64bit kernel") Signed-off-by: Tong Tiangen <tongtiangen@huawei.com> Link: https://lore.kernel.org/r/20221024094725.3054311-3-tongtiangen@huawei.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-12-02riscv/mm: hugepage's PG_dcache_clean flag is only set in head pageTong Tiangen
HugeTLB pages are always fully mapped, so only setting head page's PG_dcache_clean flag is enough. Signed-off-by: Tong Tiangen <tongtiangen@huawei.com> Link: https://lore.kernel.org/lkml/20220331065640.5777-2-songmuchun@bytedance.com/ Link: https://lore.kernel.org/r/20221024094725.3054311-2-tongtiangen@huawei.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-12-02Merge branch 'gpc-fixes' of git://git.infradead.org/users/dwmw2/linux into HEADPaolo Bonzini
Pull Xen-for-KVM changes from David Woodhouse: * add support for 32-bit guests in SCHEDOP_poll * the rest of the gfn-to-pfn cache API cleanup "I still haven't reinstated the last of those patches to make gpc->len immutable." Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-12-02KVM: x86: Advertise that the SMM_CTL MSR is not supportedJim Mattson
CPUID.80000021H:EAX[bit 9] indicates that the SMM_CTL MSR (0xc0010116) is not supported. This defeature can be advertised by KVM_GET_SUPPORTED_CPUID regardless of whether or not the host enumerates it; currently it will be included only if the host enumerates at least leaf 8000001DH, due to a preexisting bug in QEMU that KVM has to work around (commit f751d8eac176, "KVM: x86: work around QEMU issue with synthetic CPUID leaves", 2022-04-29). Signed-off-by: Jim Mattson <jmattson@google.com> Message-Id: <20221007221644.138355-1-jmattson@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-12-02KVM: x86: remove unnecessary exportsPaolo Bonzini
Several symbols are not used by vendor modules but still exported. Removing them ensures that new coupling between kvm.ko and kvm-*.ko is noticed and reviewed. Co-developed-by: Sean Christopherson <seanjc@google.com> Co-developed-by: Like Xu <like.xu.linux@gmail.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Like Xu <like.xu.linux@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-12-02RISC-V: defconfig: Enable CONFIG_SERIAL_8250_DWHal Feng
Add CONFIG_SERIAL_8250_DW=y, which is a necessary option for StarFive JH7110 and JH7100 SoCs to boot with serial ports. Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Hal Feng <hal.feng@starfivetech.com> Acked-by: Palmer Dabbelt <palmer@rivosinc.com> Link: https://lore.kernel.org/r/20221118011714.70877-9-hal.feng@starfivetech.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-12-02KVM: x86: fix APICv/x2AVIC disabled when vm reboot by itselfYuan ZhaoXiong
When a VM reboots itself, the reset process will result in an ioctl(KVM_SET_LAPIC, ...) to disable x2APIC mode and set the xAPIC id of the vCPU to its default value, which is the vCPU id. That will be handled in KVM as follows: kvm_vcpu_ioctl_set_lapic kvm_apic_set_state kvm_lapic_set_base => disable X2APIC mode kvm_apic_state_fixup kvm_lapic_xapic_id_updated kvm_xapic_id(apic) != apic->vcpu->vcpu_id kvm_set_apicv_inhibit(APICV_INHIBIT_REASON_APIC_ID_MODIFIED) memcpy(vcpu->arch.apic->regs, s->regs, sizeof(*s)) => update APIC_ID When kvm_apic_set_state invokes kvm_lapic_set_base to disable x2APIC mode, the old 32-bit x2APIC id is still present rather than the 8-bit xAPIC id. kvm_lapic_xapic_id_updated will set the APICV_INHIBIT_REASON_APIC_ID_MODIFIED bit and disable APICv/x2AVIC. Instead, kvm_lapic_xapic_id_updated must be called after APIC_ID is changed. In fact, this fixes another small issue in the code in that potential changes to a vCPU's xAPIC ID need not be tracked for KVM_GET_LAPIC. Fixes: 3743c2f02517 ("KVM: x86: inhibit APICv/AVIC on changes to APIC ID or APIC base") Signed-off-by: Yuan ZhaoXiong <yuanzhaoxiong@baidu.com> Message-Id: <1669984574-32692-1-git-send-email-yuanzhaoxiong@baidu.com> Cc: stable@vger.kernel.org Reported-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-12-02Merge patch series "RISC-V: Dynamic ftrace support for RV32I"Palmer Dabbelt
Jamie Iles <jamie@jamieiles.com> says: This series enables dynamic ftrace support for RV32I bringing it to parity with RV64I. Most of the work is already there, this is largely just assembly fixes to handle register sizes, correct handling of the psABI calling convention and Kconfig change. Validated with all ftrace boot time self test with qemu for RV32I and RV64I in addition to real tracing on an RV32I FPGA design. * b4-shazam-merge: RISC-V: enable dynamic ftrace for RV32I RISC-V: preserve a1 in mcount RISC-V: reduce mcount save space on RV32 RISC-V: use REG_S/REG_L for mcount Link: https://lore.kernel.org/r/20221115200832.706370-1-jamie@jamieiles.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-12-02RISC-V: enable dynamic ftrace for RV32IJamie Iles
The RISC-V mcount function is now capable of supporting RV32I so make it available in the kernel config. Signed-off-by: Jamie Iles <jamie@jamieiles.com> Link: https://lore.kernel.org/r/20221115200832.706370-5-jamie@jamieiles.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-12-02RISC-V: preserve a1 in mcountJamie Iles
The RISC-V ELF psABI states that both a0 and a1 are used for return values so we should preserve them both in return_to_handler. This is especially important for RV32 for functions returning a 64-bit quantity otherwise the return value can be corrupted and undefined behaviour results. Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Jamie Iles <jamie@jamieiles.com> Link: https://lore.kernel.org/r/20221115200832.706370-4-jamie@jamieiles.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-12-02RISC-V: reduce mcount save space on RV32Jamie Iles
For RV32 we can reduce the size of the ABI save+restore state by using SZREG so that register stores are packed rather than on an 8 byte boundary. Signed-off-by: Jamie Iles <jamie@jamieiles.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Link: https://lore.kernel.org/r/20221115200832.706370-3-jamie@jamieiles.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-12-02RISC-V: use REG_S/REG_L for mcountJamie Iles
In preparation for rv32i ftrace support, convert mcount routines to use native sized loads/stores. Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Jamie Iles <jamie@jamieiles.com> Link: https://lore.kernel.org/r/20221115200832.706370-2-jamie@jamieiles.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-12-02Merge tag 'kvm-x86-fixes-6.2-1' of https://github.com/kvm-x86/linux into HEADPaolo Bonzini
Misc KVM x86 fixes and cleanups for 6.2: - One-off fixes for various emulation flows (SGX, VMXON, NRIPS=0). - Reinstate IBPB on emulated VM-Exit that was incorrectly dropped a few years back when eliminating unnecessary barriers when switching between vmcs01 and vmcs02. - Clean up the MSR filter docs. - Clean up vmread_error_trampoline() to make it more obvious that params must be passed on the stack, even for x86-64. - Let userspace set all supported bits in MSR_IA32_FEAT_CTL irrespective of the current guest CPUID. - Fudge around a race with TSC refinement that results in KVM incorrectly thinking a guest needs TSC scaling when running on a CPU with a constant TSC, but no hardware-enumerated TSC frequency.
2022-12-02KVM: Delete all references to removed KVM_SET_MEMORY_ALIAS ioctlJavier Martinez Canillas
The documentation says that the ioctl has been deprecated, but it has been actually removed and the remaining references are just left overs. Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Message-Id: <20221202105011.185147-3-javierm@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-12-02s390/checksum: support GENERIC_CSUM, enable it for KASANHeiko Carstens
This is the s390 variant of commit d911c67e10b4 ("x86: kasan: kmsan: support CONFIG_GENERIC_CSUM on x86, enable it for KASAN/KMSAN"). Even though most of the s390 specific checksum code is written in C there is still the csum_partial() inline assembly which could prevent KASAN and KMSAN from seeing all memory accesses. Therefore switch to GENERIC_CSUM if KASAN is enabled just like x86. Reviewed-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2022-12-02s390/appldata: remove power management callbacksHeiko Carstens
Support for power managemant has been removed from s390 since quite some time. Therefore remove unused power managemant code from the appldata device driver. Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2022-12-02arm64: dts: qcom: sc8280xp: fix UFS reference clocksJohan Hovold
There are three UFS reference clocks on SC8280XP which are used as follows: - The GCC_UFS_REF_CLKREF_CLK clock is fed to any UFS device connected to either controller. - The GCC_UFS_1_CARD_CLKREF_CLK and GCC_UFS_CARD_CLKREF_CLK clocks provide reference clocks to the two PHYs. Note that this depends on first updating the clock driver to reflect that all three clocks are sourced from CXO. Specifically, the UFS controller driver expects the device reference clock to have a valid frequency: ufshcd-qcom 1d84000.ufs: invalid ref_clk setting = 0 Fixes: 152d1faf1e2f ("arm64: dts: qcom: add SC8280XP platform") Fixes: 8d6b458ce6e9 ("arm64: dts: qcom: sc8280xp: fix ufs_card_phy ref clock") Fixes: f3aa975e230e ("arm64: dts: qcom: sc8280xp: correct ref clock for ufs_mem_phy") Link: https://lore.kernel.org/lkml/Y2OEjNAPXg5BfOxH@hovoldconsulting.com/ Cc: stable@vger.kernel.org # 5.20 Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Brian Masney <bmasney@redhat.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221104092045.17410-2-johan+linaro@kernel.org
2022-12-02arm64: dts: qcom: sc8280xp: fix PCIe DMA coherencyJohan Hovold
The devices on the SC8280XP PCIe buses are cache coherent and must be marked as such to avoid data corruption. A coherent device can, for example, end up snooping stale data from the caches instead of using data written by the CPU through the non-cacheable mapping which is used for consistent DMA buffers for non-coherent devices. Note that this is much more likely to happen since commit c44094eee32f ("arm64: dma: Drop cache invalidation from arch_dma_prep_coherent()") that was added in 6.1 and which removed the cache invalidation when setting up the non-cacheable mapping. Marking the PCIe devices as coherent specifically fixes the intermittent NVMe probe failures observed on the Thinkpad X13s, which was due to corruption of the submission and completion queues. This was typically observed as corruption of the admin submission queue (with well-formed completion): could not locate request for tag 0x0 nvme nvme0: invalid id 0 completed on queue 0 or corruption of the admin or I/O completion queues (malformed completion): could not locate request for tag 0x45f nvme nvme0: invalid id 25695 completed on queue 25965 presumably as these queues are small enough to not be allocated using CMA which in turn make them more likely to be cached (e.g. due to accesses to nearby pages through the cacheable linear map). Increasing the buffer sizes to two pages to force CMA allocation also appears to make the problem go away. Fixes: 813e83157001 ("arm64: dts: qcom: sc8280xp/sa8540p: add PCIe2-4 nodes") Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221124142501.29314-1-johan+linaro@kernel.org
2022-12-02Merge branch 'arm64-fixes-for-6.1' into HEADBjorn Andersson
Mergeback arm64-fixes-for-6.1 to avoid merge conflicts.
2022-12-02mips/pci: use devm_platform_ioremap_resource()zhang songyi
Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by: zhang songyi <zhang.songyi@zte.com.cn> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2022-12-02x86/sgx: Replace kmap/kunmap_atomic() callsKristen Carlson Accardi
kmap_local_page() is the preferred way to create temporary mappings when it is feasible, because the mappings are thread-local and CPU-local. kmap_local_page() uses per-task maps rather than per-CPU maps. This in effect removes the need to disable preemption on the local CPU while the mapping is active, and thus vastly reduces overall system latency. It is also valid to take pagefaults within the mapped region. The use of kmap_atomic() in the SGX code was not an explicit design choice to disable page faults or preemption, and there is no compelling design reason to using kmap_atomic() vs. kmap_local_page(). Signed-off-by: Kristen Carlson Accardi <kristen@linux.intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Reviewed-by: Fabio M. De Francesco <fmdefrancesco@gmail.com> Reviewed-by: Ira Weiny <ira.weiny@intel.com> Link: https://lore.kernel.org/linux-sgx/Y0biN3%2FJsZMa0yUr@kernel.org/ Link: https://lore.kernel.org/r/20221115161627.4169428-1-kristen@linux.intel.com
2022-12-02x86/of: Add support for boot time interrupt delivery mode configurationRahul Tanwar
Presently, init/boot time interrupt delivery mode is enumerated only for ACPI enabled systems by parsing MADT table or for older systems by parsing MP table. But for OF based x86 systems, it is assumed & hardcoded to be legacy PIC mode. This causes a boot time crash for platforms which do not provide a 8259 compliant legacy PIC. Add support for configuration of init time interrupt delivery mode for x86 OF based systems by introducing a new optional boolean property 'intel,virtual-wire-mode' for the local APIC interrupt-controller node. This property emulates IMCRP Bit 7 of MP feature info byte 2 of MP floating pointer structure. Defaults to legacy PIC mode if absent. Configures it to virtual wire compatibility mode if present. Signed-off-by: Rahul Tanwar <rtanwar@maxlinear.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20221124084143.21841-5-rtanwar@maxlinear.com
2022-12-02x86/of: Replace printk(KERN_LVL) with pr_lvl()Rahul Tanwar
Use pr_lvl() instead of the deprecated printk(KERN_LVL). Just a upgrade of print utilities usage. no functional changes. Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rahul Tanwar <rtanwar@maxlinear.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20221124084143.21841-4-rtanwar@maxlinear.com
2022-12-02x86/of: Remove unused early_init_dt_add_memory_arch()Andy Shevchenko
Recently objtool started complaining about dead code in the object files, in particular vmlinux.o: warning: objtool: early_init_dt_scan_memory+0x191: unreachable instruction when CONFIG_OF=y. Indeed, early_init_dt_scan() is not used on x86 and making it compile (with help of CONFIG_OF) will abrupt the code flow since in the middle of it there is a BUG() instruction. Remove the pointless function. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20221124184824.9548-1-andriy.shevchenko@linux.intel.com
2022-12-02x86/apic: Handle no CONFIG_X86_X2APIC on systems with x2APIC enabled by BIOSMateusz Jończyk
A kernel that was compiled without CONFIG_X86_X2APIC was unable to boot on platforms that have x2APIC already enabled in the BIOS before starting the kernel. The kernel was supposed to panic with an approprite error message in validate_x2apic() due to the missing X2APIC support. However, validate_x2apic() was run too late in the boot cycle, and the kernel tried to initialize the APIC nonetheless. This resulted in an earlier panic in setup_local_APIC() because the APIC was not registered. In my experiments, a panic message in setup_local_APIC() was not visible in the graphical console, which resulted in a hang with no indication what has gone wrong. Instead of calling panic(), disable the APIC, which results in a somewhat working system with the PIC only (and no SMP). This way the user is able to diagnose the problem more easily. Disabling X2APIC mode is not an option because it's impossible on systems with locked x2APIC. The proper place to disable the APIC in this case is in check_x2apic(), which is called early from setup_arch(). Doing this in __apic_intr_mode_select() is too late. Make check_x2apic() unconditionally available and remove the empty stub. Reported-by: Paul Menzel <pmenzel@molgen.mpg.de> Reported-by: Robert Elliott (Servers) <elliott@hpe.com> Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/lkml/d573ba1c-0dc4-3016-712a-cc23a8a33d42@molgen.mpg.de Link: https://lore.kernel.org/lkml/20220911084711.13694-3-mat.jonczyk@o2.pl Link: https://lore.kernel.org/all/20221129215008.7247-1-mat.jonczyk@o2.pl
2022-12-02x86/asm/32: Remove setup_once()Brian Gerst
After the removal of the stack canary segment setup code, this function does nothing. Signed-off-by: Brian Gerst <brgerst@gmail.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20221115184328.70874-1-brgerst@gmail.com
2022-12-02x86/alternative: Remove noinline from __ibt_endbr_seal[_end]() stubsMiaohe Lin
Due to the explicit 'noinline' GCC-7.3 is not able to optimize away the argument setup of: apply_ibt_endbr(__ibt_endbr_seal, __ibt_enbr_seal_end); even when X86_KERNEL_IBT=n and the function is an empty stub, which leads to link errors due to missing __ibt_endbr_seal* symbols: ld: arch/x86/kernel/alternative.o: in function `alternative_instructions': alternative.c:(.init.text+0x15d): undefined reference to `__ibt_endbr_seal_end' ld: alternative.c:(.init.text+0x164): undefined reference to `__ibt_endbr_seal' Remove the explicit 'noinline' to help gcc optimize them away. Signed-off-by: Miaohe Lin <linmiaohe@huawei.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20221011113803.956808-1-linmiaohe@huawei.com
2022-12-02powerpc/code-patching: Remove protection against patching init addresses ↵Christophe Leroy
after init Once init section is freed, attempting to patch init code ends up in the weed. Commit 51c3c62b58b3 ("powerpc: Avoid code patching freed init sections") protected patch_instruction() against that, but it is the responsibility of the caller to ensure that the patched memory is valid. All callers have now been verified and fixed so the check can be removed. This improves ftrace activation by about 2% on 8xx. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/504310828f473d424e2ed229eff57bf075f52796.1669969781.git.christophe.leroy@csgroup.eu
2022-12-02powerpc/feature-fixups: Do not patch init section after initChristophe Leroy
Once init section is freed, attempting to patch init code ends up in the weed. Commit 51c3c62b58b3 ("powerpc: Avoid code patching freed init sections") protected patch_instruction() against that, but it is the responsibility of the caller to ensure that the patched memory is valid. In the same spirit as jump_label with its jump_label_can_update() function, add is_fixup_addr_valid() function to skip patching on freed init section. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/8e9311fc1b057e4e6a2a3a0701ebcc74b787affe.1669969781.git.christophe.leroy@csgroup.eu
2022-12-02powerpc/feature-fixups: Refactor other fixups patchingChristophe Leroy
Several fonctions have the same loop for patching instructions. Introduce function do_patch_fixups() to refactor those loops. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/58ab36949c18f94d466fc98d6c085783b0cd474f.1669969781.git.christophe.leroy@csgroup.eu
2022-12-02powerpc/feature-fixups: Refactor entry fixups patchingChristophe Leroy
Several fonctions have the same loop for patching instructions. Introduce function do_patch_entry_fixups() to refactor those loops. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/79eeff7b20a98f7136da5f79b1f7c436928f27f3.1669969781.git.christophe.leroy@csgroup.eu
2022-12-02powerpc/code-patching: Remove #ifdef CONFIG_STRICT_KERNEL_RWXChristophe Leroy
No need to have one implementation of patch_instruction() for CONFIG_STRICT_KERNEL_RWX and one for !CONFIG_STRICT_KERNEL_RWX. In patch_instruction(), call raw_patch_instruction() when !CONFIG_STRICT_KERNEL_RWX. In poking_init(), bail out immediately, it will be equivalent to the weak default implementation. Everything else is declared static and will be discarded by GCC when !CONFIG_STRICT_KERNEL_RWX. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/f67d2a109404d03e8fdf1ea15388c8778337a76b.1669969781.git.christophe.leroy@csgroup.eu
2022-12-02tty: nfcon: use console_is_registered()John Ogness
Currently CON_ENABLED is being (mis)used to identify if the console has been registered. This is not reliable because it can be set even though registration failed or it can be unset, even though the console is registered. Use console_is_registered() instead. Signed-off-by: John Ogness <john.ogness@linutronix.de> Reviewed-by: Petr Mladek <pmladek@suse.com> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Petr Mladek <pmladek@suse.com> Link: https://lore.kernel.org/r/20221116162152.193147-24-john.ogness@linutronix.de
2022-12-02um: kmsg_dumper: use srcu console list iteratorJohn Ogness
Rather than using the console_lock to guarantee safe console list traversal, use srcu console list iteration. Signed-off-by: John Ogness <john.ogness@linutronix.de> Reviewed-by: Petr Mladek <pmladek@suse.com> Signed-off-by: Petr Mladek <pmladek@suse.com> Link: https://lore.kernel.org/r/20221116162152.193147-14-john.ogness@linutronix.de
2022-12-02um: kmsg_dump: only dump when no output console availableJohn Ogness
The initial intention of the UML kmsg_dumper is to dump the kernel buffers to stdout if there is no console available to perform the regular crash output. However, if ttynull was registered as a console, no crash output was seen. Commit e23fe90dec28 ("um: kmsg_dumper: always dump when not tty console") tried to fix this by performing the kmsg_dump unless the stdio console was behind /dev/console or enabled. But this allowed kmsg dumping to occur even if other non-stdio consoles will output the crash output. Also, a console being the driver behind /dev/console has nothing to do with a crash scenario. Restore the initial intention by dumping the kernel buffers to stdout only if a non-ttynull console is registered and enabled. Also add detailed comments so that it is clear why these rules are applied. Signed-off-by: John Ogness <john.ogness@linutronix.de> Reviewed-by: Petr Mladek <pmladek@suse.com> Signed-off-by: Petr Mladek <pmladek@suse.com> Link: https://lore.kernel.org/r/20221116162152.193147-8-john.ogness@linutronix.de
2022-12-02crypto: Prepare to move crypto_tfm_ctxHerbert Xu
The helper crypto_tfm_ctx is only used by the Crypto API algorithm code and should really be in algapi.h. However, for historical reasons many files relied on it to be in crypto.h. This patch changes those files to use algapi.h instead in prepartion for a move. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2022-12-02crypto: x86/curve25519 - disable gcovJoe Fradley
curve25519-x86_64.c fails to build when CONFIG_GCOV_KERNEL is enabled. The error is "inline assembly requires more registers than available" thrown from the `fsqr()` function. Therefore, excluding this file from GCOV profiling until this issue is resolved. Thereby allowing CONFIG_GCOV_PROFILE_ALL to be enabled for x86. Signed-off-by: Joe Fradley <joefradley@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
generated by cgit (git 2.34.1) at 2025-09-21 16:15:47 +0000