Prepare qcom-next based on tag 'Linux 7.1-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git#582
Open
sgaud-quic wants to merge 806 commits into
Conversation
This change enables DP controllers, DPTX0 and DPTX1 alongside their corresponding PHYs of mdss1 which corresponds to edp2 and edp3. Signed-off-by: Mani Chandana Ballary Kuntumalla <quic_mkuntuma@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260402095003.3758176-3-quic_mkuntuma@quicinc.com
…te heap On KODIAK platforms boot can fail when the DT "adsp-rpc-remote-heap" reserved-memory region overlaps with firmware allocations (UEFI/EFI runtime). The kernel then reports failure to reserve the region and subsequent EFI runtime activity may trigger aborts. The remote heap node was described as a fixed "no-map" region, which turns it into a hard carveout. Replace it with a "shared-dma-pool" reserved memory region with reusable CMA-backed allocation, specifying alignment and size. This avoids hard carveouts and reduces the chance of conflicting with firmware memory maps while keeping an explicit pool for ADSP remote heap usage. Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
All the existing variants Kodiak boards are using Gunyah hypervisor which means that, so far, Linux-based OS could only boot in EL1 on those devices. However, it is possible for us to boot Linux at EL2 on these devices [1]. When running under Gunyah, the remote processor firmware IOMMU streams are controlled by Gunyah. However, without Gunyah, the IOMMU is managed by the consumer of this DeviceTree. Therefore, describe the firmware streams for each remote processor. Add a EL2-specific DT overlay and apply it to Kodiak IOT variant devices to create -el2.dtb for each of them alongside "normal" dtb. [1] https://docs.qualcomm.com/bundle/publicresource/topics/80-70020-4/boot-developer-touchpoints.html#uefi Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> [SG: watchdog fixup] Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260427095603.1157963-2-sumit.garg@kernel.org
Enable the MCP2518FD CAN controller on the QCS6490 RB3 Gen2 platform. The controller is connected via SPI3 and uses a 40 MHz oscillator. Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260403-can-spi-kodiak-dtsi-v1-1-4055e67dd3fc@oss.qualcomm.com
Add bindings to describe vendor-specific reboot modes. Values here correspond to valid parameters to vendor-specific reset types in PSCI SYSTEM_RESET2 call. Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260427-arm-psci-system_reset2-vendor-reboots-v21-6-dcf937775e73@oss.qualcomm.com
Add dp_mst_drm to manage the DP MST bridge operations similar to the dp_drm file which manages the SST bridge operations. Each MST encoder creates one bridge and each bridge is bound to its own dp_panel abstraction to manage the operations of its pipeline. Keep the connector/panel association in bridge private state for atomic assignment and release, and mirror it in the bridge object for runtime bridge callbacks. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260410-msm-dp-mst-v4-34-b20518dea8de@oss.qualcomm.com/
…aths Call drm_dp_mst_atomic_check() from msm_atomic_check() so MST-specific state, such as connector and topology changes, is validated as part of the atomic check. Hook the MST helpers into atomic_commit_setup() and atomic_commit_tail() to support non-blocking atomic commits for DisplayPort MST, and ensure MST commits properly wait for dependencies. For SST, non-blocking commits are already handled via commit_tail(), which waits for dependencies in the DRM core. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260410-msm-dp-mst-v4-35-b20518dea8de@oss.qualcomm.com/ Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Introduce an MST connector abstraction for DP MST, with each MST connector associated with a DP panel and connected through a DRM bridge to an MST encoder. The connector is only used for MST helper callbacks, such as detect, get_modes, and get_encoder. Display enable/disable, hotplug handling, and modeset sequencing continue to be handled by the bridge path. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260410-msm-dp-mst-v4-36-b20518dea8de@oss.qualcomm.com/
Add HPD callback for the MST module which shall be invoked from the dp_display's HPD handler to perform MST specific operations in case of HPD. In MST case, route the HPD messages to MST module. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260410-msm-dp-mst-v4-37-b20518dea8de@oss.qualcomm.com/
Use msm_dp_get_mst_intf_id() to get the interface ID for the DP MST controller as the intf_id is unique for each MST stream of each DP controller. For DSI/eDP/DP SST, the stream_id is always 0, so existing behavior remains unchanged. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260410-msm-dp-mst-v4-38-b20518dea8de@oss.qualcomm.com/
…r 0 and 1 This change enables SA8775P support for Multi-Stream Transport (MST), allowing each controller to handle up to two or four DisplayPort streams. As all necessary code for MST support was already implemented in the previous series of patches. Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20250825-msm-dp-mst-v3-38-01faacfcdedd@oss.qualcomm.com/
… set reboot_mode_create_device() and reboot_mode_unregister_device() unconditionally dereference reboot->dev->driver->name to name the sysfs device. psci_init_vendor_reset() allocates a reboot_mode_driver with kzalloc (so reboot->dev == NULL) and never sets reboot->dev, causing a NULL pointer dereference at boot: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000068 pc : reboot_mode_register+0x334/0x3b8 psci_init_vendor_reset+0xdc/0x128 Kernel panic - not syncing: Oops: Fatal exception The offset 0x68 is the 'driver' pointer inside struct device on arm64, confirming that reboot->dev itself is NULL. Fix this by adding a 'name' field to struct reboot_mode_driver. reboot_mode_create_device() and reboot_mode_unregister_device() now prefer reboot->name; they fall back to reboot->dev->driver->name only when reboot->name is NULL, and return -EINVAL / return early if neither source is available. Set reboot->name = "psci" in psci_init_vendor_reset() so the sysfs device is correctly named. Existing device-based callers (nvmem-reboot-mode, syscon-reboot-mode, qcom-pon) are unaffected: they set reboot->dev before calling devm_reboot_mode_register(), so the fallback path is taken as before. Fixes: cfaf0a9 ("power: reset: reboot-mode: Expose sysfs for registered reboot_modes") Fixes: 614b17a ("firmware: psci: Implement vendor-specific resets as reboot-mode") Reported-by: LAVA job 91409 <https://lava-oss.qualcomm.com/scheduler/job/91409> Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
Bootup crash seen on kaanapali-mtp board. [ 8.114249][ C0] [drm:dpu_encoder_frame_done_timeout:2731] [dpu error]enc33 frame done timeout [ 8.116480][ T284] Unable to handle kernel paging request at virtual address ffff800080e5e000 [ 8.116488][ T284] Mem abort info: [ 8.116492][ T284] ESR = 0x0000000096000007 [ 8.116497][ T284] EC = 0x25: DABT (current EL), IL = 32 bits [ 8.116502][ T284] SET = 0, FnV = 0 [ 8.116507][ T284] EA = 0, S1PTW = 0 [ 8.116511][ T284] FSC = 0x07: level 3 translation fault [ 8.116516][ T284] Data abort info: [ 8.116519][ T284] ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 [ 8.116524][ T284] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 8.116529][ T284] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 8.116535][ T284] swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000009bf36c000 [ 8.116541][ T284] [ffff800080e5e000] pgd=0000000000000000, p4d=1000000880346403, pud=1000000880347403, pmd=1000000881e2d403, pte=0000000000000000 [ 8.116567][ T284] Internal error: Oops: 0000000096000007 [#1] SMP Revert the change for now to unblock. This reverts commit b0907ee. Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
A wrong channel survey index was introduced in ath12k_mac_op_get_survey by [1], which can cause ACS to fail. The index is decremented before being used, resulting in an incorrect value when accessing the channel survey data. Fix the index handling to ensure the correct survey entry is used and avoid ACS failures. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Fixes: 4f242b1 ("wifi: ath12k: support get_survey mac op for single wiphy") # [1] Signed-off-by: Yingying Tang <yingying.tang@oss.qualcomm.com>
Commit [1] introduces dp->reo_cmd_update_rx_queue_list for the purpose of tracking all pending REO queue flush commands. The helper ath12k_dp_prepare_reo_update_elem() allocates an element and populates it with REO queue information, then add it to the list. The element would be helpful during clean up stage to finally unmap/free the corresponding REO queue buffer. In MLO scenarios with more than one links, for non dp_primary_link_only chips like WCN7850, that helper is called for each link peer. This results in multiple elements added to the list but all of them pointing to the same REO queue buffer. Consequently the same buffer gets unmap/freed multiple times: BUG kmalloc-2k (Tainted: G B W O ): Object already free ----------------------------------------------------------------------------- Allocated in ath12k_wifi7_dp_rx_assign_reoq+0xce/0x280 [ath12k_wifi7] age=7436 cpu=10 pid=16130 __kmalloc_noprof ath12k_wifi7_dp_rx_assign_reoq ath12k_dp_rx_peer_tid_setup ath12k_dp_peer_setup ath12k_mac_station_add ath12k_mac_op_sta_state [...] Freed in ath12k_dp_rx_tid_cleanup.part.0+0x25/0x40 [ath12k] age=1 cpu=27 pid=16137 kfree ath12k_dp_rx_tid_cleanup.part.0 ath12k_dp_rx_reo_cmd_list_cleanup ath12k_dp_cmn_device_deinit ath12k_core_stop ath12k_core_hw_group_cleanup ath12k_pci_remove Fix this by allowing list addition for primary link only. Note dp_primary_link_only chips like QCN9274 are not affected by this change, because that's what they were doing in the first place. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Fixes: 3bf2e57 ("wifi: ath12k: Add Retry Mechanism for REO RX Queue Update Failures") # [1] Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221011 Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Signed-off-by: Yingying Tang <yingying.tang@oss.qualcomm.com>
Add support for 5 GHz channel 177 with a center frequency of 5885 MHz and Operating Class 125 per IEEE Std 802.11-2024 Table E-4. Channels 169, 173, and 177 are in the 5.9 GHz band and must be disabled when 5.9 GHz service bit is not supported. The 5.9 GHz band is only permitted for WLAN operation under FCC regulations. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Link: https://lore.kernel.org/ath12k/20260415063857.2462256-1-yintang@qti.qualcomm.com Signed-off-by: Yingying Tang <yingying.tang@oss.qualcomm.com>
ath12k_dp_rx_deliver_msdu() currently uses hal_rx_desc_data::peer_id parsed from mpdu_start descriptor to do peer lookup. However In an A-MSDU aggregation scenario, hardware only populates mpdu_start descriptor for the first sub-msdu, but not the following ones. In that case peer_id could be invalid, leading to peer lookup failure: ath12k_wifi7_pci 0000:06:00.0: rx skb 00000000c391c041 len 1532 peer (null) 0 ucast sn 0 eht320 rate_idx 12 vht_nss 2 freq 6105 band 3 flag 0x40d1a fcs-err 0 mic-err 0 amsdu-more 0 As a result pubsta is NULL and parts of ieee80211_rx_status structure are left uninitialized, which may cause unexpected behavior. Fix it by switching the normal RX path to use ath12k_skb_rxcb::peer_id which is parsed from REO ring's rx_mpdu_desc and is always valid. hal_rx_desc_data::peer_id is still used in ath12k_wifi7_dp_rx_frag_h_mpdu(), which is safe since A-MSDU aggregation does not occur for fragmented frames. Similarly, ath12k_skb_rxcb::peer_id may be overwritten by hal_rx_desc_data::peer_id in ath12k_wifi7_dp_rx_h_mpdu(), which only handles non-aggregated multicast/broadcast traffic. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Link: https://lore.kernel.org/all/20260427-ath12k-fix-peer-id-source-v1-1-b5f701fb8e88@oss.qualcomm.com Fixes: 11157e0 ("wifi: ath12k: Use ath12k_dp_peer in per packet Tx & Rx paths") Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
HAL_TLV_HDR_LEN was using the wrong bitmask; fix it to cover
bits [21:10]. Also drop HAL_SRNG_TLV_HDR_{TAG,LEN} and use the
generic TLV header bit definitions for TLV32/TLV64 encode/decode
to avoid redundant macros.
Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0.c2-00068-QCACOLSWPL_V1_TO_SILICONZ-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
Fixes: d889913 ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
Link: https://lore.kernel.org/linux-wireless/20260509025819.1641630-2-miaoqing.pan@oss.qualcomm.com/
Change TLV decode helpers to return the TLV value pointer and optionally decode tag/len/usrid via out parameters. This allows reusing the helpers for DP monitor RX status header TLV parsing and avoids duplicated header decoding in callers. No functional change intended. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0.c2-00068-QCACOLSWPL_V1_TO_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com> Link: https://lore.kernel.org/linux-wireless/20260509025819.1641630-3-miaoqing.pan@oss.qualcomm.com/
… alignment Wi-Fi 7 monitor RX status TLV parsing needs to decode TLV headers and advance the pointer with the correct header alignment. Different targets use different TLV header layouts (32-bit vs 64-bit), but the HAL ops for dp_mon RX status header decode and header alignment were not populated for all wifi7 targets. Add dp_mon RX status TLV header decode callbacks and TLV header alignment helpers to the wifi7 HAL ops for QCC2072, QCN9274 and WCN7850. Export helpers to query the required TLV header alignment for 32-bit and 64-bit TLV headers so the caller can align the TLV walk correctly across targets. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0.c2-00068-QCACOLSWPL_V1_TO_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com> Link: https://lore.kernel.org/linux-wireless/20260509025819.1641630-4-miaoqing.pan@oss.qualcomm.com/
Wi-Fi 7 monitor status parsing in dp_mon currently assumes a 64-bit TLV header and directly decodes tag/len/userid from struct hal_tlv_64_hdr. On chips using a 32-bit TLV header (e.g. QCC2072), this causes monitor RX status packets to be dropped during TLV parsing. Introduce HAL helpers to decode TLV header fields (tag/len/userid/value) for both 32-bit and 64-bit header layouts. Without changing the actual TLV parsing logic. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0.c2-00068-QCACOLSWPL_V1_TO_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com> Link: https://lore.kernel.org/linux-wireless/20260509025819.1641630-5-miaoqing.pan@oss.qualcomm.com/
Validate the pointer to the next RX monitor TLV more strictly by ensuring that at least a full TLV header is available within the status buffer before continuing TLV parsing. Prevent potential out-of-bounds access when handling malformed or truncated RX monitor status data. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0.c2-00068-QCACOLSWPL_V1_TO_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com> Link: https://lore.kernel.org/linux-wireless/20260509025819.1641630-6-miaoqing.pan@oss.qualcomm.com/
Introduce the initial support for the Qualcomm Shikra SoC. The initial submission enables support for: - CPUs nodes with PSCI idle states - Interrupt-controller - Top Level Mode Multiplexer (TLMM) - System Timer Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
The Shikra SoM is a compact compute module integrating the SoC and essential components optimized for IoT applications, designed to mount on carrier boards. Shikra supports three SoM variants: two retail options (with and without modem) and one industrial variant , represented by the following device trees: - shikra-cqm-som.dtsi : Retail SoM with modem - shikra-cqs-som.dtsi : Retail SoM without modem - shikra-iqs-som.dtsi : Industrial SoM without modem Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
Add device trees for the Shikra EVK platform, which combines Shikra SoM with a common carrier board. Introduce DTS files for CQM, CQS and IQS EVK variants: - shikra-cqm-evk.dts - shikra-cqs-evk.dts - shikra-iqs-evk.dts Also add a shared include file, shikra-evk.dtsi, which contains the common daughter card nodes used across Shikra EVK variants. Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
Add the reserved memory nodes for Shikra. Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
Add the apps and adreno smmu node as found in Shikra SoC. Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
Add qcom,shikra-apcs-hmss-global for the APCS mailbox binding. This avoids undocumented-compatible warnings from checkpatch and keeps schema constraints aligned for this target. Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
Add the RPM message RAM SRAM region and APCS HMSS global mailbox controller, and wire them up to a new glink-edge node. The rpm_msg_ram node exposes the shared SRAM used for GLINK FIFOs and includes the apss_mpm sub-node for the MPM sleep counter. The `qcom,glink-rpm` transport uses: - `qcom,rpm-msg-ram` for shared GLINK FIFOs - APCS mailbox channel 0 for kick/notify This enables RPM GLINK-based inter-processor communication on Shikra. Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
Add qfprom node and its properties for Shikra SoC. Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
# Conflicts: # arch/arm64/boot/dts/qcom/kaanapali.dtsi
# Conflicts: # drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
# Conflicts: # drivers/remoteproc/qcom_q6v5_pas.c # drivers/soc/qcom/smem.c
Test Matrix
|
…ap_attach() Commit c7d8100 introduced a brace-less if that skips the dma_buf_map_attachment_unlocked() call when sess->coherent is true, leaving 'table' uninitialized. The unconditional IS_ERR(table) check that follows does not catch NULL, so execution continues with a NULL sg_table, causing a level-0 translation fault when the sgl pointer is dereferenced. Remove the guard; the mapping is always needed to obtain DMA addresses consumed by the rest of the function. Signed-off-by: Anandu Krishnan E <anandu.e@oss.qualcomm.com>
Adding merge log file and topic_SHA1 file Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
sgaud-quic
force-pushed
the
qcom-next-staging-7.1-rc2-20260514
branch
from
54e7856 to
1a5fa21
Compare
shashim-quic
approved these changes
May 14, 2026
Test Matrix
|
Test Matrix
|
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 eea3e98 11
tech/bsp/devfreq 6ebf719 6
tech/bsp/ec 069ea63 2
tech/bsp/soc-infra 20c09ce 3
tech/bsp/pinctrl 3f1acf8 1
tech/bsp/remoteproc a7b9b6d 10
tech/bus/peripherals 287f0f5 8
tech/bus/pci/all 13f302c 9
tech/bus/pci/phy aaf8ef1 4
tech/bus/usb/dwc 49ac8e0 2
tech/bus/usb/phy 8c7f91d 35
tech/debug/hwtracing 25c6a74 30
tech/pmic/misc eee20da 1
tech/pmic/regulator 81fc8fb 6
tech/mem/iommu 1fa98cb 5
tech/mm/audio/all cab3357 10
tech/mm/camss b9a32dc 31
tech/mm/drm 2fbdd74 60
tech/mm/fastrpc e0ba718 9
tech/mm/phy 56ccbf4 1
tech/mm/video 5ee68af 38
tech/net/ath 3623de0 13
tech/net/phy a3602e9 1
tech/net/bluetooth 9cca493 2
tech/pm/power 2d42c35 9
tech/pm/thermal 90f2db5 5
tech/security/crypto f030676 14
tech/security/ice 1564b82 25
tech/storage/phy cf1667f 1
tech/storage/all e254dae 1
tech/all/dt/qcs6490 5828ac7 17
tech/all/dt/qcs9100 8a00fd7 17
tech/all/dt/qcs8300 90ba006 15
tech/all/dt/qcs615 9e2f111 9
tech/all/dt/agatti c828f10 1
tech/all/dt/hamoa 670d002 29
tech/all/dt/glymur 9251e24 28
tech/all/dt/kaanapali 7436a08 9
tech/all/dt/pakala 705ac54 6
tech/all/config ff67f6a 61
tech/overlay/dt 88293df 43
tech/all/workaround d15f5a1 15
tech/mproc/all 0aa90b7 3
tech/noup/debug/all 53e8e4b 24
tech/hwe/unoq b2ea57b 5
early/hwe/shikra/drivers 74e831c 69
early/hwe/shikra/dt 8f7e16e 53