linux-mips
[Top] [All Lists]

Re: [PATCH] MIPS: DECstation HRT calibration bug fixes

To: "Maciej W. Rozycki" <macro@linux-mips.org>
Subject: Re: [PATCH] MIPS: DECstation HRT calibration bug fixes
From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Date: Tue, 17 Sep 2013 10:41:26 +0200
Cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
In-reply-to: <alpine.LFD.2.03.1309160606110.2176@linux-mips.org>
List-archive: <http://www.linux-mips.org/archives/linux-mips/>
List-help: <mailto:ecartis@linux-mips.org?Subject=help>
List-id: linux-mips <linux-mips.eddie.linux-mips.org>
List-owner: <mailto:ralf@linux-mips.org>
List-post: <mailto:linux-mips@linux-mips.org>
List-software: Ecartis version 1.0.0
List-subscribe: <mailto:ecartis@linux-mips.org?subject=subscribe%20linux-mips>
List-unsubscribe: <mailto:ecartis@linux-mips.org?subject=unsubscribe%20linux-mips>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <alpine.LFD.2.03.1309041410160.11570@linux-mips.org> <20130905180825.GB11592@linux-mips.org> <alpine.LFD.2.03.1309052118560.11570@linux-mips.org> <20130907073450.GE11592@linux-mips.org> <alpine.LFD.2.03.1309071304090.19552@linux-mips.org> <alpine.LFD.2.03.1309160606110.2176@linux-mips.org>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.21 (2010-09-15)
On Mon, Sep 16, 2013 at 06:54:55AM +0100, Maciej W. Rozycki wrote:
>  Thomas, what was the rationale behind arranging things in this way?  Did 
> you mean to make this code shared among platforms needing it?  I would 

I really can't remember the reasoning any more, but I guess code sharing
was a reason.

> guess so, but then the copy in arch/mips/dec/prom/ would have to be 
> removed and macros in <asm/dec/prom.h> adjusted according to the new API 
> which you didn't do in your change.

because I didn't have a running DECstation handy.

> Also why the need for stack 
> switching?  It looks like an unnecessary complication to me, any firmware 
> callbacks exported have to maintain stack integrity or they would be 
> unusable.  Is that to work around some SNI firmware quirk?

a 64bit kernel with more than CKSEG0 addressable memory may end up having
a stack outside of CKSEG0, which is something the 32bit SNI firmware
doesn't like. I guess the same is true for DECstation, if there is a HW config
with enough memory.

>  [And does it work for the SNI in the first place? -- it looks to me like 
> `o32_stk' has an alignment problem (8 is required for the stack pointer in 
> the o32 ABI though 4 will often be enough to satisfy hardware); but 
> perhaps it just happens to get correct alignment by virtue of merely 
> always following a data object that enforces it, hmm...]

it worked, but nevertheless fixing the aligment isn't a bad thing.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]

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