On 6/22/2017 7:49 PM, Logan Gunthorpe wrote:
> Now that ioread64 and iowrite64 are always available we don't
> need the ugly ifdefs to change their implementation when they
> are not.
>
Thanks Logan.
Note however this is not equivalent - it changes the behaviour, since
CAAM engine on i.MX6S/SL/D/
On Mon, Jun 19, 2017 at 09:55:24AM +0200, Corentin Labbe wrote:
>
> Since there are two different user of "crypto engine + ablkcipher", it will
> be not easy to convert them in one serie. (I could do it, but I simply could
> not test it for OMAP (lack of hw))
> And any new user which want to use
In Broadcom SPU driver, due to missing break statement
in spu2_hash_xlate() while mapping SPU2 equivalent
SHA3-512 value, -EINVAL is chosen and hence leading to
failure of SHA3-512 algorithm. This patch fixes the same.
Signed-off-by: Raveendra Padasalagi
Reviewed-by: Ray Jui
Reviewed-by: Scott B
On Thu, Jun 22, 2017 at 01:56:40PM +, Radu Solea wrote:
> There are two ways of fixing this AFAIK: the first is adding
> cacheline_aligned so those fields don't fall into the same cacheline.
> The second is to kzalloc hash and iv separately. kmalloc should honor
> ARCH_DMA_MINALIGN which would
On Wed, Jun 21, 2017 at 10:03:02PM +0200, Stephan Müller wrote:
>
> + /* convert iovecs of output buffers into RX SGL */
> + while (len < ctx->used && msg_data_left(msg)) {
How are we supposed to reach the wait path when ctx->used == 0?
> + /*
> + * This error cov
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 https://llvm.org/bugs/sh
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 becaus
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 maybe
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 64bit single read/wri
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
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 accept you don't have one.
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 currently
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 leads to ugly hacks suc
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. But
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 chain two 32-bit opera
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| 9 +
> cnn55xx_se.f
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
> +#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
> -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; l
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 d
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
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 Hubbe
---
drivers/ntb/hw/intel/ntb_hw_intel.c | 30
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
---
drivers/gpu/drm/tilcdc/tilcdc_regs.h | 6 --
1 file changed, 6 deletions(-)
diff --gi
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 architectur
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 anothe
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
Cc: "David S. Miller"
---
drivers/crypto/caam/regs.h | 29 ---
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
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
Cc: David Airlie
---
drivers/gpu/d
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.
Sign
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 reference to ePAPR in Documen
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 |1
drivers/crypt
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 reference to ePAPR in Documentation/devicetree/bindings/arm/cci.txt
is generic, remove it.
Some files are not upda
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
> >> base specification f
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
---
drivers/crypto/ccp/ccp-dev-v5.c | 10 +
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 = &ctx->d
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
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
"If you take a class in large-scale robotics,
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,
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
"If you take
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
---
drivers/staging/ccree/ssi_hash.c | 1
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 but not yet marged for sam
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 +-
drivers/staging/ccree/cc_regs.h
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 ++--
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 +-
drivers/staging/ccree/ssi_driver.c | 40
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
b/drivers/staging/ccree/cc_hw_queue_defs.h
index c73
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
1 file cha
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 drive
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 run-time configurable option
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))
>> + /* No all devices ha
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' may
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 ple
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 +++
drivers/crypto/ccp/ccp-d
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 Sing
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
---
drivers/crypto/Kconfig
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
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 z
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
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: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~h
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 Carpent
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
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 C
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: http://gondor.apana.org.au/~herbert/pubkey.txt
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: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor
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;
Ug
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.
>> > Highlights includes the driver passing crypto te
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 multiple HW revs. without
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 manager, and get it to read
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
Home Page:
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):
> staging: ccree: fix hash im
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
b/drivers/staging/ccree/cc_hw_queue_defs.h
index c73
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
1 file cha
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 +-
drivers/staging/ccree/cc_regs.h
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 ++--
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 drive
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 +-
drivers/staging/ccree/ssi_driver.c | 43
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
---
drivers/staging/ccree/ssi_hash.c | 1
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
sta
76 matches
Mail list logo
