summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2023-11-23x86/ioapic: Remove unfinished sentence from commentAdrian Huang
[ mingo: Refine changelog. ] Signed-off-by: Adrian Huang <ahuang12@lenovo.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: linux-kernel@vger.kernel.org
2023-11-23x86/io: Remove the unused 'bw' parameter from the BUILDIO() macroYuntao Wang
Commit 1e8f93e18379 ("x86: Consolidate port I/O helpers") moved some port I/O helpers to <asm/shared/io.h>, which caused the 'bw' parameter in the BUILDIO() macro to become unused. Remove it. Signed-off-by: Yuntao Wang <ytcoode@gmail.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20231123034911.217791-1-ytcoode@gmail.com
2023-11-23Merge branch 'asm-generic-io.h-cleanup' into asm-genericArnd Bergmann
MIPS is the last architecture that is yet to start using asm-generic/io.h, so Baoquan He converts it, which allows the other changes to remove code duplication, and it will allow further cleanups in the future. * asm-generic-io.h-cleanup: asm/io: remove unnecessary xlate_dev_mem_ptr() and unxlate_dev_mem_ptr() mips: io: remove duplicated codes arch/*/io.h: remove ioremap_uc in some architectures mips: add <asm-generic/io.h> including
2023-11-23hexagon: Remove CONFIG_HEXAGON_ARCH_VERSION from uapi headerThomas Huth
uapi headers should not expose CONFIG switches since they are not available in userspace. Fix it in arch/hexagon/include/uapi/asm/user.h by always defining the cs0 and cs1 entries instead of pad values. Suggested-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-11-23asm/io: remove unnecessary xlate_dev_mem_ptr() and unxlate_dev_mem_ptr()Kefeng Wang
The asm-generic/io.h already has default definition, remove unnecessary arch's defination. Cc: Richard Henderson <richard.henderson@linaro.org> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Russell King <linux@armlinux.org.uk> Cc: Brian Cain <bcain@quicinc.com> Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: Christophe Leroy <christophe.leroy@csgroup.eu> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Cc: Rich Felker <dalias@libc.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Stanislav Kinsburskii <stanislav.kinsburskii@gmail.com> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-11-23mips: io: remove duplicated codesBaoquan He
By adding <asm-generic/io.h> support, the duplicated phys_to_virt can be removed to use the default version in <asm-gneneric/io.h>. Meanwhile move isa_bus_to_virt() down below <asm-generic/io.h> including to fix the compiling error of missing phys_to_virt definition. Signed-off-by: Baoquan He <bhe@redhat.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Helge Deller <deller@gmx.de> Cc: Serge Semin <fancer.lancer@gmail.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: Huacai Chen <chenhuacai@kernel.org> Cc: Jiaxun Yang <jiaxun.yang@flygoat.com> Cc: linux-mips@vger.kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-11-23arch/*/io.h: remove ioremap_uc in some architecturesBaoquan He
ioremap_uc() is only meaningful on old x86-32 systems with the PAT extension, and on ia64 with its slightly unconventional ioremap() behavior. So remove the ioremap_uc() definition in architecutures other than x86 and ia64. These architectures all have asm-generic/io.h included and will have the default ioremap_uc() definition which returns NULL. This changes the existing behaviour, while no need to worry about any breakage because in the only callsite of ioremap_uc(), code has been adjusted to eliminate the impact. Please see atyfb_setup_generic() of drivers/video/fbdev/aty/atyfb_base.c. If any new invocation of ioremap_uc() need be added, please consider using ioremap() intead or adding a ARCH specific version if necessary. Signed-off-by: Baoquan He <bhe@redhat.com> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc) Acked-by: Helge Deller <deller@gmx.de> # parisc Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Acked-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> (SuperH) Cc: linux-alpha@vger.kernel.org Cc: linux-hexagon@vger.kernel.org Cc: linux-m68k@lists.linux-m68k.org Cc: linux-mips@vger.kernel.org Cc: linux-parisc@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-sh@vger.kernel.org Cc: sparclinux@vger.kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-11-23mips: add <asm-generic/io.h> includingJiaxun Yang
With the adding, some default ioremap_xx methods defined in asm-generic/io.h can be used. E.g the default ioremap_uc() returning NULL. We also massaged various headers to avoid nested includes. Signed-off-by: Baoquan He <bhe@redhat.com> Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> [jiaxun.yang@flygoat.com: Massage more headers, fix ioport defines] Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Huacai Chen <chenhuacai@kernel.org> Cc: linux-mips@vger.kernel.org Cc: linux-arch@vger.kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-11-23arm/xen: fix xen_vcpu_info allocation alignmentStefano Stabellini
xen_vcpu_info is a percpu area than needs to be mapped by Xen. Currently, it could cross a page boundary resulting in Xen being unable to map it: [ 0.567318] kernel BUG at arch/arm64/xen/../../arm/xen/enlighten.c:164! [ 0.574002] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Fix the issue by using __alloc_percpu and requesting alignment for the memory allocation. Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com> Link: https://lore.kernel.org/r/alpine.DEB.2.22.394.2311221501340.2053963@ubuntu-linux-20-04-desktop Fixes: 24d5373dda7c ("arm/xen: Use alloc_percpu rather than __alloc_percpu") Reviewed-by: Juergen Gross <jgross@suse.com> Signed-off-by: Juergen Gross <jgross@suse.com>
2023-11-22arm64: mm: Fix "rodata=on" when CONFIG_RODATA_FULL_DEFAULT_ENABLED=yWill Deacon
When CONFIG_RODATA_FULL_DEFAULT_ENABLED=y, passing "rodata=on" on the kernel command-line (rather than "rodata=full") should turn off the "full" behaviour, leaving writable linear aliases of read-only kernel memory. Unfortunately, the option has no effect in this situation and the only way to disable the "rodata=full" behaviour is to disable rodata protection entirely by passing "rodata=off". Fix this by parsing the "on" and "off" options in the arch code, additionally enforcing that 'rodata_full' cannot be set without also setting 'rodata_enabled', allowing us to simplify a couple of checks in the process. Fixes: 2e8cff0a0eee ("arm64: fix rodata=full") Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Will Deacon <will@kernel.org> Reviewed-by: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20231117131422.29663-1-will@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2023-11-22Merge tag 'loongarch-fixes-6.7-1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson Pull LoongArch fixes from Huacai Chen: "Fix several build errors, a potential kernel panic, a cpu hotplug issue and update links in documentations" * tag 'loongarch-fixes-6.7-1' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson: Docs/zh_CN/LoongArch: Update links in LoongArch introduction.rst Docs/LoongArch: Update links in LoongArch introduction.rst LoongArch: Implement constant timer shutdown interface LoongArch: Mark {dmw,tlb}_virt_to_page() exports as non-GPL LoongArch: Silence the boot warning about 'nokaslr' LoongArch: Add __percpu annotation for __percpu_read()/__percpu_write() LoongArch: Record pc instead of offset in la_abs relocation LoongArch: Explicitly set -fdirect-access-external-data for vmlinux LoongArch: Add dependency between vmlinuz.efi and vmlinux.efi
2023-11-22x86/mce/inject: Clear test status valueYazen Ghannam
AMD systems generally allow MCA "simulation" where MCA registers can be written with valid data and the full MCA handling flow can be tested by software. However, the platform on Scalable MCA systems, can prevent software from writing data to the MCA registers. There is no architectural way to determine this configuration. Therefore, the MCE injection module will check for this behavior by writing and reading back a test status value. This is done during module init, and the check can run on any CPU with any valid MCA bank. If MCA_STATUS writes are ignored by the platform, then there are no side effects on the hardware state. If the writes are not ignored, then the test status value will remain in the hardware MCA_STATUS register. It is likely that the value will not be overwritten by hardware or software, since the tested CPU and bank are arbitrary. Therefore, the user may see a spurious, synthetic MCA error reported whenever MCA is polled for this CPU. Clear the test value immediately after writing it. It is very unlikely that a valid MCA error is logged by hardware during the test. Errors that cause an #MC won't be affected. Fixes: 891e465a1bd8 ("x86/mce: Check whether writes to MCA_STATUS are getting ignored") Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20231118193248.1296798-2-yazen.ghannam@amd.com
2023-11-22Merge tag 'hyperv-fixes-signed-20231121' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux Pull hyperv fixes from Wei Liu: - One fix for the KVP daemon (Ani Sinha) - Fix for the detection of E820_TYPE_PRAM in a Gen2 VM (Saurabh Sengar) - Micro-optimization for hv_nmi_unknown() (Uros Bizjak) * tag 'hyperv-fixes-signed-20231121' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux: x86/hyperv: Use atomic_try_cmpxchg() to micro-optimize hv_nmi_unknown() x86/hyperv: Fix the detection of E820_TYPE_PRAM in a Gen2 VM hv/hv_kvp_daemon: Some small fixes for handling NM keyfiles
2023-11-22s390/boot: always align vmalloc area on segment boundaryAlexander Gordeev
The size of vmalloc area depends from various factors on boot and could be set to: 1. Default size as determined by VMALLOC_DEFAULT_SIZE macro; 2. One half of the virtual address space not occupied by modules and fixed mappings; 3. The size provided by user with vmalloc= kernel command line parameter; In cases [1] and [2] the vmalloc area base address is aligned on Region3 table type boundary, while in case [3] in might get aligned on page boundary. Limit the waste of page tables and always align vmalloc area size and base address on segment boundary. Acked-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2023-11-22s390/sysinfo: add variable capacity informationVasily Gorbik
If available, add machine variable capacity information to /proc/sysinfo Acked-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2023-11-22s390: remove odd commentHeiko Carstens
In the meantime hopefully most people got used to forward declarations, therefore remove the explanation. Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2023-11-22s390/ipl: add missing IPL_TYPE_ECKD_DUMP case to ipl_init()Mikhail Zaslonko
Add missing IPL_TYPE_ECKD_DUMP case to ipl_init() creating ECKD ipl device attribute group similar to IPL_TYPE_ECKD case. Commit e2d2a2968f2a ("s390/ipl: add eckd dump support") should have had it from the beginning. Fixes: e2d2a2968f2a ("s390/ipl: add eckd dump support") Signed-off-by: Mikhail Zaslonko <zaslonko@linux.ibm.com> Reviewed-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2023-11-22s390/pai: cleanup event initializationThomas Richter
Setting event::hw.last_tag to zero is not necessary. The memory for each event is dynamically allocated by the kernel common code and initialized to zero already. Remove this unnecessary assignment. Move the comment to function paicrypt_start() for clarification. Suggested-by: Sumanth Korikkar <sumanthk@linux.ibm.com> Acked-by: Sumanth Korikkar <sumanthk@linux.ibm.com> Signed-off-by: Thomas Richter <tmricht@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2023-11-22x86/hyperv: Use atomic_try_cmpxchg() to micro-optimize hv_nmi_unknown()Uros Bizjak
Use atomic_try_cmpxchg() instead of atomic_cmpxchg(*ptr, old, new) == old in hv_nmi_unknown(). On x86 the CMPXCHG instruction returns success in the ZF flag, so this change saves a compare after CMPXCHG. The generated asm code improves from: 3e: 65 8b 15 00 00 00 00 mov %gs:0x0(%rip),%edx 45: b8 ff ff ff ff mov $0xffffffff,%eax 4a: f0 0f b1 15 00 00 00 lock cmpxchg %edx,0x0(%rip) 51: 00 52: 83 f8 ff cmp $0xffffffff,%eax 55: 0f 95 c0 setne %al to: 3e: 65 8b 15 00 00 00 00 mov %gs:0x0(%rip),%edx 45: b8 ff ff ff ff mov $0xffffffff,%eax 4a: f0 0f b1 15 00 00 00 lock cmpxchg %edx,0x0(%rip) 51: 00 52: 0f 95 c0 setne %al No functional change intended. Cc: "K. Y. Srinivasan" <kys@microsoft.com> Cc: Haiyang Zhang <haiyangz@microsoft.com> Cc: Wei Liu <wei.liu@kernel.org> Cc: Dexuan Cui <decui@microsoft.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by: Uros Bizjak <ubizjak@gmail.com> Reviewed-by: Michael Kelley <mhklinux@outlook.com> Link: https://lore.kernel.org/r/20231114170038.381634-1-ubizjak@gmail.com Signed-off-by: Wei Liu <wei.liu@kernel.org> Message-ID: <20231114170038.381634-1-ubizjak@gmail.com>
2023-11-21x86/apic: Drop struct local_apicAndrew Cooper
This type predates recorded history in tglx/history.git, making it older than Feb 5th 2002. This structure is literally old enough to drink in most juristictions in the world, and has not been used once in that time. Lay it to rest in /dev/null. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Steve Wahl <steve.wahl@hpe.com> Link: https://lore.kernel.org/r/20231102-x86-apic-v1-3-bf049a2a0ed6@citrix.com
2023-11-21x86/apic: Drop enum apic_delivery_modesAndrew Cooper
The type is not used any more. Replace the constants with plain defines so they can live outside of an __ASSEMBLY__ block, allowing for more cleanup in subsequent changes. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Steve Wahl <steve.wahl@hpe.com> Link: https://lore.kernel.org/r/20231102-x86-apic-v1-2-bf049a2a0ed6@citrix.com
2023-11-21x86/apic: Drop apic::delivery_modeAndrew Cooper
This field is set to APIC_DELIVERY_MODE_FIXED in all cases, and is read exactly once. Fold the constant in uv_program_mmr() and drop the field. Searching for the origin of the stale HyperV comment reveals commit a31e58e129f7 ("x86/apic: Switch all APICs to Fixed delivery mode") which notes: As a consequence of this change, the apic::irq_delivery_mode field is now pointless, but this needs to be cleaned up in a separate patch. 6 years is long enough for this technical debt to have survived. [ bp: Fold in https://lore.kernel.org/r/20231121123034.1442059-1-andrew.cooper3@citrix.com ] Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Steve Wahl <steve.wahl@hpe.com> Link: https://lore.kernel.org/r/20231102-x86-apic-v1-1-bf049a2a0ed6@citrix.com
2023-11-21x86/microcode: Rework early revisions reportingBorislav Petkov (AMD)
The AMD side of the loader issues the microcode revision for each logical thread on the system, which can become really noisy on huge machines. And doing that doesn't make a whole lot of sense - the microcode revision is already in /proc/cpuinfo. So in case one is interested in the theoretical support of mixed silicon steppings on AMD, one can check there. What is also missing on the AMD side - something which people have requested before - is showing the microcode revision the CPU had *before* the early update. So abstract that up in the main code and have the BSP on each vendor provide those revision numbers. Then, dump them only once on driver init. On Intel, do not dump the patch date - it is not needed. Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/CAHk-=wg=%2B8rceshMkB4VnKxmRccVLtBLPBawnewZuuqyx5U=3A@mail.gmail.com
2023-11-21x86/microcode: Remove the driver announcement and versionBorislav Petkov (AMD)
First of all, the print is useless. The driver will either load and say which microcode revision the machine has or issue an error. Then, the version number is meaningless and actively confusing, as Yazen mentioned recently: when a subset of patches are backported to a distro kernel, one can't assume the driver version is the same as the upstream one. And besides, the version number of the loader hasn't been used and incremented for a long time. So drop it. Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20231115210212.9981-2-bp@alien8.de
2023-11-21ARM: dts: stm32: add SPI support on STM32F746Ben Wolsieffer
Add device tree nodes for the STM32F746 SPI controllers. Signed-off-by: Ben Wolsieffer <ben.wolsieffer@hefring.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2023-11-21ARM: dts: stm32: add STM32F746 syscfg clockBen Wolsieffer
The syscfg syscon was missing its clock, therefore any attempt to read/write it after clk_disable_unused() silently failed. This was preventing external pin interrupts from working if they were initialized after this point. Signed-off-by: Ben Wolsieffer <ben.wolsieffer@hefring.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2023-11-22powerpc/rtas: Remove 'extern' from function declarations in rtas.hNathan Lynch
This header occasionally gains new function declarations without the leading extern in accordance with current style rules. Leaving the legacy externs in place is making the header more difficult to read over time because of the inconsistency. Remove them. Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com> [mpe: Add names to rtas_call() parameters] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20231106-rtas-trivial-v1-7-61847655c51f@linux.ibm.com
2023-11-21x86/entry: Harden return-to-userPeter Zijlstra
Make the CONFIG_DEBUG_ENTRY=y check that validates CS is a user segment unconditional and move it nearer to IRET. PRE: 140,026,608 cycles:k ( +- 0.01% ) 236,696,176 instructions:k # 1.69 insn per cycle ( +- 0.00% ) POST: 139,957,681 cycles:k ( +- 0.01% ) 236,681,819 instructions:k # 1.69 insn per cycle ( +- 0.00% ) (this is with --repeat 100 and the run-to-run variance is bigger than the difference shown) Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/20231120143626.753200755@infradead.org
2023-11-21x86/entry: Optimize common_interrupt_return()Peter Zijlstra
The code in common_interrupt_return() does a bunch of unconditional work that is really only needed on PTI kernels. Specifically it unconditionally copies the IRET frame back onto the entry stack, swizzles onto the entry stack and does IRET from there. However, without PTI we can simply IRET from whatever stack we're on. ivb-ep, mitigations=off, gettid-1m: PRE: 140,118,538 cycles:k ( +- 0.01% ) 236,692,878 instructions:k # 1.69 insn per cycle ( +- 0.00% ) POST: 140,026,608 cycles:k ( +- 0.01% ) 236,696,176 instructions:k # 1.69 insn per cycle ( +- 0.00% ) (this is with --repeat 100 and the run-to-run variance is bigger than the difference shown) Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/20231120143626.638107480@infradead.org
2023-11-21perf/x86/intel: Correct incorrect 'or' operation for PMU capabilitiesDapeng Mi
When running perf-stat command on Intel hybrid platform, perf-stat reports the following errors: sudo taskset -c 7 ./perf stat -vvvv -e cpu_atom/instructions/ sleep 1 Opening: cpu/cycles/:HG ------------------------------------------------------------ perf_event_attr: type 0 (PERF_TYPE_HARDWARE) config 0xa00000000 disabled 1 ------------------------------------------------------------ sys_perf_event_open: pid 0 cpu -1 group_fd -1 flags 0x8 sys_perf_event_open failed, error -16 Performance counter stats for 'sleep 1': <not counted> cpu_atom/instructions/ It looks the cpu_atom/instructions/ event can't be enabled on atom PMU even when the process is pinned on atom core. Investigation shows that exclusive_event_init() helper always returns -EBUSY error in the perf event creation. That's strange since the atom PMU should not be an exclusive PMU. Further investigation shows the issue was introduced by commit: 97588df87b56 ("perf/x86/intel: Add common intel_pmu_init_hybrid()") The commit originally intents to clear the bit PERF_PMU_CAP_AUX_OUTPUT from PMU capabilities if intel_cap.pebs_output_pt_available is not set, but it incorrectly uses 'or' operation and leads to all PMU capabilities bits are set to 1 except bit PERF_PMU_CAP_AUX_OUTPUT. Testing this fix on Intel hybrid platforms, the observed issues disappear. Fixes: 97588df87b56 ("perf/x86/intel: Add common intel_pmu_init_hybrid()") Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20231121014628.729989-1-dapeng1.mi@linux.intel.com
2023-11-21LoongArch: Implement constant timer shutdown interfaceBibo Mao
When a cpu is hot-unplugged, it is put in idle state and the function arch_cpu_idle_dead() is called. The timer interrupt for this processor should be disabled, otherwise there will be pending timer interrupt for the unplugged cpu, so that vcpu is prevented from giving up scheduling when system is running in vm mode. This patch implements the timer shutdown interface so that the constant timer will be properly disabled when a CPU is hot-unplugged. Reviewed-by: WANG Xuerui <git@xen0n.name> Signed-off-by: Bibo Mao <maobibo@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2023-11-21LoongArch: Mark {dmw,tlb}_virt_to_page() exports as non-GPLHuacai Chen
Mark {dmw,tlb}_virt_to_page() exports as non-GPL, in order to let out-of-tree modules (e.g. OpenZFS) be built without errors. Otherwise we get: ERROR: modpost: GPL-incompatible module zfs.ko uses GPL-only symbol 'dmw_virt_to_page' ERROR: modpost: GPL-incompatible module zfs.ko uses GPL-only symbol 'tlb_virt_to_page' Reported-by: Haowu Ge <gehaowu@bitmoe.com> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2023-11-21LoongArch: Silence the boot warning about 'nokaslr'Huacai Chen
The kernel parameter 'nokaslr' is handled before start_kernel(), so we don't need early_param() to mark it technically. But it can cause a boot warning as follows: Unknown kernel command line parameters "nokaslr", will be passed to user space. When we use 'init=/bin/bash', 'nokaslr' which passed to user space will even cause a kernel panic. So we use early_param() to mark 'nokaslr', simply print a notice and silence the boot warning (also fix a potential panic). This logic is similar to RISC-V. Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2023-11-21LoongArch: Add __percpu annotation for __percpu_read()/__percpu_write()Huacai Chen
When build kernel with C=1, we get: arch/loongarch/kernel/process.c:234:46: warning: incorrect type in argument 1 (different address spaces) arch/loongarch/kernel/process.c:234:46: expected void *ptr arch/loongarch/kernel/process.c:234:46: got unsigned long [noderef] __percpu * arch/loongarch/kernel/process.c:234:46: warning: incorrect type in argument 1 (different address spaces) arch/loongarch/kernel/process.c:234:46: expected void *ptr arch/loongarch/kernel/process.c:234:46: got unsigned long [noderef] __percpu * arch/loongarch/kernel/process.c:234:46: warning: incorrect type in argument 1 (different address spaces) arch/loongarch/kernel/process.c:234:46: expected void *ptr arch/loongarch/kernel/process.c:234:46: got unsigned long [noderef] __percpu * arch/loongarch/kernel/process.c:234:46: warning: incorrect type in argument 1 (different address spaces) arch/loongarch/kernel/process.c:234:46: expected void *ptr arch/loongarch/kernel/process.c:234:46: got unsigned long [noderef] __percpu * Add __percpu annotation for __percpu_read()/__percpu_write() can avoid such warnings. __percpu_xchg() and other functions don't need annotation because their wrapper, i.e. _pcp_protect(), already suppresses warnings. Also adjust the indentations in this file. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202311080409.LlOfTR3m-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202311080840.Vc2kXhfp-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202311081340.3k72KKdg-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202311120926.cjYHyoYw-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202311152142.g6UyNx1R-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202311160339.DbhaH8LX-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202311181454.CTPrSYmQ-lkp@intel.com/ Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2023-11-21LoongArch: Record pc instead of offset in la_abs relocationWANG Rui
To clarify, the previous version functioned flawlessly. However, it's worth noting that the LLVM's LoongArch backend currently lacks support for cross-section label calculations. With this patch, we enable the use of clang to compile relocatable kernels. Tested-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: WANG Rui <wangrui@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2023-11-21LoongArch: Explicitly set -fdirect-access-external-data for vmlinuxWANG Rui
After this llvm commit [1], The -fno-pic does not imply direct access external data. Explicitly set -fdirect-access-external-data for vmlinux that can avoids GOT entries. Link: https://github.com/llvm/llvm-project/commit/47eeee297775347cbdb7624d6a766c2a3eec4a59 Suggested-by: Xi Ruoyao <xry111@xry111.site> Signed-off-by: WANG Rui <wangrui@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2023-11-21LoongArch: Add dependency between vmlinuz.efi and vmlinux.efiMasahiro Yamada
A common issue in Makefile is a race in parallel building. You need to be careful to prevent multiple threads from writing to the same file simultaneously. Commit 3939f3345050 ("ARM: 8418/1: add boot image dependencies to not generate invalid images") addressed such a bad scenario. A similar symptom occurs with the following command: $ make -j$(nproc) ARCH=loongarch vmlinux.efi vmlinuz.efi [ snip ] SORTTAB vmlinux OBJCOPY arch/loongarch/boot/vmlinux.efi OBJCOPY arch/loongarch/boot/vmlinux.efi PAD arch/loongarch/boot/vmlinux.bin GZIP arch/loongarch/boot/vmlinuz OBJCOPY arch/loongarch/boot/vmlinuz.o LD arch/loongarch/boot/vmlinuz.efi.elf OBJCOPY arch/loongarch/boot/vmlinuz.efi The log "OBJCOPY arch/loongarch/boot/vmlinux.efi" is displayed twice. It indicates that two threads simultaneously enter arch/loongarch/boot/ and write to arch/loongarch/boot/vmlinux.efi. It occasionally leads to a build failure: $ make -j$(nproc) ARCH=loongarch vmlinux.efi vmlinuz.efi [ snip ] SORTTAB vmlinux OBJCOPY arch/loongarch/boot/vmlinux.efi PAD arch/loongarch/boot/vmlinux.bin truncate: Invalid number: ‘arch/loongarch/boot/vmlinux.bin’ make[2]: *** [drivers/firmware/efi/libstub/Makefile.zboot:13: arch/loongarch/boot/vmlinux.bin] Error 1 make[2]: *** Deleting file 'arch/loongarch/boot/vmlinux.bin' make[1]: *** [arch/loongarch/Makefile:146: vmlinuz.efi] Error 2 make[1]: *** Waiting for unfinished jobs.... make: *** [Makefile:234: __sub-make] Error 2 vmlinuz.efi depends on vmlinux.efi, but such a dependency is not specified in arch/loongarch/Makefile. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2023-11-21powerpc/rtas: Remove trailing spaceNathan Lynch
Use scripts/cleanfile to remove instances of trailing space in the core RTAS code and header. Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20231106-rtas-trivial-v1-6-61847655c51f@linux.ibm.com
2023-11-21powerpc/rtas: Move post_mobility_fixup() declaration to pseriesNathan Lynch
This is a pseries-specific function declaration that doesn't belong in rtas.h. Move it to the pseries platform code and adjust pseries/suspend.c accordingly. Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20231106-rtas-trivial-v1-5-61847655c51f@linux.ibm.com
2023-11-21powerpc/rtas: Remove unused rtas_service_present()Nathan Lynch
rtas_service_present() has no more users. rtas_function_implemented() is now the appropriate API for determining whether a given RTAS function is available to call. Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20231106-rtas-trivial-v1-4-61847655c51f@linux.ibm.com
2023-11-21powerpc/rtas: Drop declaration of undefined call_rtas() functionNathan Lynch
The call_rtas() function has never been a part of arch/powerpc, and its implementation was removed from arch/ppc by 0a26b1364f14 ("ppc: Remove CHRP, POWER3 and POWER4 support from arch/ppc"). Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20231106-rtas-trivial-v1-3-61847655c51f@linux.ibm.com
2023-11-21powerpc/powermac: mark smp_psurge_{give,take}_timebase staticArnd Bergmann
These functions are only called locally and should be static like the other corresponding functions are: arch/powerpc/platforms/powermac/smp.c:416:13: error: no previous prototype for 'smp_psurge_take_timebase' [-Werror=missing-prototypes] 416 | void __init smp_psurge_take_timebase(void) | ^~~~~~~~~~~~~~~~~~~~~~~~ arch/powerpc/platforms/powermac/smp.c:432:13: error: no previous prototype for 'smp_psurge_give_timebase' [-Werror=missing-prototypes] 432 | void __init smp_psurge_give_timebase(void) | ^~~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20231108125843.3806765-20-arnd@kernel.org
2023-11-21powerpc/pasemi: mark pas_shutdown() staticArnd Bergmann
Allmodconfig builds show a warning about one function that is accidentally marked global: arch/powerpc/platforms/pasemi/setup.c:67:6: error: no previous prototype for 'pas_shutdown' [-Werror=missing-prototypes] Fixes: 656fdf3ad8e0 ("powerpc/pasemi: Add Nemo board device init code.") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20231108125843.3806765-19-arnd@kernel.org
2023-11-21powerpc/ps3: move udbg_shutdown_ps3gelic prototypeArnd Bergmann
Allmodconfig kernels produce a missing-prototypes warning: arch/powerpc/platforms/ps3/gelic_udbg.c:239:6: error: no previous prototype for 'udbg_shutdown_ps3gelic' [-Werror=missing-prototypes] Move the declaration from a local header to asm/ps3.h where it can be seen from both the caller and the definition. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Geoff Levand <geoff@infradead.org> Acked-by: Jakub Kicinski <kuba@kernel.org> [mpe: Drop CONFIG_PS3GELIC_UDBG to fix build error] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20231108125843.3806765-18-arnd@kernel.org
2023-11-20KVM: arm64: GICv4: Do not perform a map to a mapped vLPIKunkun Jiang
Before performing a map, let's check whether the vLPI has been mapped. Fixes: 196b136498b3 ("KVM: arm/arm64: GICv4: Wire mapping/unmapping of VLPIs in VFIO irq bypass") Signed-off-by: Kunkun Jiang <jiangkunkun@huawei.com> Acked-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Zenghui Yu <yuzenghui@huawei.com> Link: https://lore.kernel.org/r/20231120131210.2039-1-jiangkunkun@huawei.com Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2023-11-20ARM: dts: stm32: use the same 3v3 for SD and DSI nodes on stm32f469-discoDario Binacchi
In the board schematic, the power supply for the SD card is the same 3.3 volts used to power the LCD panel and other peripherals. By generalizing the name of the voltage regulator, it simplifies the device tree and makes it more readable. Link: https://www.st.com/en/evaluation-tools/32f469idiscovery.html#cad-resources Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2023-11-20ARM: dts: rockchip: Make usbphy the parent of SCLK_USB480M for RK3128Alex Bee
Without setting the parent for SCLK_USB480M the clock will use xin24m as it's default parent. While this is generally not an issue for the usb blocks to work, it becomes an issue for RK3128 since SCLK_USB480M can be a parent for other HW blocks (GPU, VPU, VIO), but they will never chose it, since it is currently always running at OSC frequency which is to slow for their needs. This sets the usb2 phy's output as SCLK_USB480M's parent and it's users can chose it if desired. Signed-off-by: Alex Bee <knaerzche@gmail.com> Link: https://lore.kernel.org/r/20231119121340.109025-6-knaerzche@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2023-11-20ARM: dts: rockchip: Add dwc2 otg fifo siztes for RK3128Alex Bee
The driver currently won't probe correctly if those values are missing. They have been taken from dowstream kernel and match those of other Rockchip SoCs. Signed-off-by: Alex Bee <knaerzche@gmail.com> Link: https://lore.kernel.org/r/20231119121340.109025-5-knaerzche@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2023-11-20ARM: dts: rockchip: Add USB host clocks for RK3128Alex Bee
Add the required AHB clocks for both the ehci and ohci controller. Signed-off-by: Alex Bee <knaerzche@gmail.com> Link: https://lore.kernel.org/r/20231119121340.109025-4-knaerzche@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2023-11-20ARM: dts: rockchip: Add Geniatech XPI-3128 RK3128 boardAlex Bee
XPI-3128 is RK3128 based SBC form Geniatec in RPi form factor Specs: - Rockchip RK3128 - 512MB/1 GB DDR3 DRAM - 8/16 GB eMMC - TF card slot - 100 MBit ethernet / RJ45 (TI DP83848C phy) - optional Marvell 88W8897 (USB version) - 3 x USB host (onboard GL852G hub connected to SoC ehci host) - 1 x USB otg - 1 x Type-C (solely for powering the board) - HDMI 1.4 out - ADC button - IR receiver - Artasie AM1805 RTC - 40 pin header Signed-off-by: Alex Bee <knaerzche@gmail.com> Link: https://lore.kernel.org/r/20231119130351.112261-8-knaerzche@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
generated by cgit (git 2.34.1) at 2025-09-22 03:03:26 +0000