From: linux@armlinux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: arm: Is VFP hotplug notifiers wrong?
Date: Tue, 9 Jan 2018 11:40:48 +0000 [thread overview]
Message-ID: <20180109114048.GF17719@n2100.armlinux.org.uk> (raw)
In-Reply-To: <20180109.201221.1319754994300492102.okuno.kohji@jp.panasonic.com>
On Tue, Jan 09, 2018 at 08:12:21PM +0900, Kohji Okuno wrote:
> Dear Thomas and all,
>
> Could you please confirm about the following commit, again?
>
> http://git.armlinux.org.uk/cgit/linux-arm.git/commit/arch/arm/vfp/vfpmodule.c?id=e5b61bafe70477e05e1dce0d6ca4ec181e23cb2a
>
>
> The avobe commit eliminated the following fix, I think.
>
> http://git.armlinux.org.uk/cgit/linux-arm.git/commit/arch/arm/vfp/vfpmodule.c?id=384b38b66947b06999b3e39a596d4f2fb94f77e4
>
>
> vfp_force_reload() called from vfp_dying_cpu() does not clear
> vfp_current_hw_state[cpu], because cpu stopper task does not own the
> context held in the VFP hardware.
You are correct, tglx's patch was wrong, since the state in the CPU may
not be the current thread's state, so vfp_force_reload() may not do
anything.
vfp_force_reload() forces the reload of the specified state for the
specified CPU. What the original hotplug code did was to ensure that
the CPU's state would be reloaded when it came back up.
I do wish that people wouldn't combine functional changes and cleanups
into one patch - it makes this kind of thing harder to spot in review
and also means when we encounter crap like this, it means we can't
simply revert the cleanup.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
next prev parent reply other threads:[~2018-01-09 11:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-09 11:12 arm: Is VFP hotplug notifiers wrong? Kohji Okuno
2018-01-09 11:40 ` Russell King - ARM Linux [this message]
[not found] ` <alpine.DEB.2.20.1801091457210.1766@nanos>
2018-01-09 14:46 ` okuno.kohji at jp.panasonic.com
2018-01-09 14:49 ` Russell King - ARM Linux
2018-01-09 15:01 ` Fabio Estevam
2018-01-09 22:51 ` okuno.kohji at jp.panasonic.com
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=20180109114048.GF17719@n2100.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=linux-arm-kernel@lists.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).