summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-07-21ASoC: mediatek: preparation for Card capsulingMark Brown
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> says: I will post Card capsuling patch. To makes its review easy, tidyup mediatek drivers to reduce un-related diff as preparation. No functional change, but is preparation for cleanup driver. Link: https://patch.msgid.link/8733xdjfdq.wl-kuninori.morimoto.gx@renesas.com
2026-07-21ASoC: mediatek: mt8365-mt6357: remove useless assignmentKuninori Morimoto
static int mt8365_mt6357_dev_probe(...) { ... struct device *dev = card->dev; ... => card->dev = dev; ... } This is useless. Remove it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patch.msgid.link/87wlupi0sg.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-21ASoC: mediatek: mt8196-nau8825: remove unnecessary declarationKuninori Morimoto
No need to declarate mt8196_nau8825_soc_card. Remove it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patch.msgid.link/87y0f5i0sl.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-21ASoC: mediatek: common/mtk-dsp-sof-common: use for_each_card_prelinks()Kuninori Morimoto
We already have for_each_card_prelinks(). Let's use it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patch.msgid.link/87zezli0sp.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-21ASoC: mediatek: mt8192-mt6359-rt1015-rt5682: use *dev in ↵Kuninori Morimoto
mt8192_mt6359_card_set_be_link() use *dev, instead of card->dev. No functional change, but is preparation for cleanup driver. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patch.msgid.link/871pcxjfd9.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-21ACPI: sysfs: Properly map BERT and CCEL data to their ACPI tablesThomas Renninger
In the case of multiple BERT ACPI tables, one gets: sysfs: cannot create duplicate filename '/firmware/acpi/tables/data/BERT' This is because both: /firmware/acpi/tables/BERT1 /firmware/acpi/tables/BERT2 are attempted to be mapped to the same data table: /firmware/acpi/tables/data/BERT Address this problem by passing and using the same filename for data tables. Signed-off-by: Thomas Renninger <trenn@suse.de> Reported-by: Michal Suchanek <msuchanek@suse.com> Closes: https://bugzilla.suse.com/show_bug.cgi?id=1270211 [ rjw: Subject and changelog edits ] Link: https://patch.msgid.link/20260717065129.72924-3-trenn@suse.de Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-07-21ACPI: Use correct region struct for BERT region size checkThomas Renninger
The structure representing BERT data is struct acpi_bert_region, so its size should be used in the BERT region size check. Update the code in question accordingly. Signed-off-by: Thomas Renninger <trenn@suse.de> [ rjw: Changelog edits ] Link: https://patch.msgid.link/20260717065129.72924-2-trenn@suse.de Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-07-21rds: Fix inet6_addr_lst NULL dereference when IPv6 is disabledIlia Gavrilov
When booting with the 'ipv6.disable=1' parameter, inet6_addr_lst is never initialized because inet6_init() exits before addrconf_init() is called to initialize it. An attempt to bind an RDS socket to an ipv6 address results in a crash in __ipv6_chk_addr_and_flags() KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:__ipv6_chk_addr_and_flags+0x1df/0x7e0 Call Trace: <TASK> ipv6_chk_addr+0x3b/0x50 rds_tcp_laddr_check+0x155/0x3b0 [rds_tcp] rds_trans_get_preferred+0x15d/0x2d0 [rds] ? trace_hardirqs_on+0x2d/0x110 rds_bind+0x1433/0x1d60 [rds] ? rds_remove_bound+0xd50/0xd50 [rds] ? aa_af_perm+0x250/0x250 ? __might_fault+0xde/0x190 ? __sys_bind+0x1dc/0x210 __sys_bind+0x1dc/0x210 ? __ia32_sys_socketpair+0x100/0x100 ? restore_fpregs_from_fpstate+0x53/0x100 __x64_sys_bind+0x73/0xb0 ? syscall_enter_from_user_mode+0x1c/0x50 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0033:0x7f47f8269ea9 </TASK> The following code reproduces the issue: struct sockaddr_in6 addr; s = socket(PF_RDS, SOCK_SEQPACKET, 0); memset(&addr, 0, sizeof(addr)); inet_pton(AF_INET6, ADDRESS, &addr.sin6_addr); addr.sin6_family = AF_INET6; addr.sin6_port = htons(PORT); bind(s, &addr, sizeof(addr)); Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: eee2fa6ab322 ("rds: Changing IP address internal representation to struct in6_addr") Fixes: 1e2b44e78eea ("rds: Enable RDS IPv6 support") Signed-off-by: Ilia Gavrilov <Ilia.Gavrilov@infotecs.ru> Reviewed-by: Allison Henderson <achender@kernel.org> Link: https://patch.msgid.link/20260709162723.367523-1-Ilia.Gavrilov@infotecs.ru Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21net: txgbe: fix heap overflow when reading module EEPROMChenguang Zhao
txgbe_read_eeprom_hostif() always copies round_up(length, 4) bytes into the caller buffer, which ethtool allocates with exactly 'length' bytes. A non-4-aligned length therefore causes an out-of-bounds write. Copy only the remaining bytes on the final dword instead. Signed-off-by: Chenguang Zhao <zhaochenguang@kylinos.cn> Reviewed-by: Jiawen Wu <jiawenwu@trustnetic.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Fixes: 9b97b6b5635b ("net: txgbe: support getting module EEPROM by page") Link: https://patch.msgid.link/20260713085111.1481884-1-chenguang.zhao@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21mailmap: update entry for Alice MikityanskaAlice Mikityanska
Map all my corporate and old emails and update my name. Signed-off-by: Alice Mikityanska <alice.kernel@fastmail.im> Link: https://patch.msgid.link/20260710234319.328687-1-alice.kernel@fastmail.im Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21tipc: serialize udp bearer replicast list updatesWeiming Shi
tipc_udp_rcast_add() and cleanup_bearer() both update ub->rcast.list with list_add_rcu() / list_del_rcu(), but nothing serializes them. The add runs from the encap receive softirq (via tipc_udp_rcast_disc()) without rtnl_lock(), so it can race the cleanup delete and corrupt the list: list_del corruption. prev->next should be ffff8880298d7ab8, but was ffff88802449ad38. (prev=ffff888027e3ec98) kernel BUG at lib/list_debug.c:62! RIP: __list_del_entry_valid_or_report+0x17a/0x200 Workqueue: events cleanup_bearer Call Trace: cleanup_bearer (net/tipc/udp_media.c:811) process_one_work (kernel/workqueue.c:3302) worker_thread (kernel/workqueue.c:3466) The bearer can be enabled from an unprivileged user namespace, as the TIPCv2 generic-netlink ops carry no GENL_ADMIN_PERM. Add a spinlock to struct udp_bearer and take it around the list_add_rcu() in tipc_udp_rcast_add() and the list_del_rcu() loop in cleanup_bearer() so the two writers can no longer corrupt the list. Reject a duplicate peer under the same lock before allocating, and remove tipc_udp_is_known_peer(). The old lockless pre-check in tipc_udp_rcast_disc() was racy: two softirqs discovering the same peer could both find it absent and add it twice. cleanup_bearer() runs from a workqueue after tipc_udp_disable() clears the bearer's up bit, so an encap softirq can still reach tipc_udp_rcast_add() and add a peer after cleanup_bearer() has already emptied the list, leaking that entry when the bearer is freed. Mark the bearer disabled under rcast_lock once the list is emptied and refuse further additions. Fixes: ef20cd4dd163 ("tipc: introduce UDP replicast") Reported-by: Xiang Mei <xmei5@asu.edu> Suggested-by: Tung Nguyen <tung.quang.nguyen@est.tech> Signed-off-by: Weiming Shi <bestswngs@gmail.com> Reviewed-by: Tung Nguyen <tung.quang.nguyen@est.tech> Link: https://patch.msgid.link/20260716025203.9332-2-bestswngs@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21Merge tag 'nfsd-7.2-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux Pull nfsd fix from Chuck Lever: - Fix issue with NLMv3 GRANTED_MSG introduced in v7.2 * tag 'nfsd-7.2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux: lockd: fix NLMv3 GRANTED_MSG handling
2026-07-21rtase: Workaround for TX hang caused by hardware packet parsingJustin Lai
The hardware performs packet parsing before packet transmission. Parsing incomplete IPv4, IPv6, TCP, or UDP headers may trigger a TX hang because the hardware parser expects additional protocol header data that is not present in the packet. The hardware performs additional PTP parsing on UDP packets identified by destination ports 319/320 at the expected UDP destination port offset. If such a packet has transport data smaller than RTASE_MIN_PAD_LEN, the hardware parser expects additional packet data and may trigger a TX hang. To avoid these hardware issues, the driver applies the following workarounds. Drop malformed packets that may trigger this hardware issue before transmission. For IPv4 non-initial fragments, the hardware does not check the fragment offset before parsing the expected transport header location. As a result, these packets are still subject to transport header parsing even though they do not contain a transport header. If the transport data is shorter than the minimum transport header required by the hardware parser, pad the transport data to the minimum transport header length required by the hardware parser. Packets that also match the hardware PTP parsing conditions continue to follow the corresponding workaround. For IPv6 fragmented packets, neither of the above hardware issues occurs because the hardware only continues packet parsing when the IPv6 Base Header Next Header field directly indicates UDP. Packets carrying a Fragment Header do not continue through the subsequent packet parsing stages. For packets identified for hardware PTP parsing, pad the transport data so it reaches RTASE_MIN_PAD_LEN before transmission. Fixes: d6e882b89fdf ("rtase: Implement .ndo_start_xmit function") Cc: stable@vger.kernel.org Signed-off-by: Justin Lai <justinlai0215@realtek.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260709103456.83789-1-justinlai0215@realtek.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21KVM: arm64: Sync SCTLR_EL1 when injecting an exception into a pVMFuad Tabba
When pKVM injects a synchronous exception into a protected guest, enter_exception64() reads SCTLR_EL1 to set the new PSTATE's PAN and SSBS bits. pKVM refreshes VBAR_EL1 from the live value before injecting but not SCTLR_EL1, which is untrapped for protected guests, so a guest that updates it and then traps takes the exception with stale PAN/SSBS. Sync SCTLR_EL1 alongside VBAR_EL1. Fixes: 798eb5978700 ("KVM: arm64: Sync protected guest VBAR_EL1 on injecting an undef exception") Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev> Link: https://patch.msgid.link/20260721161624.3983041-1-fuad.tabba@linux.dev Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-21bpf, riscv: Fix extable handling for arena load_acquireFeng Jiang
emit_atomic_ld_st() returns 1 to have build_body() skip the zext after a sub-word load_acquire. The caller does "ret = ret ?: add_exception_handler(...)", which skips add_exception_handler() on any non-zero ret, so the extable entry is missing and a faulting PROBE_ATOMIC load_acquire oopses. REG_DONT_CLEAR_MARKER leaves rd stale on fault, and the verifier still thinks the load overwrote it, so a program can leak it through a map. Check ret >= 0 before calling add_exception_handler(), and pass rd for LOAD_ACQ so the fault zeroes rd like a PROBE_MEM load. Return ret unchanged for the zext skip. Fixes: fb7cefabae81 ("riscv, bpf: Add support arena atomics for RV64") Suggested-by: Pu Lehui <pulehui@huawei.com> Signed-off-by: Feng Jiang <jiangfeng@kylinos.cn> Reviewed-by: Pu Lehui <pulehui@huawei.com> Reviewed-by: Björn Töpel <bjorn@kernel.org> Acked-by: Björn Töpel <bjorn@kernel.org> Link: https://lore.kernel.org/bpf/20260720-bpf-riscv-fix-extable-v4-1-165c0b3b07d5@kylinos.cn Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-21net: dsa: yt921x: Fix external port detectionChukun Pan
The YT921x switch has two MAC ports: 8 and 9. Currently, the driver only allows port 8 as an external port, while port 9 is not working: yt921x mdio-bus:1d: Wrong mode 23 on port 9 yt921x mdio-bus:1d: Failed to config port 9: -22 Update the external port detection logic to enable the external PHY connected to port 9. Cc: stable+noautosel@kernel.org # never worked Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn> Link: https://patch.msgid.link/20260710100000.3018614-1-amadeus@jmu.edu.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21Merge branch 'mixing-bpf2bpf-and-tailcalls-for-rv64'Kumar Kartikeya Dwivedi
Pu Lehui says: ==================== Mixing bpf2bpf and tailcalls for RV64 In the current RV64 JIT, if we just don't initialize the TCC in subprog, the TCC can be propagated from the parent process to the subprocess, but the updated TCC of the parent process cannot be restored when the subprocess exits. Since the RV64 TCC is initialized before saving the callee saved registers into the stack, we cannot use the callee saved register to pass the TCC, otherwise the original value of the callee saved register will be destroyed. So we implemented mixing bpf2bpf and tailcalls similar to x86_64, i.e. using a non-callee saved register to transfer the TCC between functions, and saving that register to the stack to protect the TCC value. As for the tailcall hierarchy issue, inspired by the s390's low-overhead approach, we store TCC from RV_REG_TCC back to stack after calling bpf2bpf call or calling orig bpf func in bpf trampoline. In addition, some code cleans are also attached to this patchset. Tests test_bpf.ko and test_verifier have passed, as well as the relative testcases of test_progs*. v6: - Add new patch to fix memory leak in bpf_jit_free. (Sashiko) v5: https://lore.kernel.org/bpf/20260707142219.2871758-1-pulehui@huaweicloud.com - Fix TCC value was not restored to RV_REG_TCC upon trampoline exit, resulting in an infinite tail call. (Sashiko) - Fix epilogue not restored TCC value to RV_REG_TCC, resulting in leaf tailcall callee may clobbered RV_REG_TCC. (Sashiko) - Remove patch of `Remove ctx->offset initialization` as it would hit some corner case. (Sashiko) - Fix double-count kcfi insn when tailcall to target. (Sashiko) - Add detail for selftest commit message. (BPF BOT) v4: https://lore.kernel.org/bpf/20260629140048.733346-1-pulehui@huaweicloud.com - Fix tailcall hierarchy issue. - use is_struct_ops_tramp helper in bpf trampoline v3: https://lore.kernel.org/bpf/20240201083351.943121-1-pulehui@huaweicloud.com - Remove duplicate RV_REG_TCC load in epiloguei. (Björn Töpel) v2: https://lore.kernel.org/bpf/20240130040958.230673-1-pulehui@huaweicloud.com - Fix emit restore RV_REG_TCC double times when `flags & BPF_TRAMP_F_CALL_ORIG` - Use bpf_is_subprog helper v1: https://lore.kernel.org/bpf/20230919035711.3297256-1-pulehui@huaweicloud.com ==================== Link: https://patch.msgid.link/20260708064436.2971933-1-pulehui@huaweicloud.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-21selftests/bpf: Remove tailcalls tests from DENYLIST.riscv64Pu Lehui
The RV64 BPF JIT now supports mixing bpf2bpf and tailcalls. Therefore, the tailcall_bpf2bpf tests can be safely removed from the riscv64 denylist. Signed-off-by: Pu Lehui <pulehui@huawei.com> Reviewed-by: Björn Töpel <bjorn@kernel.org> Acked-by: Björn Töpel <bjorn@kernel.org> Link: https://lore.kernel.org/bpf/20260708064436.2971933-8-pulehui@huaweicloud.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-21riscv, bpf: Mixing bpf2bpf and tailcallsPu Lehui
In the current RV64 JIT, if we just don't initialize the TCC in subprog, the TCC can be propagated from the parent process to the subprocess, but the updated TCC of the parent process cannot be restored when the subprocess exits. Since the RV64 TCC is initialized before saving the callee saved registers into the stack, we cannot use the callee saved register to pass the TCC, otherwise the original value of the callee saved register will be destroyed. So we implemented mixing bpf2bpf and tailcalls similar to x86_64, i.e. using a non-callee saved register to transfer the TCC between functions, and saving that register to the stack to protect the TCC value. As for the tailcall hierarchy issue, inspired by the s390's low-overhead approach, we store TCC from RV_REG_TCC back to stack after calling bpf2bpf call or calling orig bpf func in bpf trampoline. Tests test_bpf.ko and test_verifier have passed, as well as the relative testcases of test_progs*. Signed-off-by: Pu Lehui <pulehui@huawei.com> Reviewed-by: Björn Töpel <bjorn@kernel.org> Acked-by: Björn Töpel <bjorn@kernel.org> Link: https://lore.kernel.org/bpf/20260708064436.2971933-7-pulehui@huaweicloud.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-21riscv, bpf: Add RV_TAILCALL_OFFSET macro to format tailcall offsetPu Lehui
Add RV_TAILCALL_OFFSET macro to format tailcall offset, and correct the relevant comments. Signed-off-by: Pu Lehui <pulehui@huawei.com> Reviewed-by: Björn Töpel <bjorn@kernel.org> Acked-by: Björn Töpel <bjorn@kernel.org> Link: https://lore.kernel.org/bpf/20260708064436.2971933-6-pulehui@huaweicloud.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-21Merge branch 'net-fix-stale-tx-skb-pointers-on-dma-map-failure'Jakub Kicinski
Xuanqiang Luo says: ==================== net: fix stale TX skb pointers on DMA map failure From: Xuanqiang Luo <luoxuanqiang@kylinos.cn> While I was backporting commit 1a303baa715e6 ("ice: fix double-free of tx_buf skb"), an AI-assisted scan identified several suspected TX error paths. I reviewed the results and found this issue in the three drivers fixed here. The drivers differ, but the bug is the same. On a DMA mapping failure, the TX path frees an skb while its ring entry still points to it. A later transmission normally overwrites the entry. If the interface is stopped first, teardown can instead access or free the skb again. I do not have these adapters, so I have not tested the drivers on hardware. I checked the error and teardown paths by inspection. Still, these small fixes seem worth posting for review. They are independent, but are sent as one series because they address the same issue. ==================== Link: https://patch.msgid.link/20260710090527.58354-1-xuanqiang.luo@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21riscv, bpf: Fix kernel stack corruption in tailcall with CFIPu Lehui
When CONFIG_CFI_CLANG is enabled, prog->bpf_func already skips the kcfi instruction during setup. Including it again in the tailcall jump offset causes it to jump over an extra 4 bytes, skipping the stack pointer adjustment, which will result in kernel stack corruption. Fixes: 30a59cc79754 ("riscv, bpf: Fix possible infinite tailcall when CONFIG_CFI_CLANG is enabled") Reported-by: Sashiko <sashiko-bot@kernel.org> Signed-off-by: Pu Lehui <pulehui@huawei.com> Reviewed-by: Björn Töpel <bjorn@kernel.org> Acked-by: Björn Töpel <bjorn@kernel.org> Link: https://lore.kernel.org/bpf/20260708064436.2971933-5-pulehui@huaweicloud.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-21net: hibmcge: fix double-free of tx skb on DMA mapping failureXuanqiang Luo
If hbg_dma_map() fails, hbg_net_start_xmit() frees the skb, but buffer->skb is left pointing to it. ring->ntu is not advanced, so the buffer is not visible to the TX cleanup path. A subsequent transmit normally overwrites the buffer. However, if the interface is brought down first, hbg_ring_uninit() calls hbg_buffer_free(). It sees the stale pointer, attempts to unmap the failed mapping, and frees the skb again. Clear buffer->skb before freeing the skb in the error path, preventing hbg_buffer_free() from treating it as an outstanding TX buffer. Cc: stable+noautosel@kernel.org # untested fix to unlikely driver error path Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn> Reviewed-by: Jijie Shao <shaojijie@huawei.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260710090527.58354-4-xuanqiang.luo@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21riscv, bpf: Using kvzalloc_objs to allocate cache bufferPu Lehui
It is unnecessary to allocate continuous physical memory for cache buffer, and when ebpf program is too large, it may cause memory allocation failure. Signed-off-by: Pu Lehui <pulehui@huawei.com> Reviewed-by: Björn Töpel <bjorn@kernel.org> Acked-by: Björn Töpel <bjorn@kernel.org> Link: https://lore.kernel.org/bpf/20260708064436.2971933-4-pulehui@huaweicloud.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-21riscv, bpf: Fix memory leak in bpf_jit_freePu Lehui
When bpf_int_jit_compile() is called for subprograms, it returns early during the first pass (!prog->is_func || extra_pass is false), keeping ctx->offset alive for the subsequent extra pass. If JIT compilation fails for a later subprogram, the BPF core aborts and calls bpf_jit_free() to clean up the first subprogram. However, bpf_jit_free() fails to free jit_data->ctx.offset, which causes a memory leak of the JIT context offsets array. Fix this by adding the missing kfree(jit_data->ctx.offset) in bpf_jit_free(). Fixes: 48a8f78c50bd ("bpf, riscv: use prog pack allocator in the BPF JIT") Reported-by: Sashiko <sashiko-bot@kernel.org> Signed-off-by: Pu Lehui <pulehui@huawei.com> Reviewed-by: Björn Töpel <bjorn@kernel.org> Acked-by: Björn Töpel <bjorn@kernel.org> Link: https://lore.kernel.org/bpf/20260708064436.2971933-3-pulehui@huaweicloud.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-21ALSA: hda: Add AW88399 HDA side codec driver for Lenovo LegionMark Brown
Marco Giunta <marco_giunta@outlook.it> says: Several Lenovo Legion laptops (Pro 7i 16IAX10H, Y9000P IAX10, Pro 7 16AFR10H, R9000P ADR10) use AWINIC AW88399 smart amplifiers to drive their bass woofers, connected via I2C as side codecs to a Realtek ALC287 HDA codec. Without a driver for these amplifiers, only the tweeters produce sound, resulting in quiet and tinny audio. An ASoC driver for the AW88399 already exists in-tree (sound/soc/codecs/aw88399.c), contributed by AWINIC, but it targets ASoC topologies and cannot drive the chip when it sits behind an HDA controller. This series adds a proper HDA side codec driver, following the established pattern used by the CS35L41, CS35L56, and TAS2781 drivers. Patch 1 extracts the device-level functions from the existing ASoC driver into a shared library module (SND_SOC_AW88399_LIB) with a shared header at include/sound/aw88399.h, following the CS35L41 precedent (SND_SOC_CS35L41_LIB / include/sound/cs35l41.h). This avoids a build-time dependency on the full ASoC codec module and ensures clean separation between the ASoC and HDA drivers. Patches 2 through 5 prepare the shared library for use on ACPI-based HDA systems: patch 2 extends channel assignment to work without Device Tree properties, patch 3 adds a per-instance flag to bypass an unreliable hardware status bit on certain boards, patch 4 adds a firmware reload flag so that the HDA driver can signal that DSP firmware needs to be re-uploaded after system sleep, and patch 5 adds a channel setter so that the HDA driver can configure the amplifier without depending on ASoC-internal device headers. NOTE ON FIRMWARE: This driver requires the firmware file aw88399_acf.bin, which uses the same format and request path as the existing ASoC driver. This firmware is not yet available in the linux-firmware repository. We intend to coordinate with the AWINIC maintainers (CC'd) to arrange its inclusion. In the meantime, users can extract the firmware from the Windows driver and place it in /lib/firmware/. This work builds on the initial driver development by Yakov Till ("Lyapsus") and the bounty effort organized by Nadim Kobeissi: https://github.com/nadimkobeissi/16iax10h-linux-sound-saga Link: https://patch.msgid.link/DS7PR19MB77247D9AD698CF0FF37DB58BFCC62@DS7PR19MB7724.namprd19.prod.outlook.com
2026-07-21hinic3: fix use-after-free on DMA mapping failureXuanqiang Luo
If hinic3_tx_map_skb() fails in hinic3_send_one_skb(), the skb is freed, but tx_info->skb was set before the mapping attempt and is not cleared. The SQ producer index is rolled back, so later transmissions normally overwrite the entry. If the interface is brought down first, hinic3_free_txqs_res() calls free_all_tx_skbs(). It scans the entire tx_info array and finds the stale pointer. hinic3_tx_unmap_skb() then dereferences the freed skb in skb_shinfo(), before it is freed again. Set tx_info->skb and its WQEBB count only after DMA mapping succeeds, preventing the stale pointer from reaching free_all_tx_skbs(). Cc: stable+noautosel@kernel.org # untested fix to unlikely driver error path Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn> Reviewed-by: Fan Gong <gongfan1@huawei.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260710090527.58354-3-xuanqiang.luo@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21bna: fix use-after-free on DMA mapping failureXuanqiang Luo
If dma_map_single() fails in bnad_start_xmit(), the skb is freed, but head_unmap->skb was set before the mapping attempt and is not cleared. The producer index is not advanced, so later transmissions normally overwrite the entry. However, if the interface is brought down first, bnad_txq_cleanup() scans the entire unmap queue, finds the stale pointer, and calls bnad_tx_buff_unmap() on it. That function dereferences the freed skb in skb_headlen(). Its zero nvecs count is decremented to -1, causing its while (nvecs) loop to repeatedly unmap entries around the TX ring and potentially hang cleanup. Set head_unmap->skb after the first DMA mapping succeeds. This prevents the stale entry from reaching bnad_tx_buff_unmap(). Cc: stable+noautosel@kernel.org # untested fix to unlikely error path Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260710090527.58354-2-xuanqiang.luo@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21bpf: Extract the is_struct_ops_tramp helperPu Lehui
Extract the is_struct_ops_tramp helper, and use it in riscv as the current checks are somewhat hacky. Signed-off-by: Pu Lehui <pulehui@huawei.com> Reviewed-by: Björn Töpel <bjorn@kernel.org> Acked-by: Björn Töpel <bjorn@kernel.org> Link: https://lore.kernel.org/bpf/20260708064436.2971933-2-pulehui@huaweicloud.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-21ASoC: aw88399: add channel setter for HDA side codecMarco Giunta
Add aw88399_dev_set_channel() to the shared library so that the HDA side codec driver can set the amplifier's channel assignment without including the aw88395 device header directly. The AW88399's struct aw_device is defined in aw88395_device.h, which lives under sound/soc/codecs/aw88395/. Without this accessor, the HDA driver would need a cross-subsystem relative include path to access the channel field. Providing a setter in the library keeps the interface clean and avoids coupling the HDA driver to ASoC-internal headers. Tested-by: Nadim Kobeissi <nadim@symbolic.software> Tested-by: Xia Yun'an <imitoy@imitoy.top> Tested-by: Munzir Taha <munzirtaha@gmail.com> Signed-off-by: Marco Giunta <marco_giunta@outlook.it> Link: https://patch.msgid.link/DS7PR19MB7724E8A1AD36D1E623FA2A0AFCC62@DS7PR19MB7724.namprd19.prod.outlook.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-21ASoC: aw88399: add firmware reload flag for resumeMarco Giunta
Add a fw_needs_reload flag to struct aw88399 that, when set, causes aw88399_start to perform a full DSP firmware upload instead of assuming the firmware binary is already present in memory. After system sleep, the AW88399 loses its memory contents. The existing start sequence assumes the firmware binary persists from initialization and only uploads register configuration and DSP config (AW88399_DSP_FW_UPDATE_OFF). When memory is empty, this causes the subsequent CRC check to fail, triggering the retry mechanism in aw88399_start_pa which re-uploads the firmware on the second attempt. While the retry mechanism recovers correctly, it produces misleading error-level log messages on every resume cycle. The fw_needs_reload flag allows the HDA side codec driver to signal that a full firmware reload is needed after resume, eliminating the spurious CRC failures. The flag defaults to false via kzalloc, preserving the original behavior for existing ASoC users. No existing code path sets this flag; it will be set by the HDA side codec driver's system suspend handler. Tested-by: Nadim Kobeissi <nadim@symbolic.software> Tested-by: Xia Yun'an <imitoy@imitoy.top> Tested-by: Munzir Taha <munzirtaha@gmail.com> Signed-off-by: Marco Giunta <marco_giunta@outlook.it> Link: https://patch.msgid.link/DS7PR19MB77240CB79188C0B7AE243829FCC62@DS7PR19MB7724.namprd19.prod.outlook.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-21ASoC: aw88399: add per-instance BSTS status bypass flagMarco Giunta
Add a bsts_unreliable flag to struct aw88399 that, when set, causes the startup status check (aw_dev_check_sysst) to skip the BSTS (boost startup finished) requirement. On some hardware, the BSTS bit in the SYSST register (0x01, bit 9) does not reliably assert even during normal audio playback. Register inspection on affected Lenovo Legion hardware shows both amplifiers reporting BSTS=0 on both channels despite clean audio output. Per the AW88399 datasheet, BSTS indicates boost startup completion. If BSTS never reliably sets to 1, the chip is never allowed to start by aw_dev_check_sysst, regardless of whether the boot failure is genuine. The new flag defaults to false via kzalloc, preserving the original check behavior for all existing users. No existing code path sets this flag; it will be set by the forthcoming HDA side codec property driver for affected hardware. Tested-by: Nadim Kobeissi <nadim@symbolic.software> Tested-by: Xia Yun'an <imitoy@imitoy.top> Tested-by: Munzir Taha <munzirtaha@gmail.com> Signed-off-by: Marco Giunta <marco_giunta@outlook.it> Link: https://patch.msgid.link/DS7PR19MB77242B8E5BB8BFB5E69816E9FCC62@DS7PR19MB7724.namprd19.prod.outlook.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-21ASoC: aw88399: derive channel from I2C address on ACPI systemsMarco Giunta
Extend aw88399_parse_channel_dt to derive the audio channel from the I2C address when the Device Tree property "awinic,audio-channel" is absent. The original code calls of_property_read_u32 without checking the return value. On ACPI systems, the DT property is never present, and channel_value is used uninitialized in the assignment to aw_dev->channel. Add a fallback that computes the channel as (i2c_addr - 0x34), where 0x34 is the AW88399's base I2C address per the datasheet (valid range 0x34-0x37). This channel assignment may be subsequently overridden by the HDA side codec's property driver on systems that require it. No change on Device Tree systems where the property is present. Tested-by: Nadim Kobeissi <nadim@symbolic.software> Tested-by: Xia Yun'an <imitoy@imitoy.top> Tested-by: Munzir Taha <munzirtaha@gmail.com> Co-developed-by: Yakov Till <yakov.till@gmail.com> Signed-off-by: Yakov Till <yakov.till@gmail.com> Signed-off-by: Marco Giunta <marco_giunta@outlook.it> Link: https://patch.msgid.link/DS7PR19MB772468BB9F4D6925DC4E8E3EFCC62@DS7PR19MB7724.namprd19.prod.outlook.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-21ASoC: aw88399: extract shared device libraryMarco Giunta
Extract the device-level functions from aw88399.c into a new shared library module (aw88399-lib.c) with a shared header at include/sound/aw88399.h, following the pattern established by CS35L41 (cs35l41-lib.c / include/sound/cs35l41.h) for chips that need both ASoC and HDA drivers. The shared header at include/sound/aw88399.h contains the register definitions, bit-field masks, hardware constants, device enums, the struct aw88399 definition, and the library function declarations. The ASoC-private header at sound/soc/codecs/aw88399.h is reduced to ASoC-specific definitions (PCM formats/rates, ALSA kcontrol helpers, calibration constants) and includes the shared header. The library contains the chip initialization, firmware loading, playback start/stop sequences, and all their internal dependencies (PLL checks, DSP management, volume control, calibration, CRC verification, etc.). The ASoC codec driver retains the ALSA controls, DAPM widgets, codec probe/remove, calibration service, and I2C bus driver registration. A new Kconfig symbol SND_SOC_AW88399_LIB is introduced. SND_SOC_AW88399 (the existing ASoC codec) selects it, ensuring no change for current users. The HDA side codec driver (introduced later in this series) selects the library without pulling in the full ASoC codec module. This avoids a build-time dependency on the full ASoC driver and follows the established pattern used by CS35L41 (SND_SOC_CS35L41_LIB) for chips with both ASoC and HDA drivers. Some library functions (DSP control, volume setting, mute, calibration updates, profile management, and status helpers) are used internally by the library's start/stop sequences but are also called directly by the ASoC driver's remaining code. These are exported from the library so the ASoC module can access them. This is a pure code movement with no functional changes. The moved functions are identical to their originals in aw88399.c. Tested-by: Nadim Kobeissi <nadim@symbolic.software> Tested-by: Xia Yun'an <imitoy@imitoy.top> Tested-by: Munzir Taha <munzirtaha@gmail.com> Signed-off-by: Marco Giunta <marco_giunta@outlook.it> Link: https://patch.msgid.link/DS7PR19MB772415C485FAF74297673FD7FCC62@DS7PR19MB7724.namprd19.prod.outlook.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-21net: mvneta: bm: fix device reference leak on failed lookupJohan Hovold
Make sure to drop the reference taken to the buffer manager device when attempting to look up its driver data before the driver has been bound. Note that holding a reference to a device does not prevent its driver data from going away. Cc: stable+noautosel@kernel.org # untested fix to unlikely error path Cc: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com> Link: https://patch.msgid.link/20260709082713.829446-1-johan@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21mptcp: only set DATA_FIN when a mapping is presentMichael Bommarito
mptcp_get_options() clears only the status group of struct mptcp_options_received; data_seq, subflow_seq and data_len are filled in by mptcp_parse_option() exclusively inside the DSS mapping block, which runs only when the DSS M (mapping present) bit is set. A peer can send a DSS option with the DATA_FIN flag set but the mapping bit clear. The parser then records mp_opt->data_fin while leaving data_len and data_seq uninitialized. For a zero-length segment mptcp_incoming_options() evaluates if (mp_opt.data_fin && mp_opt.data_len == 1 && mptcp_update_rcv_data_fin(msk, mp_opt.data_seq, mp_opt.dsn64)) which reads the uninitialized data_len and data_seq; KMSAN reports an uninit-value in mptcp_incoming_options(). The stale data_seq can also be fed into the receive-side DATA_FIN sequence tracking. Record the DATA_FIN flag only when the DSS option carries a mapping, so data_fin is never set without data_seq and data_len also being present. data_fin is part of the status group that mptcp_get_options() clears up front, so on the no-map path it stays zero and the zero-length DATA_FIN branch is simply skipped. A DATA_FIN is always transmitted together with a mapping (mptcp_write_data_fin() sets use_map along with data_seq and data_len), so legitimate DATA_FIN handling is unaffected. Move the pr_debug() that logs the parsed DSS flags below the mapping block, so it reports the final data_fin value instead of the stale one it would otherwise print before the assignment. Fixes: 43b54c6ee382 ("mptcp: Use full MPTCP-level disconnect state machine") Suggested-by: Paolo Abeni <pabeni@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260709191925.2811195-1-michael.bommarito@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21ASoC: qcom: preparation for Card capsulingMark Brown
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> says: I will post Card capsuling patch. To makes its review easy, tidyup meson drivers to reduce un-related diff as preparation. No functional change, but is preparation for cleanup driver. Link: https://patch.msgid.link/87qzkxi0j5.wl-kuninori.morimoto.gx@renesas.com
2026-07-21ASoC: qcom: storm: use dev instead of card on storm_parse_of()Kuninori Morimoto
storm_parse_of() can be processed without using *card. No functional change, but is preparation for Card capsuling. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> Link: https://patch.msgid.link/87mrvli0hx.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-21ASoC: qcom: sdm845: remove unused cardKuninori Morimoto
It is not used. Let's remove. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://patch.msgid.link/87o6g1i0i6.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-21ASoC: qcom: common: use devKuninori Morimoto
qcom_snd_parse_of() already have dev. Let's use it. No functional change, but is preparation for Card capsuling. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> Link: https://patch.msgid.link/87pl0hi0il.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-21ASoC: amd: preparation for Card capsulingMark Brown
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> says: I will post Card capsuling patch. To makes its review easy, tidyup its drivers to reduce un-related diff as preparation. No functional change, but is preparation for cleanup driver. Link: https://patch.msgid.link/87bjc1i05a.wl-kuninori.morimoto.gx@renesas.com
2026-07-21ASoC: amd: acp-sdw-sof-mach: use &pdev->dev instead of card->devKuninori Morimoto
acp-sdw-sof-mach.c will be updated when Card capsuling. To makes its review easy, use &pdev->dev instead of card->dev in mc_probe(). There is no diff, because static int mc_probe(...) { ... card->dev = &pdev->dev; ... } No functional change, but is preparation for cleanup driver. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://patch.msgid.link/878q75i04q.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-21ASoC: amd: acp-sdw-legacy-mach: use &pdev->dev instead of card->devKuninori Morimoto
acp-sdw-legacy-mach.c will be updated when Card capsuling. To makes its review easy, use &pdev->dev instead of card->dev in mc_probe(). There is no diff, because static int mc_probe(...) { ... card->dev = &pdev->dev; ... } No functional change, but is preparation for cleanup driver. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://patch.msgid.link/87a4rli04u.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-21selftests/net/openvswitch: add ICMPv6 echo type match testMinxi Hou
Register OVS_KEY_ATTR_ICMPV6 in the flow key parser so that icmpv6(type=...) can be used in flow specifications. Without this registration the parser silently drops the token and the kernel rejects the flow with EINVAL because the expected ICMPv6 key attribute is missing. While here, add convert_int() to the ovs_key_ipv6 and ovs_key_icmp fields_map entries so that specifying a field value produces the correct wildcard mask. The IPv6 flow label uses convert_int(20) to produce a 20-bit mask (0x000FFFFF), matching the kernel constraint in flow_netlink.c that rejects masks with bits 20-31 set; byte-wide fields use convert_int(8). The ipv4 counterpart already does this via convert_int(); the ipv6 and icmp classes were simply missing the fifth tuple element. Existing callers that pass empty parentheses are unaffected because convert_int("") returns (0, 0). Add test_icmpv6 exercising the ICMPv6 echo flow key. The test uses static neighbour entries with nud permanent to prevent racy NDP, then verifies in three steps: install icmpv6(type=128) and icmpv6(type=129) flows and confirm ping works, remove the flows and confirm ping fails, reinstall and confirm recovery. Signed-off-by: Minxi Hou <houminxi@gmail.com> Reviewed-by: Aaron Conole <aconole@redhat.com> Link: https://patch.msgid.link/20260709120541.3556748-1-houminxi@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21regulator: dt-bindings: tps51632: Convert to DT schemaBhargav Joshi
Convert Texas Instruments TPS51632 Voltage regulators from legacy text to DT schema. No functional changes are introduced. Signed-off-by: Bhargav Joshi <j.bhargav.u@gmail.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260717-ti-regulator-tp-v1-1-a49d41dc56d3@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-21ASoC: dt-bindings: ti,omap4-dmic: Convert to DT schemaBhargav Joshi
Convert the TI OMAP4+ dmic bindings from txt to DT schema. Following changes are introduced during converson: - Drop ti,hwmods property as it is not needed since the sysc conversion no existing DTS uses it. - Add dma, dma-names, reg-names properties to match the DTS. - Update example node to match existing DTS. Signed-off-by: Bhargav Joshi <j.bhargav.u@gmail.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260713-ti-omap4-dmic-v1-1-3cc6e13decec@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-21KVM: arm64: vgic-v3: Kill kvm_vgic_global_state.ich_vtr_el2Marc Zyngier
kvm_vgic_global_state.ich_vtr_el2 is the last bit of caching that we can get rid of. Not as bad as a sysreg access, but still worse than a constant. Move over to the inlined stuff and remove the cached value. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260721170754.3150521-7-maz@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-21KVM: arm64: vgic-v3: Simplify initial GICv3 configuration samplingMarc Zyngier
Now that we have our magic inline helper for ICH_VTR_EL2, we can get rid of the hack that was reporting a combination of that register and of the indication of the CPU interface supporting GICv2 compatibility. We now only report the latter. As a small benefit, GICv5 is not involved in this stuff anymore, since it never has GICv2 compatibility.. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260721170754.3150521-6-maz@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-21KVM: arm64: Convert most ICH_VTR_EL2 accesses to inlined literal valueMarc Zyngier
Now that we have a new helper that inlines the value of ICH_VTR_EL2 into the code, use this to replace most of the sysreg accesses to that register. This avoids a lot of traps when running KVM under NV. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260721170754.3150521-5-maz@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-21KVM: arm64: Add a helper providing an inlined literal value for ICH_VTR_EL2Marc Zyngier
We already have two ways to deal with ICH_VTR_EL2: - directly read the system register - read a cached copy in the vgic global state Add a third way, in the form of an inlined literal value that will eventually replace all of the above. This literal value is computed at boot time, and patched in the relevant code locations. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260721170754.3150521-4-maz@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-06 07:34:24 +0000