Update README Test - #12
Open
sgaud-quic wants to merge 102 commits into
Open
Conversation
Document the DPU for Qualcomm QCS8300 platform. It use the same DPU hardware with SA8775P and reuse it's driver. Link:https://lore.kernel.org/all/20250911-qcs8300_mdss-v12-1-5f7d076e2b81@oss.qualcomm.com/ Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
…ompatible Add compatible string for the DisplayPort controller found on the Qualcomm QCS8300 SoC. The Qualcomm QCS8300 platform comes with one DisplayPort controller that supports 4 MST streams, similar to the one found on the SA8775P. Link:https://lore.kernel.org/all/20250911-qcs8300_mdss-v12-2-5f7d076e2b81@oss.qualcomm.com/ Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
Document the MDSS hardware found on the Qualcomm QCS8300 platform. Link:https://lore.kernel.org/all/20250911-qcs8300_mdss-v12-3-5f7d076e2b81@oss.qualcomm.com/ Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
The QCS8300 supports UBWC 4.0 and 4 channels LP5 memory interface. Use the SC8280XP data structure for QCS8300 according to the specification. Link:https://lore.kernel.org/all/20250911-qcs8300_mdss-v12-4-5f7d076e2b81@oss.qualcomm.com/ Acked-by: Bjorn Andersson <andersson@kernel.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
Add Mobile Display Subsystem (MDSS) support for the QCS8300 platform. Link:https://lore.kernel.org/all/20250911-qcs8300_mdss-v12-5-5f7d076e2b81@oss.qualcomm.com/ Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
…r control Introduce the channel map mixer control support for LPASS macro codec Digital Audio Interfaces (DAIs). The channel map mixer controls are required by APPS to configure usecase-specific audio routing and channel mapping. Link: https://lore.kernel.org/linux-sound/708dc6e4-1566-4c72-9f3a-a34f935ac247@oss.qualcomm.com/ Signed-off-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>
…DAI links In setups where the same codec DAI is reused across multiple DAI links, mute controls via `snd_soc_dai_digital_mute()` is skipped for non-dynamic links. The trigger operations are not invoked when `dai_link->dynamic == 0`, and mute controls is currently conditioned only on `snd_soc_dai_mute_is_ctrled_at_trigger()`. This patch ensures that mute and unmute is applied explicitly for non-dynamic links. Link: https://lore.kernel.org/linux-sound/20251007023325.853640-1-mohammad.rafi.shaik@oss.qualcomm.com/ Fixes: f022057 ("ASoC: soc-dai: add flag to mute and unmute stream during trigger") Cc: stable@vger.kernel.org Signed-off-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>
Most Qualcomm platforms feature Gunyah hypervisor which handles IOMMU configuration for remote processor and when it is not present, the operating system must perform these configurations instead and for that firmware stream should be presented to the operating system. Hence, add iommus property as optional property for PAS supported devices. Link: https://lore.kernel.org/lkml/20251013-kvm_rprocv5-v5-1-d609ed766061@oss.qualcomm.com/ Acked-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Peripheral and pas_id refers to unique id for a subsystem and used only when peripheral authentication service from secure world is utilized. Lets rename peripheral to pas_id to reflect closer to its meaning. Link: https://lore.kernel.org/lkml/20251013-kvm_rprocv5-v5-2-d609ed766061@oss.qualcomm.com/ Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
…lper function When the Peripheral Authentication Service (PAS) method runs on a SoC where Linux operates at EL2 (i.e., without the Gunyah hypervisor), the reset sequences are handled by TrustZone. In such cases, Linux must perform additional steps before invoking PAS SMC calls, such as creating a SHM bridge. Therefore, PAS SMC calls require awareness and handling of these additional steps when Linux runs at EL2. To support this, there is a need for a data structure that can be initialized prior to invoking any SMC or MDT functions. This structure allows those functions to determine whether they are operating in the presence or absence of the Gunyah hypervisor and behave accordingly. Currently, remoteproc and non-remoteproc subsystems use different variants of the MDT loader helper API, primarily due to differences in metadata context handling. Remoteproc subsystems retain the metadata context until authentication and reset are completed, while non-remoteproc subsystems (e.g., video, graphics, IPA, etc.) do not retain the metadata context and can free it within the qcom_scm_pas_init() call by passing a NULL context parameter and due to these differences, it is not possible to extend metadata context handling to support remoteproc and non remoteproc subsystem use PAS operations, when Linux operates at EL2. Add PAS context data structure and initialization helper function. Link: https://lore.kernel.org/lkml/20251013-kvm_rprocv5-v5-3-d609ed766061@oss.qualcomm.com/ Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
…structure As a superset of the existing metadata context, the PAS context structure enables both remoteproc and non-remoteproc subsystems to better support scenarios where the SoC runs with or without the Gunyah hypervisor. To reflect this, relevant SCM and metadata functions are updated to incorporate PAS context awareness. Link: https://lore.kernel.org/lkml/20251013-kvm_rprocv5-v5-4-d609ed766061@oss.qualcomm.com/ Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
…ad() function Introduce a new PAS context-aware function, qcom_mdt_pas_load(), for remote processor drivers. This function utilizes the PAS context pointer returned from qcom_scm_pas_ctx_init() to perform firmware metadata verification and memory setup via SMC calls. The qcom_mdt_pas_load() and qcom_mdt_load() functions are largely similar, but the former is designed for clients using the PAS context-based data structure. Over time, all users of qcom_mdt_load() can be migrated to use qcom_mdt_pas_load() for consistency and improved abstraction. As the remoteproc PAS driver (qcom_q6v5_pas) has already adopted the PAS context-based approach, update it to use qcom_mdt_pas_load(). Link: https://lore.kernel.org/lkml/20251013-kvm_rprocv5-v5-5-d609ed766061@oss.qualcomm.com/ Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
…ted symbols qcom_mdt_pas_init() was previously used only by the remoteproc driver (drivers/remoteproc/qcom_q6v5_pas.c). Since that driver has now transitioned to using PAS context-based qcom_mdt_pas_load() function, making qcom_mdt_pas_init() obsolete for external use. Removes qcom_mdt_pas_init() from the list of exported symbols and make it static to limit its scope to internal use within mdtloader. Link: https://lore.kernel.org/lkml/20251013-kvm_rprocv5-v5-6-d609ed766061@oss.qualcomm.com/ Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
…nction For memory passed to TrustZone (TZ), it must either be part of a pool registered with TZ or explicitly registered via SHMbridge SMC calls. When Gunyah hypervisor is present, PAS SMC calls from Linux running at EL1 are trapped by Gunyah running @ EL2, which handles SHMbridge creation for both metadata and remoteproc carveout memory before invoking the calls to TZ. On SoCs running with a non-Gunyah-based hypervisor, Linux must take responsibility for creating the SHM bridge before invoking PAS SMC calls. For the auth_and_reset() call, the remoteproc carveout memory must first be registered with TZ via a SHMbridge SMC call and once authentication and reset are complete, the SHMbridge memory can be deregistered. Introduce qcom_scm_pas_prepare_and_auth_reset(), which sets up the SHM bridge over the remoteproc carveout memory when Linux operates at EL2. This behavior is indicated by a new field added to the PAS context data structure. The function then invokes the auth_and_reset SMC call. Link: https://lore.kernel.org/lkml/20251013-kvm_rprocv5-v5-7-d609ed766061@oss.qualcomm.com/ Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Simplify qcom_scm_pas_init_image() by making the memory allocation, copy and free operations done in a separate function than the actual SMC call. Link: https://lore.kernel.org/lkml/20251013-kvm_rprocv5-v5-8-d609ed766061@oss.qualcomm.com/ Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
…nning without QHEE On SoCs running with a non-Gunyah-based hypervisor, Linux must take responsibility for creating the SHM bridge both for metadata (before calling qcom_scm_pas_init_image()) and for remoteproc memory (before calling qcom_scm_pas_auth_and_reset()). We have taken care the things required for qcom_scm_pas_auth_and_reset(). Lets put these awareness of above conditions into qcom_scm_pas_init_image() and qcom_scm_pas_metadata_release(). Link: https://lore.kernel.org/lkml/20251013-kvm_rprocv5-v5-9-d609ed766061@oss.qualcomm.com/ Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
… resource table Qualcomm remote processor may rely on Static and Dynamic resources for it to be functional. Static resources are fixed like for example, memory-mapped addresses required by the subsystem and dynamic resources, such as shared memory in DDR etc., are determined at runtime during the boot process. For most of the Qualcomm SoCs, when run with Gunyah or older QHEE hypervisor, all the resources whether it is static or dynamic, is managed by the hypervisor. Dynamic resources if it is present for a remote processor will always be coming from secure world via SMC call while static resources may be present in remote processor firmware binary or it may be coming qcom_scm_pas_get_rsc_table() SMC call along with dynamic resources. Some of the remote processor drivers, such as video, GPU, IPA, etc., do not check whether resources are present in their remote processor firmware binary. In such cases, the caller of this function should set input_rt and input_rt_size as NULL and zero respectively. Remoteproc framework has method to check whether firmware binary contain resources or not and they should be pass resource table pointer to input_rt and resource table size to input_rt_size and this will be forwarded to TrustZone for authentication. TrustZone will then append the dynamic resources and return the complete resource table in output_rt More about documentation on resource table format can be found in include/linux/remoteproc.h Link: https://lore.kernel.org/lkml/20251013-kvm_rprocv5-v5-10-d609ed766061@oss.qualcomm.com/ Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
…s via SMC call Qualcomm remote processor may rely on static and dynamic resources for it to be functional. For most of the Qualcomm SoCs, when run with Gunyah or older QHEE hypervisor, all the resources whether it is static or dynamic, is managed by the hypervisor. Dynamic resources if it is present for a remote processor will always be coming from secure world via SMC call while static resources may be present in remote processor firmware binary or it may be coming from SMC call along with dynamic resources. Remoteproc already has method like rproc_elf_load_rsc_table() to check firmware binary has resources or not and if it is not having then we pass NULL and zero as input resource table and its size argument respectively to qcom_scm_pas_get_rsc_table() and while it has resource present then it should pass the present resources to Trustzone(TZ) so that it could authenticate the present resources and append dynamic resource to return in output_rt argument along with authenticated resources. Extend parse_fw callback to include SMC call to get resources from Trustzone and to leverage resource table parsing and mapping and unmapping code from the remoteproc framework. Link: https://lore.kernel.org/lkml/20251013-kvm_rprocv5-v5-11-d609ed766061@oss.qualcomm.com/ Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
… managed by Linux Most Qualcomm platforms feature Gunyah hypervisor, which typically handles IOMMU configuration. This includes mapping memory regions and device memory resources for remote processors by intercepting qcom_scm_pas_auth_and_reset() calls. These mappings are later removed during teardown. Additionally, SHM bridge setup is required to enable memory protection for both remoteproc metadata and its memory regions. When the aforementioned hypervisor is absent, the operating system must perform these configurations instead. When Linux runs as the hypervisor (@ EL2) on a SoC, it will have its own device tree overlay file that specifies the firmware stream ID now managed by Linux for a particular remote processor. If the iommus property is specified in the remoteproc device tree node, it indicates that IOMMU configuration must be handled by Linux. In this case, the has_iommu flag is set for the remote processor, which ensures that the resource table, carveouts, and SHM bridge are properly configured before memory is passed to TrustZone for authentication. Otherwise, the has_iommu flag remains unset, which indicates default behavior. Enables Secure PAS support for remote processors when IOMMU configuration is managed by Linux. Link: https://lore.kernel.org/lkml/20251013-kvm_rprocv5-v5-12-d609ed766061@oss.qualcomm.com/ Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
On X Elite platform, the eDP PHY uses one more clock called ref. The current X Elite devices supported upstream work fine without this clock, because the boot firmware leaves this clock enabled. But we should not rely on that. Also, even though this change breaks the ABI, it is needed in order to make the driver disables this clock along with the other ones, for a proper bring-down of the entire PHY. So attach the this ref clock to the PHY. Cc: stable@vger.kernel.org # v6.10 Fixes: 5d56078 ("dt-bindings: phy: qcom-edp: Add X1E80100 PHY compatibles") Link:https://lore.kernel.org/all/20250909-phy-qcom-edp-add-missing-refclk-v3-1-4ec55a0512ab@linaro.org/ Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
On X Elite, the DP PHY needs another clock called ref, while all other platforms do not. The current X Elite devices supported upstream work fine without this clock, because the boot firmware leaves this clock enabled. But we should not rely on that. Also, even though this change breaks the ABI, it is needed in order to make the driver disables this clock along with the other ones, for a proper bring-down of the entire PHY. So in order to handle these clocks on different platforms, make the driver get all the clocks regardless of how many there are provided. Cc: stable@vger.kernel.org # v6.10 Fixes: db83c10 ("phy: qcom: edp: Add v6 specific ops and X1E80100 platform support") Link:https://lore.kernel.org/all/20250909-phy-qcom-edp-add-missing-refclk-v3-2-4ec55a0512ab@linaro.org/ Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Add edp reference clock for sa8775p edp phy. Link:https://lore.kernel.org/all/20251013104806.6599-2-quic_riteshk@quicinc.com/ Signed-off-by: Ritesh Kumar <quic_riteshk@quicinc.com>
… example Update clock entry in edp phy example node to add support for edp reference clock. Link:https://lore.kernel.org/all/20251013104806.6599-3-quic_riteshk@quicinc.com/ Signed-off-by: Ritesh Kumar <quic_riteshk@quicinc.com>
A612 GPU has a new IP called RGMU (Reduced Graphics Management Unit) which replaces GMU. But it doesn't do clock or voltage scaling. So we need the gpu core clock in the GPU node along with the power domain to do clock and voltage scaling from the kernel. Update the bindings to describe this GPU. Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Link: https://lore.kernel.org/all/20251107-qcs615-spin-2-v2-2-a2d7c4fbf6e6@oss.qualcomm.com/
RGMU a.k.a Reduced Graphics Management Unit is a small state machine with the sole purpose of providing IFPC (Inter Frame Power Collapse) support. Compared to GMU, it doesn't manage GPU clock, voltage scaling, bw voting or any other functionalities. All it does is detect an idle GPU and toggle the GDSC switch. As it doesn't access DDR space, it doesn't require iommu. So far, only Adreno 612 GPU has an RGMU core. Document RGMU in the GMU's schema. Signed-off-by: Jie Zhang <jie.zhang@oss.qualcomm.com> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Link: https://lore.kernel.org/all/20251107-qcs615-spin-2-v2-3-a2d7c4fbf6e6@oss.qualcomm.com/
…link Since max_dp_lanes and max_dp_link_rate are link-specific parameters, move their parsing from dp_panel to dp_link for better separation of concerns. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Xiangxu Yin <xiangxu.yin@oss.qualcomm.com> Link: https://lore.kernel.org/all/20250926-add-displayport-support-for-qcs615-platform-v7-13-dc5edaac6c2b@oss.qualcomm.com/
QCS615 platform requires non-default logical-to-physical lane mapping due to its unique hardware routing. Unlike the standard mapping sequence <0 1 2 3>, QCS615 uses <3 2 0 1>, which necessitates explicit configuration via the data-lanes property in the device tree. This ensures correct signal routing between the DP controller and PHY. For partial definitions, fill remaining lanes with unused physical lanes in ascending order. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Xiangxu Yin <xiangxu.yin@oss.qualcomm.com> Link: https://lore.kernel.org/all/20250926-add-displayport-support-for-qcs615-platform-v7-14-dc5edaac6c2b@oss.qualcomm.com/
Add DisplayPort controller binding for Qualcomm SM6150 SoC. SM6150 uses the same controller IP as SM8150. Declare 'qcom,sm6150-dp' as a fallback compatible to 'qcom,sm8150-dp' and 'qcom,sm8350-dp' for consistency with existing bindings and to ensure correct matching and future clarity. Signed-off-by: Xiangxu Yin <xiangxu.yin@oss.qualcomm.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20250916-add-dp-controller-support-for-sm6150-v3-1-dd60ebbd101e@oss.qualcomm.com/
…troller SM6150 uses the same DisplayPort controller as SM8150, which is compatible with SM8350. Add SM6150-specific compatible string for the DisplayPort controller. Signed-off-by: Xiangxu Yin <xiangxu.yin@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/all/20251104-add-displayport-support-to-qcs615-devicetree-v7-1-e51669170a6f@oss.qualcomm.com/
…tion and OPP values Improve the binding example by fixing indentation and adding missing blank lines for better readability. Also correct the OPP clock values to match the actual SM6150 DTS configuration. Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Xiangxu Yin <xiangxu.yin@oss.qualcomm.com> Link: https://lore.kernel.org/all/20251104-add-displayport-support-to-qcs615-devicetree-v7-2-e51669170a6f@oss.qualcomm.com/
# Conflicts: # arch/arm64/boot/dts/qcom/Makefile
# Conflicts: # include/linux/firmware/qcom/qcom_scm.h
Adding merge log file and topic_SHA1 file Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
quic-viskuma
self-requested a review
December 16, 2025 11:23
quic-viskuma
approved these changes
Dec 16, 2025
sgaud-quic
force-pushed
the
qcom-6.18.y
branch
from
December 22, 2025 16:48
a7f4923 to
2750785
Compare
sgaud-quic
pushed a commit
that referenced
this pull request
Apr 22, 2026
[ Upstream commit a6413e6 ] XDP multi-buf programs can modify the layout of the XDP buffer when the program calls bpf_xdp_pull_data() or bpf_xdp_adjust_tail(). The referenced commit in the fixes tag corrected the assumption in the mlx5 driver that the XDP buffer layout doesn't change during a program execution. However, this fix introduced another issue: the dropped fragments still need to be counted on the driver side to avoid page fragment reference counting issues. Such issue can be observed with the test_xdp_native_adjst_tail_shrnk_data selftest when using a payload of 3600 and shrinking by 256 bytes (an upcoming selftest patch): the last fragment gets released by the XDP code but doesn't get tracked by the driver. This results in a negative pp_ref_count during page release and the following splat: WARNING: include/net/page_pool/helpers.h:297 at mlx5e_page_release_fragmented.isra.0+0x4a/0x50 [mlx5_core], CPU#12: ip/3137 Modules linked in: [...] CPU: 12 UID: 0 PID: 3137 Comm: ip Not tainted 6.19.0-rc3+ #12 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5e_page_release_fragmented.isra.0+0x4a/0x50 [mlx5_core] [...] Call Trace: <TASK> mlx5e_dealloc_rx_wqe+0xcb/0x1a0 [mlx5_core] mlx5e_free_rx_descs+0x7f/0x110 [mlx5_core] mlx5e_close_rq+0x50/0x60 [mlx5_core] mlx5e_close_queues+0x36/0x2c0 [mlx5_core] mlx5e_close_channel+0x1c/0x50 [mlx5_core] mlx5e_close_channels+0x45/0x80 [mlx5_core] mlx5e_safe_switch_params+0x1a5/0x230 [mlx5_core] mlx5e_change_mtu+0xf3/0x2f0 [mlx5_core] netif_set_mtu_ext+0xf1/0x230 do_setlink.isra.0+0x219/0x1180 rtnl_newlink+0x79f/0xb60 rtnetlink_rcv_msg+0x213/0x3a0 netlink_rcv_skb+0x48/0xf0 netlink_unicast+0x24a/0x350 netlink_sendmsg+0x1ee/0x410 __sock_sendmsg+0x38/0x60 ____sys_sendmsg+0x232/0x280 ___sys_sendmsg+0x78/0xb0 __sys_sendmsg+0x5f/0xb0 [...] do_syscall_64+0x57/0xc50 This patch fixes the issue by doing page frag counting on all the original XDP buffer fragments for all relevant XDP actions (XDP_TX , XDP_REDIRECT and XDP_PASS). This is basically reverting to the original counting before the commit in the fixes tag. As frag_page is still pointing to the original tail, the nr_frags parameter to xdp_update_skb_frags_info() needs to be calculated in a different way to reflect the new nr_frags. Fixes: afd5ba5 ("net/mlx5e: RX, Fix generating skb from non-linear xdp_buff for legacy RQ") Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Amery Hung <ameryhung@gmail.com> Link: https://patch.msgid.link/20260305142634.1813208-6-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
sgaud-quic
pushed a commit
that referenced
this pull request
Jul 25, 2026
Tariq Toukan says: ==================== devlink: add per-port resource support This series by Or adds devlink per-port resource support: Currently, devlink resources are only available at the device level. However, some resources are inherently per-port, such as the maximum number of subfunctions (SFs) that can be created on a specific PF port. This limitation prevents user space from obtaining accurate per-port capacity information. This series adds infrastructure for per-port resources in devlink core and implements it in the mlx5 driver to expose the max_SFs resource on PF devlink ports. Patch #1 refactors resource functions to be generic Patch #2 adds port-level resource registration infrastructure Patch #3 registers SF resource on PF port representor in mlx5 Patch #4 adds devlink port resource registration to netdevsim for testing Patch #5 adds dump support for device-level resources Patch #6 includes port resources in the resource dump dumpit path Patch #7 adds port-specific option to resource dump doit path Patch #8 adds selftest for devlink port resource doit Patch #9 documents port-level resources and full dump Patch #10 adds resource scope filtering to resource dump Patch #11 adds selftest for resource dump and scope filter Patch #12 documents resource scope filtering ==================== Link: https://patch.msgid.link/20260407194107.148063-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
sgaud-quic
pushed a commit
that referenced
this pull request
Jul 25, 2026
Currently, the initialization of loongarch_jump_ops does not contain an
assignment to its .free field. This causes disasm_line__free() to fall
through to ins_ops__delete() for LoongArch jump instructions.
ins_ops__delete() will free ins_operands.source.raw and
ins_operands.source.name, and these fields overlaps with
ins_operands.jump.raw_comment and ins_operands.jump.raw_func_start.
Since in loongarch_jump__parse(), these two fields are populated by
strchr()-ing the same buffer, trying to free them will lead to undefined
behavior.
This invalid free usually leads to crashes:
Process 1712902 (perf) of user 1000 dumped core.
Stack trace of thread 1712902:
#0 0x00007fffef155c58 n/a (libc.so.6 + 0x95c58)
#1 0x00007fffef0f7a94 raise (libc.so.6 + 0x37a94)
#2 0x00007fffef0dd6a8 abort (libc.so.6 + 0x1d6a8)
#3 0x00007fffef145490 n/a (libc.so.6 + 0x85490)
#4 0x00007fffef1646f4 n/a (libc.so.6 + 0xa46f4)
#5 0x00007fffef164718 n/a (libc.so.6 + 0xa4718)
#6 0x00005555583a6764 __zfree (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x106764)
#7 0x000055555854fb70 disasm_line__free (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x2afb70)
#8 0x000055555853d618 annotated_source__purge (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x29d618)
#9 0x000055555852300c __hist_entry__tui_annotate (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x28300c)
#10 0x0000555558526718 do_annotate (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x286718)
#11 0x000055555852ed94 evsel__hists_browse (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x28ed94)
#12 0x000055555831fdd0 cmd_report (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x7fdd0)
#13 0x000055555839b644 handle_internal_command (/home/csmantle/dist/linux-arch/tools/perf/perf + 0xfb644)
#14 0x00005555582fe6ac main (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x5e6ac)
#15 0x00007fffef0ddd90 n/a (libc.so.6 + 0x1dd90)
#16 0x00007fffef0ddf0c __libc_start_main (libc.so.6 + 0x1df0c)
#17 0x00005555582fed10 _start (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x5ed10)
ELF object binary architecture: LoongArch
... and it can be confirmed with Valgrind:
==1721834== Invalid free() / delete / delete[] / realloc()
==1721834== at 0x4EA9014: free (in /usr/lib/valgrind/vgpreload_memcheck-loongarch64-linux.so)
==1721834== by 0x4106287: __zfree (zalloc.c:13)
==1721834== by 0x42ADC8F: disasm_line__free (in /home/csmantle/dist/linux-arch/tools/perf/perf)
==1721834== by 0x429B737: annotated_source__purge (in /home/csmantle/dist/linux-arch/tools/perf/perf)
==1721834== by 0x42811EB: __hist_entry__tui_annotate (in /home/csmantle/dist/linux-arch/tools/perf/perf)
==1721834== by 0x42848D7: do_annotate (in /home/csmantle/dist/linux-arch/tools/perf/perf)
==1721834== by 0x428CF33: evsel__hists_browse (in /home/csmantle/dist/linux-arch/tools/perf/perf)
==1721834== Address 0x7d34303 is 35 bytes inside a block of size 62 alloc'd
==1721834== at 0x4EA59B8: malloc (in /usr/lib/valgrind/vgpreload_memcheck-loongarch64-linux.so)
==1721834== by 0x6B80B6F: strdup (strdup.c:42)
==1721834== by 0x42AD917: disasm_line__new (in /home/csmantle/dist/linux-arch/tools/perf/perf)
==1721834== by 0x42AE5A3: symbol__disassemble_objdump (in /home/csmantle/dist/linux-arch/tools/perf/perf)
==1721834== by 0x42AF0A7: symbol__disassemble (in /home/csmantle/dist/linux-arch/tools/perf/perf)
==1721834== by 0x429B3CF: symbol__annotate (in /home/csmantle/dist/linux-arch/tools/perf/perf)
==1721834== by 0x429C233: symbol__annotate2 (in /home/csmantle/dist/linux-arch/tools/perf/perf)
==1721834== by 0x42804D3: __hist_entry__tui_annotate (in /home/csmantle/dist/linux-arch/tools/perf/perf)
==1721834== by 0x42848D7: do_annotate (in /home/csmantle/dist/linux-arch/tools/perf/perf)
==1721834== by 0x428CF33: evsel__hists_browse (in /home/csmantle/dist/linux-arch/tools/perf/perf)
This patch adds the missing free() specialization in loongarch_jump_ops,
which prevents disasm_line__free() from invoking the default cleanup
function.
Fixes: fb7fd2a ("perf annotate: Move raw_comment and raw_func_start fields out of 'struct ins_operands'")
Cc: stable@vger.kernel.org
Cc: WANG Rui <wangrui@loongson.cn>
Cc: Huacai Chen <chenhuacai@kernel.org>
Cc: WANG Xuerui <kernel@xen0n.name>
Cc: loongarch@lists.linux.dev
Signed-off-by: Rong Bao <rong.bao@csmantle.top>
Tested-by: WANG Rui <wangrui@loongson.cn>
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
sgaud-quic
pushed a commit
that referenced
this pull request
Jul 25, 2026
ice_reset_all_vfs() ignores the return value of ice_vf_rebuild_vsi().
When the VSI rebuild fails (e.g. during NVM firmware update via
nvmupdate64e), ice_vsi_rebuild() tears down the VSI on its error path,
leaving txq_map and rxq_map as NULL. The subsequent unconditional call
to ice_vf_post_vsi_rebuild() leads to a NULL pointer dereference in
ice_ena_vf_q_mappings() when it accesses vsi->txq_map[0].
The single-VF reset path in ice_reset_vf() already handles this
correctly by checking the return value of ice_vf_reconfig_vsi() and
skipping ice_vf_post_vsi_rebuild() on failure.
Apply the same pattern to ice_reset_all_vfs(): check the return value
of ice_vf_rebuild_vsi() and skip ice_vf_post_vsi_rebuild() and
ice_eswitch_attach_vf() on failure. The VF is left safely disabled
(ICE_VF_STATE_INIT not set, VFGEN_RSTAT not set to VFACTIVE) and can
be recovered via a VFLR triggered by a PCI reset of the VF
(sysfs reset or driver rebind).
Note that this patch does not prevent the VF VSI rebuild from failing
during NVM update — the underlying cause is firmware being in a
transitional state while the EMP reset is processed, which can cause
Admin Queue commands (ice_add_vsi, ice_cfg_vsi_lan) to fail. This
patch only prevents the subsequent NULL pointer dereference that
crashes the kernel when the rebuild does fail.
crash> bt
PID: 50795 TASK: ff34c9ee708dc680 CPU: 1 COMMAND: "kworker/u512:5"
#0 [ff72159bcfe5bb50] machine_kexec at ffffffffaa8850ee
#1 [ff72159bcfe5bba8] __crash_kexec at ffffffffaaa15fba
#2 [ff72159bcfe5bc68] crash_kexec at ffffffffaaa16540
#3 [ff72159bcfe5bc70] oops_end at ffffffffaa837eda
#4 [ff72159bcfe5bc90] page_fault_oops at ffffffffaa893997
#5 [ff72159bcfe5bce8] exc_page_fault at ffffffffab528595
#6 [ff72159bcfe5bd10] asm_exc_page_fault at ffffffffab600bb2
[exception RIP: ice_ena_vf_q_mappings+0x79]
RIP: ffffffffc0a85b29 RSP: ff72159bcfe5bdc8 RFLAGS: 00010206
RAX: 00000000000f0000 RBX: ff34c9efc9c00000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000010 RDI: ff34c9efc9c00000
RBP: ff34c9efc27d4828 R8: 0000000000000093 R9: 0000000000000040
R10: ff34c9efc27d4828 R11: 0000000000000040 R12: 0000000000100000
R13: 0000000000000010 R14: R15:
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
#7 [ff72159bcfe5bdf8] ice_sriov_post_vsi_rebuild at ffffffffc0a85e2e [ice]
#8 [ff72159bcfe5be08] ice_reset_all_vfs at ffffffffc0a920b4 [ice]
#9 [ff72159bcfe5be48] ice_service_task at ffffffffc0a31519 [ice]
#10 [ff72159bcfe5be88] process_one_work at ffffffffaa93dca4
#11 [ff72159bcfe5bec8] worker_thread at ffffffffaa93e9de
#12 [ff72159bcfe5bf18] kthread at ffffffffaa946663
#13 [ff72159bcfe5bf50] ret_from_fork at ffffffffaa8086b9
The panic occurs attempting to dereference the NULL pointer in RDX at
ice_sriov.c:294, which loads vsi->txq_map (offset 0x4b8 in ice_vsi).
The faulting VSI is an allocated slab object but not fully initialized
after a failed ice_vsi_rebuild():
crash> struct ice_vsi 0xff34c9efc27d4828
netdev = 0x0,
rx_rings = 0x0,
tx_rings = 0x0,
q_vectors = 0x0,
txq_map = 0x0,
rxq_map = 0x0,
alloc_txq = 0x10,
num_txq = 0x10,
alloc_rxq = 0x10,
num_rxq = 0x10,
The nvmupdate64e process was performing NVM firmware update:
crash> bt 0xff34c9edd1a30000
PID: 49858 TASK: ff34c9edd1a30000 CPU: 1 COMMAND: "nvmupdate64e"
#0 [ff72159bcd617618] __schedule at ffffffffab5333f8
#4 [ff72159bcd617750] ice_sq_send_cmd at ffffffffc0a35347 [ice]
#5 [ff72159bcd6177a8] ice_sq_send_cmd_retry at ffffffffc0a35b47 [ice]
#6 [ff72159bcd617810] ice_aq_send_cmd at ffffffffc0a38018 [ice]
#7 [ff72159bcd617848] ice_aq_read_nvm at ffffffffc0a40254 [ice]
#8 [ff72159bcd6178b8] ice_read_flat_nvm at ffffffffc0a4034c [ice]
#9 [ff72159bcd617918] ice_devlink_nvm_snapshot at ffffffffc0a6ffa5 [ice]
dmesg:
ice 0000:13:00.0: firmware recommends not updating fw.mgmt, as it
may result in a downgrade. continuing anyways
ice 0000:13:00.1: ice_init_nvm failed -5
ice 0000:13:00.1: Rebuild failed, unload and reload driver
Fixes: 12bb018 ("ice: Refactor VF reset")
Signed-off-by: Petr Oros <poros@redhat.com>
Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Link: https://patch.msgid.link/20260427-jk-iwl-net-petr-oros-fixes-v1-5-cdcb48303fd8@intel.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
13 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.