aboutsummaryrefslogtreecommitdiffstats
path: root/include/linux
AgeCommit message (Collapse)AuthorFilesLines
2026-09-03kprobes: Protect kprobe_blacklist with RCUMasami Hiramatsu (Google)1-0/+1
__within_kprobe_blacklist() traverses kprobe_blacklist without holding kprobe_mutex. When a module is unloaded, kprobe_remove_area_blacklist() removes blacklist entries and immediately frees them with kfree(). A concurrent call to within_kprobe_blacklist() can therefore dereference freed memory. Furthermore, within_kprobe_blacklist() can be called in atomic or non-preemptible contexts where the sleeping kprobe_mutex cannot be taken. Protect kprobe_blacklist with RCU. Use guard(rcu)() and list_for_each_entry_rcu() for traversal, list_add_tail_rcu() for insertions, list_del_rcu() for deletions, and kfree_rcu() to reclaim entries safely after a grace period. Link: https://lore.kernel.org/all/178810004323.64882.16493230858653316962.stgit@devnote2/ Fixes: 376e242429bf ("kprobes: Introduce NOKPROBE_SYMBOL() macro to maintain kprobes blacklist") Cc: stable@vger.kernel.org Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://lore.kernel.org/all/20260807155802.F06041F000E9@smtp.kernel.org/ Assisted-by: Antigravity:gemini-3.7-flash Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
2026-09-02ARM: imx6q: remove KSZ9021 PHY fixupHeiner Kallweit1-5/+0
477fce49aef4 ("arm/imx6q-sabrelite: add enet phy ksz9021rn fixup") added this PHY fixup in 2011. In 2013 954c396756e3 ("net/phy: micrel: Add OF configuration support for ksz9021") added support for configuring pad skew parameters via OF, removing the need for the board-level fixup. Note: In 2013 14078291d89b ("ARM: i.MX6: call ksz9021 phy fixup for all i.MX6 boards") extended usage of the fixup to nitrogen6x and titanium. nitrogen6x configures the PHY properly via OF, and titanium has no mainline Linux support. From u-boot titanium support was removed in 2021. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-09-02perf: Enhance perf_reg_validate() with simd_enabled argumentDapeng Mi1-1/+1
The upcoming patch will support x86 APX eGPRs sampling by using the reclaimed XMM register space to represent eGPRs in sample_regs_* fields. To differentiate between XMM and eGPRs in sample_regs_* fields, an additional argument, simd_enabled, is introduced to the perf_reg_validate() helper. If simd_enabled is set to 1, it indicates that eGPRs are represented in sample_regs_* fields for the x86 platform; otherwise, XMM registers are represented. Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260824082731.1013973-18-dapeng1.mi@linux.intel.com
2026-09-02perf/x86: Support XMM sampling using sample_simd_vec_reg_* fieldsDapeng Mi1-0/+1
Support sampling of XMM registers using the sample_simd_vec_reg_* fields. When sample_simd_regs_enabled is set, the original XMM space in the sample_regs_* field is treated as reserved. An INVAL error will be reported to user space if any bit is set in the original XMM space while sample_simd_regs_enabled is set. The perf_reg_value function requires ABI information to understand the layout of sample_regs. To accommodate this, a new abi field is introduced in the struct x86_perf_regs to represent ABI information. Additionally, the x86 specific perf_simd_reg_value() function is implemented to retrieve the XMM register values. XMM sampling will be enabled in a subsequent patch that sets PERF_PMU_CAP_SIMD_REGS. Co-developed-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260824082731.1013973-14-dapeng1.mi@linux.intel.com
2026-09-02perf: Add sampling support for SIMD registersKan Liang2-0/+16
Users may be interested in sampling SIMD registers during profiling. The current sample_regs_* structure does not have sufficient space for all SIMD registers. To address this, new attribute fields sample_simd_{pred,vec}_reg_* are added to struct perf_event_attr to represent the SIMD registers that are expected to be sampled. Currently, the perf/x86 code supports XMM registers in sample_regs_*. To unify the configuration of SIMD registers and ensure a consistent method for configuring XMM and other SIMD registers, a new event attribute field, sample_simd_regs_enabled, is introduced. When sample_simd_regs_enabled is set, it indicates that all SIMD registers, including XMM, will be represented by the newly introduced sample_simd_{pred|vec}_reg_* fields. The original XMM space in sample_regs_* is reserved for future uses. Since SIMD registers are wider than 64 bits, a new output format is introduced. The number and width of SIMD registers are dumped first, followed by the register values. The number and width are based on the user's configuration. A new ABI, PERF_SAMPLE_REGS_ABI_SIMD, is added to indicate the new format. The enum perf_sample_regs_abi is now a bitmap. This change should not impact existing tools, as the version and bitmap remain the same for values 1 and 2. Additionally, two new __weak functions are introduced: - perf_simd_reg_value(): Retrieves the value of the requested SIMD register. - perf_simd_reg_validate(): Validates the configuration of the SIMD registers. A new flag, PERF_PMU_CAP_SIMD_REGS, is added to indicate that the PMU supports SIMD register dumping. An error is generated if sample_simd_{pred|vec}_reg_* is mistakenly set for a PMU that does not support this capability. Suggested-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Kan Liang <kan.liang@linux.intel.com> Co-developed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260824082731.1013973-13-dapeng1.mi@linux.intel.com
2026-09-02perf: Move and enhance has_extended_regs() for arch-specific useKan Liang1-0/+10
Move has_extended_regs() to include/linux/perf_event.h so it can be used by arch-specific code. While moving it, enhance the check logic and rename it to event_has_extended_regs() to match existing perf event helper naming. Signed-off-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260824082731.1013973-9-dapeng1.mi@linux.intel.com
2026-09-02perf: Eliminate duplicate arch-specific function definitionsDapeng Mi1-26/+6
Define default common __weak functions for perf_reg_value(), perf_reg_validate(), perf_reg_abi() and perf_get_regs_user(). This helps to eliminate the duplicated arch-specific definitions. No function changes intended. Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260824082731.1013973-5-dapeng1.mi@linux.intel.com
2026-09-02sched: Convert paravirt_steal to new static key APIsHongyan Xia1-3/+3
paravirt_steal_rq_enabled and paravirt_steal_enabled use raw static_key APIs which are now deprecated. Use the new API instead. No functional change. Signed-off-by: Hongyan Xia <hongyan.xia@transsion.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Juergen Gross <jgross@suse.com> Link: https://patch.msgid.link/20260819081207.12150-1-hongyan.xia@transsion.com
2026-09-02platform/x86: int3472: support the POWER1 GPIO typeJakob Berg Jespersen1-0/+2
INT3472 can describe a second sensor power rail as a GPIO of type POWER1 (0x08), which the driver does not recognise, so the rail is left unmapped and never enabled: int3472-discrete INT3472:01: GPIO type 0x08 unknown; the sensor may not work On the Microsoft Surface Pro 7+ the rear camera's INT3472 (INT347A, ov8865) has such a pin; without it the ov8865 "dvdd" supply resolves to a dummy regulator and the sensor never probes. Define the POWER0 (0x07) and POWER1 (0x08) GPIO types and map POWER1 to a regulator with con_id "dvdd" for all devices, the supply the in-tree ov8865 driver already requests. POWER0 is defined but left unmapped, as no device that uses it is known. With this change the Surface Pro 7+ rear camera probes and streams reliably. Link: https://github.com/linux-surface/linux-surface/pull/1867 Link: https://github.com/linux-surface/linux-surface/pull/2201 Suggested-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Jakob Berg Jespersen <dev@berg.pm> Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com> [Sakari Ailus: Sanitised the commit message a little.] Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2026-09-02sched: dynamic: Simplify preempt model accessorsMark Rutland1-10/+10
PREEMPT_DYNAMIC is now limited to the FULL and LAZY preemption models. When CONFIG_PREEMPT_DYNAMIC=y, the NONE and VOLUNTARY models cannot be used, and neither CONFIG_PREEMPT_NONE nor CONFIG_PREEMPT_VOLUNTARY can be selected. Simplify the preempt model accessors accordingly: remove the out-of-line implementations of preempt_model_none() and preempt_model_voluntary(), and remove the preempt_dynamic_{none,voluntary} values. There are no current users of preempt_model_voluntary(), but I've kept it around for consistency, with every scheduler model having its own preempt_model_*() accessor. Suggested-by: Shrikanth Hegde <sshegde@linux.ibm.com> Signed-off-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Jinjie Ruan <ruanjinjie@huawei.com> Reviewed-by: Shrikanth Hegde <sshegde@linux.ibm.com> Tested-by: Mete Durlu <meted@linux.ibm.com> Tested-by: Shrikanth Hegde <sshegde@linux.ibm.com> Tested-by: Jinjie Ruan <ruanjinjie@huawei.com> Link: https://patch.msgid.link/20260803191731.3244294-7-mark.rutland@arm.com
2026-09-02sched: dynamic: Simplify irqentry_exit_cond_resched()Mark Rutland1-16/+1
PREEMPT_DYNAMIC is now limited to the FULL and LAZY preemption models. In either model, irqentry_exit_cond_resched() is always called and never disabled. Remove the unnecessary code for this when PREEMPT_DYNAMIC is selected. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Shrikanth Hegde <sshegde@linux.ibm.com> Reviewed-by: Jinjie Ruan <ruanjinjie@huawei.com> Tested-by: Mete Durlu <meted@linux.ibm.com> Tested-by: Shrikanth Hegde <sshegde@linux.ibm.com> Tested-by: Jinjie Ruan <ruanjinjie@huawei.com> Link: https://patch.msgid.link/20260803191731.3244294-5-mark.rutland@arm.com
2026-09-02sched: dynamic: Simplify {cond,might}_resched()Mark Rutland2-48/+3
PREEMPT_DYNAMIC is now limited to the FULL and LAZY preemption models. In either model, both cond_resched() and might_resched() are always disabled and do nothing. Remove the unnecessary code for these when PREEMPT_DYNAMIC is selected. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Shrikanth Hegde <sshegde@linux.ibm.com> Reviewed-by: Jinjie Ruan <ruanjinjie@huawei.com> Tested-by: Mete Durlu <meted@linux.ibm.com> Tested-by: Shrikanth Hegde <sshegde@linux.ibm.com> Tested-by: Jinjie Ruan <ruanjinjie@huawei.com> Link: https://patch.msgid.link/20260803191731.3244294-3-mark.rutland@arm.com
2026-09-01perf: RISC-V: store available counter mask as bitmapXixin Liu1-1/+1
The available-counter mask was a single unsigned long, but iteration uses RISCV_MAX_COUNTERS, which is 64. On RV32 that reads past the object. Filling with an unsigned-long bit at index 32 and above is also wrong. Use DECLARE_BITMAP and set_bit/bitmap helpers. Walk each bitmap word into CFG_MATCH when checking events, when allocating an index, and when stopping all counters. Set the counter base to i times BITS_PER_LONG. Share the CFG_MATCH ecall through a small helper so the 32-bit argument split is not duplicated. On qemu-system-riscv32 the probe bitmap has bits above XLEN set, so the first word alone is not enough. Fixes: e9991434596f ("RISC-V: Add perf platform driver based on SBI PMU extension") Assisted-by: DeepSeek:deepseek-v3 Signed-off-by: Xixin Liu <liuxixin@kylinos.cn> Link: https://patch.msgid.link/prpmask02cmap.v2.1786434000.git.liuxixin@kylinos.cn Cc: stable@kernel.org [pjw@kernel.org: updated to apply; fixed checkpatch.pl issues] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-09-01ftrace: Take trace_array reference before accessing its ftrace_opsSteven Rostedt1-2/+3
The trace instance files set_ftrace_filter and set_ftrace_notrace was updated to work with specific trace instances (trace_arrays). The issue is that when these files are opened, there is a small race window where it will use the ftrace_ops from the inode->private pointer to get a reference to the trace_array and then take its reference. The problem is that the ftrace_ops itself could be freed. If the rmdir on the instance happens at the same time the set_ftrace_filter file is opened, the rmdir could have also freed the ftrace_ops and referencing it will cause a use-after-free bug and crash the kernel. Instead, pass in the trace_array as the file private data (NULL for the top level instance), and then pass both the trace_array and the ftrace_ops to the ftrace_regex_open() function. If the trace_array is NULL, then it just uses the ftrace_ops without the need to take its reference (like normal). If the ftrace_ops is NULL, that is only the case for the top level instance and the global_ops can be used. This allows the trace_array to have its reference incremented before touching the ftrace_ops that could also be freed when the instance is. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260828223901.29e26edb@robin Fixes: 591dffdade9f0 ("ftrace: Allow for function tracing instance to filter functions") Reported-by: Breno Leitao <leitao@debian.org> Tested-by: Breno Leitao <leitao@debian.org> Closes: https://lore.kernel.org/all/apGORjltZgAiAYHT@gmail.com/ Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-09-01sched_ext: Skip per-CPU data allocation for built-in DSQsfangqiurong1-1/+1
Only user DSQs use the per-DSQ deferred reenqueue state: schedule_dsq_reenq() serves the local DSQ through sch->pcpu->deferred_reenq_local and rejects all other built-in DSQ ids. Every DSQ, built-in or not, still allocates a struct scx_dsq_pcpu per possible CPU. As the local, reject, rescue and bypass DSQs are themselves per-CPU, the wasted memory grows with the square of the CPU count, most of it at boot before any scheduler is loaded. Skip the allocation for built-in DSQ ids. While at it, rename ->pcpu to ->pcpu_user so that the per-CPU data reads as user-DSQ only. Signed-off-by: fangqiurong <fangqiurong@kylinos.cn> Reviewed-by: Zhan Xusheng <zhanxusheng@xiaomi.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2026-09-01iio: rename stale IIO_DEV_ACQUIRE_ERR reference to IIO_DEV_ACQUIRE_FAILEDJavier Carrasco1-1/+1
Update the kernel-doc reference left over from an earlier revision of the series, before the macro was renamed to IIO_DEV_ACQUIRE_FAILED(). Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
2026-09-01clk: fix self-consuming provider module pinningJerome Brunet1-3/+19
clk_hw_get_clk() lets a provider get a struct clk for one of its own struct clk_hw. When a struct clk is created, the module usage count of the provider is unconditionally increased. For a self-consuming provider, this means it pins itself and the module can never be unloaded. Increasing the module usage count should only be done when the consumer lives in a different module from the provider. Use THIS_MODULE to capture caller's module and increase the module usage count accordingly. It is OK for consumer-only APIs such as clk_get() or of_clk_get() to pass a NULL owner. As a result, any provider module will get pinned, same as before. Fixes: 30d6f8c15d2c ("clk: add api to get clk consumer from clk_hw") Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Brian Masney <bmasney@redhat.com>
2026-09-01Merge drm/drm-fixes into drm-misc-fixesMaxime Ripard365-3286/+10792
Let's start the 7.3 drm-misc-fixes cycle. Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-09-01Merge tag 'v7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into gpio/for-nextBartosz Golaszewski55-991/+1709
Linux 7.3-rc1
2026-08-31Merge tag 'edac_updates_for_v7.3_rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/rasLinus Torvalds1-3/+0
Pull forgotten EDAC updates from Borislav Petkov: "Somewhat belated (and forgotten :-\) EDAC updates lineup for v7.3: - Mark the mpc85xx and ThunderX EDAC drivers as orphaned due to lack of access to hardware - Remove the unused fake error injection interface from the EDAC debugfs code due to potential races between logging a fake and a real hw error - edac_mc_sysfs: Use sysfs_emit_at() for proper bounds checking - Remove Mark Gross from maintainer entries and move him to CREDITS - Load the AMD address translation library only on systems which can actually make use of it (have ECC memory) instead of on every AMD Zen system out there - In edac_altera, detect the SoC variant using the ECC manager's compatible string instead of the build architecture to select the correct interrupt layout, and remove leftover architecture-specific ifdeffery from the double-bit error handling path - Add a new reviewer for the Xilinx EDAC drivers - Unify address translation logic in Intel client EDAC drivers igen6 and ie31200 along with detecting memory controller counts at boot time instead of relying on hardcoded, platform specific numbers. Also, fix a bunch of issues in them; work by Qiuxu Zhuo - Add support for a new Intel processor platform Starfire which is a derivative of Panther Lake SoCs - The usual cleanups and fixlets all over" * tag 'edac_updates_for_v7.3_rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras: (24 commits) EDAC/thunderx: Orphan it EDAC/device_sysfs: Cleanup around edac_device_ctl_poll_msec_store() EDAC/device_sysfs: Use kstrtouint() for poll_msec to prevent truncation EDAC/igen6: Add Intel Starfire SoCs support EDAC/igen6: Refactor address translation logic EDAC/igen6: Remove redundant resource configuration tables EDAC/igen6: Detect present memory controllers at runtime EDAC/igen6: Simplify compute die ID comments EDAC/igen6: Remove unnecessary XOR on the zero-valued interleave bit EDAC/igen6: Fix Raptor Lake-P logged error address EDAC/igen6: Fix channel address decode for non-hash mode EDAC/igen6: Fix channel selection hash EDAC/igen6: Fix interleave boundary condition EDAC/ie31200: Decouple DIMM width decoding from enum order RAS/AMD/ATL: Remove conditional return with no effect EDAC: Remove redundant dev_err() MAINTAINERS: Add Radhey Shyam Pandey as Xilinx EDAC reviewer EDAC/altera: Remove remaining CONFIG_64BIT ifdefs in the DB-error path EDAC/altera: Use ECC manager compatible to select A10/S10 IRQ layout RAS/AMD/ATL, EDAC/amd64: Only load ATL when needed ...
2026-09-01firewire: core: fix wrong git hash in code commentTakashi Sakamoto1-1/+1
When refactoring device quirk code, the wrong git hash from my local repository slipped into the common header. Fixes: 5a43dc9f4ee0 ("firewire: core: detect device quirk when reading configuration ROM") Link: https://lore.kernel.org/lkml/20260901134921.2386739-1-o-takashi@sakamocchi.jp/ Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2026-08-31igmp: convert struct ip_sf_list to RCUEric Dumazet1-3/+4
Commit 23d2b94043ca ("igmp: Add ip_mc_list lock in ip_check_mc_rcu") added spin_lock_bh(&im->lock) to ip_check_mc_rcu() to prevent a use-after-free while iterating im->sources during concurrent deletions. However, ip_check_mc_rcu() is called from RCU read-side critical sections in packet receive and route lookup fast paths (e.g. __mkroute_output(), ip_route_input_rcu(), and __udp4_lib_rcv()). When igmpv3_send_cr() or igmpv3_send_report() holds &pmc->lock and calls add_grec() -> igmpv3_newpack() -> ip_route_output_ports(), an XFRM policy matching a multicast destination triggers xfrm_tmpl_resolve_one() -> xfrm4_get_saddr() -> __mkroute_output() -> ip_check_mc_rcu(). This attempts to acquire &im->lock while &pmc->lock is already held on the same CPU, triggering a lockdep recursive locking warning / deadlock. Fix this by converting IPv4 struct ip_sf_list to RCU, mirroring the IPv6 implementation in net/ipv6/mcast.c: 1. Add struct rcu_head to struct ip_sf_list and annotate sf_next, sources, and tomb as __rcu pointers. 2. Use rcu_assign_pointer() and kfree_rcu() for list updates and deletions. 3. Remove spin_lock_bh(&im->lock) from ip_check_mc_rcu() and traverse im->sources locklessly with for_each_psf_rcu(), reading and writing counter fields with READ_ONCE() and WRITE_ONCE(). Note: RCU conversion of /proc/net/mcfilter will be done in a separate patch. Fixes: 23d2b94043ca ("igmp: Add ip_mc_list lock in ip_check_mc_rcu") Reported-by: syzbot+3d99fb01bcd740f2fc1e@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3d99fb01bcd740f2fc1e Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260827160656.903003-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-31soc: qcom: ubwc: Add configuration for HawiWangao Wang1-0/+3
Add UBWC configuration data for the Hawi platform, which uses UBWC 7.0 and enables the required flags and highest bank bit settings. This allows drivers to query the correct UBWC capabilities on Hawi. Also add UBWC 7.0 support to the version tag helper so that qcom_ubwc_version_tag() returns the correct tag for UBWC 7.0. Signed-off-by: Wangao Wang <wangao.wang@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260812-ubwc_for_hawi_maili-v1-1-c29edecb3bd8@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-08-31soc: qcom: apr: Drop unused apr_device_idUwe Kleine-König (The Capable Hub)3-24/+2
apr_device_id was introduced in commit 6adba21eb434 ("soc: qcom: Add APR bus driver") in 2018, and since then not a single driver made use of it. So drop the unused id_table pointer from struct apr_driver and move APR_NAME_SIZE to the apr header which still has a usage of it. Note that with the id_table being NULL apr_device_match() degrades to just of_driver_match_device(), so replace this callback accordingly. Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/e8b352f33ae38df3616dc157c1cafd13d49c5e3e.1784554037.git.u.kleine-koenig@baylibre.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-08-31sched_ext: Rename tg->scx.idle to tg->scx.sched_idleTao Cui1-1/+1
A bare "idle" reads as CPU idle state in sched_ext (ops.update_idle(), idle cpumasks, scx_bpf_pick_idle_cpu()). cpu.idle is the cgroup analog of the SCHED_IDLE policy, so name the task_group field sched_idle to match scx_cgroup_init_args.sched_idle. Pure rename, no behavior change. Signed-off-by: Tao Cui <cuitao@kylinos.cn> Reviewed-by: Andrea Righi <arighi@nvidia.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2026-08-31Merge tag 'devm_notifier_chain_register-for-7.4' of https://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux into HEADUwe Kleine-König1-0/+7
Provide devm_{atomic,blocking}_notifier_chain_register() Base for merging into subsystem trees that want to benefit from the devm variants of notifier_chain_register functions created by Eliav Farber for the 7.4 merge window.
2026-08-31Merge tag 'cgroup-for-7.3-rc1-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroupLinus Torvalds1-1/+4
Pull cgroup fixes from Tejun Heo: - After cgroup.kill was written to a cgroup, every child cloned into it with CLONE_INTO_CGROUP was spuriously killed because the fork path snapshotted the kill counter before resolving the target cgroup - Releasing an isolated cpuset partition dropped the isolation of CPUs isolated on the kernel command line - Selftest and documentation fixes * tag 'cgroup-for-7.3-rc1-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup: selftests/cgroup: test clone3() into a previously killed cgroup cgroup: fix spurious SIGKILL of CLONE_INTO_CGROUP children selftests/cgroup: Add test for preserving boot-isolated CPUs cgroup/cpuset: Preserve boot-isolated CPUs on partition release selftests/cgroup: Drop invalid boot isolation comparison docs: cgroup-v2: fix misc.events key format description selftests/cgroup: Fix cg_run_in_subcgroups ignoring arg parameter selftests/cgroup: set the test plan after the setup checks
2026-08-31firmware: qcom_scm: Remove SCM PAS wrappersSumit Garg1-29/+0
Now since all the Qcom SCM client drivers have been migrated over to generic PAS TZ service, let's drop the exported SCM PAS wrappers. Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Tested-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> # Lemans Tested-by: Vignesh Viswanathan <vignesh.viswanathan@oss.qualcomm.com> # IPQ9650 Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260702115835.167602-14-sumit.garg@kernel.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-08-31lsm: add LSM_AUDIT_DATA_NS for namespace audit recordsMickaël Salaün1-0/+5
Add a new LSM audit data type LSM_AUDIT_DATA_NS that logs namespace information in audit records. Two fields are provided: - namespace_type: the CLONE_NEW* flag identifying the namespace type, logged in hexadecimal. - namespace_id: the unique 64-bit namespace identifier, retrievable from userspace via NS_GET_ID or listns(2). Unlike the proc inode number (inum), namespace_id is never recycled. For namespace creation denials, namespace_id is 0 because the namespace does not exist yet. A new audit data type is needed because no existing LSM_AUDIT_DATA_* type carries namespace information. The closest alternatives (e.g. LSM_AUDIT_DATA_TASK or LSM_AUDIT_DATA_NONE with custom strings) would either lose the namespace type or require ad-hoc formatting that bypasses the structured audit data union. Cc: Günther Noack <gnoack@google.com> Cc: Paul Moore <paul@paul-moore.com> Reviewed-by: Christian Brauner <brauner@kernel.org> Reviewed-by: Günther Noack <gnoack@google.com> Signed-off-by: Mickaël Salaün <mic@digikod.net> [PM: corrected audit fields in the description, subject tweaks] Signed-off-by: Paul Moore <paul@paul-moore.com>
2026-08-31lsm: add LSM blob and hooks for namespacesChristian Brauner4-0/+27
All namespace types now share the same ns_common infrastructure. Extend this to include a security blob so LSMs can start managing namespaces uniformly without having to add one-off hooks or security fields to every individual namespace type. Add a ns_security pointer to ns_common and the corresponding lbs_ns blob size to lsm_blob_sizes. Allocation and freeing hooks are called from the common __ns_common_init() and __ns_common_free() paths so every namespace type gets covered in one go. All information about the namespace type and the appropriate casting helpers to get at the containing namespace are available via ns_common making it straightforward for LSMs to differentiate when they need to. A namespace_install hook is called from validate_ns() during setns(2) giving LSMs a chance to enforce policy on namespace transitions. The LSM check runs before ns->ops->install() so the security module can deny the operation before any type-specific installation effects. Individual namespace types can still have their own specialized security hooks when needed. This is just the common baseline that makes it easy to track and manage namespaces from the security side without requiring every namespace type to reinvent the wheel. Cc: Günther Noack <gnoack@google.com> Cc: Paul Moore <paul@paul-moore.com> Cc: Serge E. Hallyn <serge@hallyn.com> Signed-off-by: Christian Brauner <brauner@kernel.org> Link: https://lore.kernel.org/r/20260216-work-security-namespace-v1-1-075c28758e1f@kernel.org Signed-off-by: Mickaël Salaün <mic@digikod.net> [PM: subject tweak] Signed-off-by: Paul Moore <paul@paul-moore.com>
2026-08-31cred: clarify that task_struct::cred is only for the current taskJann Horn2-8/+17
The `cred` field in task_struct is currently marked as __rcu, but that's not true: It can point to credentials from access_override_creds(), which do not get freed with RCU delay. What actually protects task_struct::cred is that accessing it is only permitted for the current task (except for setting up a child during fork() or tearing down a dead process). (There is currently code in Smack that violates this rule, but that's a bug and causes UAF, I have sent a separate fix for that.) Clarify this, remove the __rcu marker, and remove RCU helpers from all accesses to this field. Signed-off-by: Jann Horn <jannh@google.com> Reviewed-by: Serge Hallyn <serge@hallyn.com> [PM: style tweak in security_init(), applied fixup from JH] Signed-off-by: Paul Moore <paul@paul-moore.com>
2026-08-31audit: add missing unlikely hint to audit_dummy_context() wrappersRicardo Robaina1-3/+3
The inline wrappers: audit_log_kern_module(), audit_tk_injoffset(), and audit_ntp_log() check audit_dummy_context() without unlikely(), unlike every other wrapper in the file. Add the missing annotations for consistency. Signed-off-by: Ricardo Robaina <rrobaina@redhat.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
2026-08-31Merge tag 'xfs-fixes-7.3-rc2' of gitolite.kernel.org:/pub/scm/fs/xfs/xfs-linuxLinus Torvalds1-0/+5
Pull xfs fixes from Carlos Maiolino: "This contains a few fixes for the zoned storage support, a possible deadlock vector fix, some code refactoring patches and a quota evasion fix on XFS while exporting it via NFS. Please note that for the quota evasion fix, a couple patches for the capability subsystem are included in the pull request. Those have been ack'ed by the respective maintainer which also agreed to have them going through the xfs tree. This also includes a patch for the quota subsystem to stop issuing audit messages during quota enforcing. Quota maintainer also ack'ed and agreed with this going through xfs tree" * tag 'xfs-fixes-7.3-rc2' of gitolite.kernel.org:/pub/scm/fs/xfs/xfs-linux: capability: unexport has_capability_noaudit xfs: replace ns_capable_noaudit quota: Don't issue audit messages on quota enforcing capability: Add new capable_noaudit xfs: fix capability check in xfs xfs: restore bi_bdev in xfs_zone_gc_write_chunk xfs: split ioend handling into a separate source file xfs: factor out a xfs_iomap_set_anon_write helper xfs: fix zoned write iomap flags assignments xfs: fix racy open zone caching xfs: handle NULL open_zone for merged ioends in xfs_ioend_put_open_zones xfs: use inode_init_always_gfp with __GFP_NOFAIL in xfs_inode_alloc xfs: remove kmem_to_page() xfs: don't flush and invalidate internal RT device twice in xfs_shutdown_devices xfs: split an assert in xfs_trans_log_buf xfs: don't hold buffer locks across sync transaction commit in xfs_sync_sb_buf
2026-08-31soc: qcom: llcc: Update the SCT table for IPQ5424Kathiravan Thirumoorthy1-0/+4
Update the IPQ5424 LLCC slice configuration table to give the PPE and Wi-Fi datapaths dedicated slices. Assign slice IDs 1 and 5 to the PPE RX descriptor and RX fill use cases, slice IDs 6 and 7 to the Wi-Fi radios connected over PCIe, and slice ID 2 to the CPU subsystem. Adjust the corresponding capacities, priorities, and way masks for these consumers. These slice assignments are based on recommendations from the performance team, following throughput measurements on IPQ5424. Having the dedicated slice configuration for each of these use cases helps to improve the networking throughput by more than 1 Gbps. Rename the usecase IDs for slice IDs 1 and 2 because LLCC_CPUSS and LLCC_VIDSC0 do not describe the actual users of those slices. Assisted-by: LLM Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260819-ipq5424_llcc_updates-v3-1-42b48451481d@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-08-31cgroup: fix spurious SIGKILL of CLONE_INTO_CGROUP childrenEtienne Perot1-1/+4
Since commit b69bb476dee9 ("cgroup: fix race between fork and cgroup.kill"), the fork path snapshots the kill_seq of the child's future cgroup into kargs->kill_seq, and cgroup_post_fork() SIGKILLs the child if that cgroup's kill_seq has changed in the meantime, to catch forks racing with a cgroup.kill sweep. For CLONE_INTO_CGROUP, however, the snapshot in cgroup_css_set_fork() is taken before the target cgroup has been resolved: kargs->cgrp is always NULL at this point (it is only set at the end of the function). So the "if (kargs->cgrp)" branch is dead code and the snapshot always records the kill_seq of the parent's cgroup. cgroup_post_fork() then compares it with the kill_seq of the target cgroup, so the child gets SIGKILLed whenever the two cgroups have been killed a different number of times. As a result, once cgroup.kill has been written to a cgroup, every child subsequently cloned into it with clone3(CLONE_INTO_CGROUP) is killed on the spot, for as long as the cgroup exists: kill_seq is not exposed to userspace and never resets. Re-snapshot kill_seq from the target cgroup once it has been resolved, and drop the dead branch at the early snapshot site. This does not reopen the race fixed by b69bb476dee9. For CLONE_INTO_CGROUP, everything from the snapshot to the check in cgroup_post_fork() runs with cgroup_mutex held, and kill_seq is only ever incremented under cgroup_mutex. tj: Updated the comment above kill_seq to reflect the new serialization rules as suggested by Shakeel Butt. Fixes: b69bb476dee9 ("cgroup: fix race between fork and cgroup.kill") Cc: stable@vger.kernel.org Cc: Shakeel Butt <shakeel.butt@linux.dev> Assisted-by: LLM Signed-off-by: Etienne Perot <eperot@google.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2026-08-31s390/ap: Drop unused member from ap_device_idUwe Kleine-König (The Capable Hub)1-2/+0
ap_device_id::driver_info is not used in the kernel. The structure is also not part of API/ABI, so the unused member can just be dropped. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Acked-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2026-08-31Merge drm/drm-fixes into drm-misc-fixesThomas Zimmermann2-0/+3
Updating drm-misc-fixes to the state of v7.2. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2026-08-31kexec: keep the next kernel off hardware-poisoned pagesBreno Leitao1-0/+14
Memory failures (such as unrecoverable ECCs errors) are getting more and more common. The kernel knows how to handle it while running, marking it as poisoned (and SIGBUS user tasks). Poisoned memory is removed from the buddy allocator, but, not from other places. A current problem is that kexec will load new kernel on top of a bad/poisoned memory, which is undesirable. If the next kernel's image, initrd or purgatory lands on a poisoned frame, the relocation copy puts it on memory that is known bad. The error happens on the first read from a bad page, and that is what we want to avoid. Skip hardware-poisoned frames that were detected by the memory failure subsystem earlier when placing kexec segments. To do so, add a helper that reports the first or the last poisoned page in a range: memory is walked top-down by locate_mem_hole_top_down() and bottom-up by locate_mem_hole_bottom_up(), so each direction needs a different answer to stay clear of the poison. kexec_load() gets its destinations from userspace and cannot move them, so there sanity_check_segment_list() just rejects a segment that happens to have a poisoned page. is_page_hwpoison() also covers hugetlb, so a poisoned hugetlb folio is skipped as a whole. Suggested-by: Kiryl Shutsemau <kas@kernel.org> Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Kiryl Shutsemau (Meta) <kas@kernel.org> Reviewed-by: Pratyush Yadav <pratyush@kernel.org> Reviewed-by: Bradley Morgan <include@grrlz.net> Reviewed-by: Miaohe Lin <linmiaohe@huawei.com> Link: https://patch.msgid.link/20260812-kexec_posioned-v6-2-e477887086f0@debian.org Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
2026-08-31firewire: core: fix wrong git hash in code commentTakashi Sakamoto1-1/+1
When refactoring device quirk code, the wrong git hash from my local repository slipped into the common header. Fixes: 5a43dc9f4ee0 ("firewire: core: detect device quirk when reading configuration ROM") Link: https://lore.kernel.org/r/20260831101253.1810143-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2026-08-31dma-buf: fix some kernel-doc warningsRandy Dunlap2-6/+4
- drop Excess description of @lock from kernel-doc - add missing function/macro short descriptions WARNING: include/linux/dma-fence-array.h:47 Excess struct member 'lock' description in 'dma_fence_array' WARNING: include/linux/dma-fence-chain.h:48 Excess struct member 'lock' description in 'dma_fence_chain' Warning: include/linux/dma-fence-chain.h:82 missing initial short description on line: * dma_fence_chain_alloc Warning: include/linux/dma-fence-chain.h:94 missing initial short description on line: * dma_fence_chain_free Fixes: 5943243914b9 ("dma-buf: use inline lock for the dma-fence-array") Fixes: a408c0ca0c41 ("dma-buf: use inline lock for the dma-fence-chain") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20260831031956.3410813-1-rdunlap@infradead.org
2026-08-31reboot: fix cad_pid use-after-free raceCen Zhang (Microsoft)2-5/+2
cad_pid is a single kernel-wide struct pid pointer. proc_do_cad_pid() reads it and passes it to pid_vnr() without protecting the lifetime of the referenced struct pid. A concurrent writer can replace cad_pid and drop the final reference to the old struct pid after the reader has loaded the pointer but before pid_vnr() has finished dereferencing it, causing a use-after-free. kill_cad_pid() has the same lifetime race when it passes cad_pid to kill_pid(). At the time this issue was reported, an unprivileged user could reach the sysctl through user and PID namespaces because cad_pid was registered in pid_table[]. Moving cad_pid back to the global reboot sysctl table corrected that namespace and permission mismatch, but did not fix the underlying lifetime race. Fix this by treating cad_pid as an RCU-protected pointer at both read sites and by waiting for a grace period before dropping the old reference on the write side. call_rcu(&old_pid->rcu, ...) cannot be used here because free_pid() also queues pid->rcu; queueing the same rcu_head twice can corrupt the RCU callback list. Original KASAN crash stack: kernel/pid.c:545 pid_nr_ns() # reads freed pid->level kernel/pid.c:556 pid_vnr() # calls pid_nr_ns() kernel/pid.c:775 proc_do_cad_pid() # calls pid_vnr(cad_pid) Fixes: 9ec52099e4b8 ("[PATCH] replace cad_pid by a struct pid") Reported-by: AutonomousCodeSecurity@microsoft.com Closes: https://lore.kernel.org/all/20260717210143.4734-1-blbllhy@gmail.com/ Link: https://lore.kernel.org/all/alz5ZYLE4kaq_v2P@redhat.com/ Link: https://lore.kernel.org/all/al4ICz9biJKtdZc4@redhat.com/ Suggested-by: Mateusz Guzik <mjguzik@gmail.com> Suggested-by: Bradley Morgan <include@grrlz.net> Suggested-by: Oleg Nesterov <oleg@redhat.com> Suggested-by: Eric W. Biederman <ebiederm@xmission.com> Suggested-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com> Cc: stable@vger.kernel.org Signed-off-by: Cen Zhang (Microsoft) <blbllhy@gmail.com> Link: https://patch.msgid.link/20260814040944.16561-1-blbllhy@gmail.com Reviewed-by: Bradley Morgan <include@grrlz.net> Reviewed-by: Oleg Nesterov <oleg@redhat.com> Reviewed-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-08-31signal: allow taks to temporarily block TIF_NOTIFY_SIGNALChristian Brauner2-3/+26
TIF_NOTIFY_SIGNAL is used to kick a task in uninterruptible sleep to return to userspace and run task work and then go back to sleep. This mechanism works well but breaks e.g., coredumps. dump_interrupted() only allows fatal signals to interrupt a coredump and the whole regular write path going to actual filesystems is impervious to TIF_NOTIFY_SIGNAL as well. Add PF_NO_NOTIFY_SIGNAL and helpers to raise and restore it. This is the same approach as memalloc_nofs_save(). signal_pending() will not report a fake pending signal via TIF_NOTIFY_SIGNAL if inside a PF_NO_NOTIFY_SIGNAL section. No functional changes. Link: https://patch.msgid.link/20260824-work-tif_notify_signal-v2-1-6609e42b3157@kernel.org Reviewed-by: Oleg Nesterov <oleg@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-08-31netfs: Fix read progress reportingDavid Howells1-1/+1
For really big read RPC ops that span multiple folios, netfslib allows the filesystem to give progress notifications to wake up the collector thread to do a collection of folios that have now been fetched, even if the RPC is still ongoing, thereby allowing the application to make progress. This works by taking the current rreq->cleaned_to value (which indicates which folios have been unlocked) and adding the stashed size of the next folio to it. cleaned_to, however, is subject to 64-bit tearing on a 32-bit arch. Fix this by stashing the next progress notification point as a size_t (which won't tear) to be added to rreq->start (which won't change), with the collector thread calculating that from cleaned_to plus the next folio size. Further, however, if the folios are small, the collector thread gets constantly woken up - which has a negative performance impact on the system. Fix that too by setting a minimum trigger of 256KiB or the size of the folio at the front of the queue, whichever is larger. Note that this has an issue that different subreqs have different need-to-be-cached properties; this is solved by a preceding patch that marks the property on the folios whilst issuing subreqs rather than when collecting them. Also, make sure rreq->cleaned_to is initialised up front, along with rreq->collected_to and stream->collected_to. Fixes: e2d46f2ec332 ("netfs: Change the read result collector to only use one work item") Link: https://sashiko.dev/#/patchset/20260804100224.2748935-1-dhowells%40redhat.com Signed-off-by: David Howells <dhowells@redhat.com> Link: https://patch.msgid.link/20260827134304.2075713-10-dhowells@redhat.com Acked-by: Paulo Alcantara <pc@manguebit.org> cc: Paulo Alcantara <pc@manguebit.org> cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-08-31netfs: Mark folios with COPY_TO_CACHE whilst issuing subreqsDavid Howells1-1/+1
Mark folios with NETFS_FOLIO_COPY_TO_CACHE whilst issuing subreqs rather than when collecting them. This means that the collector thread doesn't have to try and keep track of which subreqs contribute to which folios - and thus which folios will need to be copied to the cache because at least one byte wasn't in the cache. Instead, this is marked on the folios up front and the collector need only consider the folios. For PG_private_2-using filesystems, PG_private_2 is set instead of NETFS_FOLIO_COPY_TO_CACHE, but otherwise it works the same. The NETFS_RREQ_COPY_TO_CACHE is replaced with NETFS_RREQ_CANCEL_CACHING, which is now set if caching fails somewhere, thereby causing the collection thread to cancel the copy-to-cache marks on the remaining folios. Signed-off-by: David Howells <dhowells@redhat.com> Link: https://patch.msgid.link/20260827134304.2075713-9-dhowells@redhat.com Acked-by: Paulo Alcantara <pc@manguebit.org> cc: Paulo Alcantara (Red Hat) <pc@manguebit.org> cc: Matthew Wilcox <willy@infradead.org> cc: netfs@lists.linux.dev cc: linux-mm@kvack.org cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-08-31netfs: Fix readahead synchronisation issues by loading all folios upfrontDavid Howells2-3/+4
There are some synchronisation issues that derive from the app thread adding more folios to the rolling buffer whilst the collector thread is looking at them or trying to clear them, such as determining the setting of front_folio_order when the next folio hasn't been added yet, The reason for the rolling buffer approach is that loading the buffer upfront and then dropping all the refs just acquired is quite a slow operation, and loading progressively allows some of the cost to be deferred until after at least some of the I/O is started. Instead, a better way is to load all the folios into the rolling buffer upfront - and then drop the refs later, once the I/O is in progress. (Even better would be for the refs not to be there at all.) Fix this by changing the rolling buffer loader to load all the folios selected by the VM for readahead upfront into the folio queue. The folio queue is allocated a batch worth at a time as we don't know how many folios are involved (the readahead_control struct, alas, has a page count, not a folio count). The folio refs acquired from readahead are then dropped in bulk once the first subrequest is dispatched as it's quite a slow operation. The collector waits for NETFS_RREQ_NEED_PUT_RA_REFS to be cleared so that it doesn't unlock folios before the xarray has been scanned for them. This simplifies the buffer handling later and isn't noticeably slower as the xarray doesn't need to be modified and the folios are all already pre-locked. Fixes: ee4cdf7ba857 ("netfs: Speed up buffered reading") Link: https://sashiko.dev/#/patchset/20260824120224.504575-1-dhowells%40redhat.com Signed-off-by: David Howells <dhowells@redhat.com> Link: https://patch.msgid.link/20260827134304.2075713-8-dhowells@redhat.com Acked-by: Paulo Alcantara <pc@manguebit.org> cc: Paulo Alcantara (Red Hat) <pc@manguebit.org> cc: Matthew Wilcox <willy@infradead.org> cc: netfs@lists.linux.dev cc: linux-mm@kvack.org cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-08-31memblock: simplify reset_all_zones_managed_pages()Sang-Heon Jeon1-1/+0
reset_all_zones_managed_pages() is only called from memblock_free_all(), which runs once during boot. So remove the reset_managed_pages_done guard, make the function static and drop its declaration. No functional change. Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com> Link: https://patch.msgid.link/20260819154436.3225746-1-ekffu200098@gmail.com Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
2026-08-31Merge drm/drm-next into drm-misc-nextThomas Zimmermann383-3361/+10897
Getting drm-misc-next up to v7.3-rc1. In exynos, there was a conflict in exynos_dbi_bind(). The merge resolves it to the state of commit 3cc8eee9f346 ("drm/exynos: remove dependency on DRM simple helpers"). Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2026-08-31platform/chrome: cros_ec: Sync host command header with ECDaniel Balint1-0/+72
Sync host command header with the ChromeOS EC firmware. This primarily adds the host command, MKBP event, and related data structures for power monitoring so that the API is available for other drivers. Signed-off-by: Daniel Balint <dbalint@google.com> Link: https://lore.kernel.org/r/20260824155554.1046334-1-dbalint@google.com Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
2026-08-31iio: gts-helper: fix error headersJavier Carrasco1-0/+1
Both industrialio-gts-helper.c and iio-gts-helper.h use error codes defined in <asm-generic/errno-base.h> (usually included via <linux/errno.h>), but only industrialio-gts-helper.c includes it. On the other hand, that file also uses error macros like IS_ERR() and PTR_ERR(), which are included in <linux/err.h>. Add the right includes to provide the used elements from the error headers: - <linux/errno.h> in iio-gts-helper.h - <linux/err.h> in industrialio-gts-helper.c, which in turn includes <asm/errno.h>, which only includes <asm-generic/errno-base.h> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
2026-08-30regulator: pca9450: Support regulator-off-in-suspendFabio Estevam1-0/+3
The PCA9450 uses each regulator's ENMODE field to control whether the regulator remains enabled when the PMIC transitions from RUN to STANDBY mode. The driver does not currently implement set_suspend_disable(), so a regulator configured with regulator-off-in-suspend remains enabled during system suspend. Implement set_suspend_disable() for the buck regulators and LDO3-LDO5. The suspend and runtime controls share ENMODE, so first read the field and leave it unchanged when it is 00b. This preserves the state of a regulator that was already disabled at runtime. For an enabled regulator, program 10b to keep it on in RUN and turn it off while PMIC_STBY_REQ is asserted. Most buck descriptors set enable_val to 01b, while BUCK2 uses 10b. When enable_val is nonzero, regulator_is_enabled_regmap() checks for an exact match. It would therefore report most bucks as disabled after their ENMODE is changed from 01b to 10b, even though all valid nonzero ENMODE values enable the regulator in RUN. Use a custom is_enabled() helper for the buck operation tables that considers a nonzero ENMODE enabled. The LDO descriptors leave enable_val at zero, for which the generic helper already performs this nonzero check, so keep using it for the LDOs. Runtime enable and disable operations remain unchanged: disable writes 00b and enable writes the regulator's default mode. The suspend callback reapplies 10b on each suspend after any intervening runtime operation. Keep LDO1 and LDO2 on regulator operations without set_suspend_disable(), because these regulators supply the SNVS domain and must remain enabled in STANDBY mode. Measured on a custom i.MX8MP board, turning off NVCC_SD2 (LDO5) during system suspend reduced power consumption by approximately 64 mW. Signed-off-by: Fabio Estevam <festevam@nabladev.com> Link: https://patch.msgid.link/20260818014059.351152-2-festevam@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>