[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHmME9p+-TMR4mywPH2wasY52fyBVGPpYmBwmn9aF0MF+14W8Q@mail.gmail.com>
Date: Mon, 3 Jan 2022 04:45:10 +0100
From: "Jason A. Donenfeld" <Jason@...c4.com>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: linux-kernel@...r.kernel.org, Ard Biesheuvel <ardb@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Masahiro Yamada <masahiroy@...nel.org>,
linux-kbuild@...r.kernel.org, linux-crypto@...r.kernel.org
Subject: Re: [PATCH v6] lib/crypto: blake2s: include as built-in
On 1/3/22, Herbert Xu <herbert@...dor.apana.org.au> wrote:
> At this point I think we should push this through crypto. The
> changes are too invasive with respect to the crypto Kconfig files.
Ugh, can we please not? That will really make things much harder and
more annoying for me. I have an early pull planned, and you'll quickly
be able to rebase on top of it. It also doesn't appear to conflict
with anything you have queued up. Please, I would really appreciate
some straight forward linearity here, and I don't think my taking it
will negatively impact the flow.
>
>> diff --git a/crypto/Kconfig b/crypto/Kconfig
>> index 285f82647d2b..b7a2e50dcbc8 100644
>> --- a/crypto/Kconfig
>> +++ b/crypto/Kconfig
>> @@ -702,7 +702,7 @@ config CRYPTO_BLAKE2S
>> See https://blake2.net for further information.
>>
>> config CRYPTO_BLAKE2S_X86
>> - tristate "BLAKE2s digest algorithm (x86 accelerated version)"
>> + bool "BLAKE2s digest algorithm (x86 accelerated version)"
>> depends on X86 && 64BIT
>> select CRYPTO_LIB_BLAKE2S_GENERIC
>> select CRYPTO_ARCH_HAVE_LIB_BLAKE2S
>
> This will break when CRYPTO is disabled because the x86 crypto
> glue code depends on the crypto subsystem.
That snippet is inside an 'if CRYPTO' block, so it can't be selected
without CRYPTO being enabled.
Powered by blists - more mailing lists