Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API

2015-10-19 Thread Herbert Xu 
On Mon, Oct 19, 2015 at 09:14:09AM +0200, Stephan Mueller wrote:
>
> However, I would suggest that you pull patch 1/5 as this is a bug fix that 
> may 
> affect even other users.

Sure I'll look into it.

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-crypto" 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/5] crypto: add algif_akcipher user space API

2015-10-19 Thread Stephan Mueller 
Am Montag, 19. Oktober 2015, 09:32:30 schrieb Herbert Xu:

Hi Herbert,

> On Sun, Oct 18, 2015 at 12:44:00PM +0200, Stephan Mueller wrote:
> > Hi,
> > 
> > This patch set adds the AF_ALG user space API to externalize the
> > asymmetric cipher API recently added to the kernel crypto API.
> > 
> > The patch set is tested with the user space library of libkcapi [1].
> > Use [1] test/test.sh for a full test run. The test covers the
> 
> > following scenarios:
> Thanks Stephan.  But I would prefer to defer this til after we have
> completed the conversion of current in-kernel users.  This is because
> changing the kernel interface is easy while changing the user-space
> interface is not.

Sure, let us wait.

However, I would suggest that you pull patch 1/5 as this is a bug fix that may 
affect even other users.

-- 
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] akcipher: Don't #include crypto/public_key.h as the contents aren't used

2015-10-19 Thread David Howells 
Don't #include crypto/public_key.h in akcipher as the contents of the
header aren't used and changes in a future patch cause it to fail to
compile if CONFIG_KEYS=n.

Signed-off-by: David Howells 
---

 crypto/akcipher.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/crypto/akcipher.c b/crypto/akcipher.c
index 528ae6aa9bff..120ec042ec9e 100644
--- a/crypto/akcipher.c
+++ b/crypto/akcipher.c
@@ -21,7 +21,6 @@
 #include 
 #include 
 #include 
-#include 
 #include "internal.h"
 
 #ifdef CONFIG_NET

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" 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/18] crypto: marvell: add flag to determine algorithm endianness

2015-10-19 Thread Jason Cooper 
Hey Russell,

On Sun, Oct 18, 2015 at 05:23:40PM +0100, Russell King wrote:
> Rather than determining whether we're using a MD5 hash by looking at
> the digest size, switch to a cleaner solution using a per-request flag
> initialised by the method type.
> 
> Signed-off-by: Russell King 
> ---
>  drivers/crypto/marvell/cesa.h |  1 +
>  drivers/crypto/marvell/hash.c | 17 +
>  2 files changed, 10 insertions(+), 8 deletions(-)
> 
...
> diff --git a/drivers/crypto/marvell/hash.c b/drivers/crypto/marvell/hash.c
> index f59faabcd34f..aa12274608ab 100644
> --- a/drivers/crypto/marvell/hash.c
> +++ b/drivers/crypto/marvell/hash.c
> @@ -351,7 +351,7 @@ static int mv_cesa_ahash_process(struct 
> crypto_async_request *req, u32 status)
>* Hardware's MD5 digest is in little endian format, but
>* SHA in big endian format
>*/
> - if (digsize == MD5_DIGEST_SIZE) {
> + if (creq->algo_le) {
>   __le32 *result = (void *)ahashreq->result;
>  
>   for (i = 0; i < digsize / 4; i++)
> @@ -407,7 +407,7 @@ static const struct mv_cesa_req_ops mv_cesa_ahash_req_ops 
> = {
>  };
>  
>  static int mv_cesa_ahash_init(struct ahash_request *req,
> -   struct mv_cesa_op_ctx *tmpl)
> +   struct mv_cesa_op_ctx *tmpl, bool algo_le)

nit: Would it make more sense the do bool algo_endian, and then ...

> @@ -861,7 +862,7 @@ static int mv_cesa_md5_init(struct ahash_request *req)
>  
>   mv_cesa_set_op_cfg(, CESA_SA_DESC_CFG_MACM_MD5);
>  
> - mv_cesa_ahash_init(req, );
> + mv_cesa_ahash_init(req, , true);

mv_cesa_ahash_init(req, , ALGO_ENDIAN_LITTLE);

'true' doesn't seem as obvious.  But again, nit-picky.

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" 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/18] crypto: marvell: add flag to determine algorithm endianness

2015-10-19 Thread Russell King - ARM Linux 
On Mon, Oct 19, 2015 at 03:04:51PM +, Jason Cooper wrote:
> Hey Russell,
> 
> On Sun, Oct 18, 2015 at 05:23:40PM +0100, Russell King wrote:
> >  static int mv_cesa_ahash_init(struct ahash_request *req,
> > - struct mv_cesa_op_ctx *tmpl)
> > + struct mv_cesa_op_ctx *tmpl, bool algo_le)
> 
> nit: Would it make more sense the do bool algo_endian, and then ...

I don't like "bool"s that don't self-document what they mean.
What does "if (algo_endian)" mean?  It's pretty clear what
"if (algo_le)" means in the context of endianness, though I'll
give you that "if (algo_little_endian)" would be a lot better.

> 
> > @@ -861,7 +862,7 @@ static int mv_cesa_md5_init(struct ahash_request *req)
> >  
> > mv_cesa_set_op_cfg(, CESA_SA_DESC_CFG_MACM_MD5);
> >  
> > -   mv_cesa_ahash_init(req, );
> > +   mv_cesa_ahash_init(req, , true);
> 
>   mv_cesa_ahash_init(req, , ALGO_ENDIAN_LITTLE);
> 
> 'true' doesn't seem as obvious.  But again, nit-picky.

I did think about:

enum {
ALGO_LITTLE_ENDIAN,
ALGO_BIG_ENDIAN,
};

and passing an int algo_endian around, but that seemed to be like too
much bloat... though if you want to insist, I could make that change.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" 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/3] ARM: dts: Enable Exynos RNG module

2015-10-19 Thread Tobias Jakobi 
Hello Krzysztof,

I can confirm that this also works on a Odroid-X2, so I guess it's safe
to enable the PRNG for all Exynos4412-based Odroid devices.

Any chance that you might also take a look at the other hwcrypto stuff
on the SoC ('samsung,exynos4210-secss' compatible)?

With best wishes,
Tobias


Krzysztof Kozlowski wrote:
> Hi,
> 
> 
> The patchset adds necessary clock from Security SubSystem (SSS)
> and enables the PRNG module of Exynos for Trats2 board.
> 
> The first patch (clock) is required for other ones so please
> take everything in one step.
> 
> The actual Device Tree support (and compatible) was sent in separate
> patch:
>  - https://patchwork.kernel.org/patch/7432891/
>  - http://marc.info/?l=linux-crypto-vger=144522952725052=2
> 
> The device can be tested (after applying both patchsets) with:
> $ echo exynos > /sys/class/misc/hw_random/rng_current
> $ dd if=/dev/hwrng of=/dev/null bs=1 count=16
> 
> 
> Best regards,
> Krzysztof
> 
> Krzysztof Kozlowski (3):
>   clk: samsung: exynos4: Add SSS gate clock
>   ARM: dts: Add PRNG module for exynos4
>   ARM: dts: Enable PRNG module on exynos4412-trats2
> 
>  arch/arm/boot/dts/exynos4.dtsi  | 8 
>  arch/arm/boot/dts/exynos4412-trats2.dts | 4 
>  drivers/clk/samsung/clk-exynos4.c   | 1 +
>  include/dt-bindings/clock/exynos4.h | 1 +
>  4 files changed, 14 insertions(+)
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" 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/18] crypto: marvell: add flag to determine algorithm endianness

2015-10-19 Thread Herbert Xu 
On Mon, Oct 19, 2015 at 04:25:07PM +0100, Russell King - ARM Linux wrote:
>
> > > @@ -861,7 +862,7 @@ static int mv_cesa_md5_init(struct ahash_request *req)
> > >  
> > >   mv_cesa_set_op_cfg(, CESA_SA_DESC_CFG_MACM_MD5);
> > >  
> > > - mv_cesa_ahash_init(req, );
> > > + mv_cesa_ahash_init(req, , true);
> > 
> > mv_cesa_ahash_init(req, , ALGO_ENDIAN_LITTLE);
> > 
> > 'true' doesn't seem as obvious.  But again, nit-picky.
> 
> I did think about:
> 
> enum {
>   ALGO_LITTLE_ENDIAN,
>   ALGO_BIG_ENDIAN,
> };
> 
> and passing an int algo_endian around, but that seemed to be like too
> much bloat... though if you want to insist, I could make that change.

I think the patch is fine as it is.

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-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH net-next 2/2] xfrm: Fix unaligned access in xfrm_notify_sa() for DELSA

2015-10-19 Thread Sowmini Varadhan 
On sparc, deleting established SAs (e.g., by restarting ipsec
at the peer) results in unaligned access messages via
xfrm_del_sa -> km_state_notify -> xfrm_send_state_notify().
Use an aligned pointer to xfrm_usersa_info for this case.

Signed-off-by: Sowmini Varadhan 
---
 net/xfrm/xfrm_user.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index a8de9e3..158ef4a 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -2659,7 +2659,7 @@ static int xfrm_notify_sa(struct xfrm_state *x, const 
struct km_event *c)
if (attr == NULL)
goto out_free_skb;
 
-   p = nla_data(attr);
+   p = PTR_ALIGN(nla_data(attr), __alignof__(*p));
}
err = copy_to_user_state_extra(x, p, skb);
if (err)
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/2] xfrm/crypto: unaligned access fixes

2015-10-19 Thread Sowmini Varadhan 
A two-part patchset that fixes some "unaligned access" warnings
that showed up my sparc test machines with ipsec set up.


Sowmini Varadhan (2):
  crypto/x509: Fix unaligned access in x509_get_sig_params()
  Fix unaligned access in xfrm_notify_sa() for DELSA

 crypto/asymmetric_keys/x509_public_key.c |5 +++--
 net/xfrm/xfrm_user.c |2 +-
 2 files changed, 4 insertions(+), 3 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" 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/3] clk: samsung: exynos4: Add SSS gate clock

2015-10-19 Thread Stephen Boyd 
On 10/19, Krzysztof Kozlowski wrote:
> Add a gate clock for controlling all clocks of Security Sub System
> (SSS).
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---

The To: list is huge, so I have no idea if you want me to apply
this patch or not, and given that it's part of a series that has
dts changes I guess that means it should go through arm-soc:

Acked-by: Stephen Boyd 

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" 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/3] ARM: dts: Enable Exynos RNG module

2015-10-19 Thread Krzysztof Kozlowski 
On 20.10.2015 01:11, Tobias Jakobi wrote:
> Hello Krzysztof,
> 
> I can confirm that this also works on a Odroid-X2, so I guess it's safe
> to enable the PRNG for all Exynos4412-based Odroid devices.

Sure, I can send a patch for that. I can test it later also on Odroid-U3.


> 
> Any chance that you might also take a look at the other hwcrypto stuff
> on the SoC ('samsung,exynos4210-secss' compatible)?

What do you mean? The s5p-sss driver already supports Device Tree.

Best regards,
Krzysztof

> 
> With best wishes,
> Tobias
> 
> 
> Krzysztof Kozlowski wrote:
>> Hi,
>>
>>
>> The patchset adds necessary clock from Security SubSystem (SSS)
>> and enables the PRNG module of Exynos for Trats2 board.
>>
>> The first patch (clock) is required for other ones so please
>> take everything in one step.
>>
>> The actual Device Tree support (and compatible) was sent in separate
>> patch:
>>  - https://patchwork.kernel.org/patch/7432891/
>>  - http://marc.info/?l=linux-crypto-vger=144522952725052=2
>>
>> The device can be tested (after applying both patchsets) with:
>> $ echo exynos > /sys/class/misc/hw_random/rng_current
>> $ dd if=/dev/hwrng of=/dev/null bs=1 count=16
>>
>>
>> Best regards,
>> Krzysztof
>>
>> Krzysztof Kozlowski (3):
>>   clk: samsung: exynos4: Add SSS gate clock
>>   ARM: dts: Add PRNG module for exynos4
>>   ARM: dts: Enable PRNG module on exynos4412-trats2
>>
>>  arch/arm/boot/dts/exynos4.dtsi  | 8 
>>  arch/arm/boot/dts/exynos4412-trats2.dts | 4 
>>  drivers/clk/samsung/clk-exynos4.c   | 1 +
>>  include/dt-bindings/clock/exynos4.h | 1 +
>>  4 files changed, 14 insertions(+)
>>
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 17/18] crypto: marvell: fix first-fragment handling in mv_cesa_ahash_dma_last_req()

2015-10-19 Thread Arnaud Ebalard 
Hi Russell,

Russell King  writes:

> When adding the software padding, this must be done using the first/mid
> fragment mode, and any subsequent operation needs to be a mid-fragment.
> Fix this.
>
> Signed-off-by: Russell King 
> ---
>  drivers/crypto/marvell/hash.c | 8 
>  1 file changed, 8 deletions(-)
>
> diff --git a/drivers/crypto/marvell/hash.c b/drivers/crypto/marvell/hash.c
> index da541e59cc1d..34271e9eb3a5 100644
> --- a/drivers/crypto/marvell/hash.c
> +++ b/drivers/crypto/marvell/hash.c
> @@ -575,20 +575,12 @@ mv_cesa_ahash_dma_last_req(struct mv_cesa_tdma_chain 
> *chain,
>   if (IS_ERR(op))
>   return op;
>  
> - mv_cesa_update_op_cfg(op, CESA_SA_DESC_CFG_MID_FRAG,
> -   CESA_SA_DESC_CFG_FRAG_MSK);
> -
>   if (len == trailerlen)
>   return op;
>  
>   padoff += len;
>   }
>  
> - if (!mv_cesa_mac_op_is_first_frag(>op_tmpl))
> - mv_cesa_update_op_cfg(>op_tmpl,
> -   CESA_SA_DESC_CFG_MID_FRAG,
> -   CESA_SA_DESC_CFG_FRAG_MSK);
> -
>   ret = mv_cesa_dma_add_data_transfer(chain,
>   CESA_SA_DATA_SRAM_OFFSET,
>   ahashdreq->padding_dma +

I'll consider it's just late here and I need some sleep but I fail to
align the commit message w/ the content of the patch, i.e. it's
unclear to me.

Cheers,

a+
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" 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/18] crypto: further fixes for Marvell CESA hash

2015-10-19 Thread Arnaud Ebalard 
Hi Russell,

Boris Brezillon  writes:

> On Sun, 18 Oct 2015 17:16:49 +0100
> Russell King - ARM Linux  wrote:
>
>> Following on from the previous series, this series addresses further
>> problems with the Marvell CESA hash driver found while testing it my
>> openssl/ssh scenarios.
>> 
>> The first patch improves one from the previous series: we can get the
>> transform more directly using req->base.tfm rather than going round
>> the houses.
>> 
>> The next few patches rework the algorithm endianness conversions.
>> There are two things which depend on the algorithm endianness - the
>> format of the result, and the format of the bit length in the last
>> block.  We introduce a flag to convey this information, and keep
>> the creq->state format in CPU endian mode for consistency.
>> 
>> Some of the inconsistent hash results are down to the template
>> operation not being properly initialised - so we zero initialise all
>> template operations.
>> 
>> The following patches (from "factor out first fragment decisions to
>> helper") rework the digest handling to ensure that we always provide
>> the hardware with a complete block of data to hash, otherwise it can
>> be left mid-calculation, which then causes state to leak to
>> subsequent operations.  This requires a re-structure of the way we
>> put together the DMA entries, so it's done in relatively small steps.
>> 
>> This results in the CESA driver passing all tests I can throw at it
>> via the AF_ALG openssl plugin with the exception of asking for the
>> hash of /dev/null.  This returns an all zero result, rather than the
>> correct hash value.  This bug is pending further diagnosis, but it
>> is believed not to be a driver specific bug as iMX6 CAAM also behaves
>> the same.
>> 
>> Unfortunately, this is a large series, but the driver unfortunately
>> needs this level of bug fixing to work properly.
>
> Thanks for spending some time fixing those bugs and
> simplifying/factorizing/documenting the hash logic.

+1

> To the whole series:
>
> Acked-by: Boris Brezillon 
>
> Note that my ack might seem quite quick compared to the amount of
> changes, but Russell actually sent me a preliminary version last
> Wednesday.
>
> Arnaud, if you have some time, could you also have a look at those
> patches?

Acked-by: Arnaud Ebalard 

Cheers,

a+
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" 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] Sparse related fixes

2015-10-19 Thread Arnaud Ebalard 
Hi,

Boris Brezillon  writes:

> On Sun, 18 Oct 2015 18:30:39 +0100
> Russell King - ARM Linux  wrote:
>
>> Continuing on from the previous set of 18 patches, I also fixed a
>> number of sparse problems and other cleanups.  I don't deem these
>> suitable for -rc merging, especially now that we're basically at
>> -rc6.
>> 
>> The first patch switches the driver over to appropriately using
>> the relaxed IO accessors - this avoids calling out to the heavy
>> barrier on every read and write operation, but only calling out on
>> those which really matter.
>> 
>> We switch to using dma_addr_t for DMA addresses which are not accessed
>> by hardware, and using gfp_t for the get_free_page flags.  String-based
>> MMIO accesses are used instead of plain memcpy()/memset() which prevents
>> us potentially stumbling over GCC optimisations that it thinks it may
>> make with these functions.
>> 
>> We convert as much of the hardware state to __le32 endian markings,
>> and use cpu_to_le32() as appropriate.  A number of places are left
>> unfixed, as we temporarily store CPU native endian values at these
>> locations; these warnings should not be fixed (basically, only
>> appropriate sparse warnings should be fixed without penalising code.)
>
> To the whole series:
>
> Acked-by: Boris Brezillon 

Same here:

Acked-by: Arnaud Ebalard 

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" 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 1/5] MPI: fix off by one in mpi_read_raw_from_sgl

2015-10-19 Thread Tadeusz Struk 
On 10/18/2015 03:45 AM, Stephan Mueller wrote:
> The patch fixes the analysis of the input data which contains an off
> by one.
> 
> The issue is visible when the SGL contains one byte per SG entry.
> The code for checking for zero bytes does not operate on the data byte.
> 
> Signed-off-by: Stephan Mueller 
> ---
>  lib/mpi/mpicoder.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/mpi/mpicoder.c b/lib/mpi/mpicoder.c
> index c20ef27..c7e0a70 100644
> --- a/lib/mpi/mpicoder.c
> +++ b/lib/mpi/mpicoder.c
> @@ -446,8 +446,11 @@ MPI mpi_read_raw_from_sgl(struct scatterlist *sgl, 
> unsigned int len)
>   const u8 *buff = sg_virt(sg);
>   int len = sg->length;
>  
> - while (len-- && !*buff++)
> + while (len && !*buff) {
>   lzeros++;
> + len--;
> + buff++;
> + }
>  
>   if (len && *buff)
>   break;

ACK. Thanks for testing this Stephan.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/6] crypto: marvell: use memcpy_fromio()/memcpy_toio()

2015-10-19 Thread Arnaud Ebalard 
Hi Russell,

Russell King  writes:

> Use the IO memcpy() functions when copying from/to MMIO memory.
> These locations were found via sparse.

On recent MVEBU hardware, *_std_* function are not expected to be used
because we will instead use the TDMA-based versions. So the only
possible penalty we could get (if any) from this change on recent
devices is for the copy of the IV in mv_cesa_ablkcipher_process(). Out
of curiosity, I took a quick look at what is generated and it seems this
results in a call to mmiocpy(): 

0340 :
 340:   e1a0c00dmov ip, sp
 344:   e92dd830push{r4, r5, fp, ip, lr, pc}
 348:   e24cb004sub fp, ip, #4
 34c:   e24dd008sub sp, sp, #8

 

 3a4:   e5943010ldr r3, [r4, #16]
 3a8:   e5951008ldr r1, [r5, #8]
 3ac:   e594001cldr r0, [r4, #28]
 3b0:   e2811040add r1, r1, #64 ; 0x40
 3b4:   e593201cldr r2, [r3, #28]
 3b8:   ebfebl  0 

which if I am not mistaken is provided by arch/arm/lib/memcpy.S via:

ENTRY(mmiocpy)
ENTRY(memcpy)

#include "copy_template.S"

ENDPROC(memcpy)
ENDPROC(mmiocpy)

Am I right in concluding this will end up being the code of a usual
memcpy(), i.e. the change is a noop in the final code compared to
previous version? 

Cheers,

a+


>
> Signed-off-by: Russell King 
> ---
>  drivers/crypto/marvell/cipher.c | 11 ++-
>  drivers/crypto/marvell/hash.c   | 16 
>  2 files changed, 14 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/crypto/marvell/cipher.c b/drivers/crypto/marvell/cipher.c
> index 4db2d632204f..6edae64bb387 100644
> --- a/drivers/crypto/marvell/cipher.c
> +++ b/drivers/crypto/marvell/cipher.c
> @@ -98,10 +98,10 @@ static void mv_cesa_ablkcipher_std_step(struct 
> ablkcipher_request *req)
>  
>   /* FIXME: only update enc_len field */
>   if (!sreq->skip_ctx) {
> - memcpy(engine->sram, >op, sizeof(sreq->op));
> + memcpy_toio(engine->sram, >op, sizeof(sreq->op));
>   sreq->skip_ctx = true;
>   } else {
> - memcpy(engine->sram, >op, sizeof(sreq->op.desc));
> + memcpy_toio(engine->sram, >op, sizeof(sreq->op.desc));
>   }
>  
>   mv_cesa_set_int_mask(engine, CESA_SA_INT_ACCEL0_DONE);
> @@ -145,8 +145,9 @@ static int mv_cesa_ablkcipher_process(struct 
> crypto_async_request *req,
>   if (ret)
>   return ret;
>  
> - memcpy(ablkreq->info, engine->sram + CESA_SA_CRYPT_IV_SRAM_OFFSET,
> -crypto_ablkcipher_ivsize(crypto_ablkcipher_reqtfm(ablkreq)));
> + memcpy_fromio(ablkreq->info,
> +   engine->sram + CESA_SA_CRYPT_IV_SRAM_OFFSET,
> +   
> crypto_ablkcipher_ivsize(crypto_ablkcipher_reqtfm(ablkreq)));
>  
>   return 0;
>  }
> @@ -181,7 +182,7 @@ mv_cesa_ablkcipher_std_prepare(struct ablkcipher_request 
> *req)
>   sreq->size = 0;
>   sreq->offset = 0;
>   mv_cesa_adjust_op(engine, >op);
> - memcpy(engine->sram, >op, sizeof(sreq->op));
> + memcpy_toio(engine->sram, >op, sizeof(sreq->op));
>  }
>  
>  static inline void mv_cesa_ablkcipher_prepare(struct crypto_async_request 
> *req,
> diff --git a/drivers/crypto/marvell/hash.c b/drivers/crypto/marvell/hash.c
> index 84ddc4cbfa9d..8330815d72fc 100644
> --- a/drivers/crypto/marvell/hash.c
> +++ b/drivers/crypto/marvell/hash.c
> @@ -209,8 +209,8 @@ static void mv_cesa_ahash_std_step(struct ahash_request 
> *req)
>   size_t  len;
>  
>   if (creq->cache_ptr)
> - memcpy(engine->sram + CESA_SA_DATA_SRAM_OFFSET, creq->cache,
> -creq->cache_ptr);
> + memcpy_toio(engine->sram + CESA_SA_DATA_SRAM_OFFSET,
> + creq->cache, creq->cache_ptr);
>  
>   len = min_t(size_t, req->nbytes + creq->cache_ptr - sreq->offset,
>   CESA_SA_SRAM_PAYLOAD_SIZE);
> @@ -251,10 +251,10 @@ static void mv_cesa_ahash_std_step(struct ahash_request 
> *req)
>   if (len + trailerlen > CESA_SA_SRAM_PAYLOAD_SIZE) {
>   len &= CESA_HASH_BLOCK_SIZE_MSK;
>   new_cache_ptr = 64 - trailerlen;
> - memcpy(creq->cache,
> -engine->sram +
> -CESA_SA_DATA_SRAM_OFFSET + len,
> -new_cache_ptr);
> + memcpy_fromio(creq->cache,
> +   engine->sram +
> +   CESA_SA_DATA_SRAM_OFFSET + len,
> +   new_cache_ptr);
>   } else {
>   len += mv_cesa_ahash_pad_req(creq,
>

Re: [PATCH 1/3] clk: samsung: exynos4: Add SSS gate clock

2015-10-19 Thread Krzysztof Kozlowski 
On 20.10.2015 04:59, Stephen Boyd wrote:
> On 10/19, Krzysztof Kozlowski wrote:
>> Add a gate clock for controlling all clocks of Security Sub System
>> (SSS).
>>
>> Signed-off-by: Krzysztof Kozlowski 
>> ---
> 
> The To: list is huge, so I have no idea if you want me to apply
> this patch or not, and given that it's part of a series that has
> dts changes I guess that means it should go through arm-soc:
> 
> Acked-by: Stephen Boyd 

If you are OK with that I would like to push it through arm-soc. Thanks
for the ack!

Best regards,
Krzysztof

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" 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/18] crypto: marvell: add flag to determine algorithm endianness

2015-10-19 Thread Jason Cooper 
On Mon, Oct 19, 2015 at 04:25:07PM +0100, Russell King - ARM Linux wrote:
> On Mon, Oct 19, 2015 at 03:04:51PM +, Jason Cooper wrote:
> > Hey Russell,
> > 
> > On Sun, Oct 18, 2015 at 05:23:40PM +0100, Russell King wrote:
> > >  static int mv_cesa_ahash_init(struct ahash_request *req,
> > > -   struct mv_cesa_op_ctx *tmpl)
> > > +   struct mv_cesa_op_ctx *tmpl, bool algo_le)
> > 
> > nit: Would it make more sense the do bool algo_endian, and then ...
> 
> I don't like "bool"s that don't self-document what they mean.
> What does "if (algo_endian)" mean?  It's pretty clear what

That's where I would go with an enum.  "if (algo_endian ==
ALGO_ENDIAN_LITTLE) ..."

> "if (algo_le)" means in the context of endianness, though I'll
> give you that "if (algo_little_endian)" would be a lot better.

Right, it's really a question of where do we want readability?  I was
focusing on the call site, since the context isn't there for newcomers to
easily grok 'true'.

> > > @@ -861,7 +862,7 @@ static int mv_cesa_md5_init(struct ahash_request *req)
> > >  
> > >   mv_cesa_set_op_cfg(, CESA_SA_DESC_CFG_MACM_MD5);
> > >  
> > > - mv_cesa_ahash_init(req, );
> > > + mv_cesa_ahash_init(req, , true);
> > 
> > mv_cesa_ahash_init(req, , ALGO_ENDIAN_LITTLE);
> > 
> > 'true' doesn't seem as obvious.  But again, nit-picky.
> 
> I did think about:
> 
> enum {
>   ALGO_LITTLE_ENDIAN,
>   ALGO_BIG_ENDIAN,
> };
> 
> and passing an int algo_endian around, but that seemed to be like too
> much bloat... though if you want to insist, I could make that change.

Like I said, it's a nit.  Either a self-documenting bool, or an enum
will work.


thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html