linux-crypto.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Will Deacon <will.deacon@arm.com>
Cc: Matthias Brugger <mbrugger@suse.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	"David S. Miller" <davem@davemloft.net>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Yazen Ghannam <yazen.ghannam@linaro.org>,
	Alexander Graf <agraf@suse.de>,
	"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] crypto: arm64/crc32 - detect crc32 support in assembler
Date: Wed, 1 Feb 2017 09:43:15 +0000	[thread overview]
Message-ID: <CAKv+Gu9gPAb-AMdbK32dXciX1mgh1sqSrxMAjB-ZGw7uAk2r2Q@mail.gmail.com> (raw)
In-Reply-To: <CAKv+Gu_LcU3mSSMdrjks02ZuhHLhkYqNuZGOcTp1AmS8cpzCDg@mail.gmail.com>

On 1 February 2017 at 09:07, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 27 January 2017 at 10:52, Will Deacon <will.deacon@arm.com> wrote:
>> On Fri, Jan 27, 2017 at 10:43:16AM +0000, Ard Biesheuvel wrote:
>>> On 27 January 2017 at 10:40, Matthias Brugger <mbrugger@suse.com> wrote:
>>> > Older compilers may not be able to detect the crc32 extended cpu type.
>>>
>>> What do you mean 'detect'? Could you describe the failure in more detail
>>> please?
>>>
>>> > Anyway only inline assembler code is used, which gets passed to the
>>> > assembler. This patch moves the crc detection to the assembler.
>>> >
>>> > Suggested-by: Alexander Graf <agraf@suse.de>
>>> > Signed-off-by: Matthias Brugger <mbrugger@suse.com>
>>> > ---
>>> >  arch/arm64/crypto/Makefile      | 2 --
>>> >  arch/arm64/crypto/crc32-arm64.c | 3 +++
>>> >  2 files changed, 3 insertions(+), 2 deletions(-)
>>> >
>>> > diff --git a/arch/arm64/crypto/Makefile b/arch/arm64/crypto/Makefile
>>> > index aa8888d7b744..0d779dac75cd 100644
>>> > --- a/arch/arm64/crypto/Makefile
>>> > +++ b/arch/arm64/crypto/Makefile
>>> > @@ -48,8 +48,6 @@ CFLAGS_aes-glue-ce.o  := -DUSE_V8_CRYPTO_EXTENSIONS
>>> >
>>> >  obj-$(CONFIG_CRYPTO_CRC32_ARM64) += crc32-arm64.o
>>> >
>>> > -CFLAGS_crc32-arm64.o   := -mcpu=generic+crc
>>> > -
>>> >  $(obj)/aes-glue-%.o: $(src)/aes-glue.c FORCE
>>> >         $(call if_changed_rule,cc_o_c)
>>> >
>>> > diff --git a/arch/arm64/crypto/crc32-arm64.c b/arch/arm64/crypto/crc32-arm64.c
>>> > index 6a37c3c6b11d..10f5dd075323 100644
>>> > --- a/arch/arm64/crypto/crc32-arm64.c
>>> > +++ b/arch/arm64/crypto/crc32-arm64.c
>>> > @@ -29,6 +29,9 @@ MODULE_AUTHOR("Yazen Ghannam <yazen.ghannam@linaro.org>");
>>> >  MODULE_DESCRIPTION("CRC32 and CRC32C using optional ARMv8 instructions");
>>> >  MODULE_LICENSE("GPL v2");
>>> >
>>> > +/* Request crc extension capabilities from the assembler */
>>> > +asm(".arch_extension crc");
>>> > +
>>>
>>> Will should confirm, but I think this is a recent feature in GAS for
>>> AArch64, so this may break older toolchains as well.
>>
>> Yes, the .arch_extension directive isn't universally supported by AArch64
>> gas so we can't rely on it unconditionally. The best bet is to check for
>> the support and, if it's not present, then disable whatever feature relies
>> on it. See the lseinstr variable in Makefile.
>>
>
> Actually, this driver has become somewhat redundant now that we have
> an alternative that combines an implementation based on 64x64
> polynomial multiplication with an implementation based on the CRC32
> instructions.
>
> I will propose a patch that makes the latter usable when only the
> CRC32 instructions are supported.

... although you still haven't explained what the actual problem is
that you are trying to solve.

  reply	other threads:[~2017-02-01  9:43 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20170127104039.29351-1-mbrugger@suse.com>
2017-01-27 10:43 ` [PATCH] crypto: arm64/crc32 - detect crc32 support in assembler Ard Biesheuvel
2017-01-27 10:52   ` Will Deacon
2017-02-01  9:07     ` Ard Biesheuvel
2017-02-01  9:43       ` Ard Biesheuvel [this message]
2017-02-01 13:58         ` Alexander Graf
2017-02-01 15:12           ` 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=CAKv+Gu9gPAb-AMdbK32dXciX1mgh1sqSrxMAjB-ZGw7uAk2r2Q@mail.gmail.com \
    --to=ard.biesheuvel@linaro.org \
    --cc=agraf@suse.de \
    --cc=catalin.marinas@arm.com \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbrugger@suse.com \
    --cc=will.deacon@arm.com \
    --cc=yazen.ghannam@linaro.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).