From: Mark Brown <broonie@kernel.org>
To: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Eric Biggers <ebiggers@google.com>,
Ard Biesheuvel <ardb@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
linux-crypto@vger.kernel.org, Mark Brown <broonie@kernel.org>
Subject: [PATCH 0/3] arm64: Open code .arch_extension
Date: Wed, 25 Mar 2020 11:41:07 +0000 [thread overview]
Message-ID: <20200325114110.23491-1-broonie@kernel.org> (raw)
Currently several assembler files override the default architecture to
enable extensions in order to allow them to implement optimised routines
for systems with those extensions. Since inserting BTI landing pads into
assembler functions will require us to change the default architecture we
need a way to enable extensions without hard coding the architecture.
The assembler has the .arch_extension feature but this was introduced
for arm64 in gas 2.26 which is too modern for us to rely on it.
We could just update the base architecture used by these assembler files
but this would mean the assembler would no longer catch attempts to use
newer instructions so instead introduce a macro which sets the default
architecture centrally. Doing this will also make our use of .arch and
.cpu to select the base architecture more consistent.
Mark Brown (3):
arm64: asm: Provide macro to control enabling architecture extensions
arm64: lib: Use ARM64_EXTENSIONS()
arm64: crypto: Use ARM64_EXTENSIONS()
arch/arm64/crypto/aes-ce-ccm-core.S | 3 ++-
arch/arm64/crypto/aes-ce-core.S | 2 +-
arch/arm64/crypto/aes-ce.S | 2 +-
arch/arm64/crypto/crct10dif-ce-core.S | 3 ++-
arch/arm64/crypto/ghash-ce-core.S | 3 ++-
arch/arm64/crypto/sha1-ce-core.S | 3 ++-
arch/arm64/crypto/sha2-ce-core.S | 3 ++-
arch/arm64/include/asm/linkage.h | 6 ++++++
arch/arm64/lib/crc32.S | 2 +-
9 files changed, 19 insertions(+), 8 deletions(-)
--
2.20.1
next reply other threads:[~2020-03-25 11:41 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-25 11:41 Mark Brown [this message]
2020-03-25 11:41 ` [PATCH 1/3] arm64: asm: Provide macro to control enabling architecture extensions Mark Brown
2020-03-25 11:41 ` [PATCH 2/3] arm64: lib: Use ARM64_EXTENSIONS() Mark Brown
2020-03-25 11:41 ` [PATCH 3/3] arm64: crypto: " Mark Brown
2020-03-25 11:45 ` [PATCH 0/3] arm64: Open code .arch_extension Ard Biesheuvel
2020-03-25 11:50 ` Mark Brown
2020-03-25 11:54 ` Ard Biesheuvel
2020-03-25 12:01 ` Mark Brown
2020-03-25 12:03 ` Mark Rutland
2020-03-25 12:24 ` Robin Murphy
2020-04-22 18:00 ` Catalin Marinas
2020-04-23 11:18 ` Mark Brown
2020-04-23 11:59 ` Catalin Marinas
2020-04-23 13:40 ` Catalin Marinas
2020-03-25 12:31 ` Mark Rutland
2020-03-25 13:26 ` Ard Biesheuvel
2020-03-25 13:30 ` Mark Brown
2020-03-25 13:27 ` Mark Brown
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=20200325114110.23491-1-broonie@kernel.org \
--to=broonie@kernel.org \
--cc=ardb@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=ebiggers@google.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=will@kernel.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).