I'll have to compile up the 4.4.35 kernel now!|
I have not done much so far, under normal circumstances I don't expect to see any performance increase. It would most sensibly be used to simply seed the random number generator, rather than use it directly. If however someone needed lots of random numbers quickly then this is a good option, but they are almost certainly writing code and hence have no problem accessing the device file directly and in that use case it would be well worth the effort.
One obvious place where lots random numbers are used in with SSL for HTTPS and it was something I intended to explore. Apache for example can specify an SSLCryptoDevice which potentially could be mapped onto the hardware random number generator. This would free up some processing to service web requests so making the maximum number of SSL requests performantly supportable higher. However there is probably a bigger performance kick from ensuring the hardware ciphers are preferred. Something else I'll have a look at.
Java is another example where it could easily be used and might again depending upon circumstance show a big performance jump. Java, in unix anyway, uses /dev/random, I have been bitten by this as it will block if there is insufficient entropy. The answer is easy though switch to /dev/urandom, which never does, however here we could use /dev/hwrnd for a performance increase. That said I doubt much java is running on a banana pi's!