No subject

"""
Since ADC was not designed to be a dedicated HW RNG, we do not want to bind=
 it to /dev/hwrng framework directly.
"""

> Where is the description of the RNG, where is the test implementation?=20
> >=20
> > Otherwise, your patch will cause high CPU load,  as continuously=20
> > read ADC data if entropy bits under write_wakeup_threshold.
>=20
> The issue is that although you may have analyzed it, others are unable=20
> to measure the quality of the RNG and assess the design as well as the=20
> implementation of the RNG. This RNG is the only implementation of a=20
> hardware RNG that per default and without being able to change it at=20
> runtime injects data into the input_pool where the noise source cannot=20
> be audited. Note, even other respected RNG noise sources like the=20
> Intel RDRAND will not feed into / dev/random per default in a way that do=
minates all other noise sources.
>=20
> I would like to be able to deactivate that noise source to the extent=20
> that it does not cause /dev/random to unblock. The reason is that your=20
> noise source starts to dominate all other noise sources.

I think the short-term problem here is the config logic:

config ATH9K_HWRNG
       bool "Random number generator support"
       depends on ATH9K && (HW_RANDOM =3D y || HW_RANDOM =3D ATH9K)
       default y

If you have *any* hwrngs you want to use and you have an ath9k card (HW_RAN=
DOM =3D y and ATH9K !=3D n), you get the behavior Stephan is pointing out.

Short term, we should just default no here.

> If you think that this patch is a challenge because your driver starts=20
> to spin, please help and offer another solution.

Well, I don't buy the reasoning listed above for not using the hwrng framew=
ork.  Interrupt timings were never designed to be a source of entropy eithe=
r.  We need to grab it where ever we can find it, especially on embedded sy=
stems.  Documentation/hw_random.txt even says:

"""
This data is NOT CHECKED by any fitness tests, and could potentially be bog=
us (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 u=
nder 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.

Is ath9k the only wireless card that exposes ADC registers?  What about sou=
nd cards?

thx,

Jason.