From: daniel.thompson@linaro.org (Daniel Thompson)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 0/5] arm64: alternative: Provide if/else/endif assembler macros
Date: Mon, 20 Jul 2015 16:09:59 +0100 [thread overview]
Message-ID: <1437405004-1296-1-git-send-email-daniel.thompson@linaro.org> (raw)
In-Reply-To: <1436536130-31438-1-git-send-email-daniel.thompson@linaro.org>
Will: This is a split out version of previous patch, as requested. I have
retained a patch at the send of the series to nix alternative_insn
but there's no need to take this one for 4.3. Likewise I've fully
split out all the switch-over patches so you can just drop them
if they bring any merge trouble.
The existing alternative_insn macro has some limitations that make it
hard to work with. In particular the fact it takes instructions from it
own macro arguments means it doesn't play very nicely with C pre-processor
macros because the macro arguments look like a string to the C
pre-processor. Workarounds are (probably) possible but things start to
look ugly.
This patchset introduces new macros that allow instructions to be
presented to the assembler as normal and overcomes these limitations,
together with patches to switch all existing users to the new macros.
My view is that these if_not/else/endif macros are more readable
than the original macro and that alone might be enough to justify them.
However below is an concrete example of an alterntive sequence that is
needlessly hard to write without them because ICC_PMR_EL1 is a C
pre-processor macro.
.macro disable_irq, tmp
mov \tmp, #ICC_PMR_EL1_MASKED
alternative_if_not ARM64_HAS_SYSREG_GIC_CPUIF
msr daifset, #2
alternative_else
msr_s ICC_PMR_EL1, \tmp
alternative_endif
.endm
The new macros have received a fair degree of testing because I have
based my (not published since March) pseudo-NMI patch set on them.
v2:
* Split big patch out into atomized components (Will Deacon).
To show where I would like to go I have retained a patch to remove
assembler_insn() from the code base although, based on Will's email
I don't anticipate this patch being taken for 4.3.
* Add some comments to make clear the constraints imposed on alternative
sequences.
Daniel Thompson (5):
arm64: alternative: Provide if/else/endif assembler macros
arm64: mm: Adopt new alternative assembler macros
arm64: kernel: Adopt new alternative assembler macros
arm64: kvm: Adopt new alternative assembler macros
arm64: alternative: Remove alternative_insn macro
arch/arm64/include/asm/alternative.h | 40 ++++++++++++++++++++++++++++++------
arch/arm64/kernel/entry.S | 29 ++++++++++++--------------
arch/arm64/kvm/hyp.S | 12 +++++++++--
arch/arm64/mm/cache.S | 7 ++++++-
4 files changed, 63 insertions(+), 25 deletions(-)
--
2.4.3
next prev parent reply other threads:[~2015-07-20 15:09 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-10 13:48 [PATCH] arm64: alternative: Provide if/else/endif assembler macros Daniel Thompson
2015-07-16 18:19 ` Will Deacon
2015-07-17 10:42 ` Daniel Thompson
2015-07-20 15:09 ` Daniel Thompson [this message]
2015-07-20 15:10 ` [PATCH v2 1/5] " Daniel Thompson
2015-07-20 17:12 ` Will Deacon
2015-07-22 11:08 ` Daniel Thompson
2015-07-20 15:10 ` [PATCH v2 2/5] arm64: mm: Adopt new alternative " Daniel Thompson
2015-07-20 15:10 ` [PATCH v2 3/5] arm64: kernel: " Daniel Thompson
2015-07-20 15:10 ` [PATCH v2 4/5] arm64: kvm: " Daniel Thompson
2015-07-20 15:10 ` [PATCH v2 5/5] arm64: alternative: Remove alternative_insn macro Daniel Thompson
2015-07-22 11:21 ` [PATCH v3 0/5] arm64: alternative: Provide if/else/endif assembler macros Daniel Thompson
2015-07-22 11:21 ` [PATCH v3 1/5] " Daniel Thompson
2015-07-22 11:21 ` [PATCH v3 2/5] arm64: mm: Adopt new alternative " Daniel Thompson
2015-07-22 11:21 ` [PATCH v3 3/5] arm64: kernel: " Daniel Thompson
2015-07-22 11:21 ` [PATCH v3 4/5] arm64: kvm: " Daniel Thompson
2015-07-22 15:17 ` Will Deacon
2015-07-22 15:55 ` Marc Zyngier
2015-07-22 11:21 ` [PATCH v3 5/5] arm64: alternative: Remove alternative_insn macro Daniel Thompson
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=1437405004-1296-1-git-send-email-daniel.thompson@linaro.org \
--to=daniel.thompson@linaro.org \
--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).