At least eight bytes of this number are totally unique for the device
it seems, so this is a perfect candidate for feeding the entropy
pool. One byte more or less of constants does not matter so feed in
the entire OID struct.
This fixes the issue of similar devices initializing to the
same state initially.
Further registers could be added too, such as OMAP4
CONTROL_STD_FUSE_OPP* and CONTROL_DPLL_NWELL_TRIM* registers,
but those vary based on the SoC generation.
Cc: Theodore Ts'o <tytso@mit.edu>
Cc: Paul Walmsley <paul@pwsan.com>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Reviewed-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
[tony@atomide.com: updated comments per mailing list discussion]
Signed-off-by: Tony Lindgren <tony@atomide.com>
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/io.h>
+#include <linux/random.h>
#include <linux/slab.h>
#ifdef CONFIG_SOC_BUS
odi->id_3 = read_tap_reg(OMAP_TAP_DIE_ID_3);
}
+static int __init omap_feed_randpool(void)
+{
+ struct omap_die_id odi;
+
+ /* Throw the die ID into the entropy pool at boot */
+ omap_get_die_id(&odi);
+ add_device_randomness(&odi, sizeof(odi));
+ return 0;
+}
+omap_device_initcall(omap_feed_randpool);
+
void __init omap2xxx_check_revision(void)
{
int i, j;