- 08 Feb, 2019 1 commit
-
-
Antonio Nino Diaz authored
Instead of having a custom implementation of setjmp() and longjmp() it is better to follow the C standard. The comments in setjmp.h are no longer needed as there are no deviations from the expected one, so they have been removed. All SDEI code that relied on them has been fixed to use the new function prototypes and structs. Change-Id: I6cd2e21cb5a5bcf81ba12283f2e4c067bd5172ca Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 15 Jan, 2019 1 commit
-
-
Paul Beesley authored
Corrects typos in core code, documentation files, drivers, Arm platforms and services. None of the corrections affect code; changes are limited to comments and other documentation. Change-Id: I5c1027b06ef149864f315ccc0ea473e2a16bfd1d Signed-off-by: Paul Beesley <paul.beesley@arm.com>
-
- 04 Jan, 2019 1 commit
-
-
Antonio Nino Diaz authored
Enforce full include path for includes. Deprecate old paths. The following folders inside include/lib have been left unchanged: - include/lib/cpus/${ARCH} - include/lib/el3_runtime/${ARCH} The reason for this change is that having a global namespace for includes isn't a good idea. It defeats one of the advantages of having folders and it introduces problems that are sometimes subtle (because you may not know the header you are actually including if there are two of them). For example, this patch had to be created because two headers were called the same way: e0ea0928 ("Fix gpio includes of mt8173 platform to avoid collision."). More recently, this patch has had similar problems: 46f9b2c3 ("drivers: add tzc380 support"). This problem was introduced in commit 4ecca339 ("Move include and source files to logical locations"). At that time, there weren't too many headers so it wasn't a real issue. However, time has shown that this creates problems. Platforms that want to preserve the way they include headers may add the removed paths to PLAT_INCLUDES, but this is discouraged. Change-Id: I39dc53ed98f9e297a5966e723d1936d6ccf2fc8f Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 31 Oct, 2018 1 commit
-
-
Varun Wadekar authored
This patch includes context.h from sdei_private.h to fix the following compilation errors: <snip> In file included from services/std_svc/sdei/sdei_event.c:9:0: services/std_svc/sdei/sdei_private.h: In function 'sdei_client_el': services/std_svc/sdei/sdei_private.h:164:2: error: unknown type name 'cpu_context_t' cpu_context_t *ns_ctx = cm_get_context(NON_SECURE); ^ services/std_svc/sdei/sdei_private.h:165:2: error: unknown type name 'el3_state_t' el3_state_t *el3_ctx = get_el3state_ctx(ns_ctx); ^ services/std_svc/sdei/sdei_private.h:165:2: error: implicit declaration of function 'get_el3state_ctx' [-Werror=implicit-function-declaration] services/std_svc/sdei/sdei_private.h:165:25: error: initialization makes pointer from integer without a cast [-Werror] el3_state_t *el3_ctx = get_el3state_ctx(ns_ctx); ^ services/std_svc/sdei/sdei_private.h:167:2: error: implicit declaration of function 'read_ctx_reg' [-Werror=implicit-function-declaration] return ((read_ctx_reg(el3_ctx, CTX_SCR_EL3) & SCR_HCE_BIT) != 0U) ? ^ services/std_svc/sdei/sdei_private.h:167:33: error: 'CTX_SCR_EL3' undeclared (first use in this function) return ((read_ctx_reg(el3_ctx, CTX_SCR_EL3) & SCR_HCE_BIT) != 0U) ? ^ services/std_svc/sdei/sdei_private.h:167:33: note: each undeclared identifier is reported only once for each function it appears in cc1: all warnings being treated as errors <snip> Change-Id: Id0cad56accf81b19cb0d301784f3f086dd052722 Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
-
- 22 Aug, 2018 1 commit
-
-
Antonio Nino Diaz authored
The codebase was using non-standard headers. It is needed to replace them by the correct ones so that we can use the new libc headers. Change-Id: I530f71d9510cb036e69fe79823c8230afe890b9d Acked-by: Sumit Garg <sumit.garg@linaro.org> Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 20 Aug, 2018 1 commit
-
-
Jeenu Viswambharan authored
These changes address most of the required MISRA rules. In the process, some from generic code is also fixed. No functional changes. Change-Id: I6235a355e006f0b1c7c1c4d811b3964a64d0434f Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
- 22 Jun, 2018 1 commit
-
-
Jeenu Viswambharan authored
commit 2ccfcb2e ("SDEI: Determine client EL from NS context's SCR_EL3") intended to read from SCR_EL3, but wrongly read from SPSR_EL3 instead. This patch fixes that. Change-Id: I8ffea39cc98ef59cb8e7a4c6ef4cb12011c58536 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
- 21 Jun, 2018 3 commits
-
-
Jeenu Viswambharan authored
SDEI event dispatches currently only sets up the Non-secure context before returning to the caller. The actual dispatch only happens upon exiting EL3 next time. However, for various error handling scenarios, it's beneficial to have the dispatch happen synchronously. I.e. when receiving SDEI interrupt, or for a successful sdei_dispatch_event() call, the event handler is executed; and upon the event completion, dispatcher execution resumes after the point of dispatch. The jump primitives introduced in the earlier patch facilitates this feature. With this patch: - SDEI interrupts and calls to sdei_dispatch_event prepares the NS context for event dispatch, then sets a jump point, and immediately exits EL3. This results in the client handler executing in Non-secure. - When the SDEI client completes the dispatched event, the SDEI dispatcher does a longjmp to the jump pointer created earlier. For the caller of the sdei_dispatch_event() in particular, this would appear as if call returned successfully. The dynamic workaround for CVE_2018_3639 is slightly shifted around as part of related minor refactoring. It doesn't affect the workaround functionality. Documentation updated. NOTE: This breaks the semantics of the explicit dispatch API, and any exiting usages should be carefully reviewed. Change-Id: Ib9c876d27ea2af7fb22de49832e55a0da83da3f9 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
Jeenu Viswambharan authored
Currently, the dispatcher reads from SCR_EL3 register directly to determine the EL of SDEI client. This is with the assumption that SCR_EL3 is not modified throughout. However, with RAS work flows, it's possible that SCR_EL3 register contains values corresponding to Secure world, and therefore EL determination can go wrong. To mitigate this, always read the register from the saved Non-secure context. Change-Id: Ic85e4021deb18eb58757f676f9a001174998543a Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
Jeenu Viswambharan authored
The current macros only allow to define dynamic and statically-bound SDEI events. However, there ought be a mechanism to define SDEI events that are explicitly dispatched; i.e., events that are dispatched as a result of a previous secure interrupt or other exception This patch introduces SDEI_EXPLICIT_EVENT() macro to define an explicit event. They must be placed under private mappings. Only the priority flags are allowed to be additionally specified. Documentation updated. Change-Id: I2e12f5571381195d6234c9dfbd5904608ad41db3 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
- 13 Nov, 2017 1 commit
-
-
Jeenu Viswambharan authored
The implementation currently supports only interrupt-based SDEI events, and supports all interfaces as defined by SDEI specification version 1.0 [1]. Introduce the build option SDEI_SUPPORT to include SDEI dispatcher in BL31. Update user guide and porting guide. SDEI documentation to follow. [1] http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf Change-Id: I758b733084e4ea3b27ac77d0259705565842241a Co-authored-by: Yousuf A <yousuf.sait@arm.com> Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-