Hi Sasha,
the changes in hci_request.c look quite different from what I submitted for mainline (and also from the version for 6.6 LTS). Are you sure that everything went correctly?
regards, Christian
On Monday, 14 July 2025, 19:37:07 CEST, Sasha Levin wrote:
This is a note to let you know that I've just added the patch titled
Bluetooth: HCI: Set extended advertising data synchronously
to the 5.10-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git%3Ba=su...
The filename of the patch is: bluetooth-hci-set-extended-advertising-data-synchron.patch and it can be found in the queue-5.10 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree, please let stable@vger.kernel.org know about it.
commit 8766e406adb9b3c4bd8c0506a71bbbf99a43906d Author: Christian Eggers ceggers@arri.de Date: Sat Jul 12 02:08:03 2025 -0400
Bluetooth: HCI: Set extended advertising data synchronously
[ Upstream commit 89fb8acc38852116d38d721ad394aad7f2871670 ] Currently, for controllers with extended advertising, the advertising data is set in the asynchronous response handler for extended adverstising params. As most advertising settings are performed in a synchronous context, the (asynchronous) setting of the advertising data is done too late (after enabling the advertising). Move setting of adverstising data from asynchronous response handler into synchronous context to fix ordering of HCI commands. Signed-off-by: Christian Eggers ceggers@arri.de Fixes: a0fb3726ba55 ("Bluetooth: Use Set ext adv/scan rsp data if controller supports") Cc: stable@vger.kernel.org v2: https://lore.kernel.org/linux-bluetooth/20250626115209.17839-1-ceggers@arri.... Signed-off-by: Luiz Augusto von Dentz luiz.von.dentz@intel.com Signed-off-by: Sasha Levin sashal@kernel.org
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c index 7f26c1aab9a06..2cc4aaba09abe 100644 --- a/net/bluetooth/hci_event.c +++ b/net/bluetooth/hci_event.c @@ -1726,36 +1726,6 @@ static void hci_cc_set_adv_param(struct hci_dev *hdev, struct sk_buff *skb) hci_dev_unlock(hdev); } -static void hci_cc_set_ext_adv_param(struct hci_dev *hdev, struct sk_buff *skb) -{
- struct hci_rp_le_set_ext_adv_params *rp = (void *) skb->data;
- struct hci_cp_le_set_ext_adv_params *cp;
- struct adv_info *adv_instance;
- BT_DBG("%s status 0x%2.2x", hdev->name, rp->status);
- if (rp->status)
return;
- cp = hci_sent_cmd_data(hdev, HCI_OP_LE_SET_EXT_ADV_PARAMS);
- if (!cp)
return;
- hci_dev_lock(hdev);
- hdev->adv_addr_type = cp->own_addr_type;
- if (!hdev->cur_adv_instance) {
/* Store in hdev for instance 0 */
hdev->adv_tx_power = rp->tx_power;
- } else {
adv_instance = hci_find_adv_instance(hdev,
hdev->cur_adv_instance);
if (adv_instance)
adv_instance->tx_power = rp->tx_power;
- }
- /* Update adv data as tx power is known now */
- hci_req_update_adv_data(hdev, hdev->cur_adv_instance);
- hci_dev_unlock(hdev);
-} static void hci_cc_read_rssi(struct hci_dev *hdev, struct sk_buff *skb) { @@ -3601,9 +3571,6 @@ static void hci_cmd_complete_evt(struct hci_dev *hdev, struct sk_buff *skb, hci_cc_le_read_num_adv_sets(hdev, skb); break;
- case HCI_OP_LE_SET_EXT_ADV_PARAMS:
hci_cc_set_ext_adv_param(hdev, skb);
break;
case HCI_OP_LE_SET_EXT_ADV_ENABLE: hci_cc_le_set_ext_adv_enable(hdev, skb); diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c index 7ce6db1ac558a..743ba58941f8b 100644 --- a/net/bluetooth/hci_request.c +++ b/net/bluetooth/hci_request.c @@ -2179,6 +2179,9 @@ int __hci_req_setup_ext_adv_instance(struct hci_request *req, u8 instance) hci_req_add(req, HCI_OP_LE_SET_EXT_ADV_PARAMS, sizeof(cp), &cp);
- /* Update adv data after setting ext adv params */
- __hci_req_update_adv_data(req, instance);
- if (own_addr_type == ADDR_LE_DEV_RANDOM && bacmp(&random_addr, BDADDR_ANY)) { struct hci_cp_le_set_adv_set_rand_addr cp;
On Mon, Jul 14, 2025 at 08:14:56PM +0200, Christian Eggers wrote:
Hi Sasha,
the changes in hci_request.c look quite different from what I submitted for mainline (and also from the version for 6.6 LTS). Are you sure that everything went correctly?
Yeah, this looks really wrong, I'll go drop it from the 5.10 queue if for no other reason than it's not included for 6.1.y and 5.15.y, and we can't have that.
thanks,
greg k-h
linux-stable-mirror@lists.linaro.org