aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2026-07-31md/raid5: complete discard bios while reshape is activeGenjian Zhang1-2/+6
make_discard_request() returns without completing the bio when reshape is in progress. Discard callers block in submit_bio_wait() waiting for a completion that never arrives. The caller hangs in uninterruptible sleep, and this does not resolve when reshape finishes. Complete the bio with BLK_STS_AGAIN so userspace can retry after reshape, consistent with the existing policy of not processing discard during reshape. Tested on a loop-backed RAID5 array during mdadm --grow: without this patch, blkdiscard hangs in bio_await() and remains in uninterruptible sleep after md reports "reshape done"; with this patch it returns -EAGAIN instead. Signed-off-by: Genjian Zhang <zhanggenjian@kylinos.cn> Reviewed-by: Yu Kuai <yukuai@fygo.io> Link: https://patch.msgid.link/20260711161326.962336-1-zhanggenjian@126.com Signed-off-by: Yu Kuai <yukuai@fygo.io>
2026-07-31Merge tag 'drm-misc-fixes-2026-07-30' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixesDave Airlie18-65/+230
drm-misc-fies for v7.2-rc6: - vmwgfx: - Improve various size checks and limit checks. - Fix oops when submitting invalid execbuf ioctl. - Correctly lock in vmfwgx fence signaling path. - More validation of execbuf ioctl. - Fix oops in vmwgfx vkms init failure path. - Overflow handling in shader path. - Improve firmware validation in panthor. - Fix small leak in bridge/display-connector - Improve imagination trace points. - Fix QAIC transaction length check. - Restrict some DP bandwidth calculations to HDMI DFP. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patch.msgid.link/178a513f-2d7f-4e3a-811b-cd0d9dc309eb@linux.intel.com
2026-07-31Merge tag 'amd-drm-fixes-7.2-2026-07-29' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixesDave Airlie63-254/+818
amd-drm-fixes-7.2-2026-07-29: amdgpu: - VCN 5.3 fix - UserQ fixes - GEM close optimization - HDMI AV mute fix - UML build fixes - GFXOFF residency metrics fixes - SMU 15 fixes - debug_vm fix - PSP 15 fixes - NBIO 7.11.5 fix - pptable use after free fix - gpu metrics fetch fix - DC viewport fix - DML2.1 fix - i2c retimer spam fix - UMD profile pstate fix - Power metrics format cleanup - GTT size fix on APUs - DC context logging fix amdkfd: - Various bounds checking fixes - Mutex locking fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20260729182209.4072227-1-alexander.deucher@amd.com
2026-07-31Merge tag 'mediatek-drm-fixes-20260729' of https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-fixesDave Airlie5-16/+21
Mediatek DRM Fixes - 20260729 1. Check CRTC state before freeing 2. mtk_hdmi: Fix DDC adapter double put in v2 3. mtk_hdmi_common: take i2c adapter module reference 4. mtk_dsi: Enable HS clock only at pre-enable 5. ovl_adaptor: balance component registrations Signed-off-by: Dave Airlie <airlied@redhat.com> From: Chun-Kuang Hu <chunkuang.hu@kernel.org> Link: https://patch.msgid.link/20260729131701.4158-1-chunkuang.hu@kernel.org
2026-07-30clk: qcom: Return expected ENOMEM error on dynamic allocation failureVladimir Zapolskiy1-2/+2
If a dynamic memory allocation fails, the returned error code in clock controller driver probe functions on a few legacy platforms should be set to -ENOMEM instead of -EINVAL. Fixes: ee15faffef11 ("clk: qcom: common: Add API to register board clocks backwards compatibly") Signed-off-by: Vladimir Zapolskiy <vz@kernel.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260629162127.3910603-1-vz@kernel.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: apss-ipq-pll: Add IPQ5210 supportVaradarajan Narayanan1-0/+19
The Application Processor Subsystem on the IPQ5210 platform sources its clock from the Huayra PLL. Add the configuration data necessary to set it up. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260703-apss-clk-v3-2-4785e89a9c58@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: Add support for videocc driver on Qualcomm Maili SoCJagadeesh Kona3-0/+671
Add support for Qualcomm Maili video clock controller driver for video clients to be able to request for videocc clocks. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com> Signed-off-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260717-maili_videocc-v3-2-6656694b06a7@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: gpucc-qcm2290: Park RCG's clk source at XO during disableImran Shaik1-1/+1
The RCG's clk src has to be parked at XO while disabling as per hardware team's recommendation, hence use clk_rcg2_shared_ops to achieve the same. Fixes: 8cab033628b1 ("clk: qcom: Add QCM2290 GPU clock controller driver") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260718-shikra-dispcc-gpucc-v6-11-62703e05ef0f@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: gpucc-qcm2290: Keep the critical clocks always-on from probeImran Shaik1-15/+1
Drop modelling of gpu_cc_ahb_clk and keep it always enabled from probe similar to other critical clocks, since marking it as CLK_IS_CRITICAL causes the clock framework to invoke clk_pm_runtime_get() during prepare, which prevents the associated power domains from collapsing. Fixes: 8cab033628b1 ("clk: qcom: Add QCM2290 GPU clock controller driver") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260718-shikra-dispcc-gpucc-v6-10-62703e05ef0f@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: gpucc-qcm2290: Move to the latest common qcom_cc_probe() modelImran Shaik1-30/+20
Update the QCM2290 GPUCC driver to use the qcom_cc_probe() model by moving the critical clocks handling and PLL configurations from probe to the driver_data to align with the latest convention. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260718-shikra-dispcc-gpucc-v6-9-62703e05ef0f@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: gpucc-qcm2290: Drop pm_clk handlingImran Shaik1-11/+0
Drop the pm_clk handling from QCM2290 GPUCC driver as the required GCC AHB clocks are kept always enabled by the GCC driver during probe. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260718-shikra-dispcc-gpucc-v6-8-62703e05ef0f@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: qcm2290: Update DISPCC and GPUCC GDSC *wait_val valuesImran Shaik2-0/+9
Update the QCM2290 DISPCC and GPUCC GDSC wait_val fields to match the hardware default values. Incorrect settings can cause the GDSC FSM to stuck, leading to power on/off failures. Fixes: cc517ea3333f ("clk: qcom: Add display clock controller driver for QCM2290") Fixes: 8cab033628b1 ("clk: qcom: Add QCM2290 GPU clock controller driver") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260718-shikra-dispcc-gpucc-v6-7-62703e05ef0f@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: qcm2290: Add RETAIN_FF_ENABLE flag for DISPCC and GPUCC GDSCsImran Shaik2-3/+3
Add RETAIN_FF_ENABLE flag for DISPCC and GPUCC GDSCs on QCM2290 to retain the register context across GDSC power collapse. Fixes: cc517ea3333f ("clk: qcom: Add display clock controller driver for QCM2290") Fixes: 8cab033628b1 ("clk: qcom: Add QCM2290 GPU clock controller driver") Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260718-shikra-dispcc-gpucc-v6-6-62703e05ef0f@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: qcm2290: Set POLL_CFG_GDSCR flag for DISPCC and GPUCC GDSCsImran Shaik2-2/+2
The Qualcomm QCM2290 SoC GDSCR status bit may not reflect the actual state of the GDSC, instead the power on/off bits in CFG_GDSCR must be polled to determine the GDSC state correctly. Set POLL_CFG_GDSCR flag for the QCM2290 MDSS GDSC and GPUCC GX GDSC to ensure the correct GDSC status. This is not applicable for GPUCC CX GDSC, which relies on gds_hw_ctrl status. Fixes: cc517ea3333f ("clk: qcom: Add display clock controller driver for QCM2290") Fixes: 8cab033628b1 ("clk: qcom: Add QCM2290 GPU clock controller driver") Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260718-shikra-dispcc-gpucc-v6-5-62703e05ef0f@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: dispcc-qcm2290: Enable runtime PM supportImran Shaik1-0/+1
The QCM2290 DISPCC is now associated with a power domain (RPMPD_CX) to propagate genpd performance state votes to the CX rail. Set use_rpm to true so that a runtime PM reference is acquired and released around probe, instead of leaving a permanent 'enable' vote on the power domain. Fixes: cc517ea3333f ("clk: qcom: Add display clock controller driver for QCM2290") Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260718-shikra-dispcc-gpucc-v6-4-62703e05ef0f@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: dispcc-qcm2290: Move to the latest common qcom_cc_probe() modelImran Shaik1-19/+19
Update the QCM2290 DISPCC driver to use the qcom_cc_probe() model by moving the critical clocks handling and PLL configurations from probe to the driver_data to align with the latest convention. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260718-shikra-dispcc-gpucc-v6-3-62703e05ef0f@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: gcc-qcm2290: Keep the critical clocks always-on from probeImran Shaik1-98/+15
Some GCC branch clocks are required to be kept always-on due to the hardware requirements. Drop the modelling of those always-on QCM2290 GCC clocks and use the latest .clk_cbcr convention to keep them enabled from probe. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260718-shikra-dispcc-gpucc-v6-2-62703e05ef0f@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: Add Audio Core clock controller support on Qualcomm Shikra SoCImran Shaik3-0/+821
Add support for Audio Core Clock Controller (AUDIOCORECC) and Audio Core CSR resets on Qualcomm Shikra SoC. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260724-shikra-audiocorecc-v4-2-0a89bb13d817@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: gpucc: Add Nord graphics clock controller supportTaniya Das4-0/+1150
Add support for the GPU clock controllers (GPUCC) on the Qualcomm Nord platform. The platform includes two GPU clock controller instances,GPUCC and GPU2CC. Register support for both controllers, which provide clocks required for the graphics subsystem. Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com> Reviewed-by: Shawn Guo <shengchao.guo@oss.qualcomm.com> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260724-nords_mm_v1-v3-6-32b45232217f@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: Add Nord display clock controller supportTaniya Das4-0/+4020
Add support for the display clock controllers (DISPCC) on the Qualcomm Nord platform. The platform includes two display clock controller instances, display0 and display1. Register support for both controllers. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Shawn Guo <shengchao.guo@oss.qualcomm.com> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com> Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com> Link: https://lore.kernel.org/r/20260724-nords_mm_v1-v3-4-32b45232217f@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: negcc-nord: keep GPU2 CFG clock enabled via critical CBCRTaniya Das1-16/+6
The GPU2 CFG clock must remain enabled for correct operation and should not be exposed as a controllable clk_branch. Remove the clk_branch and mark its CBCR as critical instead to prevent unintended gating. This follows the same approach as 'nw_gcc_gpu_cfg_ahb_clk' and aligns with other always-on clocks in Qualcomm CC drivers. Fixes: a4f780cd5c7a ("clk: qcom: gcc: Add multiple global clock controller driver for Nord SoC") Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260724-nords_mm_v1-v3-2-32b45232217f@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: gcc-nord: mark PCIe link clocks as criticalTaniya Das1-30/+7
The PCIe link AHB and XO clocks must remain enabled for proper operation. Representing them as clk_branch instances allows them to be gated, which is undesirable. Remove their clk_branch definitions and register their CBCRs as critical clocks instead so they remain enabled. This matches the handling of similar always-on clocks in other Qualcomm clock drivers. Fixes: a4f780cd5c7a ("clk: qcom: gcc: Add multiple global clock controller driver for Nord SoC") Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260724-nords_mm_v1-v3-1-32b45232217f@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: clean-up simple provider misuse of the consumer APIJerome Brunet4-6/+6
Clock provider should not be using the consumer interface. In other words, a provider should not be dealing with struct clk. This change targets occurrences for which the provider uses the consumer interface and corresponding clk_hw interface exist. Reviewed-by: Brian Masney <bmasney@redhat.com> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260724-clk-provider-simple-clean-v2-2-56f306156d25@baylibre.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: negcc-nord: use clk_regmap_phy_mux for USB3 pipe clock srcsTaniya Das1-37/+12
ne_gcc_usb3_prim_phy_pipe_clk_src and ne_gcc_usb3_sec_phy_pipe_clk_src are 2-bit muxes selecting between a PHY-sourced USB3 pipe clock and BI_TCXO, implemented with clk_regmap_mux_closest_ops. This requires manual parent switching and does not park the mux on the reference clock when the clock is disabled. Convert both to clk_regmap_phy_mux with clk_regmap_phy_mux_ops, which automatically parks the mux on the XO/ref source on disable and restores the PHY parent on enable, matching the existing UFS symbol clock conversions in this driver. Fixes: a4f780cd5c7a ("clk: qcom: gcc: Add multiple global clock controller driver for Nord SoC") Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com> Tested-by: Shawn Guo <shengchao.guo@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260716-b4-nord-pipe-clk-fixes-v1-2-e4f583633356@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: nord: use BRANCH_HALT_SKIP for PHY pipe clocksTaniya Das2-6/+6
The PCIe and USB3 pipe clocks on Nord are sourced from their respective PHYs. The halt bit for these branches does not toggle reliably when the PHY is powered down or not yet brought up, so polling for it with BRANCH_HALT_VOTED can spuriously time out. Switch these pipe clock branches to BRANCH_HALT_SKIP, matching the convention used for PHY-sourced pipe clocks elsewhere in the Qualcomm clock drivers. Fixes: a4f780cd5c7a ("clk: qcom: gcc: Add multiple global clock controller driver for Nord SoC") Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com> Tested-by: Shawn Guo <shengchao.guo@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260716-b4-nord-pipe-clk-fixes-v1-1-e4f583633356@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: Fix test_ctl_hi field for DEFAULT_EVO PLLsImran Shaik3-9/+9
CLK_ALPHA_PLL_TYPE_DEFAULT_EVO type PLLs do not have the PLL_TEST_CTL_U1 register, so clk_alpha_pll_configure() does not program test_ctl_hi1_val for this PLL type. The GCC PLL configurations for QCM2290, Shikra and SM6115 wrongly use test_ctl_hi1_val instead of test_ctl_hi_val, deviating from the hardware recommended settings. Fix them to use test_ctl_hi_val. Fixes: 496d1a13d405 ("clk: qcom: Add Global Clock Controller driver for QCM2290") Fixes: 01cf3e27824d ("clk: qcom: Add Global clock controller support on Qualcomm Shikra SoC") Fixes: e88c533d8a2a ("clk: qcom: gcc-sm6115: Add missing PLL config properties") Cc: stable@vger.kernel.org Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260729-pll-test-ctrl-fixup-v1-1-246d79589380@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30remoteproc: qcom: pas: Drop unused dtb_mem_region fieldMukesh Ojha1-1/+2
dtb_mem_region is no longer referenced after the ioremap was moved to respective places where mapping is required. Remove it from struct qcom_pas. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260724182858.1868271-6-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30remoteproc: qcom: pas: Map/unmap subsystem region before auth_and_resetMukesh Ojha2-17/+33
Qualcomm remoteproc drivers such as qcom_q6v5_mss, which do not use the Peripheral Authentication Service (PAS), always map the MBA region before use and unmap it once the usage is complete. This behavior was introduced to avoid issues seen in the past where speculative accesses from the application processor to the MBA region after it was assigned to the remote Q6 led to an XPU violation. The issue was mitigated by unmapping the region before handing control to the remote Q6. Currently, most Qualcomm SoCs using the PAS driver run either with a standalone QHEE or the Gunyah hypervisor. In these environments, the hypervisor unmaps the Q6 memory from HLOS Stage-2 and remaps it into the Q6 Stage-2 page table. As a result, speculative accesses from HLOS cannot reach the region even if it remains mapped in HLOS Stage-1; therefore, XPU violations cannot occur. However, when the same SoC runs Linux at EL2, Linux itself must perform the unmapping to avoid such issues. It is still correct to apply this mapping/ unmapping sequence even for SoCs that run under Gunyah, so this behavior should not be conditional. Introduce qcom_pas_ctx_map() in qcom_pas.h to centralise the ioremap_wc pattern used by both qcom_q6v5_pas and qcom_mdt_pas_load, and use it in both places. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260724182858.1868271-5-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30remoteproc: qcom: pas: Fix the PAS context creation placementMukesh Ojha1-16/+13
DTB PAS context creation should be done only for subsystems that support a DTB firmware binary; otherwise, memory is wasted. Move the context creation to the appropriate location. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260724182858.1868271-4-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30remoteproc: qcom: pas: Guard dtb metadata release with dtb_pas_id checkMukesh Ojha1-8/+5
All other call sites of qcom_scm_pas_metadata_release() for the DTB context are guarded by a check on pas->dtb_pas_id, but the call inside qcom_pas_load() was not. Fix this by moving the call to the guarded block. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Fixes: 29814986b82e ("remoteproc: qcom_q6v5_pas: add support for dtb co-firmware loading") Cc: stable@vger.kernel.org Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260724182858.1868271-3-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30remoteproc: qcom: annotate mem_region fields with __iomemMukesh Ojha3-11/+11
The firmware memory regions in qcom_adsp, qcom_pas and qcom_wcnss are mapped using devm_ioremap_wc() / devm_ioremap_resource_wc(), which return void __iomem *. However, the mem_region (and dtb_mem_region) fields in the respective driver structs were declared as plain void *, causing sparse to flag address space mismatches: qcom_q6v5_adsp.c:639:26: warning: incorrect type in assignment (different address spaces) qcom_q6v5_adsp.c:639:26: expected void *mem_region qcom_q6v5_adsp.c:639:26: got void [noderef] __iomem * qcom_q6v5_pas.c:141:45: warning: incorrect type in argument 2 (different address spaces) qcom_q6v5_pas.c:141:45: expected void const volatile [noderef] __iomem *src qcom_q6v5_pas.c:141:45: got void * qcom_q6v5_pas.c:637:25: warning: incorrect type in assignment (different address spaces) qcom_q6v5_pas.c:637:25: expected void *mem_region qcom_q6v5_pas.c:637:25: got void [noderef] __iomem * qcom_q6v5_pas.c:654:29: warning: incorrect type in assignment (different address spaces) qcom_q6v5_pas.c:654:29: expected void *dtb_mem_region qcom_q6v5_pas.c:654:29: got void [noderef] __iomem * qcom_wcnss.c:540:27: warning: incorrect type in assignment (different address spaces) qcom_wcnss.c:540:27: expected void *mem_region qcom_wcnss.c:540:27: got void [noderef] __iomem * Fix this by annotating the struct fields with __iomem to correctly reflect the address space of the underlying mapping. These regions are subsequently passed to qcom_mdt_load(), qcom_mdt_load_no_init() and qcom_mdt_pas_load(), all of which take void * and use plain memcpy()/memset() internally to write firmware segments into the region. This is intentional and safe: the mappings are write-combining (WC), which on arm64 permits bulk CPU stores without requiring the memcpy_toio()/memset_io() accessors. Changing the MDT loader API to accept void __iomem * would be a more invasive change and would affect callers. Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260724182858.1868271-2-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30net/funeth: switch to higher-level allocator APIBrendan Jackman1-1/+1
The difference between __alloc_pages_node() and alloc_pages_node() is that the latter allows you to pass NUMA_NO_NODE. The former is going away and the latter works fine here so switch over. No functional change intended. Link: https://lore.kernel.org/20260703-alloc-trylock-v5-12-c87b714e19d3@google.com Signed-off-by: Brendan Jackman <jackmanb@google.com> Reviewed-by: Suren Baghdasaryan <surenb@google.com> Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> Reviewed-by: Zi Yan <ziy@nvidia.com> Cc: Dimitris Michailidis <dmichail@fungible.com> Cc: Andrew Lunn <andrew+netdev@lunn.ch> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Assisted-by: Gemini:unknown-version Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30sgi-xp: use higher-level allocator APIBrendan Jackman1-3/+2
The difference between __alloc_pages_node() and alloc_pages_node() is that the latter allows you to pass NUMA_NO_NODE. The former is going away and the latter works fine here so switch over. No functional change intended. Link: https://lore.kernel.org/20260703-alloc-trylock-v5-11-c87b714e19d3@google.com Signed-off-by: Brendan Jackman <jackmanb@google.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Suren Baghdasaryan <surenb@google.com> Acked-by: Steve Wahl <steve.wahl@hpe.com> Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> Reviewed-by: Zi Yan <ziy@nvidia.com> Cc: Robin Holt <robinmholt@gmail.com> Cc: Steve Wahl <steve.wahl@hpe.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Assisted-by: Gemini:unknown-model Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-31platform/chrome: lightbar: Limit payload to max packet sizeAlexis Savery1-1/+6
The LIGHTBAR_CMD_SET_PROGRAM command uses an 8-bit size field for its payload length, but the protocol-negotiated `max_request` may exceed the maximum value an 8-bit integer can represent. When this occurs, large payloads (e.g., >255 bytes) integer wrap the 8-bit size variable when assigning `param->set_program_ex.size`, causing truncation and parse failures downstream in the EC firmware stack. Clamp `max_size` to the maximum value the structural size field can support. Fixes: 9600b8bdbfe4 ("platform/chrome: lightbar: Add support for large sequence") Signed-off-by: Alexis Savery <asavery@google.com> Link: https://lore.kernel.org/r/20260730204240.2227178-1-asavery@google.com Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
2026-07-30net: mctp: usb: Allow multiple urbs in flightJeremy Kerr1-4/+29
Currently, we stop tx queues when we have one urb submitted. This means we will immediately hit dev_hard_start_xmit's tx-queues-off -> NETDEV_TX_BUSY case, and revert to the requeue -> gso_skb single-dequeue path, and no longer be able to pack skbs without an xmit_more indication. Instead, allow a few urbs to be in-flight, with a limit of 16kB of data outstanding (after which we will disable queues). With this, the tx path will cause fewer requeues (and therefore non-packed transfers) under normal loads. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Link: https://patch.msgid.link/20260724-dev-mctp-usb-1-1-v5-12-e66bbba0dbdc@codeconstruct.com.au Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30net: mctp: usb: enable v1.1 packet spanningJeremy Kerr1-5/+21
Now that mctp-usblib supports DSP0283 v1.1 packet spanning, enable it in our host-side transport driver. Add a match for the new device subclass (0x02), and indicating spanning mode to the usblib rx/tx implementation. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Link: https://patch.msgid.link/20260724-dev-mctp-usb-1-1-v5-11-e66bbba0dbdc@codeconstruct.com.au Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30net: mctp: usblib: Add initial kunit testsJeremy Kerr3-0/+421
Add some initial tests for the usblib receive path, where we're extracting MCTP packets from incoming USB transfer data. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Link: https://patch.msgid.link/20260724-dev-mctp-usb-1-1-v5-10-e66bbba0dbdc@codeconstruct.com.au Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30net: mctp: usblib: Implement transmit-side packet spanningJeremy Kerr2-10/+20
Add support for packet spanning as defined in DSP0283 v1.1. With the existing v1.0 implementation of multi-packet transfers, all we need here is to adjust the buffer sizes to suit v1.1. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Link: https://patch.msgid.link/20260724-dev-mctp-usb-1-1-v5-9-e66bbba0dbdc@codeconstruct.com.au Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30net: mctp: usblib: Implement receive-side packet spanningJeremy Kerr2-50/+121
Using the existing prepare/complete API, we can persist the rx skb across receives to implement v1.1 packet spanning. Alter the packet-extraction loop to allow truncated packets, returning early with the skb persisted for the next IN urb completion. When we see we have a complete packet, netif_rx() that. If the packet boundary aligns with the urb completion, we can netif_rx() the whole thing. Those intermediate packets are cloned from the original (large-transfer-data) skb. Unlike existing behaviour, if the clone fails, we drop just that clone, instead of the existing transfer skb. This allows us to process the rest of the skb data, and any continuation of the span into the next transfer. One subtle change: the mctp_usblib_rx() helper now handles skbs with the full transport header, so we shift the skb_pull() for the header data to the helper, before doing the rx_bytes stats update. We still need to handle non-spanning mode, so error out on truncated-packet cases there. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Link: https://patch.msgid.link/20260724-dev-mctp-usb-1-1-v5-8-e66bbba0dbdc@codeconstruct.com.au Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30net: mctp: usb: Accommodate DSP0283 v1.1 header formatJeremy Kerr1-6/+8
In the v1.1 update to DSP0283, we have a larger header field, of 13 bits rather than 8. In order to accommodate this, in preparation for proper v1.1 support, expand our struct mctp_usb_hdr's len field to a u16, and endian-convert when necessary. Because we don't yet support spanning mode, we will never receive or transmit with the top 5 bits set, so we always mask out anyway. This allows for a future change where we allow spanning mode with >512-byte transfers. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Link: https://patch.msgid.link/20260724-dev-mctp-usb-1-1-v5-7-e66bbba0dbdc@codeconstruct.com.au Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30net: mctp: usblib: Add support for multi-packet transmitJeremy Kerr1-46/+206
The MCTP over USB spec allows us to pack multiple packets in one transfer. Given the packet max length is 255, and the transfer max length is 512, we can typically include two full-size packets per urb submission. To do this, we allow a struct mctp_usb_tx to persist a tx_ctx, representing the ongoing context for a transmit. If possible, a TX skb will be queued to the context and the send deferred until the context is full, or the device queue reports no more packets. This typically requires a linear buffer for the 512-byte TX, which we allocate along with the TX context. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Link: https://patch.msgid.link/20260724-dev-mctp-usb-1-1-v5-6-e66bbba0dbdc@codeconstruct.com.au Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30net: mctp: usblib: Move TX transfer processing to mctp-usblibJeremy Kerr2-64/+253
With the RX processing in mctp-usblib, add TX processing alongside. To accommodate packed transfers in DSP0283, where a transfer may contain multiple MCTP packets, we move to a split process for the transmit API: * push: create a new transmit context, and add a skb to it. * send: callback to the driver implementation to send the (possibly multi-packet) USB transfer * complete: update skb accounting and release the tx context The actual multi-packet transfer implementation will be added in the next change; no tx context persists beyond the single send at present. However, we use an anchor in the host driver implementation to track the submitted TX urb when necessary. While we're here, fix an inconsistency between tx and rx stats: both should not include the transport header. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Link: https://patch.msgid.link/20260724-dev-mctp-usb-1-1-v5-5-e66bbba0dbdc@codeconstruct.com.au Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30net: mctp: usb: Improve IN endpoint status handlingJeremy Kerr1-7/+84
Currently, we give-up on all non-zero status values on our IN/rx urb, and do not re-queue the urb. This will stall the driver, and prevent any further receive. Instead, attempt a re-queue on transient errors, with a max of ten successive failures. Handle EPIPE specially, by scheduling a usb_clear_halt() in non-atomic context. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Link: https://patch.msgid.link/20260724-dev-mctp-usb-1-1-v5-4-e66bbba0dbdc@codeconstruct.com.au Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30net: mctp: usblib: Move RX transfer processing to a new mctp-usblibJeremy Kerr4-81/+214
The processing of USB receive transfers is common to both sides of a MCTP over USB transport. In order to support a future gadget driver, move the current host-side driver into a new common file, mctp-usblib. This currently handles the submit-complete-packetise process of the receive path of the USB transport. We'll add transmit handling in an upcoming change. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Link: https://patch.msgid.link/20260724-dev-mctp-usb-1-1-v5-3-e66bbba0dbdc@codeconstruct.com.au Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30net: mctp: usb: Use packet-length max for maximum packet-size checkJeremy Kerr1-1/+1
The max packet size is smaller than the max transfer size, as we only have a u8 length field in the transport header. Add a define for the maximum representable length, and use that for our check. Use this for the MTU maximum calculation too. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Link: https://patch.msgid.link/20260724-dev-mctp-usb-1-1-v5-2-e66bbba0dbdc@codeconstruct.com.au Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30net: mctp: usb: Include version indicator in max packet size definesJeremy Kerr1-4/+4
DSP0283 v1.1.0 will introduce larger maximum packet sizes. In preparation, indicate that the current maxima are specific to v1.0.x. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Link: https://patch.msgid.link/20260724-dev-mctp-usb-1-1-v5-1-e66bbba0dbdc@codeconstruct.com.au Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30Merge tag 'for-v7.2-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supplyLinus Torvalds3-9/+51
Pull power supply fixes from Sebastian Reichel: - Documentation build fix for bd71828 - max17040: handle missing status supplier - macsmc: Support macOS 27 SMC firmware - bq25890: fix the -10 C NTC lookup entry * tag 'for-v7.2-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply: power: supply: bq25890: fix the -10 C NTC lookup entry power: supply: macsmc: Support macOS 27 SMC firmware power: supply: max17040: handle missing status supplier power: supply: bd71828: add a terminating table border
2026-07-30pds_core: cancel pending PCI reset work on AER recoveryNikhil P. Rao1-0/+4
pdsc_check_pci_health() queues pci_reset_work when it sees a broken PCI connection, and nothing cancels it. When the PCI core starts AER recovery, pdsc_pci_error_detected() runs pdsc_reset_prepare() and recovers the device, but a pci_reset_work queued just before is left pending. If it runs after recovery released the device lock, it resets a device the driver now considers healthy, bouncing the link for no reason. Cancel pci_reset_work in pdsc_pci_error_detected() after pdsc_reset_prepare(), which has already stopped the health thread so it cannot requeue the work. cancel_work_sync() is safe under the device lock here because pdsc_pci_reset_thread() uses pci_try_reset_function(), which returns instead of blocking on the lock. Only PFs initialize pci_reset_work, so guard the cancel with !is_virtfn. Fixes: 81665adf25d2 ("pds_core: Fix pdsc_check_pci_health function to use work thread") Reported-by: sashiko-bot <sashiko-bot@kernel.org> Closes: https://sashiko.dev/#/patchset/20260714180223.1642792-2-nikhil.rao%40amd.com?part=1 Signed-off-by: Nikhil P. Rao <nikhil.rao@amd.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260727170030.361116-1-nikhil.rao@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30pds_core: keep the health thread stopped during resetNikhil P. Rao2-2/+9
Commit d9407ff11809 ("pds_core: Prevent health thread from running during reset/remove") stops the health thread with cancel_work_sync() before a reset, but a devcmd timeout during pdsc_fw_down() re-queues health_work, so pdsc_health_thread() runs again mid-reset and double allocates the core DMA queues via pdsc_fw_up(). Only the reset path is affected: on remove PDSC_S_STOPPING_DRIVER gates the health thread and the workqueue is destroyed. Use disable_work_sync() to cancel health_work and block further queue_work() on it, and enable_work() in pdsc_restart_health_thread() to re-allow it after the reset. disable_work_sync() keeps a disable depth, so every disable must be matched by one enable. pdsc_reset_prepare() stops the health thread and pdsc_reset_done() restarts it. On the AER path pdsc_pci_error_detected() calls pdsc_reset_prepare(), then pdsc_pci_error_resume() re-inits via pci_reset_function_locked() (pds_core has no .slot_reset handler), which runs the pair again - stopping the thread twice but restarting it once. Gate the disable and enable on a health_stopped flag so each fires at most once per stopped/running transition. Fixes: d9407ff11809 ("pds_core: Prevent health thread from running during reset/remove") Reported-by: sashiko-bot <sashiko-bot@kernel.org> Closes: https://sashiko.dev/#/patchset/20260629200358.2626129-1-nikhil.rao%40amd.com?part=2 Signed-off-by: Nikhil P. Rao <nikhil.rao@amd.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260727164548.359562-1-nikhil.rao@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30net/mlx5e: TC, Check if flow is PEER before acquiring devcom lockShay Drory2-1/+4
In case __mlx5e_add_fdb_flow() fails in lower levels, the flow is deleted via mlx5e_tc_del_flow(), and mlx5e_tc_del_flow() is acquiring ESW devcom lock without condition. In addition, in case of peer_flow, __mlx5e_add_fdb_flow() is called while holding ESW devcom comp lock. This results in an AA deadlock. To fix this, introduce a new PEER flag that is set on flows created as peer flows (the duplicate flows on peer devices), and check it in mlx5e_tc_del_flow() before acquiring ESW devcom lock. Lockdep splat: ============================================ WARNING: possible recursive locking detected ============================================ Possible unsafe locking scenario: CPU0 ---- lock(&comp->lock_key#2); lock(&comp->lock_key#2); *** DEADLOCK *** Call Trace: <TASK> dump_stack_lvl+0x69/0xa0 print_deadlock_bug.cold+0xbd/0xca __lock_acquire+0x1671/0x2ec0 lock_acquire+0x10e/0x2e0 down_read+0x95/0x430 mlx5_devcom_for_each_peer_begin+0x4e/0xe0 [mlx5_core] mlx5e_tc_del_flow+0x11d/0xa70 [mlx5_core] mlx5e_flow_put+0x99/0x100 [mlx5_core] __mlx5e_add_fdb_flow+0x409/0xf00 [mlx5_core] mlx5e_configure_flower+0x2a86/0x4100 [mlx5_core] mlx5e_rep_setup_tc_cls_flower+0x12f/0x1b0 [mlx5_core] mlx5e_rep_setup_tc_cb+0x153/0x750 [mlx5_core] tc_setup_cb_add+0x1dc/0x470 fl_change+0x2f4d/0x626d [cls_flower] tc_new_tfilter+0x79b/0x2310 rtnetlink_rcv_msg+0x778/0xad0 do_syscall_64+0x70/0x960 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> Fixes: 04de7dda7394 ("net/mlx5e: Infrastructure for duplicated offloading of TC flows") Signed-off-by: Shay Drory <shayd@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260728044338.2271143-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.