Hi François,
We're definitely interested in implementing the whole driver interface, including the different forms of entropy collection. We're prioritizing cases that don't have a classic (mbedtls_xxx) API, since these open new possibilities: secure element drivers especially, and also acceleration for some algorithms that don't have an MBEDTLS_ALT_ interface. However, we'll be happy to add support for other features earlier if you can contribute the code.
On a practical note, patches are likely to conflict with the early work on driver wrapper generation since it's likely to move and refactor templates. The current step is https://github.com/ARMmbed/mbedtls/pull/5396 https://github.com/ARMmbed/mbedtls/pull/5396. This doesn't mean we need to wait, we just need to coordinate.
I see two plausible ways of getting started with an entropy driver: by implementing it for the PSA subsystem completely independently of the entropy module, or by adding a source to the mix in entropy.c. I'm fine with either approach. I do however insist on correctly handling the estimate_bits parameter, i.e. looping until the entropy estimate is large enough. Note that the existing code in entropy.c expects entropy sources to be full-entropy, e.g. 256 bits of output is supposed to give 256 bits of entropy, i.e. it expects that sources are fully conditioned. The PSA get_entropy entry point supports unconditioned sources.
Best regards,