michaelh/zephyr
1
0
Fork 0
Code Releases Activity

Bluetooth: Mesh: Warn if trying to send adv while suspended

Browse source 
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 <pavel.vasilyev@nordicsemi.no>
This commit is contained in:
Pavel Vasilyev 2024-02-01 23:04:30 +01:00 • committed by Fabio Baltieri
commit 9171ee24da
1 changed files with 4 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

4
subsys/bluetooth/mesh/adv.c
View file

@ -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;