Prepare qcom-next based on tag 'Linux 6.19-rc5' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #169
+58,743
−1,513
Conversation
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
Unlike the CPU, the GPU does not throttle its speed automatically when it reaches high temperatures. Set up GPU cooling by throttling the GPU speed when reaching 105°C. Link: https://lore.kernel.org/r/20251105-a663-gpu-support-v7-3-1bcf7f151125@oss.qualcomm.com Signed-off-by: Gaurav Kohli <quic_gkohli@quicinc.com> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Enable GPU for lemans-evk platform and provide path for zap shader. Link: https://lore.kernel.org/r/20251105-a663-gpu-support-v7-4-1bcf7f151125@oss.qualcomm.com Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Enable GPU on both qcs9100-ride platforms and provide the path for zap shader. Link: https://lore.kernel.org/r/20251105-a663-gpu-support-v7-5-1bcf7f151125@oss.qualcomm.com Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Add support for SYSTEM_RESET2 vendor-specific resets as reboot-modes in the psci node. Describe the resets: "bootloader" will cause device to reboot and stop in the bootloader's fastboot mode. "edl" will cause device to reboot into "emergency download mode", which permits loading images via the Firehose protocol. Link: https://lore.kernel.org/r/20251109-arm-psci-system_reset2-vendor-reboots-v17-10-46e085bca4cc@oss.qualcomm.com Signed-off-by: Elliot Berman <elliot.berman@oss.qualcomm.com> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
All the Lemans IOT variants 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 Lemans 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 Link: https://lore.kernel.org/r/20251217-kvm_rproc_v9-v9-14-ab7ac03e0ff1@oss.qualcomm.com Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Add edp reference clock for edp phy on lemans chipset. Link:https://lore.kernel.org/all/20251013104806.6599-4-quic_riteshk@quicinc.com/ Signed-off-by: Ritesh Kumar <quic_riteshk@quicinc.com>
There's a WCN6855 WiFi/Bluetooth module on an M.2 card. To make Bluetooth work, we need to define the necessary device tree nodes, including UART configuration and power supplies. Since there is no standard M.2 binding in the device tree at present, the PMU is described using dedicated PMU nodes to represent the internal regulators required by the module. The module provides a 3.3V supply, which originates from the main board’s 12V rail. To represent this power hierarchy in the device tree, add a fixed 12V regulator node as the DC-IN source and link it to the 3.3V regulator node. Link: https://lore.kernel.org/all/20251112071147.1450258-2-wei.deng@oss.qualcomm.com/ Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
Enable ST33HTPM TPM over SPI16 on the LeMans IoT EVK by adding the required SPI and TPM nodes. Link: https://lore.kernel.org/all/20251114-enable-tpm-lemans-v1-1-c8d8b580ace7@oss.qualcomm.com/ Signed-off-by: Khalid Faisal Ansari <khalid.ansari@oss.qualcomm.com>
…m SGMII PHY Describe the additional vdda-0p9-supply for the Qualcomm SGMII PHY. Link: https://lore.kernel.org/r/20251124-sgmiieth_serdes_regulator-v1-1-73ae8f9cbe2a@oss.qualcomm.com Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
…ulator Add the additional 0.9V regulator for the Qualcomm SerDes PHY. Fixes: 71ee90e ("arm64: dts: qcom: lemans-evk: Enable 2.5G Ethernet interface") Link: https://lore.kernel.org/r/20251124-sgmiieth_serdes_regulator-v1-2-73ae8f9cbe2a@oss.qualcomm.com Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
… PHY regulators Add the additional 0.9V regulators for both of the Qualcomm SerDes PHYs. Link: https://lore.kernel.org/r/20251124-sgmiieth_serdes_regulator-v1-3-73ae8f9cbe2a@oss.qualcomm.com Fixes: 5ef26fb ("arm64: dts: qcom: sa8775p-ride: enable the SerDes PHY") Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
Add cooling-cells property to the CPU nodes to support cpufreq cooling devices. Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251215045451.3150894-1-gaurav.kohli@oss.qualcomm.com
…ld node On Qualcomm Kaanapali platform, IMEM is a block of SRAM shared across multiple IP blocks which can falk back to "mmio-sram". Documnent it and its child node "qcom,pil-reloc-info" which is used for collecting remoteproc ramdumps. Link: https://lore.kernel.org/r/20251123-knp-soc-binding-v4-1-42b349a66c59@oss.qualcomm.com Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
… Kaanapali Document compatibles for the pmh0101, pmh0104, pmh0110 and pmk8850 SPMI PMICs. Signed-off-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com> Link: https://lore.kernel.org/all/20250924-knp-pmic-binding-v1-1-b9cce48b8460@oss.qualcomm.com/
To restrict Gunyah watchdog initialization to Qualcomm platforms running under the Gunyah Hypervisor, register the watchdog device in the QCOM SCM driver. When Gunyah is not present or Gunyah emulates MMIO-based watchdog, we expect Qualcomm watchdog or ARM SBSA watchdog device to be present in the devicetree. First, we make sure we're running under the Gunyah Hypervisor. Then we move to check if any of the above mentioned watchdog device nodes are present, if not then we proceed to register the SMC-based Gunyah watchdog device. Link: https://lore.kernel.org/all/20251118-gunyah_watchdog-v8-1-e5de12e2eef5@oss.qualcomm.com/ Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Tested-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Hrishabh Rajput <hrishabh.rajput@oss.qualcomm.com>
On Qualcomm SoCs running under the Gunyah hypervisor, access to watchdog through MMIO is not available on all platforms. Depending on the hypervisor configuration, the watchdog is either fully emulated or exposed via ARM's SMC Calling Conventions (SMCCC) through the Vendor Specific Hypervisor Service Calls space. Add driver to support the SMC-based watchdog provided by the Gunyah Hypervisor. Device registration is done in the QCOM SCM driver after checks to restrict the watchdog initialization to Qualcomm devices running under Gunyah. Gunyah watchdog is not a hardware but an SMC-based vendor-specific hypervisor interface provided by the Gunyah hypervisor. The design involving QCOM SCM driver for registering the platform device has been devised to avoid adding non-hardware nodes to devicetree. Link: https://lore.kernel.org/all/20251118-gunyah_watchdog-v8-2-e5de12e2eef5@oss.qualcomm.com/ Tested-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Hrishabh Rajput <hrishabh.rajput@oss.qualcomm.com>
On most Qualcomm platforms, the Qualcomm Hypervisor Execution Environment (QHEE) is either used as a standalone hypervisor or co-exists as a module with the Gunyah hypervisor. When QHEE is present, it configures firmware streams for remote processors. If QHEE is not available, the operating system must perform these configurations instead and for that remote processor firmware stream should be presented to the operating system. To support this, add the iommus property as an optional property for PAS-supported devices. Link: https://lore.kernel.org/r/20251217-kvm_rproc_v9-v9-1-ab7ac03e0ff1@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>
The qcom_scm_pas_metadata_release() function already frees the allocated memory and sets ctx->ptr to NULL. Resetting ctx->phys and ctx->size to zero is unnecessary because the context is expected to be discarded after release. Lets removes redundant assignments. Link: https://lore.kernel.org/r/20251217-kvm_rproc_v9-v9-2-ab7ac03e0ff1@oss.qualcomm.com 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/r/20251217-kvm_rproc_v9-v9-3-ab7ac03e0ff1@oss.qualcomm.com Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
…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 allocator helper function. Link: https://lore.kernel.org/r/20251217-kvm_rproc_v9-v9-4-ab7ac03e0ff1@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 and remove metadata context data structure completely. Link: https://lore.kernel.org/r/20251217-kvm_rproc_v9-v9-5-ab7ac03e0ff1@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/r/20251217-kvm_rproc_v9-v9-6-ab7ac03e0ff1@oss.qualcomm.com Reviewed-by: Konrad Dybcio <konrad.dybcio@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/r/20251217-kvm_rproc_v9-v9-7-ab7ac03e0ff1@oss.qualcomm.com Reviewed-by: Konrad Dybcio <konrad.dybcio@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/r/20251217-kvm_rproc_v9-v9-8-ab7ac03e0ff1@oss.qualcomm.com Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Refactor qcom_scm_pas_init_image() by moving the memory allocation, copy, and free operations to a higher-level function, and isolate the actual SMC call in a separate function. The main intention is to allow flexibility for different allocators and to respect any constraints that the allocator API may impose before invoking the actual SCM function. Link: https://lore.kernel.org/r/20251217-kvm_rproc_v9-v9-9-ab7ac03e0ff1@oss.qualcomm.com Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> 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/r/20251217-kvm_rproc_v9-v9-10-ab7ac03e0ff1@oss.qualcomm.com Reviewed-by: Konrad Dybcio <konrad.dybcio@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/r/20251217-kvm_rproc_v9-v9-11-ab7ac03e0ff1@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/r/20251217-kvm_rproc_v9-v9-12-ab7ac03e0ff1@oss.qualcomm.com Reviewed-by: Konrad Dybcio <konrad.dybcio@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/r/20251217-kvm_rproc_v9-v9-13-ab7ac03e0ff1@oss.qualcomm.com Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
There is a scenario, when fatal interrupt triggers rproc crash handling
while a user-space recovery is initiated in parallel. The overlapping
recovery/stop sequences race on rproc state and subdevice teardown,
resulting in a NULL pointer dereference in the GLINK SMEM unregister
path.
Process-A Process-B
fatal error interrupt happens
rproc_crash_handler_work()
mutex_lock_interruptible(&rproc->lock);
...
rproc->state = RPROC_CRASHED;
...
mutex_unlock(&rproc->lock);
rproc_trigger_recovery()
mutex_lock_interruptible(&rproc->lock);
qcom_pas_stop()
qcom_q6v5_pas 20c00000.remoteproc: failed to shutdown: -22
remoteproc remoteproc3: can't stop rproc: -22
mutex_unlock(&rproc->lock);
echo enabled > /sys/class/remoteproc/remoteprocX/recovery
recovery_store()
rproc_trigger_recovery()
mutex_lock_interruptible(&rproc->lock);
rproc_stop()
glink_subdev_stop()
qcom_glink_smem_unregister() ==|
|
V
Unable to handle kernel NULL pointer dereference
at virtual address 0000000000000358
It is tempting to introduce a remoteproc state that could be set from
the ->ops->stop() callback, which would have avoided the second attempt
and prevented the crash. However, making remoteproc recovery dependent
on manual intervention or a system reboot is not ideal. We should always
try to recover the remote processor if possible. A failure in the
->ops->stop() callback might be temporary or caused by a timeout, and a
recovery attempt could still succeed, as seen in similar scenarios.
Therefore, instead of adding a restrictive state, let’s add a NULL check
at the appropriate places to avoid a kernel crash and allow the system
to move forward gracefully.
Link: https://lore.kernel.org/r/20251128103240.1723386-1-mukesh.ojha@oss.qualcomm.com
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
# Conflicts: # Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml
# Conflicts: # arch/arm64/boot/dts/qcom/Makefile # arch/arm64/boot/dts/qcom/talos.dtsi
# 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>
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 567d776 19
tech/security/firmware-smc a50984a 2
tech/bsp/soc-infra 2949741 9
tech/bsp/remoteproc 27311a4 15
tech/bus/peripherals 486bcf7 1
tech/bus/pci/all 2fdd372 9
tech/bus/usb/dwc 49ac8e0 2
tech/bus/usb/phy cb24d23 11
tech/debug/hwtracing 88c50d8 27
tech/pmic/misc 91e88b9 16
tech/pmic/regulator 81fc8fb 6
tech/mem/iommu fc1b59c 1
tech/mm/audio/all ce10fd3 4
tech/mm/camss d1d2c38 3
tech/mm/drm 9bb86be 28
tech/mm/fastrpc 844e24f 4
tech/mm/video 4871417 16
tech/mm/gpu 1651b6d 5
tech/mproc/rpmsg c3875d9 1
tech/net/ath dd2aee0 20
tech/net/eth c280d7e 1
tech/net/bluetooth ee968c9 3
tech/pm/power 7b7e779 7
tech/pm/thermal 363f414 3
tech/security/crypto fa6b06a 11
tech/storage/all ba8c93d 6
tech/all/dt/qcs6490 87b5b8c 7
tech/all/dt/qcs9100 d8bc255 14
tech/all/dt/qcs8300 f5c9375 27
tech/all/dt/qcs615 9b366d4 10
tech/all/dt/hamoa 4c89453 11
tech/all/dt/kaanapali 9508158 5
tech/all/dt/pakala 2288dcf 6
tech/all/config d2f2062 35
tech/overlay/dt 50f2b36 15
tech/all/workaround 960a7bd 2
tech/mproc/all d19a4c1 5
tech/noup/debug/all ada2737 5