From: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Herbert Xu <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
Cc: alexandre.torgue-qxv4g6HH51o@public.gmane.org,
arei.gonglei-hv44wF8Li93QT0dZR+AlfA@public.gmane.org,
corbet-T1hC0tSOHrs@public.gmane.org,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org,
jasowang-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
fabien.dessenne-qxv4g6HH51o@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
Subject: Re: [PATCH v2 0/6] crypto: engine - Permit to enqueue all async requests
Date: Fri, 16 Feb 2018 16:36:56 +0100 [thread overview]
Message-ID: <20180216153656.GA22492@Red> (raw)
In-Reply-To: <20180215155100.GJ7352-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
On Thu, Feb 15, 2018 at 11:51:00PM +0800, Herbert Xu wrote:
> On Fri, Jan 26, 2018 at 08:15:28PM +0100, Corentin Labbe wrote:
> > Hello
> >
> > The current crypto_engine support only ahash and ablkcipher request.
> > My first patch which try to add skcipher was Nacked, it will add too many functions
> > and adding other algs(aead, asymetric_key) will make the situation worst.
> >
> > This patchset remove all algs specific stuff and now only process generic crypto_async_request.
> >
> > The requests handler function pointer are now moved out of struct engine and
> > are now stored directly in a crypto_engine_reqctx.
> >
> > The original proposal of Herbert [1] cannot be done completly since the crypto_engine
> > could only dequeue crypto_async_request and it is impossible to access any request_ctx
> > without knowing the underlying request type.
> >
> > So I do something near that was requested: adding crypto_engine_reqctx in TFM context.
> > Note that the current implementation expect that crypto_engine_reqctx
> > is the first member of the context.
> >
> > The first patch is a try to document the crypto engine API.
> > The second patch convert the crypto engine with the new way,
> > while the following patchs convert the 4 existing users of crypto_engine.
> > Note that this split break bisection, so probably the final commit will be all merged.
> >
> > Appart from virtio, all 4 latest patch were compile tested only.
> > But the crypto engine is tested with my new sun8i-ce driver.
> >
> > Regards
> >
> > [1] https://www.mail-archive.com/linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg1474434.html
> >
> > Changes since V1:
> > - renamed crypto_engine_reqctx to crypto_engine_ctx
> > - indentation fix in function parameter
> > - do not export crypto_transfer_request
> > - Add aead support
> > - crypto_finalize_request is now static
> >
> > Changes since RFC:
> > - Added a documentation patch
> > - Added patch for stm32-cryp
> > - Changed parameter of all crypto_engine_op functions from
> > crypto_async_request to void*
> > - Reintroduced crypto_transfer_xxx_request_to_engine functions
> >
> > Corentin Labbe (6):
> > Documentation: crypto: document crypto engine API
> > crypto: engine - Permit to enqueue all async requests
> > crypto: omap: convert to new crypto engine API
> > crypto: virtio: convert to new crypto engine API
> > crypto: stm32-hash: convert to the new crypto engine API
> > crypto: stm32-cryp: convert to the new crypto engine API
>
> All applied. Thanks.
Hello
As mentionned in the cover letter, all patchs (except documentation one) should be squashed.
A kbuild robot reported a build error on cryptodev due to this.
Regards
WARNING: multiple messages have this Message-ID (diff)
From: clabbe.montjoie@gmail.com (Corentin Labbe)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 0/6] crypto: engine - Permit to enqueue all async requests
Date: Fri, 16 Feb 2018 16:36:56 +0100 [thread overview]
Message-ID: <20180216153656.GA22492@Red> (raw)
In-Reply-To: <20180215155100.GJ7352@gondor.apana.org.au>
On Thu, Feb 15, 2018 at 11:51:00PM +0800, Herbert Xu wrote:
> On Fri, Jan 26, 2018 at 08:15:28PM +0100, Corentin Labbe wrote:
> > Hello
> >
> > The current crypto_engine support only ahash and ablkcipher request.
> > My first patch which try to add skcipher was Nacked, it will add too many functions
> > and adding other algs(aead, asymetric_key) will make the situation worst.
> >
> > This patchset remove all algs specific stuff and now only process generic crypto_async_request.
> >
> > The requests handler function pointer are now moved out of struct engine and
> > are now stored directly in a crypto_engine_reqctx.
> >
> > The original proposal of Herbert [1] cannot be done completly since the crypto_engine
> > could only dequeue crypto_async_request and it is impossible to access any request_ctx
> > without knowing the underlying request type.
> >
> > So I do something near that was requested: adding crypto_engine_reqctx in TFM context.
> > Note that the current implementation expect that crypto_engine_reqctx
> > is the first member of the context.
> >
> > The first patch is a try to document the crypto engine API.
> > The second patch convert the crypto engine with the new way,
> > while the following patchs convert the 4 existing users of crypto_engine.
> > Note that this split break bisection, so probably the final commit will be all merged.
> >
> > Appart from virtio, all 4 latest patch were compile tested only.
> > But the crypto engine is tested with my new sun8i-ce driver.
> >
> > Regards
> >
> > [1] https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1474434.html
> >
> > Changes since V1:
> > - renamed crypto_engine_reqctx to crypto_engine_ctx
> > - indentation fix in function parameter
> > - do not export crypto_transfer_request
> > - Add aead support
> > - crypto_finalize_request is now static
> >
> > Changes since RFC:
> > - Added a documentation patch
> > - Added patch for stm32-cryp
> > - Changed parameter of all crypto_engine_op functions from
> > crypto_async_request to void*
> > - Reintroduced crypto_transfer_xxx_request_to_engine functions
> >
> > Corentin Labbe (6):
> > Documentation: crypto: document crypto engine API
> > crypto: engine - Permit to enqueue all async requests
> > crypto: omap: convert to new crypto engine API
> > crypto: virtio: convert to new crypto engine API
> > crypto: stm32-hash: convert to the new crypto engine API
> > crypto: stm32-cryp: convert to the new crypto engine API
>
> All applied. Thanks.
Hello
As mentionned in the cover letter, all patchs (except documentation one) should be squashed.
A kbuild robot reported a build error on cryptodev due to this.
Regards
WARNING: multiple messages have this Message-ID (diff)
From: Corentin Labbe <clabbe.montjoie@gmail.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: alexandre.torgue@st.com, arei.gonglei@huawei.com, corbet@lwn.net,
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-doc@vger.kernel.org,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org,
linux-sunxi@googlegroups.com
Subject: Re: [PATCH v2 0/6] crypto: engine - Permit to enqueue all async requests
Date: Fri, 16 Feb 2018 16:36:56 +0100 [thread overview]
Message-ID: <20180216153656.GA22492@Red> (raw)
In-Reply-To: <20180215155100.GJ7352@gondor.apana.org.au>
On Thu, Feb 15, 2018 at 11:51:00PM +0800, Herbert Xu wrote:
> On Fri, Jan 26, 2018 at 08:15:28PM +0100, Corentin Labbe wrote:
> > Hello
> >
> > The current crypto_engine support only ahash and ablkcipher request.
> > My first patch which try to add skcipher was Nacked, it will add too many functions
> > and adding other algs(aead, asymetric_key) will make the situation worst.
> >
> > This patchset remove all algs specific stuff and now only process generic crypto_async_request.
> >
> > The requests handler function pointer are now moved out of struct engine and
> > are now stored directly in a crypto_engine_reqctx.
> >
> > The original proposal of Herbert [1] cannot be done completly since the crypto_engine
> > could only dequeue crypto_async_request and it is impossible to access any request_ctx
> > without knowing the underlying request type.
> >
> > So I do something near that was requested: adding crypto_engine_reqctx in TFM context.
> > Note that the current implementation expect that crypto_engine_reqctx
> > is the first member of the context.
> >
> > The first patch is a try to document the crypto engine API.
> > The second patch convert the crypto engine with the new way,
> > while the following patchs convert the 4 existing users of crypto_engine.
> > Note that this split break bisection, so probably the final commit will be all merged.
> >
> > Appart from virtio, all 4 latest patch were compile tested only.
> > But the crypto engine is tested with my new sun8i-ce driver.
> >
> > Regards
> >
> > [1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1474434.html
> >
> > Changes since V1:
> > - renamed crypto_engine_reqctx to crypto_engine_ctx
> > - indentation fix in function parameter
> > - do not export crypto_transfer_request
> > - Add aead support
> > - crypto_finalize_request is now static
> >
> > Changes since RFC:
> > - Added a documentation patch
> > - Added patch for stm32-cryp
> > - Changed parameter of all crypto_engine_op functions from
> > crypto_async_request to void*
> > - Reintroduced crypto_transfer_xxx_request_to_engine functions
> >
> > Corentin Labbe (6):
> > Documentation: crypto: document crypto engine API
> > crypto: engine - Permit to enqueue all async requests
> > crypto: omap: convert to new crypto engine API
> > crypto: virtio: convert to new crypto engine API
> > crypto: stm32-hash: convert to the new crypto engine API
> > crypto: stm32-cryp: convert to the new crypto engine API
>
> All applied. Thanks.
Hello
As mentionned in the cover letter, all patchs (except documentation one) should be squashed.
A kbuild robot reported a build error on cryptodev due to this.
Regards
next prev parent reply other threads:[~2018-02-16 15:36 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-26 19:15 [PATCH v2 0/6] crypto: engine - Permit to enqueue all async requests Corentin Labbe
2018-01-26 19:15 ` Corentin Labbe
2018-01-26 19:15 ` Corentin Labbe
2018-01-26 19:15 ` [PATCH v2 1/6] Documentation: crypto: document crypto engine API Corentin Labbe
2018-01-26 19:15 ` [PATCH v2 2/6] crypto: engine - Permit to enqueue all async requests Corentin Labbe
2018-01-26 19:15 ` [PATCH v2 3/6] crypto: omap: convert to new crypto engine API Corentin Labbe
[not found] ` <20180126191534.17569-1-clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-01-26 19:15 ` [PATCH v2 1/6] Documentation: crypto: document " Corentin Labbe
2018-01-26 19:15 ` Corentin Labbe
2018-01-26 19:15 ` Corentin Labbe
2018-01-26 19:15 ` [PATCH v2 2/6] crypto: engine - Permit to enqueue all async requests Corentin Labbe
2018-01-26 19:15 ` Corentin Labbe
2018-01-26 19:15 ` Corentin Labbe
2018-02-14 13:31 ` Fabien DESSENNE
2018-02-14 13:31 ` Fabien DESSENNE
2018-02-14 13:31 ` Fabien DESSENNE
2018-02-14 13:31 ` Fabien DESSENNE
2018-01-26 19:15 ` [PATCH v2 3/6] crypto: omap: convert to new crypto engine API Corentin Labbe
2018-01-26 19:15 ` Corentin Labbe
2018-01-26 19:15 ` Corentin Labbe
2018-01-26 19:15 ` [PATCH v2 4/6] crypto: virtio: " Corentin Labbe
2018-01-26 19:15 ` Corentin Labbe
2018-01-26 19:15 ` Corentin Labbe
2018-02-14 15:51 ` Michael S. Tsirkin
2018-02-14 15:51 ` Michael S. Tsirkin
2018-02-14 15:51 ` Michael S. Tsirkin
2018-01-26 19:15 ` [PATCH v2 5/6] crypto: stm32-hash: convert to the " Corentin Labbe
2018-01-26 19:15 ` Corentin Labbe
2018-01-26 19:15 ` Corentin Labbe
2018-02-15 15:51 ` [PATCH v2 0/6] crypto: engine - Permit to enqueue all async requests Herbert Xu
2018-02-15 15:51 ` Herbert Xu
2018-02-15 15:51 ` Herbert Xu
2018-02-16 15:36 ` Corentin Labbe
[not found] ` <20180215155100.GJ7352-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
2018-02-16 15:36 ` Corentin Labbe [this message]
2018-02-16 15:36 ` Corentin Labbe
2018-02-16 15:36 ` Corentin Labbe
2018-02-17 4:42 ` Herbert Xu
2018-02-17 4:42 ` Herbert Xu
2018-02-17 4:42 ` Herbert Xu
2018-01-26 19:15 ` [PATCH v2 4/6] crypto: virtio: convert to new crypto engine API Corentin Labbe
2018-01-26 19:15 ` [PATCH v2 5/6] crypto: stm32-hash: convert to the " Corentin Labbe
2018-01-26 19:15 ` [PATCH v2 6/6] crypto: stm32-cryp: " Corentin Labbe
2018-01-26 19:15 ` Corentin Labbe
2018-01-26 19:15 ` Corentin Labbe
2018-02-15 15:51 ` [PATCH v2 0/6] crypto: engine - Permit to enqueue all async requests Herbert Xu
-- strict thread matches above, loose matches on Subject: below --
2018-01-26 19:15 Corentin Labbe
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=20180216153656.GA22492@Red \
--to=clabbe.montjoie-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=alexandre.torgue-qxv4g6HH51o@public.gmane.org \
--cc=arei.gonglei-hv44wF8Li93QT0dZR+AlfA@public.gmane.org \
--cc=corbet-T1hC0tSOHrs@public.gmane.org \
--cc=davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org \
--cc=fabien.dessenne-qxv4g6HH51o@public.gmane.org \
--cc=herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org \
--cc=jasowang-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org \
--cc=mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.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.