aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2026-02-03net: stmmac: rk: remove rk3528 RMII clock initialisationRussell King (Oracle)1-2/+1
There is no need to pre-initialise the rk3528 RMII clock when selecting RMII mode on gmac0. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1vmqn1-00000007VCh-47Sv@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-03net: stmmac: rk: convert rk3588 to rk_set_reg_speed()Russell King (Oracle)1-29/+34
Update rk_set_reg_speed() to use either the grf or php_grf regmap depending on the SoC's requirements and convert rk3588, removing its custom code. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1vmqmw-00000007VCb-3glG@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-03net: stmmac: rk: move speed GRF register offset to private dataRussell King (Oracle)1-33/+81
Move the speed/clocking related GRF register offset into the driver private data, convert rk_set_reg_speed() to use it and initialise this member either from the corresponding member in struct rk_gmac_ops, or the SoC specific initialisation function. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1vmqmr-00000007VCV-3Cz8@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-03net: stmmac: rk: convert rk3588 to mask-based interface mode configRussell King (Oracle)1-10/+35
rk3588 has a quirk compared to the other Rockchip implementations in that the interface mode configuration register is in the php_grf regmap rather than the grf regmap. Add a flag to indicate this, and a separate function to write to the appropriate regmap. This allows rk3588 to be converted. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1vmqmm-00000007VCP-2XZc@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-03net: stmmac: rk: convert to mask-based interface mode configurationRussell King (Oracle)1-101/+156
The majority of Rockchip implementations require three common pieces of information to configure the PHY interface mode: - The grf register offset for configuring the GMAC phy_intf_sel field and the RMII mode bit. - The bitfield in this register for the GMAC's phy_intf_sel. - The bit position for RMII mode but clear for RGMII mode. Introduce members for this information into struct rk_priv_data and struct rk_gmac_ops, which will be used to pre-initialise the struct rk_priv_data members. We describe the register contents using bitfields, even for those that are a single bit for consistency. As each register comprises of two halves, where the upper half enables changing the bit state in the lower half, we can describe these bitfields using a 16-bit data type, and provide rk_encode_wm16() to generate the actual register values from the field mask and field value. We are unable to use the FIELD_PREP_WM16() macros for this as these require the field mask to be a constant. Add code to rk_gmac_powerup() to get the phy_intf_sel value, validating that the resulting mode is either RMII or RGMII. No other modes are supported by any of the Rockchip SoCs supported by this driver. If either of the bitfield mask values are populated in struct rk_priv_data, use these to generate the register contents, and write the resulting value to the specified GRF register. Convert many Rockchip implementations to use this new infrastructure. For those where there is a single GMAC instance, it is merely a case of filling in the new members of struct rk_gmac_ops. For those with multiple instances, one or more of these members depends on the GMAC instance, so setup of the members in struct rk_gmac has to be done via the .init method of struct rk_gmac_ops. The corresponding code is removed from the set_to_rgmii() and set_to_rmii() implementations. Since the member name documents the purpose of the field that is being initialised, providing preprocessor macros to define the bitfields is deemed to be less than useful given the massive size of this driver. The existing mechanisms remain behind for those SoCs that can not be converted to this scheme. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> v2: disable clocks on failure Link: https://patch.msgid.link/E1vmqmh-00000007VCJ-1xns@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-03fs/tests: exec: drop duplicate bprm_stack_limits test vectorsTitouan Ameline de Cadeville1-6/+0
Remove duplicate entries from the bprm_stack_limits KUnit test vector table. The duplicates do not add coverage and only increase test size. Signed-off-by: Titouan Ameline de Cadeville <titouan.ameline@gmail.com> Fixes: 60371f43e56b ("exec: Add KUnit test for bprm_stack_limits()") Link: https://patch.msgid.link/20260203175950.43710-1-titouan.ameline@gmail.com Signed-off-by: Kees Cook <kees@kernel.org>
2026-02-03Merge branch 'bpf-avoid-locks-in-bpf_timer-and-bpf_wq'Andrii Nakryiko7-342/+851
Alexei Starovoitov says: ==================== bpf: Avoid locks in bpf_timer and bpf_wq From: Alexei Starovoitov <ast@kernel.org> This series reworks implementation of BPF timer and workqueue APIs to make them usable from any context. Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com> Changes in v9: - Different approach for patches 1 and 3: - s/EBUSY/ENOENT/ when refcnt==0 to match existing - drop latch, use refcnt and kmalloc_nolock() instead - address race between timer/wq_start and delete_elem, add a test - Link to v8: https://lore.kernel.org/bpf/20260127-timer_nolock-v8-0-5a29a9571059@meta.com/ Changes in v8: - Return -EBUSY in bpf_async_read_op() if last_seq is failed to be set - In bpf_async_cancel_and_free() drop bpf_async_cb ref after calling bpf_async_process() - Link to v7: https://lore.kernel.org/r/20260122-timer_nolock-v7-0-04a45c55c2e2@meta.com Changes in v7: - Addressed Andrii's review points from the previous version - nothing very significang. - Added NMI stress tests for bpf_timer - hit few verifier failing checks and removed them. - Address sparse warning in the bpf_async_update_prog_callback() - Link to v6: https://lore.kernel.org/r/20260120-timer_nolock-v6-0-670ffdd787b4@meta.com Changes in v6: - Reworked destruction and refcnt use: - On cancel_and_free() set last_seq to BPF_ASYNC_DESTROY value, drop map's reference - In irq work callback, atomically switch DESTROY to DESTROYED, cancel timer/wq - Free bpf_async_cb on refcnt going to 0. - Link to v5: https://lore.kernel.org/r/20260115-timer_nolock-v5-0-15e3aef2703d@meta.com Changes in v5: - Extracted lock-free algorithm for updating cb->prog and cb->callback_fn into a function bpf_async_update_prog_callback(), added a new commit and introduces this function and uses it in __bpf_async_set_callback(), bpf_timer_cancel() and bpf_async_cancel_and_free(). This allows to move the change into the separate commit without breaking correctness. - Handle NULL prog in bpf_async_update_prog_callback(). - Link to v4: https://lore.kernel.org/r/20260114-timer_nolock-v4-0-fa6355f51fa7@meta.com Changes in v4: - Handle irq_work_queue failures in both schedule and cancel_and_free paths: introduced bpf_async_refcnt_dec_cleanup() that decrements refcnt and makes sure if last reference is put, there is at least one irq_work scheduled to execute final cleanup. - Additional refcnt inc/dec in set_callback() + rcu lock to make sure cleanup is not running at the same time as set_callback(). - Added READ_ONCE where it was needed. - Squash 'bpf: Refactor __bpf_async_set_callback()' commit into 'bpf: Add lock-free cell for NMI-safe async operations' - Removed mpmc_cell, use seqcount_latch_t instead. - Link to v3: https://lore.kernel.org/r/20260107-timer_nolock-v3-0-740d3ec3e5f9@meta.com Changes in v3: - Major rework - Introduce mpmc_cell, allowing concurrent writes and reads - Implement irq_work deferring - Adding selftests - Introduces bpf_timer_cancel_async kfunc - Link to v2: https://lore.kernel.org/r/20251105-timer_nolock-v2-0-32698db08bfa@meta.com Changes in v2: - Move refcnt initialization and put (from cancel_and_free()) from patch 5 into the patch 4, so that patch 4 has more clear and full implementation and use of refcnt - Link to v1: https://lore.kernel.org/r/20251031-timer_nolock-v1-0-b064ae403bfb@meta.com ==================== Link: https://patch.msgid.link/20260201025403.66625-1-alexei.starovoitov@gmail.com Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
2026-02-03selftests/bpf: Add a test to stress bpf_timer_start and map_delete raceAlexei Starovoitov2-0/+203
Add a test to stress bpf_timer_start and map_delete race Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20260201025403.66625-10-alexei.starovoitov@gmail.com
2026-02-03selftests/bpf: Removed obsolete testsMykyta Yatsenko1-111/+0
Now bpf_timer can be used in tracepoints, so these tests are no longer relevant. Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20260201025403.66625-9-alexei.starovoitov@gmail.com
2026-02-03selftests/bpf: Add timer stress test in NMI contextMykyta Yatsenko2-12/+231
Add stress tests for BPF timers that run in NMI context using perf_event programs attached to PERF_COUNT_HW_CPU_CYCLES. The tests cover three scenarios: - nmi_race: Tests concurrent timer start and async cancel operations - nmi_update: Tests updating a map element (effectively deleting and inserting new for array map) from within a timer callback - nmi_cancel: Tests timer self-cancellation attempt. A common test_common() helper is used to share timer setup logic across all test modes. The tests spawn multiple threads in a child process to generate perf events, which trigger the BPF programs in NMI context. Hit counters verify that the NMI code paths were actually exercised. Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20260201025403.66625-8-alexei.starovoitov@gmail.com
2026-02-03selftests/bpf: Verify bpf_timer_cancel_async worksMykyta Yatsenko2-0/+48
Add test that verifies that bpf_timer_cancel_async works: can cancel callback successfully. Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20260201025403.66625-7-alexei.starovoitov@gmail.com
2026-02-03selftests/bpf: Add stress test for timer async cancelMykyta Yatsenko2-4/+28
Extend BPF timer selftest to run stress test for async cancel. Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20260201025403.66625-6-alexei.starovoitov@gmail.com
2026-02-03selftests/bpf: Refactor timer selftestsMykyta Yatsenko1-19/+36
Refactor timer selftests, extracting stress test into a separate test. This makes it easier to debug test failures and allows to extend. Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20260201025403.66625-5-alexei.starovoitov@gmail.com
2026-02-03bpf: Introduce bpf_timer_cancel_async() kfuncAlexei Starovoitov1-0/+48
Introduce bpf_timer_cancel_async() that wraps hrtimer_try_to_cancel() and executes it either synchronously or defers to irq_work. Co-developed-by: Mykyta Yatsenko <yatsenko@meta.com> Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20260201025403.66625-4-alexei.starovoitov@gmail.com
2026-02-03bpf: Add verifier support for bpf_timer argument in kfuncsMykyta Yatsenko1-18/+37
Extend the verifier to recognize struct bpf_timer as a valid kfunc argument type. Previously, bpf_timer was only supported in BPF helpers. This prepares for adding timer-related kfuncs in subsequent patches. Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20260201025403.66625-3-alexei.starovoitov@gmail.com
2026-02-03bpf: Enable bpf_timer and bpf_wq in any contextAlexei Starovoitov1-183/+225
Refactor bpf_timer and bpf_wq to allow calling them from any context: - add refcnt to bpf_async_cb - map_delete_elem or map_free will drop refcnt to zero via bpf_async_cancel_and_free() - once refcnt is zero timer/wq_start is not allowed to make sure that callback cannot rearm itself - if in_hardirq defer to start/cancel operations to irq_work Co-developed-by: Mykyta Yatsenko <yatsenko@meta.com> Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Link: https://lore.kernel.org/bpf/20260201025403.66625-2-alexei.starovoitov@gmail.com
2026-02-04fs/ntfs3: allow explicit boolean acl/prealloc mount optionsKonstantin Komarov1-6/+14
This patch improves mount option parsing by allowing explicit boolean values for acl and prealloc. Previously those options were exposed only as presence/absence flags. Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
2026-02-03Merge tag 'v6.19rc8-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6Linus Torvalds2-1/+4
Pull smb client fixes from Steve French: "Two small client memory leak fixes" * tag 'v6.19rc8-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6: smb/client: fix memory leak in SendReceive() smb/client: fix memory leak in smb2_open_file()
2026-02-03scripts/make_fit: Compress dtbs in parallelSimon Glass1-6/+50
When there are 1500 device tree files it takes quite a while to compress them. Do it in parallel. Signed-off-by: Simon Glass <sjg@chromium.org> Link: https://patch.msgid.link/20260106162738.2605574-7-sjg@chromium.org Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2026-02-03scripts/make_fit: Support a few more parallel compressorsSimon Glass1-3/+9
Add support for pbzip2, xz and plzip which can compress in parallel. This speeds up the ramdisk compression. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Nicolas Schier <nsc@kernel.org> Link: https://patch.msgid.link/20260106162738.2605574-6-sjg@chromium.org Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2026-02-03kbuild: Support a FIT_EXTRA_ARGS environment variableSimon Glass1-1/+1
In some cases it is useful to be able to pass additional flags to the make_fit.py script. For example, since ramdisks are typically large, passing -E to use external data can be helpful. Add a new FIT_EXTRA_ARGS variable for this. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Nicolas Schier <nsc@kernel.org> Reviewed-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Link: https://patch.msgid.link/20260106162738.2605574-5-sjg@chromium.org Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2026-02-03scripts/make_fit: Move dtb processing into a functionSimon Glass1-23/+44
Since build_fit() is getting quite long, move the dtb processing into a separate function. Change the double quotes in the write() call to single, to match the rest of the script. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Nicolas Schier <nsc@kernel.org> Reviewed-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://patch.msgid.link/20260106162738.2605574-4-sjg@chromium.org Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2026-02-03scripts/make_fit: Support an initial ramdiskSimon Glass1-8/+44
FIT (Flat Image Tree) allows a ramdisk to be included in each configuration. Add support for this to the script. This feature is not available via 'make image.fit' since the ramdisk likely needs to be built separately anyway, e.g. using modules from the kernel build. Future work may provide support for doing that. Note that the uncompressed size is not correct when a ramdisk is used, since it is too expensive to decompress the ramdisk. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Nicolas Schier <nsc@kernel.org> Reviewed-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Link: https://patch.msgid.link/20260106162738.2605574-3-sjg@chromium.org Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2026-02-03scripts/make_fit: Speed up operationSimon Glass1-2/+4
The kernel is likely at least 16MB so we may as well use that as a step size when reallocating space for the FIT in memory. Pack the FIT at the end, so there is no wasted space. This reduces the time to pack by an order of magnitude, or so. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Nicolas Schier <nsc@kernel.org> Reviewed-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://patch.msgid.link/20260106162738.2605574-2-sjg@chromium.org Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2026-02-03PCI: dwc: ep: Add comment explaining controller level PTM access in multi PF ↵Aksh Garg1-0/+12
setup PCIe r6.0, section 7.9.15 requires PTM capability in exactly one function to control all PTM-capable functions. This makes PTM registers controller level rather than per-function. Add a comment explaining why PTM capability registers are accessed using the standard DBI accessors instead of func_no indexed per-function accessors. Suggested-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Aksh Garg <a-garg7@ti.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Niklas Cassel <cassel@kernel.org> Link: https://patch.msgid.link/20260130115516.515082-4-a-garg7@ti.com
2026-02-03PCI: dwc: ep: Add per-PF BAR and inbound ATU mapping supportAksh Garg2-37/+54
The commit 24ede430fa49 ("PCI: designware-ep: Add multiple PFs support for DWC") added support for multiple PFs in the DWC driver, but the implementation was incomplete. It did not properly support MSI/MSI-X, as well as BAR and inbound ATU mapping for multiple PFs. The MSI/MSI-X issue was later fixed by commit 47a062609a30 ("PCI: designware-ep: Modify MSI and MSIX CAP way of finding") by introducing a per-PF struct dw_pcie_ep_func. However, even with both commits, the multiple PF support in the driver remains broken because BAR configuration and ATU mappings are managed globally in struct dw_pcie_ep, meaning all PFs share the same BAR-to-ATU mapping table. This causes one PF's EPF to overwrite the address translation of another PF's EPF in the internal ATU region, creating conflicts when multiple physical functions attempt to configure their BARs independently. The commit cfbc98dbf44d ("PCI: dwc: ep: Support BAR subrange inbound mapping via Address Match Mode iATU") later introduced Address Match Mode support, which suffers from the same multi-PF conflict issue. Fix this by moving the required members from struct dw_pcie_ep to struct dw_pcie_ep_func, similar to what commit 47a062609a30 ("PCI: designware-ep: Modify MSI and MSIX CAP way of finding") did for MSI/MSI-X capability support, to allow proper multi-function endpoint operation, where each PF can configure its BARs and corresponding internal ATU region without interfering with other PFs. Fixes: 24ede430fa49 ("PCI: designware-ep: Add multiple PFs support for DWC") Fixes: cc839bef7727 ("PCI: dwc: ep: Support BAR subrange inbound mapping via Address Match Mode iATU") Signed-off-by: Aksh Garg <a-garg7@ti.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Niklas Cassel <cassel@kernel.org> Link: https://patch.msgid.link/20260130115516.515082-3-a-garg7@ti.com
2026-02-03rust: kconfig: Don't require RUST_IS_AVAILABLE for rustc-optionMatthew Maurer1-2/+0
The final version of this macro does not fail in the absence of an invokable `$(RUSTC)`, so we don't need to be careful not to invoke it. Link: https://lore.kernel.org/all/CAGSQo01mQfcU1EiW53be1hcts0c1p-HQAab_HBk6VcVmhq3n2Q@mail.gmail.com/ Signed-off-by: Matthew Maurer <mmaurer@google.com> Link: https://patch.msgid.link/20250909-docrem-v1-1-dcc69059a5cb@google.com Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2026-02-03MAINTAINERS: Add scripts/install.sh into Kbuild entryTiezhu Yang1-0/+1
The common installation code is in scripts/install.sh, add it into Kbuild entry to reflect the reality. With this updated entry, folks running get_maintainer.pl on patches that touch scripts/install.sh will know to send it to linux-kbuild@ as well. Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Link: https://patch.msgid.link/20260120123730.30487-2-yangtiezhu@loongson.cn [nathan: Alphabetize entry] Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2026-02-03modpost: Amend ppc64 save/restfpr symnames for -Os buildRené Rebe1-0/+4
Building a size optimized ppc64 kernel (-Os), gcc emits more FP save/restore symbols, that the linker generates on demand into the .sfpr section. Explicitly allow-list those in scripts/mod/modpost.c, too. They are needed for the amdgpu in-kernel floating point support. MODPOST Module.symvers ERROR: modpost: "_restfpr_20" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_restfpr_26" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_restfpr_22" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_savegpr1_27" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_savegpr1_25" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_restfpr_28" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_savegpr1_29" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_savefpr_20" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_savefpr_22" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_restfpr_15" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! WARNING: modpost: suppressed 56 unresolved symbol warnings because there were too many) Signed-off-by: René Rebe <rene@exactco.de> Link: https://patch.msgid.link/20251123.131330.407910684435629198.rene@exactco.de Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2026-02-03drm/amdgpu: Fix double deletion of validate_listHarish Kasiviswanathan1-7/+7
If amdgpu_amdkfd_gpuvm_free_memory_of_gpu() fails after kgd_mem is removed from validate_list, the mem handle still lingers in the KFD idr. This means when process is terminated, kfd_process_free_outstanding_kfd_bos() will call amdgpu_amdkfd_gpuvm_free_memory_of_gpu() again resulting in double deletion. To avoid this - (a) Check if list is empty before deleting it (b) Rearragne amdgpu_amdkfd_gpuvm_free_memory_of_gpu() such that it can be safely called again if it returns failure the first time. Signed-off-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Reviewed-by: Philip Yang <Philip.Yang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 6ba60345f45eaf7cb4f89105d26083a4b9fd1cba)
2026-02-03drm/amd/display: remove assert around dpp_base replacementMelissa Wen1-1/+0
There is nothing wrong if in_shaper_func type is DISTRIBUTED POINTS. Remove the assert placed for a TODO to avoid misinterpretations. Signed-off-by: Melissa Wen <mwen@igalia.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 1714dcc4c2c53e41190896eba263ed6328bcf415)
2026-02-03drm/amd/display: extend delta clamping logic to CM3 LUT helperMelissa Wen5-25/+49
Commit 27fc10d1095f ("drm/amd/display: Fix the delta clamping for shaper LUT") fixed banding when using plane shaper LUT in DCN10 CM helper. The problem is also present in DCN30 CM helper, fix banding by extending the same bug delta clamping fix to CM3. Signed-off-by: Melissa Wen <mwen@igalia.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 0274a54897f356f9c78767c4a2a5863f7dde90c6)
2026-02-03drm/amd/display: fix wrong color value mapping on MCM shaper LUTMelissa Wen1-2/+5
Some shimmer/colorful points appears when using the steamOS color pipeline for HDR on gaming with DCN32. These points look like black values being wrongly mapped to red/blue/green values. It was caused because the number of hw points in regular LUTs and in a shaper LUT was treated as the same. DCN3+ regular LUTs have 257 bases and implicit deltas (i.e. HW calculates them), but shaper LUT is a special case: it has 256 bases and 256 deltas, as in DCN1-2 regular LUTs, and outputs 14-bit values. Fix that by setting by decreasing in 1 the number of HW points computed in the LUT segmentation so that shaper LUT (i.e. fixpoint == true) keeps the same DCN10 CM logic and regular LUTs go with `hw_points + 1`. CC: Krunoslav Kovac <Krunoslav.Kovac@amd.com> Fixes: 4d5fd3d08ea9 ("drm/amd/display: PQ tail accuracy") Signed-off-by: Melissa Wen <mwen@igalia.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 5006505b19a2119e71c008044d59f6d753c858b9)
2026-02-03Revert "drm/amd: Check if ASPM is enabled from PCIe subsystem"Bert Karwatzki1-3/+0
This reverts commit 7294863a6f01248d72b61d38478978d638641bee. This commit was erroneously applied again after commit 0ab5d711ec74 ("drm/amd: Refactor `amdgpu_aspm` to be evaluated per device") removed it, leading to very hard to debug crashes, when used with a system with two AMD GPUs of which only one supports ASPM. Link: https://lore.kernel.org/linux-acpi/20251006120944.7880-1-spasswolf@web.de/ Link: https://github.com/acpica/acpica/issues/1060 Fixes: 0ab5d711ec74 ("drm/amd: Refactor `amdgpu_aspm` to be evaluated per device") Signed-off-by: Bert Karwatzki <spasswolf@web.de> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 97a9689300eb2b393ba5efc17c8e5db835917080) Cc: stable@vger.kernel.org
2026-02-03drm/amd: Set minimum version for set_hw_resource_1 on gfx11 to 0x52Mario Limonciello1-1/+1
commit f81cd793119e ("drm/amd/amdgpu: Fix MES init sequence") caused a dependency on new enough MES firmware to use amdgpu. This was fixed on most gfx11 and gfx12 hardware with commit 0180e0a5dd5c ("drm/amdgpu/mes: add compatibility checks for set_hw_resource_1"), but this left out that GC 11.0.4 had breakage at MES 0x51. Bump the requirement to 0x52 instead. Reported-by: danijel@nausys.com Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4576 Fixes: f81cd793119e ("drm/amd/amdgpu: Fix MES init sequence") Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit c2d2ccc85faf8cc6934d50c18e43097eb453ade2) Cc: stable@vger.kernel.org
2026-02-03PM: sleep: wakeirq: harden dev_pm_clear_wake_irq() against racesGui-Dong Han1-3/+6
dev_pm_clear_wake_irq() currently uses a dangerous pattern where dev->power.wakeirq is read and checked for NULL outside the lock. If two callers invoke this function concurrently, both might see a valid pointer and proceed. This could result in a double-free when the second caller acquires the lock and tries to release the same object. Address this by removing the lockless check of dev->power.wakeirq. Instead, acquire dev->power.lock immediately to ensure the check and the subsequent operations are atomic. If dev->power.wakeirq is NULL under the lock, simply unlock and return. This guarantees that concurrent calls cannot race to free the same object. Based on a quick scan of current users, I did not find an actual bug as drivers seem to rely on their own synchronization. However, since asynchronous usage patterns exist (e.g., in drivers/net/wireless/ti/wlcore), I believe a race is theoretically possible if the API is used less carefully in the future. This change hardens the API to be robust against such cases. Fixes: 4990d4fe327b ("PM / Wakeirq: Add automated device wake IRQ handling") Signed-off-by: Gui-Dong Han <hanguidong02@gmail.com> Link: https://patch.msgid.link/20260203031943.1924-1-hanguidong02@gmail.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-02-03cpufreq: Documentation: Update description of rate_limit_us default valueYaxiong Tian1-1/+1
Due to commit 37c6dccd6837 ("cpufreq: Remove LATENCY_MULTIPLIER") updating the acquisition logic of cpufreq_policy_transition_delay_us(), the original description of 2 ms has become inaccurate. Therefore, update the description of the default value for rate_limit_us from 2ms to 1ms. Signed-off-by: Yaxiong Tian <tianyaxiong@kylinos.cn> [ rjw: Subject and changelog edits ] Link: https://patch.msgid.link/20260203093501.1138721-1-tianyaxiong@kylinos.cn Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-02-03cpufreq: intel_pstate: Enable asym capacity only when CPU SMT is not possibleYaxiong Tian1-1/+1
According to the description in the intel_pstate.rst documentation, Capacity-Aware Scheduling and Energy-Aware Scheduling are only supported on a hybrid processor without SMT. Previously, the system used sched_smt_active() for judgment, which is not a strict condition because users can switch it on or off via /sys at any time. This could lead to incorrect driver settings in certain scenarios. For example, on a CPU that supports SMT, a user can disable SMT via the nosmt parameter to enable asym capacity, and then re-enable SMT via /sys. In such cases, some settings in the driver would no longer be correct. To address this issue, replace sched_smt_active() with cpu_smt_possible(), and only enable asym capacity when CPU SMT is not possible. Fixes: 929ebc93ccaa ("cpufreq: intel_pstate: Set asymmetric CPU capacity on hybrid systems") Signed-off-by: Yaxiong Tian <tianyaxiong@kylinos.cn> [ rjw: Subject and changelog edits ] Link: https://patch.msgid.link/20260203024852.301066-1-tianyaxiong@kylinos.cn Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-02-03spi: xilinx: use device property accessors.Abdurrahman Hussain1-5/+5
Switch to device property accessors. Signed-off-by: Abdurrahman Hussain <abdurrahman@nexthop.ai> Link: https://patch.msgid.link/20260203-spi-xilinx-v4-1-42f7c326061b@nexthop.ai Signed-off-by: Mark Brown <broonie@kernel.org>
2026-02-03Merge tag 'i2c-host-6.20' of ↵Wolfram Sang22-452/+423
git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux into i2c/for-mergewindow i2c-host for v6.20 - amd-mp2, designware, mlxbf, rtl9300, spacemit, tegra: cleanups - designware: use a dedicated algorithm for AMD Navi - designware: replace magic numbers with named constants - designware: replace min_t() with min() to avoid u8 truncation - designware: refactor core to enable mode switching - imx-lpi2c: add runtime PM support for IRQ and clock handling - lan9691-i2c: add new driver - rtl9300: use OF helpers directly and avoid fwnode handling - spacemit: add bus reset support - units: add HZ_PER_GHZ and use it in several i2c drivers
2026-02-03i2c: imx: preserve error state in block data length handlerLI Qingwu1-1/+2
When a block read returns an invalid length, zero or >I2C_SMBUS_BLOCK_MAX, the length handler sets the state to IMX_I2C_STATE_FAILED. However, i2c_imx_master_isr() unconditionally overwrites this with IMX_I2C_STATE_READ_CONTINUE, causing an endless read loop that overruns buffers and crashes the system. Guard the state transition to preserve error states set by the length handler. Fixes: 5f5c2d4579ca ("i2c: imx: prevent rescheduling in non dma mode") Signed-off-by: LI Qingwu <Qing-wu.Li@leica-geosystems.com.cn> Cc: <stable@vger.kernel.org> # v6.13+ Reviewed-by: Stefan Eichenberger <eichest@gmail.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20260116111906.3413346-2-Qing-wu.Li@leica-geosystems.com.cn Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2026-02-03ceph: fix oops due to invalid pointer for kfree() in parse_longname()Daniel Vogelbacher1-4/+5
This fixes a kernel oops when reading ceph snapshot directories (.snap), for example by simply running `ls /mnt/my_ceph/.snap`. The variable str is guarded by __free(kfree), but advanced by one for skipping the initial '_' in snapshot names. Thus, kfree() is called with an invalid pointer. This patch removes the need for advancing the pointer so kfree() is called with correct memory pointer. Steps to reproduce: 1. Create snapshots on a cephfs volume (I've 63 snaps in my testcase) 2. Add cephfs mount to fstab $ echo "samba-fileserver@.files=/volumes/datapool/stuff/3461082b-ecc9-4e82-8549-3fd2590d3fb6 /mnt/test/stuff ceph acl,noatime,_netdev 0 0" >> /etc/fstab 3. Reboot the system $ systemctl reboot 4. Check if it's really mounted $ mount | grep stuff 5. List snapshots (expected 63 snapshots on my system) $ ls /mnt/test/stuff/.snap Now ls hangs forever and the kernel log shows the oops. Cc: stable@vger.kernel.org Fixes: 101841c38346 ("[ceph] parse_longname(): strrchr() expects NUL-terminated string") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220807 Suggested-by: Helge Deller <deller@gmx.de> Signed-off-by: Daniel Vogelbacher <daniel@chaospixel.com> Reviewed-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com> Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
2026-02-03rbd: check for EOD after exclusive lock is ensured to be heldIlya Dryomov1-12/+21
Similar to commit 870611e4877e ("rbd: get snapshot context after exclusive lock is ensured to be held"), move the "beyond EOD" check into the image request state machine so that it's performed after exclusive lock is ensured to be held. This avoids various race conditions which can arise when the image is shrunk under I/O (in practice, mostly readahead). In one such scenario rbd_assert(objno < rbd_dev->object_map_size); can be triggered if a close-to-EOD read gets queued right before the shrink is initiated and the EOD check is performed against an outdated mapping_size. After the resize is done on the server side and exclusive lock is (re)acquired bringing along the new (now shrunk) object map, the read starts going through the state machine and rbd_obj_may_exist() gets invoked on an object that is out of bounds of rbd_dev->object_map array. Cc: stable@vger.kernel.org Signed-off-by: Ilya Dryomov <idryomov@gmail.com> Reviewed-by: Dongsheng Yang <dongsheng.yang@linux.dev>
2026-02-03perf/arm-cmn: Reject unsupported hardware configurationsRobin Murphy1-1/+14
So far we've been fairly lax about accepting both unknown CMN models (at least with a warning), and unknown revisions of those which we do know, as although things do frequently change between releases, typically enough remains the same to be somewhat useful for at least some basic bringup checks. However, we also make assumptions of the maximum supported sizes and numbers of things in various places, and there's no guarantee that something new might not be bigger and lead to nasty array overflows. Make sure we only try to run on things that actually match our assumptions and so will not risk memory corruption. We have at least always failed on completely unknown node types, so update that error message for clarity and consistency too. Cc: stable@vger.kernel.org Fixes: 7819e05a0dce ("perf/arm-cmn: Revamp model detection") Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-02-03perf: arm_spe: Properly set hw.state on failuresLeo Yan1-6/+12
When arm_spe_pmu_next_off() fails to calculate a valid limit, it returns zero to indicate that tracing should not start. However, the caller arm_spe_perf_aux_output_begin() does not propagate this failure by updating hwc->state, cause the error to be silently ignored by upper layers. Because hwc->state remains zero after a failure, arm_spe_pmu_start() continues to programs filter registers unnecessarily. The driver still reports success to the perf core, so the core assumes the SPE event was enabled and proceeds to enable other events. This breaks event group semantics: SPE is already stopped while other events in the same group are enabled. Fix this by updating arm_spe_perf_aux_output_begin() to return a status code indicating success (0) or failure (-EIO). Both the interrupt handler and arm_spe_pmu_start() check the return value and call arm_spe_pmu_stop() to set PERF_HES_STOPPED in hwc->state. In the interrupt handler, the period (e.g., period_left) needs to be updated, so PERF_EF_UPDATE is passed to arm_spe_pmu_stop(). When the error occurs during event start, the trace unit is not yet enabled, so a flag '0' is used to drain buffer and update state only. Fixes: d5d9696b0380 ("drivers/perf: Add support for ARMv8.2 Statistical Profiling Extension") Signed-off-by: Leo Yan <leo.yan@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-02-03workqueue: add CONFIG_BOOTPARAM_WQ_STALL_PANIC optionBreno Leitao3-2/+26
Add a kernel config option to set the default value of workqueue.panic_on_stall, similar to CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC, CONFIG_BOOTPARAM_HARDLOCKUP_PANIC and CONFIG_BOOTPARAM_HUNG_TASK_PANIC. This allows setting the number of workqueue stalls before triggering a kernel panic at build time, which is useful for high-availability systems that need consistent panic-on-stall, in other words, those servers which run with CONFIG_BOOTPARAM_*_PANIC=y already. The default remains 0 (disabled). Setting it to 1 will panic on the first stall, and higher values will panic after that many stall warnings. The value can still be overridden at runtime via the workqueue.panic_on_stall boot parameter or sysfs. Signed-off-by: Breno Leitao <leitao@debian.org> Signed-off-by: Tejun Heo <tj@kernel.org>
2026-02-03accel/amdxdna: Fix incorrect error code returned for failed chain commandLizhi Hou1-1/+1
The driver currently returns an incorrect error code when a chain command fails. In this case, ERT_CMD_STATE_ERROR is expected to be reported for failed chain commands. Fixes: aac243092b70 ("accel/amdxdna: Add command execution") Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Reviewed-by: Maciej Falkowski <maciej.falkowski@linux.intel.com> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://patch.msgid.link/20260203184037.2751889-1-lizhi.hou@amd.com
2026-02-03Merge branch 'bpf-add-bpf_stream_print_stack-kfunc'Alexei Starovoitov4-1/+85
Emil Tsalapatis says: ==================== bpf: Add bpf_stream_print_stack kfunc Add a new bpf_stream_print_stack kfunc for printing a BPF program stack into a BPF stream. Update the verifier to allow the new kfunc to be called with BPF spinlocks held, along with bpf_stream_vprintk. Patchset spun out of the larger libarena + ASAN patchset. (https://lore.kernel.org/bpf/20260127181610.86376-1-emil@etsalapatis.com/) Changeset: - Update bpf_stream_print_stack to take stream_id arg (Kumar) - Added selftest for the bpf_stream_print_stack - Add selftest for calling the streams kfuncs under lock v2->v1: (https://lore.kernel.org/bpf/20260202193311.446717-1-emil@etsalapatis.com/) - Updated Signed-off-by to be consistent with past submissions - Updated From email to be consistent with Signed-off-by Acked-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Signed-off-by: Emil Tsalapatis <emil@etsalapatis.com> ==================== Link: https://patch.msgid.link/20260203180424.14057-1-emil@etsalapatis.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-02-03selftests/bpf: Add selftests for stream functions under lockEmil Tsalapatis1-0/+32
Add a selftest to ensure BPF stream functions can now be called while holding a lock. Signed-off-by: Emil Tsalapatis <emil@etsalapatis.com> Acked-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Link: https://lore.kernel.org/r/20260203180424.14057-5-emil@etsalapatis.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-02-03bpf: Allow BPF stream kfuncs while holding a lockEmil Tsalapatis1-1/+12
The BPF stream kfuncs bpf_stream_vprintk and bpf_stream_print_stack do not sleep and so are safe to call while holding a lock. Amend the verifier to allow that. Signed-off-by: Emil Tsalapatis <emil@etsalapatis.com> Acked-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Link: https://lore.kernel.org/r/20260203180424.14057-4-emil@etsalapatis.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
generated by cgit