kernel/linux.git/arch/sparc/include, branch v5.10.257

sparc: don't reference obsolete termio struct for TC* constants

2026-03-04T12:19:54+00:00

[ Upstream commit be0bccffcde3308150d2a90e55fc10e249098909 ] Similar in nature to commit ab107276607a ("powerpc: Fix struct termio related ioctl macros"). glibc-2.42 drops the legacy termio struct, but the ioctls.h header still defines some TC* constants in terms of termio (via sizeof). Hardcode the values instead. This fixes building Python for example, which falls over like: ./Modules/termios.c:1119:16: error: invalid application of 'sizeof' to incomplete type 'struct termio' Link: https://bugs.gentoo.org/961769 Link: https://bugs.gentoo.org/962600 Signed-off-by: Sam James Reviewed-by: Andreas Larsson Signed-off-by: Andreas Larsson Signed-off-by: Sasha Levin

sparc/module: Add R_SPARC_UA64 relocation handling

2025-12-06T21:08:14+00:00

[ Upstream commit 05457d96175d25c976ab6241c332ae2eb5e07833 ] This is needed so that the kernel can handle R_SPARC_UA64 relocations, which is emitted by LLVM's IAS. Signed-off-by: Koakuma Reviewed-by: Andreas Larsson Signed-off-by: Andreas Larsson Signed-off-by: Sasha Levin

sparc64: Fix incorrect function signature and add prototype for prom_cif_init

2024-08-19T03:40:51+00:00

[ Upstream commit a6c3ea1ec96307dbfbb2f16d96c674c5cc80f445 ] Remove the unused cif_stack argument and add a protype in oplib_64.h Commit ef3e035c3a9b ("sparc64: Fix register corruption in top-most kernel stack frame during boot.") removed the cif_stack argument to prom_cif init in the declaration at the caller site and the usage of it within prom_cif_init, but not in the function signature of the function itself. This also fixes the following warning: arch/sparc/prom/p1275.c:52:6: warning: no previous prototype for ‘prom_cif_init’ Fixes: ef3e035c3a9b ("sparc64: Fix register corruption in top-most kernel stack frame during boot.") Link: https://lore.kernel.org/r/20240710094155.458731-3-andreas@gaisler.com Signed-off-by: Andreas Larsson Signed-off-by: Sasha Levin

sparc: move struct termio to asm/termios.h

2024-06-16T11:32:36+00:00

commit c32d18e7942d7589b62e301eb426b32623366565 upstream. Every other arch declares struct termio in asm/termios.h, so make sparc match them. Resolves a build failure in the PPP software package, which includes both bits/ioctl-types.h via sys/ioctl.h (glibc) and asm/termbits.h. Closes: https://bugs.gentoo.org/918992 Signed-off-by: Mike Gilbert Cc: stable@vger.kernel.org Reviewed-by: Andreas Larsson Tested-by: Andreas Larsson Link: https://lore.kernel.org/r/20240306171149.3843481-1-floppym@gentoo.org Signed-off-by: Andreas Larsson Signed-off-by: Greg Kroah-Hartman

sparc64: Fix number of online CPUs

2024-06-16T11:32:35+00:00

commit 98937707fea8375e8acea0aaa0b68a956dd52719 upstream. Nick Bowler reported: When using newer kernels on my Ultra 60 with dual 450MHz UltraSPARC-II CPUs, I noticed that only CPU 0 comes up, while older kernels (including 4.7) are working fine with both CPUs. I bisected the failure to this commit: 9b2f753ec23710aa32c0d837d2499db92fe9115b is the first bad commit commit 9b2f753ec23710aa32c0d837d2499db92fe9115b Author: Atish Patra Date: Thu Sep 15 14:54:40 2016 -0600 sparc64: Fix cpu_possible_mask if nr_cpus is set This is a small change that reverts very easily on top of 5.18: there is just one trivial conflict. Once reverted, both CPUs work again. Maybe this is related to the fact that the CPUs on this system are numbered CPU0 and CPU2 (there is no CPU1)? The current code that adjust cpu_possible based on nr_cpu_ids do not take into account that CPU's may not come one after each other. Move the chech to the function that setup the cpu_possible mask so there is no need to adjust it later. Signed-off-by: Sam Ravnborg Fixes: 9b2f753ec237 ("sparc64: Fix cpu_possible_mask if nr_cpus is set") Reported-by: Nick Bowler Tested-by: Nick Bowler Link: https://lore.kernel.org/sparclinux/20201009161924.c8f031c079dd852941307870@gmx.de/ Link: https://lore.kernel.org/all/CADyTPEwt=ZNams+1bpMB1F9w_vUdPsGCt92DBQxxq_VtaLoTdw@mail.gmail.com/ Cc: stable@vger.kernel.org # v4.8+ Cc: Andreas Larsson Cc: David S. Miller Cc: Atish Patra Cc: Bob Picco Cc: Vijay Kumar Cc: David S. Miller Reviewed-by: Andreas Larsson Acked-by: Arnd Bergmann Link: https://lore.kernel.org/r/20240330-sparc64-warnings-v1-9-37201023ee2f@ravnborg.org Signed-off-by: Andreas Larsson Signed-off-by: Greg Kroah-Hartman

sparc/cpu: Switch to arch_cpu_finalize_init()

2023-08-08T17:57:37+00:00

commit 44ade508e3bfac45ae97864587de29eb1a881ec0 upstream check_bugs() is about to be phased out. Switch over to the new arch_cpu_finalize_init() implementation. No functional change. Signed-off-by: Thomas Gleixner Reviewed-by: Sam Ravnborg Link: https://lore.kernel.org/r/20230613224545.431995857@linutronix.de Signed-off-by: Daniel Sneddon Signed-off-by: Greg Kroah-Hartman

mm: rename p4d_page_vaddr to p4d_pgtable and make it return pud_t *

2023-07-27T06:43:58+00:00

[ Upstream commit dc4875f0e791de554bdc45aa1dbd6e45e107e50f ] No functional change in this patch. [aneesh.kumar@linux.ibm.com: m68k build error reported by kernel robot] Link: https://lkml.kernel.org/r/87tulxnb2v.fsf@linux.ibm.com Link: https://lkml.kernel.org/r/20210615110859.320299-2-aneesh.kumar@linux.ibm.com Link: https://lore.kernel.org/linuxppc-dev/CAHk-=wi+J+iodze9FtjM3Zi4j4OeS+qqbKxME9QN4roxPEXH9Q@mail.gmail.com/ Signed-off-by: Aneesh Kumar K.V Cc: Christophe Leroy Cc: Hugh Dickins Cc: Joel Fernandes Cc: Kalesh Singh Cc: Kirill A. Shutemov Cc: Michael Ellerman Cc: Nicholas Piggin Cc: Stephen Rothwell Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Stable-dep-of: 0da90af431ab ("powerpc/book3s64/mm: Fix DirectMap stats in /proc/meminfo") Signed-off-by: Sasha Levin

mm: rename pud_page_vaddr to pud_pgtable and make it return pmd_t *

2023-07-27T06:43:58+00:00

[ Upstream commit 9cf6fa2458443118b84090aa1bf7a3630b5940e8 ] No functional change in this patch. [aneesh.kumar@linux.ibm.com: fix] Link: https://lkml.kernel.org/r/87wnqtnb60.fsf@linux.ibm.com [sfr@canb.auug.org.au: another fix] Link: https://lkml.kernel.org/r/20210619134410.89559-1-aneesh.kumar@linux.ibm.com Link: https://lkml.kernel.org/r/20210615110859.320299-1-aneesh.kumar@linux.ibm.com Link: https://lore.kernel.org/linuxppc-dev/CAHk-=wi+J+iodze9FtjM3Zi4j4OeS+qqbKxME9QN4roxPEXH9Q@mail.gmail.com/ Signed-off-by: Aneesh Kumar K.V Signed-off-by: Stephen Rothwell Cc: Christophe Leroy Cc: Hugh Dickins Cc: Joel Fernandes Cc: Kalesh Singh Cc: Kirill A. Shutemov Cc: Michael Ellerman Cc: Nicholas Piggin Cc: Stephen Rothwell Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Stable-dep-of: 0da90af431ab ("powerpc/book3s64/mm: Fix DirectMap stats in /proc/meminfo") Signed-off-by: Sasha Levin

sparc: add support for TIF_NOTIFY_SIGNAL

2023-01-04T10:39:21+00:00

[ Upstream commit f50a7052f5e70ee7a6a5e2ed08660994dc3df2a5 ] Wire up TIF_NOTIFY_SIGNAL handling for sparc. Cc: sparclinux@vger.kernel.org Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman

sparc: use fallback for random_get_entropy() instead of zero

2022-05-30T07:33:42+00:00

commit ac9756c79797bb98972736b13cfb239fd2cffb79 upstream. In the event that random_get_entropy() can't access a cycle counter or similar, falling back to returning 0 is really not the best we can do. Instead, at least calling random_get_entropy_fallback() would be preferable, because that always needs to return _something_, even falling back to jiffies eventually. It's not as though random_get_entropy_fallback() is super high precision or guaranteed to be entropic, but basically anything that's not zero all the time is better than returning zero all the time. This is accomplished by just including the asm-generic code like on other architectures, which means we can get rid of the empty stub function here. Cc: Thomas Gleixner Cc: Arnd Bergmann Cc: David S. Miller Signed-off-by: Jason A. Donenfeld Signed-off-by: Greg Kroah-Hartman