HW RNG cleanup & new drivers
Get series with b4
b4 am 20051029191229.562454000@omelasVersions newest first
- v1 Latest5 patches 12 repliesIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/5 | Remove existing hw_random implementationdrivers/ drivers/ drivers/ | +0 | 0 replies | |
| 2/5 | Core HW RNG supportdrivers/ drivers/ drivers/ +3 more | +222 | 1 reply | |
| 3/5 | Intel IXP4xx driverdrivers/ include/ | +68 | 0 replies | |
| 4/5 | x86 driverdrivers/ | +528 | 0 replies | |
| 5/5 | TI OMAP driverdrivers/ | +209 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [patch 0/5] HW RNG cleanup & new drivers
This patch adds support to the kernel for some more HW RNG devices and cleans up the code a bit. My basic goal was to keep the same user space interface as exists, but not have to reproduce all the same 100 lines of user space interface code across every new driver (as we currently do with watchdogs...)
The new code separates the HW specific driver from the user interface code and just adds a few function pointers so that the two can talk to each other. I opted out of using a sysfs class and all that complication b/c there will be one and only one RNG device at a time on a given system.
I've added drivers for Intels' IXP4xx and for the TI OMAP and these have both been tested.
There was some discussion on lkml on the subject of killing the in-kernel driver and moving the whole implementation to user space but that cannot be done as some SOCs (MPC85xx for example) have the RNG unit as part of a larger device that needs kernel space code to manage command descriptor rings and other such things. We also want to be able to suspend/resume the RNG devices (see OMAP driver) and that needs to be done as part of the kernel PM path.
Please apply,
~Deepak
--
Deepak Saxena - [email protected] - http://www.plexity.net
Even a stopped clock gives the right time twice a day.