Gitweb: http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=435f8a605d3b56bb96212f4d70b62ecbd0629340 Commit: 435f8a605d3b56bb96212f4d70b62ecbd0629340 Parent: e34efe3b100d0fbdf053128956c3dd0bc68754d6 Author: Linus Torvalds <[EMAIL PROTECTED]> AuthorDate: Fri Feb 2 08:07:42 2007 -0800 Committer: Linus Torvalds <[EMAIL PROTECTED]> CommitDate: Fri Feb 2 08:07:42 2007 -0800
Revert "[PATCH] fix typo in geode_configre()@cyrix.c" This reverts commit e4f0ae0ea63caceff37a13f281a72652b7ea71ba. It's not wrong, but it's not right either, and everybody seems to agree that the right fix is probably to do the ccr3 write after the ccr4 one (and that we also should clean it up a bit). And after that we need to really validate that all the bits that we write to ccr4 actually do work. The old 2.6.19 code was insane, and basically didn't change ccr4 at all (even though it certainly looks like it was the *intent* to do so). So let's revert the change that may fix things, just because it's not what was actually ever tested when the code was written, even if it _was_ the intent. There's a discussion on http://lkml.org/lkml/2007/1/9/63 that was started by the patch that now gets reverted, and that discussion may well contain the proper long-term fix. Suggested-by: Adrian Bunk <[EMAIL PROTECTED]> Acked-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> --- arch/i386/kernel/cpu/cyrix.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/i386/kernel/cpu/cyrix.c b/arch/i386/kernel/cpu/cyrix.c index abcff92..c0c3b59 100644 --- a/arch/i386/kernel/cpu/cyrix.c +++ b/arch/i386/kernel/cpu/cyrix.c @@ -173,7 +173,7 @@ static void __cpuinit geode_configure(void) ccr4 = getCx86(CX86_CCR4); ccr4 |= 0x38; /* FPU fast, DTE cache, Mem bypass */ - setCx86(CX86_CCR4, ccr4); + setCx86(CX86_CCR3, ccr3); set_cx86_memwb(); set_cx86_reorder(); - To unsubscribe from this list: send the line "unsubscribe git-commits-head" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html