On Tue, Mar 06, 2018 at 10:37:47AM +0530, Harsh Jain wrote:
> It includes bug fixes and code cleanup.
>
> Changes from v1:
>
> Remove Redundant soffset initialisation from 2/5.
Hmm, the first series has already been applied. So if you want
to change it then you'll need to send patches based on
On Mon, Mar 05, 2018 at 02:30:57PM -0600, Gary R Hook wrote:
>
> So a failure to communicate a newly-required behavior change, much less
> document it, is addressed by breaking drivers? For some reason this seems
> wrong.
>
> It's also wrong to change the documentation after the fact, and after
>
Hi Herbert,
Please ignore this series. V2 sent with minor change.
On 11-01-2018 16:45, Harsh Jain wrote:
> This series include cleanup, bug fixes and authenc algo supporting
> ctr(aes)-sha operation.
>
> Harsh Jain (5):
> crypto: chelsio - Fix Indentation
> crypto: chelsio - check for sg nu
Replace DIV_ROUND_UP to roundup or rounddown
Signed-off-by: Harsh Jain
---
drivers/crypto/chelsio/chcr_algo.c | 73 ++
drivers/crypto/chelsio/chcr_algo.h | 1 -
2 files changed, 34 insertions(+), 40 deletions(-)
diff --git a/drivers/crypto/chelsio/chcr_algo.
CBC Decryption requires Last Block as IV. In case src/dst buffer
are same last block will be replaced by plain text. This patch copies
the Last Block before sending request to HW.
Signed-off-by: Harsh Jain
---
drivers/crypto/chelsio/chcr_algo.c | 19 +++
1 file changed, 11 insert
We use ctr(aes) to fallback rfc3686(ctr) request. Send updated IV to fallback
path.
Signed-off-by: Harsh Jain
---
drivers/crypto/chelsio/chcr_algo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/chelsio/chcr_algo.c
b/drivers/crypto/chelsio/chcr_algo.c
index
ulptx header cannot have length > 64k. Adjust length accordingly.
Signed-off-by: Harsh Jain
---
drivers/crypto/chelsio/chcr_algo.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/crypto/chelsio/chcr_algo.c
b/drivers/crypto/chelsio/chcr_algo.c
index
Send multiple WRs to H/W when No. of entries received in scatter list
cannot be sent in single request.
Signed-off-by: Harsh Jain
---
drivers/crypto/chelsio/chcr_algo.c | 358 ++-
drivers/crypto/chelsio/chcr_algo.h | 10 +-
drivers/crypto/chelsio/chcr_core.h
It includes bug fixes and code cleanup.
Changes from v1:
Remove Redundant soffset initialisation from 2/5.
Harsh Jain (5):
crypto:chelsio: Use kernel round function to align lengths
crypto:chelsio: Fix src buffer dma length
crypto:chelsio: Update IV before sending request to HW
crypto:ch
On Thu, Mar 01, 2018 at 07:54:59AM -0500, Vitaly Andrianov wrote:
> The Keystone SA module has a hardware random generator module.
> This commit adds binding doc for the KS2 SA HWRNG driver.
Preferred subject prefix is "dt-bindings: rng: ..."
>
> Signed-off-by: Vitaly Andrianov
> Signed-off-by:
Hi Vladimir,
On Mon, Mar 5, 2018 at 8:44 PM, Vladimir Zapolskiy wrote:
> Yes, I have a pretty good i.MX31 dtsi change (tested everything but USB
> and multimedia, and that notorious watchdog problem still has to be
> agreed with Uwe and solved), but I'm trying to save my time a little, and
> my
On Mon, Mar 5, 2018 at 7:21 PM, Vladimir Zapolskiy wrote:
> The driver works well on i.MX31 powered boards with device description
> taken from board device tree, the only change to add to the driver is
> the missing OF device id, the affected list of included headers and
> indentation in platform
On Mon, Mar 5, 2018 at 7:20 PM, Vladimir Zapolskiy wrote:
> Freescale i.MX21 and i.MX31 SoCs contain a Random Number Generator
> Accelerator module (RNGA), which is replaced by RNGB and RNGC modules
> on later i.MX SoC series, the change adds a new compatible property
> to describe the controller.
Hi Fabio,
On 03/06/2018 12:24 AM, Fabio Estevam wrote:
> Hi Vladimir,
>
> On Mon, Mar 5, 2018 at 7:21 PM, Vladimir Zapolskiy wrote:
>> The driver works well on i.MX31 powered boards with device description
>> taken from board device tree, the only change to add to the driver is
>> the missing OF
Hi Vladimir,
On Mon, Mar 5, 2018 at 7:21 PM, Vladimir Zapolskiy wrote:
> The driver works well on i.MX31 powered boards with device description
> taken from board device tree, the only change to add to the driver is
> the missing OF device id, the affected list of included headers and
> indentati
Freescale i.MX21 and i.MX31 SoCs contain a Random Number Generator
Accelerator module (RNGA), which is replaced by RNGB and RNGC modules
on later i.MX SoC series, the change adds a new compatible property
to describe the controller.
Since all versions of Freescale RNG modules are legacy, apparentl
The series is a trivial change to extend Freescale i.MX31 RNGA
driver to work on boards with device description taken from device
tree blob. The change was tested on a legacy LogicPD MX31Lite board.
Vladimir Zapolskiy (2):
dt-bindings: rng: Document Freescale i.MX21 and i.MX31 RNGA compatibles
The driver works well on i.MX31 powered boards with device description
taken from board device tree, the only change to add to the driver is
the missing OF device id, the affected list of included headers and
indentation in platform driver struct are beautified a little.
Signed-off-by: Vladimir Za
On Mon, Feb 26, 2018 at 08:38:48PM +0200, Vladimir Zapolskiy wrote:
> Freescale i.MX31 SoC contains a Security Random Number Generator
> Accelerator module (RNGA), which is replaced by RNGB and RNGC modules
> on later i.MX SoC series, the change adds a new compatible property
> to describe the cont
On 03/05/2018 12:31 PM, Kamil Konieczny wrote:
On 05.03.2018 18:47, Gary R Hook wrote:
On 03/05/2018 03:57 AM, Kamil Konieczny wrote:
On 02.03.2018 22:11, Gary R Hook wrote:
Commit 466d7b9f6 (cryptodev-2.6) added code to testmgr to populate, for async
hash operations,
the result buffer wi
On 3/5/2018 12:31 PM, Kamil Konieczny wrote:
>
>
> On 05.03.2018 18:47, Gary R Hook wrote:
>> On 03/05/2018 03:57 AM, Kamil Konieczny wrote:
>>>
>>>
>>> On 02.03.2018 22:11, Gary R Hook wrote:
Commit 466d7b9f6 (cryptodev-2.6) added code to testmgr to populate, for
async hash operations
On 03/05/2018 07:10 AM, SF Markus Elfring wrote:
From: Markus Elfring
Date: Mon, 5 Mar 2018 13:50:13 +0100
Reuse existing functionality from memdup_user() instead of keeping
duplicate source code.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
Acked
Add a NEON-accelerated implementation of Speck128-XTS and Speck64-XTS
for ARM64. This is ported from the 32-bit version. It may be useful on
devices with 64-bit ARM CPUs that don't have the Cryptography
Extensions, so cannot do AES efficiently -- e.g. the Cortex-A53
processor on the Raspberry Pi
Now that ioread64 and iowrite64 are available in io-64-nonatomic,
we can remove the hack at the top of ntb_hw_intel.c and replace it
with an include.
Signed-off-by: Logan Gunthorpe
Reviewed-by: Andy Shevchenko
Acked-by: Dave Jiang
Acked-by: Allen Hubbe
Acked-by: Jon Mason
# Please enter the
This is v11 of my cleanup series to push a number of instances of people
defining their own io{read|write}64 functions into common headers seing
they don't exist in non-64bit systems. This series adds inline functions to the
io-64-nonatomic headers and then cleans up the drivers that defined their
This patch adds generic io{read|write}64[be]{_lo_hi|_hi_lo} macros if
they are not already defined by the architecture. (As they are provided
by the generic iomap library).
The patch also points io{read|write}64[be] to the variant specified by the
header name.
This is because new drivers are enco
Clean up the ifdefs which conditionally defined the io{read|write}64
functions in favour of the new common io-64-nonatomic-lo-hi header.
Signed-off-by: Logan Gunthorpe
Cc: Jon Mason
---
drivers/ntb/hw/mscc/ntb_hw_switchtec.c | 30 +-
1 file changed, 1 insertion(+), 2
In order to provide non-atomic functions for io{read|write}64 that will
use readq and writeq when appropriate. We define a number of variants
of these functions in the generic iomap that will do non-atomic
operations on pio but atomic operations on mmio.
These functions are only defined if readq a
These functions will be introduced into the generic iomap.c so
they can deal with PIO accesses in hi-lo/lo-hi variants. Thus,
the powerpc version of iomap.c will need to provide the same
functions even though, in this arch, they are identical to the
regular io{read|write}64 functions.
Signed-off-b
Clean up the extra ifdefs which defined the wr_reg64 and rd_reg64
functions in non-64bit cases in favour of the new common
io-64-nonatomic-lo-hi header.
To be consistent with CAAM engine HW spec: in case of 64-bit registers,
irrespective of device endianness, the lower address should be read from
Subsequent patches in this series makes use of the readq and writeq
defines in iomap.h. However, as is, they get missed on the powerpc
platform seeing the include comes before the define. This patch
moves the include down to fix this.
Signed-off-by: Logan Gunthorpe
Acked-by: Michael Ellerman
Rev
On 3/5/18 7:10 AM, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Mon, 5 Mar 2018 13:50:13 +0100
>
> Reuse existing functionality from memdup_user() instead of keeping
> duplicate source code.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfrin
On 05.03.2018 18:47, Gary R Hook wrote:
> On 03/05/2018 03:57 AM, Kamil Konieczny wrote:
>>
>>
>> On 02.03.2018 22:11, Gary R Hook wrote:
>>> Commit 466d7b9f6 (cryptodev-2.6) added code to testmgr to populate, for
>>> async hash operations,
>>> the result buffer with a known value and to test th
On 03/05/2018 03:57 AM, Kamil Konieczny wrote:
On 02.03.2018 22:11, Gary R Hook wrote:
Commit 466d7b9f6 (cryptodev-2.6) added code to testmgr to populate, for async
hash operations,
the result buffer with a known value and to test the buffer against that value
at intermediate
steps. If the r
On Mon, Mar 05, 2018 at 06:58:32AM -0800, James Bottomley wrote:
> On Mon, 2018-03-05 at 13:35 +0200, Jarkko Sakkinen wrote:
> > On Fri, Mar 02, 2018 at 10:06:15PM -0800, James Bottomley wrote:
> > >
> > > diff --git a/drivers/char/tpm/tpm2b.h b/drivers/char/tpm/tpm2b.h
> > > new file mode 100644
On 03/05/2018 03:50 AM, Herbert Xu wrote:
On Fri, Mar 02, 2018 at 03:11:52PM -0600, Gary R Hook wrote:
Commit 466d7b9f6 (cryptodev-2.6) added code to testmgr to populate, for
async hash operations, the result buffer with a known value and to test the
buffer against that value at intermediate ste
On Mon, 2018-03-05 at 07:04 -0700, Jason Gunthorpe wrote:
> On Fri, Mar 02, 2018 at 10:04:54PM -0800, James Bottomley wrote:
> >
> > By now, everybody knows we have a problem with the TPM2_RS_PW easy
> > button on TPM2 in that transactions on the TPM bus can be
> > intercepted and altered. The wa
On Mon, 2018-03-05 at 13:35 +0200, Jarkko Sakkinen wrote:
> On Fri, Mar 02, 2018 at 10:06:15PM -0800, James Bottomley wrote:
> >
> > diff --git a/drivers/char/tpm/tpm2b.h b/drivers/char/tpm/tpm2b.h
> > new file mode 100644
> > index ..c7726f2895aa
> > --- /dev/null
> > +++ b/drivers/ch
On Fri, Mar 02, 2018 at 10:04:54PM -0800, James Bottomley wrote:
> By now, everybody knows we have a problem with the TPM2_RS_PW easy
> button on TPM2 in that transactions on the TPM bus can be intercepted
> and altered. The way to fix this is to use real sessions for HMAC
> capabilities to ensure
From: Colin Ian King
The array des3_ede_skciphers is local to the source and does not need
to be in global scope, so make it static.
Cleans up sparse warning:
arch/x86/crypto/des3_ede_glue.c:407:21: warning: symbol
'des3_ede_skciphers' was not declared. Should it be static?
Signed-off-by: Colin
From: Markus Elfring
Date: Mon, 5 Mar 2018 13:50:13 +0100
Reuse existing functionality from memdup_user() instead of keeping
duplicate source code.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/crypto/ccp/psp-dev.c | 15 +--
1
On Mon, Mar 05, 2018 at 01:35:33PM +0200, Jarkko Sakkinen wrote:
> On Fri, Mar 02, 2018 at 10:06:15PM -0800, James Bottomley wrote:
> > diff --git a/drivers/char/tpm/tpm2b.h b/drivers/char/tpm/tpm2b.h
> > new file mode 100644
> > index ..c7726f2895aa
> > --- /dev/null
> > +++ b/drivers/
On Fri, Mar 02, 2018 at 10:06:15PM -0800, James Bottomley wrote:
> diff --git a/drivers/char/tpm/tpm2b.h b/drivers/char/tpm/tpm2b.h
> new file mode 100644
> index ..c7726f2895aa
> --- /dev/null
> +++ b/drivers/char/tpm/tpm2b.h
> @@ -0,0 +1,82 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
Even though it doesn't make too much sense, it is perfectly legal to:
- call .init() and then (as many times) .update()
- subseqently _not_ call any of .final(), .finup() or .export()
Update documentation since this is an important issue to consider
from resource management perspective.
Link: htt
On 02.03.2018 22:11, Gary R Hook wrote:
> Commit 466d7b9f6 (cryptodev-2.6) added code to testmgr to populate, for async
> hash operations,
> the result buffer with a known value and to test the buffer against that
> value at intermediate
> steps. If the result buffer changes the operation is f
On Fri, Mar 02, 2018 at 03:11:52PM -0600, Gary R Hook wrote:
> Commit 466d7b9f6 (cryptodev-2.6) added code to testmgr to populate, for
> async hash operations, the result buffer with a known value and to test the
> buffer against that value at intermediate steps. If the result buffer
> changes the
On 01/03/18 22:50, Krzysztof Kozlowski wrote:
Commit 8043bb1ae03c ("crypto: omap-sham - convert driver logic to use
sgs for data xmit") removed the if() clause leaving the statement as is.
The intention was in that case to finish the request always so the goto
instruction seems sensible.
Remove
On 01/03/18 22:50, Krzysztof Kozlowski wrote:
ahash_request 'req' argument passed by the caller
omap_sham_handle_queue() cannot be NULL here because it is obtained from
non-NULL pointer via container_of().
This fixes smatch warning:
drivers/crypto/omap-sham.c:812 omap_sham_prepare_request()
48 matches
Mail list logo
