Re: [PATCH] ppc44x: Remove PVR_440G* and change usages

[Eugene Surovegin <ebs@ebshome.net>]

On Mon, Mar 21, 2005 at 08:27:29AM -0700, Tom Rini wrote:
> 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 <trini@kernel.crashing.org>
> 
>  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(-)
> --- 1.11/arch/ppc/platforms/4xx/ebony.c	2005-03-04 23:41:48 -07:00
> +++ edited/arch/ppc/platforms/4xx/ebony.c	2005-03-08 15:22:19 -07:00
> @@ -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);
>  }
> --- 1.3/arch/ppc/syslib/ibm440gx_common.c	2004-11-07 19:08:31 -07:00
> +++ edited/arch/ppc/syslib/ibm440gx_common.c	2005-03-21 08:20:17 -07:00
> @@ -221,9 +221,10 @@
>  	/* Disable L2C on rev.A, rev.B and 800MHz version of rev.C,
>  	   enable it on all other revisions
>  	 */
> -	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.

--
Eugene