[Top] [All Lists]

Re: [PATCH] MIPS: Add support for the MIPS32 4Kc family I/D caches.

To: Ralf Baechle <>
Subject: Re: [PATCH] MIPS: Add support for the MIPS32 4Kc family I/D caches.
From: "Maciej W. Rozycki" <>
Date: Tue, 29 May 2012 11:48:27 +0100 (BST)
Cc: "Steven J. Hill" <>,, Douglas Leung <>
In-reply-to: <>
List-archive: <>
List-help: <>
List-id: linux-mips <>
List-owner: <>
List-post: <>
List-software: Ecartis version 1.0.0
List-subscribe: <>
List-unsubscribe: <>
References: <> <> <> <>
User-agent: Alpine 2.00 (LFD 1167 2008-08-23)
On Tue, 29 May 2012, Ralf Baechle wrote:

> >  It was not a bug, or at least not an active one.  The new encoding was 
> > only added with revision 3 of the architecture or thereabouts, so not so 
> > long ago.  It used to be reserved previously, so we just handled it 
> > arbitrarily (though perhaps we should have panicked instead on 
> > encountering it indeed).
> The patch at least was applicable to all 2.4 and 2.6 branches ...

 That you could have backported the change to old code doesn't mean the 
code was buggy at the time it was written.  It only became buggy as the 
environment changed.

 I have now double-checked my resources and according to the revision 
history of the architecture spec, the new encoding was only added with 
revision 3.00 of the spec: "Added encoding (0x7) for 32 sets for one cache 
way." that was dated March 2010 (my copy of revision 2.80 certainly does 
not list it and 3.05 does; I don't have the exact 3.00 revision 
unfortunately).  Up until then 64 was the smallest number of ways 
supported (and 7 was listed as a reserved encoding, just as when the code 
you've just patched was written).

 Linux 2.6.33 was released in February 2010 and 2.6.34 in May.  So 
anything before 2.6.34 was never buggy, and certainly none of 2.4 kernels.  

 You now have the answer to your concern as to how long we survived with 
this bug too: 2 years and 2 months.  Not too bad. ;)

 I still wonder why the 4Kc is mentioned in this context, this is a MIPS32 
revision 1 architecture chip, so revision 3 cannot apply to it anyway, 


<Prev in Thread] Current Thread [Next in Thread>