arm-trusted-firmware/include/export
Jimmy Brisson d7b5f40823 Increase type widths to satisfy width requirements
Usually, C has no problem up-converting types to larger bit sizes. MISRA
rule 10.7 requires that you not do this, or be very explicit about this.
This resolves the following required rule:

    bl1/aarch64/bl1_context_mgmt.c:81:[MISRA C-2012 Rule 10.7 (required)]<None>
    The width of the composite expression "0U | ((mode & 3U) << 2U) | 1U |
    0x3c0U" (32 bits) is less that the right hand operand
    "18446744073709547519ULL" (64 bits).

This also resolves MISRA defects such as:

    bl2/aarch64/bl2arch_setup.c:18:[MISRA C-2012 Rule 12.2 (required)]
    In the expression "3U << 20", shifting more than 7 bits, the number
    of bits in the essential type of the left expression, "3U", is
    not allowed.

Further, MISRA requires that all shifts don't overflow. The definition of
PAGE_SIZE was (1U << 12), and 1U is 8 bits. This caused about 50 issues.
This fixes the violation by changing the definition to 1UL << 12. Since
this uses 32bits, it should not create any issues for aarch32.

This patch also contains a fix for a build failure in the sun50i_a64
platform. Specifically, these misra fixes removed a single and
instruction,

    92407e73        and     x19, x19, #0xffffffff

from the cm_setup_context function caused a relocation in
psci_cpus_on_start to require a linker-generated stub. This increased the
size of the .text section and caused an alignment later on to go over a
page boundary and round up to the end of RAM before placing the .data
section. This sectionn is of non-zero size and therefore causes a link
error.

The fix included in this reorders the functions during link time
without changing their ording with respect to alignment.

Change-Id: I76b4b662c3d262296728a8b9aab7a33b02087f16
Signed-off-by: Jimmy Brisson <jimmy.brisson@arm.com>
2020-10-12 10:55:03 -05:00
..
common Increase type widths to satisfy width requirements 2020-10-12 10:55:03 -05:00
drivers Factor out cross-BL API into export headers suitable for 3rd party code 2019-07-23 20:25:34 -07:00
lib Unify type of "cpu_idx" across PSCI module. 2020-01-10 17:11:51 +00:00
plat mediatek: mt8183: pass platform parameters 2019-09-10 11:25:29 +08:00
README Factor out cross-BL API into export headers suitable for 3rd party code 2019-07-23 20:25:34 -07:00

README

All headers under include/export/ are export headers that are intended for
inclusion in third-party code which needs to interact with TF-A data structures
or interfaces. They must follow these special rules:

- Header guards should start with ARM_TRUSTED_FIRMWARE_ to reduce clash risk.

- All definitions should be sufficiently namespaced (e.g. with BL_ or TF_) to
  make name clashes with third-party code unlikely.

- They must not #include any headers except other export headers, and those
  includes must use relative paths with "../double_quotes.h" notation.

- They must not rely on any type definitions other that <stdint.h> types defined
  in the ISO C standard (i.e. uint64_t is fine, but not u_register_t). They
  should still not #include <stdint.h>. Instead, wrapper headers including
  export headers need to ensure that they #include <stdint.h> earlier in their
  include order.

- They must not rely on any macro definitions other than those which are
  pre-defined by all common compilers (e.g. __ASSEMBLER__ or __aarch64__).

- They must only contain macro, type and structure definitions, no prototypes.

- They should avoid using integer types with architecture-dependent widths
  (e.g. long, uintptr_t, pointer types) where possible. (Some existing export
  headers are violating this for now.)

- Their names should always end in "_exp.h".

- Normal TF-A code should never include export headers directly. Instead, it
  should include a wrapper header that ensures the export header is included in
  the right manner. (The wrapper header for include/export/x/y/z_exp.h should
  normally be placed at include/x/y/z.h.)