[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20160719.211522.465417746785662817.davem@davemloft.net>
Date: Tue, 19 Jul 2016 21:15:22 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: yeshaswi@...lsio.com
Cc: hariprasad@...lsio.com, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org,
jlulla@...lsio.ccom, harsh@...lsio.com, atul.gupta@...lsio.com,
herbert@...dor.apana.org.au
Subject: Re: [Patch-V2 2/3] chcr: Support for Chelsio's Crypto Hardware
From: Yeshaswi M R Gowda <yeshaswi@...lsio.com>
Date: Mon, 18 Jul 2016 22:42:14 -0700
> +config CRYPTO_DEV_CHELSIO
> + tristate "Chelsio Crypto Co-processor Driver"
> + depends on PCI && NETDEVICES && ETHERNET
> + select CRYPTO_SHA1
> + select CRYPTO_SHA256
> + select CRYPTO_SHA512
> + select NET_VENDOR_CHELSIO
> + select CHELSIO_T4
The user shouldn't have to know about the technical details about
how this chip is physically implemented.
It's therefore not reasonable to require an ethernet driver to be
enabled to use the crypto engine.
Also, selecting Kconfig symbol X does not recursively enable the
"select" statement(s) of symbol X nor does it check symbol X's
dependencies.
This is really one big huge dependency mess, and I think you have
to split out the core of the T4 driver into a driver subtype
agnostic library or similar to make this work properly.
Don't just shoehorn this stuff into the ethernet driver. Round
peg, square hole.
Powered by blists - more mailing lists