Linux bluetooth development
 help / color / mirror / Atom feed
* [PATCH v3 0/4] Bluetooth: Advertising sets on a single-set controller
@ 2026-11-11 16:51 Weihong Guan
  2026-11-11 16:51 ` [PATCH v3 1/4] Bluetooth: hci_sync: Set random address on the set's handle Weihong Guan
                   ` (4 more replies)
  0 siblings, 5 replies; 7+ messages in thread
From: Weihong Guan @ 2026-11-11 16:51 UTC (permalink / raw)
  To: linux-bluetooth; +Cc: Marcel Holtmann, Luiz Augusto von Dentz, Weihong Guan

When the controller supports a single advertising set,
hci_add_adv_instance() gives instance 1 handle 0x00, the handle Global
Advertising uses too. The parameters, data and enable commands already
use adv->handle; these patches cover what still takes the instance
number for the handle: setting the set's random address, removing the
set, and the Advertising Set Terminated event (with a helper to free an
instance already found).

Changes in v3, addressing Luiz's review of v2's patch 3:

 - Patch 3 (new): hci_free_adv_instance() frees an instance already
   found; hci_remove_adv_instance() looks it up and calls it, so its
   other callers are unchanged.
 - Patch 4 (v2's patch 3): on an error, the instance found is freed
   with hci_free_adv_instance() rather than looked up again by
   hci_remove_adv_instance().
 - Shorter titles for patches 1 and 4 (GitLint).

Changes in v2, addressing the review at
https://sashiko.dev/#/patchset/20261023132421.1889022-1-weihong.guan%40gmail.com
(I hadn't seen it, sorry):

 - The instance is looked up, and adv->handle read, with hdev->lock held.
 - Patch 1: hci_cc_le_set_adv_set_random_addr() records the address of
   the instance numbered as the handle and leaves handle 0x00 alone, so
   instance 1's address on handle 0x00 went unrecorded. It is now
   recorded in hci_set_adv_set_random_addr_sync() when the instance and
   its handle differ.
 - Patch 2: hci_cc_le_remove_adv_set() looked up instance 0 for handle
   0x00 and left instance 1 in hdev->adv_instances. The completion can't
   tell instance 1 from instance 0, which MGMT's Set Advertising also
   removes on handle 0x00, so instance 1 is removed in
   hci_remove_ext_adv_instance_sync() once the command succeeds.
 - Patch 2: while Global Advertising is on it owns handle 0x00, and the
   controller would refuse to remove an enabled set, so only the instance
   is removed then.
 - Patch 3 (new; patch 4 in v3): the Advertising Set Terminated event
   finds the instance owning handle 0x00, the one enabled on it as
   hci_le_ext_adv_set_enabled() tracks, for the connection's responder
   address (which SMP checks), the instance re-enabled after the
   disconnection, and the removal on an error.

Tested again with v3 on a Raspberry Pi 5 (rpi-7.4.y, 7.4-rc2, with
net/bluetooth and include/net/bluetooth from bluetooth-next and these
patches) with a controller reporting one advertising set (LE Read
Number of Supported Advertising Sets = 1), btmgmt and btmon:

  - A non-connectable instance (a random address) starts: its address
    goes to handle 0x00 and the set advertises from it.
  - Removing it sends LE Remove Advertising Set for handle 0x00; the
    instance leaves the list (Read Advertising Features: none) and
    Advertising Removed goes out.
  - An instance with a timeout (btmgmt add-adv -t 2): the controller
    ends the set with Advertising Set Terminated, Advertising Timeout
    (0x3c), for handle 0x00; instance 1 is freed as found (patch 4), no
    LE Remove Advertising Set is sent, and Advertising Removed goes out
    for instance 1.
  - With Global Advertising on, removing instance 1 sends no LE Remove
    Advertising Set, the instance still leaves the list, and the set
    keeps advertising for Global Advertising.
  - A connectable instance from a random static address
    (force_static_address) on handle 0x00: Advertising Set Terminated
    for handle 0x00, LE Secure Connections pairing completes (DHKey
    Check both ways, so the responder address is the one advertised),
    and after the disconnection instance 1 advertises again.

Built with W=1; checkpatch clean but for the Assisted-by tag.

v2: https://lore.kernel.org/linux-bluetooth/20261111010940.728149-1-weihong.guan@gmail.com/
v1: https://lore.kernel.org/linux-bluetooth/20261023132421.1889022-1-weihong.guan@gmail.com/

Weihong Guan (4):
  Bluetooth: hci_sync: Set random address on the set's handle
  Bluetooth: hci_sync: Remove an advertising set by its handle
  Bluetooth: hci_core: Add hci_free_adv_instance()
  Bluetooth: hci_event: Find the owner of a terminated adv set

 include/net/bluetooth/hci_core.h |  1 +
 net/bluetooth/hci_core.c         | 24 +++++---
 net/bluetooth/hci_event.c        | 42 ++++++++++----
 net/bluetooth/hci_sync.c         | 94 +++++++++++++++++++++++++++++---
 4 files changed, 132 insertions(+), 29 deletions(-)


base-commit: def8a484b8883cd21d44a2a45702dcced9bf2627
-- 
2.47.3


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2026-11-11 20:20 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-11-11 16:51 [PATCH v3 0/4] Bluetooth: Advertising sets on a single-set controller Weihong Guan
2026-11-11 16:51 ` [PATCH v3 1/4] Bluetooth: hci_sync: Set random address on the set's handle Weihong Guan
2026-11-11 18:21   ` Bluetooth: Advertising sets on a single-set controller bluez.test.bot
2026-11-11 16:51 ` [PATCH v3 2/4] Bluetooth: hci_sync: Remove an advertising set by its handle Weihong Guan
2026-11-11 16:51 ` [PATCH v3 3/4] Bluetooth: hci_core: Add hci_free_adv_instance() Weihong Guan
2026-11-11 16:51 ` [PATCH v3 4/4] Bluetooth: hci_event: Find the owner of a terminated adv set Weihong Guan
2026-11-11 20:20 ` [PATCH v3 0/4] Bluetooth: Advertising sets on a single-set controller patchwork-bot+bluetooth

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox