Hi James,
> diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c
> index a6ce1db191aa..c4795568c1f2 100644
> --- a/arch/mips/kernel/cpu-probe.c
> +++ b/arch/mips/kernel/cpu-probe.c
> @@ -858,6 +858,41 @@ static void decode_configs(struct cpuinfo_mips *c)
> if (ok)
> ok = decode_config5(c);
>
> + /* Probe the EBase.WG bit */
> + if (cpu_has_mips_r2_r6) {
> + u64 ebase;
> + unsigned int status;
> +
> + /* {read,write}_c0_ebase_64() may be UNDEFINED prior to r6 */
> + ebase = cpu_has_mips64r6 ? read_c0_ebase_64()
> + : (s32)read_c0_ebase();
> + if (ebase & MIPS_EBASE_WG) {
> + /* WG bit already set, we can avoid the clumsy probe */
> + c->options |= MIPS_CPU_EBASE_WG;
You may additionally check for bits 31:30 != 0b10 as a satisfactory
condition for WG's presence, under the assumption that 0b10 is not very
likely if a truly 64-bit exception base has been loaded. E.g.:
#define MIPS_EBASE_SEG_MASK (3 << 30)
s32 mask;
/* Avoid the clumsy probe if contents indicate 64 bits. */
mask = MIPS_EBASE_SEG_MASK | MIPS_CPU_EBASE_WG;
if ((ebase & mask) != CKSEG0) {
c->options |= MIPS_CPU_EBASE_WG;
or so.
NB I find the current description of EBase questionable to say the least.
This statement:
"The addition of the base address and the exception offset is performed
inhibiting a carry between bits 29 and 30 of the final exception address."
is repeated twice as if a leftover from the days before WG support. I
think this needs to be clarified in the case of bits 31:30 != 0b10. Also
I think the effect on the Cache Error exception vector in this case has to
be better specified. Can you please raise it with the architecture
documentation maintainers?
Also the description of DMFC0 is inconsistent with the corresponding
pseudo code. As from r6.04 of the instruction set document the pseudo
code has been updated to take into account the R6 semantics for 32-bit
registers you rely on here, however the description still claims such
operation is UNDEFINED. Can you please raise it with the architecture
documentation maintainers as well?
Maciej
