ppc44x: Remove PVR_440G* and change usages

The following patch changes the usages of PVR_440* into strcmp's with the cpu_name field, and removes the defines altogether. The Ebony portion was briefly tested.

Signed-off-by Tom Rini <[email protected]>

 arch/ppc/platforms/4xx/ebony.c    |   13 ++++---------
 arch/ppc/syslib/ibm440gx_common.c |    7 ++++---
 include/asm-ppc/reg.h             |    6 ------
 3 files changed, 8 insertions(+), 18 deletions(-)

arch/ppc/platforms/4xx/ebony.c +4 -9

@@ -97,15 +97,10 @@
 	 * on Rev. C silicon then errata forces us to
 	 * use the internal clock.
 	 */
-	switch (PVR_REV(mfspr(PVR))) {
-		case PVR_REV(PVR_440GP_RB):
-			freq = EBONY_440GP_RB_SYSCLK;
-			break;
-		case PVR_REV(PVR_440GP_RC1):
-		default:
-			freq = EBONY_440GP_RC_SYSCLK;
-			break;
-	}
+	if (strcmp(cur_cpu_spec[0]->cpu_name, "440GP Rev. B") == 0)
+		freq = EBONY_440GP_RB_SYSCLK;
+	else
+		freq = EBONY_440GP_RC_SYSCLK;
 
 	ibm44x_calibrate_decr(freq);
 }

arch/ppc/syslib/ibm440gx_common.c line 227

Quoted 7 lines

arch/ppc/syslib/ibm440gx_common.c +4 -3

-	u32 pvr = mfspr(PVR);
-	if (pvr == PVR_440GX_RA || pvr == PVR_440GX_RB ||
-	    (pvr == PVR_440GX_RC && p->cpu > 667000000))
+	if (strcmp(cur_cpu_spec[0]->cpu_name, "440GX Rev. A") == 0 ||
+			strcmp(cur_cpu_spec[0]->cpu_name, "440GX Rev. B") == 0
+			|| (strcmp(cur_cpu_spec[0]->cpu_name, "440GX Rev. C")
+				== 0 && p->cpu > 667000000))

While I applaud Tom's quest to eliminate _useless_ PVR defines I think this change looks strange.

It substitutes simple and clear (for those who are reading this code) check to something more involved without good reason, IMHO.

Also, it adds additional "point of failure" making this code more fragile. We never used those CPU ID strings anywhere in the kernel code before, people are used to the fact that they don't matter much (maybe only for user-mode) and it's possible that during some future "cleanup" code will break. One could say that we aren't allowed to change such strings because something in user-mode could break, and while I agree with that, I don't think it's good argument to _add_ additional point where code could break.