summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-05-05ovpn: ensure packet delivery happens with BH disabledRalf Lici
ovpn injects decrypted packets into the netdev RX path through ovpn_netdev_write() which invokes gro_cells_receive() and dev_dstats_rx_add(). ovpn_netdev_write() is normally called in softirq context, however, in case of TCP connections it may also be invoked process context. When this happens gro_cells_receive() will throw a warning: [ 230.183747][ T12] WARNING: net/core/gro_cells.c:30 at gro_cells_receive+0x708/0xaa0, CPU#1: kworker/u16:0/12 and lockdep will also report a potential inconsistent lock state: WARNING: inconsistent lock state 7.0.0-rc4+ #246 Tainted: G W -------------------------------- inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage. because attempts to acquire gro_cells->bh_lock by both contexts may lead to a deadlock. At the same time, dev_dstats_rx_add() does not expect to race with a softirq (which may happen when invoked in process context), because the latter may access its per-cpu state and corrupt it. Fix all this by invoking local_bh_disable/enable() around gro_cells_receive() and dev_dstats_rx_add() to ensure that bottom halves are always disabled before calling both of them. Fixes: 11851cbd60ea ("ovpn: implement TCP transport") Signed-off-by: Ralf Lici <ralf@mandelbit.com> Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
2026-05-05ovpn: reset MAC header before passing skb upQingfang Deng
After decapsulating a packet, the skb->mac_header still points to the outer transport header. Fix this by calling skb_reset_mac_header() in ovpn_netdev_write() to ensure the MAC header points to the beginning of the inner IP/network packet, as expected by the rest of the stack. Reported-by: Minqiang Chen <ptpt52@gmail.com> Fixes: 8534731dbf2d ("ovpn: implement packet processing") Signed-off-by: Qingfang Deng <qingfang.deng@linux.dev> Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
2026-05-04ARM: dts: imx6ul-var-som: add support for LVDS display panelHugo Villeneuve
Add support for the LD configuration option (LVDS encoder assembled on SOM) so that the LVDS display panel on the concerto EVK board works properly. Not all VAR-SOM-6UL SOMs have the LD configuration option so factor out this functionality to a separate dtsi. Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-05-04ARM: dts: imx6ul-var-som: factor out audio supportHugo Villeneuve
Not all boards use the audio codec, so factor out this functionality to a separate dtsi. Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-05-04ARM: dts: imx6ul-var-som: add support for EC configuration option (ENET1)Hugo Villeneuve
ENET1 is currently disabled and not supported/working on the concerto EVK. Add support for this optional configuration in a separate dtsi, so that it can be selectively enabled/disabled. Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-05-04ARM: dts: imx6ul-var-som: factor out ENET2 ethernet supportHugo Villeneuve
Not all boards use the ethernet ENET2 port, so factor out this functionality to a separate dtsi. On the concerto board, this uses the ethernet PHY assembled on it. Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-05-04ARM: dts: imx6ul-var-som: add proper Wifi and Bluetooth supportHugo Villeneuve
Add proper support for the optional Wifi and Bluetooth configuration on VAR-SOM-6UL so that it works out of the box, without any custom scripts. The Wifi/BT module support is mutually exclusive with SD card interface. Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-05-04ARM: dts: imx6ul-var-som: factor out SD card supportHugo Villeneuve
Move SD support to a separate dtsi, since it cannot be used at the same time as the Wifi/BT module. Also not all boards support the SD card. Move pinctrl_usdhc1* to the common imx6ul-var-som-common dtsi so that it can be used by the future Wifi/BT dtsi. Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-05-04ARM: dts: imx6ul-var-som-concerto: order DT propertiesHugo Villeneuve
reorder pinctrl_gpio_leds to respect alphabetical order. Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-05-04ARM: dts: imx6ul-var-som-concerto: Factor out common parts for all CPU variantsHugo Villeneuve
Export common parts to the Variscite VAR-SOM-6UL dtsi so that they can be reused on other boards and to simplify adding future dedicated device tree files for each CPU variant. Move i2c1 pinctrl to var-som dtsi pinmux, so that it can be reused by other boards. Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-05-04ARM: dts: imx6ul-var-som: Factor out common parts for all CPU variantsHugo Villeneuve
Factor out the parts on the Variscite VAR-SOM-6UL [1] that are common to all CPU variants (6UL, 6ULL, etc). This will simplify adding future dedicated device tree files for each CPU variant. Link https://dev.variscite.com/var-som-6ul [1] Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-05-04dt-bindings: arm: fsl: add variscite,var-som-imx6ullHugo Villeneuve
Add support for the imx6ull CPU variant of the Variscite concerto board evaluation kit with a VAR-SOM-6UL. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-05-04dt-bindings: arm: fsl: change incorrect VAR-SOM-MX6UL referencesHugo Villeneuve
There is no Variscite module named VAR-SOM-MX6UL, but there is VAR-SOM-MX6 and also VAR-SOM-6UL, so it is confusing at first to know to which one it refers to. The imx6ul-var-som* dts/dtsi supports only the VAR-SOM-6UL [1], not VAR-SOM-MX6 [2], so modify comments and model descriptions accordingly. Link https://dev.variscite.com/var-som-6ul [1] Link: https://dev.variscite.com/var-som-mx6 [2] Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260305180651.1827087-4-hugo@hugovil.com/ [1] Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-05-04ARM: dts: imx6ul-var-som: change incorrect VAR-SOM-MX6UL referencesHugo Villeneuve
There is no Variscite module named VAR-SOM-MX6UL, but there is VAR-SOM-MX6 and also VAR-SOM-6UL, so it is confusing at first to know to which one it refers to. The imx6ul-var-som* dts/dtsi supports only the VAR-SOM-6UL [1], not VAR-SOM-MX6 [2], so modify comments and model descriptions accordingly. Link https://dev.variscite.com/var-som-6ul [1] Link: https://dev.variscite.com/var-som-mx6 [2] Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-05-04ARM: dts: imx6ul-var-som: fix warning for boolean property with a valueHugo Villeneuve
dmesg warning: OF: /soc/bus@2000000/ethernet@20b4000/mdio/ethernet-phy@3: Read of boolean property 'micrel,rmii-reference-clock-select-25-mhz' with a value. Using of_property_read_bool() for non-boolean properties is deprecated and results in a warning during runtime since commit c141ecc3cecd ("of: Warn when of_property_read_bool() is used on non-boolean properties") micrel,rmii-reference-clock-select-25-mhz is a boolean property and should not have a value, so remove it. Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-05-04ARM: dts: imx6ul-var-som: fix warning for non-existent dc-supply propertyHugo Villeneuve
The dc-supply property is non-existent in Linux now, nor when this DTS file was created when importing it from Variscite own kernel. Therefore remove it to fix this warning: imx6ul-var-som-concerto.dtb: cpu@0 (arm,cortex-a7): Unevaluated properties are not allowed ('dc-supply' was unexpected) from schema $id: http://devicetree.org/schemas/arm/cpus.yaml Fixes: 9d6a67d9c7a9 ("ARM: dts: imx6ul: Add Variscite VAR-SOM-MX6UL SoM support") Cc: stable@kernel.org Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-05-04arm64: dts: add support for NXP i.MX95 15x15 audio board (version 2)Shengjiu Wang
i.MX Audio Board is a configurable and functional audio processing platform. Integrating a variety of audio input and output interfaces into the system, the i.MX Audio Board supports HDMI input, HDMI eARC, S/PDIF I/O, 2-ch ADC line-in, 24-ch DAC line-out and more. Based on these features, rich audio application cases can be realized. This is a basic device tree supporting with i.MX95 15x15 SoC and Audio board (version 2). - Six Cortex-A55 - NXP PCAL6416 GPIO expanders - RGB LEDs via GPIO expander - LPI2C1, LPI2C2, LPI2C3 controllers - LPUART1 (console) - USDHC1 (eMMC), USDHC2 (SD) - Three DAC (AK4458) - One ADC (AK5552) Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-05-04dt-bindings: arm: fsl: Add compatible for i.MX95 15x15 audio board (version 2)Shengjiu Wang
Introduce a new DT compatible string for the NXP i.MX95 15x15 audio board (version 2). i.MX Audio Board is a configurable and functional audio processing platform. Integrating a variety of audio input and output interfaces into the system, the i.MX Audio Board supports HDMI input, HDMI eARC, S/PDIF I/O, 2-ch ADC line-in, 24-ch DAC line-out and more. Based on these features, rich audio application cases can be realized. Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-05-04sched_ext: Add __printf format attributes to scx_vexit() and bstr formattersTejun Heo
scx_vexit() forwards (fmt, args) to vscnprintf(); bstr_format() and __bstr_format() forward fmt to bstr_printf(); the BPF kfunc wrappers scx_bpf_exit_bstr(), scx_bpf_error_bstr() and scx_bpf_dump_bstr() in turn forward fmt to those formatters. None of them have __printf(), so clang -Wmissing-format-attribute fires on the forwarded calls and C-side callers don't get format-string checking. Annotate the six functions with __printf(N, 0) matching the fmt parameter position in each. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/all/202605041112.Y6OG7v9r-lkp@intel.com/ Signed-off-by: Tejun Heo <tj@kernel.org>
2026-05-04nilfs2: reject CLEAN_SEGMENTS ioctl with out-of-range segment numbersDeepanshu Kartikey
Syzbot reported a hung task in nilfs_transaction_begin() where multiple tasks performing chmod() on a nilfs2 mount blocked for over 143 seconds waiting to acquire ns_segctor_sem for read: INFO: task syz.0.17:5918 blocked for more than 143 seconds. Call Trace: schedule+0x164/0x360 rwsem_down_read_slowpath+0x6d9/0x940 down_read+0x99/0x2e0 nilfs_transaction_begin+0x364/0x710 fs/nilfs2/segment.c:221 nilfs_setattr+0x124/0x2c0 fs/nilfs2/inode.c:921 notify_change+0xc1a/0xf40 chmod_common+0x273/0x4a0 do_fchmodat+0x12d/0x230 The writer holding ns_segctor_sem was a concurrent NILFS_IOCTL_CLEAN_SEGMENTS caller, stuck inside printk while emitting per-element warnings from nilfs_sufile_updatev(): __nilfs_msg+0x373/0x450 fs/nilfs2/super.c:78 nilfs_sufile_updatev+0x21c/0x6d0 fs/nilfs2/sufile.c:186 nilfs_sufile_freev fs/nilfs2/sufile.h:93 [inline] nilfs_free_segments fs/nilfs2/segment.c:1140 [inline] nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1261 [inline] nilfs_segctor_do_construct+0x1f55/0x76c0 nilfs_clean_segments+0x3bd/0xa50 nilfs_ioctl_clean_segments fs/nilfs2/ioctl.c:922 [inline] nilfs_ioctl+0x261f/0x2780 The root cause is that user-supplied segment numbers are not validated before nilfs_clean_segments() begins doing work; the range check on each segnum is performed deep inside the call chain by nilfs_sufile_updatev(), which emits a nilfs_warn() per invalid entry while still holding the segctor lock and the sufile mi_sem. Under load (repeated invocations across multiple mounts saturating the global printk path), the cumulative printk latency keeps ns_segctor_sem held long enough to trip the hung_task watchdog, blocking concurrent operations such as chmod() that need ns_segctor_sem for read. Fix by validating the contents of kbufs[4] in nilfs_clean_segments() immediately after acquiring ns_segctor_sem via nilfs_transaction_lock(). Holding ns_segctor_sem serializes the check against nilfs_ioctl_resize(), which can modify ns_nsegments, so the validation uses a consistent value. Out-of-range segment numbers are rejected with -EINVAL before any segment-cleaning work begins, so the bad entries never reach the per-element diagnostic path inside nilfs_sufile_updatev(). Reported-by: syzbot+62f0f99d2f2bb8e3bbd7@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=62f0f99d2f2bb8e3bbd7 Tested-by: syzbot+62f0f99d2f2bb8e3bbd7@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com> Fixes: 071cb4b81987 ("nilfs2: eliminate removal list of segments") Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com> Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
2026-05-04docs: cgroup-v1: Update charge-commit sectionT.J. Mercier
Commit 1d8f136a421f ("memcg/hugetlb: remove memcg hugetlb try-commit-cancel protocol") removed mem_cgroup_commit_charge() and mem_cgroup_cancel_charge(), but the docs still refer to those functions. There is no longer any charge cancellation. Update the docs to match the code. Signed-off-by: T.J. Mercier <tjmercier@google.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2026-05-04sched_ext: idle: Recheck prev_cpu after narrowing allowed maskDavid Carlier
scx_select_cpu_dfl() narrows @allowed to @cpus_allowed & @p->cpus_ptr when the BPF caller supplies a @cpus_allowed that differs from @p->cpus_ptr and @p doesn't have full affinity. However, @is_prev_allowed was computed against the original (wider) @cpus_allowed, so the prev_cpu fast paths could pick a @prev_cpu that is in @cpus_allowed but not in @p->cpus_ptr, violating the intended invariant that the returned CPU is always usable by @p. The kernel masks this via the SCX_EV_SELECT_CPU_FALLBACK fallback, but the behavior contradicts the documented contract. Move the @is_prev_allowed evaluation past the narrowing block so it tests against the final @allowed mask. Fixes: ee9a4e92799d ("sched_ext: idle: Properly handle invalid prev_cpu during idle selection") Cc: stable@vger.kernel.org # v6.16+ Assisted-by: Claude <noreply@anthropic.com> Signed-off-by: David Carlier <devnexen@gmail.com> Reviewed-by: Andrea Righi <arighi@nvidia.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2026-05-04sched_ext: Normalize exit dump header to "on CPU N"Cheng-Yang Chou
Unify to uppercase to match the UEI output. Signed-off-by: Cheng-Yang Chou <yphbchou0911@gmail.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2026-05-04sched_ext: Remove redundant rcu_read_lock/unlock() in ↵Zqiang
sysrq_handle_sched_ext_reset() sysrq_handle_sched_ext_reset() is called from __handle_sysrq(), which already holds rcu_read_lock() while invoking the sysrq handler. Remove the redundant rcu_read_lock/unlock() pair. Signed-off-by: Zqiang <qiang.zhang@linux.dev> Reviewed-by: Cheng-Yang Chou <yphbchou0911@gmail.com> Reviewed-by: Andrea Righi <arighi@nvidia.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2026-05-04drm/sti: remove bridge when sti_hda component_add failsOsama Abdelkader
Use devm_drm_bridge_add() so the bridge is released if probe fails after registration, and drop the manual drm_bridge_remove() in remove(). Check the return value of devm_drm_bridge_add(). Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com> Fixes: d28726efc637 ("drm/sti: hda: add bridge before attaching") Cc: stable@vger.kernel.org Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Acked-by: Raphaël Gallais-Pou <rgallaispou@gmail.com> Link: https://patch.msgid.link/20260423200622.325076-1-osama.abdelkader@gmail.com Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
2026-05-04docs: kselftest: Document the FORCE_TARGETS build variableRicardo B. Marlière
FORCE_TARGETS has been part of the kselftest build system for some time but is absent from the developer documentation. Without an entry here, users relying on kselftest in CI pipelines would have to read the selftests Makefile directly to discover the option. A build that exits zero despite some targets failing can mask real breakage and mislead automated systems into reporting success. Add a dedicated section so that CI authors can easily find and adopt FORCE_TARGETS=1 to turn such silent partial failures into hard errors. Link: https://lore.kernel.org/r/20260417-selftests-docs-v1-1-32e4a78214eb@suse.com Signed-off-by: Ricardo B. Marlière <rbm@suse.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2026-05-04isa: switch to dynamic root deviceJohan Hovold
Driver core expects devices to be dynamically allocated and will, for example, complain loudly if a device that lacks a release function is ever freed. Use root_device_register() to allocate and register the root device instead of open coding using a static device. Note that this also fixes a reference leak in case device_register() fails which may be flagged by static checkers. Signed-off-by: Johan Hovold <johan@kernel.org> Acked-by: William Breathitt Gray <wbg@kernel.org> Link: https://patch.msgid.link/20260424102400.2615677-1-johan@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-04Merge tag 'for-linus-7.1-2' of https://github.com/cminyard/linux-ipmiLinus Torvalds
Pull IPMI fixes from Corey Minyard: "Fix a number of issues that came up recently The first two fixes are workarounds for buggy IPMI hardware. The hardware says it has data for the IPMI driver to read constantly, so the driver reads the data constantly, causing any new requests to be blocked. The first fix was to check for invalid data right when the data was read from the device and stop the operation there (there was a later check for invalid data, but it could not stop the operation at that point). It turned out the device was providing good data, so that didn't fix the issue, but it's still a good check. The second fix stops fetching this data after a few fetches and allows other operations to occur. The driver won't work very well, but at least it won't wedge. This seems to fix the issue. The third issue is a problem I spotted while working on the previous issue where if a certain memory allocation failed the driver would stop working. The fourth issue is a problem was a missing set to NULL on a PTR_ERR() return, introduced in the previous series for 7.1" * tag 'for-linus-7.1-2' of https://github.com/cminyard/linux-ipmi: ipmi:ssif: NULL thread on error ipmi:si: Return state to normal if message allocation fails ipmi: Add limits to event and receive message requests ipmi: Check event message buffer response for bad data
2026-05-04driver core: class: fix typo in struct class documentationPrabhudasu Vatala
Fix a spelling error in the comment for the ns_type member of struct class. Change "detemine" to "determine". Signed-off-by: Prabhudasu Vatala <prabhudasuvatala@gmail.com> Link: https://patch.msgid.link/20260503141826.27462-1-prabhudasuvatala@gmail.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-04kunit: Fix spelling mistakes in comments and messagesJinseok Kim
Fix two spelling mistakes in kunit tooling: Bascially -> Basically higer -> higher Link: https://lore.kernel.org/r/20260501162739.3861-1-always.starving0@gmail.com Signed-off-by: Jinseok Kim <always.starving0@gmail.com> Reviewed-by: David Gow <david@davidgow.net> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2026-05-04kunit: qemu_configs: Add or1k / openrisc configurationThomas Weißschuh
Add a basic configuration to run kunit tests on or1k / openrisc. Link: https://lore.kernel.org/r/20260427-kunit-or1k-v1-2-9d3109e991e8@weissschuh.net Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: David Gow <david@davidgow.net> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2026-05-04gen_compile_commands: Ignore libgcc.aThomas Weißschuh
Some architectures link libgcc.a from the toolchain into the kernel. gen_compile_commands trie to read the kbuild .cmd files of its constituent object files, which are not available. Flat out ignore libgcc.a, as it is not built as part of the kernel anyways. Link: https://lore.kernel.org/r/20260427-kunit-or1k-v1-1-9d3109e991e8@weissschuh.net Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2026-05-04sched_ext: Skip past-sched_ext_dead() tasks in scx_task_iter_next_locked()Tejun Heo
scx_task_iter's cgroup-scoped mode can return tasks whose sched_ext_dead() has already completed: cgroup_task_dead() removes from cset->tasks after sched_ext_dead() in finish_task_switch() and is irq-work deferred on PREEMPT_RT. The global mode is fine - sched_ext_dead() removes from scx_tasks via list_del_init() first. Callers (sub-sched enable prep/abort/apply, scx_sub_disable(), scx_fail_parent()) assume returned tasks are still on @sch and trip WARN_ON_ONCE() or operate on torn-down state otherwise. Set %SCX_TASK_OFF_TASKS in sched_ext_dead() under @p's rq lock and have scx_task_iter_next_locked() skip flagged tasks under the same lock. Setter and reader serialize on the per-task rq lock - no race. Signed-off-by: Tejun Heo <tj@kernel.org>
2026-05-04cgroup, sched_ext: Include exiting tasks in cgroup iterTejun Heo
a72f73c4dd9b ("cgroup: Don't expose dead tasks in cgroup") made css_task_iter_advance() skip exiting tasks so cgroup.procs stays consistent with waitpid() visibility. Unfortunately, this broke scx_task_iter. scx_task_iter walks either scx_tasks (global) or a cgroup subtree via css_task_iter() and the two modes are expected to cover the same set of tasks. After the above change the cgroup-scoped mode silently skips tasks past exit_signals() that are still on scx_tasks. scx_sub_enable_workfn()'s abort path is one of the symptoms: an exiting SCX_TASK_SUB_INIT task can race past the cgroup iter leaking __scx_init_task() state. Other iterations share the same gap. Add CSS_TASK_ITER_WITH_DEAD to opt out of the skip and use it from scx_task_iter(). Fixes: b0e4c2f8a0f0 ("sched_ext: Implement cgroup subtree iteration for scx_task_iter") Reported-by: Cheng-Yang Chou <yphbchou0911@gmail.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2026-05-04MAINTAINERS: Update mail for Peter RosinPeter Rosin
I'm resigning from my position at Axentia. Signed-off-by: Peter Rosin <peda@lysator.liu.se> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2026-05-04cgroup: Defer css percpu_ref kill on rmdir until cgroup is depopulatedTejun Heo
A chain of commits going back to v7.0 reworked rmdir to satisfy the controller invariant that a subsystem's ->css_offline() must not run while tasks are still doing kernel-side work in the cgroup. [1] d245698d727a ("cgroup: Defer task cgroup unlink until after the task is done switching out") [2] a72f73c4dd9b ("cgroup: Don't expose dead tasks in cgroup") [3] 1b164b876c36 ("cgroup: Wait for dying tasks to leave on rmdir") [4] 4c56a8ac6869 ("cgroup: Fix cgroup_drain_dying() testing the wrong condition") [5] 13e786b64bd3 ("cgroup: Increment nr_dying_subsys_* from rmdir context") [1] moved task cset unlink from do_exit() to finish_task_switch() so a task's cset link drops only after the task has fully stopped scheduling. That made tasks past exit_signals() linger on cset->tasks until their final context switch, which led to a series of problems as what userspace expected to see after rmdir diverged from what the kernel needs to wait for. [2]-[5] tried to bridge that divergence: [2] filtered the exiting tasks from cgroup.procs; [3] had rmdir(2) sleep in TASK_UNINTERRUPTIBLE for them; [4] fixed the wait's condition; [5] made nr_dying_subsys_* visible synchronously. The cgroup_drain_dying() wait in [3] turned out to be a dead end. When the rmdir caller is also the reaper of a zombie that pins a pidns teardown (e.g. host PID 1 systemd reaping orphan pids that were re-parented to it during the same teardown), rmdir blocks in TASK_UNINTERRUPTIBLE waiting for those pids to free, the pids can't free because PID 1 is the reaper and it's stuck in rmdir, and the system A-A deadlocks. No internal lock ordering breaks this; the wait itself is the bug. The css killing side that drove the original reorder, however, can be made cleanly asynchronous: ->css_offline() is already async, run from css_killed_work_fn() driven by percpu_ref_kill_and_confirm(). The fix is to make that chain start only after all tasks have left the cgroup. rmdir's user-visible side then returns as soon as cgroup.procs and friends are empty, while ->css_offline() still runs only after the cgroup is fully drained. Verified by the original reproducer (pidns teardown + zombie reaper, runs under vng) which hangs vanilla and succeeds here, and by per-commit deterministic repros for [2], [3], [4], [5] with a boot parameter that widens the post-exit_signals() window so each state is reliably reachable. Some stress tests on top of that. cgroup_apply_control_disable() has the same shape of pre-existing race: when a controller is disabled via subtree_control, kill_css() ran synchronously while tasks past exit_signals() could still be linked to the cgroup's csets, and ->css_offline() could fire before they drained. This patch preserves the existing synchronous behavior at that call site (kill_css_sync() + kill_css_finish() back-to-back) and a follow-up patch will defer kill_css_finish() there using a per-css trigger. This seems like the right approach and I don't see problems with it. The changes are somewhat invasive but not excessively so, so backporting to -stable should be okay. If something does turn out to be wrong, the fallback is to revert the entire chain ([1]-[5]) and rework in the development branch instead. v2: Pin cgrp across the deferred destroy work with explicit cgroup_get()/cgroup_put() around queue_work() and the work_fn. v1 wasn't actually broken (ordered cgroup_offline_wq + queue_work order in cgroup_task_dead() saved it) but the explicit ref removes the dependency on those non-obvious invariants. Also note the pre-existing cgroup_apply_control_disable() race in the description; a follow-up will defer kill_css_finish() there. Fixes: 1b164b876c36 ("cgroup: Wait for dying tasks to leave on rmdir") Cc: stable@vger.kernel.org # v7.0+ Reported-and-tested-by: Martin Pitt <martin@piware.de> Link: https://lore.kernel.org/all/afHNg2VX2jy9bW7y@piware.de/ Link: https://lore.kernel.org/all/35e0670adb4abeab13da2c321582af9f@kernel.org/ Signed-off-by: Tejun Heo <tj@kernel.org> Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
2026-05-04memory: tegra: Add Tegra114 EMC driverSvyatoslav Ryhel
Introduce driver for the External Memory Controller (EMC) found in Tegra114 SoC. It controls the external DRAM on the board. The purpose of this driver is to program memory timing for external memory on the EMC clock rate change. Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com> Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com> Link: https://patch.msgid.link/20260427070312.81679-5-clamor95@gmail.com Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-05-04memory: tegra: Implement EMEM regs and ICC ops for Tegra114Svyatoslav Ryhel
Prepare Internal Memory Controller for introduction of External Memory Controller. Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com> Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com> Link: https://patch.msgid.link/20260427070312.81679-3-clamor95@gmail.com Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-05-04Merge branch 'for-v7.2/tegra114-mc-bindings' into mem-ctrl-nextKrzysztof Kozlowski
2026-05-04dt-bindings: memory: Document Tegra114 External Memory ControllerSvyatoslav Ryhel
Include Tegra114 support into existing Tegra124 EMC schema with the most notable difference being the amount of EMC timings and a few SoC unique entries. Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260427070312.81679-4-clamor95@gmail.com Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-05-04dt-bindings: memory: Document Tegra114 Memory ControllerSvyatoslav Ryhel
Add Tegra114 support into existing Tegra124 MC schema with the most notable difference in the amount of EMEM timings. Each memory client has unique hardware ID, add these IDs. Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260427070312.81679-2-clamor95@gmail.com Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-05-04kunit: config: KUNIT_DEBUGFS should depend on DEBUG_FSDavid Gow
CONFIG_KUNIT_DEBUGFS is totally useless without debugfs, so it should depend on CONFIG_DEBUG_FS. Link: https://lore.kernel.org/r/20260425034155.53913-2-david@davidgow.net Fixes: e2219db280e3 ("kunit: add debugfs /sys/kernel/debug/kunit/<suite>/results display") Signed-off-by: David Gow <david@davidgow.net> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2026-05-04kunit: config: Enable KUNIT_DEBUGFS by defaultDavid Gow
The KUNIT_DEBUGFS option is currently enabled based on the value of KUNIT_ALL_TESTS, but it really doesn't have anything to do with the set of enabled tests, so just enable it by default anyway. In particular, this shouldn't be only visible if KUNIT_ALL_TESTS is set, which is quite confusing. Link: https://lore.kernel.org/r/20260425034155.53913-1-david@davidgow.net Fixes: beaed42c427d ("kunit: default KUNIT_* fragments to KUNIT_ALL_TESTS") Signed-off-by: David Gow <david@davidgow.net> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2026-05-04memory: tegra: Add Tegra238 MC supportAshish Mhetre
Add Memory Controller driver support for Tegra238 SOC, including: - MC client definitions with Tegra238-specific stream IDs - Reuse of Tegra234 ICC operations for bandwidth management via BPMP-FW - Device tree compatible string "nvidia,tegra238-mc" Export tegra234_mc_icc_ops so it can be shared with the Tegra238 MC driver, as both SoCs use the same ICC aggregation and bandwidth management logic. Signed-off-by: Ashish Mhetre <amhetre@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20260427073419.567360-3-amhetre@nvidia.com Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-05-04dt-bindings: memory: tegra: Add nvidia,tegra238-mc compatibleAshish Mhetre
Document the device tree binding for the Tegra238 memory controller. Tegra238 has 8 memory controller channels plus broadcast and stream-id registers. Add the stream ID header (nvidia,tegra238-mc.h) defining ISO and NISO stream IDs for SMMU configuration. Signed-off-by: Ashish Mhetre <amhetre@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20260427073419.567360-2-amhetre@nvidia.com Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-05-04memory: tegra: Restore MC interrupt masks on resumeAshish Mhetre
The MC interrupt mask registers lose their state across Tegra low power suspend state (aka. SC7). Without re-applying them on resume, MC interrupts that were enabled at probe remain masked after wake, so any post-resume MC error goes unreported. Factor the existing intmask programming out of tegra_mc_probe() into tegra_mc_setup_intmask() and reuse it from the system resume callback so the mask state is restored on wake. Signed-off-by: Ashish Mhetre <amhetre@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20260430095202.1167651-4-amhetre@nvidia.com Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-05-04memory: tegra: Wire up system sleep PM opsAshish Mhetre
The tegra-mc platform driver does not register any dev_pm_ops, so the SoC-specific ->resume() is never invoked (e.g. tegra186_mc_resume) on system wake. On Tegra186 and later this means MC client Stream-ID override registers are not reprogrammed, and clients behind the ARM SMMU fault on the first DMA after resume. Register a dev_pm_ops on the tegra-mc driver and route the system resume callback into mc->soc->ops->resume() so the existing SID restore path runs again on wake. No suspend callback is needed as the resume path reprograms all MC state from the static SoC tables, so there is nothing to save. Fixes: fe3b082a6eb8 ("memory: tegra: Add SID override programming for MC clients") Signed-off-by: Ashish Mhetre <amhetre@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20260430095202.1167651-3-amhetre@nvidia.com Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-05-04memory: tegra: Make ->resume() callback return voidAshish Mhetre
tegra186_mc_resume() is the only implementation of the SoC ->resume() op in struct tegra_mc_ops, and it can never fail as the SID override loop has no error path. The int return value is therefore not used. Change the prototype to return void so callers do not need to deal with a value that is always 0. If a future SoC needs to report failure from resume, an int return type can be reintroduced then. Signed-off-by: Ashish Mhetre <amhetre@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20260430095202.1167651-2-amhetre@nvidia.com Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-05-04memory: tegra: Deduplicate rate request management codeMikko Perttunen
As is, the EMC drivers for each 32-bit platform contain almost identical duplicated code for aggregating rate requests. Move this code out to a shared tegra-emc-common file to reduce duplication, and add kerneldoc comments. Based on code from the tegra20-emc driver. Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Link: https://patch.msgid.link/20260501-memory-refactor-v3-1-69fb1ae1a7ca@nvidia.com Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-05-04memory: atmel-ebi: Allow deferred probingAlexander Dahl
After removing of_platform_default_populate() calls the atmel-ebi driver was affected by deferred probing. platform_driver_probe() is incompatible with deferred probing. This led to atmel-ebi driver eventually not being probed on at91 sam9x60-curiosity and other sam9x60 based boards. Subsequently the nand-controller driver (nand-controller being a child node of ebi) on that platform was not probed and thus raw NAND flash was inaccessible, preventing devices to boot with rootfs on raw NAND flash (e.g. with UBI/UBIFS). Fixes: 0b0f7e6539a7 ("ARM: at91: remove unnecessary of_platform_default_populate calls") Cc: stable@vger.kernel.org Suggested-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Alexander Dahl <ada@thorsis.com> Link: https://patch.msgid.link/20260429125930.844790-1-ada@thorsis.com Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
generated by cgit v1.2.3 (git 2.25.1) at 2026-09-11 22:44:32 +0000