Skip to contentSkip to conversation

omap_rng minor updates

PATCH In review David Brownell 2 participants 4 messages Apr 11, 2008 – Apr 17, 2008

Subsystems (2)
Hardware random number generator core OMAP random number generator support
lore
Share & tools
lore

David Brownell

author
#0 lore raw

PATCH 1/1 omap_rng minor updates

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 <[email protected]>
---
 drivers/char/hw_random/omap-rng.c |   26 +++++++++++++-------------
 1 files changed, 13 insertions(+), 13 deletions(-)
drivers/char/hw_random/omap-rng.c +13 -13
@@ -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 <[email protected]>
  *

@@ -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)
 			break;
+		/* RNG produces data fast enough (2+ MBit/sec, even
+		 * during "rngtest" loads, that these delays don't
+		 * seem to trigger.  We *could* use the RNG IRQ, but
+		 * that'd be higher overhead ... so why bother?
+		 */
 		udelay(10);
 	}
 	return data;

@@ -101,7 +98,8 @@ static int __init omap_rng_probe(struct 
 	 * A bit ugly, and it will never actually happen but there can
 	 * be only one RNG and this catches any bork
 	 */
-	BUG_ON(rng_dev);
+	if (rng_dev)
+		return -EBUSY;
 
 	if (cpu_is_omap24xx()) {
 		rng_ick = clk_get(NULL, "rng_ick");

@@ -124,7 +122,7 @@ static int __init omap_rng_probe(struct 
 		return -EBUSY;
 
 	dev_set_drvdata(&pdev->dev, mem);
-	rng_base = (u32 __iomem *)io_p2v(res->start);
+	rng_base = (u32 __force __iomem *)io_p2v(res->start);
 
 	ret = hwrng_register(&omap_rng_ops);
 	if (ret) {

@@ -182,6 +180,8 @@ static int omap_rng_resume(struct platfo
 
 #endif
 
+/* work with hotplug and coldplug */
+MODULE_ALIAS("platform:omap_rng");
 
 static struct platform_driver omap_rng_driver = {
 	.driver = {
maintainer
#1 lore raw
Quoted 1 line · David Brownell

Minor cleanups to the OMAP RNG:

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

Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
author
#2 lore raw
Quoted 3 lines · Herbert Xu
Quoted 1 line

Minor cleanups to the OMAP RNG:

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

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

maintainer
#3 lore raw
Quoted 2 lines · David Brownell

Is that where the RNG stuff is now getting maintained?

For hardware RNG stuff yes. For the software RNG you should send them to Matt Mackall as usual.

Thanks,

Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt