[PATCH 0/7] staging: ccree: bug fixes and TODO items for 4.13

An assortment of bug fixes and staging TODO items. Highlights includes the driver passing crypto testmgr boot tests and support of multiple HW revs. without build time changes. Gilad Ben-Yossef (7): staging: ccree: fix hash import/export staging: ccree: register setkey for none hash macs

[PATCH 1/7] staging: ccree: fix hash import/export

Hash import and export was saving and restoring the wrong context and therefore disabled. Fix it by restoring intermediate digest and additional state needed. The hash and mac transform now pass testmgr partial hash tests. Signed-off-by: Gilad Ben-Yossef ---

[PATCH 5/7] staging: ccree: add clock management support

Some SoC which implement CryptoCell have a dedicated clock tied to it, some do not. Implement clock support if exists based on device tree data and tie power management to it. Signed-off-by: Gilad Ben-Yossef --- drivers/staging/ccree/Makefile | 2 +-

[PATCH 7/7] staging: ccree: use signal safe completion wait

We were waiting for a completion notification of HW DMA operation using an interruptible wait which can result in data corruption if a signal interrupted us while DMA was not yet completed. Fix this by moving to uninterrupted wait. Fixes: abefd6741d ("staging: ccree: introduce CryptoCell HW

Re: [PATCH 0/7] staging: ccree: bug fixes and TODO items for 4.13

On Thu, Jun 22, 2017 at 10:14:08AM +0300, Gilad Ben-Yossef wrote: > On Thu, Jun 22, 2017 at 10:07 AM, Gilad Ben-Yossef > wrote: > > An assortment of bug fixes and staging TODO items. > > Highlights includes the driver passing crypto testmgr boot tests > > and support of

[PATCH 2/7] staging: ccree: register setkey for none hash macs

Fix a bug where the transformation init code did not register a setkey method for none hash based MACs. Fixes commit 50cfbbb7e627 ("staging: ccree: add ahash support"). Signed-off-by: Gilad Ben-Yossef --- drivers/staging/ccree/ssi_hash.c | 83

[PATCH 3/7] staging: ccree: add support for older HW revisions

Add support for the older CryptoCell 710 and 630P hardware revisions. Signed-off-by: Gilad Ben-Yossef --- drivers/staging/ccree/Kconfig| 7 +- drivers/staging/ccree/cc_crypto_ctx.h| 16 --- drivers/staging/ccree/cc_hw_queue_defs.h | 2 +-

[PATCH 4/7] staging: ccree: remove unused function

The function set_ack_last was not used anywhere. Remove it. Signed-off-by: Gilad Ben-Yossef --- drivers/staging/ccree/cc_hw_queue_defs.h | 12 1 file changed, 12 deletions(-) diff --git a/drivers/staging/ccree/cc_hw_queue_defs.h

[PATCH 6/7] staging: ccree: add DT bus coherency detection

The ccree driver has build time configurable support to work on top of coherent (e.g. ACP) vs. none coherent bus connections. Turn it to run-time configurable option based on device tree. Signed-off-by: Gilad Ben-Yossef --- drivers/staging/ccree/ssi_buffer_mgr.c | 37

Re: [PATCH 0/7] staging: ccree: bug fixes and TODO items for 4.13

On Thu, Jun 22, 2017 at 10:07 AM, Gilad Ben-Yossef wrote: > An assortment of bug fixes and staging TODO items. > Highlights includes the driver passing crypto testmgr boot tests > and support of multiple HW revs. without build time changes. > > Gilad Ben-Yossef (7): >

Re: [RFC PATCH] gcm - fix setkey cache coherence issues

On Thu, Jun 22, 2017 at 05:03:44AM +, Radu Solea wrote: > I'm adding cacheline_aligned to iv and result. That is done so hash, iv > and result never share a cache line. Yes but you're doing it in crypto/gcm.c which isn't even used by caam AFAIK. Cheers, -- Email: Herbert Xu

Re: [PATCH 0/7] staging: ccree: bug fixes and TODO items for 4.13

On Thu, Jun 22, 2017 at 11:28 AM, Dan Carpenter wrote: > On Thu, Jun 22, 2017 at 10:14:08AM +0300, Gilad Ben-Yossef wrote: >> On Thu, Jun 22, 2017 at 10:07 AM, Gilad Ben-Yossef >> wrote: >> > An assortment of bug fixes and staging TODO items. >> >

Re: XFRM Stats

Raj Ammanur wrote: > oops yes, completely forgot the lifetime stats. Thanks Herbert. > > I will check this out, but after a rekey, are the stats still preserved? No those stats are per-state. So your best bet would be to get this feature added to your user-space key

Re: [PATCH 6/7] staging: ccree: add DT bus coherency detection

On Thu, Jun 22, 2017 at 10:07:52AM +0300, Gilad Ben-Yossef wrote: > The ccree driver has build time configurable support > to work on top of coherent (e.g. ACP) vs. none coherent bus > connections. Turn it to run-time configurable option > based on device tree. > > Signed-off-by: Gilad Ben-Yossef

Re: [PATCH 1/2] crypto: caam - fix gfp allocation flags (part I)

On Mon, Jun 19, 2017 at 11:44:45AM +0300, Horia Geantă wrote: > Changes in the SW cts (ciphertext stealing) code in > commit 0605c41cc53ca ("crypto: cts - Convert to skcipher") > revealed a problem in the CAAM driver: > when cts(cbc(aes)) is executed and cts runs in SW, > cbc(aes) is offloaded in

Re: [PATCH 2/2] crypto: caam - fix gfp allocation flags (part II)

On Mon, Jun 19, 2017 at 11:44:46AM +0300, Horia Geantă wrote: > This is the 2nd part of fixing the usage of GFP_KERNEL for memory > allocations, taking care off all the places that haven't caused a real > problem / failure. > Again, the issue being fixed is that GFP_KERNEL should be used only when

Re: [PATCH] crypto: fix typo in docs

On Sun, Jun 18, 2017 at 11:53:41PM -0700, Benjamin Peterson wrote: > Signed-off-by: Benjamin Peterson Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key:

[RFC PATCH] crypto: ecdh: fix concurrency on ecdh_ctx

ecdh_ctx contained static allocated data for the shared secret, for the public and private key. When talking about shared secret and public key, they were doomed to concurrency issues because they could be shared by multiple crypto requests. The requests were generating specific data to the same

Re: [PATCH 1/1] crypto:drbg- Fixes panic in wait_for_completion call.

On Mon, Jun 12, 2017 at 12:00:49PM +0530, Harsh Jain wrote: > Hi Herbert, > > Since It's a panic BUG. Can we push this fix to stable kernel releases? I have added it to crypto with a stable CC. Thanks, -- Email: Herbert Xu Home Page:

Re: [PATCH 5/7] staging: ccree: add clock management support

On Thu, Jun 22, 2017 at 10:07:51AM +0300, Gilad Ben-Yossef wrote: > +int cc_clk_on(struct ssi_drvdata *drvdata) > +{ > + int rc = 0; > + struct clk *clk = drvdata->clk; > + > + if (IS_ERR(clk)) > + /* No all devices have a clock associated with CCREE */ > + goto out;

Re: [PATCH] crypto: cavium/nitrox - dma_mapping_error() returns bool

On Mon, Jun 19, 2017 at 01:51:25PM +0300, Dan Carpenter wrote: > We want to return negative error codes here, but we're accidentally > propogating the "true" return from dma_mapping_error(). > > Fixes: 14fa93cdcd9b ("crypto: cavium - Add support for CNN55XX adapters.") > Signed-off-by: Dan

Re: [PATCH] crypto: ccp - Release locks before returning

On Mon, Jun 19, 2017 at 12:31:17PM -0500, Gary R Hook wrote: > krobot warning: make sure that all error return paths release locks. > > Signed-off-by: Gary R Hook Patch applied. Thanks. -- Email: Herbert Xu Home Page:

Re: Regarding Porting of hardware cryptography to Linux kernel

On 06/22/2017 01:50 PM, sagar khadgi wrote: > Hi Marek, Hi, > I am having one microcontroller which has AES, HMAC, SHA, DES, RSA, DSA, > ECDSA cryptographic services. I want to port it to Linux Kernal so that > I can access them through OpenSSL from user space. > > I am new to Linux. Can you

[PATCH 3/3] crypto: cpp - Abstract interrupt registeration

The CCP and PSP devices part of AMD Secure Procesor may share the same interrupt. Hence we expand the SP device to register a common interrupt handler and provide functions to CCP and PSP devices to register their interrupt callback which will be invoked upon interrupt. Signed-off-by: Brijesh

[PATCH 2/3] crypto: ccp - Introduce the AMD Secure Processor device

The CCP device is part of the AMD Secure Processor. In order to expand the usage of the AMD Secure Processor, create a framework that allows functional components of the AMD Secure Processor to be initialized and handled appropriately. Signed-off-by: Brijesh Singh ---

[PATCH 1/3] crypto: ccp - Use devres interface to allocate PCI/iomap and cleanup

Update pci and platform files to use devres interface to allocate the PCI and iomap resources. Also add helper functions to consolicate module init, exit and power mangagement code duplication. Signed-off-by: Brijesh Singh --- drivers/crypto/ccp/ccp-dev-v3.c | 8 +++

[PATCH 0/3] Introduce AMD Secure Processor device

CCP device (drivers/crypto/ccp/ccp.ko) is part of AMD Secure Processor, which is not dedicated solely to crypto. The AMD Secure Processor includes CCP and PSP (Platform Secure Processor) devices. This patch series adds a framework that allows functional component of the AMD Secure Processor to be

[PATCH] crypto: qat - avoid an uninitialized variable warning

After commit 9e442aa6a753 ("x86: remove DMA_ERROR_CODE"), the inlining decisions in the qat driver changed slightly, introducing a new false-positive warning: drivers/crypto/qat/qat_common/qat_algs.c: In function 'qat_alg_sgl_to_bufl.isra.6': include/linux/dma-mapping.h:228:2: error: 'sz_out'

[PATCH v2 0/7] staging: ccree: bug fixes and TODO items for 4.13

An assortment of bug fixes and staging TODO items. Highlights includes the driver passing crypto testmgr boot tests and support of multiple HW revs. without build time changes. CC: Dan Carpenter Changes from v1: - Rebased on top of latest patches sent to mailing list

[PATCH v2 3/7] staging: ccree: add support for older HW revisions

Add support for the older CryptoCell 710 and 630P hardware revisions. Signed-off-by: Gilad Ben-Yossef --- drivers/staging/ccree/Kconfig| 7 +- drivers/staging/ccree/cc_crypto_ctx.h| 16 --- drivers/staging/ccree/cc_hw_queue_defs.h | 2 +-

[PATCH v2 1/7] staging: ccree: fix hash import/export

Hash import and export was saving and restoring the wrong context and therefore disabled. Fix it by restoring intermediate digest and additional state needed. The hash and mac transform now pass testmgr partial hash tests. Signed-off-by: Gilad Ben-Yossef ---

[PATCH v2 5/7] staging: ccree: add clock management support

Some SoC which implement CryptoCell have a dedicated clock tied to it, some do not. Implement clock support if exists based on device tree data and tie power management to it. Signed-off-by: Gilad Ben-Yossef --- drivers/staging/ccree/Makefile | 2 +-

[PATCH v2 6/7] staging: ccree: add DT bus coherency detection

The ccree driver has build time configurable support to work on top of coherent (e.g. ACP) vs. none coherent bus connections. Turn it to run-time configurable option based on device tree. Signed-off-by: Gilad Ben-Yossef --- drivers/staging/ccree/ssi_buffer_mgr.c | 37

Re: [PATCH] of: update ePAPR references to point to Devicetree Specification

On Mon, Jun 19, 2017 at 03:23:41AM -0700, Frank Rowand wrote: > On 06/18/17 07:05, Rob Herring wrote: > > On Tue, Jun 13, 2017 at 07:49:04PM -0700, frowand.l...@gmail.com wrote: > >> From: Frank Rowand > >> > >> The Devicetree Specification has superseded the ePAPR as the >

RE: [PATCH 5/7] ntb: ntb_hw_intel: remove ioread64 and iowrite64 hacks

> -Original Message- > From: linux-...@googlegroups.com [mailto:linux-...@googlegroups.com] On > Behalf Of Logan Gunthorpe > Sent: Thursday, June 22, 2017 9:48 AM > To: linux-ker...@vger.kernel.org; linux-a...@vger.kernel.org; > linux-...@googlegroups.com; linux-al...@vger.kernel.org;

Re: [PATCH 3/4] crypto: ccp - Add support for RSA on the CCP

On 6/21/2017 5:48 PM, Gary R Hook wrote: Wire up the v3 CCP as a cipher provider. The V5 support will be invoked through this also. Maybe something like: Wire up the CCP as an RSA cipher provider. Signed-off-by: Gary R Hook --- drivers/crypto/ccp/Makefile |

[PATCH 7/7] crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64

Now that ioread64 and iowrite64 are always available we don't need the ugly ifdefs to change their implementation when they are not. Signed-off-by: Logan Gunthorpe Cc: "Horia Geantă" Cc: Dan Douglass Cc: Herbert Xu

[PATCH 4/7] alpha: provide ioread64 and iowrite64 implementations

Alpha implements its own io operation and doesn't use the common library. Thus to make ioread64 and iowrite64 globally available we need to add implementations for alpha. For this, we simply use calls that chain two 32-bit operations. (mostly because I don't really understand the alpha

[PATCH 5/7] ntb: ntb_hw_intel: remove ioread64 and iowrite64 hacks

Now that ioread64 and iowrite64 are available generically we can remove the hack at the top of ntb_hw_intel.c that patches them in when they are not available. Signed-off-by: Logan Gunthorpe Cc: Jon Mason Cc: Dave Jiang Cc: Allen

[PATCH 6/7] drm/tilcdc: clean up ifdef hacks around iowrite64

Now that we can expect iowrite64 to always exist the hack is no longer necessary so we just call iowrite64 directly. Signed-off-by: Logan Gunthorpe Cc: Jyri Sarha Cc: Tomi Valkeinen Cc: David Airlie ---

[PATCH 0/7] cleanup issues with io{read|write}64

Hi, Presently, the 64bit IO functions are not very usable in drivers because they are not universally available in all architectures. This leads to a bunch of hacks in the kernel to work around this. (See the last 3 patches in this series.) As part of my switchtec_ntb submission which added

Re: [PATCH 3/4] crypto: ccp - Add support for RSA on the CCP

On 06/22/2017 12:15 AM, Stephan Müller wrote: Am Donnerstag, 22. Juni 2017, 00:48:01 CEST schrieb Gary R Hook: Hi Gary, Thanks, Stephen. Good catch(es). I will re-work this, but it looks like my changes should wait until after the patch set posted by Brijesh (Introduce AMD Secure Processor

Re: [PATCH 4/4] crypto: ccp - Expand RSA support for a v5 ccp

On 6/21/2017 5:48 PM, Gary R Hook wrote: A V5 device can accommodate larger keys, as well as read the keys directly from memory instead of requiring them to be in a local storage block. The previous patch already reads them from memory so just the first part of this sentence is needed.

Re: [PATCH 1/1] cavium: Add firmware for CNN55XX crypto driver.

On Fri, Jun 16, 2017 at 07:52:26PM +0530, Srikanth Jampala wrote: > This patchset adds the firmware for CNN55XX cryto driver, > supports Symmetric crypto operations. > > The version of the firmware is v07. > > Signed-off-by: Srikanth Jampala > --- > WHENCE|

Re: [PATCH v2] of: update ePAPR references to point to Devicetree Specification

On Thu, Jun 22, 2017 at 09:15:39AM -0700, frowand.l...@gmail.com wrote: > From: Frank Rowand > > The Devicetree Specification has superseded the ePAPR as the > base specification for bindings. Update files in Documentation > to reference the new document. > > First

[PATCH 3/7] asm-generic/io.h: make ioread64 and iowrite64 universally available

Currently, ioread64 and iowrite64 are only available io CONFIG_64BIT=y and CONFIG_GENERIC_IOMAP=n. Thus, seeing the functions are not universally available, it makes them unusable for driver developers. This leads to ugly hacks such as those at the top of drivers/ntb/hw/intel/ntb_hw_intel.c This

[PATCH 1/7] drm/tilcdc: don't use volatile with iowrite64

This is a prep patch for adding a universal iowrite64. The patch is to prevent compiler warnings when we add iowrite64 that would occur because there is an unnecessary volatile in this driver. Signed-off-by: Logan Gunthorpe Cc: Jyri Sarha Cc: Tomi Valkeinen

Re: [PATCH 4/7] alpha: provide ioread64 and iowrite64 implementations

> +#define iowrite64be(v,p) iowrite32(cpu_to_be64(v), (p)) Logan, thanks for taking this cleanup on. I think this should be iowrite64 not iowrite32? Stephen

[PATCH 2/7] iomap: implement ioread64 and iowrite64

Currently, ioread64 and iowrite64 are not impleminted in the generic iomap implementation. The prototypes are defined if CONFIG_64BIT is set but there is no actual implementation. Seeing the functions are not universally available, they are unusable for driver developers. This leads to ugly hacks

Re: [PATCH 4/7] alpha: provide ioread64 and iowrite64 implementations

On 6/22/2017 11:29 AM, Stephen Bates wrote: +#define iowrite64be(v,p) iowrite32(cpu_to_be64(v), (p)) Logan, thanks for taking this cleanup on. I think this should be iowrite64 not iowrite32? Yup, good catch. Thanks. I'll fix it in a v2 of this series. Logan

Re: [PATCH 4/7] alpha: provide ioread64 and iowrite64 implementations

On 6/22/2017 3:03 PM, Arnd Bergmann wrote: Drivers that want a non-atomic variant should include either include/linux/io-64-nonatomic-hi-lo.h or include/linux/io-64-nonatomic-lo-hi.h depending on what they need. Drivers that require 64-bit I/O should probably just depend on CONFIG_64BIT and

Re: [PATCH 4/7] alpha: provide ioread64 and iowrite64 implementations

On 6/22/2017 2:08 PM, Alan Cox wrote: But this does not do the same thing as an ioread64 with regards to atomicity or side effects on the device. The same is true of the other hacks. You either have a real 64bit single read/write from MMIO space or you don't. You can't fake it. Yes, I know.

Re: [PATCH 3/7] asm-generic/io.h: make ioread64 and iowrite64 universally available

On Thu, 22 Jun 2017 14:24:58 -0600 Logan Gunthorpe wrote: > On 6/22/2017 2:14 PM, Alan Cox wrote: > > If a platform doesn't support 64bit I/O operations from the CPU then you > > either need to use some kind of platform/architecture specific interface > > if present or

Re: [PATCH 3/7] asm-generic/io.h: make ioread64 and iowrite64 universally available

On 6/22/2017 2:36 PM, Alan Cox wrote: I think that makes sense for the platforms with that problem. I'm not sure there are many that can't do it for mmio at least. 486SX can't do it and I guess some ARM32 but I think almost everyone else can including most 32bit x86. What's more of a problem is

Re: [PATCH 4/7] alpha: provide ioread64 and iowrite64 implementations

On Thu, Jun 22, 2017 at 10:09 PM, Logan Gunthorpe wrote: > On 6/22/2017 2:08 PM, Alan Cox wrote: >> >> But this does not do the same thing as an ioread64 with regards to >> atomicity or side effects on the device. The same is true of the other >> hacks. You either have a real

Re: [PATCH 3/7] asm-generic/io.h: make ioread64 and iowrite64 universally available

On Thu, 22 Jun 2017 10:48:13 -0600 Logan Gunthorpe wrote: > Currently, ioread64 and iowrite64 are only available io CONFIG_64BIT=y > and CONFIG_GENERIC_IOMAP=n. Thus, seeing the functions are not > universally available, it makes them unusable for driver developers. > This

Re: [PATCH 3/7] asm-generic/io.h: make ioread64 and iowrite64 universally available

On 6/22/2017 2:14 PM, Alan Cox wrote: If a platform doesn't support 64bit I/O operations from the CPU then you either need to use some kind of platform/architecture specific interface if present or accept you don't have one. Yes, I understand that. The thing is that every user that's

Re: [PATCH 4/7] alpha: provide ioread64 and iowrite64 implementations

On Thu, 22 Jun 2017 10:48:14 -0600 Logan Gunthorpe wrote: > Alpha implements its own io operation and doesn't use the > common library. Thus to make ioread64 and iowrite64 globally > available we need to add implementations for alpha. > > For this, we simply use calls that

Re: [PATCH 4/7] alpha: provide ioread64 and iowrite64 implementations

On 06/22/2017 09:48 AM, Logan Gunthorpe wrote: Alpha implements its own io operation and doesn't use the common library. Thus to make ioread64 and iowrite64 globally available we need to add implementations for alpha. For this, we simply use calls that chain two 32-bit operations. (mostly

Re: [PATCH 5/7] x86, boot, LLVM: Use regparm=0 for memcpy and memset

On 03/17/17 05:08, Peter Zijlstra wrote: > On Thu, Mar 16, 2017 at 05:15:18PM -0700, Michael Davidson wrote: >> Use the standard regparm=0 calling convention for memcpy and >> memset when building with clang. >> >> This is a work around for a long standing clang bug >> (see

Re: [PATCH 1/4] crypto: ccp - Fix base RSA function for version 5 CCPs

On 6/21/2017 5:47 PM, Gary R Hook wrote: Version 5 devices have requirements for buffer lengths, as well as parameter format (e.g. bits vs. bytes). Fix the base CCP driver code to meet requirements all supported versions. Signed-off-by: Gary R Hook ---

Re: [PATCH 5/7] staging: ccree: add clock management support

On Thu, Jun 22, 2017 at 11:58 AM, Dan Carpenter wrote: > On Thu, Jun 22, 2017 at 10:07:51AM +0300, Gilad Ben-Yossef wrote: >> +int cc_clk_on(struct ssi_drvdata *drvdata) >> +{ >> + int rc = 0; >> + struct clk *clk = drvdata->clk; >> + >> + if (IS_ERR(clk)) >>

Re: [RFC PATCH] gcm - fix setkey cache coherence issues

On Jo, 2017-06-22 at 15:53 +0800, Herbert Xu wrote: > On Thu, Jun 22, 2017 at 05:03:44AM +, Radu Solea wrote: > > > > I'm adding cacheline_aligned to iv and result. That is done so > > hash, iv and result never share a cache line. > Yes but you're doing it in crypto/gcm.c which isn't even

Re: [PATCH 6/7] staging: ccree: add DT bus coherency detection

On Thu, Jun 22, 2017 at 12:04 PM, Dan Carpenter wrote: > On Thu, Jun 22, 2017 at 10:07:52AM +0300, Gilad Ben-Yossef wrote: >> The ccree driver has build time configurable support >> to work on top of coherent (e.g. ACP) vs. none coherent bus >> connections. Turn it to

[PATCH v2 4/7] staging: ccree: remove unused function

The function set_ack_last was not used anywhere. Remove it. Signed-off-by: Gilad Ben-Yossef --- drivers/staging/ccree/cc_hw_queue_defs.h | 12 1 file changed, 12 deletions(-) diff --git a/drivers/staging/ccree/cc_hw_queue_defs.h

[PATCH v2 2/7] staging: ccree: register setkey for none hash macs

Fix a bug where the transformation init code did not register a setkey method for none hash based MACs. Fixes commit 50cfbbb7e627 ("staging: ccree: add ahash support"). Signed-off-by: Gilad Ben-Yossef --- drivers/staging/ccree/ssi_hash.c | 83

[PATCH v2 7/7] staging: ccree: use signal safe completion wait

We were waiting for a completion notification of HW DMA operation using an interruptible wait which can result in data corruption if a signal interrupted us while DMA was not yet completed. Fix this by moving to uninterrupted wait. Fixes: abefd6741d ("staging: ccree: introduce CryptoCell HW

Re: [PATCH V2] staging: ccree: - style fix, spaces and tabs

On Sat, Jun 17, 2017 at 5:44 AM, Derek Robson wrote: > Changed code indent to be tabs across whole driver > Found using checkpatch > > Signed-off-by: Derek Robson > > V1 had vague subject. Acked-by: Gilad Ben-Yossef Thanks you,

Re: [PATCH] staging: ccree: fix coding style error

On Tue, Jun 20, 2017 at 5:51 PM, Jhih-Ming Huang wrote: > > Hi, > > This patch fix all coding style error in driver/staging/ccree/ssi_aead.c. For patches 1-6: Acked-by: Gilad Ben-Yossef Thanks you, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker

Re: [PATCH v2 1/7] staging: ccree: fix hash import/export

On Thu, Jun 22, 2017 at 04:36:55PM +0300, Gilad Ben-Yossef wrote: > static int ssi_ahash_export(struct ahash_request *req, void *out) > { > struct crypto_ahash *ahash = crypto_ahash_reqtfm(req); > struct ssi_hash_ctx *ctx = crypto_ahash_ctx(ahash); > + struct device *dev =