linux-mips
[Top] [All Lists]

Re: [resend] 2.4: Support R4000 as a distinct CPU type

To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Subject: Re: [resend] 2.4: Support R4000 as a distinct CPU type
From: Ralf Baechle <ralf@linux-mips.org>
Date: Wed, 2 Oct 2002 15:47:53 +0200
Cc: linux-mips@linux-mips.org
In-reply-to: <Pine.GSO.3.96.1021001163617.13606J-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Tue, Oct 01, 2002 at 06:17:11PM +0200
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <Pine.GSO.3.96.1021001163617.13606J-100000@delta.ds2.pg.gda.pl>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.2.5.1i
On Tue, Oct 01, 2002 at 06:17:11PM +0200, Maciej W. Rozycki wrote:

>  Here is a new version that takes your recent mips64 cache code rearrange
> into account.  OK to apply?

I'm not sure if that's really a good idea.  Technically it's ok but I expect
users of the R4000 to missconfigure their kernels.  So I wonder if it might
be more appropriate to have just automatically enabled this workaround for
systems that are affected?  If we keep it user-selectable then we at least
want a safety check somewhere in the startup code telling users to rebuild
their code with the workaround enabled.

Having this workaround enabled by default would also ensure Linux
distributions ship working code - you don't want users having to recompile
their whole distribution ...

>  BTW, how about renaming r5k-sc.c to sc-r5k.c for consistency?

Yes.  Though there's a bit of confusion hidden there - the Indy SC code
is named ip22-sc.c - but that at least in a different directory.

  Ralf

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