From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-14.0 required=3.0 tests=BAYES_00,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A2BC8C4338F for ; Fri, 23 Jul 2021 10:16:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8AABF60EFD for ; Fri, 23 Jul 2021 10:16:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231659AbhGWJgV (ORCPT ); Fri, 23 Jul 2021 05:36:21 -0400 Received: from mail.kernel.org ([198.145.29.99]:42406 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231602AbhGWJgU (ORCPT ); Fri, 23 Jul 2021 05:36:20 -0400 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 59C5560EE6; Fri, 23 Jul 2021 10:16:54 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1m6sEe-000T4o-Id; Fri, 23 Jul 2021 11:16:52 +0100 Date: Fri, 23 Jul 2021 11:16:52 +0100 Message-ID: <87zgud1giz.wl-maz@kernel.org> From: Marc Zyngier To: Jens Wiklander Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, op-tee@lists.trustedfirmware.org, devicetree@vger.kernel.org, linux-doc@vger.kernel.org, Jerome Forissier , Etienne Carriere , Sumit Garg , Vincent Guittot , Rob Herring , Jonathan Corbet , Ard Biesheuvel Subject: Re: [PATCH v3 1/6] docs: staging/tee.rst: add a section on OP-TEE notifications In-Reply-To: <20210723094422.2150313-2-jens.wiklander@linaro.org> References: <20210723094422.2150313-1-jens.wiklander@linaro.org> <20210723094422.2150313-2-jens.wiklander@linaro.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: jens.wiklander@linaro.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, op-tee@lists.trustedfirmware.org, devicetree@vger.kernel.org, linux-doc@vger.kernel.org, jerome@forissier.org, etienne.carriere@linaro.org, sumit.garg@linaro.org, vincent.guittot@linaro.org, robh+dt@kernel.org, corbet@lwn.net, ardb@kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Fri, 23 Jul 2021 10:44:17 +0100, Jens Wiklander wrote: > > Adds a section on notifications used by OP-TEE, synchronous and > asynchronous. > > Signed-off-by: Jens Wiklander > --- > Documentation/staging/tee.rst | 27 +++++++++++++++++++++++++++ > 1 file changed, 27 insertions(+) > > diff --git a/Documentation/staging/tee.rst b/Documentation/staging/tee.rst > index 4d4b5f889603..37bdd097336f 100644 > --- a/Documentation/staging/tee.rst > +++ b/Documentation/staging/tee.rst > @@ -184,6 +184,33 @@ order to support device enumeration. In other words, OP-TEE driver invokes this > application to retrieve a list of Trusted Applications which can be registered > as devices on the TEE bus. > > +OP-TEE notifications > +-------------------- > + > +There are two kinds of notifications that secure world can use to make > +normal world aware of some event. > + > +1. Synchronous notifications delivered with ``OPTEE_RPC_CMD_NOTIFICATION`` > + using the ``OPTEE_RPC_NOTIFICATION_SEND`` parameter. > +2. Asynchronous notifications delivered with a combination of a non-secure > + interrupt and a fast call from the non-secure interrupt handler. > + > +Synchronous notifications are limited by depending on RPC for delivery, > +this is only usable when secure world is entered with a yielding call via > +``OPTEE_SMC_CALL_WITH_ARG``. This excludes such notifications from secure > +world interrupt handlers. > + > +An asynchronous notification is delivered via a non-secure interrupt to an > +interrupt handler registered in the OP-TEE driver. The actual notification > +value are retrieved with the fast call ``OPTEE_SMC_GET_ASYNC_NOTIF_VALUE``. > + > +One notification value ``OPTEE_SMC_ASYNC_NOTIF_VALUE_DO_BOTTOM_HALF`` has a > +special meaning. When this value is received it means that normal world is > +supposed to make a yielding call ``OPTEE_MSG_CMD_DO_BOTTOM_HALF``. This > +call is done from the thread assisting the interrupt handler. This is a > +building block for OP-TEE OS in secure world to implement the top half and > +bottom half style of device drivers. > + What I find missing here is a description of the trigger for this interrupt, and how it influences the way the kernel drivers interacts with the secure side: - if it is edge triggered, this is 'fire and forget'. The interrupt will be consumed by the kernel handler, and whether it eventually calls into the secure side has no impact on the interrupt flow. - if it is level triggered, then the interrupt may be asserted until the kernel calls into the secure side, which may then drop the line level if no other requests are pending. These are evidently two very different flows, and you need to pick a side. Note that not all interrupt controllers support both signalling modes, so you are likely to leave something behind. Or you can try and support both flows, but that may make the driver slightly more complex. Either way, this needs specifying, here and in the DT binding. Thanks, M. -- Without deviation from the norm, progress is not possible.