Prepare qcom-next based on tag 'Linux 7.0-rc3' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git#355
Open
sgaud-quic wants to merge 518 commits intoqualcomm-linux:qcom-next-stagingfrom
Conversation
Monaco EVK board does not include a camera sensor in its default hardware configuration. Introducing a device tree overlay to support optional integration of the IMX577 sensor via CSIPHY1. Camera reset is handled through an I2C expander, and power is enabled via TLMM GPIO74. An example media-ctl pipeline for the imx577 is: media-ctl --reset media-ctl -V '"imx577 3-001a":0[fmt:SRGGB10/4056x3040 field:none]' media-ctl -V '"msm_csiphy1":0[fmt:SRGGB10/4056x3040]' media-ctl -V '"msm_csid0":0[fmt:SRGGB10/4056x3040]' media-ctl -V '"msm_vfe0_rdi0":0[fmt:SRGGB10/4056x3040]' media-ctl -l '"msm_csiphy1":1->"msm_csid0":0[1]' media-ctl -l '"msm_csid0":1->"msm_vfe0_rdi0":0[1]' yavta -B capture-mplane -c -I -n 5 -f SRGGB10P -s 4056x3040 -F /dev/video1 Link: https://lore.kernel.org/r/20251126081057.4191122-4-quic_vikramsa@quicinc.com Signed-off-by: Nihal Kumar Gupta <quic_nihalkum@quicinc.com> Co-developed-by: Ravi Shankar <quic_rshankar@quicinc.com> Signed-off-by: Ravi Shankar <quic_rshankar@quicinc.com> Co-developed-by: Vishal Verma <quic_vishverm@quicinc.com> Signed-off-by: Vishal Verma <quic_vishverm@quicinc.com> Signed-off-by: Vikram Sharma <quic_vikramsa@quicinc.com> Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Enable WLAN on qcs8300-ride by adding a node for the PMU module of the WCN6855 and assigning its LDO power outputs to the existing WiFi module. On the qcs8300-ride platform, the corresponding firmware and BDF are QCA6698AQ instead of WCN6855, which have been added in the 20250211 release. Link: https://lore.kernel.org/r/20260225071459.1600394-1-wei.zhang@oss.qualcomm.com Signed-off-by: Wei Zhang <wei.zhang@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.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/20251113130519.2647081-1-wei.deng@oss.qualcomm.com/ Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
Enable BT on qcs8300-ride by adding a BT device tree node. Since the platform uses the QCA6698 Bluetooth chip. While the QCA6698 shares the same IP core as the WCN6855, it has different RF components and RAM sizes, requiring new firmware files. Use the firmware-name property to specify the NVM and rampatch firmware to load. Link: https://lore.kernel.org/all/20251118140406.1551669-2-wei.deng@oss.qualcomm.com/ Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
…ice nodes Add device tree nodes for the DSI0 controller with their corresponding PHY found on Qualcomm QCS8300 SoC. Link: https://lore.kernel.org/r/20260217090955.2446470-2-quic_amakhija@quicinc.com Signed-off-by: Ayushi Makhija <quic_amakhija@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
…e node Add anx7625 DSI to DP bridge device node. Link: https://lore.kernel.org/r/20260217090955.2446470-3-quic_amakhija@quicinc.com Signed-off-by: Ayushi Makhija <quic_amakhija@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Monaco-evk has LT8713sx which act as DP to 3 DP output converter. Edp PHY from monaco soc is connected to lt8713sx as input and output of lt8713sx is connected to 3 mini DP ports. Two ports are available in mainboard and one port is available on Mezz board. lt8713sx is connected to soc over i2c0 and with reset gpio connected to pin6 of ioexpander5. Enable the edp nodes from monaco and enable lontium lt8713sx bridge node. Link: https://lore.kernel.org/r/20251228-lt8713sx-bridge-linux-for-next-v3-1-3f77ad84d7d1@oss.qualcomm.com Co-developed-by: Prahlad Valluru <vvalluru@qti.qualcomm.com> Signed-off-by: Prahlad Valluru <vvalluru@qti.qualcomm.com> Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
The Qualcomm SerDes PHY, present on multiple boards, has two regulators providing supplies of 1.2V (L5A) and 0.9V (L4A). Update the node to reflect the same instead of incorrectly voting for only L4A. Link: https://lore.kernel.org/r/20251124-sgmiieth_serdes_regulator-v1-4-73ae8f9cbe2a@oss.qualcomm.com Fixes: 117d6bc ("arm64: dts: qcom: qcs8300: Add Monaco EVK board") Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
…egulator Add the additional 0.9V regulator for the Qualcomm SerDes PHY. Link: https://lore.kernel.org/r/20251124-sgmiieth_serdes_regulator-v1-5-73ae8f9cbe2a@oss.qualcomm.com Fixes: 787cb3b ("arm64: dts: qcom: qcs8300-ride: enable ethernet0") Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
PCIe phy needs to be voted for QREF regulator, As the base dtsi changes are still pending we haven't posted the actual fix. Till we post actual fix to upstream, use this change as a workaround. Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Enable cdsp cooling devices and thermal zone cooling map bindings for cdsp. Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com> Link: https://lore.kernel.org/all/20251223123227.1317244-9-gaurav.kohli@oss.qualcomm.com/
…bypass pwrseq flow There is a conflict between the current DTS configuration and the driver behavior for the WCN6855 Bluetooth path. With the PMU node in place, the driver takes the pwrseq code path unintentionally, which leads to Bluetooth failing to power up during an on -> off -> on transition. To unblock function, temporarily remove the WCN6855 PMU node so that the driver follows the non-pwrseq path and avoids the unexpected sequence. This is a TEMPORARY WORKAROUND. Once a proper M.2 binding/solution is upstreamed, will re-submit both DTS and driver changes aligned with the M.2 model. Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
All the Monaco 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 Monaco 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/lkml/20260127-talos-el2-overlay-v2-2-b6a2266532c4@oss.qualcomm.com/ Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Currently pcie1 global IRQ is blocking a CPU core, due to which ufs is getting blocked and failing. As workaround disable PCIe1 global IRQ for now. Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Certain drivers were failing to probe during boot because their dependencies were not ready within the default deferred probe timeout. To address this, increase the deferred probe timeout to allow dependent drivers sufficient time to register and avoid probe failures during system startup. Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
When PCIe L1ss is enabled, WLAN functionality is completly broken. There are some connectivity issues in this platform mostly with CLKREQ# pin. Disable L1ss as workaround untill actual issue get resolved. Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Currently pcie1 global IRQ is blocking a CPU core, due to which ufs is getting blocked and failing. As workaround disable PCIe1 global IRQ for now. Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
It is obsrved that qcs9100-ride fails to boot intermittently due to ufs cmd timeouts. The timeout happens as the ufs threaded-irq fails to schedule within the default UIC_CMD_TIMEOUT_DEFAULT (500 msec) due to console logs spewing at the same moment. Increase timeout to max for now to UIC_CMD_TIMEOUT_MAX (5000 msecs) to allow ufs cmd sequences to complete. Signed-off-by: Shiraz Hashim <shiraz.hashim@oss.qualcomm.com>
…cture Add reference counting using kref to the fastrpc_user structure to prevent use-after-free issues when contexts are freed from workqueue after device release. The issue occurs when fastrpc_device_release() frees the user structure while invoke contexts are still pending in the workqueue. When the workqueue later calls fastrpc_context_free(), it attempts to access buf->fl->cctx in fastrpc_buf_free(), leading to a use-after-free: pc : fastrpc_buf_free+0x38/0x80 [fastrpc] lr : fastrpc_context_free+0xa8/0x1b0 [fastrpc] ... fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_put_wq+0x78/0xa0 [fastrpc] process_one_work+0x180/0x450 worker_thread+0x26c/0x388 Implement proper reference counting to fix this: - Initialize kref in fastrpc_device_open() - Take a reference in fastrpc_context_alloc() for each context - Release the reference in fastrpc_context_free() when context is freed - Release the initial reference in fastrpc_device_release() This ensures the user structure remains valid as long as there are contexts holding references to it, preventing the race condition. Link: https://lore.kernel.org/all/20260226151121.818852-1-anandu.e@oss.qualcomm.com/ Signed-off-by: Anandu Krishnan E <anandu.e@oss.qualcomm.com>
A remoteproc booted during earlier boot stages such as UEFI or the bootloader, may need to be attached to without restarting the remoteproc hardware. To do this the remoteproc will need to check the ready and handover states in smp2p without an interrupt notification. Create qcom_smp2p_start_in() to initialize the shadow state without notifying clients because these early events happened in the past. Add support for the .irq_get_irqchip_state callback so remoteproc can read the current state of the fatal, ready and handover bits. Signed-off-by: Chris Lew <chris.lew@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260127-smp2pv2-v3-1-4060b859b1e2@oss.qualcomm.com Signed-off-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com>
smp2p v2 adds support for allowing remote processors to write outbound smp2p items without completing the feature negotiation. This is required for processors that start before linux to write out signals like error and clock ready and unblock their bootup. If a remote processor only supports v1, smp2p can version down by mirroring the peer version during the negotiation stage. When using smp2p version 2, the remote does not wait for the ssr ack before setting the items. To accommodate this, set the last_value of all the entries to 0 when SSR is detected. This forces smp2p to detect the new values written by the remote. Because the SSR ack is skipped, the down transition of bits is missed in smp2p version 2. Signed-off-by: Chris Lew <chris.lew@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260127-smp2pv2-v3-2-4060b859b1e2@oss.qualcomm.com Signed-off-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com>
Most modern Qualcomm platforms (>= SM8150) expose information about the DDR memory present on the system via SMEM. Details from this information is used in various scenarios, such as multimedia drivers configuring the hardware based on the "Highest Bank address Bit" (hbb), or the list of valid frequencies in validation scenarios... Add support for parsing v3-v7 version of the structs. Unforunately, they are not versioned, so some elbow grease is necessary to determine which one is present. See for reference: ver 3: https://git.codelinaro.org/clo/la/abl/tianocore/edk2/-/commit/1d11897d2cfcc7b85f28ff74c445018dbbecac7a ver 4: https://git.codelinaro.org/clo/la/abl/tianocore/edk2/-/commit/f6e9aa549260bbc0bdcb156c2b05f48dc5963203 ver 5: https://git.codelinaro.org/clo/la/abl/tianocore/edk2/-/commit/617d3297abe8b1b8dd3de3d1dd69c3961e6f343f ver 5 with 6regions: https://git.codelinaro.org/clo/la/abl/tianocore/edk2/-/commit/d770e009f9bae58d56d926f7490bbfb45af8341f ver 6: https://git.codelinaro.org/clo/la/abl/tianocore/edk2/-/commit/62659b557fdb1551b20fae8073d1d701dfa8a62e ver 7: https://git.codelinaro.org/clo/la/abl/tianocore/edk2/-/commit/734d95599c5ebb1ca0d4e1639142e65c590532b7 Reviewed-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-HDK Link: https://lore.kernel.org/r/20260108-topic-smem_dramc-v3-1-6b64df58a017@oss.qualcomm.com
When qrtr is loaded as module, qrtr-ns runs from SELinux kmod_t domain. On targets using upstream SELinux policies, this domain does not receive CAP_NET_ADMIN, which prevents it from binding control port even though qrtr-ns is a trusted system component. Granting kmod_t the CAP_NET_ADMIN capability in policy is possible, but not desirable, as kmod_t is not expected to perform networking operations and widening its capability set is discouraged. To address this in a contained way within qrtr, extend the control port permission check to allow binding when either: - the process has CAP_NET_ADMIN, or - the process belongs to GLOBAL_ROOT_GID (root-equivalent tasks) This permits qrtr-ns to successfully bind its control port in kmod_t restricted environments without broadening SELinux capability assignments. Link: https://lore.kernel.org/r/20260205-qrtr-control-port-access-permission-v1-1-e900039e92d5@oss.qualcomm.com Co-developed-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com> Signed-off-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com> Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
Reduce zone1_thres_count from 16 to 3 so the driver can lower the bus vote after 3 sample windows instead of waiting for 16. The previous 16‑window delay (~64 ms) is too long at higher FPS workloads, causing delayed decision making and measurable power regression. Empirical tuning showed that lower values (e.g., 2) made bwmon behavior jittery, while higher values (4–6) were stable but less responsive and reduced power savings. A value of 3 provided the best balance: responsive enough for timely power reduction while maintaining stable bwmon operation. Significant power savings were observed across multiple use cases when reducing the threshold from 16 to 3: USECASE zone1_thres_count=16 zone1_thres_count=3 4K video playback 236.15 mA 203.15 mA Sleep 7mA 6.9mA Display (idle display) 71.95mA 67.11mA Link: https://lore.kernel.org/r/20260227111051.1789439-1-pussin@qti.qualcomm.com Signed-off-by: Shivnandan Kumar <quic_kshivnan@quicinc.com> Signed-off-by: Pushpendra Singh <pussin@qti.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>
…_req_ei It looks element length declared in servreg_loc_pfr_req_ei for reason not matching servreg_loc_pfr_req's reason field due which we could observe decoding error on PD crash. qmi_decode_string_elem: String len 81 >= Max Len 65 Fix this by matching with servreg_loc_pfr_req's reason field. Cc: stable@vger.kernel.org Fixes: 1ebcde0 ("soc: qcom: add pd-mapper implementation") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Co-developed-by: Gokul Krishnakumar <gokul.krishnakumar@oss.qualcomm.com> Signed-off-by: Gokul Krishnakumar <gokul.krishnakumar@oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Signed-off-by: Xin Liu <xin.liu@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260202103641.3003867-1-mukesh.ojha@oss.qualcomm.com/
Few error paths in the qmi_interface module log a failure message but do not include the actual error code. Include the error value in the log so debugging failures becomes easier. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Signed-off-by: Xin Liu <xin.liu@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260202103641.3003867-2-mukesh.ojha@oss.qualcomm.com/
… compatible Define a Glymur compatible string for the QMP combo PHY, along with resource requirements. Acked-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Wesley Cheng <wesley.cheng@oss.qualcomm.com> Link: https://lore.kernel.org/all/20251209-linux-next-12825-v8-1-42133596bda0@oss.qualcomm.com/
Add the Glymur compatible to the M31 eUSB2 PHY, and use the SM8750 as the fallback. Signed-off-by: Wesley Cheng <wesley.cheng@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/all/20251209-linux-next-12825-v8-3-42133596bda0@oss.qualcomm.com/
# Conflicts: # Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml
# Conflicts: # arch/arm64/boot/dts/qcom/talos.dtsi
# Conflicts: # drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
# Conflicts: # arch/arm64/configs/defconfig
sgaud-quic
force-pushed
the
qcom-next-staging-7.0-rc3-20260316
branch
from
04f4ef7 to
f0046df
Compare
Test Matrix
|
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-rc3-20260316
branch
from
f0046df to
4fbbe88
Compare
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 5da9c61 12
tech/bsp/interconnect 7d3a72c 5
tech/security/firmware-smc a50984a 2
tech/bsp/soc-infra c793ce5 5
tech/bsp/remoteproc 11892a2 8
tech/bus/peripherals 486bcf7 1
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 9f9b618 17
tech/debug/hwtracing ef3b67a 30
tech/pmic/misc e6525e3 9
tech/pmic/regulator 81fc8fb 6
tech/mem/iommu 4cff31b 3
tech/mm/audio/all 4fbd58c 9
tech/mm/camss 474b965 17
tech/mm/drm 52fe805 10
tech/mm/fastrpc c29b2a8 5
tech/mm/video 947c848 3
tech/mm/gpu 9c8e55d 2
tech/net/ath 4185630 2
tech/net/eth 49b156f 1
tech/net/qrtr 64d75f7 1
tech/net/phy a3602e9 1
tech/net/bluetooth 45bd075 2
tech/pm/power fe6575e 6
tech/pm/thermal fe74bbc 3
tech/security/crypto a6ce790 12
tech/security/ice 5184a0e 15
tech/storage/all e254dae 1
tech/all/dt/qcs6490 3a9ead0 15
tech/all/dt/qcs9100 5586aac 19
tech/all/dt/qcs8300 37ae346 21
tech/all/dt/qcs615 faec75c 25
tech/all/dt/agatti c828f10 1
tech/all/dt/hamoa b107e47 27
tech/all/dt/glymur ece11da 20
tech/all/dt/kaanapali bd30924 13
tech/all/dt/pakala 7bfc082 4
tech/all/config 4e00978 48
tech/overlay/dt ed58ab1 22
tech/all/workaround 2d2bae0 10
tech/mproc/all eabd91e 4
tech/noup/debug/all b3bff1d 13
tech/hwe/unoq f22c83f 16
early/hwe/shikra/drivers 6752ae9 6
early/hwe/shikra/dt ebaa0e6 3