[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20200127165646.19806-1-andrew.smirnov@gmail.com>
Date: Mon, 27 Jan 2020 08:56:37 -0800
From: Andrey Smirnov <andrew.smirnov@...il.com>
To: linux-crypto@...r.kernel.org
Cc: Andrey Smirnov <andrew.smirnov@...il.com>,
Chris Healy <cphealy@...il.com>,
Lucas Stach <l.stach@...gutronix.de>,
Horia Geantă <horia.geanta@....com>,
Herbert Xu <herbert@...dor.apana.org.au>,
Iuliana Prodan <iuliana.prodan@....com>,
linux-kernel@...r.kernel.org, linux-imx@....com
Subject: [PATCH v7 0/9] enable CAAM's HWRNG as default
Everyone:
This series is a continuation of original [discussion]. I don't know
if what's in the series is enough to use CAAMs HWRNG system wide, but
I am hoping that with enough iterations and feedback it will be.
Changes since [v1]:
- Original hw_random replaced with the one using output of TRNG directly
- SEC4 DRNG IP block exposed via crypto API
- Small fix regarding use of GFP_DMA added to the series
Chagnes since [v2]:
- msleep in polling loop to avoid wasting CPU cycles
- caam_trng_read() bails out early if 'wait' is set to 'false'
- fixed typo in ZII's name
Changes since [v3]:
- DRNG's .cra_name is now "stdrng"
- collected Reviewd-by tag from Lucas
- typo fixes in commit messages of the series
Changes since [v4]:
- Dropped "crypto: caam - RNG4 TRNG errata" and "crypto: caam -
enable prediction resistance in HRWNG" to limit the scope of the
series. Those two patches are not yet ready and can be submitted
separately later.
- Collected Tested-by from Chris
Changes since [v5]:
- Series is converted back to implementing HWRNG using a job ring
as per feedback from Horia.
Changes since [v6]:
- "crypto: caam - drop global context pointer and init_done"
changed to use devres group to allow freeing HWRNG resource
independently of the parent device lifecycle. Code to deal with
circular deallocation dependency is added as well
- Removed worker self-scheduling in "crypto: caam - simplify RNG
implementation". It didn't bring much value, but meant that
simple cleanup with just a call to flush_work() wasn't good
enough.
- Added a simple function with a FIXME item for MC firmware check in
"crypto: caam - enable prediction resistance in HRWNG"
- "crypto: caam - limit single JD RNG output to maximum of 16
bytes" now shrinks async FIFO size from 32K to 64 bytes, since
having a buffer that big doesn't seem to do any good given that
througput of TRNG
Feedback is welcome!
Thanks,
Andrey Smirnov
[discussion] https://patchwork.kernel.org/patch/9850669/
[v1] https://lore.kernel.org/lkml/20191029162916.26579-1-andrew.smirnov@gmail.com
[v2] https://lore.kernel.org/lkml/20191118153843.28136-1-andrew.smirnov@gmail.com
[v3] https://lore.kernel.org/lkml/20191120165341.32669-1-andrew.smirnov@gmail.com
[v4] https://lore.kernel.org/lkml/20191121155554.1227-1-andrew.smirnov@gmail.com
[v5] https://lore.kernel.org/lkml/20191203162357.21942-1-andrew.smirnov@gmail.com
[v6] https://lore.kernel.org/lkml/20200108154047.12526-1-andrew.smirnov@gmail.com
Andrey Smirnov (9):
crypto: caam - allocate RNG instantiation descriptor with GFP_DMA
crypto: caam - use struct hwrng's .init for initialization
crypto: caam - use devm_kzalloc to allocate JR data
crypto: caam - drop global context pointer and init_done
crypto: caam - simplify RNG implementation
crypto: caam - check if RNG job failed
crypto: caam - invalidate entropy register during RNG initialization
crypto: caam - enable prediction resistance in HRWNG
crypto: caam - limit single JD RNG output to maximum of 16 bytes
drivers/crypto/caam/caamrng.c | 395 +++++++++++++---------------------
drivers/crypto/caam/ctrl.c | 56 +++--
drivers/crypto/caam/desc.h | 2 +
drivers/crypto/caam/intern.h | 7 +-
drivers/crypto/caam/jr.c | 13 +-
drivers/crypto/caam/regs.h | 7 +-
6 files changed, 209 insertions(+), 271 deletions(-)
--
2.21.0
Powered by blists - more mailing lists