- 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>
-
- 04 Sep, 2018 1 commit
-
-
Bryan O'Donoghue authored
This patch adds snvs.c with a imx_snvs_init() function. imx_snvs_init() sets up permissions of the RTC via the SNVS HPCOMR. During previous work with OPTEE on the i.MX7 part we discovered that prior to switching from secure-world to normal-world it is required to apply more permissive permissions than are defaulted to in order for Linux to be able to access the RTC and CAAM functionality in general. This patch pertains to fixing the RTC permissions by way of the HPCOMR.NPSWA_EN bit. Once set non-privileged code aka Linux-kernel code has permissions to access the SNVS where the RTC resides. Perform that permissions fix in imx_snvs_init() now, with a later patch making the call from our platform setup code. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
-