[riot-notifications] [RIOT-OS/RIOT] drivers/nrf24l01p: Netdev driver for nrf24l01p (#13743)

Marian Buschsieweke notifications at github.com
Mon May 4 16:28:37 CEST 2020

@maribu commented on this pull request.

> +    if (nrf24l01p_ng_acquire(dev) < 0) {
+        DEBUG("[nrf24l01p_ng] _init(): nrf24l01p_ng_acquire() failed\n");
+        return -EIO;
+    }
+    if (dev->state != NRF24L01P_NG_STATE_POWER_DOWN) {
+        nrf24l01p_ng_transition_to_power_down(dev);
+    }
+    nrf24l01p_ng_flush_tx(dev);
+    nrf24l01p_ng_flush_rx(dev);
+    uint8_t addr_size = NRF24L01P_NG_ADDR_WIDTH;
+    uint8_t pipes = 0;
+    uint8_t cnt = 1; /* counter assures that the LSB is different
+                        for all pipe addresses*/
+    uint8_t addr_p0[] = NRF24L01P_NG_L2ADDR_AUTO;
+    if (!memcmp(dev->params.urxaddr.rxaddrpx.rx_p0, addr_p0, addr_size)) {
+        luid_base(dev->params.urxaddr.rxaddrpx.rx_p0, addr_size);

This is actually a common pattern. E.g. when generating RSA keys you just call a cryptographic strength PRNG in a loop and test each output if it meets your requirements. Once the requirements are fulfilled, the "algorithm" terminates.

With only a single address not being valid (the broadcast address), the chances are pretty good that the first output of of `luid_get()` are fine. Modifying the output of `luid_get()` to bring the result in compliance is not allowed, as this could result in one of the subsequent callers of `luid_get()` obtaining the same ID again.

I honestly think there is no other way of doing this, unless relying on specific implementation details `luid_get()`.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20200504/21870378/attachment.htm>

More information about the notifications mailing list