Hi Paul,
Well, run-time patching might be an alternative to get the best of bothFAOD <cpu-feature-overrides.h> is not a hack, but an optimisation measureFair enough. Bloat-o-meter reports about ~100 KiB saved when that file is
so that features known to be hardwired for a given machine/CPU do not have
to be dynamically queried every time referred. In some cases that results
in large portions of code being optimised away by the compiler as well.
present. But we can't use it in a generic kernel, unfortunately.
worlds, but someone would have to reimplement our feature selection system
to use it.
I wasn't aware of that. In that case it has been a design abuse whichThe hardcoded value for a feature defined in <cpu-feature-overrides.h>In theory yes, in practice the CPU detection code is lagging behind...
always has to be the same as one in the corresponding bit of the `options'
member of `struct cpuinfo_mips', in this case MIPS_CPU_TLBINV.
has been missed by the maintainer when accepting patches. It used to be
the case that run-time detection was accurate and overrides were rather
lazily added.
Also I note Ingenic must have had a CPU erratum if our `decode_configs'
doesn't just work, as the interpretation of CP0.Config[5:0] registers has
been architectural and mandatory, and that for a reason. It's only legacy
MIPS I-IV processors that should require special attention here.
Maciej