1. 08 Apr, 2021 1 commit
  2. 09 Oct, 2020 1 commit
    • Jimmy Brisson's avatar
      Don't return error information from console_flush · 831b0e98
      Jimmy Brisson authored
      
      
      And from crash_console_flush.
      
      We ignore the error information return by console_flush in _every_
      place where we call it, and casting the return type to void does not
      work around the MISRA violation that this causes. Instead, we collect
      the error information from the driver (to avoid changing that API), and
      don't return it to the caller.
      
      Change-Id: I1e35afe01764d5c8f0efd04f8949d333ffb688c1
      Signed-off-by: default avatarJimmy Brisson <jimmy.brisson@arm.com>
      831b0e98
  3. 25 Feb, 2020 1 commit
  4. 24 Jan, 2020 1 commit
  5. 01 Aug, 2019 1 commit
    • Julius Werner's avatar
      Switch AARCH32/AARCH64 to __aarch64__ · 402b3cf8
      Julius Werner authored
      
      
      NOTE: AARCH32/AARCH64 macros are now deprecated in favor of __aarch64__.
      
      All common C compilers pre-define the same macros to signal which
      architecture the code is being compiled for: __arm__ for AArch32 (or
      earlier versions) and __aarch64__ for AArch64. There's no need for TF-A
      to define its own custom macros for this. In order to unify code with
      the export headers (which use __aarch64__ to avoid another dependency),
      let's deprecate the AARCH32 and AARCH64 macros and switch the code base
      over to the pre-defined standard macro. (Since it is somewhat
      unintuitive that __arm__ only means AArch32, let's standardize on only
      using __aarch64__.)
      
      Change-Id: Ic77de4b052297d77f38fc95f95f65a8ee70cf200
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      402b3cf8
  6. 24 Jul, 2019 1 commit
    • Julius Werner's avatar
      Use explicit-width data types in AAPCS parameter structs · 9352be88
      Julius Werner authored
      
      
      It's not a good idea to use u_register_t for the members of
      aapcs64_params_t and aapcs32_params_t, since the width of that type
      always depends on the current execution environment. This would cause
      problems if e.g. we used this structure to set up the entry point of an
      AArch32 program from within an AArch64 program. (It doesn't seem like
      any code is doing that today, but it's probably still a good idea to
      write this defensively. Also, it helps with my next patch.)
      
      Change-Id: I12c04a85611f2b6702589f3362bea3e6a7c9f776
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      9352be88
  7. 28 Jun, 2019 1 commit
  8. 01 Feb, 2019 2 commits
  9. 15 Jan, 2019 1 commit
  10. 04 Jan, 2019 1 commit
    • Antonio Nino Diaz's avatar
      Sanitise includes across codebase · 09d40e0e
      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: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      09d40e0e
  11. 10 Dec, 2018 1 commit
  12. 08 Nov, 2018 2 commits
  13. 30 Oct, 2018 1 commit
  14. 10 Oct, 2018 1 commit
  15. 28 Sep, 2018 1 commit
  16. 27 Sep, 2018 1 commit
    • Shawn Guo's avatar
      poplar: fix build error with POPLAR_RECOVERY=1 · d5ed2946
      Shawn Guo authored
      Commit eba1b6b3
      
       ("plat/poplar: migrate to mmc framework") defines
      variable 'info' without !POPLAR_RECOVERY protection, and hence causes
      the following unused variable error with POPLAR_RECOVERY=1 build.
      
      plat/hisilicon/poplar/bl1_plat_setup.c: In function ‘bl1_platform_setup’:
      plat/hisilicon/poplar/bl1_plat_setup.c:95:25: error: unused variable ‘info’ [-Werror=unused-variable]
        struct mmc_device_info info;
                               ^~~~
      
      The patches fixes the build error with POPLAR_RECOVERY=1.
      Signed-off-by: default avatarShawn Guo <shawn.guo@linaro.org>
      d5ed2946
  17. 10 Aug, 2018 1 commit
  18. 20 Jul, 2018 1 commit
  19. 24 Apr, 2018 1 commit
  20. 27 Mar, 2018 1 commit
    • Joel Hutton's avatar
      Clean usage of void pointers to access symbols · 9f85f9e3
      Joel Hutton authored
      
      
      Void pointers have been used to access linker symbols, by declaring an
      extern pointer, then taking the address of it. This limits symbols
      values to aligned pointer values. To remove this restriction an
      IMPORT_SYM macro has been introduced, which declares it as a char
      pointer and casts it to the required type.
      
      Change-Id: I89877fc3b13ed311817bb8ba79d4872b89bfd3b0
      Signed-off-by: default avatarJoel Hutton <Joel.Hutton@Arm.com>
      9f85f9e3
  21. 26 Mar, 2018 1 commit
  22. 27 Feb, 2018 1 commit
  23. 07 Feb, 2018 6 commits
  24. 29 Jan, 2018 1 commit
  25. 22 Jan, 2018 2 commits
  26. 12 Dec, 2017 5 commits
  27. 30 Nov, 2017 1 commit
    • David Cunado's avatar
      Do not enable SVE on pre-v8.2 platforms · 3872fc2d
      David Cunado authored
      
      
      Pre-v8.2 platforms such as the Juno platform does not have
      the Scalable Vector Extensions implemented and so the build
      option ENABLE_SVE is set to zero.
      
      This has a minor performance improvement with no functional
      impact.
      
      Change-Id: Ib072735db7a0247406f8b60e325b7e28b1e04ad1
      Signed-off-by: default avatarDavid Cunado <david.cunado@arm.com>
      3872fc2d
  28. 17 Oct, 2017 1 commit