linux-mips
[Top] [All Lists]

Re: [patch 4/5] SiByte fixes for 2.6.12

To: "Maciej W. Rozycki" <macro@linux-mips.org>
Subject: Re: [patch 4/5] SiByte fixes for 2.6.12
From: Andy Isaacson <adi@hexapodia.org>
Date: Thu, 23 Jun 2005 15:27:09 -0700
Cc: linux-mips@linux-mips.org
In-reply-to: <Pine.LNX.4.61L.0506231601270.17155@blysk.ds.pg.gda.pl>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20050622230151.GA17970@broadcom.com> <Pine.LNX.4.61L.0506231208120.17155@blysk.ds.pg.gda.pl> <20050623144926.GA10216@hexapodia.org> <Pine.LNX.4.61L.0506231601270.17155@blysk.ds.pg.gda.pl>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.4.2i
On Thu, Jun 23, 2005 at 04:11:51PM +0100, Maciej W. Rozycki wrote:
> On Thu, 23 Jun 2005, Andy Isaacson wrote:
> > The code looks like it's structured to be able to be compiled with
> > support for multiple CPUs, say, r4k and SB1; using #error would seem to
> > prevent that.
> > 
> > With the code as currently structured, you don't know it's going to be a
> > noop until runtime comes along and cpu_has_4ktlb is true...
> 
>  Well, I've had a look at the code and it's such a mess.  Obviously 
> calling ld_mmu_r4xx0() (or any of the other variants) should not be 
> compiled conditionally and more specific cases, i.e. based on PRId values 
> should take precedence.  I'll see if I can make it better.

I certainly won't argue with a cleanup of arch/mips/mm/cache.c, that
code has annoyed me from first laying eyes on it...

-andy

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