[PATCH] kernel/process.c: R3000 setup for kernel_thread()

[PATCH] kernel/process.c: R3000 setup for kernel_thread()

[Maciej W. Rozycki]

 Match the R4000 semantics for the initial state of interrupt/kernel
status register flags for the R3000 in kernel_thread().

Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
---
 The R4000 variation preserves the interrupt/kernel status flags; the 
R3000 assumes a certain state.  It may not matter, at least at the current 
state of the code, but for consistency I think the R3000 variation should 
do the same as the R4000 one, first for purity and second because there is 
less maintenance force available for the R3000 and any discrepancy between 
the two variations means a greater chance for subtle bugs.  The 
performance hit is negligible.

 Tested at the runtime.

 Please consider.

  Maciej

patch-mips-2.6.23-rc5-20070904-r3000-process-1
diff -up --recursive --new-file linux-mips-2.6.23-rc5-20070904.macro/arch/mips/kernel/process.c linux-mips-2.6.23-rc5-20070904/arch/mips/kernel/process.c
--- linux-mips-2.6.23-rc5-20070904.macro/arch/mips/kernel/process.c	2007-09-04 04:55:19.000000000 +0000
+++ linux-mips-2.6.23-rc5-20070904/arch/mips/kernel/process.c	2007-09-18 15:43:16.000000000 +0000
@@ -231,8 +231,8 @@ long kernel_thread(int (*fn)(void *), vo
 	regs.cp0_epc = (unsigned long) kernel_thread_helper;
 	regs.cp0_status = read_c0_status();
 #if defined(CONFIG_CPU_R3000) || defined(CONFIG_CPU_TX39XX)
-	regs.cp0_status &= ~(ST0_KUP | ST0_IEC);
-	regs.cp0_status |= ST0_IEP;
+	regs.cp0_status = (regs.cp0_status & ~(ST0_KUP | ST0_IEP | ST0_IEC)) |
+			  ((regs.cp0_status & (ST0_KUC | ST0_IEC)) << 2);
 #else
 	regs.cp0_status |= ST0_EXL;
 #endif

Re: [PATCH] kernel/process.c: R3000 setup for kernel_thread()

[Ralf Baechle]

On Tue, Sep 18, 2007 at 06:49:08PM +0100, Maciej W. Rozycki wrote:

>  Match the R4000 semantics for the initial state of interrupt/kernel
> status register flags for the R3000 in kernel_thread().
> 
> Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
> ---
>  The R4000 variation preserves the interrupt/kernel status flags; the 
> R3000 assumes a certain state.  It may not matter, at least at the current 
> state of the code, but for consistency I think the R3000 variation should 
> do the same as the R4000 one, first for purity and second because there is 
> less maintenance force available for the R3000 and any discrepancy between 
> the two variations means a greater chance for subtle bugs.  The 
> performance hit is negligible.

Since it doesn't seem to bite I queued this for 2.6.24.  Thanks,

  Ralf