MIPS: Honor L2 bypass bit

On many of the newer MIPS32 cores, CP0 CONFIG2 bit 12 (L2B) indicates that the L2 cache is disabled and therefore Linux should not attempt to use it.

---
 arch/mips/mm/sc-mips.c |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

index 5ab5fa8..f2e2886 100644
@@ -79,6 +79,17 @@ static inline int __init mips_sc_probe(void)
 		return 0;
 
 	config2 = read_c0_config2();
+
+	/* Check the bypass bit (L2B) */
+	switch (c->cputype) {
+	case CPU_34K:
+	case CPU_74K:
+	case CPU_1004K:
+	case CPU_BMIPS5000:
+		if (config2 & (1 << 12))
+			return 0;
+	}
+
 	tmp = (config2 >> 4) & 0x0f;
 	if (0 < tmp && tmp <= 7)
 		c->scache.linesz = 2 << tmp;

1.7.0.4

I did a bit of research in the meantime. Turns out that some MIPS customers are using their own L2 cache controller. That means a simple check by the CPU PrID is not sufficient and we will need some sort of platform-specific probe, sigh.

I've moved all the code your patch adds to a separate function and added a comment so at least people working on platforms with different L2 conntrollers will have a small chance of figuring out what mine blew up under their feet.

Ralf

FWIW, I did check the software user's manual for each of the four processors in the list and verified that L2B is at CONFIG2 bit 12. It would be very rude for an L2 designer to redefine those bits in defiance of the SUM, no?

I also rechecked 24KE just now, and found that L2B is defined in the latest rev of the SUM, but in my local copy (Revision 01.02) bit 12 is the MSB of SS instead. Hmmm.

To err is human -- people do all kinds of weird stuff, not necessarily on
purpose. I think it should be safe to assume the bit is used properly until proved otherwise.

Clearly a documentation bug -- notice how the width of the field
disagress with the bit indices quoted.

Maciej