Prepare qcom-next based on tag 'Linux 7.0' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git#495
Open
sgaud-quic wants to merge 694 commits intoqualcomm-linux:qcom-next-stagingfrom
Conversation
CS pin added on pinctrl0 property is causing spidev to return -ENODEV since that GPIO is already part of spi5 pinmuxing. Fixes: 3f745bc ("arm64: dts: qcom: qrb2210: add dts for Arduino unoq") Signed-off-by: Riccardo Mereu <r.mereu@arduino.cc> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://patch.msgid.link/20260213101002.105238-1-r.mereu.kernel@arduino.cc
The drm/msm module bundles several drivers, each of them having a separate OF match table, however only MDSS (subsystem) and KMS devices had corresponding MODULE_DEVICE_ID tables. Thus, if the platform has enabled only the GPU device (without enabling display counterparts), the module will not be picked up and loaded by userspace. Add MODULE_DEVICE_ID to the GPU driver and to all other drivers in this module. Fixes: 5545996 ("drm/msm: add a330/apq8x74") Reported-by: Loïc Minier <loic.minier@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Link: https://patch.msgid.link/20260219-msm-device-id-v1-1-9e7315a6fd20@oss.qualcomm.com
This reverts commit 851d5ae. RB1 board fails to boot with this change: [ 17.280102] qcom,fastrpc-cb ab00000.remoteproc:glink-edge:fastrpc:compute-cb@5: mem mmap error, fd 11, vaddr ffffb3670000, size 262144 Issue has been reported upstream here: Link: https://lore.kernel.org/all/acoCFMdKRviiMZRp@sumit-xelite/
Add device tree bindings for the video clock controller on Qualcomm X1P42100 (Purwa) SoC. Signed-off-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260331-purwa-videocc-camcc-v3-1-6daca180a4b1@oss.qualcomm.com
Add X1P42100 camera clock controller support and clock bindings for camera QDSS debug clocks which are applicable for both X1E80100 and X1P42100 platforms. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260331-purwa-videocc-camcc-v3-2-6daca180a4b1@oss.qualcomm.com
…ntroller Add support for the video clock controller for video clients to be able to request for videocc clocks on X1P42100 platform. Although X1P42100 is derived from X1E80100, the video clock controller differs significantly. The BSE clocks are newly added, several cdiv clocks have been removed, and most RCG frequency tables have been updated. Initial PLL configurations also require changes, hence introduce a separate videocc driver for X1P42100 platform. Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260331-purwa-videocc-camcc-v3-3-6daca180a4b1@oss.qualcomm.com
…g clocks Add support for camera QDSS debug clocks on X1E80100 platform which are required to be voted for camera icp and cpas usecases. This change aligns the camcc driver to the new ABI exposed from X1E80100 camcc bindings that supports these camcc QDSS debug clocks. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com> Fixes: 76126a5 ("clk: qcom: Add camcc clock driver for x1e80100") Link: https://lore.kernel.org/r/20260331-purwa-videocc-camcc-v3-4-6daca180a4b1@oss.qualcomm.com
…troller Add support for the camera clock controller for camera clients to be able to request for camcc clocks on X1P42100 platform. Although X1P42100 is derived from X1E80100, the camera clock controller driver differs significantly. Few PLLs, clocks and GDSC's are removed, there is delta in frequency tables for most RCG's and parent data structures also changed for few RCG's. Hence introduce a separate camcc driver for X1P42100 platform. 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/20260331-purwa-videocc-camcc-v3-5-6daca180a4b1@oss.qualcomm.com
Add device tree bindings for the camera clock controller on Qualcomm Glymur SoC. Signed-off-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260402-glymur_camcc-v1-1-e8da05a21da7@oss.qualcomm.com
Add support for the camera clock controller for camera clients to be able to request for camcc clocks on Glymur platform. Signed-off-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260402-glymur_camcc-v1-2-e8da05a21da7@oss.qualcomm.com
Add CAMX overlay dts file for Hamoa boards. This change also enables the compilation of the CAMX overlay for Hamoa boards. Signed-off-by: Ignatius Michael Jihan <mignatiu@qti.qualcomm.com>
…nect in Mahua SoC Document the RPMh Network-on-Chip (NoC) interconnect for the Qualcomm Mahua platform. Mahua is a derivative of the Glymur SoC. Many interconnect nodes are identical and continue to use Glymur fallback compatibles. Mahua introduces SoC-specific configurations and topologies for several NoC blocks, including CNOC, HSCNOC, PCIe West ANoC/Slave NoCs. This updates the existing Glymur yaml schema to include Mahua-specific compatible strings, using two-cell "fallback" compatibles wherever the hardware is identical with Glymur. Co-developed-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com> Signed-off-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com> Signed-off-by: Raviteja Laggyshetty <raviteja.laggyshetty@oss.qualcomm.com> Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260127-mahua_icc-v2-1-f0d8ddf7afca@oss.qualcomm.com
Mahua is a derivative of the Glymur SoC. Extend the
Glymur driver to support Mahua by:
1. Adding new node definitions for interconnects that differ from Glymur
(Config NoC, High-Speed Coherent NoC, PCIe West ANOC/Slave NoC).
2. Reusing existing Glymur definitions for identical NoCs.
3. Overriding the channel and buswidth, with Mahua specific values for
the differing NoCs
Co-developed-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com>
Signed-off-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com>
Signed-off-by: Raviteja Laggyshetty <raviteja.laggyshetty@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260127-mahua_icc-v2-2-f0d8ddf7afca@oss.qualcomm.com
…operty to enable QoS Some QCS8300 interconnect nodes have QoS registers located inside a block whose interface is clock-gated. For those nodes, driver must enable the corresponding clock(s) before accessing the registers. Add the 'clocks' property so the driver can obtain and enable the required clock(s). Only interconnects that have clock‑gated QoS register interface use this property; it is not applicable to all interconnect nodes. Signed-off-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260127090116.1438780-2-odelu.kukatla@oss.qualcomm.com
Enable QoS configuration for master ports with predefined priority and urgency forwarding. Signed-off-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260127090116.1438780-3-odelu.kukatla@oss.qualcomm.com
Add clocks which need to be enabled for configuring QoS on qcs8300 SoC. Signed-off-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260127090116.1438780-4-odelu.kukatla@oss.qualcomm.com
Add cooling-cells property to the CPU nodes to support cpufreq cooling devices. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com> Link: https://patch.msgid.link/20260403-cpufreq-v1-1-9d465988c3f9@oss.qualcomm.com Signed-off-by: Aastha Pandey <aastha.pandey@oss.qualcomm.com>
Commit d4a44f0 ("iommu/arm-smmu: Invoke pm_runtime across the driver") enabled pm_runtime for the arm-smmu device. On systems where the SMMU sits in a power domain, all register accesses must be done while the device is runtime active to avoid unclocked register reads and potential NoC errors. So far, this has not been an issue for most SMMU clients because stall-on-fault is enabled by default. While a translation fault is being handled, the SMMU stalls further translations for that context bank, so the fault handler would not race with a powered-down SMMU. Adreno SMMU now disables stall-on-fault in the presence of fault storms to avoid saturating SMMU resources and hanging the GMU. With stall-on-fault disabled, the SMMU can generate faults while its power domain may no longer be enabled, which makes unclocked accesses to fault-status registers in the SMMU fault handlers possible. Guard the context and global fault handlers with pm_runtime_get_if_active() and pm_runtime_put_autosuspend() so that all SMMU fault register accesses are done with the SMMU powered. In case pm_runtime is not active we can safely ignore the fault as for pm runtime resume the smmu device is reset and fault registers are cleared. List: https://lore.kernel.org/all/20260313-smmu-rpm-v2-1-8c2236b402b0@oss.qualcomm.com/ Fixes: b130440 ("drm/msm: Temporarily disable stall-on-fault after a page fault") Co-developed-by: Pratyush Brahma <pratyush.brahma@oss.qualcomm.com> Signed-off-by: Pratyush Brahma <pratyush.brahma@oss.qualcomm.com> Signed-off-by: Prakash Gupta <prakash.gupta@oss.qualcomm.com>
Devres APIs are intended for use in drivers, and they should be avoided in shared subsystem code which is being used by multiple drivers. Avoid using devres based allocations in the reboot-mode subsystem and manually free the resources. Replace devm_kzalloc with kzalloc and handle memory cleanup explicitly. Fixes: 4fcd504 ("power: reset: add reboot mode driver") Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251109-arm-psci-system_reset2-vendor-reboots-v17-1-46e085bca4cc@oss.qualcomm.com
The reboot-mode driver does not have a strict requirement for device-based registration. It primarily uses the device's of_node to read mode-<cmd> properties. Remove the dependency on struct device and introduce support for firmware node (fwnode) based registration. This enables drivers that are not associated with a struct device to leverage the reboot-mode framework. Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251109-arm-psci-system_reset2-vendor-reboots-v17-2-46e085bca4cc@oss.qualcomm.com
Current reboot-mode supports a single 32-bit argument for any supported mode. Some reboot-mode based drivers may require passing two independent 32-bit arguments during a reboot sequence, for uses-cases, where a mode requires an additional argument. Such drivers may not be able to use the reboot-mode driver. For example, ARM PSCI vendor-specific resets, need two arguments for its operation – reset_type and cookie, to complete the reset operation. If a driver wants to implement this firmware-based reset, it cannot use reboot-mode framework. Introduce 64-bit magic values in reboot-mode driver to accommodate dual 32-bit arguments when specified via device tree. In cases, where no second argument is passed from device tree, keep the upper 32-bit of magic un-changed(0) to maintain backward compatibility. Update the current drivers using reboot-mode for a 64-bit magic value. Reviewed-by: Umang Chheda <umang.chheda@oss.qualcomm.com> Reviewed-by: Nirmesh Kumar Singh <nirmesh.singh@oss.qualcomm.com> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251109-arm-psci-system_reset2-vendor-reboots-v17-3-46e085bca4cc@oss.qualcomm.com
Add ABI documentation for /sys/class/reboot-mode/*/reboot_modes, a read-only sysfs attribute exposing the list of supported reboot-mode arguments. This file is created by reboot-mode framework and provides a user-readable interface to query available reboot-mode arguments. Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251109-arm-psci-system_reset2-vendor-reboots-v17-4-46e085bca4cc@oss.qualcomm.com
Currently, there is no standardized mechanism for userspace to discover which reboot-modes are supported on a given platform. This limitation forces tools and scripts to rely on hardcoded assumptions about the supported reboot-modes. Create a class 'reboot-mode' and a device under it to expose a sysfs interface to show the available reboot mode arguments to userspace. Use the driver_name field of the struct reboot_mode_driver to create the device. For device-based drivers, configure the device driver name as driver_name. This results in the creation of: /sys/class/reboot-mode/<driver>/reboot_modes This read-only sysfs file will exposes the list of supported reboot modes arguments provided by the driver, enabling userspace to query the list of arguments. Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251109-arm-psci-system_reset2-vendor-reboots-v17-5-46e085bca4cc@oss.qualcomm.com
SoC vendors have different types of resets which are controlled through various hardware registers. For instance, Qualcomm SoC may have a requirement that reboot with “bootloader” command should reboot the device to bootloader flashing mode and reboot with “edl” should reboot the device into Emergency flashing mode. Setting up such reboots on Qualcomm devices can be inconsistent across SoC platforms and may require setting different HW registers, where some of these registers may not be accessible to HLOS. These knobs evolve over product generations and require more drivers. PSCI spec defines, SYSTEM_RESET2, vendor-specific reset which can help align this requirement. Add support for PSCI SYSTEM_RESET2, vendor-specific resets and align the implementation to allow user-space initiated reboots to trigger these resets. Implement the PSCI vendor-specific resets by registering to the reboot-mode framework. As psci init is done at early kernel init, reboot-mode registration cannot be done at the time of psci init. This is because reboot-mode creates a “reboot-mode” class for exposing sysfs, which can fail at early kernel init. To overcome this, introduce a late_initcall to register PSCI vendor-specific resets as reboot modes. Implement a reboot-mode write function that sets reset_type and cookie values during the reboot notifier callback. Introduce a firmware-based call for SYSTEM_RESET2 vendor-specific reset in the psci_sys_reset path, using reset_type and cookie if supported by secure firmware. Register a panic notifier and clear vendor_reset valid status during panic. This is needed for any kernel panic that occurs post reboot_notifiers. By using the above implementation, userspace will be able to issue such resets using the reboot() system call with the "*arg" parameter as a string based command. The commands can be defined in PSCI device tree node under “reboot-mode” and are based on the reboot-mode based commands. Reviewed-by: Umang Chheda <umang.chheda@oss.qualcomm.com> Reviewed-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com> Reviewed-by: Nirmesh Kumar Singh <nirmesh.singh@oss.qualcomm.com> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251109-arm-psci-system_reset2-vendor-reboots-v17-7-46e085bca4cc@oss.qualcomm.com
…nd QMP Document PDC reg to configure pass through or secondary controller mode for GPIO IRQs. Document QMP handle for action concerning global resources. Link: https://lore.kernel.org/r/20260312-hamoa_pdc-v1-2-760c8593ce50@oss.qualcomm.com Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com> Signed-off-by: Sneh Mankad <sneh.mankad@oss.qualcomm.com>
There are two modes PDC irqchip supports pass through mode and secondary controller mode. All PDC irqchip supports pass through mode in which both Direct SPIs and GPIO IRQs (as SPIs) are sent to GIC without latching at PDC. Newer PDCs (v3.0 onwards) also support additional secondary controller mode where PDC latches GPIO IRQs and sends to GIC as level type IRQ. Direct SPIs still works same as pass through mode without latching at PDC even in secondary controller mode. All the SoCs so far default uses pass through mode with the exception of x1e. x1e PDC may be set to secondary controller mode for builds on CRD boards whereas it may be set to pass through mode for IoT-EVK. There is no way to read which current mode it is set to and make PDC work in respective mode as the read access is not opened up for non secure world. There is though write access opened up via SCM write API to set the mode. Configure PDC mode to pass through mode for all x1e based boards via SCM write. Link: https://lore.kernel.org/r/20260312-hamoa_pdc-v1-3-760c8593ce50@oss.qualcomm.com Co-developed-by: Sneh Mankad <sneh.mankad@oss.qualcomm.com> Signed-off-by: Sneh Mankad <sneh.mankad@oss.qualcomm.com> Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com>
…100 PDC Purwa shares the Hamoa (X1E80100) PDC device, but the hardware register bug addressed in commit e9a48ea ("irqchip/qcom-pdc: Workaround hardware register bug on X1E80100") is already fixed in Purwa silicon. Hamoa compatible forces the software workaround. Add PDC compatible for purwa as "qcom,x1p42100-pdc" to remove the workaround from Purwa. Fixes: f08edb5 ("arm64: dts: qcom: Add X1P42100 SoC and CRD") Link: https://lore.kernel.org/r/20251231-purwa_pdc-v1-1-2b4979dd88ad@oss.qualcomm.com Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com> Signed-off-by: Sneh Mankad <sneh.mankad@oss.qualcomm.com>
Rename the hamoa camera DTBs variable to match the
hamoa-camera-camx DTB target naming and improve consistency
with existing Makefile conventions.
Fixes: 9041882f7c4c ("QCLINUX: arm64: dts: qcom: Add hamoa camx overlay
dts")
Signed-off-by: Ignatius Michael Jihan <mignatiu@qti.qualcomm.com>
…perty to enable QoS Aggre1-noc interconnect node on QCS615 has QoS registers located inside a block whose interface is clock-gated. Accessing these registers requires the corresponding clock(s) to be enabled. Update the bindings to include the 'clocks' property. Ensure that only aggre1-noc interconnect node uses this property by explicitly forbidding it for all other interconnect nodes. Signed-off-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260311103548.1823044-2-odelu.kukatla@oss.qualcomm.com
Enable QoS configuration for master ports with predefined priority and urgency forwarding. Signed-off-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260311103548.1823044-3-odelu.kukatla@oss.qualcomm.com
# Conflicts: # arch/arm64/boot/dts/qcom/Makefile
# Conflicts: # arch/arm64/boot/dts/qcom/kaanapali.dtsi
# Conflicts: # arch/arm64/boot/dts/qcom/talos.dtsi
# Conflicts: # drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
# Conflicts: # Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml # arch/arm64/configs/defconfig
Test Matrix
|
Test Matrix
|
sgaud-quic
force-pushed
the
qcom-next-staging-7.0-20260420
branch
from
398c3dd to
73d7af4
Compare
Test Matrix
|
Contributor
|
for kaanapali dt change，LGTM |
Contributor
Author
@vnarapar RB8 device is booting fine when i tried locally, please help check the CI setup |
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.0-20260420
branch
from
73d7af4 to
3ab29d9
Compare
Test Matrix
|
Test Matrix
|
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 0f5a318 14
tech/bsp/interconnect ec1ab95 7
tech/security/firmware-smc a50984a 2
tech/bsp/soc-infra c793ce5 5
tech/bsp/pinctrl 28c2b80 1
tech/bsp/remoteproc abb91ae 5
tech/bus/peripherals 0849a10 6
tech/bus/pci/all 6a697f8 6
tech/bus/pci/mhi fb9c163 1
tech/bus/pci/phy aaf8ef1 4
tech/bus/usb/dwc 49ac8e0 2
tech/bus/usb/phy 8c7f91d 35
tech/debug/hwtracing 87ae82d 31
tech/pmic/misc e6525e3 9
tech/pmic/regulator 81fc8fb 6
tech/mem/iommu e31b170 5
tech/mm/audio/all 06f5706 16
tech/mm/camss 7c584e4 29
tech/mm/drm fa2d11c 15
tech/mm/fastrpc c29b2a8 5
tech/mm/video 72e188f 29
tech/mm/gpu 9c8e55d 2
tech/net/ath 0fa4871 3
tech/net/eth 49b156f 1
tech/net/qrtr 64d75f7 1
tech/net/phy a3602e9 1
tech/net/bluetooth 229e73e 3
tech/pm/power 2c0fae8 10
tech/pm/thermal d174ed3 6
tech/security/crypto a6ce790 12
tech/security/ice 7a9d8eb 26
tech/storage/phy cf1667f 1
tech/storage/all e254dae 1
tech/all/dt/qcs6490 5df38ca 19
tech/all/dt/qcs9100 c98cdc0 22
tech/all/dt/qcs8300 a32d843 27
tech/all/dt/qcs615 cdbdac6 27
tech/all/dt/agatti c828f10 1
tech/all/dt/hamoa 0c8d1c1 38
tech/all/dt/glymur ac7a496 32
tech/all/dt/kaanapali 710775e 28
tech/all/dt/pakala f6b63a0 7
tech/all/config b31ed76 57
tech/overlay/dt 2d3b16a 34
tech/all/workaround c3f9d3b 13
tech/mproc/all b204da4 5
tech/noup/debug/all a8695a4 19
tech/hwe/unoq ce06e26 16