powerpc: Fix 44x Machine Check handling

This removes the old CONFIG_440A which was a pain for multiplatform kernel and wasn't set properly by default and replaces it with a CPU feature. This makes Machine Check reporting work correctly on my Ebony (440GP) board.

I'm not sure I like this. It introduces another cpu feature flag, that we'll soon run out of if it's used to signify version info per implementation like this.

1) The SET_IVOR could be done from the cpu_setups for 440A instead (i.e. introduce one).

2) Please just move the machine check handlers out to individual ones instead of using the generic one. That way you don't need runtime checks between the two (they don't seem to share much of it as-is anyway).

With the above two changes, you shouldn't need the feature bit any more.

Quoted 7 lines · Olof Johansson

I'm not sure I like this. It introduces another cpu feature flag, that we'll soon run out of if it's used to signify version info per implementation like this.

1) The SET_IVOR could be done from the cpu_setups for 440A instead (i.e. introduce one).

Quoted 5 lines

2) Please just move the machine check handlers out to individual ones instead of using the generic one. That way you don't need runtime checks between the two (they don't seem to share much of it as-is anyway).

With the above two changes, you shouldn't need the feature bit any more.

We can easily make the cpu features bigger ... But ok, I'll have a look at doing it the way you suggest.

Quoted 12 lines · Benjamin Herrenschmidt

Quoted 11 lines · Olof Johansson

I'm not sure I like this. It introduces another cpu feature flag, that we'll soon run out of if it's used to signify version info per implementation like this.

1) The SET_IVOR could be done from the cpu_setups for 440A instead (i.e. introduce one).

2) Please just move the machine check handlers out to individual ones instead of using the generic one. That way you don't need runtime checks between the two (they don't seem to share much of it as-is anyway).

Quoted 4 lines

Quoted 1 line

With the above two changes, you shouldn't need the feature bit any more.

We can easily make the cpu features bigger ... But ok, I'll have a look at doing it the way you suggest.

Note that first, I'd like to figure out if there are other relevant differences with 440A ... arch/ppc didn't list any and diff'ing PDFs is not fun but if people around here know, please speak up

Quoted 23 lines · Benjamin Herrenschmidt

Quoted 20 lines · Benjamin Herrenschmidt

Quoted 7 lines · Olof Johansson

I'm not sure I like this. It introduces another cpu feature flag, that we'll soon run out of if it's used to signify version info per implementation like this.

1) The SET_IVOR could be done from the cpu_setups for 440A instead (i.e. introduce one).

Quoted 8 lines

2) Please just move the machine check handlers out to individual ones
instead of using the generic one. That way you don't need runtime checks
between the two (they don't seem to share much of it as-is anyway).

With the above two changes, you shouldn't need the feature bit any more.

We can easily make the cpu features bigger ... But ok, I'll have a look
at doing it the way you suggest.

Quoted 4 lines

Note that first, I'd like to figure out if there are other relevant differences with 440A ... arch/ppc didn't list any and diff'ing PDFs is
not fun but if people around here know, please speak up

I think it added isel support.

Quoted 4 lines · Benjamin Herrenschmidt

This removes the old CONFIG_440A which was a pain for multiplatform kernel and wasn't set properly by default and replaces it with a CPU feature. This makes Machine Check reporting work correctly on my Ebony (440GP) board.

I'm not sure I like this. It introduces another cpu feature flag, that we'll soon run out of if it's used to signify version info per implementation like this.

1) The SET_IVOR could be done from the cpu_setups for 440A instead (i.e. introduce one).

2) Please just move the machine check handlers out to individual ones instead of using the generic one. That way you don't need runtime checks between the two (they don't seem to share much of it as-is anyway).

Quoted 1 line

2) Please just move the machine check handlers out to individual

ones

Quoted 1 line

instead of using the generic one. That way you don't need runtime

checks

Quoted 1 line

between the two (they don't seem to share much of it as-is anyway).

Anton pinged me about cleaning that up a couple months ago. I have a half-baked patch for it somewhere, but I agree having 4xx set a ppc_md specific handler would be a good idea.

This removes the old CONFIG_440A which was a pain for multiplatform kernel and wasn't set properly by default and replaces it with a CPU feature. This makes Machine Check reporting work correctly on my Ebony (440GP) board.

Signed-off-by Benjamin Herrenschmidt <[email protected]>

---

Note: I'm only setting it for 440GX and EPx as the old code did, I haven't checked whether other new 440 chips such as SPe also need that bit set.

arch/powerpc/kernel/cputable.c     |   10 +++++-----
arch/powerpc/kernel/head_44x.S     |   11 ++++++-----
arch/powerpc/kernel/traps.c        |   19 ++++++++-----------
arch/powerpc/platforms/44x/Kconfig |    5 -----
include/asm-powerpc/cputable.h     |    3 ++-
include/asm-powerpc/reg_booke.h    |    2 +-
6 files changed, 22 insertions(+), 28 deletions(-)

include/asm-powerpc/cputable.h extern void do_feature_fixups(unsigned l · line 141

Quoted 12 lines

Index: linux-work/include/asm-powerpc/cputable.h
===================================================================
--- linux-work.orig/include/asm-powerpc/cputable.h 2007-11-16
16:14:29.000000000 +1100
+++ linux-work/include/asm-powerpc/cputable.h 2007-11-16
16:19:35.000000000 +1100

include/asm-powerpc/cputable.h +1 -0

@@ -138,6 +138,7 @@ extern void do_feature_fixups(unsigned l
 #define CPU_FTR_FPU_UNAVAILABLE		ASM_CONST(0x0000000000800000)
 #define CPU_FTR_UNIFIED_ID_CACHE	ASM_CONST(0x0000000001000000)
 #define CPU_FTR_SPE			ASM_CONST(0x0000000002000000)
+#define CPU_FTR_440A			ASM_CONST(0x0000000004000000)

Can we be more specific about what this feature really means.

How about something like CPU_FTR_ENH_MCHCK or something like that.