Prepare qcom-next based on tag 'Linux 7.2-rc7' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git - #943
Closed
Salendarsingh Gaud (sgaud-quic) wants to merge 1509 commits into
Conversation
On WCN6750 platforms, reboot stress testing occasionally results in WLAN initialization failures after boot. The WPSS firmware reaches the running state successfully, but no WLAN interface is created. Analysis shows that ath11k_ahb depends on the QRTR SMD transport for QMI communication with WPSS firmware. However, this dependency is not currently expressed in Kconfig, allowing qrtr_smd and ath11k_ahb to load in either order when built as modules. If ath11k_ahb is loaded before qrtr_smd becomes available, WLAN initialization may not complete successfully. Make the QRTR and QRTR_SMD dependencies explicit and add a soft dependency to ensure qrtr_smd is loaded before ath11k_ahb. Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00204-QCAMSLSWPLZ-1 Fixes: 00402f4 ("ath11k: Add support for WCN6750 device") Link: https://lore.kernel.org/linux-wireless/20260730010505.143458-2-miaoqing.pan@oss.qualcomm.com/ Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
…nit incomplete On WCN6750, if QMI messages never arrive (for example when qrtr_smd is not ready), WLAN initialization stops before the device is fully registered. In this case ATH11K_FLAG_QMI_FAIL is not set because no QMI event handler is executed. When the driver is removed, ath11k_ahb_remove() still calls ath11k_core_deinit(), which eventually triggers ath11k_ce_cleanup_pipes() on uninitialized CE pipes and results in a NULL pointer dereference in ath11k_hal_srng_access_begin(): ath11k_hal_srng_access_begin+0x14/0x68 [ath11k] ath11k_ce_cleanup_pipes+0x184/0x190 [ath11k] ath11k_pcic_stop+0x24/0x38 [ath11k] ath11k_core_deinit+0xfc/0x1c0 [ath11k] ath11k_ahb_remove+0x38/0xa0 [ath11k_ahb] Fix this by invoking ath11k_ahb_remove_prepare() before the state check and skipping ath11k_core_deinit() when either QMI initialization failed or the device was never registered. If ATH11K_FLAG_REGISTERED is not set, core initialization did not complete and CE pipes may remain uninitialized, making ath11k_core_deinit() unsafe. Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00204-QCAMSLSWPLZ-1 Fixes: 00402f4 ("ath11k: Add support for WCN6750 device") Link: https://lore.kernel.org/linux-wireless/20260730010505.143458-3-miaoqing.pan@oss.qualcomm.com/ Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
ath11k_core_init() registers a PM notifier before the QMI server becomes available. If the QMI server never arrives, the device remove() path can take the early-exit path introduced for QMI initialization failures, skipping ath11k_core_deinit(). As a result, the PM notifier remains registered after the ath11k base object has been freed. A subsequent suspend or resume event may invoke the stale notifier and trigger a use-after-free. Fix this by explicitly unregistering the PM notifier in the QMI failure cleanup path before releasing ath11k resources. Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00204-QCAMSLSWPLZ-1 Fixes: 32d93b5 ("wifi: ath11k: choose default PM policy for hibernation") Link: https://lore.kernel.org/linux-wireless/20260730010505.143458-4-miaoqing.pan@oss.qualcomm.com/ Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
When UTF monitor is enabled, ath10k forwards WMI events to nl80211 testmode. Non-UTF events can therefore be delivered to userspace and confuse FTM tools which expect only UTF responses. Only forward known UTF event IDs from WMI event namespaces that route events through ath10k_tm_event_wmi(), and drop other WMI events while UTF monitor is active. READY events are still handled by the normal WMI receive path. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.3.7.c5-00093.2-QCAHLSWMTPL-1 Signed-off-by: Linghui Wu <linghui.wu@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260730023226.707008-1-linghui.wu@oss.qualcomm.com
Add support for building an EL2 combined DTB for the talos-evk in the Qualcomm DTS Makefile. The new talos-evk-el2.dtb is generated by combining the base talos-evk.dtb with the talos-el2.dtbo overlay, enabling EL2-specific configurations required by the platform. Signed-off-by: Xin Liu <xin.liu@oss.qualcomm.com>
Set CONFIG_SWIOTLB_DEFAULT_SIZE_MB=2 to reduce the default SWIOTLB pool size from 64 MiB to 2 MiB. This lowers kernel reserved memory and increases available RAM for user space. Signed-off-by: Jagadeesh Pagadala <jpagadal@qti.qualcomm.com>
…e CSIPHY Add more detailed resource information for CSIPHY devices in the camss driver along with the support for v2.4.0 in the 2 phase CSIPHY driver that is responsible for the PHY lane register configuration, module reset and interrupt handling. Link: https://lore.kernel.org/all/20260508-kaanapali-camss-v13-3-2541d8e55651@oss.qualcomm.com/ Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
Add more detailed resource information for CSID devices along with the driver for CSID gen4 that is responsible for CSID register configuration, module reset and IRQ handling for BUF_DONE events. And aggregate a common definition 'CSI2_RX_CFG0_PHY_SEL_BASE_IDX' into csid header file. In this CSID version, RUP and AUP update values are split into two registers along with a SET register. Accordingly, enhance the CSID interface to accommodate both the legacy combined reg_update and the split RUP and AUP updates. Link: https://lore.kernel.org/all/20260508-kaanapali-camss-v13-4-2541d8e55651@oss.qualcomm.com/ Co-developed-by: Atiya Kailany <atiya.kailany@oss.qualcomm.com> Signed-off-by: Atiya Kailany <atiya.kailany@oss.qualcomm.com> Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
Add Video Front End (VFE) version gen4 as found on the Kaanapali SoC. The FULL front end modules in Kaanapali camera subsystem are called TFEs (Thin Front End), however, retaining the name VFE at places to maintain consistency and avoid unnecessary code changes. This change limits the VFE output lines to 3 for now as constrained by the CAMSS driver framework. Kaanapali architecture requires for the REG_UPDATE and AUP_UPDATE to be issued after all of the CSID configuration has been done. Additionally, the number of AUP_UPDATEs should match the number of buffers enqueued to the write master while it's being enabled. Although the real time data from TFE goes through the RT_CAMNOC, we are required to enable both the camnoc_rt_axi and camnoc_nrt_axi clocks for the PDX_NOC, that follows both the RT and NRT NOCs in this architecture, to ensure that both of the latter are idle after reset. Link: https://lore.kernel.org/all/20260508-kaanapali-camss-v13-5-2541d8e55651@oss.qualcomm.com/ Co-developed-by: Atiya Kailany <atiya.kailany@oss.qualcomm.com> Signed-off-by: Atiya Kailany <atiya.kailany@oss.qualcomm.com> Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
Add bindings for the Camera Subsystem for X1P42100. The X1P42100 platform provides: - 2 x CSIPHY - 3 x TPG - 3 x CSID - 2 x CSID Lite - 1 x IFE - 2 x IFE Lite Link: https://lore.kernel.org/all/20260410-purwa_camss-v1-1-eedcf6d9d8ee@oss.qualcomm.com/ Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
The Purwa camera subsystem is a cut-down variant of the Hamoa CAMSS. Compared to Hamoa, Purwa provides only two CSIPHY instances and does not include the VFE1. Link: https://lore.kernel.org/all/20260410-purwa_camss-v1-2-eedcf6d9d8ee@oss.qualcomm.com/ Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
Add bindings for Camera Subsystem (CAMSS) on the Qualcomm SM8750 platform. The SM8750 platform provides: - 6 x CSIPHY (CSI Physical Layer) - 3 x TPG (Test Pattern Generator) - 3 x CSID (CSI Decoder) - 2 x CSID Lite - 3 x VFE (Video Front End), 5 RDI per VFE - 2 x VFE Lite, 4 RDI per VFE Lite Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260508-add-support-for-camss-on-sm8750-v3-1-fc6861a65c67@oss.qualcomm.com/
Add SM8750 platform support to the CAMSS driver with ICC bandwidth resources and device tree match entry. Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260508-add-support-for-camss-on-sm8750-v3-2-fc6861a65c67@oss.qualcomm.com/
…e CSIPHY Add more detailed resource information for CSIPHY devices in the camss driver along with the support for v2.3.0 in the 2 phase CSIPHY driver that is responsible for the PHY lane register configuration, module reset and interrupt handling. Additionally, generalize the struct name for the lane configuration that had been added for Kaanapali and use it for SM8750 as well as they share the settings. Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260508-add-support-for-camss-on-sm8750-v3-3-fc6861a65c67@oss.qualcomm.com/
Add more detailed resource information for CSID devices along with the driver for CSID 980 that is responsible for CSID register configuration, module reset and IRQ handling for BUF_DONE events. In SM8750, RUP and AUP updates for the CSID Full modules are split into two registers along with a SET register. However, CSID Lite modules still use a single register to update RUP and AUP without the additional SET register. Handled such differences in the driver. Co-developed-by: Atiya Kailany <atiya.kailany@oss.qualcomm.com> Signed-off-by: Atiya Kailany <atiya.kailany@oss.qualcomm.com> Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260508-add-support-for-camss-on-sm8750-v3-4-fc6861a65c67@oss.qualcomm.com/
Add support for Video Front End (VFE) that is on the SM8750 SoCs. VFE gen4 has support for VFE 980. This change limits SM8750 VFE output lines to 3 for now as constrained by the CAMSS driver framework. Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Co-developed-by: Atiya Kailany <atiya.kailany@oss.qualcomm.com> Signed-off-by: Atiya Kailany <atiya.kailany@oss.qualcomm.com> Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260508-add-support-for-camss-on-sm8750-v3-5-fc6861a65c67@oss.qualcomm.com/
Add device tree bindings for the Camera Subsystem (CAMSS) on the Qualcomm Glymur platform. The Glymur platform provides: - 3 x CSIPHY (CSI Physical Layer) - 3 x CSID (CSI Decoder), 2 x CSID Lite - 3 x TPG (Test Pattern Generator) - 2 x VFE (Video Front End), 2 x VFE Lite Signed-off-by: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260529-glymur_camss-v1-1-bee535396d22@oss.qualcomm.com/
Add CAMSS_GLYMUR enum, Glymur compatible and Glymur camss driver private data, the private data just include some basic information for now, later changes will enumerate with csiphy, tpg, csid and vfe resources. Signed-off-by: Prashant Shrotriya <pshrotri@qti.qualcomm.com> Link: https://lore.kernel.org/all/20260529-glymur_camss-v1-3-bee535396d22@oss.qualcomm.com/
Glymur uses the same CSIPHY hardware version as x1e80100. The only difference between the two platforms is the number of CSIPHY instances. x1e80100 has four, while Glymur has three. Signed-off-by: Prashant Shrotriya <pshrotri@qti.qualcomm.com> Link: https://lore.kernel.org/all/20260529-glymur_camss-v1-4-bee535396d22@oss.qualcomm.com/
Extend vfe_src_pad_code() and vfe_bpl_align() for Glymur. Signed-off-by: Prashant Shrotriya <pshrotri@qti.qualcomm.com> Link: https://lore.kernel.org/all/20260529-glymur_camss-v1-5-bee535396d22@oss.qualcomm.com/
Enumerate csiphy, csid and vfe resources for Glymur. Signed-off-by: Prashant Shrotriya <pshrotri@qti.qualcomm.com> Link: https://lore.kernel.org/all/20260529-glymur_camss-v1-6-bee535396d22@oss.qualcomm.com/
Add CAMSS driver support for Shikra SoC. Add high level resource definitions for 2 CSIPHY, 2 CSID and 2 VFE instances along with the interconnect bandwidth votes for AHB, HF and SF MNOC paths. Signed-off-by: Prashant Shrotriya <pshrotri@qti.qualcomm.com> Signed-off-by: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260526-shikra-camss-review-v1-3-645d2c8c75a7@qti.qualcomm.com/
…me PM helpers cci_resume() unconditionally calls cci_resume_runtime() regardless of the runtime PM state. If the device is already runtime-suspended before system suspend, the clock is re-enabled while runtime_status remains RPM_SUSPENDED. As a result, pm_request_autosuspend() does not arm the timer, leaving the clock permanently enabled. Fixes: e517526 ("i2c: Add Qualcomm CCI I2C driver") Cc: stable@vger.kernel.org Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260625-cci-v1-1-a100cda673ce@oss.qualcomm.com/
The lane mask must be multiplied by 2, but this was accidentally omitted. Link: https://lore.kernel.org/r/20260617-qcom-cphy-v9-1-83da8a8e4e44@ixit.cz Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Suggested-by: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com> Signed-off-by: David Heidelberg <david@ixit.cz> Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
Read PHY configuration from the device-tree bus-type and save it into the csiphy structure for later use. For C-PHY, skip clock line configuration, as there is none. Link: https://lore.kernel.org/r/20260617-qcom-cphy-v9-2-83da8a8e4e44@ixit.cz Acked-by: Cory Keitz <ckeitz@amazon.com> Reviewed-by: Bryan O'Donoghue <bod@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: David Heidelberg <david@ixit.cz> Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
…g C-PHY lanes So far, only D-PHY mode was supported, which uses even bits when enabling or masking lanes. For C-PHY configuration, the hardware instead requires using the odd bits. Since there can be unrecognized configuration allow returning failure. Link: https://lore.kernel.org/r/20260617-qcom-cphy-v9-3-83da8a8e4e44@ixit.cz Acked-by: Cory Keitz <ckeitz@amazon.com> Reviewed-by: Bryan O'Donoghue <bod@kernel.org> Signed-off-by: David Heidelberg <david@ixit.cz> Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
Inherit C-PHY information from CSIPHY, so we can configure CSID properly. CSI2_RX_CFG0_PHY_TYPE_SEL must be set to 1, when C-PHY mode is used. Link: https://lore.kernel.org/r/20260617-qcom-cphy-v9-4-83da8a8e4e44@ixit.cz Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Acked-by: Cory Keitz <ckeitz@amazon.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: David Heidelberg <david@ixit.cz> Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
…on is available The lanes must not be initialized before the driver has access to the lane configuration, as it depends on whether D-PHY or C-PHY mode is in use. Move the lane initialization to csiphy_lanes_enable which is called when the configuration structures are available. Link: https://lore.kernel.org/r/20260617-qcom-cphy-v9-5-83da8a8e4e44@ixit.cz Co-developed-by: Petr Hodina <phodina@protonmail.com> Signed-off-by: Petr Hodina <phodina@protonmail.com> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Acked-by: Cory Keitz <ckeitz@amazon.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: David Heidelberg <david@ixit.cz> Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
…PHY init Add a PHY configuration sequence for the sdm845 which uses a Qualcomm Gen 2 version 1.1 CSI-2 PHY. The PHY can be configured as two phase or three phase in C-PHY or D-PHY mode. This configuration supports three-phase C-PHY mode. Link: https://lore.kernel.org/r/20260617-qcom-cphy-v9-6-83da8a8e4e44@ixit.cz Acked-by: Cory Keitz <ckeitz@amazon.com> Signed-off-by: David Heidelberg <david@ixit.cz> Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
… C-PHY init These values should improve C-PHY behaviour. Should match most recent Qualcomm code. Link: https://lore.kernel.org/r/20260617-qcom-cphy-v9-7-83da8a8e4e44@ixit.cz Acked-by: Cory Keitz <ckeitz@amazon.com> Suggested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: David Heidelberg <david@ixit.cz> Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
# Conflicts: # arch/arm64/boot/dts/qcom/Makefile
# Conflicts: # Makefile # drivers/video/fbdev/core/fbsysfs.c
# Conflicts: # arch/arm64/boot/dts/qcom/monaco-evk.dts # arch/arm64/boot/dts/qcom/monaco.dtsi
# Conflicts: # Makefile
# Conflicts: # arch/arm64/boot/dts/qcom/Makefile # arch/arm64/boot/dts/qcom/talos.dtsi
# Conflicts: # arch/arm64/boot/dts/qcom/qcs8300-ride.dts # drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
# Conflicts: # drivers/firmware/qcom/Kconfig # drivers/firmware/qcom/Makefile
# Conflicts: # Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml # Documentation/devicetree/bindings/display/msm/qcom,qcm2290-dpu.yaml # Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml # drivers/dma/qcom/bam_dma.c # drivers/misc/fastrpc.c # drivers/soc/qcom/ubwc_config.c # sound/soc/qcom/qdsp6/q6prm.h # sound/soc/qcom/sc8280xp.c
# Conflicts: # Documentation/devicetree/bindings/sound/qcom,q6apm-dai.yaml
# Conflicts: # arch/arm64/boot/dts/qcom/Makefile
…emory and SMMU mappings" This change have introduced an issue on multimedia builds where AudioRecord is broken on monaco-evk board. [ 153.325884] q6apm-lpass-dais 3000000.remoteproc:glink-edge:gpr:service@1:bedais: Failed to start APM port 19 [ 153.335982] q6apm-lpass-dais 3000000.remoteproc:glink-edge:gpr:service@1:bedais: ASoC error (-110): at soc_dai_trigger() on SEC_MI2S_TX [ 153.348489] MultiMedia2 Capture: ASoC error (-110): at dpcm_be_dai_trigger() on MultiMedia2 Capture [ 153.357875] MultiMedia2 Capture: ASoC error (-110): trigger FE cmd: 1 failed Revert the change for now, to fix the issue. This reverts commit cd0f5c6. Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
…emory and SMMU mappings" This change have introduced an issue on multimedia builds where AudioRecord is broken on lemans-evk board. [ 840.168044] q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: Failed to start APM port 21 [ 840.178229] q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: ASoC error (-110): at soc_dai_trigger() on TERT_MI2S_TX [ 840.190901] MultiMedia2 Capture: ASoC error (-110): at dpcm_be_dai_trigger() on MultiMedia2 Capture [ 840.200277] MultiMedia2 Capture: ASoC error (-110): trigger FE cmd: 1 failed Revert the change for now, to fix the issue. This reverts commit f75b90a.
This change have introduced a regression on Shikra board, wherein Rx on UART Shell is stuck, and no input is accepted. Issue: qualcomm-linux#921 Revert the change for now, to fix the issue. This reverts commit 6a36c4b. Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
Adding merge log file and topic_SHA1 file Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
Salendarsingh Gaud (sgaud-quic)
force-pushed
the
qcom-next-staging-7.2-rc7-20260812
branch
from
August 12, 2026 10:26
3cbb979 to
66b8114
Compare
🔨 Build Failure Analysis — PR #943PR: #943
VerdictBoth errors are introduced by this PR. The PR adds a 📎 Detailed analysis: Full report |
🔨 Build Failure Analysis — PR #943PR: #943
VerdictBoth errors are introduced by this PR. The PR adds a CDSP remoteproc node but fails to add the required smp2p-cdsp communication channel node. 📎 Detailed analysis: Full report |
🔨 Build Failure Analysis — PR #943PR: #943
VerdictBoth errors are introduced by this PR due to inconsistent label naming in the device tree. 📎 Detailed analysis: Full report |
🔨 Build Failure Analysis — PR #943PR: #943
VerdictBoth errors are introduced by this PR. The PR adds a CDSP remoteproc node to eliza.dtsi but fails to define the required smp2p labels. 📎 Detailed analysis: Full report |
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
20 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.
Name SHA Commits
tech/bsp/clk 24b9b5e 32
tech/bsp/devfreq 4809534 7
tech/security/firmware-smc de7413c 6
tech/bsp/soc-infra ff6ff7b 22
tech/bsp/pinctrl 79149ef 1
tech/bsp/remoteproc 39a86aa 13
tech/bus/peripherals e6f6741 8
tech/bus/pci/all 99d5cf2 45
tech/bus/pci/phy 66e44c2 14
tech/bus/usb/dwc 9dd47ad 3
tech/bus/usb/phy c3aa7d5 35
tech/debug/hwtracing 27d6059 23
tech/pmic/misc 8d60b51 22
tech/mem/iommu cdc9e80 9
tech/mm/audio/all 88b8f29 8
tech/mm/camss dffc6e9 49
tech/mm/drm 209715e 75
tech/mm/fastrpc bff2f47 12
tech/mm/video bdcc5c4 127
tech/mm/gpu 0b8d9f4 7
tech/mproc/rpmsg 55dc464 1
tech/net/ath 149122b 20
tech/net/bluetooth 450dc5e 7
tech/pm/power f712532 16
tech/pm/thermal d525ff9 8
tech/security/crypto 1f60c0a 23
tech/security/ice beabac0 9
tech/storage/all cef1b3c 5
tech/all/dt/qcs6490 740676b 27
tech/all/dt/qcs9100 0a48d61 92
tech/all/dt/qcs8300 a02cf61 31
tech/all/dt/qcs615 5cec04d 10
tech/all/dt/agatti c828f10 1
tech/all/dt/eliza 4dc6311 23
tech/all/dt/hamoa 106f486 49
tech/all/dt/glymur 6caeb7d 60
tech/all/dt/kaanapali d21ef73 26
tech/all/dt/pakala 33ecf6f 14
tech/all/config 0e19c86 76
tech/overlay/dt b895d0e 78
tech/all/workaround 219d869 12
tech/mproc/all 104969c 2
tech/noup/debug/all e473076 29
tech/hwe/unoq a2d85fe 4
early/hwe/shikra/drivers b19d2ec 184
early/hwe/shikra/dt dd90d88 130
early/hwe/lyra d92faf9 3