| #
72e8f245 |
| 08-Aug-2023 |
Manish V Badarkhe <manish.badarkhe@arm.com> |
Merge "chore: update to use Arm word across TF-A" into integration
|
| #
4c700c15 |
| 01-Aug-2023 |
Govindraj Raja <govindraj.raja@arm.com> |
chore: update to use Arm word across TF-A
Align entire TF-A to use Arm in copyright header.
Change-Id: Ief9992169efdab61d0da6bd8c5180de7a4bc2244 Signed-off-by: Govindraj Raja <govindraj.raja@arm.co
chore: update to use Arm word across TF-A
Align entire TF-A to use Arm in copyright header.
Change-Id: Ief9992169efdab61d0da6bd8c5180de7a4bc2244 Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
show more ...
|
| #
562abecf |
| 28-Feb-2020 |
Sandrine Bailleux <sandrine.bailleux@arm.com> |
Merge "fconf: Fix misra issues" into integration
|
| #
845db722 |
| 24-Feb-2020 |
Louis Mayencourt <louis.mayencourt@arm.com> |
fconf: Fix misra issues
MISRA C-2012 Rule 20.7: Macro parameter expands into an expression without being wrapped by parentheses.
MISRA C-2012 Rule 12.1: Missing explicit parentheses on sub-expressi
fconf: Fix misra issues
MISRA C-2012 Rule 20.7: Macro parameter expands into an expression without being wrapped by parentheses.
MISRA C-2012 Rule 12.1: Missing explicit parentheses on sub-expression.
MISRA C-2012 Rule 18.4: Essential type of the left hand operand is not the same as that of the right operand.
Include does not provide any needed symbols.
Change-Id: Ie1c6451cfbc8f519146c28b2cf15c50b1f36adc8 Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>
show more ...
|
| #
9a207532 |
| 04-Jan-2019 |
Antonio Niño Díaz <antonio.ninodiaz@arm.com> |
Merge pull request #1726 from antonio-nino-diaz-arm/an/includes
Sanitise includes across codebase
|
| #
09d40e0e |
| 14-Dec-2018 |
Antonio Nino Diaz <antonio.ninodiaz@arm.com> |
Sanitise includes across codebase
Enforce full include path for includes. Deprecate old paths.
The following folders inside include/lib have been left unchanged:
- include/lib/cpus/${ARCH} - inclu
Sanitise includes across codebase
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: e0ea0928d5b7 ("Fix gpio includes of mt8173 platform to avoid collision."). More recently, this patch has had similar problems: 46f9b2c3a282 ("drivers: add tzc380 support").
This problem was introduced in commit 4ecca33988b9 ("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>
show more ...
|
| #
bd8c4016 |
| 12-Oct-2018 |
Dimitris Papastamos <dimitris.papastamos@arm.com> |
Merge pull request #1627 from sandrine-bailleux-arm/sb/object-pool-allocator
Introduce object pool allocator
|
| #
9cc4651c |
| 01-Jun-2018 |
Sandrine Bailleux <sandrine.bailleux@arm.com> |
Introduce object pool allocator
The object pool allocator provides a simplistic interface to manage allocation in a fixed-size static array. The caller creates a static "object pool" out of such an
Introduce object pool allocator
The object pool allocator provides a simplistic interface to manage allocation in a fixed-size static array. The caller creates a static "object pool" out of such an array and may then call pool_alloc() to get the next available object within the pool. There is also a variant to get multiple consecutive objects: pool_alloc_n().
Note that this interface does not provide any way to free the objects afterwards. This is by design and it is not a limitation. We do not want to introduce complexity induced by memory freeing, such as use-after-free bugs, memory fragmentation and so on.
Change-Id: Iefc2e153767851fbde5841a295f92ae48adda71f Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
show more ...
|