On Tue, Apr 07, 2026 at 10:24:44AM +0530, Sumit Garg wrote: > 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.
After further offline internal Qcom discussions, the teams are aligned on the vision to use and extend generic Qcom PAS layer for all the TZ backends whether it's legacy SCM backend based on QTEE, OP-TEE backend as proposed by this patch-set or future object invoke (based on SMCInvoke) for QTEE. I hope with that we can progress to get this patch-set merged in next merge window. I will send v4 shortly after merge window closes to address misc. comments from Harshal on patch 04/15. -Sumit
