drivers: entropy: ease runtime requirements on BT HCI

On platforms like nrf5340 there are 2 CPUs:
- one is the cpu_net which takes care of the radio stuff and
  owns the HW random generator
- one is the cpu_app which holds application data and polls
  cpu_net through HCI commands when it needs some random data.

The PSA core implemented in Mbed TLS needs random data at initialization
time, which happens early in the boot process. If we wait for BT to
be ready before issuing the HCI command, then PSA core intialization
will fail. In facts there is no need for the BT to be completely
initialized just to ask for some random data from the cpu_app to
the cpu_net since the HW random generator will likely be already
functional in the cpu_net.
So let's just try the HCI command and, if something is not right,
it will fail anyway. There's no need to anticipate the failure.

Signed-off-by: Valerio Setti <[email protected]>

drivers/entropy/entropy_bt_hci.c

@@ -20,9 +20,17 @@ static int entropy_bt_init(const struct device *dev)
 static int entropy_bt_get_entropy(const struct device *dev,
 				  uint8_t *buffer, uint16_t length)
 {
-	if (!bt_is_ready()) {
-		return -EAGAIN;
-	}
+	/* Do not wait for BT to be ready (i.e. bt_is_ready()) before issueing
+	 * the command. The reason is that when crypto is enabled and the PSA
+	 * Crypto API support is provided through Mbed TLS, random number generator
+	 * needs to be available since the very first call to psa_crypto_init()
+	 * which is usually done before BT is completely intialized.
+	 * On the other hand, in devices like the nrf5340, the crytographically
+	 * secure RNG is owned by the cpu_net, so the cpu_app needs to poll it
+	 * to get random data. Again, there is no need to wait for BT to be
+	 * completely initalized for this kind of support. Just try to send the
+	 * request through HCI. If the command fails for any reason, then
+	 * we return failure anyway. */
 
 	return bt_hci_le_rand(buffer, length);
 }