summaryrefslogtreecommitdiffstats
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2023-01-13x86/pci: Treat EfiMemoryMappedIO as reservation of ECAM spaceBjorn Helgaas1-0/+31
Normally we reject ECAM space unless it is reported as reserved in the E820 table or via a PNP0C02 _CRS method (PCI Firmware, r3.3, sec 4.1.2). 07eab0901ede ("efi/x86: Remove EfiMemoryMappedIO from E820 map"), removes E820 entries that correspond to EfiMemoryMappedIO regions because some other firmware uses EfiMemoryMappedIO for PCI host bridge windows, and the E820 entries prevent Linux from allocating BAR space for hot-added devices. Some firmware doesn't report ECAM space via PNP0C02 _CRS methods, but does mention it as an EfiMemoryMappedIO region via EFI GetMemoryMap(), which is normally converted to an E820 entry by a bootloader or EFI stub. After 07eab0901ede, that E820 entry is removed, so we reject this ECAM space, which makes PCI extended config space (offsets 0x100-0xfff) inaccessible. The lack of extended config space breaks anything that relies on it, including perf, VSEC telemetry, EDAC, QAT, SR-IOV, etc. Allow use of ECAM for extended config space when the region is covered by an EfiMemoryMappedIO region, even if it's not included in E820 or PNP0C02 _CRS. Link: https://lore.kernel.org/r/ac2693d8-8ba3-72e0-5b66-b3ae008d539d@linux.intel.com Link: https://bugzilla.kernel.org/show_bug.cgi?id=216891 Fixes: 07eab0901ede ("efi/x86: Remove EfiMemoryMappedIO from E820 map") Link: https://lore.kernel.org/r/20230110180243.1590045-3-helgaas@kernel.org Reported-by: Kan Liang <kan.liang@linux.intel.com> Reported-by: Tony Luck <tony.luck@intel.com> Reported-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Reported-by: Yunying Sun <yunying.sun@intel.com> Reported-by: Baowen Zheng <baowen.zheng@corigine.com> Reported-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reported-by: Yang Lixiao <lixiao.yang@intel.com> Tested-by: Tony Luck <tony.luck@intel.com> Tested-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Tested-by: Kan Liang <kan.liang@linux.intel.com> Tested-by: Yunying Sun <yunying.sun@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Rafael J. Wysocki <rafael@kernel.org>
2023-01-13Merge tag 'efi-fixes-for-v6.2-1' of ↵Linus Torvalds1-0/+1
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi Pull EFI fixes from Ard Biesheuvel: - avoid a potential crash on the efi_subsys_init() error path - use more appropriate error code for runtime services calls issued after a crash in the firmware occurred - avoid READ_ONCE() for accessing firmware tables that may appear misaligned in memory * tag 'efi-fixes-for-v6.2-1' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: efi: tpm: Avoid READ_ONCE() for accessing the event log efi: rt-wrapper: Add missing include efi: fix userspace infinite retry read efivars after EFI runtime services page fault efi: fix NULL-deref in init error path
2023-01-13Merge tag 'arm64-fixes' of ↵Linus Torvalds16-49/+132
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fixes from Will Deacon: "Here's a sizeable batch of Friday the 13th arm64 fixes for -rc4. What could possibly go wrong? The obvious reason we have so much here is because of the holiday season right after the merge window, but we've also brought back an erratum workaround that was previously dropped at the last minute and there's an MTE coredumping fix that strays outside of the arch/arm64 directory. Summary: - Fix PAGE_TABLE_CHECK failures on hugepage splitting path - Fix PSCI encoding of MEM_PROTECT_RANGE function in UAPI header - Fix NULL deref when accessing debugfs node if PSCI is not present - Fix MTE core dumping when VMA list is being updated concurrently - Fix SME signal frame handling when SVE is not implemented by the CPU - Fix asm constraints for cmpxchg_double() to hazard both words - Fix build failure with stack tracer and older versions of Clang - Bring back workaround for Cortex-A715 erratum 2645198" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: Fix build with CC=clang, CONFIG_FTRACE=y and CONFIG_STACK_TRACER=y arm64/mm: Define dummy pud_user_exec() when using 2-level page-table arm64: errata: Workaround possible Cortex-A715 [ESR|FAR]_ELx corruption firmware/psci: Don't register with debugfs if PSCI isn't available firmware/psci: Fix MEM_PROTECT_RANGE function numbers arm64/signal: Always allocate SVE signal frames on SME only systems arm64/signal: Always accept SVE signal frames on SME only systems arm64/sme: Fix context switch for SME only systems arm64: cmpxchg_double*: hazard against entire exchange variable arm64/uprobes: change the uprobe_opcode_t typedef to fix the sparse warning arm64: mte: Avoid the racy walk of the vma list during core dump elfcore: Add a cprm parameter to elf_core_extra_{phdrs,data_size} arm64: mte: Fix double-freeing of the temporary tag storage during coredump arm64: ptrace: Use ARM64_SME to guard the SME register enumerations arm64/mm: add pud_user_exec() check in pud_user_accessible_page() arm64/mm: fix incorrect file_map_count for invalid pmd
2023-01-12Merge tag 's390-6.2-2' of ↵Linus Torvalds11-73/+107
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 fixes from Heiko Carstens: - Add various missing READ_ONCE() to cmpxchg() loops prevent the compiler from potentially generating incorrect code. This includes a rather large change to the s390 specific hardware sampling code and its current use of cmpxchg_double(). Do the fix now to get it out of the way of Peter Zijlstra's cmpxchg128() work, and have something that can be backported. The added new code includes a private 128 bit cmpxchg variant which will be removed again after Peter's rework is available. Also note that this 128 bit cmpxchg variant is used to implement 128 bit READ_ONCE(), while strictly speaking it wouldn't be necessary, and _READ_ONCE() should also be sufficient; even though it isn't obvious for all converted locations that this is the case. Therefore use this implementation for for the sake of clarity and consistency for now. - Fix ipl report address handling to avoid kdump failures/hangs. - Fix misuse of #(el)if in kernel decompressor. - Define RUNTIME_DISCARD_EXIT to fix link error with GNU ld < 2.36, caused by the recently changed discard behaviour. - Make sure _edata and _end symbols are always page aligned. - The current header guard DEBUG_H in one of the s390 specific header files is too generic and conflicts with the ath9k wireless driver. Add an _ASM_S390_ prefix to the guard to make it unique. - Update defconfigs. * tag 's390-6.2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390: update defconfigs KVM: s390: interrupt: use READ_ONCE() before cmpxchg() s390/percpu: add READ_ONCE() to arch_this_cpu_to_op_simple() s390/cpum_sf: add READ_ONCE() semantics to compare and swap loops s390/kexec: fix ipl report address for kdump s390: fix -Wundef warning for CONFIG_KERNEL_ZSTD s390: define RUNTIME_DISCARD_EXIT to fix link error with GNU ld < 2.36 s390: expicitly align _edata and _end symbols on page boundary s390/debug: add _ASM_S390_ prefix to header guard
2023-01-12Merge tag 'for-linus-6.2-rc4-tag' of ↵Linus Torvalds1-5/+0
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip Pull xen fixes from Juergen Gross: - two cleanup patches - a fix of a memory leak in the Xen pvfront driver - a fix of a locking issue in the Xen hypervisor console driver * tag 'for-linus-6.2-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: xen/pvcalls: free active map buffer on pvcalls_front_free_map hvc/xen: lock console list traversal x86/xen: Remove the unused function p2m_index() xen: make remove callback of xen driver void returned
2023-01-12Merge tag 'perf-urgent-2023-01-12' of ↵Linus Torvalds3-9/+16
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf events hw enablement from Ingo Molnar: - More hardware-enablement for Intel Meteor Lake & Emerald Rapid systems: pure model ID enumeration additions that do not affect other systems. * tag 'perf-urgent-2023-01-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf/x86/intel/uncore: Add Emerald Rapids perf/x86/msr: Add Emerald Rapids perf/x86/msr: Add Meteor Lake support perf/x86/cstate: Add Meteor Lake support
2023-01-12ARM: dts: at91: sam9x60: fix the ddr clock for sam9x60Claudiu Beznea1-1/+1
The 2nd DDR clock for sam9x60 DDR controller is peripheral clock with id 49. Fixes: 1e5f532c2737 ("ARM: dts: at91: sam9x60: add device tree for soc and board") Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Link: https://lore.kernel.org/r/20221208115241.36312-1-claudiu.beznea@microchip.com
2023-01-12x86/mm: fix poking_init() for Xen PV guestsJuergen Gross1-0/+4
Commit 3f4c8211d982 ("x86/mm: Use mm_alloc() in poking_init()") broke the kernel for running as Xen PV guest. It seems as if the new address space is never activated before being used, resulting in Xen rejecting to accept the new CR3 value (the PGD isn't pinned). Fix that by adding the now missing call of paravirt_arch_dup_mmap() to poking_init(). That call was previously done by dup_mm()->dup_mmap() and it is a NOP for all cases but for Xen PV, where it is just doing the pinning of the PGD. Fixes: 3f4c8211d982 ("x86/mm: Use mm_alloc() in poking_init()") Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20230109150922.10578-1-jgross@suse.com
2023-01-12powerpc/64s/hash: Make stress_hpt_timer_fn() staticYang Yingliang1-1/+1
stress_hpt_timer_fn() is only used in hash_utils.c, make it static. Fixes: 6b34a099faa1 ("powerpc/64s/hash: add stress_hpt kernel boot option to increase hash faults") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20221228093603.3166599-1-yangyingliang@huawei.com
2023-01-11KVM: x86/xen: Avoid deadlock by adding kvm->arch.xen.xen_lock leaf node lockDavid Woodhouse2-37/+31
In commit 14243b387137a ("KVM: x86/xen: Add KVM_IRQ_ROUTING_XEN_EVTCHN and event channel delivery") the clever version of me left some helpful notes for those who would come after him: /* * For the irqfd workqueue, using the main kvm->lock mutex is * fine since this function is invoked from kvm_set_irq() with * no other lock held, no srcu. In future if it will be called * directly from a vCPU thread (e.g. on hypercall for an IPI) * then it may need to switch to using a leaf-node mutex for * serializing the shared_info mapping. */ mutex_lock(&kvm->lock); In commit 2fd6df2f2b47 ("KVM: x86/xen: intercept EVTCHNOP_send from guests") the other version of me ran straight past that comment without reading it, and introduced a potential deadlock by taking vcpu->mutex and kvm->lock in the wrong order. Solve this as originally suggested, by adding a leaf-node lock in the Xen state rather than using kvm->lock for it. Fixes: 2fd6df2f2b47 ("KVM: x86/xen: intercept EVTCHNOP_send from guests") Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Message-Id: <20230111180651.14394-4-dwmw2@infradead.org> [Rebase, add docs. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-01-11x86/pci: Simplify is_mmconf_reserved() messagesBjorn Helgaas1-6/+7
is_mmconf_reserved() takes a "with_e820" parameter that only determines the message logged if it finds the MMCONFIG region is reserved. Pass the message directly, which will simplify a future patch that adds a new way of looking for that reservation. No functional change intended. Link: https://lore.kernel.org/r/20230110180243.1590045-2-helgaas@kernel.org Tested-by: Tony Luck <tony.luck@intel.com> Tested-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Tested-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Dan Williams <dan.j.williams@intel.com>
2023-01-11s390: update defconfigsHeiko Carstens3-6/+9
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-01-11KVM: x86/xen: Fix potential deadlock in kvm_xen_update_runstate_guest()David Woodhouse1-2/+17
The kvm_xen_update_runstate_guest() function can be called when the vCPU is being scheduled out, from a preempt notifier. It *opportunistically* updates the runstate area in the guest memory, if the gfn_to_pfn_cache which caches the appropriate address is still valid. If there is *contention* when it attempts to obtain gpc->lock, then locking inside the priority inheritance checks may cause a deadlock. Lockdep reports: [13890.148997] Chain exists of: &gpc->lock --> &p->pi_lock --> &rq->__lock [13890.149002] Possible unsafe locking scenario: [13890.149003] CPU0 CPU1 [13890.149004] ---- ---- [13890.149005] lock(&rq->__lock); [13890.149007] lock(&p->pi_lock); [13890.149009] lock(&rq->__lock); [13890.149011] lock(&gpc->lock); [13890.149013] *** DEADLOCK *** In the general case, if there's contention for a read lock on gpc->lock, that's going to be because something else is either invalidating or revalidating the cache. Either way, we've raced with seeing it in an invalid state, in which case we would have aborted the opportunistic update anyway. So in the 'atomic' case when called from the preempt notifier, just switch to using read_trylock() and avoid the PI handling altogether. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Message-Id: <20230111180651.14394-2-dwmw2@infradead.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-01-11KVM: x86/xen: Fix lockdep warning on "recursive" gpc lockingDavid Woodhouse1-1/+3
In commit 5ec3289b31 ("KVM: x86/xen: Compatibility fixes for shared runstate area") we declared it safe to obtain two gfn_to_pfn_cache locks at the same time: /* * The guest's runstate_info is split across two pages and we * need to hold and validate both GPCs simultaneously. We can * declare a lock ordering GPC1 > GPC2 because nothing else * takes them more than one at a time. */ However, we forgot to tell lockdep. Do so, by setting a subclass on the first lock before taking the second. Fixes: 5ec3289b31 ("KVM: x86/xen: Compatibility fixes for shared runstate area") Suggested-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Message-Id: <20230111180651.14394-1-dwmw2@infradead.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-01-11Merge tag 'kvmarm-fixes-6.2-1' of ↵Paolo Bonzini9-39/+60
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into kvm-master KVM/arm64 fixes for 6.2, take #1 - Fix the PMCR_EL0 reset value after the PMU rework - Correctly handle S2 fault triggered by a S1 page table walk by not always classifying it as a write, as this breaks on R/O memslots - Document why we cannot exit with KVM_EXIT_MMIO when taking a write fault from a S1 PTW on a R/O memslot - Put the Apple M2 on the naughty step for not being able to correctly implement the vgic SEIS feature, just liek the M1 before it - Reviewer updates: Alex is stepping down, replaced by Zenghui
2023-01-11ARM: 9284/1: include <asm/pgtable.h> from proc-macros.S to fix -Wundef warningsMasahiro Yamada1-0/+1
Since commit 80b6093b55e3 ("kbuild: add -Wundef to KBUILD_CPPFLAGS for W=1 builds"), building with W=1 detects -Wundef warnings for assembly code. $ make W=1 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- arch/arm/mm/ [snip] AS arch/arm/mm/cache-v7.o In file included from arch/arm/mm/cache-v7.S:17: arch/arm/mm/proc-macros.S:109:5: warning: "L_PTE_SHARED" is not defined, evaluates to 0 [-Wundef] 109 | #if L_PTE_SHARED != PTE_EXT_SHARED | ^~~~~~~~~~~~ arch/arm/mm/proc-macros.S:109:21: warning: "PTE_EXT_SHARED" is not defined, evaluates to 0 [-Wundef] 109 | #if L_PTE_SHARED != PTE_EXT_SHARED | ^~~~~~~~~~~~~~ arch/arm/mm/proc-macros.S:113:10: warning: "L_PTE_XN" is not defined, evaluates to 0 [-Wundef] 113 | (L_PTE_XN+L_PTE_USER+L_PTE_RDONLY+L_PTE_DIRTY+L_PTE_YOUNG+\ | ^~~~~~~~ arch/arm/mm/proc-macros.S:113:19: warning: "L_PTE_USER" is not defined, evaluates to 0 [-Wundef] 113 | (L_PTE_XN+L_PTE_USER+L_PTE_RDONLY+L_PTE_DIRTY+L_PTE_YOUNG+\ | ^~~~~~~~~~ arch/arm/mm/proc-macros.S:113:30: warning: "L_PTE_RDONLY" is not defined, evaluates to 0 [-Wundef] 113 | (L_PTE_XN+L_PTE_USER+L_PTE_RDONLY+L_PTE_DIRTY+L_PTE_YOUNG+\ | ^~~~~~~~~~~~ arch/arm/mm/proc-macros.S:113:43: warning: "L_PTE_DIRTY" is not defined, evaluates to 0 [-Wundef] 113 | (L_PTE_XN+L_PTE_USER+L_PTE_RDONLY+L_PTE_DIRTY+L_PTE_YOUNG+\ | ^~~~~~~~~~~ arch/arm/mm/proc-macros.S:113:55: warning: "L_PTE_YOUNG" is not defined, evaluates to 0 [-Wundef] 113 | (L_PTE_XN+L_PTE_USER+L_PTE_RDONLY+L_PTE_DIRTY+L_PTE_YOUNG+\ | ^~~~~~~~~~~ arch/arm/mm/proc-macros.S:114:10: warning: "L_PTE_PRESENT" is not defined, evaluates to 0 [-Wundef] 114 | L_PTE_PRESENT) > L_PTE_SHARED | ^~~~~~~~~~~~~ arch/arm/mm/proc-macros.S:114:27: warning: "L_PTE_SHARED" is not defined, evaluates to 0 [-Wundef] 114 | L_PTE_PRESENT) > L_PTE_SHARED | ^~~~~~~~~~~~ Include <asm/pgtable.h> from proc-macros.S to fix the warnings. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2023-01-11ARM: 9280/1: mm: fix warning on phys_addr_t to void pointer assignmentGiulio Benetti1-1/+1
zero_page is a void* pointer but memblock_alloc() returns phys_addr_t type so this generates a warning while using clang and with -Wint-error enabled that becomes and error. So let's cast the return of memblock_alloc() to (void *). Cc: <stable@vger.kernel.org> # 4.14.x + Fixes: 340a982825f7 ("ARM: 9266/1: mm: fix no-MMU ZERO_PAGE() implementation") Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2023-01-11KVM: s390: interrupt: use READ_ONCE() before cmpxchg()Heiko Carstens1-4/+8
Use READ_ONCE() before cmpxchg() to prevent that the compiler generates code that fetches the to be compared old value several times from memory. Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Link: https://lore.kernel.org/r/20230109145456.2895385-1-hca@linux.ibm.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-01-11s390/percpu: add READ_ONCE() to arch_this_cpu_to_op_simple()Heiko Carstens1-1/+1
Make sure that *ptr__ within arch_this_cpu_to_op_simple() is only dereferenced once by using READ_ONCE(). Otherwise the compiler could generate incorrect code. Cc: <stable@vger.kernel.org> Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-01-11s390/cpum_sf: add READ_ONCE() semantics to compare and swap loopsHeiko Carstens2-55/+77
The current cmpxchg_double() loops within the perf hw sampling code do not have READ_ONCE() semantics to read the old value from memory. This allows the compiler to generate code which reads the "old" value several times from memory, which again allows for inconsistencies. For example: /* Reset trailer (using compare-double-and-swap) */ do { te_flags = te->flags & ~SDB_TE_BUFFER_FULL_MASK; te_flags |= SDB_TE_ALERT_REQ_MASK; } while (!cmpxchg_double(&te->flags, &te->overflow, te->flags, te->overflow, te_flags, 0ULL)); The compiler could generate code where te->flags used within the cmpxchg_double() call may be refetched from memory and which is not necessarily identical to the previous read version which was used to generate te_flags. Which in turn means that an incorrect update could happen. Fix this by adding READ_ONCE() semantics to all cmpxchg_double() loops. Given that READ_ONCE() cannot generate code on s390 which atomically reads 16 bytes, use a private compare-and-swap-double implementation to achieve that. Also replace cmpxchg_double() with the private implementation to be able to re-use the old value within the loops. As a side effect this converts the whole code to only use bit fields to read and modify bits within the hws trailer header. Reported-by: Alexander Gordeev <agordeev@linux.ibm.com> Acked-by: Alexander Gordeev <agordeev@linux.ibm.com> Acked-by: Hendrik Brueckner <brueckner@linux.ibm.com> Reviewed-by: Thomas Richter <tmricht@linux.ibm.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/linux-s390/Y71QJBhNTIatvxUT@osiris/T/#ma14e2a5f7aa8ed4b94b6f9576799b3ad9c60f333 Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-01-11powerpc/imc-pmu: Fix use of mutex in IRQs disabled sectionKajol Jain2-71/+67
Current imc-pmu code triggers a WARNING with CONFIG_DEBUG_ATOMIC_SLEEP and CONFIG_PROVE_LOCKING enabled, while running a thread_imc event. Command to trigger the warning: # perf stat -e thread_imc/CPM_CS_FROM_L4_MEM_X_DPTEG/ sleep 5 Performance counter stats for 'sleep 5': 0 thread_imc/CPM_CS_FROM_L4_MEM_X_DPTEG/ 5.002117947 seconds time elapsed 0.000131000 seconds user 0.001063000 seconds sys Below is snippet of the warning in dmesg: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 2869, name: perf-exec preempt_count: 2, expected: 0 4 locks held by perf-exec/2869: #0: c00000004325c540 (&sig->cred_guard_mutex){+.+.}-{3:3}, at: bprm_execve+0x64/0xa90 #1: c00000004325c5d8 (&sig->exec_update_lock){++++}-{3:3}, at: begin_new_exec+0x460/0xef0 #2: c0000003fa99d4e0 (&cpuctx_lock){-...}-{2:2}, at: perf_event_exec+0x290/0x510 #3: c000000017ab8418 (&ctx->lock){....}-{2:2}, at: perf_event_exec+0x29c/0x510 irq event stamp: 4806 hardirqs last enabled at (4805): [<c000000000f65b94>] _raw_spin_unlock_irqrestore+0x94/0xd0 hardirqs last disabled at (4806): [<c0000000003fae44>] perf_event_exec+0x394/0x510 softirqs last enabled at (0): [<c00000000013c404>] copy_process+0xc34/0x1ff0 softirqs last disabled at (0): [<0000000000000000>] 0x0 CPU: 36 PID: 2869 Comm: perf-exec Not tainted 6.2.0-rc2-00011-g1247637727f2 #61 Hardware name: 8375-42A POWER9 0x4e1202 opal:v7.0-16-g9b85f7d961 PowerNV Call Trace: dump_stack_lvl+0x98/0xe0 (unreliable) __might_resched+0x2f8/0x310 __mutex_lock+0x6c/0x13f0 thread_imc_event_add+0xf4/0x1b0 event_sched_in+0xe0/0x210 merge_sched_in+0x1f0/0x600 visit_groups_merge.isra.92.constprop.166+0x2bc/0x6c0 ctx_flexible_sched_in+0xcc/0x140 ctx_sched_in+0x20c/0x2a0 ctx_resched+0x104/0x1c0 perf_event_exec+0x340/0x510 begin_new_exec+0x730/0xef0 load_elf_binary+0x3f8/0x1e10 ... do not call blocking ops when !TASK_RUNNING; state=2001 set at [<00000000fd63e7cf>] do_nanosleep+0x60/0x1a0 WARNING: CPU: 36 PID: 2869 at kernel/sched/core.c:9912 __might_sleep+0x9c/0xb0 CPU: 36 PID: 2869 Comm: sleep Tainted: G W 6.2.0-rc2-00011-g1247637727f2 #61 Hardware name: 8375-42A POWER9 0x4e1202 opal:v7.0-16-g9b85f7d961 PowerNV NIP: c000000000194a1c LR: c000000000194a18 CTR: c000000000a78670 REGS: c00000004d2134e0 TRAP: 0700 Tainted: G W (6.2.0-rc2-00011-g1247637727f2) MSR: 9000000000021033 <SF,HV,ME,IR,DR,RI,LE> CR: 48002824 XER: 00000000 CFAR: c00000000013fb64 IRQMASK: 1 The above warning triggered because the current imc-pmu code uses mutex lock in interrupt disabled sections. The function mutex_lock() internally calls __might_resched(), which will check if IRQs are disabled and in case IRQs are disabled, it will trigger the warning. Fix the issue by changing the mutex lock to spinlock. Fixes: 8f95faaac56c ("powerpc/powernv: Detect and create IMC device") Reported-by: Michael Petlan <mpetlan@redhat.com> Reported-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Kajol Jain <kjain@linux.ibm.com> [mpe: Fix comments, trim oops in change log, add reported-by tags] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20230106065157.182648-1-kjain@linux.ibm.com
2023-01-11powerpc/boot: Fix incorrect version calculation issue in ld_versionOjaswin Mujoo1-0/+4
The ld_version() function computes the wrong version value for certain ld versions such as the following: $ ld --version GNU ld (GNU Binutils; SUSE Linux Enterprise 15) 2.37.20211103-150100.7.37 For input 2.37.20211103, the value computed is 202348030000 which is higher than the value for a later version like 2.39.0, which is 23900000. This issue was highlighted because with the above ld version, the powerpc kernel build started failing with ld error: "unrecognized option --no-warn-rwx-segments". This was caused due to the recent commit 579aee9fc594 ("powerpc: suppress some linker warnings in recent linker versions") which added the --no-warn-rwx-segments linker flag if the ld version is greater than 2.39. Due to the bug in ld_version(), ld version 2.37.20111103 is wrongly calculated to be greater than 2.39 and the unsupported flag is added. To fix it, if version is of the form x.y.z and length(z) == 8, then most probably it is a date [yyyymmdd] commonly used for release snapshots and not an actual new version. Hence, ignore the date part replacing it with 0. Fixes: 579aee9fc594 ("powerpc: suppress some linker warnings in recent linker versions") Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> [mpe: Tweak change log wording/formatting, add Fixes tag] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20230104202437.90039-1-ojaswin@linux.ibm.com
2023-01-10Merge tag 'qcom-arm64-fixes-for-6.2' of ↵Arnd Bergmann7-82/+108
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/fixes Qualcomm ARM64 DTS fixes for 6.2 The cluster idle issue was resolved on SM8250, so the change disabling the cluster state is being reverted. Issues where identified with the QMP PHY binding, that would prevent enablement of Displayport and it was decided not to support the old binding for the recently introduced SC8280XP, which broke USB. This adjusts the USB PHY nodes to the new binding. The reset signal for the first QMP PHY is corrected as well. The reserved memory map is updated on Xiaomi Mi 4C and Huawei Nexus 6P, to avoid instabilities caused by use of protected memory regions. The compatible for the MSM8992 TCSR mutex is corrected as well. Lastly SDHCI interconnects on SM8350 are corrected to match the providers #interconnect-cells. * tag 'qcom-arm64-fixes-for-6.2' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: arm64: dts: qcom: msm8992-libra: Fix the memory map arm64: dts: qcom: msm8992: Don't use sfpb mutex arm64: dts: msm8994-angler: fix the memory map arm64: dts: qcom: sm8350: correct SDHCI interconnect arguments Revert "arm64: dts: qcom: sm8250: Disable the not yet supported cluster idle state" arm64: dts: msm8992-bullhead: add memory hole region arm64: dts: qcom: sc8280xp: fix USB-DP PHY nodes arm64: dts: qcom: sc8280xp: fix primary USB-DP PHY reset Link: https://lore.kernel.org/r/20230110213724.2183668-1-andersson@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-01-10Merge tag 'qcom-dts-fixes-for-6.2' of ↵Arnd Bergmann2-12/+12
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/fixes Qualcomm ARM32 DTS fix for 6.2 This fixes a regression on Inforce 6540, as the sdhci nodes no longer overrides the platform's mmc nodes. * tag 'qcom-dts-fixes-for-6.2' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: ARM: dts: qcom: apq8084-ifc6540: fix overriding SDHCI Link: https://lore.kernel.org/r/20230110212750.2182904-1-andersson@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-01-10Merge branch 'armsoc-build-fixes' of ↵Arnd Bergmann7-53/+19
https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc into arm/fixes ARM: SoC fixes These are three fixes for mistakes I discovered during the preparation of the boardfile removal. Robert noticed the accidental removal of PXA310 and PXA320 support because of a misplaced Kconfig statement, and the two OMAP patches were build failures that got introduced earlier but that I found while testing the removal. * 'armsoc-build-fixes' of https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: ARM: omap1: fix building gpio15xx ARM: omap1: fix !ARCH_OMAP1_ANY link failures ARM: pxa: enable PXA310/PXA320 for DT-only build
2023-01-10ARM: omap1: fix building gpio15xxArnd Bergmann1-0/+1
In some randconfig builds, the asm/irq.h header is not included in gpio15xx.c, so add an explicit include to avoid a build fialure: In file included from arch/arm/mach-omap1/gpio15xx.c:15: arch/arm/mach-omap1/irqs.h:99:34: error: 'NR_IRQS_LEGACY' undeclared here (not in a function) 99 | #define IH2_BASE (NR_IRQS_LEGACY + 32) | ^~~~~~~~~~~~~~ arch/arm/mach-omap1/irqs.h:105:38: note: in expansion of macro 'IH2_BASE' 105 | #define INT_MPUIO (5 + IH2_BASE) | ^~~~~~~~ arch/arm/mach-omap1/gpio15xx.c:28:27: note: in expansion of macro 'INT_MPUIO' 28 | .start = INT_MPUIO, | ^~~~~~~~~ Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-01-10ARM: omap1: fix !ARCH_OMAP1_ANY link failuresArnd Bergmann5-53/+16
While compile-testing randconfig builds for the upcoming boardfile removal, I noticed that an earlier patch of mine was completely broken, and the introduction of CONFIG_ARCH_OMAP1_ANY only replaced one set of build failures with another one, now resulting in link failures like ld: drivers/video/fbdev/omap/omapfb_main.o: in function `omapfb_do_probe': drivers/video/fbdev/omap/omapfb_main.c:1703: undefined reference to `omap_set_dma_priority' ld: drivers/dma/ti/omap-dma.o: in function `omap_dma_free_chan_resources': drivers/dma/ti/omap-dma.c:777: undefined reference to `omap_free_dma' drivers/dma/ti/omap-dma.c:1685: undefined reference to `omap_get_plat_info' ld: drivers/usb/gadget/udc/omap_udc.o: in function `next_in_dma': drivers/usb/gadget/udc/omap_udc.c:820: undefined reference to `omap_get_dma_active_status' I tried reworking it, but the resulting patch ended up much bigger than simply avoiding the original problem of unused-function warnings like arch/arm/mach-omap1/mcbsp.c:76:30: error: unused variable 'omap1_mcbsp_ops' [-Werror,-Wunused-variable] As a result, revert the previous fix, and rearrange the code that produces warnings to hide them. For mcbsp, the #ifdef check can simply be removed as the cpu_is_omapxxx() checks already achieve the same result, while in the io.c the easiest solution appears to be to merge the common map bits into each soc specific portion. This gets cleaned in a nicer way after omap7xx support gets dropped, as the remaining SoCs all have the exact same I/O map. Fixes: 615dce5bf736 ("ARM: omap1: fix build with no SoC selected") Cc: stable@vger.kernel.org Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-01-10Merge tag 'xtensa-20230110' of https://github.com/jcmvbkbc/linux-xtensaLinus Torvalds3-15/+0
Pull xtensa fixes from Max Filippov: - fix xtensa allmodconfig build broken by the kcsan test - drop unused members of struct thread_struct * tag 'xtensa-20230110' of https://github.com/jcmvbkbc/linux-xtensa: xtensa: drop unused members of struct thread_struct kcsan: test: don't put the expect array on the stack
2023-01-10x86/resctrl: Fix event counts regression in reused RMIDsPeter Newman1-16/+33
When creating a new monitoring group, the RMID allocated for it may have been used by a group which was previously removed. In this case, the hardware counters will have non-zero values which should be deducted from what is reported in the new group's counts. resctrl_arch_reset_rmid() initializes the prev_msr value for counters to 0, causing the initial count to be charged to the new group. Resurrect __rmid_read() and use it to initialize prev_msr correctly. Unlike before, __rmid_read() checks for error bits in the MSR read so that callers don't need to. Fixes: 1d81d15db39c ("x86/resctrl: Move mbm_overflow_count() into resctrl_arch_rmid_read()") Signed-off-by: Peter Newman <peternewman@google.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Tested-by: Babu Moger <babu.moger@amd.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20221220164132.443083-1-peternewman@google.com
2023-01-10x86/resctrl: Fix task CLOSID/RMID update racePeter Newman1-1/+11
When the user moves a running task to a new rdtgroup using the task's file interface or by deleting its rdtgroup, the resulting change in CLOSID/RMID must be immediately propagated to the PQR_ASSOC MSR on the task(s) CPUs. x86 allows reordering loads with prior stores, so if the task starts running between a task_curr() check that the CPU hoisted before the stores in the CLOSID/RMID update then it can start running with the old CLOSID/RMID until it is switched again because __rdtgroup_move_task() failed to determine that it needs to be interrupted to obtain the new CLOSID/RMID. Refer to the diagram below: CPU 0 CPU 1 ----- ----- __rdtgroup_move_task(): curr <- t1->cpu->rq->curr __schedule(): rq->curr <- t1 resctrl_sched_in(): t1->{closid,rmid} -> {1,1} t1->{closid,rmid} <- {2,2} if (curr == t1) // false IPI(t1->cpu) A similar race impacts rdt_move_group_tasks(), which updates tasks in a deleted rdtgroup. In both cases, use smp_mb() to order the task_struct::{closid,rmid} stores before the loads in task_curr(). In particular, in the rdt_move_group_tasks() case, simply execute an smp_mb() on every iteration with a matching task. It is possible to use a single smp_mb() in rdt_move_group_tasks(), but this would require two passes and a means of remembering which task_structs were updated in the first loop. However, benchmarking results below showed too little performance impact in the simple approach to justify implementing the two-pass approach. Times below were collected using `perf stat` to measure the time to remove a group containing a 1600-task, parallel workload. CPU: Intel(R) Xeon(R) Platinum P-8136 CPU @ 2.00GHz (112 threads) # mkdir /sys/fs/resctrl/test # echo $$ > /sys/fs/resctrl/test/tasks # perf bench sched messaging -g 40 -l 100000 task-clock time ranges collected using: # perf stat rmdir /sys/fs/resctrl/test Baseline: 1.54 - 1.60 ms smp_mb() every matching task: 1.57 - 1.67 ms [ bp: Massage commit message. ] Fixes: ae28d1aae48a ("x86/resctrl: Use an IPI instead of task_work_add() to update PQR_ASSOC MSR") Fixes: 0efc89be9471 ("x86/intel_rdt: Update task closid immediately on CPU in rmdir and unmount") Signed-off-by: Peter Newman <peternewman@google.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Reviewed-by: Babu Moger <babu.moger@amd.com> Cc: <stable@kernel.org> Link: https://lore.kernel.org/r/20221220161123.432120-1-peternewman@google.com
2023-01-10x86/pat: Fix pat_x_mtrr_type() for MTRR disabled caseJuergen Gross1-1/+2
Since 72cbc8f04fe2 ("x86/PAT: Have pat_enabled() properly reflect state when running on Xen") PAT can be enabled without MTRR. This has resulted in problems e.g. for a SEV-SNP guest running under Hyper-V, when trying to establish a new mapping via memremap() with WB caching mode, as pat_x_mtrr_type() will call mtrr_type_lookup(), which in turn is returning MTRR_TYPE_INVALID due to MTRR being disabled in this configuration. The result is a mapping with UC- caching, leading to severe performance degradation. Fix that by handling MTRR_TYPE_INVALID the same way as MTRR_TYPE_WRBACK in pat_x_mtrr_type() because MTRR_TYPE_INVALID means MTRRs are disabled. [ bp: Massage commit message. ] Fixes: 72cbc8f04fe2 ("x86/PAT: Have pat_enabled() properly reflect state when running on Xen") Reported-by: Michael Kelley (LINUX) <mikelley@microsoft.com> Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Michael Kelley <mikelley@microsoft.com> Tested-by: Michael Kelley <mikelley@microsoft.com> Cc: <stable@kernel.org> Link: https://lore.kernel.org/r/20230110065427.20767-1-jgross@suse.com
2023-01-10arm64: dts: qcom: msm8992-libra: Fix the memory mapKonrad Dybcio1-17/+60
The memory map was wrong. Fix it to prevent the device from randomly rebooting. Fixes: 0f5cdb31e850 ("arm64: dts: qcom: Add Xiaomi Libra (Mi 4C) device tree") Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221219131918.446587-2-konrad.dybcio@linaro.org
2023-01-10arm64: dts: qcom: msm8992: Don't use sfpb mutexKonrad Dybcio1-4/+0
MSM8992 uses the same mutex hardware as MSM8994. This was wrong from the start, but never presented as an issue until the sfpb compatible was given different driver data. Fixes: 6a6d1978f9c0 ("arm64: dts: msm8992 SoC and LG Bullhead (Nexus 5X) support") Reported-by: Eugene Lepshy <fekz115@gmail.com> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221219131918.446587-1-konrad.dybcio@linaro.org
2023-01-10arm64: dts: msm8994-angler: fix the memory mapDominik Kobinski1-3/+16
Add reserved regions for memory hole and tz app mem to prevent rebooting. Also enable cont_splash_mem, it is the same as the generic 8994 one. Reported-by: Petr Vorel <petr.vorel@gmail.com> Signed-off-by: Dominik Kobinski <dominikkobinski314@gmail.com> Reviewed-by: Petr Vorel <petr.vorel@gmail.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221230194845.57780-1-dominikkobinski314@gmail.com
2023-01-10s390/kexec: fix ipl report address for kdumpAlexander Egorenkov1-2/+3
This commit addresses the following erroneous situation with file-based kdump executed on a system with a valid IPL report. On s390, a kdump kernel, its initrd and IPL report if present are loaded into a special and reserved on boot memory region - crashkernel. When a system crashes and kdump was activated before, the purgatory code is entered first which swaps the crashkernel and [0 - crashkernel size] memory regions. Only after that the kdump kernel is entered. For this reason, the pointer to an IPL report in lowcore must point to the IPL report after the swap and not to the address of the IPL report that was located in crashkernel memory region before the swap. Failing to do so, makes the kdump's decompressor try to read memory from the crashkernel memory region which already contains the production's kernel memory. The situation described above caused spontaneous kdump failures/hangs on systems where the Secure IPL is activated because on such systems an IPL report is always present. In that case kdump's decompressor tried to parse an IPL report which frequently lead to illegal memory accesses because an IPL report contains addresses to various data. Cc: <stable@vger.kernel.org> Fixes: 99feaa717e55 ("s390/kexec_file: Create ipl report and pass to next kernel") Reviewed-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-01-10x86/boot: Avoid using Intel mnemonics in AT&T syntax asmPeter Zijlstra1-2/+2
With 'GNU assembler (GNU Binutils for Debian) 2.39.90.20221231' the build now reports: arch/x86/realmode/rm/../../boot/bioscall.S: Assembler messages: arch/x86/realmode/rm/../../boot/bioscall.S:35: Warning: found `movsd'; assuming `movsl' was meant arch/x86/realmode/rm/../../boot/bioscall.S:70: Warning: found `movsd'; assuming `movsl' was meant arch/x86/boot/bioscall.S: Assembler messages: arch/x86/boot/bioscall.S:35: Warning: found `movsd'; assuming `movsl' was meant arch/x86/boot/bioscall.S:70: Warning: found `movsd'; assuming `movsl' was meant Which is due to: PR gas/29525 Note that with the dropped CMPSD and MOVSD Intel Syntax string insn templates taking operands, mixed IsString/non-IsString template groups (with memory operands) cannot occur anymore. With that maybe_adjust_templates() becomes unnecessary (and is hence being removed). More details: https://sourceware.org/bugzilla/show_bug.cgi?id=29525 Borislav Petkov further explains: " the particular problem here is is that the 'd' suffix is "conflicting" in the sense that you can have SSE mnemonics like movsD %xmm... and the same thing also for string ops (which is the case here) so apparently the agreement in binutils land is to use the always accepted suffixes 'l' or 'q' and phase out 'd' slowly... " Fixes: 7a734e7dd93b ("x86, setup: "glove box" BIOS calls -- infrastructure") Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Acked-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/Y71I3Ex2pvIxMpsP@hirez.programming.kicks-ass.net
2023-01-10sh/mm: Fix pmd_t for realPeter Zijlstra1-1/+1
Because typing is hard... Fixes: 0862ff059c9e ("sh/mm: Make pmd_t similar to pte_t") Reported-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2023-01-10arm64: dts: marvell: AC5/AC5X: Fix address for UART1Chris Packham1-1/+1
The correct address offset is 0x12100. Fixes: 31be791e26cf ("arm64: dts: marvell: Add UART1-3 for AC5/AC5X") Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2023-01-09ARM: footbridge: drop unnecessary inclusionAlexandre Belloni1-1/+0
isa-rtc.c doesn't use any definition from bcd.h, remove its inclusion Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20221212135953.212303-1-alexandre.belloni@bootlin.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-01-09Merge tag 'imx-fixes-6.2' of ↵Arnd Bergmann34-49/+47
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixes i.MX fixes for 6.2: - Fix i.MX8MP DT for missing GPC Interrupt, power-domain typo and USB clock error. - Fix mach-imx cpu code to add missing of_node_put() call. - A couple of verdin-imx8mm DT fixes for audio playback support. - Fix pca9547 i2c-mux node name for i.MX and Vybrid device trees. - Fix an imx93-11x11-evk uSDHC pad setting problem that causes Micron eMMC CMD8 CRC error in HS400ES/HS400 mode. - A couple of imx8mp-blk-ctrl driver fixes from Lucas Stach, enabling pixclk with HDMI_TX_PHY PD, dropping power device name setting. - Fix the error check for of_clk_get_by_name() in soc-imx8m driver. - Other various DT fixes and cleanups. * tag 'imx-fixes-6.2' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: (22 commits) soc: imx8m: Fix incorrect check for of_clk_get_by_name() arm64: dts: imx8mm-venice-gw7901: fix USB2 controller OC polarity arm64: dts: imx8mp-evk: pcie0-refclk cosmetic cleanup arm64: dts: imx8mp: Fix power-domain typo arm64: dts: imx8mp: Fix missing GPC Interrupt soc: imx: imx8mp-blk-ctrl: don't set power device name arm64: dts: imx8mm: Drop xtal clock specifier from eDM SBC ARM: imx: add missing of_node_put() arm64: dts: imx93-11x11-evk: correct clock and strobe pad setting arm64: dts: verdin-imx8mm: fix dev board audio playback arm64: dts: imx8mq-thor96: fix no-mmc property for SDHCI arm64: dts: imx8mm-beacon: Fix ecspi2 pinmux arm64: dts: freescale: Fix pca954x i2c-mux node names ARM: dts: vf610: Fix pca9548 i2c-mux node names ARM: dts: imx: Fix pca9547 i2c-mux node name arm64: dts: verdin-imx8mm: fix dahlia audio playback ARM: dts: imx6qdl-gw560x: Remove incorrect 'uart-has-rtscts' ARM: dts: imx7d-pico: Use 'clock-frequency' ARM: dts: imx6ul-pico-dwarf: Use 'clock-frequency' arm64: dts: imx8mp-phycore-som: Remove invalid PMIC property ... Link: https://lore.kernel.org/r/20230102132016.GA10699@T480 Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-01-09Merge tag 'amlogic-fixes-v6.2-rc' of ↵Arnd Bergmann1-6/+2
https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux into arm/fixes Amlogic fixes for v6.2-rc: - Revert "arm64: dts: meson-sm1-odroid-hc4: disable unused USB PHY0" which breaks whole USB on Odroid-HC4 * tag 'amlogic-fixes-v6.2-rc' of https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux: Revert "arm64: dts: meson-sm1-odroid-hc4: disable unused USB PHY0" Link: https://lore.kernel.org/r/7915c3f8-57bc-25e2-0314-c78af7a79d6a@linaro.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-01-09Revert "ARM: dts: armada-39x: Fix compatible string for gpios"Klaus Kudielka1-2/+2
This reverts commit d10886a4e6f85ee18d47a1066a52168461370ded. If compatible = "marvell,armadaxp-gpio", the reg property requires a second (address, size) pair, which points to the per-CPU interrupt registers <0x18800 0x30> / <0x18840 0x30>. Furthermore: Commit 5f79c651e81e explains very well, why the gpio-mvebu driver does not work reliably with per-CPU interrupts. Commit 988c8c0cd04d deprecates compatible = marvell,armadaxp-gpio for this reason. Signed-off-by: Klaus Kudielka <klaus.kudielka@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2023-01-09Revert "ARM: dts: armada-38x: Fix compatible string for gpios"Klaus Kudielka1-2/+2
This reverts commit c4de4667f15d04ef5920bacf41e514ec7d1ef03d, which causes a regression on Turris Omnia (Armada 385): GPIO interrupts cease to work, ending up in the DSA switch being non-functional. The blamed commit is incorrect in the first place: If compatible = "marvell,armadaxp-gpio", the second (address, size) pair of the reg property must to point to the per-CPU interrupt registers <0x18800 0x30> / <0x18840 0x30>, and not to the blink enable registers <0x181c0 0x08> / <0x181c8 0x08>. But even fixing that leaves the GPIO interrupts broken on the Omnia. Furthermore: Commit 5f79c651e81e explains very well, why the gpio-mvebu driver does not work reliably with per-CPU interrupts. Commit 988c8c0cd04d deprecates compatible = marvell,armadaxp-gpio for this reason. Fixes: c4de4667f15d ("ARM: dts: armada-38x: Fix compatible string for gpios") Reported-by: Klaus Kudielka <klaus.kudielka@gmail.com> Link: https://lore.kernel.org/r/f24474e70c1a4e9692bd596ef6d97ceda9511245.camel@gmail.com/ Signed-off-by: Klaus Kudielka <klaus.kudielka@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2023-01-09ARM: pxa: enable PXA310/PXA320 for DT-only buildArnd Bergmann1-0/+2
After commit b5aaaa666a85 ("ARM: pxa: add Kconfig dependencies for ATAGS based boards"), the default PXA build no longer includes support for the board files that are considered unused. As a side-effect of this, the PXA310 and PXA320 support is not built into the kernel any more, even though it should work in principle as long as the symbols are enabled. As Robert points out, there are dts files for zylonite and cm-x300, though those have not made it into the mainline kernel. Link: https://lore.kernel.org/linux-arm-kernel/m2sfglh02h.fsf@free.fr/ Reported-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-01-09arm64: Fix build with CC=clang, CONFIG_FTRACE=y and CONFIG_STACK_TRACER=yJames Clark1-2/+0
commit 45bd8951806e ("arm64: Improve HAVE_DYNAMIC_FTRACE_WITH_REGS selection for clang") fixed the build with the above combination by splitting HAVE_DYNAMIC_FTRACE_WITH_REGS into separate checks for Clang and GCC. commit 26299b3f6ba2 ("ftrace: arm64: move from REGS to ARGS") added the GCC only check "-fpatchable-function-entry=2" back in unconditionally which breaks the build. Remove the unconditional check, because the conditional ones were also updated to _ARGS in the above commit, so they work correctly on their own. Fixes: 26299b3f6ba2 ("ftrace: arm64: move from REGS to ARGS") Signed-off-by: James Clark <james.clark@arm.com> Link: https://lore.kernel.org/r/20230109122744.1904852-1-james.clark@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2023-01-09arm64/mm: Define dummy pud_user_exec() when using 2-level page-tableWill Deacon1-0/+1
With only two levels of page-table, the generic 'pud_*' macros are implemented using dummy operations in pgtable-nopmd.h. Since commit 730a11f982e6 ("arm64/mm: add pud_user_exec() check in pud_user_accessible_page()"), pud_user_accessible_page() unconditionally calls pud_user_exec(), which is an arm64-specific helper and therefore isn't defined by pgtable-nopmd.h. This results in a build failure for configurations with only two levels of page table: arch/arm64/include/asm/pgtable.h: In function 'pud_user_accessible_page': >> arch/arm64/include/asm/pgtable.h:870:51: error: implicit declaration of function 'pud_user_exec'; did you mean 'pmd_user_exec'? [-Werror=implicit-function-declaration] 870 | return pud_leaf(pud) && (pud_user(pud) || pud_user_exec(pud)); | ^~~~~~~~~~~~~ | pmd_user_exec Fix the problem by defining pud_user_exec() as pud_user() in this case. Link: https://lore.kernel.org/r/202301080515.z6zEksU4-lkp@intel.com Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Will Deacon <will@kernel.org>
2023-01-09s390: fix -Wundef warning for CONFIG_KERNEL_ZSTDMasahiro Yamada1-2/+2
Since commit 80b6093b55e3 ("kbuild: add -Wundef to KBUILD_CPPFLAGS for W=1 builds"), building with W=1 detects misuse of #(el)if. $ make W=1 ARCH=s390 CROSS_COMPILE=s390x-linux-gnu- [snip] arch/s390/boot/decompressor.c:28:7: warning: "CONFIG_KERNEL_ZSTD" is not defined, evaluates to 0 [-Wundef] 28 | #elif CONFIG_KERNEL_ZSTD | ^~~~~~~~~~~~~~~~~~ This issue has been hidden because arch/s390/boot/Makefile overwrites KBUILD_CFLAGS, dropping -Wundef. CONFIG_KERNEL_ZSTD is a bool option. #elif defined() should be used. The line #ifdef CONFIG_KERNEL_BZIP2 is fine, but I changed it for consistency. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Link: https://lore.kernel.org/r/20230106161024.2373602-1-masahiroy@kernel.org Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-01-09efi: rt-wrapper: Add missing includeArd Biesheuvel1-0/+1
Add the missing #include of asm/assembler.h, which is where the ldr_l macro is defined. Fixes: ff7a167961d1b97e ("arm64: efi: Execute runtime services from a dedicated stack") Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2023-01-09perf/x86/intel/uncore: Add Emerald RapidsKan Liang1-0/+1
From the perspective of the uncore PMU, the new Emerald Rapids is the same as the Sapphire Rapids. The only difference is the event list, which will be supported in the perf tool later. Signed-off-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20230106160449.3566477-4-kan.liang@linux.intel.com
2023-01-09perf/x86/msr: Add Emerald RapidsKan Liang1-0/+1
The same as Sapphire Rapids, the SMI_COUNT MSR is also supported on Emerald Rapids. Add Emerald Rapids model. Signed-off-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20230106160449.3566477-3-kan.liang@linux.intel.com
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-22 05:30:04 +0000