Prepare qcom-next based on tag 'Linux 7.2-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git - #976
Closed
Salendarsingh Gaud (sgaud-quic) wants to merge 1525 commits into
Conversation
…elay-us Add the standard 'regulator-off-on-delay-us' property to the list of allowed properties for RPMh regulators. This property is required for platforms where specific rails (like camera LDOs) rely on passive discharge and need a mandatory off-time constraint enforced by the regulator core. Link: https://lore.kernel.org/all/20260127190211.14312-2-bjsaikiran@gmail.com/ Signed-off-by: Saikiran <bjsaikiran@gmail.com>
…y-us The core regulator framework supports enforcing a physical off-time via standard properties, but the `qcom-rpmh-regulator` driver currently ignores them. The issue is platform-specific: The Lenovo Yoga Slim 7x (Snapdragon X Elite) has large bulk capacitors on the camera rails (LDO1, LDO3, LDO7). When these regulators are disabled, the voltage decays very slowly (passive discharge). If the rail is re-enabled before this discharge completes, the sensor experiences a brownout and fails to initialize. Add support for parsing the 'regulator-off-on-delay-us' property from the device tree to enforce this physical constraint. Link: https://lore.kernel.org/all/20260127190211.14312-3-bjsaikiran@gmail.com/ Signed-off-by: Saikiran <bjsaikiran@gmail.com>
…m5_get_temp Commit bb21ee3 ("iio: Fix iio_multiply_value use in iio_read_channel_processed_scale") fixed the iio_read_channel_processed_scale to return 0 on success instead of IIO_VAL_INT (1). The existing check in adc_tm5_get_temp() treated a successful return as an error because it expected IIO_VAL_INT. Drop the redundant `ret != IIO_VAL_INT` condition and rely solely on the negative error check. Link: https://lore.kernel.org/all/20260724-adc-tm5-drop-iio-val-int-check-v1-1-0b85a0895dd7@oss.qualcomm.com/ Fixes: bb21ee3 ("iio: Fix iio_multiply_value use in iio_read_channel_processed_scale") Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
PMIC5 Gen4 ADC is similar to PMIC5 Gen3 ADC, with several changes made for improved performance, mostly at the hardware level. The main differences are increased ratiometric conversion resolution (from 14 bits to 16 bits) and increased bit field width for PMIC SID (to allow communication with an increased number of PMICs, supported on latest SoCs). Link: https://lore.kernel.org/all/20260731-pmic5_gen4_adc-v1-1-9c49b2eea6f9@oss.qualcomm.com/ Signed-off-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>
…en4 ADC PMIC5 Gen4 ADC is similar to PMIC5 Gen3 ADC, with several changes made for improved performance, mostly at the hardware level. One significant software change is that ratiometric conversion resolution has been increased from 14 bits to 16 bits, so the maximum value of these measurements needs to be updated for Gen4. Add a new scaling function for thermistor channels which use this type of conversion. In the latest PMIC arbiter version (v8), there can be up to 4 buses under the PMIC arbiter and 32 PMICs under each bus. In order to support communication between ADC on the master PMIC and ADCs on any of the other PMICs, a field of width 2 bits is added for bus index and the bits for SID are extended from 4 to 5 bits, in the SID register. Add support for this. In addition, it is possible that the master PMIC has ADC of one generation and it needs to communicate with another PMIC with ADC of a different generation. Add new DT properties "qcom,adc5-gen3" and "qcom,adc5-gen4", to distinguish Gen3 channels under a Gen4 master and Gen4 channels under a Gen3 master respectively, to ensure that their conversions are handled correctly. Link: https://lore.kernel.org/all/20260731-pmic5_gen4_adc-v1-2-9c49b2eea6f9@oss.qualcomm.com/ Co-developed-by: Anjelique Melendez <anjelique.melendez@oss.qualcomm.com> Signed-off-by: Anjelique Melendez <anjelique.melendez@oss.qualcomm.com> Signed-off-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>
… PMIC5 Gen4 ADC PMIC5 Gen4 ADC is similar to PMIC5 Gen3 ADC, with several changes made for improved performance, mostly at the hardware level. One significant software change is that ratiometric conversion resolution has been increased from 14 bits to 16 bits. Add a reverse scaling function for Gen4 ADC thermistor channels. In the latest PMIC arbiter version (v8), there can be up to 4 buses under the PMIC arbiter and 32 PMICs under each bus. In order to support communication between ADC on the master PMIC and ADCs on any of the other PMICs, a field of width 2 bits is added for bus index and the bits for SID are extended from 4 to 5 bits, in the SID register. Add support for this. Link: https://lore.kernel.org/all/20260731-pmic5_gen4_adc-v1-3-9c49b2eea6f9@oss.qualcomm.com/ Co-developed-by: Anjelique Melendez <anjelique.melendez@oss.qualcomm.com> Signed-off-by: Anjelique Melendez <anjelique.melendez@oss.qualcomm.com> Signed-off-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>
Add macro definitions for virtual channels (combination of ADC channel number, PMIC SID number and PMIC bus ID number), to be used in devicetree by clients of ADC5 GEN4 device and in the "reg" property of ADC channels. Link: https://lore.kernel.org/all/20260731-pmic5_gen4_adc-v1-4-9c49b2eea6f9@oss.qualcomm.com/ Signed-off-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>
PMK8850 has an ADC5 Gen4 peripheral that acts as the master ADC for the platform, communicating with ADC peripherals on other PMICs on the system. Add the ADC peripheral node with PMK8850 die_temp and xo_therm channel nodes under it initially. Link: https://lore.kernel.org/all/20260731-pmic5_gen4_adc-v1-5-9c49b2eea6f9@oss.qualcomm.com/ Signed-off-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>
…ply support Extend the qcom_battmgr driver to report up to MAX_USB_PORTS (3) USB-C power supply ports on the X1E80100 & Glymur platform, which exposes more than one charger port to firmware. At firmware-enable time, query USB_NUM_PORTS over the existing BATTMGR_USB_PROPERTY_GET opcode to discover how many ports the firmware actually reports, and register the additional "qcom-battmgr-usb2"/"qcom-battmgr-usb3" power supplies only when the firmware confirms a second/third port. Each additional port is polled independently via new BATTMGR_USB2_PROPERTY_GET/SET (0xC0/0xC1) and BATTMGR_USB3_PROPERTY_GET/SET (0xC2/0xC3) opcodes so its properties are not aliased to the primary port's state. Also add the POWER_SUPPLY_PROP_CAPACITY entry to x1e80100_bat_props[]. Link: https://lore.kernel.org/all/20260801-b4-battmgr-multiport-usb-v1-1-89d90bf5de1f@oss.qualcomm.com/_ Assisted-by: Claude:claude-sonnet-5 Signed-off-by: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>
KASLR randomizes the kernel load address at boot to mitigate address leak exploits. While essential for production, it hinders debugging: breakpoints become unreliable, crash dump analysis is harder, and stack trace symbolication requires a fixed base address. Thus, disable CONFIG_RANDOMIZE_BASE in debug.config only. Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
…t properties The pmic_glink driver can now register an RTC auxiliary device on glymur, whose PMIC exposes an RTC over GLINK (see rtc-glink driver). Document the allow-set-time flag it consumes from the parent pmic-glink node. Link: https://lore.kernel.org/all/20260807-rtc-glink-cleanup-v1-1-7801e4d69c4f@oss.qualcomm.com/ Assisted-by: Claude:claude-sonnet-5 Signed-off-by: Raj Aryan <raryan@qti.qualcomm.com> Signed-off-by: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>
…pmic_glink Add a new RTC driver that communicates with the PMIC firmware over the GLINK transport layer. The driver supports reading time and alarm functionality via GET_PROPERTY and SET_PROPERTY opcodes. Time is read via GET_PROPERTY (opcode 0x62) using QCOM_RTC_GLINK_TIME property (0x00). Alarm set and enable are handled via SET_PROPERTY (opcode 0x63) using QCOM_RTC_GLINK_ALARM and QCOM_RTC_GLINK_ALARM_ENABLE properties respectively. GET_PROPERTY and SET_PROPERTY responses share the same firmware message layout, with the firmware echoing back the property value. Both opcodes are handled by a common callback path accordingly. Also extend pmic_glink to register the RTC as a PMIC GLINK client and add PMIC GLINK RTC client support for glymur. Link: https://lore.kernel.org/all/20260807-rtc-glink-cleanup-v1-2-7801e4d69c4f@oss.qualcomm.com/ Assisted-by: Claude:claude-sonnet-5 Signed-off-by: Raj Aryan <raryan@qti.qualcomm.com> Signed-off-by: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>
…ower supply support" This reverts commit 640161c4d4bfdbff59b6c4f4ad7a849dc074129c. Signed-off-by: Raj Aryan <raryan@qti.qualcomm.com>
…ply support Extend the qcom_battmgr driver to report up to MAX_USB_PORTS (3) USB-C power supply ports on the X1E80100 & Glymur platform, which exposes more than one charger port to firmware. At firmware-enable time, query USB_NUM_PORTS over the existing BATTMGR_USB_PROPERTY_GET opcode to discover how many ports the firmware actually reports, and register the additional "qcom-battmgr-usb2"/"qcom-battmgr-usb3" power supplies only when the firmware confirms a second/third port. Each additional port is polled independently via new BATTMGR_USB2_PROPERTY_GET/SET (0xC0/0xC1) and BATTMGR_USB3_PROPERTY_GET/SET (0xC2/0xC3) opcodes so its properties are not aliased to the primary port's state. X1E80100 ports report their USB-C adapter type on USB_ADAP_TYPE rather than the SM8350/SC8280XP USB_TYPE property, so add a dedicated x1e80100_usb_prop_map[] mapping POWER_SUPPLY_PROP_USB_TYPE to USB_ADAP_TYPE, and use it for all three X1E80100 USB ports. Give the primary X1E80100 USB port its own update/get_property callback (qcom_battmgr_usb_x1e80100_update()/ qcom_battmgr_usb_x1e80100_get_property()) instead of routing it through the SC8280XP battery-status update path, mirroring the pattern already used for the usb2/usb3 ports. Also add the POWER_SUPPLY_PROP_CAPACITY entry to x1e80100_bat_props[]. Link: https://lore.kernel.org/all/20260806-b4-battmgr-multiport-usb-v2-1-1a6dd1e06cc2@oss.qualcomm.com/ Assisted-by: Claude:claude-sonnet-5 Signed-off-by: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>
Glymur was reusing Hamoa's dump table, but its IMEM base address differs. Add a dedicated dump table for Glymur with the correct imem_base and register it under Glymur's chip IDs. Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
Add C800-C1100 context dump items to Hamoa's dump table to cover CPU8-CPU11, and bump the ETR/ETFSWAO register dump sizes to match. Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
Glymur was reusing Hamoa's dump table, but it has additional CPUs. Add a dedicated Glymur dump table with Hamoa's items plus C1200-C1700 context entries to cover CPU12-CPU17. Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
CONFIG_FUNCTION_TRACER is useful for custom schedulers, so enable it in default build. Signed-off-by: Ankit Sharma <ankit.sharma@oss.qualcomm.com>
…T variants by subdevice ID The WCN6855 and WCN7851 combo chips are available in M.2 card variants that differ by their BT interface: some expose BT over UART while others expose BT over USB. Both variants use the same PCIe device ID for the WiFi interface, distinguished only by their sub-system device ID. The bare PCI_DEVICE() entries match all sub-system IDs, so both UART and USB variants hit the same table entry and trigger UART serdev creation. For USB variants this is wrong — there is no UART BT interface on such a card, and the serdev probe will fail. Narrow the matches to UART variants only by using PCI_DEVICE_SUB with their respective sub-system IDs, so USB variants no longer trigger UART serdev creation. Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com> Link: https://patch.msgid.link/20260724-hamoa-m2-sub-id-v2-v3-1-af97de70bbbe@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
…RT serdev is created The pwrseq_m2_pci_ids[] table lists PCIe BT devices that use UART as the BT transport and need a UART serdev created by the driver. When a PCIe device under the M.2 connector does not match any entry in this table, no UART serdev is created. However, the BT subsystem of such a device may still require W_DISABLE2# to be deasserted to power up. Rather than adding every possible non-UART BT device ID to the table, add an else branch that deasserts W_DISABLE2# whenever a PCIe device is detected under the connector but does not match a UART BT entry. This allows any BT interface on the card (USB or other) to enumerate without requiring explicit knowledge of its device ID. The primary use case is USB BT variants of combo chips that share the same PCIe device ID as their UART counterpart (e.g. WCN7851 NCM865 USB, sub 0x3378, vs NCM865A UART, sub 0x337c): no UART serdev is needed, but W_DISABLE2# must be deasserted so the USB BT device can enumerate. Reassert W_DISABLE2# symmetrically when the PCIe device is removed. Validated on Hamoa EVK (IQ-X7181-EVK) with WCN7851 NCM865 USB card (sub 0x3378): without this change GPIO116 (W_DISABLE2#) stays low and no BT interface appears; with this change GPIO116 is driven high and the USB BT device enumerates and comes up via btusb. Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260709-fix-hamoa-m2-w-disable2-v1-3-5e725091266a@oss.qualcomm.com/
QDU1000 and related Qualcomm SoCs include a dedicated I2C target controller that operates exclusively in target mode. It is a distinct IP from the Qualcomm I2C master controllers (GENI, QUP) with a different register interface, so it requires its own binding. Document the MMIO region, interrupt, XO and AHB clocks, interconnect path, and optional pinctrl states for the controller. Link: https://lore.kernel.org/all/20260802-i2c-qcom-slave-v2-1-27653118fa75@oss.qualcomm.com/ Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
…ller QDU1000 and related Qualcomm SoCs include a dedicated I2C target controller that operates exclusively in target mode. The existing Qualcomm I2C controller drivers (GENI, QUP) are master-only and cannot serve systems where the SoC must respond as an I2C target on the bus. Register the controller with the Linux I2C slave framework via i2c_algorithm.reg_target and i2c_algorithm.unreg_target so that any standard slave backend (e.g. slave-24c02) can be attached at runtime via i2c_slave_register(). Handle IRQ events for RX FIFO service, clock stretching during read and write phases, STOP and repeated-start conditions, and error recovery with SW reset. Enable the required AHB and XO clocks, vote for interconnect bandwidth, and restore hardware state across suspend and resume using the noirq PM callbacks. Link: https://lore.kernel.org/all/20260802-i2c-qcom-slave-v2-2-27653118fa75@oss.qualcomm.com/ Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
…perty While testing with some higher resolution clips, the venus hardware triggers a fault due to wrong input data being received. Corruption was also observed in the captured output when the client dumped it to a file. On debugging, this was traced to the venus node not declaring dma-coherent. As a result, DMA buffers shared between the CPU and the venus video hardware/controller are not guaranteed to be I/O coherent: CPU writes to an input buffer can remain in CPU caches without being visible to the video hardware when it reads the same buffer, so the hardware receives input data that does not match what the CPU wrote. Likewise, on the capture path, data written by the video hardware to the output buffer may not be visible to the CPU, so the client reads stale or partial data, resulting in corruption. Add the dma-coherent property to the venus node so that DMA buffers shared between the CPU and the video hardware and controller remain coherent. Link: https://lore.kernel.org/all/20260801-iris-fixes-dma-pseq-fint-v1-1-aba0cb22f6ab@oss.qualcomm.com/ Fixes: 37613ae ("arm64: dts: qcom: sc7280: Add venus DT node") Cc: stable@vger.kernel.org Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
… framerates iris_enum_frameintervals() advertised frame intervals using V4L2_FRMIVAL_TYPE_STEPWISE with step=1/MAXIMUM_FPS where MAXIMUM_FPS is 480. This caused client to enumerate only framerates of the form MAXIMUM_FPS/n (where n is a positive integer), restricting support to exact divisors of MAXIMUM_FPS (e.g., 480, 240, 160, 120, 96, 80, 60, 30, 24, 1). Framerates that are not exact divisors of MAXIMUM_FPS, such as 29 fps, 25 fps, were excluded from the enumerated list. There is no hardware restriction to framerates that are exact divisors of MAXIMUM_FPS. This caused GStreamer caps negotiation to fail with an "internal data stream error" when encoding content at such framerates. Fix this by using V4L2_FRMIVAL_TYPE_CONTINUOUS. With CONTINUOUS type, GStreamer creates a continuous framerate range [1, max_fps], allowing any integer framerate within the range to pass caps negotiation. The step field is set to 1/1 as required by the V4L2 specification for continuous frame intervals. Link: https://lore.kernel.org/all/20260801-iris-fixes-dma-pseq-fint-v1-4-aba0cb22f6ab@oss.qualcomm.com/ Fixes: a688243 ("media: iris: Add support for ENUM_FRAMESIZES/FRAMEINTERVALS for encoder") Cc: stable@vger.kernel.org Signed-off-by: Vishnu Reddy <busanna.reddy@oss.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>
…es for Monaco The PCIe QMP PHYs on Monaco (QCS8300) require stable reference voltage provided by refgen and reference clock provided by qref. The refgen and qref require power supplies. Add a new sa8775p_qmp_phy_vreg_l list with vdda-qref and vdda-refgen supplies, and use it for qcs8300_qmp_gen4x2, sa8775p_qmp_gen4x2 and sa8775p_qmp_gen4x4 PCIe PHY configurations. Workaround will be reverted once the vote qref regulator for PCIe available in upstream. Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
…fgen supplies for PCIe PHYs The PCIe QMP PHYs on QCS8300 require stable reference voltage provided by refgen and reference clock provided by qref. Add vdda-qref-supply and vdda-refgen-supply to pcie0_phy and pcie1_phy nodes on the qcs8300-ride board. Workaround will be reverted once the vote qref regulator for PCIe available in upstream. Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
On compute targets, PCIe is dependent on the UEFI. In UEFI, when a PCIe link-up fails on a given root port, the default behavior is to power down that root port. The power-down sequence disables the PHY, removes all clock votes, and drops the Interconnect Bandwidth (ICB) votes that were applied in UEFI for that PCIe controller. The HLOS PCIe driver when probes the PCIe6 root port, but probe fails because the PHY is already powered down and there is no PHY bring-up sequence in HLOS for any controller. Since PCIe probe fails, the Interconnect driver's sync_state callback never gets invoked. As a result, the max boot votes applied to other peripherals are never released or reduced, keeping the system stuck at max bandwidth votes and causing the sync state errors observed, this also blocks XO shutdown. Fix this temporarly, by disabling pcie6 now as modem is not functional in this release. we will revert this after finding proper fix. Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
…nule issue Qualcomm SMMU-500 has an issue with TLBIVA/TLBIVAL where only the base-page-size entry at the base IOVA is invalidated, leaving stale TLB entries for the rest of the range. This causes use-after-free: after dma_free_coherent() unmaps a large buffer, the device can still access freed physical memory through stale TLB entries. On FastRPC workloads this manifests as ADSP crashes when the ELF loader writes to a freed PA that has been reallocated. Force the TLB invalidation step granule to the minimum page size for all Qualcomm SMMU-500 domains, ensuring each page in the range is individually invalidated. The minimum page size from pgsize_bitmap is used rather than hardcoded 4K to correctly handle 16K and 64K granule configurations. This increases the number of TLB invalidation operations for large ranges, but correctness takes precedence. Signed-off-by: Prakash Gupta <prakash.gupta@oss.qualcomm.com> Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
…boards Add the ADC channels under the PMK8850 ADC node for the other PMICS on the board with ADC peripherals. This includes die temperature and VPH power channels per PMIC and channels for available system thermistors. Add thermal zones corresponding to the thermistor channels to enable temperature monitoring. Also add io-channels and io-channel-names properties to the temp_alarm nodes so that they can get temperature reading from the newly added ADC die_temp channels. Link: https://lore.kernel.org/all/20260731-pmic5_gen4_adc-v1-7-9c49b2eea6f9@oss.qualcomm.com/ Signed-off-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>
# Conflicts: # drivers/bluetooth/hci_qca.c
# Conflicts: # MAINTAINERS # drivers/remoteproc/qcom_q6v5_pas.c
# Conflicts: # arch/arm64/boot/dts/qcom/Makefile
# Conflicts: # drivers/video/fbdev/core/fbsysfs.c
# Conflicts: # arch/arm64/boot/dts/qcom/monaco-evk.dts # arch/arm64/boot/dts/qcom/monaco.dtsi
# Conflicts: # arch/arm64/boot/dts/qcom/agatti.dtsi
# Conflicts: # arch/arm64/boot/dts/qcom/Makefile # arch/arm64/boot/dts/qcom/talos.dtsi
# Conflicts: # arch/arm64/boot/dts/qcom/qcs8300-ride.dts # drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
# Conflicts: # drivers/firmware/qcom/Kconfig # drivers/firmware/qcom/Makefile
# Conflicts: # Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml # Documentation/devicetree/bindings/display/msm/qcom,qcm2290-dpu.yaml # Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml # drivers/dma/qcom/bam_dma.c # drivers/misc/fastrpc.c # drivers/soc/qcom/ubwc_config.c # sound/soc/qcom/qdsp6/q6prm.h # sound/soc/qcom/sc8280xp.c
# Conflicts: # Documentation/devicetree/bindings/sound/qcom,q6apm-dai.yaml
# Conflicts: # arch/arm64/boot/dts/qcom/Makefile
Adding merge log file and topic_SHA1 file Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Name SHA Commits
tech/bsp/clk 24b9b5e 32
tech/bsp/devfreq 4809534 7
tech/security/firmware-smc de7413c 6
tech/bsp/soc-infra ff6ff7b 22
tech/bsp/pinctrl 79149ef 1
tech/bsp/remoteproc 39a86aa 13
tech/bus/peripherals e6f6741 8
tech/bus/pci/all 99d5cf2 45
tech/bus/pci/phy 66e44c2 14
tech/bus/usb/dwc d90fb64 4
tech/bus/usb/phy c3aa7d5 35
tech/debug/hwtracing a3f730f 24
tech/pmic/misc 8d60b51 22
tech/mem/iommu cdc9e80 9
tech/mm/audio/all 88b8f29 8
tech/mm/camss dffc6e9 49
tech/mm/drm 83f65e1 76
tech/mm/fastrpc bff2f47 12
tech/mm/video bdcc5c4 127
tech/mm/gpu b9f2291 12
tech/mproc/rpmsg 55dc464 1
tech/net/ath 2ac1acc 21
tech/net/bluetooth 450dc5e 7
tech/pm/power f712532 16
tech/pm/thermal d525ff9 8
tech/security/crypto 1f60c0a 23
tech/security/ice beabac0 9
tech/storage/all cef1b3c 5
tech/all/dt/qcs6490 2e92fd1 28
tech/all/dt/qcs9100 0a48d61 92
tech/all/dt/qcs8300 a02cf61 31
tech/all/dt/qcs615 66b7e2f 11
tech/all/dt/agatti 2ca1b63 2
tech/all/dt/eliza 5338032 25
tech/all/dt/hamoa 106f486 49
tech/all/dt/glymur c5bf216 60
tech/all/dt/kaanapali d21ef73 26
tech/all/dt/pakala 33ecf6f 14
tech/all/config 7b48e6e 78
tech/overlay/dt b895d0e 78
tech/all/workaround 219d869 12
tech/mproc/all 104969c 2
tech/noup/debug/all e473076 29
tech/hwe/unoq a2d85fe 4
early/hwe/shikra/drivers b19d2ec 184
early/hwe/shikra/dt dd90d88 130
early/hwe/lyra 8c9d598 6