Hi Stephan, On Mon, Aug 08, 2016 at 05:29:30PM +0000, Jason Cooper wrote: > On Mon, Aug 08, 2016 at 08:41:36AM +0200, Stephan Mueller wrote: ... > > If you think that this patch is a challenge because your driver starts to > > spin, please help and offer another solution. > > Well, I don't buy the reasoning listed above for not using the hwrng > framework. Interrupt timings were never designed to be a source of entropy > either. We need to grab it where ever we can find it, especially on > embedded systems. Documentation/hw_random.txt even says: > > """ > This data is NOT CHECKED by any fitness tests, and could potentially be > bogus (if the hardware is faulty or has been tampered with). > """ > > I really don't think there's a problem with adding these sorts of > sources under char/hw_random/. I think the only thing we would be > concerned about, other than the already addressed entropy estimation, > would be constraining the data rate. Further research yields char/hw_random/timeriomem-rng.c It could use an update to ->read() vice data_{present,read}(), but it's functionally exactly what the ath9k rng is doing. :) thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html