Update terminology: standard SMC to yielding SMC

Since Issue B (November 2016) of the SMC Calling Convention document
standard SMC calls are renamed to yielding SMC calls to help avoid
confusion with the standard service SMC range, which remains unchanged.

http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN0028B_SMC_Calling_Convention.pdf

This patch adds a new define for yielding SMC call type and deprecates
the current standard SMC call type. The tsp is migrated to use this new
terminology and, additionally, the documentation and code comments are
updated to use this new terminology.

Change-Id: I0d7cc0224667ee6c050af976745f18c55906a793
Signed-off-by: David Cunado <david.cunado@arm.com>

3 files changed, 31 insertions, 31 deletions

diff --git a/docs/firmware-design.md b/docs/firmware-design.md
index 45e56e69..def802c0 100644
--- a/docs/firmware-design.md
+++ b/docs/firmware-design.md
@@ -686,7 +686,7 @@ Software (BL31).
 
 The design of the runtime services depends heavily on the concepts and
 definitions described in the [SMCCC], in particular SMC Function IDs, Owning
-Entity Numbers (OEN), Fast and Standard calls, and the SMC32 and SMC64 calling
+Entity Numbers (OEN), Fast and Yielding calls, and the SMC32 and SMC64 calling
 conventions. Please refer to that document for more detailed explanation of
 these terms.
 
@@ -812,7 +812,7 @@ SMC Function which indicates the SMC64 calling convention: such calls are
 ignored and return the Unknown SMC Function Identifier result code `0xFFFFFFFF`
 in R0/X0.
 
-Bit[31] (fast/standard call) and bits[29:24] (owning entity number) of the SMC
+Bit[31] (fast/yielding call) and bits[29:24] (owning entity number) of the SMC
 Function ID are combined to index into the `rt_svc_descs_indices[]` array. The
 resulting value might indicate a service that has no handler, in this case the
 framework will also report an Unknown SMC Function ID. Otherwise, the value is
diff --git a/docs/interrupt-framework-design.md b/docs/interrupt-framework-design.md
index b4689496..1deab023 100644
--- a/docs/interrupt-framework-design.md
+++ b/docs/interrupt-framework-design.md
@@ -761,7 +761,7 @@ invoked.
 3.  It sets the `ELR_EL3` system register to `tsp_sel1_intr_entry` and sets the
     `SPSR_EL3.DAIF` bits in the secure CPU context. It sets `x0` to
     `TSP_HANDLE_SEL1_INTR_AND_RETURN`. If the TSP was preempted earlier by a non
-    secure interrupt during `standard` SMC processing, save the registers that
+    secure interrupt during `yielding` SMC processing, save the registers that
     will be trashed, which is the `ELR_EL3` and `SPSR_EL3`, in order to be able
     to re-enter TSP for Secure-EL1 interrupt processing. It does not need to
     save any other secure context since the TSP is expected to preserve it
@@ -809,17 +809,17 @@ upon receiving an SMC with `TSP_HANDLED_S_EL1_INTR` as the function identifier:
 
 ##### 2.3.2.4 Test secure payload dispatcher non-secure interrupt handling
 The TSP in Secure-EL1 can be preempted by a non-secure interrupt during
-`standard` SMC processing or by a higher priority EL3 interrupt during
+`yielding` SMC processing or by a higher priority EL3 interrupt during
 Secure-EL1 interrupt processing. Currently only non-secure interrupts can
 cause preemption of TSP since there are no EL3 interrupts in the
 system.
 
 It should be noted that while TSP is preempted, the TSPD only allows entry into
 the TSP either for Secure-EL1 interrupt handling or for resuming the preempted
-`standard` SMC in response to the `TSP_FID_RESUME` SMC from the normal world.
+`yielding` SMC in response to the `TSP_FID_RESUME` SMC from the normal world.
 (See Section 3).
 
-The non-secure interrupt triggered in Secure-EL1 during `standard` SMC processing
+The non-secure interrupt triggered in Secure-EL1 during `yielding` SMC processing
 can be routed to either EL3 or Secure-EL1 and is controlled by build option
 `TSP_NS_INTR_ASYNC_PREEMPT` (see Section 2.2.2.1). If the build option is set,
 the TSPD will set the routing model for the non-secure interrupt to be routed to
@@ -835,7 +835,7 @@ further handling.
 
 If the `TSP_NS_INTR_ASYNC_PREEMPT` build option is zero (default), the default
 routing model for non-secure interrupt in secure state is in effect
-i.e. __TEL3=0, CSS=0__. During `standard` SMC processing, the IRQ
+i.e. __TEL3=0, CSS=0__. During `yielding` SMC processing, the IRQ
 exceptions are unmasked i.e. `PSTATE.I=0`, and a non-secure interrupt will
 trigger at Secure-EL1 IRQ exception vector. The TSP saves the general purpose
 register context and issues an SMC with `TSP_PREEMPTED` as the function
@@ -860,7 +860,7 @@ invoked:
 4.  `SMC_PREEMPTED` is set in x0 and return to non secure state after
     restoring non secure context.
 
-The Normal World is expected to resume the TSP after the `standard` SMC preemption
+The Normal World is expected to resume the TSP after the `yielding` SMC preemption
 by issuing an SMC with `TSP_FID_RESUME` as the function identifier (see section 3).
 The TSPD service takes the following actions in `tspd_smc_handler()` function
 upon receiving this SMC:
@@ -951,9 +951,9 @@ The TSP handles interrupts under the asynchronous model as follows.
 -----------------------
 
 ### 3.1 Implication of preempted SMC on Non-Secure Software
-A `standard` SMC call to Secure payload can be preempted by a non-secure
+A `yielding` SMC call to Secure payload can be preempted by a non-secure
 interrupt and the execution can return to the non-secure world for handling
-the interrupt (For details on `standard` SMC refer [SMC calling convention]).
+the interrupt (For details on `yielding` SMC refer [SMC calling convention]).
 In this case, the SMC call has not completed its execution and the execution
 must return back to the secure payload to resume the preempted SMC call.
 This can be achieved by issuing an SMC call which instructs to resume the
@@ -964,26 +964,26 @@ a fast SMC call.
 
 In the Test Secure Payload implementation, `TSP_FID_RESUME` is designated
 as the resume SMC FID. It is important to note that `TSP_FID_RESUME` is a
-`standard` SMC which means it too can be be preempted. The typical non
-secure software sequence for issuing a `standard` SMC would look like this,
+`yielding` SMC which means it too can be be preempted. The typical non
+secure software sequence for issuing a `yielding` SMC would look like this,
 assuming `P.STATE.I=0` in the non secure state :
 
     int rc;
-    rc = smc(TSP_STD_SMC_FID, ...);     /* Issue a Standard SMC call */
+    rc = smc(TSP_YIELD_SMC_FID, ...);     /* Issue a Yielding SMC call */
     /* The pending non-secure interrupt is handled by the interrupt handler
        and returns back here. */
     while (rc == SMC_PREEMPTED) {       /* Check if the SMC call is preempted */
         rc = smc(TSP_FID_RESUME);       /* Issue resume SMC call */
     }
 
-The `TSP_STD_SMC_FID` is any `standard` SMC function identifier and the smc()
+The `TSP_YIELD_SMC_FID` is any `yielding` SMC function identifier and the smc()
 function invokes a SMC call with the required arguments. The pending non-secure
 interrupt causes an IRQ exception and the IRQ handler registered at the
 exception vector handles the non-secure interrupt and returns. The return value
 from the SMC call is tested for `SMC_PREEMPTED` to check whether it is
 preempted. If it is, then the resume SMC call `TSP_FID_RESUME` is issued. The
 return value of the SMC call is tested again to check if it is preempted.
-This is done in a loop till the SMC call succeeds or fails. If a `standard`
+This is done in a loop till the SMC call succeeds or fails. If a `yielding`
 SMC is preempted, until it is resumed using `TSP_FID_RESUME` SMC and
 completed, the current TSPD prevents any other SMC call from re-entering
 TSP by returning `SMC_UNK` error.
diff --git a/docs/rt-svc-writers-guide.md b/docs/rt-svc-writers-guide.md
index 4b811fea..ea599ed9 100644
--- a/docs/rt-svc-writers-guide.md
+++ b/docs/rt-svc-writers-guide.md
@@ -51,24 +51,24 @@ of these terms.
 The SMC Function Identifier includes a OEN field. These values and their
 meaning are described in [SMCCC] and summarized in table 1 below. Some entities
 are allocated a range of of OENs. The OEN must be interpreted in conjunction
-with the SMC call type, which is either _Fast_ or _Standard_. Fast calls are
-uninterruptible whereas Standard calls can be pre-empted. The majority of
-Owning Entities only have allocated ranges for Fast calls: Standard calls are
+with the SMC call type, which is either _Fast_ or _Yielding_. Fast calls are
+uninterruptible whereas Yielding calls can be pre-empted. The majority of
+Owning Entities only have allocated ranges for Fast calls: Yielding calls are
 reserved exclusively for Trusted OS providers or for interoperability with
 legacy 32-bit software that predates the [SMCCC].
 
-    Type    OEN     Service
-    Fast     0      ARM Architecture calls
-    Fast     1      CPU Service calls
-    Fast     2      SiP Service calls
-    Fast     3      OEM Service calls
-    Fast     4      Standard Service calls
-    Fast    5-47    Reserved for future use
-    Fast   48-49    Trusted Application calls
-    Fast   50-63    Trusted OS calls
+    Type       OEN     Service
+    Fast        0      ARM Architecture calls
+    Fast        1      CPU Service calls
+    Fast        2      SiP Service calls
+    Fast        3      OEM Service calls
+    Fast        4      Standard Service calls
+    Fast       5-47    Reserved for future use
+    Fast      48-49    Trusted Application calls
+    Fast      50-63    Trusted OS calls
 
-    Std     0- 1    Reserved for existing ARMv7 calls
-    Std     2-63    Trusted OS Standard Calls
+    Yielding   0- 1    Reserved for existing ARMv7 calls
+    Yielding   2-63    Trusted OS Standard Calls
 
 _Table 1: Service types and their corresponding Owning Entity Numbers_
 
@@ -115,7 +115,7 @@ initialization and call handler functions.
 *   `_start` and `_end` values must be based on the `OEN_*` values defined in
     [`smcc.h`]
 
-*   `_type` must be one of `SMC_TYPE_FAST` or `SMC_TYPE_STD`
+*   `_type` must be one of `SMC_TYPE_FAST` or `SMC_TYPE_YIELD`
 
 *   `_setup` is the initialization function with the `rt_svc_init` signature:
 
@@ -138,7 +138,7 @@ to ensure that the following conditions are met:
 
 1.  The `_start` OEN is not greater than the `_end` OEN
 2.  The `_end` OEN does not exceed the maximum OEN value (63)
-3.  The `_type` is one of `SMC_TYPE_FAST` or `SMC_TYPE_STD`
+3.  The `_type` is one of `SMC_TYPE_FAST` or `SMC_TYPE_YIELD`
 4.  `_setup` and `_smch` routines have been specified
 
 [`std_svc_setup.c`] provides an example of registering a runtime service: