[PATCH] staging: ccree: Fix lines longer than 80 characters
--- 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()'
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()
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Cc: Herbert XuCc: "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
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
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
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
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
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
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
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