Note that at the moment, we are covered in 4.4 and 4.14 through Chrome OS specific patches, and the fix is required for further kernels with tpm+hwrng code that comes directly from upstream.

In 4.4 we have it covered via trd->rng.quality = 1000 in drivers/char/hw_random/tpm-rng.c. And it should stay this way for 4.4 kernel, since picking up upstream changes that allow tpm drivers to specify the quality themselves is not planned for 4.4.

In 4.14 it currently comes from chip->hwrng.quality = 1000 in drivers/char/tpm/tpm-chip.c, which is set by https://crrev.com/c/967183. If that CL is reverted, we still have it covered for cr50: in cr50_spi and cr50_i2c we use the new ability to set the quality in tpm drivers.

For future kernels, we will rely on tpm drivers setting the quality value, so have it covered only for cr50 for now.

Alternative change (without new module parameter) sent upstream for discussion:

https://patchwork.kernel.org/patch/10615183/

I like the solution proposed in #4. Can we take that and revert our private patches ?

I am happy to do that, Andrey any thoughts?

Also - perhaps worth waiting another week or so to see if it gets accepted upstream?

It doesn't hurt to wait. Instead of jumping from one solution to another, let's just wait for upstream.

No updates on the upstream patch, Guenter any advice on how best to nudge that forwards?

Looks like you did not send the original patch to the hwrng maintainers. I would suggest to resend the patch. Mark is as "RESEND", add the Ack, and make sure it is sent to everyone who might be interested. I would have hoped to see some comment / feedback / ack from Andrey, though.