Re: [PATCH v2] hw_random: omap3-rom-rng: convert timer to delayed work
On Wed, Nov 18, 2015 at 09:59:01PM +0200, Aaro Koskinen wrote: > We cannot put the HW RNG to idle using a timer because we cannot disable > clocks from atomic context. Use a delayed work instead. > > Fixes a warning with CONFIG_DEBUG_MUTEXES on Nokia N900 during boot. > > Reported-by: Sebastian Reichel > Signed-off-by: Aaro Koskinen Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] hw_random: omap3-rom-rng: convert timer to delayed work
On Fri, Nov 06, 2015 at 12:15:24AM +0200, Aaro Koskinen wrote: > We cannot put the HW RNG to idle using a timer because we cannot disable > clocks from atomic context. Use a delayed work instead. > > Fixes a warning with CONFIG_DEBUG_MUTEXES on Nokia N900 during boot. > > Reported-by: Sebastian Reichel > Signed-off-by: Aaro Koskinen Thanks for the patch. Can you please remove timer.h and include workqueue.h instead? Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] crypto: omap-aes: Add support for GCM mode
On Tue, Sep 15, 2015 at 06:58:01PM +0530, Lokesh Vutla wrote:
>
> + assoc = &req->src[0];
> + sg_init_table(dd->in_sgl, nsg + 1);
> + if (assoclen) {
> + if (omap_aes_check_aligned(assoc, assoclen)) {
> + dd->sgs_copied |= AES_ASSOC_DATA_COPIED;
> + pages = get_order(alen);
> + buf_in = (void *)__get_free_pages(GFP_ATOMIC, pages);
It would be better if you used a list of pages rather than n
contiguous pages which is likely to fail.
> + buf_in = sg_virt(assoc);
This is bogus as assoc may not be mapped.
> + if (req->cryptlen) {
> + input = scatterwalk_ffwd(tmp, req->src, req->assoclen);
scatterwalk_ffwd may return tmp so tmp must not be on the stack
unless you stop using input after the function returns. Also tmp
must not be reused by a subsequent call to scatterwalk_ffwd.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/7] crypto: omap-aes: Add support for GCM mode
On Fri, Jul 10, 2015 at 07:39:35PM +0530, Lokesh Vutla wrote: > > If you don't mind can you elaborate more on the usage of rctx and ctx > in the driver? The ctx is a property of the tfm and it's shared by all users of that tfm. So it must not be written to unless you use locking. The reqeust context on the other hand is specific to a request so it can be used to store information. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/7] crypto: omap-aes: Add support for GCM mode
On Wed, Jul 08, 2015 at 03:48:05PM +0800, Herbert Xu wrote:
> On Wed, Jul 08, 2015 at 12:29:47PM +0530, Lokesh Vutla wrote:
> >
> > >> +if (req->assoclen + req->cryptlen == 0) {
> > >> +scatterwalk_map_and_copy(ctx->auth_tag, req->dst, 0,
> > >> authlen,
> > >> + 1);
> > >> +return 0;
> > >> +}
> > >
> > > How can this be right? Did you enable the selftest?
> > Why not? Self tests are passed for this case.
> >
> > As per the equation given in GCM spec[1], we can see that
> > if assoclen and cryptlen is 0, then output of GCM is just E(K, Y0)
> > where Y0 = IV||(0^31)1
> > I have E(K, Y0) calculated in previous step. And copying it
> > to destination if assoclen and cryptlen is 0.
> >
> > Correct me if I am wrong.
>
> It should be E(K, Y0) ^ GHASH(0). So unless GHASH(0) == 0, your
> code doesn't work.
OK, GHASH(0) is indeed zero so I guess your code does work after
all.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/7] crypto: omap-aes: Add support for GCM mode
On Wed, Jul 08, 2015 at 12:29:47PM +0530, Lokesh Vutla wrote:
>
> >> + if (req->assoclen + req->cryptlen == 0) {
> >> + scatterwalk_map_and_copy(ctx->auth_tag, req->dst, 0, authlen,
> >> + 1);
> >> + return 0;
> >> + }
> >
> > How can this be right? Did you enable the selftest?
> Why not? Self tests are passed for this case.
>
> As per the equation given in GCM spec[1], we can see that
> if assoclen and cryptlen is 0, then output of GCM is just E(K, Y0)
> where Y0 = IV||(0^31)1
> I have E(K, Y0) calculated in previous step. And copying it
> to destination if assoclen and cryptlen is 0.
>
> Correct me if I am wrong.
It should be E(K, Y0) ^ GHASH(0). So unless GHASH(0) == 0, your
code doesn't work.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/7] crypto: omap-aes: Add support for GCM mode
On Tue, Jul 07, 2015 at 09:01:42PM +0530, Lokesh Vutla wrote: > This series does some basic cleanup and adds support for > AES GCM mode for omap aes driver. > > Changes since v1: > - Switched GCM to new AEAD interface Patches 1-4 and 7 applied. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/7] crypto: omap-aes: Add support for GCM mode
On Tue, Jul 07, 2015 at 09:01:48PM +0530, Lokesh Vutla wrote:
>
> +static int omap_aes_gcm_copy_buffers(struct omap_aes_dev *dd,
> + struct aead_request *req)
> +{
> + void *buf_in;
> + int pages, alen, clen, cryptlen, nsg;
> + struct crypto_aead *aead = crypto_aead_reqtfm(req);
> + unsigned int authlen = crypto_aead_authsize(aead);
> + u32 dec = !(dd->flags & FLAGS_ENCRYPT);
> + struct scatterlist *input, *assoc, tmp[2];
> +
> + alen = ALIGN(req->assoclen, AES_BLOCK_SIZE);
> + cryptlen = req->cryptlen - (dec * authlen);
> + clen = ALIGN(cryptlen, AES_BLOCK_SIZE);
> +
> + dd->sgs_copied = 0;
> +
> + nsg = !!(req->assoclen && req->cryptlen);
> +
> + assoc = &req->src[0];
> + sg_init_table(dd->in_sgl, nsg + 1);
> + if (req->assoclen) {
> + if (omap_aes_check_aligned(assoc, req->assoclen)) {
> + dd->sgs_copied |= AES_ASSOC_DATA_COPIED;
> + pages = get_order(alen);
> + buf_in = (void *)__get_free_pages(GFP_ATOMIC, pages);
> + if (!buf_in) {
> + pr_err("Couldn't allocate for unaligncases.\n");
> + return -1;
> + }
> +
> + scatterwalk_map_and_copy(buf_in, assoc, 0,
> + req->assoclen, 0);
> + memset(buf_in + req->assoclen, 0, alen - req->assoclen);
> + } else {
> + buf_in = sg_virt(req->assoc);
req->assoc is now obsolete. Did you test this code?
> +static int do_encrypt_iv(struct aead_request *req, u32 *tag)
> +{
> + struct scatterlist iv_sg;
> + struct ablkcipher_request *ablk_req;
> + struct crypto_ablkcipher *tfm;
> + struct tcrypt_result result;
> + struct omap_aes_ctx *ctx = crypto_aead_ctx(crypto_aead_reqtfm(req));
> + int ret = 0;
> +
> + tfm = crypto_alloc_ablkcipher("ctr(aes)", 0, 0);
Ugh, you cannot allocate crypto transforms in the data path. You
should allocate it in init instead. Also using ctr(aes) is overkill.
Just use aes and do the xor by hand.
> +static int omap_aes_gcm_crypt(struct aead_request *req, unsigned long mode)
> +{
> + struct omap_aes_ctx *ctx = crypto_aead_ctx(crypto_aead_reqtfm(req));
> + struct omap_aes_reqctx *rctx = aead_request_ctx(req);
> + struct crypto_aead *aead = crypto_aead_reqtfm(req);
> + unsigned int authlen = crypto_aead_authsize(aead);
> + struct omap_aes_dev *dd;
> + __be32 counter = cpu_to_be32(1);
> + int err;
> +
> + memset(ctx->auth_tag, 0, sizeof(ctx->auth_tag));
The ctx is shared memory and you must not write to it as multiple
requests can be called on the same tfm. Use rctx instead.
> + memcpy(req->iv + 12, &counter, 4);
The IV is only 12 bytes long so you're corrupting memory here.
You should use rctx here too.
> + if (req->assoclen + req->cryptlen == 0) {
> + scatterwalk_map_and_copy(ctx->auth_tag, req->dst, 0, authlen,
> + 1);
> + return 0;
> + }
How can this be right? Did you enable the selftest?
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/7] crypto: aead: Add aead_request_cast() api
On Tue, Jul 07, 2015 at 09:01:47PM +0530, Lokesh Vutla wrote:
> Add aead_request_cast() api to get pointer to aead_request
> from cryto_async_request.
>
> Signed-off-by: Lokesh Vutla
> ---
> include/crypto/internal/aead.h | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/include/crypto/internal/aead.h b/include/crypto/internal/aead.h
> index 4b25471..0423fa5 100644
> --- a/include/crypto/internal/aead.h
> +++ b/include/crypto/internal/aead.h
> @@ -157,6 +157,12 @@ static inline unsigned int
> crypto_aead_maxauthsize(struct crypto_aead *aead)
> return crypto_aead_alg_maxauthsize(crypto_aead_alg(aead));
> }
>
> +static inline struct aead_request *aead_request_cast(
> + struct crypto_async_request *req)
> +{
> + return container_of(req, struct aead_request, base);
> +}
Please drop this and use the aead_queue interface I just posted.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/10] crypto: tcrypt: Added speed tests for Async AEAD crypto alogrithms
On Mon, Jul 06, 2015 at 02:15:06PM +0530, Lokesh Vutla wrote: > > The existing AEAD test case does not do a wait_for_completion(), when > the return value is EINPROGRESS or EBUSY like it is done for acipher_speed > tests. Please fix them to do the wait. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: omap-des: Fix unmapping of dma channels
On Thu, Jul 02, 2015 at 06:33:28PM +0530, Lokesh Vutla wrote: > dma_unmap_sg() is being called twice after completing the > task. Looks like this is a copy paste error when creating > des driver. > With this the following warn appears during boot: > > [4.210457] [ cut here ] > [4.215114] WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:1080 > check_unmap+0x710/0x9a0() > [4.222899] omap-des 480a5000.des: DMA-API: device driver tries to free > DMA memory it has not allocated [device address=0xab2ce000] [size=8 > bytes] > [4.236785] Modules linked in: > [4.239860] CPU: 0 PID: 0 Comm: swapper/0 Not tainted > 3.14.39-02999-g1bc045a-dirty #182 > [4.247918] [] (unwind_backtrace) from [] > (show_stack+0x10/0x14) > [4.255710] [] (show_stack) from [] > (dump_stack+0x84/0xb8) > [4.262977] [] (dump_stack) from [] > (warn_slowpath_common+0x68/0x8c) > [4.271107] [] (warn_slowpath_common) from [] > (warn_slowpath_fmt+0x30/0x40) > [4.279854] [] (warn_slowpath_fmt) from [] > (check_unmap+0x710/0x9a0) > [4.287991] [] (check_unmap) from [] > (debug_dma_unmap_sg+0x90/0x19c) > [4.296128] [] (debug_dma_unmap_sg) from [] > (omap_des_done_task+0x1cc/0x3e4) > [4.304963] [] (omap_des_done_task) from [] > (tasklet_action+0x84/0x124) > [4.313370] [] (tasklet_action) from [] > (__do_softirq+0xf0/0x20c) > [4.321235] [] (__do_softirq) from [] > (irq_exit+0x98/0xec) > [4.328500] [] (irq_exit) from [] > (handle_IRQ+0x50/0xb0) > [4.335589] [] (handle_IRQ) from [] > (gic_handle_irq+0x28/0x5c) > > Removing the duplicate call to dma_unmap_sg(). > > Reported-by: Tomi Valkeinen > Signed-off-by: Lokesh Vutla Applied to crypto. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/10] crypto: tcrypt: Added speed tests for Async AEAD crypto alogrithms
On Thu, Jul 02, 2015 at 10:48:40AM +0530, Lokesh Vutla wrote: > Adding simple speed tests for a range of block sizes for Async AEAD crypto > algorithms. > > Signed-off-by: Lokesh Vutla What's wrong with the existing AEAD speed tests? -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/10] crypto: omap-aes: Use BIT() macro
On Thu, Jul 02, 2015 at 02:59:03AM -0500, Felipe Balbi wrote: > On Thu, Jul 02, 2015 at 10:48:34AM +0530, Lokesh Vutla wrote: > > Use BIT()/GENMASK() macros for all register definitions instead of > > hand-writing bit masks. > > > > Signed-off-by: Lokesh Vutla > > --- > > drivers/crypto/omap-aes.c | 36 ++-- > > 1 file changed, 18 insertions(+), 18 deletions(-) > > > > diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c > > index 96fc7f7..d974ab6 100644 > > --- a/drivers/crypto/omap-aes.c > > +++ b/drivers/crypto/omap-aes.c > > @@ -52,30 +52,30 @@ > > #define AES_REG_IV(dd, x) ((dd)->pdata->iv_ofs + ((x) * 0x04)) > > > > #define AES_REG_CTRL(dd) ((dd)->pdata->ctrl_ofs) > > -#define AES_REG_CTRL_CTR_WIDTH_MASK(3 << 7) > > -#define AES_REG_CTRL_CTR_WIDTH_32 (0 << 7) > > -#define AES_REG_CTRL_CTR_WIDTH_64 (1 << 7) > > -#define AES_REG_CTRL_CTR_WIDTH_96 (2 << 7) > > -#define AES_REG_CTRL_CTR_WIDTH_128 (3 << 7) > > -#define AES_REG_CTRL_CTR (1 << 6) > > -#define AES_REG_CTRL_CBC (1 << 5) > > -#define AES_REG_CTRL_KEY_SIZE (3 << 3) > > -#define AES_REG_CTRL_DIRECTION (1 << 2) > > -#define AES_REG_CTRL_INPUT_READY (1 << 1) > > -#define AES_REG_CTRL_OUTPUT_READY (1 << 0) > > -#define AES_REG_CTRL_MASK FLD_MASK(24, 2) > > +#define AES_REG_CTRL_CTR_WIDTH_MASKGENMASK(8, 7) > > +#define AES_REG_CTRL_CTR_WIDTH_32 0 > > +#define AES_REG_CTRL_CTR_WIDTH_64 BIT(7) > > +#define AES_REG_CTRL_CTR_WIDTH_96 BIT(8) > > +#define AES_REG_CTRL_CTR_WIDTH_128 GENMASK(8, 7) > > +#define AES_REG_CTRL_CTR BIT(6) > > +#define AES_REG_CTRL_CBC BIT(5) > > +#define AES_REG_CTRL_KEY_SIZE GENMASK(4, 3) > > +#define AES_REG_CTRL_DIRECTION BIT(2) > > +#define AES_REG_CTRL_INPUT_READY BIT(1) > > +#define AES_REG_CTRL_OUTPUT_READY BIT(0) > > +#define AES_REG_CTRL_MASK GENMASK(24, 2) > > this was defined a couple patches ago, why didn't you define it with > GENMASK() to start with ? Indeed, this should be folded into the earlier patch. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/10] crypto: aead: Add aead_request_cast() api
On Thu, Jul 02, 2015 at 10:48:33AM +0530, Lokesh Vutla wrote:
> Add aead_request_cast() api to get pointer to aead_request
> from cryto_async_request.
>
> Signed-off-by: Lokesh Vutla
> ---
> include/linux/crypto.h |6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/include/linux/crypto.h b/include/linux/crypto.h
> index 10df5d2..20fac3d 100644
> --- a/include/linux/crypto.h
> +++ b/include/linux/crypto.h
> @@ -1460,6 +1460,12 @@ static inline void aead_request_set_tfm(struct
> aead_request *req,
> req->base.tfm = crypto_aead_tfm(crypto_aead_crt(tfm)->base);
> }
>
> +static inline struct aead_request *aead_request_cast(
> + struct crypto_async_request *req)
> +{
> + return container_of(req, struct aead_request, base);
> +}
> +
This should go into include/crypto/internal/aead.h.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] crypto: omap-aes: Add support for lengths not aligned with AES_BLOCK_SIZE
On Thu, Jul 02, 2015 at 10:48:31AM +0530, Lokesh Vutla wrote: > OMAP AES driver returns an error if the data is not aligned with > AES_BLOCK_SIZE bytes. > But OMAP AES hw allows data input upto 1 byte aligned, but still > zeros are to be appended and complete AES_BLOCK_SIZE has to be written. > And correct length has to be passed in LENGTH field. > Adding support for inputs not aligned with AES_BLOCK_SIZE. > > Signed-off-by: Lokesh Vutla Please explain the purpose of this patch. As it stands your change log makes no sense. If you're relaxing the check for GCM support then you should state that explicitly. Because partial blocks make no sense otherwise. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/10] crypto: omap-aes: gmc: Add algo info
On Thu, Jul 02, 2015 at 10:48:38AM +0530, Lokesh Vutla wrote: > Now the driver supports gcm mode, add omap-aes-gcm > algo info to omap-aes driver. > > Signed-off-by: Lokesh Vutla You're using the old AEAD interface. We are now moving to the new AEAD interface so I will not be accepting any new implementations using the old interface. Please convert your driver over to the new interface. Also please merge your GCM patches into a single patch. Splitting out bug fixes makes no sense. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] crypto: omap-sham: Add the offset of sg page to vaddr
On Thu, Apr 02, 2015 at 03:32:45PM +0530, Lokesh Vutla wrote: > kmap_atomic() gives only the page address of the input page. > Driver should take care of adding the offset of the scatterlist > within the page to the returned page address. > omap-sham driver is not adding the offset to page and directly operates > on the return vale of kmap_atomic(), because of which the following > error comes when running crypto tests: > > : d9 a1 1b 7c aa 90 3b aa 11 ab cb 25 00 b8 ac bf > [2.338169] 0010: c1 39 cd ff 48 d0 a8 e2 2b fa 33 a1 > [2.344008] alg: hash: Chunking test 1 failed for omap-sha256 > > So adding the scatterlist offset to vaddr. > > Signed-off-by: Lokesh Vutla Patch applied. Thanks! -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: omap-aes: Fix support for unequal lengths
On Tue, Mar 31, 2015 at 09:52:25AM +0530, Lokesh Vutla wrote:
> For cases where total length of an input SGs is not same as
> length of the input data for encryption, omap-aes driver
> crashes. This happens in the case when IPsec is trying to use
> omap-aes driver.
>
> To avoid this, we copy all the pages from the input SG list
> into a contiguous buffer and prepare a single element SG list
> for this buffer with length as the total bytes to crypt, which is
> similar thing that is done in case of unaligned lengths.
>
> Fixes: 6242332ff2f3 ("crypto: omap-aes - Add support for cases of unaligned
> lengths")
> Signed-off-by: Lokesh Vutla
Applied.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: omap-sham: Use pm_runtime_irq_safe()
On Tue, Mar 31, 2015 at 09:52:24AM +0530, Lokesh Vutla wrote: > omap_sham_handle_queue() can be called as part of done_task tasklet. > During this its atomic and any calls to pm functions cannot sleep. > > But there is a call to pm_runtime_get_sync() (which can sleep) in > omap_sham_handle_queue(), because of which the following appears: > " [ 116.169969] BUG: scheduling while atomic: kworker/0:2/2676/0x0100" > > Add pm_runtime_irq_safe() to avoid this. > > Signed-off-by: Lokesh Vutla Applied. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: omap-sham: Check for HIGHMEM before mapping SG pages
On Tue, Mar 31, 2015 at 09:52:23AM +0530, Lokesh Vutla wrote:
> Commit 26a05489ee0e ("crypto: omap-sham - Map SG pages if they are HIGHMEM
> before accessing")
> says that HIGHMEM pages may not be mapped so we must
> kmap them before accessing, but it doesn't check whether the
> corresponding page is in highmem or not. Because of this all
> the crypto tests are failing.
>
> : d9 a1 1b 7c aa 90 3b aa 11 ab cb 25 00 b8 ac bf
> [2.338169] 0010: c1 39 cd ff 48 d0 a8 e2 2b fa 33 a1
> [2.344008] alg: hash: Chunking test 1 failed for omap-sha256
>
> So Checking for HIGHMEM before mapping SG pages.
>
> Fixes: 26a05489ee0 ("crypto: omap-sham - Map SG pages if they are HIGHMEM
> before accessing")
> Signed-off-by: Lokesh Vutla
> ---
> drivers/crypto/omap-sham.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
> index 3c76696..ace5852 100644
> --- a/drivers/crypto/omap-sham.c
> +++ b/drivers/crypto/omap-sham.c
> @@ -639,13 +639,17 @@ static size_t omap_sham_append_sg(struct
> omap_sham_reqctx *ctx)
> const u8 *vaddr;
>
> while (ctx->sg) {
> - vaddr = kmap_atomic(sg_page(ctx->sg));
> + if (PageHighMem(sg_page(ctx->sg)))
> + vaddr = kmap_atomic(sg_page(ctx->sg));
> + else
> + vaddr = sg_virt(ctx->sg);
This is completely bogus. kmap_atomic should be identical to
sg_virt(sg_page()) for the lowmem case.
So either your architecture is broken (because the same problem
would obviously affect the core crypto code which does exactly
the same thing), or there is some other bug causing the selftest
to fail.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v3] hwrng: omap - Change RNG_CONFIG_REG to RNG_CONTROL_REG when, checking and disabling TRNG
On Fri, Feb 20, 2015 at 03:37:21PM +1100, Andre Wolokita wrote: > In omap4_rng_init(), a check of bit 10 of the RNG_CONFIG_REG is done to > determine > whether the RNG is running. This is suspicious firstly due to the use of > RNG_CONTROL_ENABLE_TRNG_MASK and secondly because the same mask is written to > RNG_CONTROL_REG after configuration of the FROs. Similar suspicious logic is > repeated in omap4_rng_cleanup() when RNG_CONTROL_REG masked with > RNG_CONTROL_ENABLE_TRNG_MASK is read, the same mask bit is cleared, and then > written to RNG_CONFIG_REG. Unless the TRNG is enabled with one bit in > RNG_CONTROL > and disabled with another in RNG_CONFIG and these bits are mirrored in some > way, > I believe that the TRNG is not really shutting off, leaving the FROs running > indefinitely which, in an extreme case, could lead to degredation of the > hardware and potentially reduce the level of entropy generated. > > Apart from the strange logic, I have reason to suspect that the OMAP4 related > code in this driver is driving an Inside Secure IP hardware RNG and strongly > suspect that bit 10 of RNG_CONFIG_REG is one of the bits configuring the > sampling rate of the FROs. This option is by default set to 0 and is not being > set anywhere in omap-rng.c. Reading this bit during omap4_rng_init() will > always return 0. It will remain 0 because ~(value of TRNG_MASK in control) > will > always be 0, because the TRNG is never shut off. This is of course presuming > that the OMAP4 features the Inside Secure IP, which I strongly suspect. > > I'm interested in knowing what the guys at TI think about this, as only they > can confirm or deny the detailed structure of these registers. > > Signed-off-by: Andre Wolokita Your patch is white-space damaged. Please fix and resubmit. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] crypto: omap-des - handle error of pm_runtime_get_sync
On Tue, Apr 15, 2014 at 12:51:43PM -0500, Joel Fernandes wrote: > On 04/15/2014 12:18 PM, Nishanth Menon wrote: > > On 04/15/2014 12:06 PM, Joachim Eastwood wrote: > >> On 15 April 2014 18:58, Nishanth Menon wrote: > >>> pm_runtime_get_sync may not always succeed depending on SoC involved. > >>> So handle the error appropriately ensuring usage_count is accurate in > >>> case of failure. > >>> > >>> Signed-off-by: Nishanth Menon > >>> --- > >>> V2: > >>> - review fixes, print function names in error log as well. > >>> > >>> V1: https://patchwork.kernel.org/patch/3993861/ > >>> drivers/crypto/omap-des.c | 26 +++--- > >>> 1 file changed, 23 insertions(+), 3 deletions(-) > >>> > >> > >> Fixes the runtime warning from omap_l3_noc when omap-des is built-in > >> on my VAR-SOM-OM44 (OMAP4460) board. > >> > >> Tested-by: Joachim Eastwood > > > > Thanks Joachim. Looks like in my hurry, I missed proper > > acknowledgement of your report. adding the following for patchworks to > > pickup. > > > > Reported-by: Joachim Eastwood > > > > Acked-by: Joel Fernandes Patch applied. Thanks! -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] crypto: omap-sham: Map SG pages if they are HIGHMEM before accessing
On Fri, Mar 07, 2014 at 10:28:46AM -0600, Joel Fernandes wrote: > HIGHMEM pages may not be mapped so we must kmap them before accessing. > This resolves a random OOPs error that was showing up during OpenSSL SHA > tests. > > Signed-off-by: Joel Fernandes Patch applied. Thanks! -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] crypto: omap-sham: kmap SG pages before appending
On Wed, Mar 05, 2014 at 09:42:38AM -0600, Joel Fernandes wrote: > > In my testing it wasn't called from softirq, I'm using cryptodev which is > called from openssl through ioctl, here is a traceback (sorry about wrap): > > [] (cryptodev_ioctl+0x282/0x59c [cryptodev]) > [ 220.015390] [] (cryptodev_ioctl+0x282/0x59c [cryptodev]) from > [] (do_vfs_ioctl+0x61/0x41c) > [ 220.025909] [] (do_vfs_ioctl+0x61/0x41c) from [] > (SyS_ioctl+0x4b/0x50) > [ 220.034602] [] (SyS_ioctl+0x4b/0x50) from [] > (ret_fast_syscall+0x1/0x46) > [ 220.045254] CPU: 0 PID: 1798 Comm: openssl Tainted: G O > 3.12.9-00581-g5fa084c-dirty #32 > [ 220.054636] [] (unwind_backtrace+0x1/0x9c) from [] > (show_stack+0x11/0x14) > [ 220.063619] [] (show_stack+0x11/0x14) from [] > (dump_stack+0x4b/0x60) > [ 220.072144] [] (dump_stack+0x4b/0x60) from [] > (omap_sham_update+0x1f/0xa4) > [ 220.081214] [] (omap_sham_update+0x1f/0xa4) from [] > (cryptodev_hash_update+0x26/0x80 [cryptodev]) > > > Could you suggest, what other place is update() called in softirq context? > I may be missing something. IPsec may call this from softirq context. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] crypto: omap-sham: kmap SG pages before appending
On Wed, Mar 05, 2014 at 04:18:12AM +, Fernandes, Joel wrote:
>
>
> > On Mar 4, 2014, at 8:00 PM, "Herbert Xu"
> > wrote:
> >
> >> On Tue, Mar 04, 2014 at 12:30:54PM -0600, Joel Fernandes wrote:
> >> HIGHMEM pages may not be mapped so we must kmap them before accessing.
> >> This resolves a random OOPs error that was showing up during OpenSSL SHA
> >> tests.
> >>
> >> Signed-off-by: Joel Fernandes
> >> Cc: Herbert Xu
> >> ---
> >> v2 changes:
> >>- don't check for HIGHMEM, kmap/kunmap do them anyway (Thanks Herbert).
> >>
> >> drivers/crypto/omap-sham.c |8 +++-
> >> 1 file changed, 7 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
> >> index e45aaaf..207eac1 100644
> >> --- a/drivers/crypto/omap-sham.c
> >> +++ b/drivers/crypto/omap-sham.c
> >> @@ -636,11 +636,17 @@ static size_t omap_sham_append_buffer(struct
> >> omap_sham_reqctx *ctx,
> >> static size_t omap_sham_append_sg(struct omap_sham_reqctx *ctx)
> >> {
> >>size_t count;
> >> +const u8 *vaddr;
> >>
> >>while (ctx->sg) {
> >> +vaddr = kmap(sg_page(ctx->sg));
> >
> > Are you sure you can safely use kmap here as opposed to kmap_atomic?
>
> Yes I made sure it is not called in interrupt context and also tested the
> patch.
What about omap_sham_update => omap_sham_append_sg? As the former
can be called in softirq context what is preventing it from calling
kmap?
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] crypto: omap-sham: kmap SG pages before appending
On Tue, Mar 04, 2014 at 12:30:54PM -0600, Joel Fernandes wrote:
> HIGHMEM pages may not be mapped so we must kmap them before accessing.
> This resolves a random OOPs error that was showing up during OpenSSL SHA
> tests.
>
> Signed-off-by: Joel Fernandes
> Cc: Herbert Xu
> ---
> v2 changes:
> - don't check for HIGHMEM, kmap/kunmap do them anyway (Thanks Herbert).
>
> drivers/crypto/omap-sham.c |8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
> index e45aaaf..207eac1 100644
> --- a/drivers/crypto/omap-sham.c
> +++ b/drivers/crypto/omap-sham.c
> @@ -636,11 +636,17 @@ static size_t omap_sham_append_buffer(struct
> omap_sham_reqctx *ctx,
> static size_t omap_sham_append_sg(struct omap_sham_reqctx *ctx)
> {
> size_t count;
> + const u8 *vaddr;
>
> while (ctx->sg) {
> + vaddr = kmap(sg_page(ctx->sg));
Are you sure you can safely use kmap here as opposed to kmap_atomic?
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/2] Introduce omap-des driver for OMAP SoCs
On Fri, Feb 14, 2014 at 10:48:41AM -0600, Joel Fernandes wrote: > Here are revised patches for omap-des driver addressing review comments at: > https://lkml.org/lkml/2013/8/30/116 > > Joel Fernandes (2): > crypto: omap-des: Add omap-des driver for OMAP4/AM43xx > crypto: omap-des: Add config and build options Both patches applied. Thanks! -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: omap-sham: Fix Polling mode for larger blocks
On Wed, Dec 18, 2013 at 07:03:33PM +0530, Lokesh Vutla wrote: > Command "tcrypt sec=1 mode=403" give the follwoing error for Polling > mode: > root@am335x-evm:/# insmod tcrypt.ko sec=1 mode=403 > [...] > > [ 346.982754] test 15 ( 4096 byte blocks, 1024 bytes per update, 4 > updates): 4352 opers/sec, 17825792 bytes/sec > [ 347.992661] test 16 ( 4096 byte blocks, 4096 bytes per update, 1 > updates): 7095 opers/sec, 29061120 bytes/sec > [ 349.002667] test 17 ( 8192 byte blocks, 16 bytes per update, 512 > updates): > [ 349.010882] Unable to handle kernel NULL pointer dereference at virtual > address > [ 349.020037] pgd = ddeac000 > [ 349.022884] [] *pgd=9dcb4831, *pte=, *ppte= > [ 349.029816] Internal error: Oops: 17 [#1] PREEMPT SMP ARM > [ 349.035482] Modules linked in: tcrypt(+) > [ 349.039617] CPU: 0 PID: 1473 Comm: insmod Not tainted > 3.12.4-01566-g6279006-dirty #38 > [ 349.047832] task: dda91540 ti: ddcd2000 task.ti: ddcd2000 > [ 349.053517] PC is at omap_sham_xmit_dma+0x6c/0x238 > [ 349.058544] LR is at omap_sham_xmit_dma+0x38/0x238 > [ 349.063570] pc : []lr : []psr: 2013 > [ 349.063570] sp : ddcd3c78 ip : fp : 9d8980b8 > [ 349.075610] r10: r9 : r8 : > [ 349.081090] r7 : 1000 r6 : dd898000 r5 : 0040 r4 : ddb10550 > [ 349.087935] r3 : 0004 r2 : 0010 r1 : 53100080 r0 : > [ 349.094783] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment > user > [ 349.102268] Control: 10c5387d Table: 9deac019 DAC: 0015 > [ 349.108294] Process insmod (pid: 1473, stack limit = 0xddcd2248) > > [...] > > This is because polling_mode is not enabled for ctx without FLAGS_FINUP. > > For polling mode the bufcnt is made 0 unconditionally. But it should be made 0 > only if it is a final update or a total is not zero(This condition is similar > to what is done in DMA case). Because of this wrong hashes are produced. > > Fixing the same. > > Signed-off-by: Lokesh Vutla Patch applied. Thanks! -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: omap-aes: add error check for pm_runtime_get_sync
On Tue, Dec 03, 2013 at 07:43:13PM -0600, Nishanth Menon wrote: > The AES driver currently assumes that pm_runtime_get_sync will always > succeed, which may not always be true, so add error handling for the > same. > > This scenario was reported in the following bug: > place. https://bugzilla.kernel.org/show_bug.cgi?id=66441 > > Reported-by: Tobias Jakobi > Signed-off-by: Nishanth Menon Patch applied. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: omap-sham - Only release DMA channel if successfully requested
On Tue, Nov 12, 2013 at 01:12:27PM -0700, Mark A. Greer wrote: > In omap_sham_probe() and omap_sham_remove(), 'dd->dma_lch' > is released without checking to see if it was successfully > requested or not. This is a bug and was identified and > reported by Dan Carpenter here: > > http://www.spinics.net/lists/devicetree/msg11023.html > > Add code to only release 'dd->dma_lch' when its not NULL > (that is, when it was successfully requested). > > Reported-by: Dan Carpenter > CC: Joel Fernandes > Signed-off-by: Mark A. Greer Patch applied. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] hwrng: OMAP3 ROM Random Number Generator support
On Mon, Nov 18, 2013 at 10:51:30PM +0100, Pali Rohár wrote: > On Wednesday 16 October 2013 14:57:34 Herbert Xu wrote: > > On Tue, Oct 08, 2013 at 12:04:09PM -0700, Tony Lindgren wrote: > > > * Pali Rohár [130920 06:33]: > > > > This driver provides kernel-side support for the Random > > > > Number Generator hardware found on OMAP34xx processors. > > > > > > > > This driver comes from Maemo 2.6.28 kernel and was tested > > > > on Nokia RX-51. It is platform device because it needs > > > > board specific function for smc calls. > > > > > > This one is should be merged via the hw_random patches > > > seprately: > > > > > > Acked-by: Tony Lindgren > > > > Patch applied. Thanks! > > Hello, I still do not see this patch (2/3) in linus tree. But > patch 1/3 and 3/3 are already merged. So is there any problem? 2/3 is still in my tree so when Linus pulls it it'll be there. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: omap-aes: Fix CTR mode counter length
On Tue, Oct 29, 2013 at 05:37:38PM -0500, Joel Fernandes wrote: > NIST vectors for CTR mode in testmgr.h assume the entire IV as the counter. To > get correct results that match the output of these vectors, we need to set the > counter length correctly. > > Signed-off-by: Joel Fernandes Patch applied. Thanks! -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] hwrng: OMAP3 ROM Random Number Generator support
On Tue, Oct 08, 2013 at 12:04:09PM -0700, Tony Lindgren wrote: > * Pali Rohár [130920 06:33]: > > This driver provides kernel-side support for the Random Number > > Generator hardware found on OMAP34xx processors. > > > > This driver comes from Maemo 2.6.28 kernel and was tested on Nokia RX-51. > > It is platform device because it needs board specific function for smc > > calls. > > This one is should be merged via the hw_random patches seprately: > > Acked-by: Tony Lindgren Patch applied. Thanks! -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] hwrng: reorder OMAP TRNG driver code
On Wed, Aug 21, 2013 at 10:51:16AM +0530, Lokesh Vutla wrote: > Hi Olof, > On Tuesday 20 August 2013 11:37 PM, Olof Johansson wrote: > > The newly added omap4 support in the driver was added without > > consideration for building older configs. When building omap1_defconfig, > > it resulted in: > > > > drivers/char/hw_random/omap-rng.c:190:12: warning: 'omap4_rng_init' defined > > but not used [-Wunused-function] > > drivers/char/hw_random/omap-rng.c:215:13: warning: 'omap4_rng_cleanup' > > defined but not used [-Wunused-function] > > drivers/char/hw_random/omap-rng.c:251:20: warning: 'omap4_rng_irq' defined > > but not used [-Wunused-function] > > > > Move the code around so it is grouped with its operations struct, which > > for the omap4 case means also under the #ifdef CONFIG_OF, where it needs > > to be. > > > Missed testing this. Thanks for the patch. > Reviewed-by: Lokesh Vutla Patch applied. Thanks! -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/14] crypto: omap-aes: Improve DMA, add PIO mode and support for AM437x
On Sat, Aug 17, 2013 at 09:42:21PM -0500, Joel Fernandes wrote: > Following patch series rewrites the DMA code to be cleaner and faster. > Earlier, > only a single SG was used for DMA purpose, and the SG-list passed from the > crypto layer was being copied and DMA'd one entry at a time. This turns out to > be quite inefficient and lot of code, we replace it with much simpler approach > that directly passes the SG-list from crypto to the DMA layers for cases where > possible. For all cases where such a direct passing of SG list is not > possible, > we create a new SG-list and do the copying. This is still better than before, > as > we create an SG list as big as needed and not just 1-element list. > > We also add PIO mode support to the driver, and switch to it whenever the DMA > channel allocation is not available. This also has shown to give good > performance > for small blocks as shown below. > > Tests have been performed on AM335x, OMAP4 and AM437x SoCs. > > Below is a sample run on AM335x SoC (beaglebone board), showing > performance improvement (20% for 8K blocks): All applied. Thanks! -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] crypto: omap-sham: Misc updates for driver
On Tue, Aug 20, 2013 at 08:32:33PM +0530, Lokesh Vutla wrote: > This patch series updates the following for the driver: > -> Enable polling mode if DMA fails. > -> Correct the DMA burst size. > > Lokesh Vutla (2): > crypto: omap-sham: Enable Polling mode if DMA fails > crypto: omap-sham: correct dma burst size Both patches applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] hwrng: OMAP: Updates for OMAP RNG module
On Mon, Aug 05, 2013 at 08:17:17PM +0530, Lokesh Vutla wrote: > This patch series adds support for OMAP4 version of RNG module. > This module produce a 64 bit random number and also allows to > de tune FROs when repeated pattern is coming out of FROs. > This series also has few fixes for the driver. > > Lokesh Vutla (6): > hwrng: OMAP: Use module_platform_driver macro > hwrng: OMAP: Convert to devm_kzalloc() > hwrng: OMAP: Remove duplicated function call > hwrng: OMAP: Add device tree support > ARM: OMAP2+: Only manually add hwmod data when DT not used. > hwrng: OMAP: Add OMAP4 TRNG support All applied. Thanks! -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] crypto: omap-sham: Add support for SHA384/SHA512 for OMAP5/AM43xx Soc's
On Fri, Jul 26, 2013 at 12:29:13PM +0530, Lokesh Vutla wrote: > This patch series adds support for SHA348 and SHA512 in addition to MD5, > SHA1, SHA224 SHA256 that the omap sha module supports. Also adding the pdata > for OMAP5 and AM43xx Soc's. > And using devm_* calls to make cleanup paths simpler. All applied. Thanks! -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] OMAP: AES: Don't idle/start AES device between Encrypt operations
On Tue, May 28, 2013 at 07:02:55PM -0500, Joel A Fernandes wrote: > Calling runtime PM API for every block causes serious perf hit to > crypto operations that are done on a long buffer. > As crypto is performed on a page boundary, encrypting large buffers can > cause a series of crypto operations divided by page. The runtime PM API > is also called those many times. > > We call runtime_pm_get_sync only at beginning on the session (cra_init) > and runtime_pm_put at the end. This result in upto a 50% speedup as below. > This doesn't make the driver to keep the system awake as runtime get/put > is only called during a crypto session which completes usually quickly. > > Before: > root@beagleboard:~# time -v openssl speed -evp aes-128-cbc > Doing aes-128-cbc for 3s on 16 size blocks: 13310 aes-128-cbc's in 0.01s > Doing aes-128-cbc for 3s on 64 size blocks: 13040 aes-128-cbc's in 0.04s > Doing aes-128-cbc for 3s on 256 size blocks: 9134 aes-128-cbc's in 0.03s > Doing aes-128-cbc for 3s on 1024 size blocks: 8939 aes-128-cbc's in 0.01s > Doing aes-128-cbc for 3s on 8192 size blocks: 4299 aes-128-cbc's in 0.00s > > After: > root@beagleboard:~# time -v openssl speed -evp aes-128-cbc > Doing aes-128-cbc for 3s on 16 size blocks: 18911 aes-128-cbc's in 0.02s > Doing aes-128-cbc for 3s on 64 size blocks: 18878 aes-128-cbc's in 0.02s > Doing aes-128-cbc for 3s on 256 size blocks: 11878 aes-128-cbc's in 0.10s > Doing aes-128-cbc for 3s on 1024 size blocks: 11538 aes-128-cbc's in 0.05s > Doing aes-128-cbc for 3s on 8192 size blocks: 4857 aes-128-cbc's in 0.03s > > While at it, also drop enter and exit pr_debugs, in related code. tracers > can be used for that. > > Tested on a Beaglebone (AM335x SoC) board. > > v3 changes: > Refreshed patch on kernel v3.10-rc3 > > Signed-off-by: Joel A Fernandes Patch applied. Thanks! -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] OMAP: AES: Don't idle/start AES device between Encrypt operations
On Tue, May 14, 2013 at 03:07:47AM +, Joel A Fernandes wrote: > Calling runtime PM API for every block causes serious perf hit to > crypto operations that are done on a long buffer. > As crypto is performed on a page boundary, encrypting large buffers can > cause a series of crypto operations divided by page. The runtime PM API > is also called those many times. > > We call runtime_pm_get_sync only at beginning on the session (cra_init) > and runtime_pm_put at the end. This result in upto a 50% speedup as below. > This doesn't make the driver to keep the system awake as runtime get/put > is only called during a crypto session which completes usually quickly. > > Before: > root@beagleboard:~# time -v openssl speed -evp aes-128-cbc > Doing aes-128-cbc for 3s on 16 size blocks: 13310 aes-128-cbc's in 0.01s > Doing aes-128-cbc for 3s on 64 size blocks: 13040 aes-128-cbc's in 0.04s > Doing aes-128-cbc for 3s on 256 size blocks: 9134 aes-128-cbc's in 0.03s > Doing aes-128-cbc for 3s on 1024 size blocks: 8939 aes-128-cbc's in 0.01s > Doing aes-128-cbc for 3s on 8192 size blocks: 4299 aes-128-cbc's in 0.00s > > After: > root@beagleboard:~# time -v openssl speed -evp aes-128-cbc > Doing aes-128-cbc for 3s on 16 size blocks: 18911 aes-128-cbc's in 0.02s > Doing aes-128-cbc for 3s on 64 size blocks: 18878 aes-128-cbc's in 0.02s > Doing aes-128-cbc for 3s on 256 size blocks: 11878 aes-128-cbc's in 0.10s > Doing aes-128-cbc for 3s on 1024 size blocks: 11538 aes-128-cbc's in 0.05s > Doing aes-128-cbc for 3s on 8192 size blocks: 4857 aes-128-cbc's in 0.03s > > While at it, also drop enter and exit pr_debugs, in related code. tracers > can be used for that. > > Tested on a Beaglebone (AM335x SoC) board. > > Signed-off-by: Joel A Fernandes I like your patch but it doesn't apply against the current cryptodev tree. Please rebase and repost. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: omap-sham - Fix compile errors when CONFIG_OF not defined
On Tue, Jan 15, 2013 at 01:53:02PM -0700, Mark A. Greer wrote: > From: "Mark A. Greer" > > Fix the compile errors created by commit 2545e8d > (crypto: omap-sham - Add Device Tree Support) > when CONFIG_OF is not defined. This includes > changing omap_sham_get_res_dev() to omap_sham_get_res_of() > and creating an empty version of omap_sham_of_match[]. > > Signed-off-by: Mark A. Greer Also applied. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/10] crypto: omap-aes - Updates & New Functionality
On Tue, Jan 08, 2013 at 11:57:37AM -0700, Mark A. Greer wrote: > From: "Mark A. Greer" > > Changes from v1: > - Addressed comments by Russ Dill by defining omap_aes_of_match[] to >contain an empty entry (end of list indicator) and defining >omap_aes_get_res_of() instead of incorrectly defining >omap_aes_get_res_dev() when CONFIG_OF is not defined. > > This patch series does several things to the omap-aes crypto > driver including: > - converting to use pm_runtime > - adding suspend/resume support > - converting to use dmaengine API > - adding device tree support > - adding OMAP4/AM33XX support > - adding CTR support > - some misc. cleanups > > The patches are based on the current k.o. 54e37b8 (Merge tag > 'vfio-for-v3.8-v2' of git://github.com/awilliam/linux-vfio), plus: > - the ARM hwmod, etc patches from >"[PATCH 00/15] OMAP SHAM & AES Crypto Updates" >(http://marc.info/?l=linux-omap&m=135610732120447&w=2) > - the EDMA dmaengine patches submitted by Matt Porter >"[RFC PATCH v3 00/16] DMA Engine support for AM33XX]" >(https://lkml.org/lkml/2012/10/18/256) > - some misc patches required by the EDMA patches > - a hack to fix the compilation error that the current k.o. kernel has > > A working examle is here: > > g...@github.com:mgreeraz/linux-mag.git submitted/crypto/aes > > This patch series does several things to the omap-aes crypto > driver including: > - converting to use pm_runtime > - adding suspend/resume support > - converting to use dmaengine API > - adding device tree support > - adding OMAP4/AM33XX support > - adding CTR support > - some misc. cleanups > > The patches are based on the current k.o. kernel, plus: > - the ARM hwmod, etc patches from >"[PATCH 00/15] OMAP SHAM & AES Crypto Updates" >(http://marc.info/?l=linux-omap&m=135610732120447&w=2) > - the EDMA dmaengine patches submitted by Matt Porter >"[RFC PATCH v3 00/16] DMA Engine support for AM33XX]" >(https://lkml.org/lkml/2012/10/18/256) > - some misc patches required by the EDMA patches > - a hack to fix the compilation error that the current k.o. kernel has All applied. Thanks! -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9] crypto: omap-sham - Updates & New Functionality
On Fri, Dec 21, 2012 at 10:04:00AM -0700, Mark A. Greer wrote: > From: "Mark A. Greer" > > [This supersedes the omap-sham driver patches sent in the > "crypto: omap-sham updates" series sent a few weeks ago.] > > This patch series does several things to the omap-sham crypto > driver including: > - converting to use pm_runtime > - adding suspend/resume support > - converting to use dmaengine API > - adding device tree support > - adding OMAP4/AM33XX support > - adding SHA224 and SHA256 support > - some minor cleanups > > The patches are based on the current k.o. kernel, plus: > - the ARM hwmod, etc patches from >"[PATCH 00/15] OMAP SHAM & AES Crypto Updates" >(http://marc.info/?l=linux-omap&m=135610732120447&w=2) > - the EDMA dmaengine patches submitted by Matt Porter >"[RFC PATCH v3 00/16] DMA Engine support for AM33XX]" >(https://lkml.org/lkml/2012/10/18/256) > - some misc patches required by the EDMA patches > - a hack to fix the compilation error that the current k.o. kernel has All applied. Thaks a lot! -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] hwrng/ARM: OMAP: convert to use runtime PM
On Thu, Aug 30, 2012 at 01:27:08PM -0700, Tony Lindgren wrote: > * Paul Walmsley [120827 16:39]: > > This series converts the OMAP hardware random number generator driver > > to use runtime PM. Hardware integration data is added for OMAP2xxx > > systems. I'm pretty sure this device is available on other OMAP chips > > too, but may require some experimentation with the integration details. > > Good to hear. I believe that at some point this got moved to be > only accessible in the secure mode on later omaps? > > > There are still a few rough edges with this series. Something is > > still not right with the reset behavior on OMAP2430, at least. But it > > would be good to get acks from the hwrng folks for the three patches that > > touch files in that directory. Will continue with the testing process > > here. > > Yes Matt & Herbert, care to ack the drivers/char/hw_random related changes? Acked-by: Herbert Xu > This series will conflict with the planned ARM common zImage changes > that we have planned so I'd like to merge them via the ARM soc tree. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/11] crypto: omap-sham driver fixes
On Thu, Jun 02, 2011 at 09:10:02PM +0300, Dmitry Kasatkin wrote: > Hi, > > Recently we got crashes few times after some other patches to 2.6.32 kernel. > This patch set greatly prevents race condition situations. > No crashes are noticed any more. > Now the driver should be ok for multi core as well. All applied to cryptodev. Thanks Dmitry! -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] crypto: omap-sham driver fixes
On Wed, Apr 20, 2011 at 01:34:54PM +0300, Dmitry Kasatkin wrote: > Hi, > > Here is few patches with couple of important fixes... All applied. Thanks! -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] omap-sham: backlog handling fix
On Wed, Dec 29, 2010 at 11:58:28AM +0200, Dmitry Kasatkin wrote: > Previous commit "removed redundant locking" introduced > a bug in handling backlog. > In certain cases, when async request complete callback will > call complete() on -EINPROGRESS code, it will cause uncompleted requests. > It does not happen in implementation similar to crypto test manager, > but it will happen in implementation similar to dm-crypt. > Backlog needs to be checked before dequeuing next request. > > Signed-off-by: Dmitry Kasatkin Patch applied. Thanks Dmitry. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 0/6] omap-aes off mode and error handling fixes
On Tue, Nov 30, 2010 at 10:13:26AM +0200, Dmitry Kasatkin wrote: > Changes to v1: > - omap type specific handling removed > - fixed backlog handling bug in "redundunt locking is removed" > - aes module initialized once per request instead of dma transaction > more efficient and right way to do it > - checkpatch fixes in separate patch All applied. Thanks Dmitry! -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/8] omap-sham: OMAP SHA1/MD5 driver fixes and improvements
On Fri, Nov 19, 2010 at 04:04:21PM +0200, Dmitry Kasatkin wrote: > Hi, > > Here is a set of patches which provides fixes and improvements. > > Based on Herbert feedback it also includes fixes so that calling final() > is not mandatory. All applied. Thanks Dmitry! -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: manual merge of the crypto tree with the omap tree
On Mon, Sep 27, 2010 at 02:33:00PM +1000, Stephen Rothwell wrote:
> Hi Herbert,
>
> Today's linux-next merge of the crypto tree got a conflict in
> arch/arm/mach-omap2/devices.c between commit
> 5d14f2792f9d63c5d25903bd048017c4b53c7d9a ("omap: crypto: updates to
> enable omap aes") from the omap tree and commit
> b744c679f62b368cb94c21c1dcd4618e42d88d63 ("crypto: updates to enable omap
> aes") from the crypto tree.
>
> Two versions of the same patch. The version in the omap tree has been
> updated, so I used that.
Thanks for the note Stephen.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] crypto: omap-sham: Adjust DMA parameters
On Thu, Sep 02, 2010 at 05:17:35PM +0300, Dmitry Kasatkin wrote: > From: Samu Onkalo > > DMA is set to use burst mode also for source channel. It should > descrease memory bandwidth needs. > > DMA synchronization is set to use prefetch mechanism. SHAM block is behind > L4 bus and it doesn't have fifo. SHAM block is stalling as long as the new > data is available. It takes time to fetch data from memory and transfer it > via L4 bus. With prefetch enabled, data is waiting in DMA fifo and SHAM block > receives new data block faster. > This increases SHA processing speed up to 30 percent depending on the > bus / memory load. > > Signed-off-by: Samu Onkalo > Signed-off-by: Dmitry Kasatkin Patch applied. Thanks! -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] omap-aes: OMAP2/3 AES HW accelerator driver
On Fri, Aug 20, 2010 at 04:44:45PM +0300, Dmitry Kasatkin wrote: > This set of patches provides implementation of the driver for > OMAP2/3 AES hw accelerator. > Both patches applied. Thanks! -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] crypto: updates to enable omap aes
On Tue, Aug 31, 2010 at 11:52:27AM +0300, Dmitry Kasatkin wrote: > Hi, > > Does anyone want to comment on this? Please be patient. Your patches are still in my queue. Resending them is only going to slow them down. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] omap-sham: OMAP macros corrected
On Mon, May 10, 2010 at 10:03:29AM -0700, Tony Lindgren wrote:
>
> Yeah please go ahead and add it. If we run into merge problems with
> devices.c, we move some patches into omap for-next branch.
>
> Acked-by: Tony Lindgren
Applied to cryptodev. Thanks everyone!
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~}
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] omap-sham: OMAP macros corrected
On Mon, May 10, 2010 at 03:07:55PM +0300, Dmitry Kasatkin wrote:
> Signed-off-by: Dmitry Kasatkin
> ---
> arch/arm/mach-omap2/devices.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> index beac46c..79dbf04 100644
> --- a/arch/arm/mach-omap2/devices.c
> +++ b/arch/arm/mach-omap2/devices.c
> @@ -456,7 +456,7 @@ static inline void omap_init_mcspi(void) {}
>
> #if defined(CONFIG_CRYPTO_DEV_OMAP_SHAM) ||
> defined(CONFIG_CRYPTO_DEV_OMAP_SHAM_MODULE)
>
> -#ifdef CONFIG_ARCH_OMAP24XX
> +#ifdef CONFIG_ARCH_OMAP2
> static struct resource omap2_sham_resources[] = {
> {
> .start = OMAP24XX_SEC_SHA1MD5_BASE,
> @@ -474,7 +474,7 @@ static int omap2_sham_resources_sz =
> ARRAY_SIZE(omap2_sham_resources);
> #define omap2_sham_resources_sz 0
> #endif
>
> -#ifdef CONFIG_ARCH_OMAP34XX
> +#ifdef CONFIG_ARCH_OMAP3
> static struct resource omap3_sham_resources[] = {
> {
> .start = OMAP34XX_SEC_SHA1MD5_BASE,
Hi Tony:
If I add this patch to cryptodev, is this going to cause any
problems for you?
Thbanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~}
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 0/2] omap-sham: OMAP SHA1/MD5 driver
On Wed, Apr 28, 2010 at 05:18:05PM +0300, Dmitry Kasatkin wrote:
> Changes to v4:
> - concurrent requests support via queue
> - hmac
> - shash support removed
>
> Dmitry Kasatkin (2):
> crypto: updates omap sham device related platform code
> crypto: omap-sham - omap sha1 & md5 driver
Both patches applied. Thanks for all your hard work Dmitry!
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~}
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 2/2] crypto: omap-sham - omap sha1 & md5 driver
On Wed, Apr 14, 2010 at 09:41:28AM +0300, Dmitry Kasatkin wrote:
>
> what do you mean "exporting shash object"?
>
> Providing shash alg?
>
> I was not sure if it is needed if ahash is available.
>
> Should I remove shash alg at all?
In that case please remove the shash object. ahash by itself
is enough.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~}
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 2/2] crypto: omap-sham - omap sha1 & md5 driver
Dmitry Kasatkin wrote:
> Earlier kernel contained omap sha1 and md5 driver, which was not maintained,
> was not ported to new crypto APIs and removed from the source tree.
>
> - implements async and sync crypto API using dma and cpu.
> - supports multiple sham instances if available
>
> Signed-off-by: Dmitry Kasatkin
You have not addressed my objections raised earlier.
Also, why are you exporting a shash object? You cannot sleep during
shash operations (except for setkey).
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~}
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver
On Tue, Mar 23, 2010 at 07:32:39PM +0800, Herbert Xu wrote:
>
> My only question is what's your plan with respect to HMAC? If
> you're going to do it in hardware then it's fine as it is.
>
> Otherwise you need to implement export/import and we also need
> to add ahash support to hmac.c.
Dmitry, did you answer this before or did it get lost in the mail :)
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~}
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver
On Wed, Mar 17, 2010 at 03:12:49PM +0200, Dmitry Kasatkin wrote:
> Earlier kernel contained omap sha1 and md5 driver, which was not maintained,
> was not ported to new crypto APIs and removed from the source tree.
>
> This driver implements async and sync crypto API.
>
> It still contains pr_debug() for debugging purpose.
> Will be remove for integration.
>
> Dmitry Kasatkin (2):
> sec: omap sha1 & md5 driver
> sec: Makefile/Kconfig update for omap sha1 md5 driver
It looks good to me as far as the Crypto API is concerned.
My only question is what's your plan with respect to HMAC? If
you're going to do it in hardware then it's fine as it is.
Otherwise you need to implement export/import and we also need
to add ahash support to hmac.c.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~}
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2.6.25-rc8] omap_rng minor updates
On Wed, Apr 16, 2008 at 10:04:49AM -0700, David Brownell wrote:
>
> Is that where the RNG stuff is now getting maintained?
For hardware RNG stuff yes. For the software RNG you should
send them to Matt Mackall as usual.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2.6.25-rc8] omap_rng minor updates
On Fri, Apr 11, 2008 at 04:32:03AM +, David Brownell wrote:
> Minor cleanups to the OMAP RNG:
Thanks. I've picked this up in cryptodev-2.6.
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
