RFC : RNG support
Get series with b4
b4 am [email protected]Versions newest first
- v1 RFC Latest2 patches 7 repliesIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/2 | : Improve PLL initializationdrivers/ | +91 | 0 replies | |
| 2/2 | : Add support for using the random number generatordrivers/ | +65 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [RFC HIFN 00/02]: RNG support
These two patches add support for using the HIFN rng.
The first patch improves the PLL initialization a bit by making the reference clock configurable and its speed known to the driver, which is needed to calculate the amount of time to wait between two RNG reads. Since there is no way to find out the frequency reliably (especially for the external clock), it adds some sane looking defaults and a module parameter to override it. Suggestions how to improve this are welcome.
The second patch adds hw_random support. The ugly part is finding out when to allow reads from the RNG. It currently translates the public key engine clock cycles to CPU cycles based on a 4GHz CPU and uses get_cycles(). The problems with this are obvious, it only works on CPUs that actually have some kind of cycle counter, has problems with unsynchronized TSCs and the 4GHz assumption is not very nice either, but I was reluctant to use ktime for this since it seems rather expensive to call ktime_get once per 4 bytes of random. Suggestion for improvement of this are also welcome :)
Running rngtest on the random number generator indicates that it works properly, with an average failure ratio of about 1:1000 at ~2.5mbit.
drivers/crypto/hifn_795x.c | 158 +++++++++++++++++++++++++++++++++++++++++++- 1 files changed, 156 insertions(+), 2 deletions(-)
Patrick McHardy (2):
[HIFN]: Improve PLL initialization
[HIFN]: Add support for using the random number generator