From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C3B3E2C81 for ; Wed, 13 Oct 2021 13:11:03 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 75D69610FC; Wed, 13 Oct 2021 13:11:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1634130662; bh=teGcBvjkKcvW58YVaruBcXJovWJTtD1vxXWTSxfLepM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=mXPe2vE1fb9Pn6GDKQbsAJEAsUG/rxFjdlElS6D7bjH5kak9/st7J7N15QfVPIlU/ jv/fD1vsHF6BENDGR6WV3qft2teF0clFGxJAkT2IrD7m4lQJHh9fGTz5ZJl5kWSqu6 iVnt+ASwodVsiaxj0Ex+MLzz8F8/aH5Oc53Xdasg= Date: Wed, 13 Oct 2021 15:11:00 +0200 From: Greg Kroah-Hartman To: Arnd Bergmann Cc: Vegard Nossum , linux-staging@lists.linux.dev, Linux Kernel Mailing List , Randy Dunlap , Herbert Xu , "David S. Miller" , "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" Subject: Re: [PATCH] staging: ks7010: select CRYPTO_HASH/CRYPTO_MICHAEL_MIC Message-ID: References: <20211011152941.12847-1-vegard.nossum@oracle.com> <1bfd3945-3487-31ab-5489-9c12c759276b@oracle.com> Precedence: bulk X-Mailing-List: linux-staging@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Wed, Oct 13, 2021 at 03:03:41PM +0200, Arnd Bergmann wrote: > On Wed, Oct 13, 2021 at 2:51 PM Vegard Nossum wrote: > > On 10/13/21 2:26 PM, Greg Kroah-Hartman wrote: > > > On Mon, Oct 11, 2021 at 05:29:41PM +0200, Vegard Nossum wrote: > > >> Fix the following build/link errors: > > >> > > >> ld: drivers/staging/ks7010/ks_hostif.o: in function `michael_mic.constprop.0': > > >> ks_hostif.c:(.text+0x95b): undefined reference to `crypto_alloc_shash' > > >> ld: ks_hostif.c:(.text+0x97a): undefined reference to `crypto_shash_setkey' > > >> ld: ks_hostif.c:(.text+0xa13): undefined reference to `crypto_shash_update' > > >> ld: ks_hostif.c:(.text+0xa28): undefined reference to `crypto_shash_update' > > >> ld: ks_hostif.c:(.text+0xa48): undefined reference to `crypto_shash_finup' > > >> ld: ks_hostif.c:(.text+0xa6d): undefined reference to `crypto_destroy_tfm' > > >> > > >> Signed-off-by: Vegard Nossum > > >> --- > > >> drivers/staging/ks7010/Kconfig | 3 +++ > > >> 1 file changed, 3 insertions(+) > > >> > > >> diff --git a/drivers/staging/ks7010/Kconfig b/drivers/staging/ks7010/Kconfig > > >> index 0987fdc2f70db..8ea6c09286798 100644 > > >> --- a/drivers/staging/ks7010/Kconfig > > >> +++ b/drivers/staging/ks7010/Kconfig > > >> @@ -5,6 +5,9 @@ config KS7010 > > >> select WIRELESS_EXT > > >> select WEXT_PRIV > > >> select FW_LOADER > > >> + select CRYPTO > > >> + select CRYPTO_HASH > > >> + select CRYPTO_MICHAEL_MIC > > > > > > Let's try to rely on 'depend' and not 'select' please. > > > > I used 'select' because it seemed to be the established pattern for > > these options. > > Yes, this is the correct way to do it here. In general, using "depends on" > is better than "select", especially when crossing subsystem boundaries, > however mixing the two is what really hurts because of the circular > dependencies you'd get. > > The only way we could use 'depends on' here would be to change all > the other drivers to do the same. > > > Compare: > > > > $ find -name '*Kconfig*' | xargs git grep 'depends on CRYPTO$' | wc --lines > > 1 > > > > $ find -name '*Kconfig*' | xargs git grep 'select CRYPTO$' | wc --lines > > 66 > > > > $ find -name '*Kconfig*' | xargs git grep 'depends on CRYPTO' | wc --lines > > 87 > > > > $ find -name '*Kconfig*' | xargs git grep 'select CRYPTO' | wc --lines > > 1005 > > > > That said, I have found several other cases where CRYPTO_* algorithms > > are getting 'select'-ed without also selecting CRYPTO/CRYPTO_HASH, so I > > definitely see the problem you're trying to address. > > > > I've added some more people on Cc to see if there is a consensus on the > > best way to do this for the CRYPTO* options going forwards. Thoughts, > > anybody? > > I don't think there is much point in trying to change the > existing pattern for crypto. We might want to change some of those > that use 'depends on' at the moment for consistency, though most of > those look correct as well. Ok, I'll take this as-is then. thanks, greg k-h