summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-03-11xfs: fix integer overflow in bmap intent sort comparatorLong Li
xfs_bmap_update_diff_items() sorts bmap intents by inode number using a subtraction of two xfs_ino_t (uint64_t) values, with the result truncated to int. This is incorrect when two inode numbers differ by more than INT_MAX (2^31 - 1), which is entirely possible on large XFS filesystems. Fix this by replacing the subtraction with cmp_int(). Cc: <stable@vger.kernel.org> # v4.9 Fixes: 9f3afb57d5f1 ("xfs: implement deferred bmbt map/unmap operations") Signed-off-by: Long Li <leo.lilong@huawei.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
2026-03-11intel_idle: Add Panther Lake C-states tableArtem Bityutskiy
Panther Lake supports the following requestable C-states: C1, C1E, C6S, C10. The parameters of these C-states should be consistent across all systems based on Panther Lake, so add a custom C-states table for it that will override C-state parameters supplied by platform firmware that may vary from one platform to another and may not represent the most optimum choice. Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> [ rjw: Changelog expansion ] Link: https://patch.msgid.link/20260309083818.79588-1-dedekind1@gmail.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-03-11spi: dt-bindings: sun6i: Allow Dual SPI and Quad SPI for newer SoCsChen-Yu Tsai
Support for Dual SPI and Quad SPI was added to the Linux driver in commit 0605d9fb411f ("spi: sun6i: add quirk for dual and quad SPI modes support") and commit 25453d797d7a ("spi: sun6i: add dual and quad SPI modes support for R329/D1/R528/T113s"). However the binding was never updated to allow these modes. Allow them by adding 2 and 4 to the allowed bus widths for the newer variants. While at it, also add 0 to the allowed bus widths. This signals that RX or TX is not available, i.e. the MISO or MOSI pin is disconnected. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Chen-Yu Tsai <wens@kernel.org> Link: https://patch.msgid.link/20260302153559.3199783-2-wens@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2026-03-11ACPI: CPPC: Fix uninitialized ref variable in cppc_get_perf_caps()Pengjie Zhang
Commit 8505bfb4e4ec ("ACPI: CPPC: Move reference performance to capabilities") introduced a logical error when retrieving the reference performance. On platforms lacking the reference performance register, the fallback logic leaves the local 'ref' variable uninitialized (0). This causes the subsequent sanity check to incorrectly return -EFAULT, breaking amd_pstate initialization. Fix this by assigning 'ref = nom' in the fallback path. Fixes: 8505bfb4e4ec ("ACPI: CPPC: Move reference performance to capabilities") Reported-by: Nathan Chancellor <nathan@kernel.org> Closes: https://lore.kernel.org/all/20260310003026.GA2639793@ax162/ Tested-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Pengjie Zhang <zhangpengjie2@huawei.com> [ rjw: Subject tweak ] Link: https://patch.msgid.link/20260311071334.1494960-1-zhangpengjie2@huawei.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-03-11ACPI: OSL: fix __iomem type on return from acpi_os_map_generic_address()Ben Dooks
The pointer returned from acpi_os_map_generic_address() is tagged with __iomem, so make the rv it is returned to also of void __iomem * type. Fixes the following sparse warning: drivers/acpi/osl.c:1686:20: warning: incorrect type in assignment (different address spaces) drivers/acpi/osl.c:1686:20: expected void *rv drivers/acpi/osl.c:1686:20: got void [noderef] __iomem * Fixes: 6915564dc5a8 ("ACPI: OSL: Change the type of acpi_os_map_generic_address() return value") Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> [ rjw: Subject tweak, added Fixes tag ] Link: https://patch.msgid.link/20260311105835.463030-1-ben.dooks@codethink.co.uk Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-03-11sched/mmcid: Avoid full tasklist walksThomas Gleixner
Chasing vfork()'ed tasks on a CID ownership mode switch requires a full task list walk, which is obviously expensive on large systems. Avoid that by keeping a list of tasks using a mm MMCID entity in mm::mm_cid and walk this list instead. This removes the proven to be flaky counting logic and avoids a full task list walk in the case of vfork()'ed tasks. Fixes: fbd0e71dc370 ("sched/mmcid: Provide CID ownership mode fixup functions") Signed-off-by: Thomas Gleixner <tglx@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260310202526.183824481@kernel.org
2026-03-11sched/mmcid: Remove pointless preempt guardThomas Gleixner
This is a leftover from the early versions of this function where it could be invoked without mm::mm_cid::lock held. Remove it and add lockdep asserts instead. Fixes: 653fda7ae73d ("sched/mmcid: Switch over to the new mechanism") Signed-off-by: Thomas Gleixner <tglx@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260310202526.116363613@kernel.org
2026-03-11sched/mmcid: Handle vfork()/CLONE_VM correctlyThomas Gleixner
Matthieu and Jiri reported stalls where a task endlessly loops in mm_get_cid() when scheduling in. It turned out that the logic which handles vfork()'ed tasks is broken. It is invoked when the number of tasks associated to a process is smaller than the number of MMCID users. It then walks the task list to find the vfork()'ed task, but accounts all the already processed tasks as well. If that double processing brings the number of to be handled tasks to 0, the walk stops and the vfork()'ed task's CID is not fixed up. As a consequence a subsequent schedule in fails to acquire a (transitional) CID and the machine stalls. Cure this by removing the accounting condition and make the fixup always walk the full task list if it could not find the exact number of users in the process' thread list. Fixes: fbd0e71dc370 ("sched/mmcid: Provide CID ownership mode fixup functions") Closes: https://lore.kernel.org/b24ffcb3-09d5-4e48-9070-0b69bc654281@kernel.org Reported-by: Matthieu Baerts <matttbe@kernel.org> Reported-by: Jiri Slaby <jirislaby@kernel.org> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260310202526.048657665@kernel.org
2026-03-11sched/mmcid: Prevent CID stalls due to concurrent forksThomas Gleixner
A newly forked task is accounted as MMCID user before the task is visible in the process' thread list and the global task list. This creates the following problem: CPU1 CPU2 fork() sched_mm_cid_fork(tnew1) tnew1->mm.mm_cid_users++; tnew1->mm_cid.cid = getcid() -> preemption fork() sched_mm_cid_fork(tnew2) tnew2->mm.mm_cid_users++; // Reaches the per CPU threshold mm_cid_fixup_tasks_to_cpus() for_each_other(current, p) .... As tnew1 is not visible yet, this fails to fix up the already allocated CID of tnew1. As a consequence a subsequent schedule in might fail to acquire a (transitional) CID and the machine stalls. Move the invocation of sched_mm_cid_fork() after the new task becomes visible in the thread and the task list to prevent this. This also makes it symmetrical vs. exit() where the task is removed as CID user before the task is removed from the thread and task lists. Fixes: fbd0e71dc370 ("sched/mmcid: Provide CID ownership mode fixup functions") Signed-off-by: Thomas Gleixner <tglx@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260310202525.969061974@kernel.org
2026-03-11Merge v7.0-rc3 into drm-nextSimona Vetter
Requested by Maxime Ripard for drm-misc-next because renesas people need fb797a70108f ("drm: renesas: rz-du: mipi_dsi: Set DSI divider"). Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch>
2026-03-11Merge tag 'stratix10_svc_fix_for_v7.0' of ↵Greg Kroah-Hartman
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux into char-misc-linus Dinh writes: firmware: stratix10-svc: add multiple svc clients support - Add a dedicated thread for each svc client to fix a timeout issue when the svc driver is handling multiple clients. * tag 'stratix10_svc_fix_for_v7.0' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux: firmware: stratix10-svc: Add Multi SVC clients support
2026-03-11power: supply: add support for S2MU005 battery fuel gauge deviceYassine Oudjana
Samsung's S2MU005 PMIC, which contains battery charger functionality also includes a battery fuel gauge device, which is separate from the PMIC itself, and typically connected to an I2C bus. Add a generic driver to support said device. Signed-off-by: Yassine Oudjana <y.oudjana@protonmail.com> Co-developed-by: Kaustabh Chakraborty <kauschluss@disroot.org> Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org> Link: https://patch.msgid.link/20260304-s2mu005-fuelgauge-v3-2-e4dc4e47cde8@disroot.org [Moved mutex init before power-supply registration] Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-03-11dt-bindings: power: supply: document Samsung S2MU005 battery fuel gaugeKaustabh Chakraborty
Samsung S2MU005 is a PMIC device which has LED controllers, an MUIC and a battery charger. The battery charger is paired with an independent device connected via I2C which can be used to access various metrics of the battery. Document the device as a schema. Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org> Link: https://patch.msgid.link/20260304-s2mu005-fuelgauge-v3-1-e4dc4e47cde8@disroot.org Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-03-11time/jiffies: Mark jiffies_64_to_clock_t() notraceSteven Rostedt
The trace_clock_jiffies() function that handles the "uptime" clock for tracing calls jiffies_64_to_clock_t(). This causes the function tracer to constantly recurse when the tracing clock is set to "uptime". Mark it notrace to prevent unnecessary recursion when using the "uptime" clock. Fixes: 58d4e21e50ff3 ("tracing: Fix wraparound problems in "uptime" trace clock") Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260306212403.72270bb2@robin
2026-03-11drm/i915/frontbuffer: reduce fb for frontbuffer abbreviation usageJani Nikula
Using fb for frontbuffer is a bit misleading, as framebuffer is the more common fb. Reduce fb usage in frontbuffer function naming. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patch.msgid.link/f7f04d63771891d1c3b1aa280485437bc4a70f20.1772475391.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-03-11drm/i915/frontbuffer: call parent interface directlyJani Nikula
Do away with the redundant intel_frontbuffer_get(), intel_frontbuffer_put(), and intel_frontbuffer_ref() functions, and call the parent interface functions directly. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patch.msgid.link/7451574d6840fe9a4af16d2d6b81ffb7739b5b76.1772475391.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-03-11drm/{i915, xe}/frontbuffer: move frontbuffer handling to parent interfaceJani Nikula
Move the get/put/ref/flush_for_display calls to the display parent interface. For i915, move the hooks next to the other i915 core frontbuffer code in i915_gem_object_frontbuffer.c. For xe, add new file xe_frontbuffer.c for the same. Note: The intel_frontbuffer_flush() calls from i915_gem_object_frontbuffer.c will partially route back to i915 core via the parent interface. This is less than stellar. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patch.msgid.link/f69b967ed82bbcfd60ffa77ba197b26a1399f09f.1772475391.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-03-11drm/intel: fix @dpt kernel-doc for parent interfaceJani Nikula
Fix the copy-paste fail. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patch.msgid.link/0209e128312520ca1c6a0c39f9dfb0184125322a.1772475391.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-03-11drm/i915/overlay: convert from struct intel_frontbuffer to i915_frontbufferJani Nikula
The intel_frontbuffer_get() and intel_frontbuffer_put() calls are routed through intel_frontbuffer.c to i915_gem_object_frontbuffer.c. We might as well call the functions directly, instead of going through display code. This would only get worse with get/put being moved to the parent interface. To make this easier, convert overlay code from struct intel_frontbuffer to struct i915_frontbuffer, and add a i915_gem_object_frontbuffer_track() wrapper for clarity. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patch.msgid.link/829b304a6451e80fbce554bdc7788077245e803a.1772475391.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-03-11drm/i915/gem: unify i915 gem object frontbuffer function namesJani Nikula
Many of the i915 gem object frontbuffer function names follow the file name as prefix. Follow suit with the remaining functions, renaming them i915_gem_object_frontbuffer_*(). Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patch.msgid.link/3415b59497f2c3a79586600d259eeaf58be73498.1772475391.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-03-11drm/i915/gem: relocate __i915_gem_object_{flush, invalidate}_frontbuffer()Jani Nikula
Move __i915_gem_object_{flush,invalidate}_frontbuffer() to i915_gem_object_frontbuffer.c. All the other i915 gem object frontbuffer functions are there already, and the relevant declarations are in i915_gem_object_frontbuffer.h too. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patch.msgid.link/d779ef44b4b43feda9df63f1225a947a9cd23ba8.1772475391.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-03-11pinctrl: Prefer IS_ERR_OR_NULL over manual NULL checkPhilipp Hahn
Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL check. Change generated with coccinelle. To: Linus Walleij <linusw@kernel.org> Cc: linux-gpio@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Philipp Hahn <phahn-oss@avm.de> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-03-11vdso/gettimeofday: Add a helper to read the sequence lock of a time ↵Thomas Weißschuh
namespace aware clock Currently there are three different open-coded variants of a time namespace aware variant of vdso_read_begin(). They make the code hard to read and introduce an inconsistency, as only the first copy uses unlikely(). Split the code into a shared helper function. Move that next to the definition of the regular vdso_read_begin(), so that any future changes can be kept in sync easily. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260227-vdso-cleanups-v1-2-c848b4bc4850@linutronix.de
2026-03-11vdso/gettimeofday: Drop a few usages of __maybe_unusedThomas Weißschuh
These functions are used from the very same file, so this annotation is unnecessary. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260227-vdso-cleanups-v1-1-c848b4bc4850@linutronix.de
2026-03-11libceph: Fix potential out-of-bounds access in ceph_handle_auth_reply()Raphael Zimmer
This patch fixes an out-of-bounds access in ceph_handle_auth_reply() that can be triggered by a message of type CEPH_MSG_AUTH_REPLY. In ceph_handle_auth_reply(), the value of the payload_len field of such a message is stored in a variable of type int. A value greater than INT_MAX leads to an integer overflow and is interpreted as a negative value. This leads to decrementing the pointer address by this value and subsequently accessing it because ceph_decode_need() only checks that the memory access does not exceed the end address of the allocation. This patch fixes the issue by changing the data type of payload_len to u32. Additionally, the data type of result_msg_len is changed to u32, as it is also a variable holding a non-negative length. Also, an additional layer of sanity checks is introduced, ensuring that directly after reading it from the message, payload_len and result_msg_len are not greater than the overall segment length. BUG: KASAN: slab-out-of-bounds in ceph_handle_auth_reply+0x642/0x7a0 [libceph] Read of size 4 at addr ffff88811404df14 by task kworker/20:1/262 CPU: 20 UID: 0 PID: 262 Comm: kworker/20:1 Not tainted 6.19.2 #5 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: ceph-msgr ceph_con_workfn [libceph] Call Trace: <TASK> dump_stack_lvl+0x76/0xa0 print_report+0xd1/0x620 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? kasan_complete_mode_report_info+0x72/0x210 kasan_report+0xe7/0x130 ? ceph_handle_auth_reply+0x642/0x7a0 [libceph] ? ceph_handle_auth_reply+0x642/0x7a0 [libceph] __asan_report_load_n_noabort+0xf/0x20 ceph_handle_auth_reply+0x642/0x7a0 [libceph] mon_dispatch+0x973/0x23d0 [libceph] ? apparmor_socket_recvmsg+0x6b/0xa0 ? __pfx_mon_dispatch+0x10/0x10 [libceph] ? __kasan_check_write+0x14/0x30i ? mutex_unlock+0x7f/0xd0 ? __pfx_mutex_unlock+0x10/0x10 ? __pfx_do_recvmsg+0x10/0x10 [libceph] ceph_con_process_message+0x1f1/0x650 [libceph] process_message+0x1e/0x450 [libceph] ceph_con_v2_try_read+0x2e48/0x6c80 [libceph] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [libceph] ? save_fpregs_to_fpstate+0xb0/0x230 ? raw_spin_rq_unlock+0x17/0xa0 ? finish_task_switch.isra.0+0x13b/0x760 ? __switch_to+0x385/0xda0 ? __kasan_check_write+0x14/0x30 ? mutex_lock+0x8d/0xe0 ? __pfx_mutex_lock+0x10/0x10 ceph_con_workfn+0x248/0x10c0 [libceph] process_one_work+0x629/0xf80 ? __kasan_check_write+0x14/0x30 worker_thread+0x87f/0x1570 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? __pfx_try_to_wake_up+0x10/0x10 ? kasan_print_address_stack_frame+0x1f7/0x280 ? __pfx_worker_thread+0x10/0x10 kthread+0x396/0x830 ? __pfx__raw_spin_lock_irq+0x10/0x10 ? __pfx_kthread+0x10/0x10 ? __kasan_check_write+0x14/0x30 ? recalc_sigpending+0x180/0x210 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x3f7/0x610 ? __pfx_ret_from_fork+0x10/0x10 ? __switch_to+0x385/0xda0 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> [ idryomov: replace if statements with ceph_decode_need() for payload_len and result_msg_len ] Cc: stable@vger.kernel.org Signed-off-by: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de> Reviewed-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com> Reviewed-by: Ilya Dryomov <idryomov@gmail.com> Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
2026-03-11libceph: Use u32 for non-negative values in ceph_monmap_decode()Raphael Zimmer
This patch fixes unnecessary implicit conversions that change signedness of blob_len and num_mon in ceph_monmap_decode(). Currently blob_len and num_mon are (signed) int variables. They are used to hold values that are always non-negative and get assigned in ceph_decode_32_safe(), which is meant to assign u32 values. Both variables are subsequently used as unsigned values, and the value of num_mon is further assigned to monmap->num_mon, which is of type u32. Therefore, both variables should be of type u32. This is especially relevant for num_mon. If the value read from the incoming message is very large, it is interpreted as a negative value, and the check for num_mon > CEPH_MAX_MON does not catch it. This leads to the attempt to allocate a very large chunk of memory for monmap, which will most likely fail. In this case, an unnecessary attempt to allocate memory is performed, and -ENOMEM is returned instead of -EINVAL. Cc: stable@vger.kernel.org Signed-off-by: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de> Reviewed-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com> Reviewed-by: Ilya Dryomov <idryomov@gmail.com> Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
2026-03-11clocksource: Remove ARCH_CLOCKSOURCE_DATAArnd Bergmann
After sparc64, there are no remaining users of ARCH_CLOCKSOURCE_DATA and it can just be removed. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Tested-by: Andreas Larsson <andreas@gaisler.com> Reviewed-by: Andreas Larsson <andreas@gaisler.com> Acked-by: John Stultz <jstultz@google.com> Link: https://patch.msgid.link/20260304-vdso-sparc64-generic-2-v6-14-d8eb3b0e1410@linutronix.de [Thomas: drop sparc64 bits from the patch]
2026-03-11sparc64: vdso: Implement clock_gettime64()Thomas Weißschuh
To be y2038-safe, 32-bit userspace needs to explicitly call the 64-bit safe time APIs. Implement clock_gettime64() in the 32-bit vDSO. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Tested-by: Andreas Larsson <andreas@gaisler.com> Reviewed-by: Andreas Larsson <andreas@gaisler.com> Acked-by: Andreas Larsson <andreas@gaisler.com> Link: https://patch.msgid.link/20260304-vdso-sparc64-generic-2-v6-13-d8eb3b0e1410@linutronix.de
2026-03-11sparc64: vdso2c: Remove symbol handlingThomas Weißschuh
There are no handled symbols left. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Tested-by: Andreas Larsson <andreas@gaisler.com> Reviewed-by: Andreas Larsson <andreas@gaisler.com> Acked-by: Andreas Larsson <andreas@gaisler.com> Link: https://patch.msgid.link/20260304-vdso-sparc64-generic-2-v6-12-d8eb3b0e1410@linutronix.de
2026-03-11sparc64: vdso2c: Drop sym_vvar_start handlingThomas Weißschuh
After the adoption of the generic vDSO library this symbol does not exist. The alignment invariant is now guaranteed by the generic code. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Tested-by: Andreas Larsson <andreas@gaisler.com> Reviewed-by: Andreas Larsson <andreas@gaisler.com> Acked-by: Andreas Larsson <andreas@gaisler.com> Link: https://patch.msgid.link/20260304-vdso-sparc64-generic-2-v6-11-d8eb3b0e1410@linutronix.de
2026-03-11sparc64: vdso: Switch to the generic vDSO libraryThomas Weißschuh
The generic vDSO provides a lot common functionality shared between different architectures. SPARC is the last architecture not using it, preventing some necessary code cleanup. Make use of the generic infrastructure. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Tested-by: Andreas Larsson <andreas@gaisler.com> Reviewed-by: Andreas Larsson <andreas@gaisler.com> Acked-by: Andreas Larsson <andreas@gaisler.com> Link: https://patch.msgid.link/20260304-vdso-sparc64-generic-2-v6-10-d8eb3b0e1410@linutronix.de
2026-03-11sparc64: vdso: Introduce vdso/processor.hThomas Weißschuh
The generic vDSO library expects a vdso/processor.h with an definition of cpu_relax(). Split out cpu_relax() into this dedicated header. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Tested-by: Andreas Larsson <andreas@gaisler.com> Reviewed-by: Andreas Larsson <andreas@gaisler.com> Acked-by: Andreas Larsson <andreas@gaisler.com> Link: https://patch.msgid.link/20260304-vdso-sparc64-generic-2-v6-9-d8eb3b0e1410@linutronix.de
2026-03-11sparc64: vdso: Move syscall fallbacks into headerThomas Weißschuh
The generic vDSO libraries expected the syscall fallbacks in asm/vdso/gettimeofday.h. To prepare the adoption of the generic library, move the existing functions there. While at it, rename them so they match what the generic library expects. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Tested-by: Andreas Larsson <andreas@gaisler.com> Reviewed-by: Andreas Larsson <andreas@gaisler.com> Acked-by: Andreas Larsson <andreas@gaisler.com> Link: https://patch.msgid.link/20260304-vdso-sparc64-generic-2-v6-8-d8eb3b0e1410@linutronix.de
2026-03-11sparc64: vdso: Move hardware counter read into headerThomas Weißschuh
The generic vDSO libraries expected the architecture glue around hardware counter reading in asm/vdso/gettimeofday.h. To prepare the adoption of the generic library, move the existing functions there. While at it, perform some trivial alignment with the generic vDSO library: * Drop 'notrace', as the functions are __always_inline anyways * Use the same parameter types * Use the same function names Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Tested-by: Andreas Larsson <andreas@gaisler.com> Reviewed-by: Andreas Larsson <andreas@gaisler.com> Acked-by: Andreas Larsson <andreas@gaisler.com> Link: https://patch.msgid.link/20260304-vdso-sparc64-generic-2-v6-7-d8eb3b0e1410@linutronix.de
2026-03-11sparc64: vdso: Replace code patching with runtime conditionalThomas Weißschuh
The patching logic is unnecessarily complicated and stands in the way of the adoption of the generic vDSO framework. Replace it by a simple runtime switch, similar to other architectures. Suggested-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Tested-by: Andreas Larsson <andreas@gaisler.com> Reviewed-by: Andreas Larsson <andreas@gaisler.com> Acked-by: Andreas Larsson <andreas@gaisler.com> Link: https://lore.kernel.org/lkml/87ecu9tfhw.ffs@tglx/ Link: https://patch.msgid.link/20260304-vdso-sparc64-generic-2-v6-6-d8eb3b0e1410@linutronix.de
2026-03-11sparc64: vdso: Remove obsolete "fake section table" reservationThomas Weißschuh
When the vDSO logic was copied from x86 to SPARC some unused remnants of the fake section handling were copied, too. In x86 the original fake section handling had already been removed incompletely in commit da861e18eccc ("x86, vdso: Get rid of the fake section mechanism"). On x86 the reservation was only cleaned up in commit 24b7c77bbb24 ("x86/vdso: Remove obsolete "fake section table" reservation"). Remove the reservation for SPARC, too. Fixes: 9a08862a5d2e ("vDSO for sparc") Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Tested-by: Andreas Larsson <andreas@gaisler.com> Reviewed-by: Andreas Larsson <andreas@gaisler.com> Acked-by: Andreas Larsson <andreas@gaisler.com> Link: https://patch.msgid.link/20260304-vdso-sparc64-generic-2-v6-5-d8eb3b0e1410@linutronix.de
2026-03-11sparc64: vdso: Link with -z noexecstackThomas Weißschuh
The vDSO stack does not need to be executable. Prevent the linker from creating executable. For more background see commit ffcf9c5700e4 ("x86: link vdso and boot with -z noexecstack --no-warn-rwx-segments"). Also prevent the following warning from the linker: sparc64-linux-ld: warning: arch/sparc/vdso/vdso-note.o: missing .note.GNU-stack section implies executable stack sparc64-linux-ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker Fixes: 9a08862a5d2e ("vDSO for sparc") Suggested-by: Arnd Bergmann <arnd@kernel.org> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Tested-by: Andreas Larsson <andreas@gaisler.com> Reviewed-by: Andreas Larsson <andreas@gaisler.com> Acked-by: Andreas Larsson <andreas@gaisler.com> Link: https://lore.kernel.org/lkml/20250707144726.4008707-1-arnd@kernel.org/ Link: https://patch.msgid.link/20260304-vdso-sparc64-generic-2-v6-4-d8eb3b0e1410@linutronix.de
2026-03-11vdso/datastore: Allocate data pages dynamicallyThomas Weißschuh
Allocating the data pages as part of the kernel image does not work on SPARC. The MMU will raise a fault when userspace tries to access them. Allocate the data pages through the page allocator instead. Unused pages in the vDSO VMA are still allocated to keep the virtual addresses aligned. Switch the mapping from PFNs to 'struct page' as that is required for dynamically allocated pages. This also aligns the allocation of the datapages with the code pages and is a prerequisite for mlockall() support. VM_MIXEDMAP is necessary for the call to vmf_insert_page() in the timens prefault path to work. The data pages need to be order-0, non-compound pages so that the mapping to userspace and the different orderings work. These pages are also used by the timekeeping, random pool and architecture initialization code. Some of these are running before the page allocator is available. To keep these subsytems working without changes, introduce early, statically data storage which will then replaced by the real one as soon as that is available. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org> Link: https://patch.msgid.link/20260304-vdso-sparc64-generic-2-v6-3-d8eb3b0e1410@linutronix.de
2026-03-11vdso/datastore: Drop inclusion of linux/mmap_lock.hThomas Weißschuh
This header is unnecessary and together with some upcoming changes would introduce compiler warnings. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Tested-by: Andreas Larsson <andreas@gaisler.com> Reviewed-by: Andreas Larsson <andreas@gaisler.com> Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org> Link: https://lore.kernel.org/lkml/20250916-mm-rcuwait-v1-1-39a3beea6ec3@linutronix.de/ Link: https://patch.msgid.link/20260304-vdso-sparc64-generic-2-v6-2-d8eb3b0e1410@linutronix.de
2026-03-11vdso/datastore: Reduce scope of some variables in vvar_fault()Thomas Weißschuh
These variables are only used inside a single branch. Move their declarations there. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Tested-by: Andreas Larsson <andreas@gaisler.com> Reviewed-by: Andreas Larsson <andreas@gaisler.com> Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org> Link: https://patch.msgid.link/20260304-vdso-sparc64-generic-2-v6-1-d8eb3b0e1410@linutronix.de
2026-03-11asm-generic/bitsperlong.h: Add sanity checks for __BITS_PER_LONGThomas Weißschuh
The value of __BITS_PER_LONG from architecture-specific logic should always match the generic one if that is available. It should also match the actual C type 'long'. Mismatches can happen for example when building the compat vDSO. Either during the compilation, see commit 9a6d3ff10f7f ("arm64: uapi: Provide correct __BITS_PER_LONG for the compat vDSO"), or when running sparse when mismatched CHECKFLAGS are inherited from the kernel build. Add some consistency checks which detect such issues early and clearly. The kernel-internal BITS_PER_LONG is not checked as it is derived from CONFIG_64BIT and therefore breaks for the compat vDSO. See the similar, deactivated check above. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20260302-vdso-compat-checkflags-v2-5-78e55baa58ba@linutronix.de
2026-03-11powerpc/audit: Directly include unistd_32.h from compat_audit.cThomas Weißschuh
This source file undefines '__powerpc64__' to get the 32-bit system call numbers from asm/unistd.h. However this symbol is also evaluated by other headers, among them is asm/bitsperlong.h. The undefinition leads to an inconsistency between __BITS_PER_LONG and the C type 'long'. An upcoming consistency check will be tripped by this. Directly include asm/unistd_32.h to get access to the 32-bit system call numbers instead. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20260302-vdso-compat-checkflags-v2-4-78e55baa58ba@linutronix.de
2026-03-11s390: Add -m64 to KBUILD_CPPFLAGSThomas Weißschuh
Some non-code files, like linkescripts, are preprocessed with the C preprocessor and make use of regular kernel headers. As -m64 is not passed to those preprocessor invocations this leads to an inconsistency between __BITS_PER_LONG and the C type 'long'. An upcoming consistency check will be tripped by this. Make sure -m64 is also defined for those preprocessing steps. As KBUILD_CPPFLAGS is inherited by both KBUILD_AFLAGS and KBUILD_CFLAGS, drop -m64 from these variables. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20260302-vdso-compat-checkflags-v2-3-78e55baa58ba@linutronix.de
2026-03-11sparc64: vdso: Use 32-bit CHECKFLAGS for compat vDSOThomas Weißschuh
When building the compat vDSO the CHECKFLAGS from the 64-bit kernel are used. These are combined with the 32-bit CFLAGS. This confuses sparse, producing false-positive warnings or potentially missing real issues. Manually override the CHECKFLAGS for the compat vDSO with the correct 32-bit configuration. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20260302-vdso-compat-checkflags-v2-2-78e55baa58ba@linutronix.de Closes: https://lore.kernel.org/lkml/202511030021.9v1mIgts-lkp@intel.com/
2026-03-11x86/vdso: Use 32-bit CHECKFLAGS for compat vDSOThomas Weißschuh
When building the compat vDSO the CHECKFLAGS from the 64-bit kernel are used. These are combined with the 32-bit CFLAGS. This confuses sparse, producing false-positive warnings or potentially missing real issues. Manually override the CHECKFLAGS for the compat vDSO with the correct 32-bit configuration. Reported-by: Sun Jian <sun.jian.kdev@gmail.com> Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20260302-vdso-compat-checkflags-v2-1-78e55baa58ba@linutronix.de Closes: https://lore.kernel.org/lkml/20260114084529.1676356-1-sun.jian.kdev@gmail.com/ Closes: https://lore.kernel.org/lkml/20260117215542.342638347@kernel.org/ Closes: https://lore.kernel.org/r/202602111941.PIhubgrb-lkp@intel.com/
2026-03-11drm/loongson: Mark driver as orphanedThomas Zimmermann
The maintainer's email address has been bouncing for months. Mark the loongson DRM driver as orphaned. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260309081503.67123-1-tzimmermann@suse.de
2026-03-11vdso/datapage: Correct struct member kernel-docRandy Dunlap
Remove the "[]" array indicators from the struct member descriptions to avoid kernel-doc warnings. Warning: include/vdso/datapage.h:107 struct member 'basetime' not described in 'vdso_clock' Warning: include/vdso/datapage.h:107 struct member 'offset' not described in 'vdso_clock' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260228071711.2663851-1-rdunlap@infradead.org
2026-03-11dma-buf: heaps: Clear CMA highages using helperLinus Walleij
Currently the CMA allocator clears highmem pages using kmap()->clear_page()->kunmap(), but there is a helper static inline in <linux/highmem.h> that does the same for us so use clear_highpage() instead of open coding this. Suggested-by: T.J. Mercier <tjmercier@google.com> Reviewed-by: T.J. Mercier <tjmercier@google.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Linus Walleij <linusw@kernel.org> Link: https://patch.msgid.link/20260310-cma-heap-clear-pages-v2-2-ecbbed3d7e6d@kernel.org
2026-03-11dma-buf: heaps: Clear CMA pages with clear_pages()Linus Walleij
As of commit 62a9f5a85b98 "mm: introduce clear_pages() and clear_user_pages()" we can clear a range of pages with a potentially assembly-optimized call. Instead of using a memset, use this helper to clear the whole range of pages from the CMA allocation. Reviewed-by: T.J. Mercier <tjmercier@google.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Linus Walleij <linusw@kernel.org> Link: https://patch.msgid.link/20260310-cma-heap-clear-pages-v2-1-ecbbed3d7e6d@kernel.org
2026-03-11irqchip/apple-aic: Add support for "apple,t8122-aic3"Janne Grunau
Introduce support for the new AICv3 hardware block in t8122 and t603x SoCs. AICv3 is similar to AICv2 but has an increased IRQ config offset. These MMIO offsets are coded as properties of the "aic,3" node in Apple's device tree. The actual offsets are the same for all SoCs starting from M3 through at least M5. So do not bother to follow suit but use AICv3 specific defines in the driver. The compatible string is SoC specific so future SoCs with AICv3 and different offsets would just use their own compatible string as base and add their new offsets. Signed-off-by: Janne Grunau <j@jannau.net> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Reviewed-by: Sven Peter <sven@kernel.org> Link: https://patch.msgid.link/20260223-irq-apple-aic3-v3-2-2b7328076b8d@jannau.net
generated by cgit v1.2.3 (git 2.25.1) at 2026-09-17 09:38:48 +0000