Minor cleanups to the OMAP RNG:
 - Comment update re RNG status:

     * yes, it works on 16xx; "rngtest" is quite happy

     * it's fast enough that polling vs IRQ is a non-issue

 - Get rid of BUG_ON

 - Help GCC not be stupid about inlining (object code shrink)

 - Remove "sparse" warning

 - Cope with new hotplug rule requiring "platform:" modalias
And make the file header match kernel conventions.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>

---

 drivers/char/hw_random/omap-rng.c |   26 +++++++++++++-------------

 1 files changed, 13 insertions(+), 13 deletions(-)
--- osk2.orig/drivers/char/hw_random/omap-rng.c	2008-04-10 20:23:31.000000000 -0700

+++ osk2/drivers/char/hw_random/omap-rng.c	2008-04-10 20:38:49.000000000 -0700

@@ -1,7 +1,5 @@

 /*

- * drivers/char/hw_random/omap-rng.c

- *

- * RNG driver for TI OMAP CPU family

+ * omap-rng.c - RNG driver for TI OMAP CPU family

  *

  * Author: Deepak Saxena <dsaxena@plexity.net>

  *

@@ -15,11 +13,6 @@

  * This file is licensed under  the terms of the GNU General Public

  * License version 2. This program is licensed "as is" without any

  * warranty of any kind, whether express or implied.

- *

- * TODO:

- *

- * - Make status updated be interrupt driven so we don't poll

- *

  */
 #include <linux/module.h>

@@ -55,17 +48,16 @@ static void __iomem *rng_base;

 static struct clk *rng_ick;

 static struct platform_device *rng_dev;
-static u32 omap_rng_read_reg(int reg)

+static inline u32 omap_rng_read_reg(int reg)

 {

 	return __raw_readl(rng_base + reg);

 }
-static void omap_rng_write_reg(int reg, u32 val)

+static inline void omap_rng_write_reg(int reg, u32 val)

 {

 	__raw_writel(val, rng_base + reg);

 }
-/* REVISIT: Does the status bit really work on 16xx? */

 static int omap_rng_data_present(struct hwrng *rng, int wait)

 {

 	int data, i;

@@ -74,6 +66,11 @@ static int omap_rng_data_present(struct

 		data = omap_rng_read_reg(RNG_STAT_REG) ? 0 : 1;

 		if (data || !wait...
[ message continues ]

Thanks.  I've picked this up in cryptodev-2.6.

--

Visit Openswan at http://www.openswan.org/

Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>

Home Page: http://gondor.apana.org.au/~herbert/

PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

--

Is that where the RNG stuff is now getting maintained?
If so, I wonder what should be done with some other

RNG changes sitting in one of my trees.  Briefly,

their initializations come late ... and after kernel

code has already started to use the kernel pool.  So

attacks based on known RNG patterns are possible at

that time.
So the patch I had -- needs reworking -- moves the

RNG driver initializations earlier, and uses the

first one to seed the kernel pool.  Cryptographically

that would be no worse than the current situation (even

if you don't wholly trust the RNG), and in most cases

would be a distinct improvement.
- Dave
--

For hardware RNG stuff yes.  For the software RNG you should

send them to Matt Mackall as usual.
Thanks,

--

Visit Openswan at http://www.openswan.org/

Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>

Home Page: http://gondor.apana.org.au/~herbert/

PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

--