From 6f64f77557967a41ef7df429f0a831787bb8418f Mon Sep 17 00:00:00 2001 From: Troels Nilsson Date: Wed, 11 Sep 2024 09:12:49 +0200 Subject: [PATCH] Bluetooth: Controller: Remove incorrect check of RFU bit RFU bits has to be ignored according to the spec; In addition, some MediaTek devices seems to have it set (by mistake I assume), so having the check means we cannot sync to these devices Signed-off-by: Troels Nilsson --- subsys/bluetooth/controller/ll_sw/ull_scan_aux.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/subsys/bluetooth/controller/ll_sw/ull_scan_aux.c b/subsys/bluetooth/controller/ll_sw/ull_scan_aux.c index 5990f6091e9..93a826506cd 100644 --- a/subsys/bluetooth/controller/ll_sw/ull_scan_aux.c +++ b/subsys/bluetooth/controller/ll_sw/ull_scan_aux.c @@ -361,13 +361,12 @@ void ull_scan_aux_setup(memq_link_t *link, struct node_rx_pdu *rx) h = (void *)p->ext_hdr_adv_data; - /* Regard PDU as invalid if a RFU field is set, we do not know the - * size of this future field, hence will cause incorrect calculation of - * offset to ACAD field. + /* Note: The extended header contains a RFU flag that could potentially cause incorrect + * calculation of offset to ACAD field if it gets used to add a new header field; However, + * from discussion in BT errata ES-8080 it seems clear that BT SIG is aware that the RFU + * bit can not be used to add a new field since existing implementations will not be able + * to calculate the start of ACAD in that case */ - if (h->rfu) { - goto ull_scan_aux_rx_flush; - } ptr = h->data;