| 553c24c3 | 07-Jul-2025 |
Boyan Karatotev <boyan.karatotev@arm.com> |
feat(cpufeat): enable FEAT_RAS for FEAT_STATE_CHECKED again
FEAT_RAS was originally converted to FEAT_STATE_CHECKED in 6503ff291.
However, the ability to use it was removed with 970a4a8d8 by simply
feat(cpufeat): enable FEAT_RAS for FEAT_STATE_CHECKED again
FEAT_RAS was originally converted to FEAT_STATE_CHECKED in 6503ff291.
However, the ability to use it was removed with 970a4a8d8 by 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>
show more ...
|
| f185a542 | 29-Sep-2025 |
Boyan Karatotev <boyan.karatotev@arm.com> |
fix(fvp): do not unregister the console on system suspend
On PSCI SYSTEM_SUSPEND, Arm platforms will call
arm_system_pwr_domain_save() which will call arm_console_runtime_end().
Usually (eg CSS), th
fix(fvp): do not unregister the console on system suspend
On PSCI SYSTEM_SUSPEND, Arm platforms will call
arm_system_pwr_domain_save() which will call arm_console_runtime_end().
Usually (eg CSS), that's just a flush, but on FVP that also unregisters
the console. On HW_ASSISTED_COHERENCY=0 builds, this has the potential
to break and prevent any EL3 output after a SYSTEM_SUSPEND.
This happens because the calls to
console_unregister()/console_register() will overwrite the value of the
console_list variable in drivers/console/multi_console.c. They are
only called on a system level suspend. The bug happens when the core
wakes up. The console will be registered again as part of the
pwr_domain_suspend_finish() call. However, this call happens before the
data caches have been enabled in psci_do_pwrup_cache_maintenance(). As a
result, the write to console_list will not be reflected in the L2 cache
and other cores will not be able to read the new value.
The fix is to not unregister the console like other Arm platforms -
we don't need to reinitialise the console so there's nothing to do.
A nice side effect is that arm_console_runtime_end() no longer needs to
be weak.
Change-Id: Ibbdd4b22bad0d8f1dbd63c60ee0294d889a349a4
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
show more ...
|