[PATCH] staging: ccree: Fix lines longer than 80 characters

[Stephen Brennan]

---
I'm new to kernel development and hoping to start with some simple changes to
get familiar with the process. Please let me know if there's anything I can do
to improve this very trivial patch!

 drivers/staging/ccree/ssi_pm.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/ccree/ssi_pm.c b/drivers/staging/ccree/ssi_pm.c
index 11bbdbeec22e..98ba9e918d2a 100644
--- a/drivers/staging/ccree/ssi_pm.c
+++ b/drivers/staging/ccree/ssi_pm.c
@@ -41,7 +41,9 @@ int ssi_power_mgr_runtime_suspend(struct device *dev)
int rc;
 
dev_dbg(dev, "set HOST_POWER_DOWN_EN\n");
-   WRITE_REGISTER(drvdata->cc_base + CC_REG_OFFSET(HOST_RGF, 
HOST_POWER_DOWN_EN), POWER_DOWN_ENABLE);
+   WRITE_REGISTER(
+   drvdata->cc_base + CC_REG_OFFSET(HOST_RGF, HOST_POWER_DOWN_EN),
+   POWER_DOWN_ENABLE);
rc = ssi_request_mgr_runtime_suspend_queue(drvdata);
if (rc != 0) {
dev_err(dev, "ssi_request_mgr_runtime_suspend_queue (%x)\n",
@@ -60,7 +62,9 @@ int ssi_power_mgr_runtime_resume(struct device *dev)
(struct ssi_drvdata *)dev_get_drvdata(dev);
 
dev_dbg(dev, "unset HOST_POWER_DOWN_EN\n");
-   WRITE_REGISTER(drvdata->cc_base + CC_REG_OFFSET(HOST_RGF, 
HOST_POWER_DOWN_EN), POWER_DOWN_DISABLE);
+   WRITE_REGISTER(
+   drvdata->cc_base + CC_REG_OFFSET(HOST_RGF, HOST_POWER_DOWN_EN),
+   POWER_DOWN_DISABLE);
 
rc = cc_clk_on(drvdata);
if (rc) {
-- 
2.14.2

Re: [PATCH 1/2] crypto: lrw - Fix an error handling path in 'create()'

[walter harms]

Am 08.10.2017 11:39, schrieb Christophe JAILLET:
> All error handling paths 'goto err_drop_spawn' except this one.
> In order to avoid some resources leak, we should do it as well here.
> 
> Fixes: 700cb3f5fe75 ("crypto: lrw - Convert to skcipher")
> Signed-off-by: Christophe JAILLET 
> ---
>  crypto/lrw.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/crypto/lrw.c b/crypto/lrw.c
> index a8bfae4451bf..eb681e9fe574 100644
> --- a/crypto/lrw.c
> +++ b/crypto/lrw.c
> @@ -610,8 +610,10 @@ static int create(struct crypto_template *tmpl, struct 
> rtattr **tb)
>   ecb_name[len - 1] = 0;
>  
>   if (snprintf(inst->alg.base.cra_name, CRYPTO_MAX_ALG_NAME,
> -  "lrw(%s)", ecb_name) >= CRYPTO_MAX_ALG_NAME)

this check can be done more easy,
the length of ecb_name is len
the length of inst->alg.base.cra_name is CRYPTO_MAX_ALG_NAME
if CRYPTO_MAX_ALG_NAME-len < "lrw()" < 5
no need to involve snprintf()

just my 2 cents
re,
wh

> - return -ENAMETOOLONG;
> +  "lrw(%s)", ecb_name) >= CRYPTO_MAX_ALG_NAME) {
> + err = -ENAMETOOLONG;
> + goto err_drop_spawn;
> + }
>   }
>  
>   inst->alg.base.cra_flags = alg->base.cra_flags & CRYPTO_ALG_ASYNC;

[PATCH] crypto: tcrypt: mark expected switch fall-throughs in do_test()

[Gustavo A. R. Silva]

In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.

Cc: Herbert Xu 
Cc: "David S. Miller" 
Cc: linux-crypto@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva 
---
 crypto/tcrypt.c | 108 ++--
 1 file changed, 51 insertions(+), 57 deletions(-)

diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index a371c072..28bffa6 100644
--- a/crypto/tcrypt.c
+++ b/crypto/tcrypt.c
@@ -1606,119 +1606,116 @@ static int do_test(const char *alg, u32 type, u32 
mask, int m)
  speed_template_32);
break;
 
-
case 300:
if (alg) {
test_hash_speed(alg, sec, generic_hash_speed_template);
break;
}
-
/* fall through */
-
case 301:
test_hash_speed("md4", sec, generic_hash_speed_template);
if (mode > 300 && mode < 400) break;
-
+   /* fall through */
case 302:
test_hash_speed("md5", sec, generic_hash_speed_template);
if (mode > 300 && mode < 400) break;
-
+   /* fall through */
case 303:
test_hash_speed("sha1", sec, generic_hash_speed_template);
if (mode > 300 && mode < 400) break;
-
+   /* fall through */
case 304:
test_hash_speed("sha256", sec, generic_hash_speed_template);
if (mode > 300 && mode < 400) break;
-
+   /* fall through */
case 305:
test_hash_speed("sha384", sec, generic_hash_speed_template);
if (mode > 300 && mode < 400) break;
-
+   /* fall through */
case 306:
test_hash_speed("sha512", sec, generic_hash_speed_template);
if (mode > 300 && mode < 400) break;
-
+   /* fall through */
case 307:
test_hash_speed("wp256", sec, generic_hash_speed_template);
if (mode > 300 && mode < 400) break;
-
+   /* fall through */
case 308:
test_hash_speed("wp384", sec, generic_hash_speed_template);
if (mode > 300 && mode < 400) break;
-
+   /* fall through */
case 309:
test_hash_speed("wp512", sec, generic_hash_speed_template);
if (mode > 300 && mode < 400) break;
-
+   /* fall through */
case 310:
test_hash_speed("tgr128", sec, generic_hash_speed_template);
if (mode > 300 && mode < 400) break;
-
+   /* fall through */
case 311:
test_hash_speed("tgr160", sec, generic_hash_speed_template);
if (mode > 300 && mode < 400) break;
-
+   /* fall through */
case 312:
test_hash_speed("tgr192", sec, generic_hash_speed_template);
if (mode > 300 && mode < 400) break;
-
+   /* fall through */
case 313:
test_hash_speed("sha224", sec, generic_hash_speed_template);
if (mode > 300 && mode < 400) break;
-
+   /* fall through */
case 314:
test_hash_speed("rmd128", sec, generic_hash_speed_template);
if (mode > 300 && mode < 400) break;
-
+   /* fall through */
case 315:
test_hash_speed("rmd160", sec, generic_hash_speed_template);
if (mode > 300 && mode < 400) break;
-
+   /* fall through */
case 316:
test_hash_speed("rmd256", sec, generic_hash_speed_template);
if (mode > 300 && mode < 400) break;
-
+   /* fall through */
case 317:
test_hash_speed("rmd320", sec, generic_hash_speed_template);
if (mode > 300 && mode < 400) break;
-
+   /* fall through */
case 318:
test_hash_speed("ghash-generic", sec, hash_speed_template_16);
if (mode > 300 && mode < 400) break;
-
+   /* fall through */
case 319:
test_hash_speed("crc32c", sec, generic_hash_speed_template);
if (mode > 300 && mode < 400) break;
-
+   /* fall through */
case 320:
test_hash_speed("crct10dif", sec, generic_hash_speed_template);
if (mode > 300 && mode < 400) break;
-
+   /* fall through */
case 321:
test_hash_speed("poly1305", sec, poly1305_speed_template);
if (mode > 300 && mode < 400) break;
-
+   /* fall through */
case 322:
test_hash_speed("sha3-224", sec, generic_hash_speed_template);
if (mode > 300 && mode < 400) break;
-
+   /* fall through */
 

Re: [PATCH v5] crypto: s5p-sss: Add HASH support for Exynos

[Krzysztof Kozlowski]

On Mon, Oct 09, 2017 at 01:12:30PM +0200, Kamil Konieczny wrote:
> Add support for MD5, SHA1, SHA256 hash algorithms for Exynos HW.
> It uses the crypto framework asynchronous hash api.
> It is based on omap-sham.c driver.
> S5P has some HW differencies and is not implemented.
> 
> Modifications in s5p-sss:
> 
> - Add hash supporting structures and functions.
> 
> - Modify irq handler to handle both aes and hash signals.
> 
> - Resize resource end in probe if EXYNOS_HASH is enabled in
>   Kconfig.
> 
> - Add new copyright line and new author.
> 
> - Tested on Odroid-U3 with Exynos 4412 CPU, kernel 4.13-rc6
>   with crypto run-time self test testmgr
>   and with tcrypt module with: modprobe tcrypt sec=1 mode=N
>   where N=402, 403, 404 (MD5, SHA1, SHA256).
> 
> Modifications in drivers/crypto/Kconfig:
> 
> - Add new CRYPTO_DEV_EXYNOS_HASH, depend on !EXYNOS_RNG
>   and CRYPTO_DEV_S5P
> 
> - Select sw algorithms MD5, SHA1 and SHA256 in EXYNOS_HASH
>   as they are nedded for fallback.
> 
> Signed-off-by: Kamil Konieczny 
> ---
> version 5:
> - fix suggested by Krzysztof Kozlowski: change defines HASH_OP into enum, fix
>   comments
> 
> version 4:
> - fixes suggested by Krzysztof Kozlowski: reformat comments, convert context
>   flags into two bool vars, drop SSS_ALIGNED, change name of SSS_DMA_ALIGN and
>   SSS_DMA_ALIGN_MASK, split assignments into separate lines, use IS_ENABLED in
>   place of ifdef, remove sss_hash_algs_info and simplify register and 
> deregister
>   HASH algs
> 
> version 3:
> - many fixes suggested by Krzysztof Kozlowski: comments, uppercases in const,
>   remove unused defines, remove unused variable bs, constify aes_variant,
>   remove global var use_hash, remove WARN_ON, improve hash_import(),
>   change goto label into 'out' in s5p_hash_handle_queue(), reorder variable
>   declarations, add spinlock to protect clearing HASH_FLAGS_BUSY
> - simplify code: replace one-line functions s5p_hash_update_req(),
>   s5p_hash_final_req() with call to s5p_hash_xmit_dma(), and delete them
> - replace call to s5p_hash_hw_init() into s5p_ahash_dma_init() and delete it
> - fix clearing shash flag CRYPTO_TFM_REQ_MAY_SLEEP
> - fix s5p_hash_set_flow()
> 
> version 2:
> - change patch format so number of lines drops
> - change in Kconfig as suggested by Krzysztof Kozlowski, add
>   EXYNOS_HASH subsection
> - change #ifndef EXYNOS_RNG into #ifdef CRYPTO_DEV_EXYNOS_HASH
> - remove style fixups in aes, as they should go in separate patch
> - remove FLOW_LOG, FLOW_DUMP macros and its uses
> - remove #if 0 ... endif
> - remove unused function hash_wait and its defines
> - fix compiler warning in dev_dbg
> - remove some comments
> - other minor fixes in comments
> 
>  drivers/crypto/Kconfig   |   14 +
>  drivers/crypto/s5p-sss.c | 1441 
> +-
>  2 files changed, 1445 insertions(+), 10 deletions(-)
> 

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

Re: [PATCH v2] crypto: shash - Fix zero-length shash ahash digest crash

[Stephan Müller]

Am Montag, 9. Oktober 2017, 17:30:02 CEST schrieb Herbert Xu:

Hi Herbert,

> The shash ahash digest adaptor function may crash if given a
> zero-length input together with a null SG list.  This is because
> it tries to read the SG list before looking at the length.
> 
> This patch fixes it by checking the length first.

The patch fixes the issue.
> 
> Cc: 
> Reported-by: Stephan Müller
> Signed-off-by: Herbert Xu 

Tested-by: Stephan Müller 

Ciao
Stephan

[PATCH v2] crypto: shash - Fix zero-length shash ahash digest crash

[Herbert Xu]

On Mon, Oct 09, 2017 at 05:13:48PM +0200, Stephan Müller wrote:
> Am Montag, 9. Oktober 2017, 16:19:25 CEST schrieb Herbert Xu:
> 
> Hi Herbert,
> 
> > On Sat, Oct 07, 2017 at 02:56:24PM +0200, Stephan Müller wrote:
> > > Though, this opens up the shash issue I tried to fix.
> > 
> > Does this patch fix the crash?
> 
> I get the following during boot:

Thanks for the quick response.  Obviously not doing the hash
at all isn't right.

Does this patch work better?

---8<---
The shash ahash digest adaptor function may crash if given a
zero-length input together with a null SG list.  This is because
it tries to read the SG list before looking at the length.

This patch fixes it by checking the length first.

Cc: 
Reported-by: Stephan Müller
Signed-off-by: Herbert Xu 

diff --git a/crypto/shash.c b/crypto/shash.c
index 8fcecc6..325a14d 100644
--- a/crypto/shash.c
+++ b/crypto/shash.c
@@ -275,12 +275,14 @@ static int shash_async_finup(struct ahash_request *req)
 
 int shash_ahash_digest(struct ahash_request *req, struct shash_desc *desc)
 {
-   struct scatterlist *sg = req->src;
-   unsigned int offset = sg->offset;
unsigned int nbytes = req->nbytes;
+   struct scatterlist *sg;
+   unsigned int offset;
int err;
 
-   if (nbytes < min(sg->length, ((unsigned int)(PAGE_SIZE)) - offset)) {
+   if (nbytes &&
+   (sg = req->src, offset = sg->offset,
+nbytes < min(sg->length, ((unsigned int)(PAGE_SIZE)) - offset))) {
void *data;
 
data = kmap_atomic(sg_page(sg));
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [Part2 PATCH v5.1 12.1/31] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support

[Borislav Petkov]

On Sun, Oct 08, 2017 at 07:11:04PM -0500, Brijesh Singh wrote:
> There is a single security processor driver (ccp) which provides the
> complete functionality including PSP.  But the driver should be able to
> work with multiple devices. e.g In my 2P EPYC configuration, security
> processor driver is used for the following devices
> 
> 02:00.2 Encryption controller: Advanced Micro Devices, Inc. [AMD] Device
> 1456

So we have a lot of drivers which claim more than one PCI device. It is
not mandatory to have a driver per PCI device. Actually, the decisive
argument is what is the easiest way to manage those devices and what
makes the communication between them the easiest.

> 03:00.1 Encryption controller: Advanced Micro Devices, Inc. [AMD] Device
> 1468
> 13:00.2 Encryption controller: Advanced Micro Devices, Inc. [AMD] Device
> 1456

Btw, what do those PCI functions each do? Public PPR doesn't have them
documented.

> Some of the these devices support CCP only and some support both PSP and
> CCP. It's possible that multiple devices support the PSP functionality
> but only one of them is master which can be used for issuing SEV
> commands. There isn't a register which we can read to determine whether
> the device is master. We have to probe all the devices which supports
> the PSP to determine which one of them is a master.

Sure, and if you manage all the devices in a single driver, you can
simply keep them all in a linked list or in an array and iterating over
them is trivial.

Because right now you have

1. sp-pci.c::sp_pci_probe() execute upon the PCI device detection

2. at some point, it does sp-dev.c::sp_init() which decides whether CCP or PSP

3. If PSP, it calls pcp-dev.c::psp_dev_init() which gets that
sp->dev_vdata->psp_vdata which is nothing more than a simple offset
0x10500 which is where the PSP io regs are. For example, if this offset
is hardcoded, why are we even passing that vdata? Just set psp->io_regs =
0x10500. No need for all that passing of structs around.

4. and finally, after that *whole* init has been done, you get to do
->set_psp_master_device(sp);

Or, you can save yourself all that jumping through hoops, merge sp-pci.c
and sp-dev.c into a single sp.c and put *everything* sp-related into
it. And then do the whole work of picking hw apart, detection and
configuration in sp_pci_probe() and have helper functions preparing and
configuring the device.

At the end, it adds it to the list of devices sp.c manages and done. You
actually have that list already:

static LIST_HEAD(sp_units);

in sp-dev.c.

You don't need the set_master thing either - you simply set the
sp_dev_master pointer inside sp.c

sp_init() can then go and you can replace it with its function body,
deciding whether it is a CCP or PSP and then call the respective
function which is also in sp.c or ccp-dev.c

And then all those separate compilation units and the interfaces between
them disappear - you have only the calls into the PSP and that's it.

Btw, the CCP thing could remain separate initially, I guess, with all
that ccp-* stuff in there.

> I was trying to follow the CCP  model -- in which sp-dev.c simply
> forwards the call to ccp-dev.c which does the real work.

And you don't really need that - you can do the real work directly in
sp-dev.c or sp.c or whatever.

> Currently, sev-dev.c contains barebone common code. IMO, keeping all
> the PSP private functions and data structure outside the sp-dev.c/.h
> is right thing.

By this model probably, but it causes all that init and registration
jump-through-hoops for no real reason. It is basically wasting cycles
and energy.

I'm all for splitting if it makes sense. But right now I don't see much
sense in this - it is basically a bunch of small compilation units
calling each other. And they could be merged into a single sp.c which
does it all in one go, without a lot of blabla.

> Additionally, I would like to highlight that if we decide to go with
> moving all the PSP functionality in sp-dev.c then we have to add #ifdef
> CONFIG_CRYPTO_DEV_SP_PSP because PSP feature depends on X86_66, whereas
> the sp-dev.c gets compiled for all architectures (including aarch64,
> i386 and x86_64).

That's fine. You can build it on 32-bit but add to the init function

if (IS_ENABLED(CONFIG_X86_32))
return -ENODEV;

and be done with it. No need for the ifdeffery.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

Re: [PATCH 1/2] crypto: skcipher - noop for enc/dec with NULL data

[Stephan Müller]

Am Montag, 9. Oktober 2017, 16:19:25 CEST schrieb Herbert Xu:

Hi Herbert,

> On Sat, Oct 07, 2017 at 02:56:24PM +0200, Stephan Müller wrote:
> > Though, this opens up the shash issue I tried to fix.
> 
> Does this patch fix the crash?

I get the following during boot:

[1.042673] [ cut here ]
[1.043208] kernel BUG at crypto/asymmetric_keys/public_key.c:96!
[1.044235] invalid opcode:  [#1] SMP
[1.044661] Modules linked in:
[1.044964] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.14.0-rc1+ #556
[1.045638] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-1.fc26 04/01/2014
[1.046397] task: 8ecefc88 task.stack: a776c031c000
[1.046943] RIP: 0010:public_key_verify_signature+0x25c/0x270
[1.047539] RSP: 0018:a776c031fcd8 EFLAGS: 00010246
[1.047997] RAX: a5cb1d5f RBX: 8eceb61f9780 RCX: 

[1.048618] RDX: 8eceb6169cc0 RSI: 8eceb6169cc0 RDI: 
8ecefc99be80
[1.049261] RBP: a776c031fcf0 R08: 00c9 R09: 
8ecefd003800
[1.049870] R10: c78580d88100 R11: 7fff R12: 
0001
[1.050487] R13: 8eceb61fa2a0 R14: a60c5870 R15: 
0542
[1.051118] FS:  () GS:8eceffd0() knlGS:

[1.051805] CS:  0010 DS:  ES:  CR0: 80050033
[1.052295] CR2: 7f89a5ee2000 CR3: 36036004 CR4: 
003606e0
[1.052853] Call Trace:
[1.053069]  ? x509_check_for_self_signed+0x86/0xd0
[1.053446]  x509_cert_parse+0x15e/0x1c0
[1.053764]  x509_key_preparse+0x26/0x1e0
[1.054094]  asymmetric_key_preparse+0x5c/0xd0
[1.054438]  key_create_or_update+0x137/0x430
[1.054789]  ? set_debug_rodata+0x17/0x17
[1.055119]  load_system_certificate_list+0x99/0xfa
[1.055494]  ? system_trusted_keyring_init+0x66/0x66
[1.055890]  ? set_debug_rodata+0x17/0x17
[1.056221]  do_one_initcall+0x41/0x160
[1.056519]  kernel_init_freeable+0x173/0x201
[1.056867]  ? rest_init+0xb0/0xb0
[1.057161]  kernel_init+0xe/0x110
[1.057426]  ret_from_fork+0x25/0x30
[1.057714] Code: 40 00 85 c0 b8 7f ff ff ff 44 0f 45 f8 eb 8a 48 8d bd e0 
fe ff ff e8 d4 ad 40 00 44 8b bd 00 ff ff ff e9 5a ff ff ff 0f 0b 0f 0b <0f> 
0b 0f 0b 41 bf ea ff ff ff e9 7a ff ff ff 0f 1f 44 00 00 0f 
[1.059208] RIP: public_key_verify_signature+0x25c/0x270 RSP: 
a776c031fcd8
[1.059782] ---[ end trace 5363a8b61ab8b581 ]---
[1.060236] Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x000b
[1.060236] 
[1.061073] Kernel Offset: 0x2400 from 0x8100 (relocation 
range: 0x8000-0xbfff)
[1.061990] ---[ end Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x000b
Ciao
Stephan

Re: [PATCH 1/2] crypto: skcipher - noop for enc/dec with NULL data

[Herbert Xu]

On Sat, Oct 07, 2017 at 02:56:24PM +0200, Stephan Müller wrote:
>
> Though, this opens up the shash issue I tried to fix.

Does this patch fix the crash?

---8<---
Subject: crypto: shash - Fix zero-length shash ahash digest crash

The shash ahash digest adaptor function may crash if given a
zero-length input together with a null SG list.  This is because
it tries to read the SG list before looking at the length.

This patch fixes it by checking the length first.

Cc: 
Reported-by: Stephan Müller
Signed-off-by: Herbert Xu 

diff --git a/crypto/shash.c b/crypto/shash.c
index 8fcecc6..a8322b0 100644
--- a/crypto/shash.c
+++ b/crypto/shash.c
@@ -275,11 +275,17 @@ static int shash_async_finup(struct ahash_request *req)
 
 int shash_ahash_digest(struct ahash_request *req, struct shash_desc *desc)
 {
-   struct scatterlist *sg = req->src;
-   unsigned int offset = sg->offset;
unsigned int nbytes = req->nbytes;
+   struct scatterlist *sg;
+   unsigned int offset;
int err;
 
+   if (!nbytes)
+   return 0;
+
+   sg = req->src;
+   offset = sg->offset;
+
if (nbytes < min(sg->length, ((unsigned int)(PAGE_SIZE)) - offset)) {
void *data;
 
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[PATCH v5] crypto: s5p-sss: Add HASH support for Exynos

[Kamil Konieczny]

Add support for MD5, SHA1, SHA256 hash algorithms for Exynos HW.
It uses the crypto framework asynchronous hash api.
It is based on omap-sham.c driver.
S5P has some HW differencies and is not implemented.

Modifications in s5p-sss:

- Add hash supporting structures and functions.

- Modify irq handler to handle both aes and hash signals.

- Resize resource end in probe if EXYNOS_HASH is enabled in
  Kconfig.

- Add new copyright line and new author.

- Tested on Odroid-U3 with Exynos 4412 CPU, kernel 4.13-rc6
  with crypto run-time self test testmgr
  and with tcrypt module with: modprobe tcrypt sec=1 mode=N
  where N=402, 403, 404 (MD5, SHA1, SHA256).

Modifications in drivers/crypto/Kconfig:

- Add new CRYPTO_DEV_EXYNOS_HASH, depend on !EXYNOS_RNG
  and CRYPTO_DEV_S5P

- Select sw algorithms MD5, SHA1 and SHA256 in EXYNOS_HASH
  as they are nedded for fallback.

Signed-off-by: Kamil Konieczny 
---
version 5:
- fix suggested by Krzysztof Kozlowski: change defines HASH_OP into enum, fix
  comments

version 4:
- fixes suggested by Krzysztof Kozlowski: reformat comments, convert context
  flags into two bool vars, drop SSS_ALIGNED, change name of SSS_DMA_ALIGN and
  SSS_DMA_ALIGN_MASK, split assignments into separate lines, use IS_ENABLED in
  place of ifdef, remove sss_hash_algs_info and simplify register and deregister
  HASH algs

version 3:
- many fixes suggested by Krzysztof Kozlowski: comments, uppercases in const,
  remove unused defines, remove unused variable bs, constify aes_variant,
  remove global var use_hash, remove WARN_ON, improve hash_import(),
  change goto label into 'out' in s5p_hash_handle_queue(), reorder variable
  declarations, add spinlock to protect clearing HASH_FLAGS_BUSY
- simplify code: replace one-line functions s5p_hash_update_req(),
  s5p_hash_final_req() with call to s5p_hash_xmit_dma(), and delete them
- replace call to s5p_hash_hw_init() into s5p_ahash_dma_init() and delete it
- fix clearing shash flag CRYPTO_TFM_REQ_MAY_SLEEP
- fix s5p_hash_set_flow()

version 2:
- change patch format so number of lines drops
- change in Kconfig as suggested by Krzysztof Kozlowski, add
EXYNOS_HASH subsection
- change #ifndef EXYNOS_RNG into #ifdef CRYPTO_DEV_EXYNOS_HASH
- remove style fixups in aes, as they should go in separate patch
- remove FLOW_LOG, FLOW_DUMP macros and its uses
- remove #if 0 ... endif
- remove unused function hash_wait and its defines
- fix compiler warning in dev_dbg
- remove some comments
- other minor fixes in comments

 drivers/crypto/Kconfig   |   14 +
 drivers/crypto/s5p-sss.c | 1441 +-
 2 files changed, 1445 insertions(+), 10 deletions(-)

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index fe33c199fc1a..01cf07ce34c5 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -439,6 +439,20 @@ config CRYPTO_DEV_S5P
  Select this to offload Samsung S5PV210 or S5PC110, Exynos from AES
  algorithms execution.
 
+config CRYPTO_DEV_EXYNOS_HASH
+   bool "Support for Samsung Exynos HASH accelerator"
+   depends on CRYPTO_DEV_S5P
+   depends on !CRYPTO_DEV_EXYNOS_RNG && CRYPTO_DEV_EXYNOS_RNG!=m
+   select CRYPTO_SHA1
+   select CRYPTO_MD5
+   select CRYPTO_SHA256
+   help
+ Select this to offload Exynos from HASH MD5/SHA1/SHA256.
+ This will select software SHA1, MD5 and SHA256 as they are
+ needed for small and zero-size messages.
+ HASH algorithms will be disabled if EXYNOS_RNG
+ is enabled due to hw conflict.
+
 config CRYPTO_DEV_NX
bool "Support for IBM PowerPC Nest (NX) cryptographic acceleration"
depends on PPC64
diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index 7ac657f46d15..29bec5a69fe8 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -1,18 +1,21 @@
 /*
  * Cryptographic API.
  *
- * Support for Samsung S5PV210 HW acceleration.
+ * Support for Samsung S5PV210 and Exynos HW acceleration.
  *
  * Copyright (C) 2011 NetUP Inc. All rights reserved.
+ * Copyright (c) 2017 Samsung Electronics Co., Ltd. All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as published
  * by the Free Software Foundation.
  *
+ * Hash part based on omap-sham.c driver.
  */
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -30,28 +33,41 @@
 #include 
 #include 
 
+#include 
+#include 
+#include 
+#include 
+
 #define _SBF(s, v)  ((v) << (s))
 
 /* Feed control registers */
 #define SSS_REG_FCINTSTAT   0x
+#define SSS_FCINTSTAT_HPARTINT BIT(7)
+#define SSS_FCINTSTAT_HDONEINT BIT(5)
 #define SSS_FCINTSTAT_BRDMAINT  BIT(3)
 #define SSS_FCINTSTAT_BTDMAINT  BIT(2)
 #define SSS_FCINTSTAT_HRDMAINT  BIT(1)
 #define SSS_FCINTSTAT_PKDMAINT