From 9171ee24da8f0042c6f96cac21daeb283f29b521 Mon Sep 17 00:00:00 2001 From: Pavel Vasilyev Date: Thu, 1 Feb 2024 23:04:30 +0100 Subject: [PATCH] Bluetooth: Mesh: Warn if trying to send adv while suspended This will warn if any of the mesh module will try to send anything while the stack is suspended. Not clear what to do here as both advertisers (legacy and ext) behaves differently. The legacy advertiser has a thread which is stopped after the `bt_mesh_adv_disable` call and any sent advs after suspending the stack will stay in the pool until the advertiser is resumed. The extended advertiser will schedule its work, but then fail because `ext_adv->instance` value is NULL, but will call `bt_mesh_send_cb.start` with error `-ENODEV`. What to do with these 2 behaviors is unclear at the moment. Ideally none of the mesh stack modules should call `bt_mesh_adv_send` after the stack was suspended, so if this warning appears, the faulty module wasn't stopped properly and this should be fixed. If not to add the adv to the pool, then it kind of gets lost as the implementation probably expects one of `bt_mesh_send_cb` callbacks which will never be called. Leaving the warning until clear customer request comes. Signed-off-by: Pavel Vasilyev --- subsys/bluetooth/mesh/adv.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/subsys/bluetooth/mesh/adv.c b/subsys/bluetooth/mesh/adv.c index d51f0946b85..d9b191120d1 100644 --- a/subsys/bluetooth/mesh/adv.c +++ b/subsys/bluetooth/mesh/adv.c @@ -257,6 +257,10 @@ void bt_mesh_adv_send(struct bt_mesh_adv *adv, const struct bt_mesh_send_cb *cb, LOG_DBG("type 0x%02x len %u: %s", adv->ctx.type, adv->b.len, bt_hex(adv->b.data, adv->b.len)); + if (atomic_test_bit(bt_mesh.flags, BT_MESH_SUSPENDED)) { + LOG_WRN("Sending advertisement while suspended"); + } + adv->ctx.cb = cb; adv->ctx.cb_data = cb_data; adv->ctx.busy = 1U;