Hi Lukasz,
On 27 November 2017 at 15:28, Łukasz Stelmach wrote:
> Add support for True Random Number Generator found in Samsung Exynos
> 5250+ SoCs.
>
> Signed-off-by: Łukasz Stelmach
> ---
> MAINTAINERS | 7 +
> drivers/char/hw_random/Kconfig | 12 ++
> driver
From: James Hogan
Current MIPS64r6 toolchains aren't able to generate efficient
DMULU/DMUHU based code for the C implementation of umul_ppmm(), which
performs an unsigned 64 x 64 bit multiply and returns the upper and
lower 64-bit halves of the 128-bit result. Instead it widens the 64-bit
inputs
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
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
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
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
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
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.
Signed-off-by: Logan Gunthorpe
Cc: Andy Shevchenko
Cc: Horia Geantă
Cc: Dan Douglass
Cc: Herbert Xu
Cc: "David S. Miller"
---
drivers/cryp
This is v9 of my cleanup series to push a number of instances of people
defining their own io{read|write}64 functions when 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
own.
Changes since v8
Add a check to ensure iowrite64 is only used if it is atomic.
It was decided in [1] that the tilcdc driver should not be using an
atomic operation (so it was left out of this patchset). However, it turns
out that through the drm code, a nonatomic header is actually included:
include/linux/io-64-n
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
On Tue, Dec 5, 2017 at 6:53 PM, Krzysztof Kozlowski wrote:
> On Tue, Dec 05, 2017 at 05:43:10PM +0100, Łukasz Stelmach wrote:
>> It was <2017-12-05 wto 14:54>, when Stephan Mueller wrote:
>> > Am Dienstag, 5. Dezember 2017, 13:35:57 CET schrieb Łukasz Stelmach:
>> >
>> > Hi Łukasz,
>> >
>> >> Use
On 5 December 2017 at 12:45, Ard Biesheuvel wrote:
>
>
>> On 5 Dec 2017, at 12:28, Dave Martin wrote:
>>
>>> On Mon, Dec 04, 2017 at 12:26:37PM +, Ard Biesheuvel wrote:
>>> Add a support macro to conditionally yield the NEON (and thus the CPU)
>>> that may be called from the assembler code. G
On Tue, Dec 05, 2017 at 05:20:46PM +0100, Łukasz Stelmach wrote:
> exynos-rng is one of many implementations of stdrng. With priority as
> low as 100 it isn't selected, if software implementations (DRBG) are
> available. The value 300 was selected to give the PRNG priority before
> software impleme
On Tue, Dec 05, 2017 at 05:43:10PM +0100, Łukasz Stelmach wrote:
> It was <2017-12-05 wto 14:54>, when Stephan Mueller wrote:
> > Am Dienstag, 5. Dezember 2017, 13:35:57 CET schrieb Łukasz Stelmach:
> >
> > Hi Łukasz,
> >
> >> Use memcpy_fromio() instead of custom exynos_rng_copy_random() function
It was <2017-12-05 wto 14:54>, when Stephan Mueller wrote:
> Am Dienstag, 5. Dezember 2017, 13:35:57 CET schrieb Łukasz Stelmach:
>
> Hi Łukasz,
>
>> Use memcpy_fromio() instead of custom exynos_rng_copy_random() function
>> to retrieve generated numbers from the registers of PRNG.
>>
>> Remove un
Am Dienstag, 5. Dezember 2017, 17:20:46 CET schrieb Łukasz Stelmach:
Hi Łukasz,
> exynos-rng is one of many implementations of stdrng. With priority as
> low as 100 it isn't selected, if software implementations (DRBG) are
> available. The value 300 was selected to give the PRNG priority before
>
exynos-rng is one of many implementations of stdrng. With priority as
low as 100 it isn't selected, if software implementations (DRBG) are
available. The value 300 was selected to give the PRNG priority before
software implementations, but allow them to be selected in FIPS-mode
(fips=1 in the kerne
Hello,
On Tue, Dec 5, 2017, at 12:40, Atul Gupta wrote:
> CPL handlers for TLS session, record transmit and receive
This does very much looks like full TCP offload with TLS on top? It
would be nice if you could give a few more details in the patch
descriptions.
Bye,
Hannes
On Tue, Dec 05, 2017 at 05:37:44PM +0200, Horia Geantă wrote:
> commit 2b163b5bce04546da72617bfb6c8bf07a45c4b17 upstream.
Now queued up, thanks!
greg k-h
commit 2b163b5bce04546da72617bfb6c8bf07a45c4b17 upstream.
This reverts commit 66d2e2028091a074aa1290d2eeda5ddb1a6c329c.
Quoting from Russell's findings:
https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg21136.html
[quote]
Okay, I've re-tested, using a different way of measuring, becau
On Tue, 5 Dec 2017 17:10:00 +0530
Atul Gupta wrote:
> CPL handlers for TLS session, record transmit and receive
>
> Signed-off-by: Atul Gupta
> ---
> drivers/crypto/chelsio/chtls/chtls_cm.c | 2048
> +++
> 1 file changed, 2048 insertions(+)
> create mode 100644 d
loop-AES changes since previous release:
- Worked around kernel interface changes on 4.14 and 4.15-rc kernels.
- Fixed possible timer delete race condition at loop detach time when key
scrubbing was enabled.
bzip2 compressed tarball is here:
http://loop-aes.sourceforge.net/loop-AES/loop-AE
On Tue, Dec 5, 2017 at 1:35 PM, Łukasz Stelmach wrote:
> Reseed PRNG after reading 65 kB of randomness. Although this may reduce
> performance, in most casese the loss is not noticable.
s/casese/cases/
s/noticable/noticeable/
Please explain why you want to reseed after 65 kB (as opposite to
curre
Am Dienstag, 5. Dezember 2017, 13:35:57 CET schrieb Łukasz Stelmach:
Hi Łukasz,
> Use memcpy_fromio() instead of custom exynos_rng_copy_random() function
> to retrieve generated numbers from the registers of PRNG.
>
> Remove unnecessary invocation of cpu_relax().
>
> Signed-off-by: Łukasz Stelm
Am Dienstag, 5. Dezember 2017, 13:35:58 CET schrieb Łukasz Stelmach:
Hi Łukasz,
> Reseed PRNG after reading 65 kB of randomness. Although this may reduce
> performance, in most casese the loss is not noticable.
Please add to the log that you also increase the timer-based reseed to 1
second?!
A
On Tue, Dec 5, 2017 at 1:35 PM, Łukasz Stelmach wrote:
> Use memcpy_fromio() instead of custom exynos_rng_copy_random() function
> to retrieve generated numbers from the registers of PRNG.
>
> Remove unnecessary invocation of cpu_relax().
>
> Signed-off-by: Łukasz Stelmach
> ---
> drivers/crypto
Am Dienstag, 5. Dezember 2017, 13:42:14 CET schrieb Łukasz Stelmach:
Hi Łukasz,
> exynos-rng is one of many implementations of stdrng. With priority as
> low as 100 it isn't selected, if software implementations (DRBG) are
> available.
What about using 300? The reason is the following: in the no
On Tue, Dec 5, 2017 at 1:35 PM, Łukasz Stelmach wrote:
> Add support for PRNG in Exynos5250+ SoCs.
>
> Signed-off-by: Łukasz Stelmach
> ---
> .../bindings/crypto/samsung,exynos-rng4.txt| 4 ++-
> drivers/crypto/exynos-rng.c| 36
> --
> 2 file
Am Dienstag, 5. Dezember 2017, 12:40:29 CET schrieb Atul Gupta:
Hi Atul,
> program the tx and rx key on chip.
>
> Signed-off-by: Atul Gupta
> ---
> drivers/crypto/chelsio/chtls/chtls_hw.c | 394
> 1 file changed, 394 insertions(+)
> create mode 100644 drivers/c
> On 5 Dec 2017, at 12:28, Dave Martin wrote:
>
>> On Mon, Dec 04, 2017 at 12:26:37PM +, Ard Biesheuvel wrote:
>> Add a support macro to conditionally yield the NEON (and thus the CPU)
>> that may be called from the assembler code. Given that especially the
>> instruction based accelerated
exynos-rng is one of many implementations of stdrng. With priority as
low as 100 it isn't selected, if software implementations (DRBG) are
available.
Signed-off-by: Łukasz Stelmach
---
If not 1000, what is the best value, what is the policy?
drivers/crypto/exynos-rng.c | 2 +-
1 file changed,
Reseed PRNG after reading 65 kB of randomness. Although this may reduce
performance, in most casese the loss is not noticable.
Signed-off-by: Łukasz Stelmach
---
drivers/crypto/exynos-rng.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/exy
Hello,
This is a series of patches for exynos-rng driver I've decided to
create after adding support for Exynos5250+ chips. They do not
strictly depend on each other, but I think it is better to send them
as a single patch-set.
Patch #1 Add support for PRNG in Exynos5250+ SoCs
Patch #2 Improve o
Use memcpy_fromio() instead of custom exynos_rng_copy_random() function
to retrieve generated numbers from the registers of PRNG.
Remove unnecessary invocation of cpu_relax().
Signed-off-by: Łukasz Stelmach
---
drivers/crypto/exynos-rng.c | 36 +---
1 file change
Add support for PRNG in Exynos5250+ SoCs.
Signed-off-by: Łukasz Stelmach
---
.../bindings/crypto/samsung,exynos-rng4.txt| 4 ++-
drivers/crypto/exynos-rng.c| 36 --
2 files changed, 36 insertions(+), 4 deletions(-)
diff --git a/Documentation/
On Mon, Dec 04, 2017 at 12:26:37PM +, Ard Biesheuvel wrote:
> Add a support macro to conditionally yield the NEON (and thus the CPU)
> that may be called from the assembler code. Given that especially the
> instruction based accelerated crypto code may use very tight loops, add
> some parametri
Entry for Inline TLS as another driver dependent on cxgb4 and chcr
Signed-off-by: Atul Gupta
---
drivers/crypto/chelsio/Kconfig | 10 ++
drivers/crypto/chelsio/Makefile | 1 +
2 files changed, 11 insertions(+)
diff --git a/drivers/crypto/chelsio/Kconfig b/drivers/crypto/chelsio/Kconfi
program the tx and rx key on chip.
Signed-off-by: Atul Gupta
---
drivers/crypto/chelsio/chtls/chtls_hw.c | 394
1 file changed, 394 insertions(+)
create mode 100644 drivers/crypto/chelsio/chtls/chtls_hw.c
diff --git a/drivers/crypto/chelsio/chtls/chtls_hw.c
b/
Inline TLS state, connection management. Support macros definition.
Signed-off-by: Atul Gupta
---
drivers/crypto/chelsio/chtls/Makefile | 4 +
drivers/crypto/chelsio/chtls/chtls.h| 481
drivers/crypto/chelsio/chtls/chtls_cm.h | 209 ++
3 files
CPL handlers for TLS session, record transmit and receive
Signed-off-by: Atul Gupta
---
drivers/crypto/chelsio/chtls/chtls_cm.c | 2048 +++
1 file changed, 2048 insertions(+)
create mode 100644 drivers/crypto/chelsio/chtls/chtls_cm.c
diff --git a/drivers/crypto/chel
TLS handler for record transmit and receive.
Create Inline TLS work request
Signed-off-by: Atul Gupta
---
drivers/crypto/chelsio/chtls/chtls_io.c | 1866 +++
1 file changed, 1866 insertions(+)
create mode 100644 drivers/crypto/chelsio/chtls/chtls_io.c
diff --git a/d
Define the Macro for TLS Key context
Signed-off-by: Atul Gupta
---
drivers/crypto/chelsio/chcr_algo.h | 42 +
drivers/crypto/chelsio/chcr_core.h | 55 +-
include/uapi/linux/tls.h | 1 +
3 files changed, 97 insertions(+),
Register chtls as another tcp ULP, Based on a similar infrastructure
in tcp_cong. proto_ops are defined to handle CPL to send/receive
crypto request to hw.
Signed-off-by: Atul Gupta
---
drivers/crypto/chelsio/chtls/chtls_main.c | 585 ++
1 file changed, 585 insertions
Add new uld driver for Inline TLS support. WR is defined to
submit crypto request to firmware.
Key area size is configured in hw-config file.
Signed-off-by: Atul Gupta
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c | 18 ++-
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c| 32 ++--
RFC series for Chelsio Inline TLS driver (chtls.ko)
Chtls driver use the available ULP infrastructure to register
chtls as another ULP. Chtls use the TCP Sockets to transmit and
receive TLS record. TCP proto_ops is extended to offload TLS
record.
T6 adapter provide the following features:
fix a type cast error for queue descriptor
Reported-by: Dan Carpenter
Signed-off-by: Atul Gupta
---
drivers/crypto/chelsio/chcr_ipsec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/chelsio/chcr_ipsec.c
b/drivers/crypto/chelsio/chcr_ipsec.c
index f90f991..a
Without the gf128mul library support, we can run into a link
error:
drivers/crypto/chelsio/chcr_algo.o: In function `chcr_update_tweak':
chcr_algo.c:(.text+0x7e0): undefined reference to `gf128mul_x8_ble'
This adds a Kconfig select statement for it, next to the ones we
already have.
Fixes: b8fd1
On Tue, Dec 5, 2017 at 10:30 AM, Łukasz Stelmach wrote:
> It was <2017-12-04 pon 14:13>, when Krzysztof Kozlowski wrote:
>> On Mon, Dec 4, 2017 at 1:53 PM, Łukasz Stelmach
>> wrote:
>>> Add binding documentation for the True Random Number Generator
>>> found on Samsung Exynos 5250+ SoCs.
>>>
>>>
It was <2017-12-04 pon 14:13>, when Krzysztof Kozlowski wrote:
> On Mon, Dec 4, 2017 at 1:53 PM, Łukasz Stelmach
> wrote:
>> Add binding documentation for the True Random Number Generator
>> found on Samsung Exynos 5250+ SoCs.
>>
>> Signed-off-by: Łukasz Stelmach
>> ---
>> .../devicetree/bindin
50 matches
Mail list logo