Re: [PATCH v3 00/15] firmware: qcom: Add OP-TEE PAS service support
Sumit Garg via OP-TEE <[email protected]> Tue, 7 Apr 2026 10:24:44 +0530
| Newsgroups | org.trustedfirmware.lists.op-tee,org.freedesktop.lists.dri-devel,org.infradead.lists.ath12k,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel,org.kernel.vger.linux-media,org.kernel.vger.linux-remoteproc,org.kernel.vger.linux-wireless,org.kernel.vger.netdev |
|---|---|
| Message-ID | <adSOFCL26y5qt1Cu@sumit-xelite> |
Hi Bjorn, On Mon, Apr 06, 2026 at 10:09:27AM -0500, Bjorn Andersson wrote: > On Fri, Mar 27, 2026 at 06:40:28PM +0530, Sumit Garg wrote: > > From: Sumit Garg <[email protected]> > > > > 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. > > > > Please get our colleagues involved in this discussion, because this > non-SCM interface does not match the direction we are taking. I thought I have already involved folks from QTEE perspective (Apurupa and Sree) actively working on FF-A implementation aligned to this interface. It would have been better if you could let me know where is the direction mismatch here. In case there is a better alternative design proposal for PAS service with FF-A, I would be happy to hear that. Anyhow for the legacy SoCs like KLMT, we really don't have any alternative but have to stick to existing QTEE PAS design with OP-TEE providing as an alternative backend. Surely we want to support loading of existing signed firmware present in linux-firmware repo for KLMT with OP-TEE being the TZ. -Sumit