Silicon Errata and Software Workarounds¶

Author: Will Deacon <will.deacon@arm.com>

Date : 27 November 2015

It is an unfortunate fact of life that hardware is often produced withso-called “errata”, which can cause it to deviate from the architectureunder specific circumstances. For hardware produced by ARM, theseerrata are broadly classified into the following categories:

Category A	A critical error without a viable workaround.
Category B	A significant or critical error with an acceptableworkaround.
Category C	A minor error that is not expected to occur under normaloperation.

For more information, consult one of the “Software Developers ErrataNotice” documents available on infocenter.arm.com (registrationrequired).

As far as Linux is concerned, Category B errata may require some specialtreatment in the operating system. For example, avoiding a particularsequence of code, or configuring the processor in a particular way. Aless common situation may require similar actions in order to declassifya Category A erratum into a Category C erratum. These are collectivelyknown as “software workarounds” and are only required in the minority ofcases (e.g. those cases that both require a non-secure workaroundandcan be triggered by Linux).

For software workarounds that may adversely impact systems unaffected bythe erratum in question, a Kconfig entry is added under “KernelFeatures” -> “ARM errata workarounds via the alternatives framework”.These are enabled by default and patched in at runtime when an affectedCPU is detected. For less-intrusive workarounds, a Kconfig option is notavailable and the code is structured (preferably with a comment) in sucha way that the erratum will not be hit.

This approach can make it slightly onerous to determine exactly whicherrata are worked around in an arbitrary kernel source tree, so thisfile acts as a registry of software workarounds in the Linux Kernel andwill be updated when new workarounds are committed and backported tostable kernels.