All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Walleij <linus.walleij@linaro.org>
To: Ard Biesheuvel <ardb@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>
Cc: linux-arm-kernel@lists.infradead.org, linux@armlinux.org.uk,
	 Frederic Weisbecker <frederic@kernel.org>,
	Guenter Roeck <linux@roeck-us.net>,
	 Peter Zijlstra <peterz@infradead.org>,
	Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH v3 4/4] ARM: vfp: Reimplement VFP exception entry in C code
Date: Thu, 16 Mar 2023 09:59:35 +0100	[thread overview]
Message-ID: <CACRpkdaCBBCDArMUqWR0Jn174M6gMPZGTzCG1G4D75jaNw9UmA@mail.gmail.com> (raw)
In-Reply-To: <20230316082007.652669-5-ardb@kernel.org>

On Thu, Mar 16, 2023 at 9:20 AM Ard Biesheuvel <ardb@kernel.org> wrote:

> En/disabling softirqs from asm code turned out to be trickier than
> expected, so vfp_support_entry now returns by tail calling
> __local_enable_bh_ip() and passing the same arguments that a C call to
> local_bh_enable() would pass. However, this is slightly hacky, as we
> don't want to carry our own implementation of local_bh_enable().
>
> So let's bite the bullet, and get rid of the asm logic in
> vfp_support_entry that reasons about whether or not to save and/or
> reload the VFP state, and about whether or not an FP exception is
> pending, and only keep the VFP loading logic as a function that is
> callable from C.
>
> Replicate the removed logic in vfp_entry(), and use the exact same
> reasoning as in the asm code. To emphasize the correspondance, retain
> some of the asm comments in the C version as well.
>
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>

I tried to model what the assembly is doing in my head to review
if the new code in C does the same thing, but after following some of
the semantics (which look correct) I realized it will mostly be down to
testing anyway.

It's definately better to have it like this so FWIW:
Acked-by: Linus Walleij <linus.walleij@linaro.org>

Apparently a bunch of this code was written by Catalin for VFPv3 support,
he may or may not have the memory and time to go back and look at it, but
let's page him in anyway :)

Yours,
Linus Walleij

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-03-16  9:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-16  8:20 [PATCH v3 0/4] ARM: vfp: Switch to C API to en/disable softirqs Ard Biesheuvel
2023-03-16  8:20 ` [PATCH v3 1/4] ARM: vfp: Pass thread_info pointer to vfp_support_entry Ard Biesheuvel
2023-03-16  8:20 ` [PATCH v3 2/4] ARM: vfp: Pass successful return address via register R3 Ard Biesheuvel
2023-03-16  8:20 ` [PATCH v3 3/4] ARM: vfp: Fix broken softirq handling with instrumentation enabled Ard Biesheuvel
2023-03-16  8:20 ` [PATCH v3 4/4] ARM: vfp: Reimplement VFP exception entry in C code Ard Biesheuvel
2023-03-16  8:59   ` Linus Walleij [this message]
2023-03-18 16:20     ` Ard Biesheuvel
2023-03-17  0:23 ` [PATCH v3 0/4] ARM: vfp: Switch to C API to en/disable softirqs Guenter Roeck
2023-03-17  0:24   ` Guenter Roeck
2023-03-17  8:55     ` Ard Biesheuvel

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=CACRpkdaCBBCDArMUqWR0Jn174M6gMPZGTzCG1G4D75jaNw9UmA@mail.gmail.com \
    --to=linus.walleij@linaro.org \
    --cc=ardb@kernel.org \
    --cc=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=frederic@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux@armlinux.org.uk \
    --cc=linux@roeck-us.net \
    --cc=peterz@infradead.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.