Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Thu, 16 Sep 2021 19:03:15 +1000 (AEST)
From:   Finn Thain <fthain@linux-m68k.org>
To:     Al Viro <viro@zeniv.linux.org.uk>
cc:     linux-m68k@lists.linux-m68k.org,
        Geert Uytterhoeven <geert@linux-m68k.org>,
        Greg Ungerer <gerg@linux-m68k.org>,
        linux-kernel@vger.kernel.org
Subject: Re: [RFC][CFT] signal handling fixes
In-Reply-To: <YP2c1xk9LJ0zE3KW@zeniv-ca.linux.org.uk>
Message-ID: <89b7f0e5-21a5-5828-1eb8-5119fb8e2d58@linux-m68k.org>
References: <YP2c1xk9LJ0zE3KW@zeniv-ca.linux.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Precedence: bulk

On Sun, 25 Jul 2021, Al Viro wrote:

> ...
> 
> PS:  FWIW, ifdefs in arch/m68k/kernel/signal.c are wrong - it's not !MMU 
> vs. coldfire/MMU vs. classic/MMU.  It's actually 68000 vs. coldfire vs. 
> everything else.  These days it's nearly correct, but only because on 
> MMU variants of coldfire we never see exception stack frames with type 
> other than 4 - it's controlled by alignment of kernel stack pointer on 
> those, and it's under the kernel control, so it's always 32bit-aligned.  
> It used to be more serious back when we had 68360 support - that's !MMU 
> and exception stack frames are like those on 68020, unless I'm 
> misreading their manual...
> 

I don't claim to understand this code but CPU32 cores appear to be 
unsupported on either #ifdef branch: the MMU branch due to CACR and CAAR 
used in push_cache(), and the !MMU branch due to frame format $4 used in 
adjust_format().

The CPU32 Reference Manual appendix says these chips only supports control 
registers SFC, DFC, VBR and stack frame formats $0, $2, $C. 
https://www.nxp.com/files-static/microcontrollers/doc/ref_manual/CPU32RM.pdf