mirror of
https://github.com/ARM-software/arm-trusted-firmware.git
synced 2026-07-05 07:08:40 +00:00
Boyan Karatotev
553c24c3ad
FEAT_RAS was originally converted to FEAT_STATE_CHECKED in6503ff291. However, the ability to use it was removed with970a4a8d8by simply saying it impacts execution at EL3. That's true, but FEAT_STATE_CHECKED can still be allowed by being a bit clever about it. First, the remainder of common code can be converted to use the is_feat_ras_supported() helper instead of the `#if FEATURE` pattern. There are no corner cases to consider there. The feature is either present (and appropriate action must be taken) or the feature is not (so we can skip RAS code). A conscious choice is taken to check the RAS code in synchronize_errors despite it being in a hot path. Any fixed platform that seeks to be performant should be setting features to 0 or 1. Then, the SCTLR_EL3.IESB bit is always set if ENABLE_FEAT_RAS != 0 since we expect FEAT_IESB to be present if FEAT_RAS is (despite the architecture not guaranteeing it). If FEAT_RAS isn't present then we don't particularly care about the status of FEAT_IESB. Second, platforms that don't set ENABLE_FEAT_RAS must continue to work. This is true out of the box with the is_feat_xyz_supported() helpers, as they make sure to fully disable code within them. Third, platforms that do set ENABLE_FEAT_RAS=1 must continue to work. This is also true out of the box and no logical change is undertaken in common code. Finally, ENABLE_FEAT_RAS is set to 2 on FVP. Having RAS implies that the whole handling machinery will be built-in and registered as appropriate. However, when RAS is built-in but not present in hardware, these registrations can still happen, they will only never be invoked at runtime. Change-Id: I949e648601dc0951ef9c2b217f34136b6ea4b3dc Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>