Searched hist:"9352 be88033900f89aa50dfbb13a13d40d698a9e" (Results 1 – 2 of 2) sorted by relevance
| /rk3399_ARM-atf/include/common/ |
| H A D | ep_info.h | 9352be88033900f89aa50dfbb13a13d40d698a9e Wed Jul 24 03:00:13 UTC 2019 Julius Werner <jwerner@chromium.org> Use explicit-width data types in AAPCS parameter structs
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: Julius Werner <jwerner@chromium.org>
|
| /rk3399_ARM-atf/plat/hisilicon/poplar/ |
| H A D | bl31_plat_setup.c | 9352be88033900f89aa50dfbb13a13d40d698a9e Wed Jul 24 03:00:13 UTC 2019 Julius Werner <jwerner@chromium.org> Use explicit-width data types in AAPCS parameter structs
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: Julius Werner <jwerner@chromium.org>
|