[PATCH] rtas_extended_busy_delay_time() fix

[John Rose]

The rtas_extended_busy_delay_time() function does not calculate the expected
number of milliseconds given an RTAS return code.  Julie DeWandel of Redhat
pointed out this bug and solution.  The comment above the function says:

/* Given an RTAS status code of 990n compute the hinted delay of 10^n
 * (last digit) milliseconds.  For now we bound at n=5 (100 secs).
 */

This matches the RPA description of what should happen, but the code doesn't do
this.  The calculation is a bit hard to follow, and contains a magic number
with 1 too many zeroes.  As a result, it calculates the following:

rtas_extended_busy_delay_time(9900) = 0
rtas_extended_busy_delay_time(9901) = 1
rtas_extended_busy_delay_time(9902) = 10
rtas_extended_busy_delay_time(9903) = 100
rtas_extended_busy_delay_time(9904) = 1000
rtas_extended_busy_delay_time(9905) = 10000

The fix as proposed by Julie makes the calculation more obvious, and fixes the
error.  Comments welcome.

Thanks-
John

diff -Nru a/arch/ppc64/kernel/rtas.c b/arch/ppc64/kernel/rtas.c
--- a/arch/ppc64/kernel/rtas.c	Tue Jan  6 15:21:46 2004
+++ b/arch/ppc64/kernel/rtas.c	Tue Jan  6 15:21:46 2004
@@ -197,9 +197,10 @@
 		order = 5;	/* bound */

 	/* Use microseconds for reasonable accuracy */
-	for (ms = 1000; order > 0; order--)
-		ms = ms * 10;
-	return ms / (1000000/HZ); /* round down is fine */
+	for (ms=1; order > 0; order--)
+		ms *= 10;
+
+	return ms;
 }

 int


** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/