Skip to content
Browse files

bluetooth: controller: Mayfly yield after call under Kconfig

Added Kconfig BT_MAYFLY_YIELD_AFTER_CALL to support vendor requirement
of invoking all outstanding mayflies for a given callee in

Signed-off-by: Morten Priess <>
  • Loading branch information...
mtpr-ot authored and aescolar committed Apr 29, 2019
1 parent d533dde commit c741ef6efd0afe64387a116d73ea301c9a785b09
Showing with 20 additions and 0 deletions.
  1. +8 −0 subsys/bluetooth/controller/Kconfig
  2. +12 −0 subsys/bluetooth/controller/util/mayfly.c
@@ -733,4 +733,12 @@ config BT_CTLR_DEBUG_PINS
when debugging with a logic analyzer or profiling certain sections of
the code.

bool "Yield from mayfly thread after first call"
default y
Only process one mayfly callback per invocation (legacy behavior).
If set to 'n', all pending mayflies for callee are executed before

endif # BT_CTLR
@@ -215,6 +215,17 @@ void mayfly_run(u8_t callee_id)
(void **)&m);

* When using cooperative thread implementation, an issue has been seen where
* pended mayflies are never executed in certain scenarios.
* This happens when mayflies with higher caller_id are constantly pended, in
* which case lower value caller ids never get to be executed.
* By allowing complete traversal of mayfly queues for all caller_ids, this
* does not happen, however this means that more than one mayfly function is
* potentially executed in a mayfly_run(), with added execution time as
* consequence.
/* yield out of mayfly_run if a mayfly function was
* called.
@@ -229,6 +240,7 @@ void mayfly_run(u8_t callee_id)

if (mft[callee_id][caller_id].disable_req !=

0 comments on commit c741ef6

Please sign in to comment.
You can’t perform that action at this time.