All of lore.kernel.org
 help / color / mirror / Atom feed
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Daniel Palmer <daniel@0x0f.com>
Cc: gerg@linux-m68k.org, fthain@linux-m68k.org,
	 linux-m68k@lists.linux-m68k.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/2] m68k: Fix interrupt stack frames for 68000
Date: Mon, 8 Jan 2024 10:56:37 +0100	[thread overview]
Message-ID: <CAMuHMdX44A6+BNByuvbCC2gcM5vAipbaGAK7L8Vh8q3tMynBbQ@mail.gmail.com> (raw)
In-Reply-To: <20240108093221.1477020-3-daniel@0x0f.com>

Hi Daniel,

Thanks for your patch!

On Mon, Jan 8, 2024 at 10:32 AM Daniel Palmer <daniel@0x0f.com> wrote:
> The plain old 68000 does not push the frame type/vector on the
> stack when an interrupt starts like the brand new 68010 does.

;-)

> This means that currently everything in struct pt_regs is
> a bit off because it expects the processor to push an extra
> short before the kernel interrupt code adds the rest.
>
> In entry.S for the 68000 we already need to manually put
> the vector number on the stack to work out what interrupt
> is being handled because the cpu doesn't push that to the
> stack.
>
> So we can jiggle this around a bit to fix the issue:
> - For 68000 use the same struct pt_regs layout as coldfire
>   where frame/vector is after pc and sp.
> - In entry.S push the vector number first, the stack pointer
>   now lines up with the sktadj field in pt_regs and when saving
>   the remaining registers the offsets match the fields in the
>   struct.
> - Remove the vec argument from the DragonBall interrupt
>   decoding logic as it's not pushed on the stack anymore
>   and not used either way.
>
> Signed-off-by: Daniel Palmer <daniel@0x0f.com>

> --- a/arch/m68k/include/uapi/asm/ptrace.h
> +++ b/arch/m68k/include/uapi/asm/ptrace.h
> @@ -39,7 +39,7 @@ struct pt_regs {
>    long     d0;
>    long     orig_d0;
>    long     stkadj;
> -#ifdef CONFIG_COLDFIRE
> +#if defined(CONFIG_COLDFIRE) || defined(CONFIG_M68000)
>    unsigned format :  4; /* frame format specifier */
>    unsigned vector : 12; /* vector offset */
>    unsigned short sr;

I think it would be better to use the classic m68k stack frame.
That would pave the way for building a single nommu kernel for
MC680[012346]0 that runs on e.g. any Amiga.
MC68000 and Coldfire are incompatible anyway.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

  reply	other threads:[~2024-01-08  9:56 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-08  9:32 [PATCH v2 0/2] Fix 68000 interrupt stack frames Daniel Palmer
2024-01-08  9:32 ` [PATCH v2 1/2] m68k: Use macro to generate 68000 interrupt entry sleds Daniel Palmer
2024-01-08  9:32 ` [PATCH v2 2/2] m68k: Fix interrupt stack frames for 68000 Daniel Palmer
2024-01-08  9:56   ` Geert Uytterhoeven [this message]
2024-01-08 10:17     ` Daniel Palmer
2024-01-09 14:09     ` Daniel Palmer
2024-01-09 14:27       ` Geert Uytterhoeven
2024-01-09  4:14   ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAMuHMdX44A6+BNByuvbCC2gcM5vAipbaGAK7L8Vh8q3tMynBbQ@mail.gmail.com \
    --to=geert@linux-m68k.org \
    --cc=daniel@0x0f.com \
    --cc=fthain@linux-m68k.org \
    --cc=gerg@linux-m68k.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.