[Top] [All Lists]

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

To: "Maciej W. Rozycki" <>
Subject: Re: [PATCH] MIPS: DECstation HRT calibration bug fixes
From: Thomas Bogendoerfer <>
Date: Tue, 17 Sep 2013 10:41:26 +0200
Cc: Ralf Baechle <>,
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: <>
Original-recipient: rfc822;
References: <> <> <> <> <> <>
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.


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>