From: Corentin Labbe <clabbe.montjoie@gmail.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: alexandre.torgue@st.com, arei.gonglei@huawei.com,
davem@davemloft.net, jasowang@redhat.com,
mcoquelin.stm32@gmail.com, mst@redhat.com,
fabien.dessenne@st.com, linux-arm-kernel@lists.infradead.org,
linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org
Subject: Re: [PATCH RFC 1/4] crypto: engine - Permit to enqueue all async requests
Date: Fri, 22 Dec 2017 09:41:48 +0100 [thread overview]
Message-ID: <20171222084148.GA3024@Red> (raw)
In-Reply-To: <20171222065724.GA27149@gondor.apana.org.au>
On Fri, Dec 22, 2017 at 05:57:24PM +1100, Herbert Xu wrote:
> On Wed, Nov 29, 2017 at 09:41:18AM +0100, Corentin Labbe wrote:
> > The crypto engine could actually only enqueue hash and ablkcipher request.
> > This patch permit it to enqueue any type of crypto_async_request.
> >
> > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
>
> This is going the wrong way. We do not want to expose any of the
> base types such as crypto_alg, crypto_async_request to end-users
> and that includes drivers. Only core API code should touch these
> base types.
>
Hello
It's you that was suggesting using crypto_async_request:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1474434.html
"The only wart with this scheme is that the drivers end up seeing
struct crypto_async_request and will need to convert that to the
respective request types but I couldn't really find a better way."
So I wait for any suggestion.
Regards
Corentin Labbe
WARNING: multiple messages have this Message-ID (diff)
From: clabbe.montjoie@gmail.com (Corentin Labbe)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RFC 1/4] crypto: engine - Permit to enqueue all async requests
Date: Fri, 22 Dec 2017 09:41:48 +0100 [thread overview]
Message-ID: <20171222084148.GA3024@Red> (raw)
In-Reply-To: <20171222065724.GA27149@gondor.apana.org.au>
On Fri, Dec 22, 2017 at 05:57:24PM +1100, Herbert Xu wrote:
> On Wed, Nov 29, 2017 at 09:41:18AM +0100, Corentin Labbe wrote:
> > The crypto engine could actually only enqueue hash and ablkcipher request.
> > This patch permit it to enqueue any type of crypto_async_request.
> >
> > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
>
> This is going the wrong way. We do not want to expose any of the
> base types such as crypto_alg, crypto_async_request to end-users
> and that includes drivers. Only core API code should touch these
> base types.
>
Hello
It's you that was suggesting using crypto_async_request:
https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1474434.html
"The only wart with this scheme is that the drivers end up seeing
struct crypto_async_request and will need to convert that to the
respective request types but I couldn't really find a better way."
So I wait for any suggestion.
Regards
Corentin Labbe
next prev parent reply other threads:[~2017-12-22 8:41 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-29 8:41 [PATCH RFC 0/4] crypto: engine - Permit to enqueue all async requests Corentin Labbe
2017-11-29 8:41 ` Corentin Labbe
2017-11-29 8:41 ` [PATCH RFC 1/4] " Corentin Labbe
2017-11-29 8:41 ` Corentin Labbe
2017-11-29 8:41 ` Corentin Labbe
2017-11-29 8:41 ` Corentin Labbe
2017-12-06 11:02 ` Fabien DESSENNE
2017-12-06 11:02 ` Fabien DESSENNE
2017-12-06 11:02 ` Fabien DESSENNE
2017-12-07 9:24 ` Corentin Labbe
2017-12-07 9:24 ` Corentin Labbe
2017-12-07 9:24 ` Corentin Labbe
2017-12-22 6:57 ` Herbert Xu
2017-12-22 6:57 ` Herbert Xu
2017-12-22 6:57 ` Herbert Xu
2017-12-22 8:41 ` Corentin Labbe [this message]
2017-12-22 8:41 ` Corentin Labbe
2017-12-22 9:06 ` Herbert Xu
2017-12-22 9:06 ` Herbert Xu
2017-12-22 9:06 ` Herbert Xu
2017-12-22 9:34 ` Corentin Labbe
2017-12-22 9:34 ` Corentin Labbe
2017-12-22 9:34 ` Corentin Labbe
2017-12-22 8:41 ` Corentin Labbe
2017-11-29 8:41 ` [PATCH RFC 2/4] crypto: omap: convert to new crypto engine API Corentin Labbe
2017-11-29 8:41 ` Corentin Labbe
2017-11-29 8:41 ` Corentin Labbe
2017-11-29 8:41 ` [PATCH RFC 3/4] crypto: virtio: " Corentin Labbe
2017-11-29 8:41 ` Corentin Labbe
2017-11-29 8:41 ` Corentin Labbe
2017-11-29 8:41 ` [PATCH RFC 4/4] crypto: stm32: convert to the " Corentin Labbe
2017-11-29 8:41 ` Corentin Labbe
2017-11-29 8:41 ` Corentin Labbe
2017-12-06 11:03 ` Fabien DESSENNE
2017-12-06 11:03 ` Fabien DESSENNE
2017-12-06 11:03 ` Fabien DESSENNE
2017-12-06 10:59 ` [PATCH RFC 0/4] crypto: engine - Permit to enqueue all async requests Fabien DESSENNE
2017-12-06 10:59 ` Fabien DESSENNE
2017-12-07 9:37 ` Corentin Labbe
2017-12-07 9:37 ` Corentin Labbe
2017-12-07 9:37 ` Corentin Labbe
2017-12-06 10:59 ` Fabien DESSENNE
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=20171222084148.GA3024@Red \
--to=clabbe.montjoie@gmail.com \
--cc=alexandre.torgue@st.com \
--cc=arei.gonglei@huawei.com \
--cc=davem@davemloft.net \
--cc=fabien.dessenne@st.com \
--cc=herbert@gondor.apana.org.au \
--cc=jasowang@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mcoquelin.stm32@gmail.com \
--cc=mst@redhat.com \
--cc=virtualization@lists.linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.