summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-07-22arm64: dts: nuvoton: npcm845: Reorder timer0 and PECI nodesTomer Maimon
Move the timer0 and PECI nodes so the APB children are ordered by ascending unit address. Signed-off-by: Tomer Maimon <tmaimon77@gmail.com> Link: https://patch.msgid.link/20260708165929.2233934-3-tmaimon77@gmail.com Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
2026-07-22arm64: dts: nuvoton: npcm845: Drop redundant timer clock-namesTomer Maimon
The NPCM845 timer0 node references a single clock, but its clock-names property is not described by the timer binding. Drop the undocumented name so the DTS matches the binding. Signed-off-by: Tomer Maimon <tmaimon77@gmail.com> Link: https://patch.msgid.link/20260708165929.2233934-2-tmaimon77@gmail.com Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
2026-07-22Merge branch 'icc-misc' into icc-nextGeorgi Djakov
* icc-misc interconnect: qcom: add COMPILE_TEST interconnect: qcom: simplify allocation interconnect: debugfs-client: add NULL check for platform_device_alloc interconnect: Fix use after free in icc_get() and of_icc_get_by_index() Signed-off-by: Georgi Djakov <djakov@kernel.org>
2026-07-22Merge branch 'icc-maili' into icc-nextGeorgi Djakov
Add interconnect bindings and RPMh-based interconnect driver support for the upcoming Qualcomm Maili SoC. * icc-maili dt-bindings: interconnect: qcom: document the RPMh Network-On-Chip interconnect in Maili SoC interconnect: qcom: add Maili interconnect provider driver Link: https://patch.msgid.link/20260622-maili_icc-v2-0-18b5ac08c04f@oss.qualcomm.com Signed-off-by: Georgi Djakov <djakov@kernel.org>
2026-07-22Merge branch 'icc-shikra' into icc-nextGeorgi Djakov
Add Epoch Subsystem (EPSS) L3 scaling support on Qualcomm Shikra SoC. EPSS hardware on Shikra is similar to other SoCs but supports only twelve L3 frequency entries (LUT). Reading the LUT beyond supported frequencies can expose incorrect frequencies. Introduce new compatible to represent this constrained variant of EPSS. * icc-shikra dt-bindings: interconnect: qcom,osm-l3: Add EPSS L3 DT binding for Qualcomm Shikra SoC interconnect: qcom: Add EPSS L3 scaling support for Shikra SoC Link: https://patch.msgid.link/20260603-shikra_epss_l3-v3-0-3c2e0b796e78@oss.qualcomm.com Signed-off-by: Georgi Djakov <djakov@kernel.org>
2026-07-22interconnect: Fix use after free in icc_get() and of_icc_get_by_index()Kuan-Wei Chiu
In of_icc_get_by_index() and icc_get(), if the dynamic allocation for path->name fails via kasprintf(), the error handling path directly calls kfree(path) to free the path object and returns an error. However, prior to this point, path_find() calls path_init(), which already links the path's requests into the req_list of the respective interconnect nodes via hlist_add_head(). Directly invoking kfree(path) leaves dangling pointers in the hlist. A subsequent call to icc_get() or icc_set_bw() will traverse or modify these corrupted lists, triggering a slab use afterfree. KASAN report showing the vulnerability when reproducing via debugfs: BUG: KASAN: slab-use-after-free in path_find+0x6f8/0xcfc Write of size 8 at addr fff000000d43f748 by task sh/1 ... Call trace: kasan_report+0xac/0xfc path_find+0x6f8/0xcfc icc_get+0x148/0x380 icc_get_set+0xf8/0x2d0 ... Freed by task 1: kfree+0x1a0/0x4a4 icc_get+0x2cc/0x380 icc_get_set+0xf8/0x2d0 Fix this by replacing kfree(path) with the proper teardown function, icc_put(path), which safely removes the requests from the req_list using hlist_del() and drops the provider usage references before freeing the memory. Additionally, in icc_get(), ensure that the icc_lock mutex is released prior to calling icc_put(path) to avoid a deadlock, as icc_put() internally acquires the same lock. Fixes: 3791163602f7 ("interconnect: Handle memory allocation errors") Cc: stable@vger.kernel.org Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com> Link: https://patch.msgid.link/20260416190840.1753468-1-visitorckw@gmail.com Signed-off-by: Georgi Djakov <djakov@kernel.org>
2026-07-22firmware: arm_scmi: Fix requested device removal raceSudeep Holla
scmi_protocol_device_unrequest() drops scmi_requested_devices_mtx while notifying listeners but continues to retain the per-protocol list head. When two SCMI drivers for the same protocol unregister concurrently, one thread can remove the final request and free the list head while the other is running its notifier. The latter then dereferences the freed list head after reacquiring the mutex and can free it a second time. Complete the list and IDR updates, including freeing an empty list head, before dropping the mutex. Keep the blocking notifier outside the critical section and retain only the detached request across the callback. Fixes: d3cd7c525fd2 ("firmware: arm_scmi: Refactor protocol device creation") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20260722095250.2011630-1-sudeep.holla@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-07-22RDMA/efa: Add Completion Counters supportMichael Margolin
Implement completion counters for the EFA device. Each completion counter is backed by two EFA event counters, one for success completions and one for error completions. The driver creates umem for counters from private descriptor ioctl attributes using core utility. Read operations are not implemented as the counter values are accessed directly from userspace through the mapped memory. Reviewed-by: Yonatan Nachum <ynachum@amazon.com> Signed-off-by: Michael Margolin <mrgolin@amazon.com> Link: https://patch.msgid.link/20260722083603.30334-7-mrgolin@amazon.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-07-22RDMA/efa: Update device interfaceMichael Margolin
Align device interface definitions. Reviewed-by: Daniel Kinsbursky <dkinsb@amazon.com> Reviewed-by: Yonatan Nachum <ynachum@amazon.com> Signed-off-by: Michael Margolin <mrgolin@amazon.com> Link: https://patch.msgid.link/20260722083603.30334-6-mrgolin@amazon.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-07-22RDMA/core: Add Completion Counters to resource trackingMichael Margolin
Track completion counter objects in the resource tracking database so they are visible through the rdma netlink interface. The rdma tool displays the comp_cntr count in the resource summary. Add RDMA_RESTRACK_COMP_CNTR type, embed rdma_restrack_entry in ib_comp_cntr, and add the res_to_dev mapping. Register the resource on create and remove it on destroy. Reviewed-by: Yonatan Nachum <ynachum@amazon.com> Signed-off-by: Michael Margolin <mrgolin@amazon.com> Link: https://patch.msgid.link/20260722083603.30334-5-mrgolin@amazon.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-07-22RDMA/core: Expose Completion Counter capabilities to userspaceMichael Margolin
Add a dedicated query interface for completion counter capabilities via UVERBS_METHOD_QUERY_COMP_CNTR_CAPS on the device object. The query returns the maximum number of counters, maximum counter value, and a bitmask of supported QP attach operations. Each field is an optional ioctl attribute, allowing userspace to request only the capabilities it needs. Drivers implement the query_comp_cntr_caps operation to report device-specific capabilities. Reviewed-by: Yonatan Nachum <ynachum@amazon.com> Signed-off-by: Michael Margolin <mrgolin@amazon.com> Link: https://patch.msgid.link/20260722083603.30334-4-mrgolin@amazon.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-07-22RDMA/core: Prevent destroying in-use completion countersMichael Margolin
Reject comp_cntr destroy while it is attached to any QP. Track attachments using an xarray in ib_qp keyed by the attach op_mask. Use op bitmask to reject overlapping attaches early. Reviewed-by: Yonatan Nachum <ynachum@amazon.com> Signed-off-by: Michael Margolin <mrgolin@amazon.com> Link: https://patch.msgid.link/20260722083603.30334-3-mrgolin@amazon.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-07-22RDMA/core: Add Completion Counters supportMichael Margolin
Add core infrastructure for Completion Counters, a light-weight alternative to polling CQ for tracking operation completions. Define the UVERBS_OBJECT_COMP_CNTR ioctl object with create, destroy, modify and read methods for both success and error counters. Add a QP attach method on the QP object to associate a completion counter with a queue pair. Add ib_comp_cntr struct, ib_comp_cntr_attach_attr, device ops, and DECLARE_RDMA_OBJ_SIZE for driver object allocation. Only userspace Completion Counters are supported at this stage. Reviewed-by: Yonatan Nachum <ynachum@amazon.com> Signed-off-by: Michael Margolin <mrgolin@amazon.com> Link: https://patch.msgid.link/20260722083603.30334-2-mrgolin@amazon.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-07-22RDMA/core: Fix potential use after free in ib_dealloc_pd_user()Patrisious Haddad
When accessing a PD via the netlink path the only synchronization mechanism for the said PD is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of ib_dealloc_pd_user(), which is too late, since by that point vendor-specific resources associated with the PD might already be freed. This can leave a short window where the PD remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_begin_del() call to the start of ib_dealloc_pd_user(), ensuring that the PD is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a PD that is in the process of destruction. In addition, this change preserves the intended inverted order between create and destroy routines: resources are added to restrack at the end of successful creation, and hence shall be removed from the restrack first thing during the destruction flow, which keeps the lifecycle management consistent and predictable. Fixes: 91a7c58fce06 ("RDMA: Restore ability to fail on PD deallocate") Signed-off-by: Patrisious Haddad <phaddad@nvidia.com> Reviewed-by: Michael Guralnik <michaelgur@nvidia.com> Signed-off-by: Edward Srouji <edwards@nvidia.com> Link: https://patch.msgid.link/20260713-restrack-uaf-fix-resub-v2-8-bbe8bb270d51@nvidia.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-07-22RDMA/core: Fix potential use after free in uverbs_free_dmah()Patrisious Haddad
When accessing a dmah via the netlink path the only synchronization mechanism for the said dmah is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of uverbs_free_dmah(), which is too late, since by that point vendor-specific resources associated with the dmah might already be freed. This can leave a short window where the dmah remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_begin_del() call to the start of uverbs_free_dmah(), ensuring that the dmah is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a dmah that is in the process of destruction. In addition, this change preserves the intended inverted order between create and destroy routines: resources are added to restrack at the end of successful creation, and hence shall be removed from the restrack first thing during the destruction flow, which keeps the lifecycle management consistent and predictable. Fixes: d83edab562a4 ("RDMA/core: Introduce a DMAH object and its alloc/free APIs") Signed-off-by: Patrisious Haddad <phaddad@nvidia.com> Reviewed-by: Michael Guralnik <michaelgur@nvidia.com> Signed-off-by: Edward Srouji <edwards@nvidia.com> Link: https://patch.msgid.link/20260713-restrack-uaf-fix-resub-v2-7-bbe8bb270d51@nvidia.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-07-22RDMA/core: Fix potential use after free in ib_free_cq()Patrisious Haddad
When accessing a CQ via the netlink path the only synchronization mechanism for the said CQ is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of ib_free_cq(), which is too late, since by that point vendor-specific resources associated with the CQ might already be freed. This can leave a short window where the CQ remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_del() call to be before the freeing of the vendor-specific resources ensuring that the CQ is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a CQ that is in the process of destruction. Fixes: 43d781b9fa56 ("RDMA: Allow fail of destroy CQ") Signed-off-by: Patrisious Haddad <phaddad@nvidia.com> Reviewed-by: Michael Guralnik <michaelgur@nvidia.com> Signed-off-by: Edward Srouji <edwards@nvidia.com> Link: https://patch.msgid.link/20260713-restrack-uaf-fix-resub-v2-6-bbe8bb270d51@nvidia.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-07-22RDMA/core: Fix potential use after free in counter_release()Patrisious Haddad
When accessing a counter via the netlink path the only synchronization mechanism for the said counter is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of counter_release(), which is too late, since by that point vendor-specific resources associated with the counter might already be freed. This can leave a short window where the counter remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_del() call to be before the freeing of the vendor-specific resources, ensuring that the counter is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a counter that is in the process of destruction. Fixes: 99fa331dc862 ("RDMA/counter: Add "auto" configuration mode support") Signed-off-by: Patrisious Haddad <phaddad@nvidia.com> Reviewed-by: Michael Guralnik <michaelgur@nvidia.com> Signed-off-by: Edward Srouji <edwards@nvidia.com> Link: https://patch.msgid.link/20260713-restrack-uaf-fix-resub-v2-5-bbe8bb270d51@nvidia.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-07-22RDMA/core: Fix potential use after free in ib_destroy_srq_user()Patrisious Haddad
When accessing a SRQ via the netlink path the only synchronization mechanism for the said SRQ is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of ib_destroy_srq_user(), which is too late, since by that point vendor-specific resources associated with the SRQ might already be freed. This can leave a short window where the SRQ remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_begin_del() call to the start of ib_destroy_srq_user(), ensuring that the SRQ is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a SRQ that is in the process of destruction. In addition, this change preserves the intended inverted order between create and destroy routines: resources are added to restrack at the end of successful creation, and hence shall be removed from the restrack first thing during the destruction flow, which keeps the lifecycle management consistent and predictable. Fixes: 48f8a70e899f ("RDMA/restrack: Add support to get resource tracking for SRQ") Signed-off-by: Patrisious Haddad <phaddad@nvidia.com> Reviewed-by: Michael Guralnik <michaelgur@nvidia.com> Signed-off-by: Edward Srouji <edwards@nvidia.com> Link: https://patch.msgid.link/20260713-restrack-uaf-fix-resub-v2-4-bbe8bb270d51@nvidia.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-07-22RDMA/core: Fix potential use after free in ib_destroy_cq_user()Patrisious Haddad
When accessing a CQ via the netlink path the only synchronization mechanism for the said CQ is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of ib_destroy_cq_user(), which is too late, since by that point vendor-specific resources associated with the CQ might already be freed. This can leave a short window where the CQ remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_begin_del() call to the start of ib_destroy_cq_user(), ensuring that the CQ is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a CQ that is in the process of destruction. In addition, this change preserves the intended inverted order between create and destroy routines: resources are added to restrack at the end of successful creation, and hence shall be removed from the restrack first thing during the destruction flow, which keeps the lifecycle management consistent and predictable. Fixes: 08f294a1524b ("RDMA/core: Add resource tracking for create and destroy CQs") Signed-off-by: Patrisious Haddad <phaddad@nvidia.com> Reviewed-by: Michael Guralnik <michaelgur@nvidia.com> Signed-off-by: Edward Srouji <edwards@nvidia.com> Link: https://patch.msgid.link/20260713-restrack-uaf-fix-resub-v2-3-bbe8bb270d51@nvidia.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-07-22RDMA/core: Fix use after free in ib_query_qp()Patrisious Haddad
When querying a QP via the netlink flow the only synchronization mechanism for the said QP is rdma_restrack_get(), meanwhile during the QP destroy path rdma_restrack_del() is called at the end of the ib_destroy_qp_user() function which is too late, since by then the vendor specific resources for said QP would already be destroyed, and till the rdma_restrack_del() is called this QP can still be accessed, which could cause the use after free below. Fix this by moving the rdma_restrack_begin_del() to the start of the ib_destroy_qp_user(), which in turn waits for all usages of the QP to be done then removes it from the database to prevent access to it while it is being destroyed. RIP: 0010:ib_query_qp+0x15/0x50 [ib_core] Code: 48 83 05 5d 8e b9 ff 01 eb b5 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 c7 46 40 00 00 00 00 48 c7 46 78 00 00 00 00 <48> 8b 07 48 8b 80 88 01 00 00 48 85 c0 74 1a 48 83 05 54 91 b9 ff RSP: 0018:ff11000108a8f2f0 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ff11000108a8f370 RCX: ff11000108a8f370 RDX: 0000000000000000 RSI: ff11000108a8f3d8 RDI: 0000000000000000 RBP: ff1100010de5a000 R08: 0000000000000e80 R09: 0000000000000004 R10: ff110001057a604c R11: 0000000000000000 R12: ff11000108a8f370 R13: ff110001090e8000 R14: 0000000000000000 R15: ff110001057a602c FS: 00007f2ffd8db6c0(0000) GS:ff110008dc90b000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010b9a7004 CR4: 0000000000373eb0 Call Trace: <TASK> mlx5_ib_gsi_query_qp+0x21/0x50 [mlx5_ib] mlx5_ib_query_qp+0x689/0x9d0 [mlx5_ib] ib_query_qp+0x35/0x50 [ib_core] fill_res_qp_entry_query.isra.0+0x47/0x280 [ib_core] ? __wake_up+0x40/0x50 ? netlink_broadcast_filtered+0x15a/0x550 ? kobject_uevent_env+0x562/0x710 ? ep_poll_callback+0x242/0x270 ? __nla_put+0xc/0x20 ? nla_put+0x28/0x40 ? nla_put_string+0x2e/0x40 [ib_core] fill_res_qp_entry+0x138/0x190 [ib_core] res_get_common_dumpit+0x4a5/0x800 [ib_core] ? fill_res_qp_entry_query.isra.0+0x280/0x280 [ib_core] nldev_res_get_qp_dumpit+0x1e/0x30 [ib_core] netlink_dump+0x16f/0x450 __netlink_dump_start+0x1ce/0x2e0 rdma_nl_rcv_msg+0x1d3/0x330 [ib_core] ? nldev_res_get_qp_raw_dumpit+0x30/0x30 [ib_core] rdma_nl_rcv_skb.constprop.0.isra.0+0x108/0x180 [ib_core] rdma_nl_rcv+0x12/0x20 [ib_core] netlink_unicast+0x255/0x380 ? __alloc_skb+0xfa/0x1e0 netlink_sendmsg+0x1f3/0x420 __sock_sendmsg+0x38/0x60 ____sys_sendmsg+0x1e8/0x230 ? copy_msghdr_from_user+0xea/0x170 ___sys_sendmsg+0x7c/0xb0 ? __futex_wait+0x95/0xf0 ? __futex_wake_mark+0x40/0x40 ? futex_wait+0x67/0x100 ? futex_wake+0xac/0x1b0 __sys_sendmsg+0x5f/0xb0 do_syscall_64+0x55/0xb90 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Fixes: 514aee660df4 ("RDMA: Globally allocate and release QP memory") Signed-off-by: Patrisious Haddad <phaddad@nvidia.com> Reviewed-by: Michael Guralnik <michaelgur@nvidia.com> Signed-off-by: Edward Srouji <edwards@nvidia.com> Link: https://patch.msgid.link/20260713-restrack-uaf-fix-resub-v2-2-bbe8bb270d51@nvidia.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-07-22RDMA/core: Add rdma_restrack_begin/abort/commit_del() operationsPatrisious Haddad
Add rdma_restrack_abort_del(), rdma_restrack_begin_del() and rdma_restrack_commit_del() functions to allow deleting a resource from the xarray to effectively prevent future access to it and wait for all current users to finish while preserving its index in the xarray to allow to re-insert it if needed with guaranteed success. This is a preparatory change for subsequent patches in the series which will use these functions to fix the cleanup flow. Signed-off-by: Patrisious Haddad <phaddad@nvidia.com> Reviewed-by: Michael Guralnik <michaelgur@nvidia.com> Signed-off-by: Edward Srouji <edwards@nvidia.com> Link: https://patch.msgid.link/20260713-restrack-uaf-fix-resub-v2-1-bbe8bb270d51@nvidia.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-07-22interconnect: debugfs-client: add NULL check for platform_device_allocLi Jun
platform_device_alloc() may return NULL when memory allocation fails. Add proper error handling to prevent a potential NULL pointer dereference when calling platform_device_add() with a NULL pointer. Signed-off-by: Li Jun <lijun01@kylinos.cn> Link: https://patch.msgid.link/20260602103120.2966458-1-lijun01@kylinos.cn Signed-off-by: Georgi Djakov <djakov@kernel.org>
2026-07-22RDMA/mana_ib: drain QP references after partial table insertionLeon Romanovsky
mana_table_store_ud_qp() publishes a QP at its send-queue id before inserting the receive-queue id, dropping the XArray lock between the two xa_insert_irq() calls. A concurrent completion handler can look up the QP and take a transient reference. When the second insertion fails, the rollback erased only the send-queue entry and returned, leaving both the initial table reference and the transient reference outstanding while RDMA core frees the QP, causing a use-after-free. Drain the reference as normal destruction does: drop the initial reference and wait for qp->free, releasing the QP only after every concurrent lookup returns its reference. Fixes: 8001e9257eca ("RDMA/mana_ib: extend mana QP table") Link: https://patch.msgid.link/20260721-if-mana-table-store-qp-qids-partiall-v1-1-8fb3d2d2b559@nvidia.com Reviewed-by: Konstantin Taranov <kotaranov@microsoft.com> Reviewed-by: Long Li <longli@microsoft.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
2026-07-22USB: serial: io_edgeport: cap received transmit creditsSunho Park
The interrupt-status packet reports transmit credits returned by the device. edge_interrupt_callback() adds the 16-bit value to txCredits without checking maxTxCredits. edge_write() uses txCredits minus the software FIFO count as the amount of data that fits. Since the FIFO is allocated with maxTxCredits bytes, txCredits exceeding maxTxCredits can cause OOB write in ring buffer. Cap accumulated credits at maxTxCredits. Conforming devices should never hit the cap. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Sunho Park <shpark061104@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2026-07-22wifi: brcmfmac: fix 802.1X-SHA256 call trace warningShelley Yang
Based on wpa_auth as 1x_256 mode, need to set up "use_fwsup" with BRCMF_PROFILE_FWSUP_1X. Or it will happen trace warning when call brcmf_cfg80211_set_pmk(). [ 4481.831101] ------------[ cut here ]------------ [ 4481.831102] WARNING: CPU: 1 PID: 2997 at drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:7242 brcmf_cfg80211_set_pmk+0x77/0xd0 [brcmfmac] [...] [ 4481.831202] Call Trace: [ 4481.831204]  <TASK> [ 4481.831205]  nl80211_set_pmk+0x183/0x250 [cfg80211] [ 4481.831233]  genl_family_rcv_msg_doit+0xea/0x150 [ 4481.831237]  genl_rcv_msg+0x104/0x240 [ 4481.831239]  ? cfg80211_probe_status+0x2c0/0x2c0 [cfg80211] [ 4481.831257]  ? genl_family_rcv_msg_doit+0x150/0x150 [ 4481.831259]  netlink_rcv_skb+0x4e/0x100 [ 4481.831261]  genl_rcv+0x24/0x40 [ 4481.831262]  netlink_unicast+0x236/0x380 [ 4481.831264]  netlink_sendmsg+0x250/0x4b0 [ 4481.831266]  sock_sendmsg+0x5c/0x70 [ 4481.831269]  ____sys_sendmsg+0x236/0x2b0 [ 4481.831271]  ? copy_msghdr_from_user+0x6d/0xa0 [ 4481.831272]  ___sys_sendmsg+0x86/0xd0 [ 4481.831274]  ? avc_has_perm+0x8c/0x1a0 [ 4481.831276]  ? preempt_count_add+0x6a/0xa0 [ 4481.831279]  ? sock_has_perm+0x82/0xa0 [ 4481.831280]  __sys_sendmsg+0x57/0xa0 [ 4481.831282]  do_syscall_64+0x38/0x90 [ 4481.831284]  entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 4481.831286] RIP: 0033:0x7fd270d369b4 Fixes: 2526ff21aa77 ("brcmfmac: support 4-way handshake offloading for 802.1X") Signed-off-by: Shelley Yang <shelley.yang@infineon.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260525083859.581246-1-shelley.yang@infineon.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-07-22interconnect: qcom: simplify allocationRosen Penev
Use a flexible array member to reduce allocation by 1. Add __counted_by for extra runtime analysis. Move counting variable assignment after allocation before any array access. Signed-off-by: Rosen Penev <rosenp@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://patch.msgid.link/20260609222454.37352-1-rosenp@gmail.com Signed-off-by: Georgi Djakov <djakov@kernel.org>
2026-07-22interconnect: qcom: add COMPILE_TESTRosen Penev
Allow non-ARM to build this. Signed-off-by: Rosen Penev <rosenp@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://patch.msgid.link/20260608050542.6167-1-rosenp@gmail.com Signed-off-by: Georgi Djakov <djakov@kernel.org>
2026-07-22RDMA/mlx5: move mlx5 clock info to common struct ib_uverbs_clock_infoAbhijit Gangurde
Use struct ib_uverbs_clock_info from ib_user_verbs.h for clock info. Signed-off-by: Abhijit Gangurde <abhijit.gangurde@amd.com> Link: https://patch.msgid.link/20260610154216.712374-6-abhijit.gangurde@amd.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-07-22RDMA/ionic: add completion timestamp to CQE formatAbhijit Gangurde
Update the CQE structure to include hardware timestamp. When firmware supports RDMA completion timestamps, the hardware populates the timestamp field. Co-developed-by: Allen Hubbe <allen.hubbe@amd.com> Signed-off-by: Allen Hubbe <allen.hubbe@amd.com> Signed-off-by: Abhijit Gangurde <abhijit.gangurde@amd.com> Link: https://patch.msgid.link/20260610154216.712374-5-abhijit.gangurde@amd.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-07-22RDMA/ionic: map PHC state into user spaceAbhijit Gangurde
Enable user space applications to access the PHC state page when firmware RDMA completion timestamp is supported. This mapping allows user space to convert RDMA completion timestamps to system wall time without kernel transitions, minimizing latency overhead. Applications can directly read the PHC state through mmap, enabling efficient timestamp correlation for precision timing applications. Co-developed-by: Allen Hubbe <allen.hubbe@amd.com> Signed-off-by: Allen Hubbe <allen.hubbe@amd.com> Signed-off-by: Abhijit Gangurde <abhijit.gangurde@amd.com> Link: https://patch.msgid.link/20260610154216.712374-4-abhijit.gangurde@amd.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-07-22net: ionic: Add PHC state page for user space accessAbhijit Gangurde
Add a page associated with the PHC that can be mapped to user space, allowing applications to access hardware timestamp information. In order to synchronize between kernel and user space, a sequence number is incremented at the beginning and end of each update. An odd number means the data is being updated while an even number means the update is complete. To guarantee that the data structure was accessed atomically, user space will: repeat: seq1 = <read sequence> goto <repeat> if odd <read PHC state> seq2 = <read sequence> if seq1 != seq2 goto repeat This mechanism acts as a guard against reading invalid state during concurrent updates. Co-developed-by: Allen Hubbe <allen.hubbe@amd.com> Signed-off-by: Allen Hubbe <allen.hubbe@amd.com> Signed-off-by: Abhijit Gangurde <abhijit.gangurde@amd.com> Link: https://patch.msgid.link/20260610154216.712374-3-abhijit.gangurde@amd.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-07-22net: ionic: register PHC for rdma timestampingAbhijit Gangurde
Currently, the driver only registers the PTP Hardware Clock (PHC) if Ethernet hardware timestamping is supported. Update the registration logic to register the PHC if the device supports either Ethernet hardware timestamping or RDMA completion timestamping. Co-developed-by: Allen Hubbe <allen.hubbe@amd.com> Signed-off-by: Allen Hubbe <allen.hubbe@amd.com> Signed-off-by: Abhijit Gangurde <abhijit.gangurde@amd.com> Link: https://patch.msgid.link/20260610154216.712374-2-abhijit.gangurde@amd.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-07-22Merge tag 'mt76-fixes-2026-07-22' of https://github.com/nbd168/wirelessJohannes Berg
Felix Fietkau says: =================== mt76 fixes for 7.2 - fix warnings on removing device - null pointer deref fixes - fix for data structure confusion on USB/SDIO devices =================== Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-07-22RDMA/erdma: Fix CEQ tasklet use-after-free on removalMyeonghun Pak
Each CEQ interrupt handler only schedules eqc->tasklet. The tasklet calls erdma_ceq_completion_handler(), which reads the DMA-coherent EQ ring through get_next_valid_eqe() and updates eq->dbrec through notify_eq(). erdma_ceqs_uninit() frees each CEQ IRQ and then destroys its EQ. free_irq() prevents another hard IRQ and waits for an in-flight handler, but it does not drain a tasklet that the handler already scheduled. The tasklet can therefore access eq->qbuf or eq->dbrec after erdma_eq_destroy() frees them. Clearing ceq_cb->ready does not synchronize with a tasklet that already passed the check at the start of erdma_ceq_completion_handler(). Kill the tasklet after free_irq(), when no handler can schedule it again, and before erdma_ceq_uninit_one() releases the EQ buffers. Fixes: f2a0a630b953 ("RDMA/erdma: Add event queue implementation") Co-developed-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Myeonghun Pak <mhun512@gmail.com> Link: https://patch.msgid.link/20260721082545.47395-1-mhun512@gmail.com Acked-by: Cheng Xu <chengyou@linux.alibaba.com> Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-07-21sched_ext: Build the cid tables privately and publish them with RCUTejun Heo
The cid tables are visible to the cid kfuncs while being modified: the first enable publishes the global pointers before filling them, ops.init_cids() overrides rewrite them in place, and re-enables rebuild them in place. A racing TRACING or SYSCALL program can read unfilled entries, including uninitialized memory in the kmalloc'd tables, or torn topo updates. Tie the tables' lifetimes to the root sched instead: each root enable builds a fresh set privately and publishes the per-table __rcu globals once the layout is final, and root disable unpublishes and RCU-frees the set. A non-NULL global is now always a fully built table which stays valid for the reader's RCU read section, and lookups stay two loads. Kfuncs treat NULL as no-mapping, also after the scheduler exits instead of reporting the stale last mapping. The cid kfuncs are available whether the root scheduler is cid-form or cpu-form, the latter to allow gradual migration to cids. Every root therefore builds and publishes a default mapping. Every reader must either be gated on scheduler liveness or NULL-check inside an RCU read section. Fix the two kfuncs that were neither: scx_bpf_this_cid() read the table with no RCU or preemption protection and scx_bpf_task_cid() relied on KF_RCU, which doesn't put a sleepable program in an RCU read section. The hotplug callbacks are instead serialized by retiring the tables inside the cpus_read_lock() section that clears scx_root. v2: Document why every root builds the tables (desc + cid.c comment). Reported-by: Andrea Righi <arighi@nvidia.com> Closes: https://lore.kernel.org/r/al3tLtPZZkFjMveK@gpd4 Reviewed-by: Andrea Righi <arighi@nvidia.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2026-07-21sched_ext: Drop unused scx_cpumask_to_cmask()Tejun Heo
scx_cpumask_to_cmask() has no callers. Reviewed-by: Andrea Righi <arighi@nvidia.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2026-07-21sched_ext: Skip the default CPU selection while bypassingTejun Heo
select_task_rq_scx() falls into the default path when the scheduler has no ops.select_cpu or is bypassing. There it calls scx_select_cpu_dfl() and direct-dispatches to the picked CPU's local DSQ. While bypassing, neither does anything: the enqueue path routes the task to a bypass DSQ before consulting the direct-dispatch target, so the direct dispatch never happens, and the CPU pick at most shifts which CPU's bypass DSQ receives the task. Worse, when the scheduler does its own idle tracking, the built-in idle cpumasks the pick consults are not even updated, so it doesn't work anyway. Return prev_cpu without the default selection while bypassing and let the bypass enqueue place the task. Reviewed-by: Andrea Righi <arighi@nvidia.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2026-07-21sched_ext: Blame the DSQ's owning scheduler for a runnable stallTejun Heo
check_rq_for_timeouts() blames a runnable stall on the task's owner. Under a sub-scheduler hierarchy the stalled task can be sitting on a DSQ that a different scheduler has to drain, e.g. an ancestor's bypass DSQ while the owner is bypassing. The drainer then escapes blame while the owner is exited, and when the owner's exit is already claimed, nothing actionable is reported at all. Blame the DSQ's owning scheduler instead. The local DSQ is consumed by the cpu itself and keeps blame on the owner. Detection keeps the owner's timeout and single-scheduler behavior is unchanged. Reviewed-by: Andrea Righi <arighi@nvidia.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2026-07-22phy: qcom-qmp-pcie: Add support for ipq5210 PCIe physVaradarajan Narayanan
Add support for a PCIe phys found on Qualcomm ipq5210 platform. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com> Link: https://patch.msgid.link/20260721-pcie-phy-v5-2-8d403ef7e780@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-07-22dt-bindings: phy: qcom,ipq8074-qmp-pcie: Document the ipq5210 QMP PCIe PHYVaradarajan Narayanan
The ipq5210 has one dual lane and one single lane PCIe phy. The dual lane phy is similar to the dual lane phy present in ipq9574. Hence qcom,ipq5210-qmp-gen3x2-pcie-phy is documented with ipq9574's dual lane phy as fallback compatible. The single lane phy (qcom,ipq5210-qmp-gen3x1-pcie-phy) is documented as specific compatible as it uses a combination of its own initialization tables and some of the existing tables. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com> Link: https://patch.msgid.link/20260721-pcie-phy-v5-1-8d403ef7e780@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-07-22phy: zynqmp: fix runtime PM leak on probe allocation failureRadhey Shyam Pandey
Allocate saved_regs before pm_runtime_resume_and_get() so a devm_kmalloc() failure does not leave an unreleased runtime PM usage counter. Fixes: 5af9b304bc60 ("phy: xilinx: phy-zynqmp: Fix SGMII linkup failure on resume") Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com> Reviewed-by: Michal Simek <michal.simek@amd.com> Link: https://patch.msgid.link/20260720153832.1130006-3-radhey.shyam.pandey@amd.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-07-22phy: zynqmp: fix clock error handling in xpsgtr_phy_init()Radhey Shyam Pandey
Propagate clk_prepare_enable() failures to the caller instead of returning success, and disable the reference clock on initialization error paths to avoid leaking clock references when phy_exit() is not called. Fixes: 25d700833513 ("phy: xilinx: phy-zynqmp: dynamic clock support for power-save") Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com> Reviewed-by: Michal Simek <michal.simek@amd.com> Link: https://patch.msgid.link/20260720153832.1130006-2-radhey.shyam.pandey@amd.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-07-22phy: qcom: qmp-usbc: Add qmp configuration for ShikraKrishna Kurapati
Add init sequence and phy configuration for the Super Speed port on Shikra SoC. Also since Shikra uses 3 resets, add support for the third reset and configure Shikra platform data to use 3 resets. Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://patch.msgid.link/20260712-usb-shikra-phy-v6-v6-4-1b3e51bf1541@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-07-22phy: qcom-qusb2: Add support for ShikraKrishna Kurapati
Add init sequence and phy configuration for Shikra. Since the init sequence is same as that of QCS615, reuse the existing init table in Shikra. Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://patch.msgid.link/20260712-usb-shikra-phy-v6-v6-3-1b3e51bf1541@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-07-22dt-bindings: phy: qcs615-qmp-usb3dp: Add support for Shikra SoCKrishna Kurapati
Declare the USB-C QMP PHY present on the Qualcomm Shikra SoC. Shikra uses 3 resets to be programmed before initialising the phy. As per the hardware documentation, the third reset is PHY_PRIM_SP0_BCR, hence naming it "phy". Also, add remote endpoints and orientation switch support for getting Type-C orientation information. Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260712-usb-shikra-phy-v6-v6-2-1b3e51bf1541@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-07-22dt-bindings: phy: qcom,qusb2: Document QUSB2 Phy for ShikraKrishna Kurapati
Update dt-bindings to add Shikra to QUSB2 Phy list. Shikra SoC has two High Speed QUSB2 Phys. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com> Link: https://patch.msgid.link/20260712-usb-shikra-phy-v6-v6-1-1b3e51bf1541@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-07-22mm/mm_init: remove redundant memset in free_area_init()Sang-Heon Jeon
zone_movable_pfn is zero-initialized and only set by find_zone_movable_pfns_for_nodes(), which runs once during boot right after the memset, so the memset has no effect. Remove redundant memset. No functional change. Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com> Link: https://patch.msgid.link/20260720150915.756749-1-ekffu200098@gmail.com Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
2026-07-22drm/i915/dp: set VSC_SDP MSA delegation only for capable sinksChaitanya Kumar Borah
Per DP 1.4a section 2.2.4.3, the MSA MISC1 VSC_SDP bit signals that the sink should defer colorimetry to the VSC SDP. It should only be set when the sink advertises DP_VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED and a VSC SDP with pixel encoding/colorimetry payload will actually be sent. Fold the colorimetry_support check into intel_dp_needs_vsc_colorimetry() so both intel_ddi_set_dp_msa() and intel_dp_compute_vsc_sdp() share a single consistent gate. Assisted-by: GitHub_Copilot:claude-sonnet-4.6 Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Pranay Samala <pranay.samala@intel.com> Link: https://patch.msgid.link/20260709113951.3557968-3-chaitanya.kumar.borah@intel.com
2026-07-22drm/i915/dp: s/intel_dp_needs_vsc_sdp/intel_dp_needs_vsc_colorimetryChaitanya Kumar Borah
The function answers whether a VSC SDP with colorimetry and pixel encoding payload is required by the content being displayed. Rename it to reflect that. No functional change intended. Assisted-by: GitHub_Copilot:claude-sonnet-4.6 Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Pranay Samala <pranay.samala@intel.com> Link: https://patch.msgid.link/20260709113951.3557968-2-chaitanya.kumar.borah@intel.com
2026-07-22phy: lynx-10g: fix lynx_10g_pccr_val_enabled()Vladimir Oltean
The intention of the code is to extract the PCCR8_SGMIIa_CFG field out of the "pccr" value, not to create a new value with the PCCR8_SGMIIa_CFG field set to the "pccr" value. Since FIELD_GET() is implemented as ((reg) & (mask)) >> __bf_shf(mask) and FIELD_PREP() as (val) << __bf_shf(mask)) & (mask) and since "mask" is GENMASK(2, 0), in practice there is no functional difference between FIELD_GET() and FIELD_PREP(). But FIELD_GET() is logically the correct helper. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20260612125731.133330-1-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>