Qcom next staging 7.2 rc7 20260812 optee - #967
Open
Salendarsingh Gaud (sgaud-quic) wants to merge 1526 commits into
Open
Qcom next staging 7.2 rc7 20260812 optee#967Salendarsingh Gaud (sgaud-quic) wants to merge 1526 commits into
Salendarsingh Gaud (sgaud-quic) wants to merge 1526 commits into
Conversation
…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>
…upport Add binding for the Lontium LT9211C bridge chip. Signed-off-by: Yi Zhang <zhanyi@qti.qualcomm.com> Signed-off-by: Nilesh Laad <nilesh.laad@oss.qualcomm.com> Signed-off-by: Gopi Botlagunta <venkata.botlagunta@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260323-add-lt9211c-bridge-v5-1-9c63bb035c17@oss.qualcomm.com/
Currently edid_read has value from previous connect session and resulting in drm using older edid before new edid is available in lt9611uxc. Reset edid_read so that correct status is updated and correct edid is available for drm. Link: https://lore.kernel.org/lkml/20260202-lt9611uxc-reset-edid-v2-1-b1e1d72edc90@oss.qualcomm.com/ Signed-off-by: Ravi Agola <raviagol@qti.qualcomm.com> Signed-off-by: Nilesh Laad <nilesh.laad@oss.qualcomm.com>
If HPD IRQ is enabled in the display_connector's probe, it can be triggered too early, before the DRM connector is completely setup. Use the enable_hpd / disable_hpd callbacks to control enablement of the HPD IRQ. Fixes: 0c275c3 ("drm/bridge: Add bridge driver for display connectors") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260314-dp-connector-hpd-v1-1-786044cedc17@oss.qualcomm.com/
…r DP If the DisplayPort drivers use display-connector for the HPD detection, the internal HPD state machine might be not active and thus the hardware might be not able to handle cable detection correctly. Instead it will depend on the externall HPD notifications to set the cable state, bypassing the internal HPD state machine (for example this is the case for the msm DP driver). However if the cable has been plugged before the HPD IRQ has been enabled, there will be no HPD event coming. The drivers might fail detection in such a case. Trigger the HPD notification after enabling the HPD IRQ, propagating the cable insertion state. Fixes: 2e2bf3a ("drm/bridge: display-connector: add DP support") Reported-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260314-dp-connector-hpd-v1-2-786044cedc17@oss.qualcomm.com/
…Glymur The existing DP PHY PLL and AUX configuration for the Glymur platform does not fully follow the Hardware Programming Guide requirements for DP over Type-C, which results in DP link bring-up failures. Update the DP PHY programming sequence and PLL-related register settings to align with the latest HPG recommendations. With this change, DP link training completes successfully on Glymur-based platforms. Fixes: d10736d ("phy: qualcomm: qmp-combo: Add DP offsets and settings for Glymur platforms") Link: https://lore.kernel.org/r/20260419-glymur_dp-v1-1-ad1067a8e8ae@oss.qualcomm.com Signed-off-by: Ritesh Kumar <ritesh.kumar@oss.qualcomm.com> Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
LT9211c is a Single/Dual-Link DSI/LVDS or Single DPI input to Single-link/Dual-Link DSI/LVDS or Single DPI output bridge chip. Extend the existing lontium-lt9211 driver to support DSI-to-LVDS bridge configuration. Signed-off-by: Yi Zhang <zhanyi@qti.qualcomm.com> Signed-off-by: Nilesh Laad <nilesh.laad@oss.qualcomm.com> Signed-off-by: Gopi Botlagunta <venkata.botlagunta@oss.qualcomm.com> Link:https://lore.kernel.org/all/20260323-add-lt9211c-bridge-v5-2-9c63bb035c17@oss.qualcomm.com/
Currently valid mode checks are only for hdisplay and vdisplay, add htotal and vtotal to filter only specific modes. Link:https://lore.kernel.org/lkml/20251126-lt9611uxc-modes-v2-1-34bf9b351921@oss.qualcomm.com/ Signed-off-by: Nilesh Laad <nilesh.laad@oss.qualcomm.com> Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
Add 3840x2160@30 mode in lt9611uxc modes to add support for 4K@30 resolution. Link:https://lore.kernel.org/r/20251126-lt9611uxc-4k30-v2-1-3de0ea58c24e@oss.qualcomm.com Signed-off-by: Nilesh Laad <nilesh.laad@oss.qualcomm.com> Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
The cached drm_edid seems unnecessary here. Use the drm_edid pointer directly in the plug stage instead of caching it. Remove the cached drm_edid and the corresponding oneliner to simplify the code. Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260609-dp_mstclean-v7-1-ea04113e8233@oss.qualcomm.com/
The bridge .mode_set() callback is deprecated. Remove it and move all mode setup logic to .atomic_enable(), where the adjusted_mode is available from the atomic CRTC state. Drop msm_dp_mode from msm_dp_display_private and store the mode directly in the panel, as it was only used as a temporary cache. Both changes are limited to msm_dp_display_set_mode and are kept in a single patch. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260609-dp_mstclean-v7-2-ea04113e8233@oss.qualcomm.com/
…fo() The display layer directly assigns msm_dp_panel mode fields (bpp, sync polarity, yuv420 flag) instead of letting the panel manage its own state. Pass adjusted_mode and bpp as parameters to msm_dp_panel_init_panel_info() and move the assignments inside it. Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260609-dp_mstclean-v7-3-ea04113e8233@oss.qualcomm.com/
… and stream parts The DP_CONFIGURATION_CTRL register contains both link-level and stream-specific fields. Currently, msm_dp_ctrl_config_ctrl() configures all of them together. Separate the configuration into link parts and stream parts to support MST. Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260609-dp_mstclean-v7-4-ea04113e8233@oss.qualcomm.com/
…te function Refactor the MISC1_MISC0 register configuration into a standalone helper function to support MST. Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260609-dp_mstclean-v7-5-ea04113e8233@oss.qualcomm.com/
msm_dp_ctrl_configure_source_params() should only handle stream-related configuration. Move the link setup out of it so MST can program link and stream settings separately. Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260609-dp_mstclean-v7-6-ea04113e8233@oss.qualcomm.com/
# 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
…emory and SMMU mappings" This change have introduced an issue on multimedia builds where AudioRecord is broken on monaco-evk board. [ 153.325884] q6apm-lpass-dais 3000000.remoteproc:glink-edge:gpr:service@1:bedais: Failed to start APM port 19 [ 153.335982] q6apm-lpass-dais 3000000.remoteproc:glink-edge:gpr:service@1:bedais: ASoC error (-110): at soc_dai_trigger() on SEC_MI2S_TX [ 153.348489] MultiMedia2 Capture: ASoC error (-110): at dpcm_be_dai_trigger() on MultiMedia2 Capture [ 153.357875] MultiMedia2 Capture: ASoC error (-110): trigger FE cmd: 1 failed Revert the change for now, to fix the issue. This reverts commit cd0f5c6. Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
…emory and SMMU mappings" This change have introduced an issue on multimedia builds where AudioRecord is broken on lemans-evk board. [ 840.168044] q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: Failed to start APM port 21 [ 840.178229] q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: ASoC error (-110): at soc_dai_trigger() on TERT_MI2S_TX [ 840.190901] MultiMedia2 Capture: ASoC error (-110): at dpcm_be_dai_trigger() on MultiMedia2 Capture [ 840.200277] MultiMedia2 Capture: ASoC error (-110): trigger FE cmd: 1 failed Revert the change for now, to fix the issue. This reverts commit f75b90a.
This change have introduced a regression on Shikra board, wherein Rx on UART Shell is stuck, and no input is accepted. Issue: qualcomm-linux#921 Revert the change for now, to fix the issue. This reverts commit 6a36c4b. Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
Adding merge log file and topic_SHA1 file Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
Qcom platforms has the legacy of using non-standard SCM calls splintered over the various kernel drivers. These SCM calls aren't compliant with the standard SMC calling conventions which is a prerequisite to enable migration to the FF-A specifications from Arm. OP-TEE as an alternative trusted OS to Qualcomm TEE (QTEE) can't support these non-standard SCM calls. And even for newer architectures using S-EL2 with Hafnium support, QTEE won't be able to support SCM calls either with FF-A requirements coming in. And with both OP-TEE and QTEE drivers well integrated in the TEE subsystem, it makes further sense to reuse the TEE bus client drivers infrastructure. The added benefit of TEE bus infrastructure is that there is support for discoverable/enumerable services. With that client drivers don't have to manually invoke a special SCM call to know the service status. So enable the generic Peripheral Authentication Service (PAS) provided by the firmware. It acts as the common layer with different TZ backends plugged in whether it's an SCM implementation or a proper TEE bus based PAS service implementation. Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260427095603.1157963-5-sumit.garg@kernel.org/
With the availability of generic PAS service, let's add SCM calls as a backend to keep supporting legacy QTEE interfaces. The exported qcom_scm* wrappers will get dropped once all the client drivers get migrated as part of future patches. Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260427095603.1157963-5-sumit.garg@kernel.org/
Add support for Peripheral Authentication Service (PAS) driver based on TEE bus with OP-TEE providing the backend PAS service implementation. The TEE PAS service ABI is designed to be extensible with additional API as PTA_QCOM_PAS_CAPABILITIES. This allows to accommodate any future extensions of the PAS service needed while still maintaining backwards compatibility. Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260427095603.1157963-5-sumit.garg@kernel.org/
Switch qcom_q6v5_pas client driver over to generic PAS TZ APIs. Generic PAS TZ service allows to support multiple TZ implementation backends like QTEE based SCM PAS service, OP-TEE based PAS service and any further future TZ backend service. Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260427095603.1157963-5-sumit.garg@kernel.org/
Switch qcom_q6v5_mss client driver over to generic PAS TZ APIs. Generic PAS TZ service allows to support multiple TZ implementation backends like QTEE based SCM PAS service, OP-TEE based PAS service and any further future TZ backend service. Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260427095603.1157963-5-sumit.garg@kernel.org/
Switch mdtloader client driver over to generic PAS TZ APIs. Generic PAS TZ service allows to support multiple TZ implementation backends like QTEE based SCM PAS service, OP-TEE based PAS service and any further future TZ backend service. Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260427095603.1157963-5-sumit.garg@kernel.org/
Switch qcom_wcnss client driver over to generic PAS TZ APIs. Generic PAS TZ service allows to support multiple TZ implementation backends like QTEE based SCM PAS service, OP-TEE based PAS service and any further future TZ backend service. Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260427095603.1157963-5-sumit.garg@kernel.org/
Select PAS generic service driver to enable support for multiple PAS backends like OP-TEE in addition to SCM. Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260427095603.1157963-5-sumit.garg@kernel.org/
Switch drm/msm client drivers over to generic PAS TZ APIs. Generic PAS TZ service allows to support multiple TZ implementation backends like QTEE based SCM PAS service, OP-TEE based PAS service and any further future TZ backend service. Acked-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260427095603.1157963-5-sumit.garg@kernel.org/
Switch qcom media client drivers over to generic PAS TZ APIs. Generic PAS TZ service allows to support multiple TZ implementation backends like QTEE based SCM PAS service, OP-TEE based PAS service and any further future TZ backend service. Along with that pass proper PAS ID to set_remote_state API. As per testing the SCM backend just ignores it while OP-TEE makes use of it to for proper book keeping purpose. Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260427095603.1157963-5-sumit.garg@kernel.org/
Switch ipa client driver over to generic PAS TZ APIs. Generic PAS TZ service allows to support multiple TZ implementation backends like QTEE based SCM PAS service, OP-TEE based PAS service and any further future TZ backend service. Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260427095603.1157963-5-sumit.garg@kernel.org/
Switch ath12k client driver over to generic PAS TZ APIs. Generic PAS TZ service allows to support multiple TZ implementation backends like QTEE based SCM PAS service, OP-TEE based PAS service and any further future TZ backend service. Acked-by: Jeff Johnson <jjohnson@kernel.org> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260427095603.1157963-5-sumit.garg@kernel.org/
Now since all the Qcom SCM client drivers have been migrated over to generic PAS TZ service, let's drop the exported SCM PAS wrappers. Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260427095603.1157963-5-sumit.garg@kernel.org/
Add Sumit Garg as the maintainer for the Qualcomm generic Peripheral Authentication Service (PAS) as well as the PAS TEE backend driver. Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260427095603.1157963-5-sumit.garg@kernel.org/
qcom_scm_mem_protect_video_var() is not serviced when PAS is backed by OP-TEE (the TEE owns secure memory protection), so its failure there is expected. Add qcom_pas_is_tee_backed() to report when the active PAS backend is the OP-TEE one, and in iris only treat the SCM failure as fatal when OP-TEE is not on the bus. Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez.ortiz@gmail.com>
Test Matrix
|
Salendarsingh Gaud (sgaud-quic)
force-pushed
the
qcom-next-staging
branch
3 times, most recently
from
August 18, 2026 16:32
4020a6e to
8d3ae59
Compare
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.
No description provided.