Bluetooth: host: remove TX thread

We don't need the TX thread anymore.

Generalizing the pull-based architecture (ie. `tx_processor`) to HCI
commands makes it possible to run the whole TX path from the the system
workqueue, or any workqueue really.

There is an edge-case, where we call `bt_hci_cmd_send_sync()` from the
syswq, stalling the system. The proposed mitigation is to attempt to drain
the command queue from within `bt_hci_cmd_send_sync()`.

My spidey sense tingles however, and it would be better to just remove the
capability of calling this fn from the syswq. But doing this requires
refactoring a bunch of synchronous procedures in the stack (e.g. stack
init, connection establishment, address setting etc), dragging in more
work. I will do it, but in a later patch.

Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
This commit is contained in:
Jonathan Rico 2023-08-01 13:25:13 +02:00 committed by Alberto Escolar
commit 28be8909a6
6 changed files with 113 additions and 100 deletions

View file

@ -32,8 +32,8 @@ static atomic_t nwrites;
static atomic_t indications;
static atomic_t notifications;
/* Defined in hci_core.c */
extern k_tid_t bt_testing_tx_tid_get(void);
/* Defined in conn.c */
extern void bt_conn_suspend_tx(bool suspend);
static struct bt_conn *dconn;
@ -159,7 +159,7 @@ static ssize_t written_to(struct bt_conn *conn,
if (atomic_get(&nwrites) == 0) {
/* Suspend on the first write, which is an ATT Request */
LOG_INF("suspending HCI TX thread");
k_thread_suspend(bt_testing_tx_tid_get());
bt_conn_suspend_tx(true);
}
atomic_inc(&nwrites);
@ -311,7 +311,7 @@ void test_procedure_0(void)
WAIT_FOR_VAL(nwrites, 3);
/* Send RSP to LL */
k_thread_resume(bt_testing_tx_tid_get());
bt_conn_suspend_tx(false);
PASS("DUT done\n");
}