On 1/3/22, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> 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.
