* [PATCH v2 6/8] Bluetooth: hci_sync: Add NVMEM-backed BD address retrieval
From: Loic Poulain @ 2026-05-07 15:24 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Jens Axboe, Johannes Berg,
Jeff Johnson, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Srinivas Kandagatla, Andrew Lunn, Heiner Kallweit,
Russell King, Saravana Kannan
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-msm, linux-block,
linux-wireless, ath10k, linux-bluetooth, netdev, daniel,
Loic Poulain
In-Reply-To: <20260507-block-as-nvmem-v2-0-bf17edd5134e@oss.qualcomm.com>
Some devices store the Bluetooth BD address in non-volatile
memory, which can be accessed through the NVMEM framework.
Similar to Ethernet or WiFi MAC addresses, add support for
reading the BD address from a 'local-bd-address' NVMEM cell.
As with the device-tree provided BD address, add a quirk to
indicate whether a device or platform should attempt to read
the address from NVMEM when no valid in-chip address is present.
Also add a quirk to indicate if the address is stored in
big-endian byte order.
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
---
include/net/bluetooth/hci.h | 18 ++++++++++++++++++
net/bluetooth/hci_sync.c | 39 ++++++++++++++++++++++++++++++++++++++-
2 files changed, 56 insertions(+), 1 deletion(-)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index 572b1c620c5d653a1fe10b26c1b0ba33e8f4968f..7686466d1109253b0d75edeb5f6a99fb98ce4cc6 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -164,6 +164,24 @@ enum {
*/
HCI_QUIRK_BDADDR_PROPERTY_BROKEN,
+ /* When this quirk is set, the public Bluetooth address
+ * initially reported by HCI Read BD Address command
+ * is considered invalid. The public BD Address can be
+ * retrieved via a 'local-bd-address' NVMEM cell.
+ *
+ * This quirk can be set before hci_register_dev is called or
+ * during the hdev->setup vendor callback.
+ */
+ HCI_QUIRK_USE_BDADDR_NVMEM,
+
+ /* When this quirk is set, the Bluetooth Device Address provided by
+ * the 'local-bd-address' NVMEM is stored in big-endian order.
+ *
+ * This quirk can be set before hci_register_dev is called or
+ * during the hdev->setup vendor callback.
+ */
+ HCI_QUIRK_BDADDR_NVMEM_BE,
+
/* When this quirk is set, the duplicate filtering during
* scanning is based on Bluetooth devices addresses. To allow
* RSSI based updates, restart scanning if needed.
diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
index fd3aacdea512a37c22b9a2be90c89ddca4b4d99f..589ccdfa26c1281d6eb979370523fff0d7920302 100644
--- a/net/bluetooth/hci_sync.c
+++ b/net/bluetooth/hci_sync.c
@@ -7,6 +7,7 @@
*/
#include <linux/property.h>
+#include <linux/of_net.h>
#include <net/bluetooth/bluetooth.h>
#include <net/bluetooth/hci_core.h>
@@ -3588,6 +3589,37 @@ int hci_powered_update_sync(struct hci_dev *hdev)
return 0;
}
+/**
+ * hci_dev_get_bd_addr_from_nvmem - Get the Bluetooth Device Address
+ * (BD_ADDR) for a HCI device from
+ * an NVMEM cell.
+ * @hdev: The HCI device
+ *
+ * Search for 'local-bd-address' NVMEM cell in the device firmware node.
+ *
+ * All-zero BD addresses are rejected (unprovisioned).
+ */
+static int hci_dev_get_bd_addr_from_nvmem(struct hci_dev *hdev)
+{
+ struct device_node *np = dev_of_node(hdev->dev.parent);
+ u8 ba[sizeof(bdaddr_t)];
+ int err;
+
+ if (!np)
+ return -ENODEV;
+
+ err = of_get_nvmem_eui48(np, "local-bd-address", ba);
+ if (err)
+ return err;
+
+ if (hci_test_quirk(hdev, HCI_QUIRK_BDADDR_NVMEM_BE))
+ baswap(&hdev->public_addr, (bdaddr_t *)ba);
+ else
+ bacpy(&hdev->public_addr, (bdaddr_t *)ba);
+
+ return 0;
+}
+
/**
* hci_dev_get_bd_addr_from_property - Get the Bluetooth Device Address
* (BD_ADDR) for a HCI device from
@@ -5042,12 +5074,17 @@ static int hci_dev_setup_sync(struct hci_dev *hdev)
* its setup callback.
*/
invalid_bdaddr = hci_test_quirk(hdev, HCI_QUIRK_INVALID_BDADDR) ||
- hci_test_quirk(hdev, HCI_QUIRK_USE_BDADDR_PROPERTY);
+ hci_test_quirk(hdev, HCI_QUIRK_USE_BDADDR_PROPERTY) ||
+ hci_test_quirk(hdev, HCI_QUIRK_USE_BDADDR_NVMEM);
if (!ret) {
if (hci_test_quirk(hdev, HCI_QUIRK_USE_BDADDR_PROPERTY) &&
!bacmp(&hdev->public_addr, BDADDR_ANY))
hci_dev_get_bd_addr_from_property(hdev);
+ if (hci_test_quirk(hdev, HCI_QUIRK_USE_BDADDR_NVMEM) &&
+ !bacmp(&hdev->public_addr, BDADDR_ANY))
+ hci_dev_get_bd_addr_from_nvmem(hdev);
+
if (invalid_bdaddr && bacmp(&hdev->public_addr, BDADDR_ANY) &&
hdev->set_bdaddr) {
ret = hdev->set_bdaddr(hdev, &hdev->public_addr);
--
2.34.1
^ permalink raw reply related
* [PATCH v2 5/8] net: of_net: Add of_get_nvmem_eui48() helper for EUI-48 lookup
From: Loic Poulain @ 2026-05-07 15:24 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Jens Axboe, Johannes Berg,
Jeff Johnson, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Srinivas Kandagatla, Andrew Lunn, Heiner Kallweit,
Russell King, Saravana Kannan
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-msm, linux-block,
linux-wireless, ath10k, linux-bluetooth, netdev, daniel,
Loic Poulain
In-Reply-To: <20260507-block-as-nvmem-v2-0-bf17edd5134e@oss.qualcomm.com>
Factor out the common NVMEM EUI-48 retrieval logic from
of_get_mac_address_nvmem() into a new of_get_nvmem_eui48() helper that
accepts the NVMEM cell name as a parameter. This allows other subsystems
(e.g. Bluetooth) to reuse the same lookup-validate-copy pattern with a
different cell name, without duplicating code.
of_get_mac_address_nvmem() is updated to call of_get_nvmem_eui48() with
"mac-address", preserving its existing behavior.
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
---
include/linux/of_net.h | 7 +++++++
net/core/of_net.c | 47 +++++++++++++++++++++++++++++++++++------------
2 files changed, 42 insertions(+), 12 deletions(-)
diff --git a/include/linux/of_net.h b/include/linux/of_net.h
index d88715a0b3a52f87af23d47791bea3baf5be5200..7854ba555d9a55f3d020a37fe00a27ae52e0e5dc 100644
--- a/include/linux/of_net.h
+++ b/include/linux/of_net.h
@@ -15,6 +15,7 @@ struct net_device;
extern int of_get_phy_mode(struct device_node *np, phy_interface_t *interface);
extern int of_get_mac_address(struct device_node *np, u8 *mac);
extern int of_get_mac_address_nvmem(struct device_node *np, u8 *mac);
+int of_get_nvmem_eui48(struct device_node *np, const char *cell_name, u8 *addr);
int of_get_ethdev_address(struct device_node *np, struct net_device *dev);
extern struct net_device *of_find_net_device_by_node(struct device_node *np);
#else
@@ -34,6 +35,12 @@ static inline int of_get_mac_address_nvmem(struct device_node *np, u8 *mac)
return -ENODEV;
}
+static inline int of_get_nvmem_eui48(struct device_node *np,
+ const char *cell_name, u8 *addr)
+{
+ return -ENODEV;
+}
+
static inline int of_get_ethdev_address(struct device_node *np, struct net_device *dev)
{
return -ENODEV;
diff --git a/net/core/of_net.c b/net/core/of_net.c
index 93ea425b9248a23f4f95a336e9cdbf0053248e32..79b289de0f16aa5f8724e84d6f2300648c25b6c4 100644
--- a/net/core/of_net.c
+++ b/net/core/of_net.c
@@ -61,9 +61,6 @@ static int of_get_mac_addr(struct device_node *np, const char *name, u8 *addr)
int of_get_mac_address_nvmem(struct device_node *np, u8 *addr)
{
struct platform_device *pdev = of_find_device_by_node(np);
- struct nvmem_cell *cell;
- const void *mac;
- size_t len;
int ret;
/* Try lookup by device first, there might be a nvmem_cell_lookup
@@ -75,27 +72,53 @@ int of_get_mac_address_nvmem(struct device_node *np, u8 *addr)
return ret;
}
- cell = of_nvmem_cell_get(np, "mac-address");
+ ret = of_get_nvmem_eui48(np, "mac-address", addr);
+ if (ret)
+ return ret;
+
+ if (!is_valid_ether_addr(addr))
+ return -EINVAL;
+
+ return 0;
+}
+EXPORT_SYMBOL(of_get_mac_address_nvmem);
+
+/**
+ * of_get_nvmem_eui48 - Read a 6-byte EUI-48 address from a named NVMEM cell.
+ * @np: Device node to look up the NVMEM cell from.
+ * @cell_name: Name of the NVMEM cell (e.g. "mac-address", "local-bd-address").
+ * @addr: Output buffer for the 6-byte address.
+ *
+ * Reads the named NVMEM cell and validates that it contains a non-zero 6-byte
+ * address. Returns 0 on success, negative errno on failure.
+ */
+int of_get_nvmem_eui48(struct device_node *np, const char *cell_name, u8 *addr)
+{
+ struct nvmem_cell *cell;
+ const void *eui48;
+ size_t len;
+
+ cell = of_nvmem_cell_get(np, cell_name);
if (IS_ERR(cell))
return PTR_ERR(cell);
- mac = nvmem_cell_read(cell, &len);
+ eui48 = nvmem_cell_read(cell, &len);
nvmem_cell_put(cell);
- if (IS_ERR(mac))
- return PTR_ERR(mac);
+ if (IS_ERR(eui48))
+ return PTR_ERR(eui48);
- if (len != ETH_ALEN || !is_valid_ether_addr(mac)) {
- kfree(mac);
+ if (len != ETH_ALEN || !memchr_inv(eui48, 0, ETH_ALEN)) {
+ kfree(eui48);
return -EINVAL;
}
- memcpy(addr, mac, ETH_ALEN);
- kfree(mac);
+ memcpy(addr, eui48, ETH_ALEN);
+ kfree(eui48);
return 0;
}
-EXPORT_SYMBOL(of_get_mac_address_nvmem);
+EXPORT_SYMBOL_GPL(of_get_nvmem_eui48);
/**
* of_get_mac_address()
--
2.34.1
^ permalink raw reply related
* [PATCH v2 4/8] block: implement NVMEM provider
From: Loic Poulain @ 2026-05-07 15:24 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Jens Axboe, Johannes Berg,
Jeff Johnson, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Srinivas Kandagatla, Andrew Lunn, Heiner Kallweit,
Russell King, Saravana Kannan
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-msm, linux-block,
linux-wireless, ath10k, linux-bluetooth, netdev, daniel,
Loic Poulain
In-Reply-To: <20260507-block-as-nvmem-v2-0-bf17edd5134e@oss.qualcomm.com>
From: Daniel Golle <daniel@makrotopia.org>
On embedded devices using an eMMC it is common that one or more partitions
on the eMMC are used to store MAC addresses and Wi-Fi calibration EEPROM
data. Allow referencing the partition in device tree for the kernel and
Wi-Fi drivers accessing it via the NVMEM layer.
To safely defer the freeing of the provider private data until all
consumers have released their cells, a nvmem_dev() accessor is added to
the NVMEM core to expose the struct device embedded in struct nvmem_device.
This allows registering a devm action on the nvmem device itself, ensuring
the private data outlives any active cell references.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Co-developed-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
---
block/Kconfig | 9 ++
block/Makefile | 1 +
block/blk-nvmem.c | 188 +++++++++++++++++++++++++++++++++++++++++
drivers/nvmem/core.c | 13 +++
include/linux/nvmem-consumer.h | 6 ++
5 files changed, 217 insertions(+)
diff --git a/block/Kconfig b/block/Kconfig
index 15027963472d7b40e27b9097a5993c457b5b3054..0b33747e16dc33473683706f75c92bdf8b648f7c 100644
--- a/block/Kconfig
+++ b/block/Kconfig
@@ -209,6 +209,15 @@ config BLK_INLINE_ENCRYPTION_FALLBACK
by falling back to the kernel crypto API when inline
encryption hardware is not present.
+config BLK_NVMEM
+ bool "Block device NVMEM provider"
+ depends on OF
+ depends on NVMEM
+ help
+ Allow block devices (or partitions) to act as NVMEM providers,
+ typically used with eMMC to store MAC addresses or Wi-Fi
+ calibration data on embedded devices.
+
source "block/partitions/Kconfig"
config BLK_PM
diff --git a/block/Makefile b/block/Makefile
index 7dce2e44276c4274c11a0a61121c83d9c43d6e0c..d7ac389e71902bc091a8800ea266190a43b3e63d 100644
--- a/block/Makefile
+++ b/block/Makefile
@@ -36,3 +36,4 @@ obj-$(CONFIG_BLK_INLINE_ENCRYPTION) += blk-crypto.o blk-crypto-profile.o \
blk-crypto-sysfs.o
obj-$(CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK) += blk-crypto-fallback.o
obj-$(CONFIG_BLOCK_HOLDER_DEPRECATED) += holder.o
+obj-$(CONFIG_BLK_NVMEM) += blk-nvmem.o
diff --git a/block/blk-nvmem.c b/block/blk-nvmem.c
new file mode 100644
index 0000000000000000000000000000000000000000..96c0ffc51b1862a75644f3f94add35d59577d86b
--- /dev/null
+++ b/block/blk-nvmem.c
@@ -0,0 +1,188 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * block device NVMEM provider
+ *
+ * Copyright (c) 2024 Daniel Golle <daniel@makrotopia.org>
+ *
+ * Useful on devices using a partition on an eMMC for MAC addresses or
+ * Wi-Fi calibration EEPROM data.
+ */
+
+#include "blk.h"
+#include <linux/nvmem-provider.h>
+#include <linux/nvmem-consumer.h>
+#include <linux/of.h>
+#include <linux/pagemap.h>
+#include <linux/property.h>
+
+static void blk_nvmem_free(void *data)
+{
+ kfree(data);
+}
+
+/* List of all NVMEM devices */
+static LIST_HEAD(nvmem_devices);
+static DEFINE_MUTEX(devices_mutex);
+
+struct blk_nvmem {
+ struct nvmem_device *nvmem;
+ dev_t devt;
+ bool removed;
+ struct list_head list;
+};
+
+static int blk_nvmem_reg_read(void *priv, unsigned int from,
+ void *val, size_t bytes)
+{
+ blk_mode_t mode = BLK_OPEN_READ | BLK_OPEN_RESTRICT_WRITES;
+ unsigned long offs = from & ~PAGE_MASK, to_read;
+ pgoff_t f_index = from >> PAGE_SHIFT;
+ struct blk_nvmem *bnv = priv;
+ size_t bytes_left = bytes;
+ struct file *bdev_file;
+ struct folio *folio;
+ void *p;
+ int ret = 0;
+
+ if (bnv->removed)
+ return -ENODEV;
+
+ bdev_file = bdev_file_open_by_dev(bnv->devt, mode, priv, NULL);
+ if (!bdev_file)
+ return -ENODEV;
+
+ if (IS_ERR(bdev_file))
+ return PTR_ERR(bdev_file);
+
+ while (bytes_left) {
+ folio = read_mapping_folio(bdev_file->f_mapping, f_index++, NULL);
+ if (IS_ERR(folio)) {
+ ret = PTR_ERR(folio);
+ goto err_release_bdev;
+ }
+ to_read = min_t(unsigned long, bytes_left, PAGE_SIZE - offs);
+ p = folio_address(folio) + offset_in_folio(folio, offs);
+ memcpy(val, p, to_read);
+ offs = 0;
+ bytes_left -= to_read;
+ val += to_read;
+ folio_put(folio);
+ }
+
+err_release_bdev:
+ fput(bdev_file);
+
+ return ret;
+}
+
+static int blk_nvmem_register(struct device *dev)
+{
+ struct device_node *np = dev_of_node(dev);
+ struct block_device *bdev = dev_to_bdev(dev);
+ struct nvmem_config config = {};
+ struct blk_nvmem *bnv;
+
+ /* skip devices which do not have a device tree node */
+ if (!np)
+ return 0;
+
+ /* skip devices without an nvmem layout defined */
+ if (!of_get_child_by_name(np, "nvmem-layout"))
+ return 0;
+
+ /*
+ * skip block device too large to be represented as NVMEM devices
+ * which are using an 'int' as address
+ */
+ if (bdev_nr_bytes(bdev) > INT_MAX)
+ return -EFBIG;
+
+ bnv = kzalloc_obj(*bnv);
+ if (!bnv)
+ return -ENOMEM;
+
+ config.id = NVMEM_DEVID_NONE;
+ config.dev = &bdev->bd_device;
+ config.name = dev_name(&bdev->bd_device);
+ config.owner = THIS_MODULE;
+ config.priv = bnv;
+ config.reg_read = blk_nvmem_reg_read;
+ config.size = bdev_nr_bytes(bdev);
+ config.word_size = 1;
+ config.stride = 1;
+ config.read_only = true;
+ config.root_only = true;
+ config.ignore_wp = true;
+ config.of_node = to_of_node(dev->fwnode);
+
+ bnv->devt = bdev->bd_device.devt;
+ bnv->nvmem = nvmem_register(&config);
+ if (IS_ERR(bnv->nvmem)) {
+ dev_err_probe(&bdev->bd_device, PTR_ERR(bnv->nvmem),
+ "Failed to register NVMEM device\n");
+
+ kfree(bnv);
+ return PTR_ERR(bnv->nvmem);
+ }
+
+ /*
+ * Free bnv only when the nvmem device is fully released (i.e. when
+ * its kref hits zero), not at unregister time. This prevents a
+ * use-after-free if a consumer still holds an nvmem_cell reference
+ * when the block device is removed: nvmem_unregister() only does a
+ * kref_put(), so reg_read could still be called with bnv as priv
+ * until the last consumer drops its cell.
+ */
+ if (devm_add_action(nvmem_dev(bnv->nvmem), blk_nvmem_free, bnv)) {
+ nvmem_unregister(bnv->nvmem);
+ kfree(bnv);
+ return -ENOMEM;
+ }
+
+ mutex_lock(&devices_mutex);
+ list_add_tail(&bnv->list, &nvmem_devices);
+ mutex_unlock(&devices_mutex);
+
+ return 0;
+}
+
+static void blk_nvmem_unregister(struct device *dev)
+{
+ struct blk_nvmem *bnv_c, *bnv = NULL;
+
+ mutex_lock(&devices_mutex);
+ list_for_each_entry(bnv_c, &nvmem_devices, list) {
+ if (bnv_c->devt == dev_to_bdev(dev)->bd_device.devt) {
+ bnv = bnv_c;
+ break;
+ }
+ }
+
+ if (!bnv) {
+ mutex_unlock(&devices_mutex);
+ return;
+ }
+
+ list_del(&bnv->list);
+ mutex_unlock(&devices_mutex);
+ bnv->removed = true;
+ nvmem_unregister(bnv->nvmem);
+}
+
+static struct class_interface blk_nvmem_bus_interface __refdata = {
+ .class = &block_class,
+ .add_dev = &blk_nvmem_register,
+ .remove_dev = &blk_nvmem_unregister,
+};
+
+static int __init blk_nvmem_init(void)
+{
+ int ret;
+
+ ret = class_interface_register(&blk_nvmem_bus_interface);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+device_initcall(blk_nvmem_init);
diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 311cb2e5a5c02d2c6979d7c9bbb7f94abdfbdad1..ee3481229c20b3063c86d0dd66aabbf6b5e29169 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -2154,6 +2154,19 @@ const char *nvmem_dev_name(struct nvmem_device *nvmem)
}
EXPORT_SYMBOL_GPL(nvmem_dev_name);
+/**
+ * nvmem_dev() - Get the struct device of a given nvmem device.
+ *
+ * @nvmem: nvmem device.
+ *
+ * Return: pointer to the struct device of the nvmem device.
+ */
+struct device *nvmem_dev(struct nvmem_device *nvmem)
+{
+ return &nvmem->dev;
+}
+EXPORT_SYMBOL_GPL(nvmem_dev);
+
/**
* nvmem_dev_size() - Get the size of a given nvmem device.
*
diff --git a/include/linux/nvmem-consumer.h b/include/linux/nvmem-consumer.h
index 34c0e58dfa26636d2804fcc7e0bc4a875ee73dae..ce387c89dc8e4bc1241f3b6f36be8c6c95e282ed 100644
--- a/include/linux/nvmem-consumer.h
+++ b/include/linux/nvmem-consumer.h
@@ -82,6 +82,7 @@ int nvmem_device_cell_write(struct nvmem_device *nvmem,
const char *nvmem_dev_name(struct nvmem_device *nvmem);
size_t nvmem_dev_size(struct nvmem_device *nvmem);
+struct device *nvmem_dev(struct nvmem_device *nvmem);
void nvmem_add_cell_lookups(struct nvmem_cell_lookup *entries,
size_t nentries);
@@ -220,6 +221,11 @@ static inline const char *nvmem_dev_name(struct nvmem_device *nvmem)
return NULL;
}
+static inline struct device *nvmem_dev(struct nvmem_device *nvmem)
+{
+ return NULL;
+}
+
static inline void
nvmem_add_cell_lookups(struct nvmem_cell_lookup *entries, size_t nentries) {}
static inline void
--
2.34.1
^ permalink raw reply related
* [PATCH v2 3/8] dt-bindings: bluetooth: qcom: Add NVMEM BD address cell
From: Loic Poulain @ 2026-05-07 15:24 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Jens Axboe, Johannes Berg,
Jeff Johnson, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Srinivas Kandagatla, Andrew Lunn, Heiner Kallweit,
Russell King, Saravana Kannan
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-msm, linux-block,
linux-wireless, ath10k, linux-bluetooth, netdev, daniel,
Loic Poulain
In-Reply-To: <20260507-block-as-nvmem-v2-0-bf17edd5134e@oss.qualcomm.com>
Add support for an NVMEM cell provider for "local-bd-address",
allowing the Bluetooth stack to retrieve controller's BD address
from non-volatile storage such as an EEPROM or an eMMC partition.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
---
.../devicetree/bindings/net/bluetooth/qcom,bluetooth-common.yaml | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/bluetooth/qcom,bluetooth-common.yaml b/Documentation/devicetree/bindings/net/bluetooth/qcom,bluetooth-common.yaml
index c8e9c55c1afb4c8e05ba2dae41ce2db4194b4a0f..7cb28f30c9af032082f23311f2fc89a32f266f17 100644
--- a/Documentation/devicetree/bindings/net/bluetooth/qcom,bluetooth-common.yaml
+++ b/Documentation/devicetree/bindings/net/bluetooth/qcom,bluetooth-common.yaml
@@ -22,4 +22,13 @@ properties:
description:
boot firmware is incorrectly passing the address in big-endian order
+ nvmem-cells:
+ maxItems: 1
+ description:
+ Nvmem data cell that contains a 6 byte BD address with the most
+ significant byte first (big-endian).
+
+ nvmem-cell-names:
+ const: local-bd-address
+
additionalProperties: true
--
2.34.1
^ permalink raw reply related
* [PATCH v2 2/8] dt-bindings: net: wireless: qcom,ath10k: Add NVMEM MAC address cell
From: Loic Poulain @ 2026-05-07 15:24 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Jens Axboe, Johannes Berg,
Jeff Johnson, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Srinivas Kandagatla, Andrew Lunn, Heiner Kallweit,
Russell King, Saravana Kannan
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-msm, linux-block,
linux-wireless, ath10k, linux-bluetooth, netdev, daniel,
Loic Poulain
In-Reply-To: <20260507-block-as-nvmem-v2-0-bf17edd5134e@oss.qualcomm.com>
Add support for an NVMEM cell provider with the standard "mac-address"
cell name. This allows the ath10k device to retrieve its MAC address
from non-volatile storage such as an EEPROM or an eMMC partition.
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
---
Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
index c21d66c7cd558ab792524be9afec8b79272d1c87..96e025cd1e3acacf3da270ed43955b0d6acdb7de 100644
--- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
@@ -92,6 +92,15 @@ properties:
ieee80211-freq-limit: true
+ nvmem-cells:
+ maxItems: 1
+ description:
+ Nvmem data cell that contains a 6 byte MAC address with the most
+ significant byte first (big-endian).
+
+ nvmem-cell-names:
+ const: mac-address
+
qcom,calibration-data:
$ref: /schemas/types.yaml#/definitions/uint8-array
description:
--
2.34.1
^ permalink raw reply related
* [PATCH v2 1/8] dt-bindings: mmc: Document support for nvmem-layout
From: Loic Poulain @ 2026-05-07 15:24 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Jens Axboe, Johannes Berg,
Jeff Johnson, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Srinivas Kandagatla, Andrew Lunn, Heiner Kallweit,
Russell King, Saravana Kannan
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-msm, linux-block,
linux-wireless, ath10k, linux-bluetooth, netdev, daniel,
Loic Poulain
In-Reply-To: <20260507-block-as-nvmem-v2-0-bf17edd5134e@oss.qualcomm.com>
Add support for an nvmem-layout subnode under an eMMC hardware
partition. This allows the partition to be exposed as an NVMEM
provider and its internal layout to be described. For example,
an eMMC boot partition can be used to store device-specific
information such as a WiFi MAC address.
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
---
.../devicetree/bindings/mmc/mmc-card.yaml | 24 ++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/mmc-card.yaml b/Documentation/devicetree/bindings/mmc/mmc-card.yaml
index a61d6c96df759102f9c1fbfd548b026a77921cae..b21426a49cf1d9aae5b4e8e447b5be11b08c96bf 100644
--- a/Documentation/devicetree/bindings/mmc/mmc-card.yaml
+++ b/Documentation/devicetree/bindings/mmc/mmc-card.yaml
@@ -40,6 +40,9 @@ patternProperties:
contains:
const: fixed-partitions
+ nvmem-layout:
+ $ref: /schemas/nvmem/layouts/nvmem-layout.yaml
+
required:
- compatible
- reg
@@ -86,6 +89,27 @@ examples:
read-only;
};
};
+
+ partitions-boot2 {
+ nvmem-layout {
+ compatible = "fixed-layout";
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ mac-addr@4400 {
+ compatible = "mac-base";
+ reg = <0x4400 0x6>;
+ #nvmem-cell-cells = <1>;
+ };
+
+ bd-addr@5400 {
+ compatible = "mac-base";
+ reg = <0x5400 0x6>;
+ #nvmem-cell-cells = <1>;
+ };
+ };
+ };
};
};
--
2.34.1
^ permalink raw reply related
* [PATCH v2 0/8] Support for block device NVMEM providers
From: Loic Poulain @ 2026-05-07 15:24 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Jens Axboe, Johannes Berg,
Jeff Johnson, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Srinivas Kandagatla, Andrew Lunn, Heiner Kallweit,
Russell King, Saravana Kannan
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-msm, linux-block,
linux-wireless, ath10k, linux-bluetooth, netdev, daniel,
Loic Poulain, Konrad Dybcio
On embedded devices, it is common for factory provisioning to store
device-specific information, such as Ethernet or WiFi MAC addresses,
in a dedicated area of an eMMC partition. This avoids the need for
and additional EEPROM/OTP and leverages the persistence of eMMC.
One example is the Arduino UNO-Q, where the WiFi MAC address and the
Bluetooth Device address are stored in the eMMC Boot1 partition.
Until now, accessing this information required a custom bootloader
to read the data and inject it into the Device Tree before handing
control over to the kernel. This approach is fragile and leads to
device-specific workarounds.
Rather than adding a new NVMEM provider specifically to the eMMC
subsystem, the new support operates at the block layer, allowing any
block device to behave like other non-volatile memories such as EEPROM
or OTP.
This series builds on earlier work by Daniel Golle that enables block
devices to act as NVMEM providers:
https://lore.kernel.org/all/6061aa4201030b9bb2f8d03ef32a564fdb786ed1.1709667858.git.daniel@makrotopia.org/
It also introduces an NVMEM layout description for the Arduino UNO-Q,
allowing device-specific data stored in the eMMC Boot1 partition to
be accessed in a standard way.
WiFi and Ethernet already support retrieving MAC addresses from NVMEM.
Bluetooth requires similar support, which is also addressed.
Note that this is currently limited to MMC-backed block devices, as
only the MMC core associates a firmware node with the block device
(add_disk_fwnode). This can be easily extended in the future to
support additional block drivers.
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
---
Changes in v2:
- Fix example nvmem-layout cells to use compatible = "mac-base"
- Squash WiFi MAC and Bluetooth BD address consumer patches into the nvmem layout patch
- Fix possible use-after-free in blk-nvmem: bnv (nvmem priv) linked to nvmem lifetime
- Simplify nvmem-cell-names from items: - const: to plain const:
- Factor out common NVMEM EUI-48 retrieval logic
- Reorder changes
- Link to v1: https://lore.kernel.org/r/20260428-block-as-nvmem-v1-0-6ad23e75190a@oss.qualcomm.com
---
Daniel Golle (1):
block: implement NVMEM provider
Loic Poulain (7):
dt-bindings: mmc: Document support for nvmem-layout
dt-bindings: net: wireless: qcom,ath10k: Add NVMEM MAC address cell
dt-bindings: bluetooth: qcom: Add NVMEM BD address cell
net: of_net: Add of_get_nvmem_eui48() helper for EUI-48 lookup
Bluetooth: hci_sync: Add NVMEM-backed BD address retrieval
Bluetooth: qca: Set NVMEM BD address quirks when address is invalid
arm64: dts: qcom: arduino-imola: Describe NVMEM layout for WiFi/BT addresses
.../devicetree/bindings/mmc/mmc-card.yaml | 24 +++
.../net/bluetooth/qcom,bluetooth-common.yaml | 9 +
.../bindings/net/wireless/qcom,ath10k.yaml | 9 +
arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts | 34 ++++
block/Kconfig | 9 +
block/Makefile | 1 +
block/blk-nvmem.c | 188 +++++++++++++++++++++
drivers/bluetooth/btqca.c | 5 +-
drivers/nvmem/core.c | 13 ++
include/linux/nvmem-consumer.h | 6 +
include/linux/of_net.h | 7 +
include/net/bluetooth/hci.h | 18 ++
net/bluetooth/hci_sync.c | 39 ++++-
net/core/of_net.c | 47 ++++--
14 files changed, 395 insertions(+), 14 deletions(-)
---
base-commit: 47c4835fc0fed583d01d90387b67633950eba2b2
change-id: 20260428-block-as-nvmem-4b308e8bda9a
Best regards,
--
Loic Poulain <loic.poulain@oss.qualcomm.com>
^ permalink raw reply
* [PATCH v3 2/2] Bluetooth: MGMT: Add SCI setting bit(25)
From: Luiz Augusto von Dentz @ 2026-05-07 15:13 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <20260507151309.145613-1-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This adds MGMT_SETTING_SCI(25) which indicates that the controller is
support SCI feature.
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
---
include/net/bluetooth/hci_core.h | 2 ++
include/net/bluetooth/mgmt.h | 1 +
net/bluetooth/mgmt.c | 6 ++++++
3 files changed, 9 insertions(+)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 61872403fe65..84a1ee798da1 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -2094,6 +2094,8 @@ void hci_conn_del_sysfs(struct hci_conn *conn);
/* Shorter Connection Intervals support */
#define le_sci_capable(dev) \
((dev)->le_features[9] & HCI_LE_SCI)
+#define le_sci_enabled(dev) \
+ (le_enabled(dev) && le_sci_capable(dev))
void hci_sci_groups_clear(struct hci_dev *hdev);
diff --git a/include/net/bluetooth/mgmt.h b/include/net/bluetooth/mgmt.h
index 8234915854b6..dfd264f0bac7 100644
--- a/include/net/bluetooth/mgmt.h
+++ b/include/net/bluetooth/mgmt.h
@@ -121,6 +121,7 @@ struct mgmt_rp_read_index_list {
#define MGMT_SETTING_LL_PRIVACY BIT(22)
#define MGMT_SETTING_PAST_SENDER BIT(23)
#define MGMT_SETTING_PAST_RECEIVER BIT(24)
+#define MGMT_SETTING_SCI BIT(25)
#define MGMT_OP_READ_INFO 0x0004
#define MGMT_READ_INFO_SIZE 0
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index b05bb380e5f8..1ea06ae1efdc 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -864,6 +864,9 @@ static u32 get_supported_settings(struct hci_dev *hdev)
if (past_receiver_capable(hdev))
settings |= MGMT_SETTING_PAST_RECEIVER;
+ if (le_sci_capable(hdev))
+ settings |= MGMT_SETTING_SCI;
+
settings |= MGMT_SETTING_PHY_CONFIGURATION;
return settings;
@@ -955,6 +958,9 @@ static u32 get_current_settings(struct hci_dev *hdev)
if (past_receiver_enabled(hdev))
settings |= MGMT_SETTING_PAST_RECEIVER;
+ if (le_sci_enabled(hdev))
+ settings |= MGMT_SETTING_SCI;
+
return settings;
}
--
2.53.0
^ permalink raw reply related
* [PATCH v3 1/2] Bluetooth: HCI: Add initial support for Short Connection Interval feature
From: Luiz Augusto von Dentz @ 2026-05-07 15:13 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This adds initial support for SCI related commands, command bits, event
event mask bit and feature bits:
Events:
HCI_LE_Connection_Rate_Change(0x37)
Commands:
HCI_LE_Connection_Rate_Request(0x20a1)
HCI_LE_Set_Default_Rate_Parameters(0x20a2)
HCI_LE_Read_Minimum_Supported_Connection_Interval(0x20a3)
Also update the init sequence to incorporte support for reading SCI
groups and then setting the Default Rate
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
---
include/net/bluetooth/hci.h | 52 ++++++++++++++++++++
include/net/bluetooth/hci_core.h | 15 ++++++
net/bluetooth/hci_core.c | 14 +++++-
net/bluetooth/hci_event.c | 62 ++++++++++++++++++++++++
net/bluetooth/hci_sync.c | 83 +++++++++++++++++++++++++++++++-
5 files changed, 224 insertions(+), 2 deletions(-)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index 572b1c620c5d..848ec42de827 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -656,6 +656,7 @@ enum {
#define HCI_LE_LL_EXT_FEATURE 0x80
#define HCI_LE_CS 0x40
#define HCI_LE_CS_HOST 0x80
+#define HCI_LE_SCI 0x01
/* Connection modes */
#define HCI_CM_ACTIVE 0x0000
@@ -2486,6 +2487,46 @@ struct hci_rp_le_cs_test {
#define HCI_OP_LE_CS_TEST_END 0x2096
+#define HCI_OP_LE_CONN_RATE 0x20a1
+struct hci_cp_le_conn_rate {
+ __le16 handle;
+ __le16 interval_min;
+ __le16 interval_max;
+ __le16 subrate_min;
+ __le16 subrate_max;
+ __le16 max_latency;
+ __le16 cont_num;
+ __le16 supv_timeout;
+ __le16 min_ce_len;
+ __le16 max_ce_len;
+} __packed;
+
+#define HCI_OP_LE_SET_DEF_RATE 0x20a2
+struct hci_cp_le_set_def_rate {
+ __le16 interval_min;
+ __le16 interval_max;
+ __le16 subrate_min;
+ __le16 subrate_max;
+ __le16 max_latency;
+ __le16 cont_num;
+ __le16 supv_timeout;
+ __le16 min_ce_len;
+ __le16 max_ce_len;
+} __packed;
+
+#define HCI_OP_LE_READ_CONN_INTERVAL 0x20a3
+struct hci_le_conn_interval_group {
+ __le16 min;
+ __le16 max;
+ __le16 stride;
+} __packed;
+
+struct hci_rp_le_read_conn_interval {
+ __u8 status;
+ __u8 num_grps;
+ struct hci_le_conn_interval_group grps[] __counted_by(num_grps);
+} __packed;
+
/* ---- HCI Events ---- */
struct hci_ev_status {
__u8 status;
@@ -3300,6 +3341,17 @@ struct hci_evt_le_cs_test_end_complete {
__u8 status;
} __packed;
+#define HCI_EVT_LE_CONN_RATE_CHANGE 0x37
+struct hci_evt_le_conn_rate_change {
+ __u8 status;
+ __le16 handle;
+ __le16 interval;
+ __le16 subrate;
+ __le16 latency;
+ __le16 cont_number;
+ __le16 supv_timeout;
+} __packed;
+
#define HCI_EV_VENDOR 0xff
/* Internal events generated by Bluetooth stack */
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index aa600fbf9a53..61872403fe65 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -333,6 +333,14 @@ struct adv_monitor {
#define HCI_ADV_MONITOR_EXT_NONE 1
#define HCI_ADV_MONITOR_EXT_MSFT 2
+
+struct sci_group {
+ struct list_head list;
+ __u16 min;
+ __u16 max;
+ __u16 stride;
+};
+
#define HCI_MAX_SHORT_NAME_LENGTH 10
#define HCI_CONN_HANDLE_MAX 0x0eff
@@ -572,6 +580,7 @@ struct hci_dev {
struct list_head pend_le_reports;
struct list_head blocked_keys;
struct list_head local_codecs;
+ struct list_head sci_groups;
struct hci_dev_stats stat;
@@ -2082,6 +2091,12 @@ void hci_conn_del_sysfs(struct hci_conn *conn);
#define mws_transport_config_capable(dev) (((dev)->commands[30] & 0x08) && \
(!hci_test_quirk((dev), HCI_QUIRK_BROKEN_MWS_TRANSPORT_CONFIG)))
+/* Shorter Connection Intervals support */
+#define le_sci_capable(dev) \
+ ((dev)->le_features[9] & HCI_LE_SCI)
+
+void hci_sci_groups_clear(struct hci_dev *hdev);
+
/* ----- HCI protocols ----- */
#define HCI_PROTO_DEFER 0x01
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index c46c1236ebfa..04c5559ef029 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -2543,8 +2543,9 @@ struct hci_dev *hci_alloc_dev_priv(int sizeof_priv)
INIT_LIST_HEAD(&hdev->adv_instances);
INIT_LIST_HEAD(&hdev->blocked_keys);
INIT_LIST_HEAD(&hdev->monitored_devices);
-
INIT_LIST_HEAD(&hdev->local_codecs);
+ INIT_LIST_HEAD(&hdev->sci_groups);
+
INIT_WORK(&hdev->rx_work, hci_rx_work);
INIT_WORK(&hdev->cmd_work, hci_cmd_work);
INIT_WORK(&hdev->tx_work, hci_tx_work);
@@ -2740,6 +2741,16 @@ void hci_unregister_dev(struct hci_dev *hdev)
}
EXPORT_SYMBOL(hci_unregister_dev);
+void hci_sci_groups_clear(struct hci_dev *hdev)
+{
+ struct sci_group *grp, *tmp;
+
+ list_for_each_entry_safe(grp, tmp, &hdev->sci_groups, list) {
+ list_del(&grp->list);
+ kfree(grp);
+ }
+}
+
/* Release HCI device */
void hci_release_dev(struct hci_dev *hdev)
{
@@ -2766,6 +2777,7 @@ void hci_release_dev(struct hci_dev *hdev)
hci_discovery_filter_clear(hdev);
hci_blocked_keys_clear(hdev);
hci_codec_list_clear(&hdev->local_codecs);
+ hci_sci_groups_clear(hdev);
msft_release(hdev);
hci_dev_unlock(hdev);
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index eea2f810aafa..50ce09b752f0 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -3957,6 +3957,51 @@ static u8 hci_cc_le_read_all_local_features(struct hci_dev *hdev, void *data,
return rp->status;
}
+static u8 hci_cc_le_read_conn_interval(struct hci_dev *hdev, void *data,
+ struct sk_buff *skb)
+{
+ struct hci_rp_le_read_conn_interval *rp = data;
+ __u8 i;
+
+ bt_dev_dbg(hdev, "status 0x%2.2x", rp->status);
+
+ if (rp->status)
+ return rp->status;
+
+ hci_dev_lock(hdev);
+
+ /* Clear any existing SCI groups before adding new ones. */
+ hci_sci_groups_clear(hdev);
+
+ for (i = 0; i < rp->num_grps; i++) {
+ struct hci_le_conn_interval_group *grp;
+ struct sci_group *sgrp;
+
+ /* Pull HCI event data for the current group. */
+ grp = skb_pull_data(skb, sizeof(*grp));
+ if (!grp) {
+ bt_dev_err(hdev, "invalid data length for SCI group");
+ break;
+ }
+
+ sgrp = kzalloc(sizeof(*sgrp), GFP_KERNEL);
+ if (!sgrp) {
+ bt_dev_err(hdev, "can't allocate memory for SCI group");
+ break;
+ }
+
+ sgrp->min = __le16_to_cpu(grp->min);
+ sgrp->max = __le16_to_cpu(grp->max);
+ sgrp->stride = __le16_to_cpu(grp->stride);
+
+ list_add(&sgrp->list, &hdev->sci_groups);
+ }
+
+ hci_dev_unlock(hdev);
+
+ return rp->status;
+}
+
static void hci_cs_le_create_big(struct hci_dev *hdev, u8 status)
{
bt_dev_dbg(hdev, "status 0x%2.2x", status);
@@ -4239,6 +4284,10 @@ static const struct hci_cc {
HCI_CC(HCI_OP_LE_READ_ALL_LOCAL_FEATURES,
hci_cc_le_read_all_local_features,
sizeof(struct hci_rp_le_read_all_local_features)),
+ HCI_CC_VL(HCI_OP_LE_READ_CONN_INTERVAL,
+ hci_cc_le_read_conn_interval,
+ sizeof(struct hci_rp_le_read_conn_interval),
+ HCI_MAX_EVENT_SIZE),
};
static u8 hci_cc_func(struct hci_dev *hdev, const struct hci_cc *cc,
@@ -7372,6 +7421,16 @@ static void hci_le_read_all_remote_features_evt(struct hci_dev *hdev,
hci_dev_unlock(hdev);
}
+static void hci_le_conn_rate_change_evt(struct hci_dev *hdev, void *data,
+ struct sk_buff *skb)
+{
+ struct hci_evt_le_conn_rate_change *ev = data;
+
+ bt_dev_dbg(hdev, "status 0x%2.2x", ev->status);
+
+ /* TODO: Store rate to be used for next connection? */
+}
+
#define HCI_LE_EV_VL(_op, _func, _min_len, _max_len) \
[_op] = { \
.func = _func, \
@@ -7483,6 +7542,9 @@ static const struct hci_le_ev {
sizeof(struct
hci_evt_le_read_all_remote_features_complete),
HCI_MAX_EVENT_SIZE),
+ /* [0x37 = HCI_EVT_LE_CONN_RATE_CHANGE] */
+ HCI_LE_EV(HCI_EVT_LE_CONN_RATE_CHANGE, hci_le_conn_rate_change_evt,
+ sizeof(struct hci_evt_le_conn_rate_change)),
};
static void hci_le_meta_evt(struct hci_dev *hdev, void *data,
diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
index fd3aacdea512..dffcfdcad8cf 100644
--- a/net/bluetooth/hci_sync.c
+++ b/net/bluetooth/hci_sync.c
@@ -4449,6 +4449,10 @@ static int hci_le_set_event_mask_sync(struct hci_dev *hdev)
events[6] |= 0x02; /* LE CS Subevent Result Continue event */
events[6] |= 0x04; /* LE CS Test End Complete event */
}
+
+ if (le_sci_capable(hdev))
+ events[6] |= 0x20; /* LE Connection Rate Change */
+
return __hci_cmd_sync_status(hdev, HCI_OP_LE_SET_EVENT_MASK,
sizeof(events), events, HCI_CMD_TIMEOUT);
}
@@ -4611,9 +4615,16 @@ static int hci_le_set_host_features_sync(struct hci_dev *hdev)
return err;
}
- if (le_cs_capable(hdev))
+ if (le_cs_capable(hdev)) {
/* Channel Sounding (Host Support) */
err = hci_le_set_host_feature_sync(hdev, 47, 0x01);
+ if (err)
+ return err;
+ }
+
+ if (le_sci_capable(hdev))
+ /* Short Connection Interval (Host Support) */
+ err = hci_le_set_host_feature_sync(hdev, 73, 0x01);
return err;
}
@@ -4896,11 +4907,81 @@ static int hci_le_set_default_phy_sync(struct hci_dev *hdev)
sizeof(cp), &cp, HCI_CMD_TIMEOUT);
}
+/* Read Connection Interval if command is supported and SCI feature bit is
+ * marked as supported.
+ */
+static int hci_le_read_conn_interval_sync(struct hci_dev *hdev)
+{
+ if (!(hdev->commands[48] & BIT(7)) || !le_sci_capable(hdev))
+ return 0;
+
+ return __hci_cmd_sync_status(hdev, HCI_OP_LE_READ_CONN_INTERVAL,
+ 0, NULL, HCI_CMD_TIMEOUT);
+}
+
+/* Set Default Connection Rate Parameters if command is supported, SCI feature
+ * bit is marked as supported and at least one of the supported SCI groups
+ * exists.
+ */
+static int hci_le_set_def_rate_sync(struct hci_dev *hdev)
+{
+ struct hci_cp_le_set_def_rate cp;
+ struct sci_group *grp, *tmp;
+ __u16 min = 0, max = 0;
+
+ if (!(hdev->commands[48] & BIT(6)) || !le_sci_capable(hdev) ||
+ list_empty(&hdev->sci_groups))
+ return 0;
+
+ memset(&cp, 0, sizeof(cp));
+
+ /* Iterate over the SCI groups and find the widest supported connection
+ * interval range to maximize compatibility with peer devices.
+ */
+ list_for_each_entry_safe(grp, tmp, &hdev->sci_groups, list) {
+ if (!min || grp->min < min)
+ min = grp->min;
+
+ if (!max || grp->max > max)
+ max = grp->max;
+ }
+
+ cp.interval_min = cpu_to_le16(min);
+ cp.interval_max = cpu_to_le16(max);
+
+ /* HOG 1.2 Table 7.4. Modes with recommended parameter values suggests
+ * subrate 1-4 for all modes so use that as default.
+ */
+ cp.subrate_min = cpu_to_le16(0x0001);
+ cp.subrate_max = cpu_to_le16(0x0004);
+
+ /* HIP 1.2 Table 7.5. Modes with recommended parameter values suggests
+ * max latency of 0 for all modes expect low power.
+ */
+ cp.max_latency = 0x0000;
+
+ /* HIP 1.2 Table 7.5. Modes with recommended parameter values suggests
+ * continuation number 1 for full range.
+ */
+ cp.cont_num = cpu_to_le16(0x0001);
+
+ cp.supv_timeout = hdev->le_supv_timeout;
+ cp.min_ce_len = cpu_to_le16(min);
+ cp.max_ce_len = cpu_to_le16(max);
+
+ return __hci_cmd_sync_status(hdev, HCI_OP_LE_SET_DEF_RATE,
+ sizeof(cp), &cp, HCI_CMD_TIMEOUT);
+}
+
static const struct hci_init_stage le_init4[] = {
/* HCI_OP_LE_WRITE_DEF_DATA_LEN */
HCI_INIT(hci_le_set_write_def_data_len_sync),
/* HCI_OP_LE_SET_DEFAULT_PHY */
HCI_INIT(hci_le_set_default_phy_sync),
+ /* HCI_OP_LE_READ_CONN_INTERVAL */
+ HCI_INIT(hci_le_read_conn_interval_sync),
+ /* HCI_OP_LE_SET_DEF_RATE */
+ HCI_INIT(hci_le_set_def_rate_sync),
{}
};
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 12/12] Bluetooth: hci_qca: Fix the broken BT_EN GPIO detection for Qcom WCN devices
From: Bartosz Golaszewski @ 2026-05-07 14:55 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: manivannan.sadhasivam, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Shuai Zhang, linux-pm, linux-kernel,
linux-pci, linux-arm-msm, linux-bluetooth, Wei Deng,
Luiz Augusto von Dentz, stable+noautosel, Dmitry Baryshkov
In-Reply-To: <u65dquj6im54rc6w5apmq2a6mcpndvh3slcxbjh2bs5el7epw4@zjovdsjkm6ur>
On Thu, May 7, 2026 at 1:59 PM Manivannan Sadhasivam <mani@kernel.org> wrote:
> >
> > This will break the case of WCN399x devices without the PMU in device
> > tree. There is no enable-gpios since BT is not controllable, but if
> > there is no PMU, then devm_pwrseq_get() will always return
> > -EPROBE_DEFER.
> >
>
> Hmm. I missed that the pwrseq returns -EPROBE_DEFER even if the client doesn't
> require power sequencing. It is because, it has no way to figure it out.
>
> But I think the client can parse the regulator phandle, reach the regulator
> parent, then check for the '-pmu' suffix in the compatible to make sure that it
> has the power sequencing requirement. Then it can call devm_pwrseq_get() only if
> that check passes.
>
I'm wondering if we could maybe provide pwrseq_get_optional() that would only
really be optional with fw_devlink enabled (where we'd be able to ensure the
provider is probed before the consumer thus be able to tell right away if the
device is power-sequenced or not) while with fw_devlink disabled, it would
just behave like pwrseq_get() and return -EPROBE_DEFER?
Would it make sense?
Bart
^ permalink raw reply
* Re: [BlueZ v2 0/5] Add helper for "cleanup" variable attribute
From: Bastien Nocera @ 2026-05-07 14:42 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <20260506143220.3076135-1-hadess@hadess.net>
Hey,
I've made some changes to this patchset locally to make it easier to
use, I'll send a v3 next week.
(the MIN/MAX changes are still fine to push right now)
Regards
On Wed, 2026-05-06 at 16:30 +0200, Bastien Nocera wrote:
> As discussed in:
> https://lore.kernel.org/linux-bluetooth/ed949f2550f79a4bef19bd482bf8b069ad5b7e0c.camel@hadess.net/
>
> Implement a cleanup helper.
>
> The MIN/MAX fix is here because it touches the same hunk in
> src/main.c
> as the other patches. Feel free to pick it up straight away while the
> rest is discussed.
>
> Changes since v1:
> - Fixed checkpatch warnings
>
> Bastien Nocera (5):
> all: Remove more unneeded MIN/MAX macro definition
> shared/util: Add helper for "cleanup" variable attribute
> doc: Recommend using _cleanup_ and friends
> main: Use _cleanup_() to simplify configuration parsing
> main: Use _cleanup_() to simplify GError-handling
>
> doc/maintainer-guidelines.rst | 3 +
> lib/bluetooth/hci.c | 4 --
> src/main.c | 102 +++++++++++---------------------
> --
> src/shared/gatt-server.c | 8 ---
> src/shared/util.h | 8 +++
> 5 files changed, 43 insertions(+), 82 deletions(-)
^ permalink raw reply
* Re: [PATCH] Bluetooth: L2CAP: avoid using hci_conn after dropping hold
From: Luiz Augusto von Dentz @ 2026-05-07 13:58 UTC (permalink / raw)
To: Cen Zhang; +Cc: marcel, linux-bluetooth, linux-kernel, baijiaju1990
In-Reply-To: <20260506155313.1412894-1-zzzccc427@gmail.com>
Hi Cen,
On Wed, May 6, 2026 at 11:53 AM Cen Zhang <zzzccc427@gmail.com> wrote:
>
> l2cap_chan_connect() drops the temporary HCI connection hold after
> __l2cap_chan_add() attaches the L2CAP channel and takes its own hold.
> The function then checks hcon->state to see whether the channel can be
> started immediately because the underlying HCI link is already connected.
>
> Keep that state sample before hci_conn_drop(hcon), and only use the
> cached result afterwards. This avoids dereferencing hcon after the
> temporary hold has been released. Use READ_ONCE() for the sample because
> HCI connection state can be advanced concurrently by the command-sync
> worker while L2CAP is setting up the channel.
>
> The sampled state is only an optimization for the already-connected case:
> a stale non-connected value leaves the L2CAP channel pending for the
> normal HCI connect confirmation path.
>
> Signed-off-by: Cen Zhang <zzzccc427@gmail.com>
> ---
> net/bluetooth/l2cap_core.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> index 95c65fece39bd..40e84c1623a9c 100644
> --- a/net/bluetooth/l2cap_core.c
> +++ b/net/bluetooth/l2cap_core.c
> @@ -7078,6 +7078,7 @@ int l2cap_chan_connect(struct l2cap_chan *chan, __le16 psm, u16 cid,
> struct l2cap_conn *conn;
> struct hci_conn *hcon;
> struct hci_dev *hdev;
> + bool link_connected;
> int err;
>
> BT_DBG("%pMR -> %pMR (type %u) psm 0x%4.4x mode 0x%2.2x", &chan->src,
> @@ -7222,6 +7223,7 @@ int l2cap_chan_connect(struct l2cap_chan *chan, __le16 psm, u16 cid,
> chan->src_type = bdaddr_src_type(hcon);
>
> __l2cap_chan_add(conn, chan);
> + link_connected = READ_ONCE(hcon->state) == BT_CONNECTED;
>
> /* l2cap_chan_add takes its own ref so we can drop this one */
> hci_conn_drop(hcon);
> @@ -7236,7 +7238,7 @@ int l2cap_chan_connect(struct l2cap_chan *chan, __le16 psm, u16 cid,
> chan->sport = 0;
> write_unlock(&chan_list_lock);
>
> - if (hcon->state == BT_CONNECTED) {
> + if (link_connected) {
> if (chan->chan_type != L2CAP_CHAN_CONN_ORIENTED) {
> __clear_chan_timer(chan);
> if (l2cap_chan_check_security(chan, true))
It doesn't seem to be very useful to read the hcon->state and cache it
while other function still going to access it, anyway we refcount the
hcon and hci_dev_lock is being held accourding to sashiko:
https://sashiko.dev/#/patchset/20260506155313.1412894-1-zzzccc427%40gmail.com
--
Luiz Augusto von Dentz
^ permalink raw reply
* [bluetooth-next:master] BUILD SUCCESS 6911f19876fbf65116c61ae93a47e2316b41d5a4
From: kernel test robot @ 2026-05-07 13:48 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git master
branch HEAD: 6911f19876fbf65116c61ae93a47e2316b41d5a4 Bluetooth: HIDP: serialise l2cap_unregister_user via hidp_session_sem
elapsed time: 727m
configs tested: 194
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc defconfig gcc-15.2.0
arc randconfig-001 gcc-8.5.0
arc randconfig-001-20260507 gcc-14.3.0
arc randconfig-001-20260507 gcc-8.5.0
arc randconfig-002 gcc-8.5.0
arc randconfig-002-20260507 gcc-14.3.0
arc randconfig-002-20260507 gcc-8.5.0
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm defconfig gcc-15.2.0
arm randconfig-001 gcc-8.5.0
arm randconfig-001-20260507 gcc-14.3.0
arm randconfig-001-20260507 gcc-8.5.0
arm randconfig-002 gcc-8.5.0
arm randconfig-002-20260507 gcc-14.3.0
arm randconfig-002-20260507 gcc-8.5.0
arm randconfig-003 gcc-8.5.0
arm randconfig-003-20260507 gcc-14.3.0
arm randconfig-003-20260507 gcc-8.5.0
arm randconfig-004 gcc-8.5.0
arm randconfig-004-20260507 gcc-14.3.0
arm randconfig-004-20260507 gcc-8.5.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001 gcc-15.2.0
arm64 randconfig-001-20260507 gcc-15.2.0
arm64 randconfig-002 gcc-15.2.0
arm64 randconfig-002-20260507 gcc-15.2.0
arm64 randconfig-003 gcc-15.2.0
arm64 randconfig-003-20260507 gcc-15.2.0
arm64 randconfig-004 gcc-15.2.0
arm64 randconfig-004-20260507 gcc-15.2.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001 gcc-15.2.0
csky randconfig-001-20260507 gcc-15.2.0
csky randconfig-002 gcc-15.2.0
csky randconfig-002-20260507 gcc-15.2.0
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260507 clang-23
hexagon randconfig-002-20260507 clang-23
i386 allmodconfig clang-20
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20260507 clang-20
i386 buildonly-randconfig-002-20260507 clang-20
i386 buildonly-randconfig-003-20260507 clang-20
i386 buildonly-randconfig-004-20260507 clang-20
i386 buildonly-randconfig-005-20260507 clang-20
i386 buildonly-randconfig-006-20260507 clang-20
i386 defconfig gcc-15.2.0
i386 randconfig-001 gcc-14
i386 randconfig-001-20260507 gcc-14
i386 randconfig-002 gcc-14
i386 randconfig-002-20260507 gcc-14
i386 randconfig-003 gcc-14
i386 randconfig-003-20260507 gcc-14
i386 randconfig-004 gcc-14
i386 randconfig-004-20260507 gcc-14
i386 randconfig-005 gcc-14
i386 randconfig-005-20260507 gcc-14
i386 randconfig-006 gcc-14
i386 randconfig-006-20260507 gcc-14
i386 randconfig-007 gcc-14
i386 randconfig-007-20260507 gcc-14
i386 randconfig-011 clang-20
i386 randconfig-011-20260507 clang-20
i386 randconfig-012 clang-20
i386 randconfig-012-20260507 clang-20
i386 randconfig-013 clang-20
i386 randconfig-013-20260507 clang-20
i386 randconfig-014 clang-20
i386 randconfig-014-20260507 clang-20
i386 randconfig-015 clang-20
i386 randconfig-015-20260507 clang-20
i386 randconfig-016 clang-20
i386 randconfig-016-20260507 clang-20
i386 randconfig-017 clang-20
i386 randconfig-017-20260507 clang-20
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260507 clang-23
loongarch randconfig-002-20260507 clang-23
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
nios2 allmodconfig clang-23
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig clang-23
nios2 defconfig clang-19
nios2 randconfig-001-20260507 clang-23
nios2 randconfig-002-20260507 clang-23
openrisc allmodconfig clang-23
openrisc allmodconfig gcc-15.2.0
openrisc allnoconfig clang-23
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allyesconfig clang-19
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260507 gcc-8.5.0
parisc randconfig-002-20260507 gcc-8.5.0
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc mpc836x_rdk_defconfig clang-23
powerpc randconfig-001-20260507 gcc-8.5.0
powerpc randconfig-002-20260507 gcc-8.5.0
powerpc64 randconfig-001-20260507 gcc-8.5.0
powerpc64 randconfig-002-20260507 gcc-8.5.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allyesconfig clang-19
sh ap325rxa_defconfig gcc-15.2.0
sh defconfig gcc-14
sparc allnoconfig clang-23
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260507 gcc-12.5.0
sparc randconfig-002-20260507 gcc-12.5.0
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260507 gcc-12.5.0
sparc64 randconfig-002-20260507 gcc-12.5.0
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260507 gcc-12.5.0
um randconfig-002-20260507 gcc-12.5.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260507 clang-20
x86_64 buildonly-randconfig-002-20260507 clang-20
x86_64 buildonly-randconfig-003-20260507 clang-20
x86_64 buildonly-randconfig-004-20260507 clang-20
x86_64 buildonly-randconfig-005-20260507 clang-20
x86_64 buildonly-randconfig-006-20260507 clang-20
x86_64 defconfig gcc-14
x86_64 randconfig-001-20260507 gcc-14
x86_64 randconfig-002-20260507 gcc-14
x86_64 randconfig-003-20260507 gcc-14
x86_64 randconfig-004-20260507 gcc-14
x86_64 randconfig-005-20260507 gcc-14
x86_64 randconfig-006-20260507 gcc-14
x86_64 randconfig-011-20260507 gcc-14
x86_64 randconfig-012-20260507 gcc-14
x86_64 randconfig-013-20260507 gcc-14
x86_64 randconfig-014-20260507 gcc-14
x86_64 randconfig-015-20260507 gcc-14
x86_64 randconfig-016-20260507 gcc-14
x86_64 randconfig-071-20260507 clang-20
x86_64 randconfig-072-20260507 clang-20
x86_64 randconfig-073-20260507 clang-20
x86_64 randconfig-074-20260507 clang-20
x86_64 randconfig-075-20260507 clang-20
x86_64 randconfig-076-20260507 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allyesconfig clang-23
xtensa allyesconfig gcc-15.2.0
xtensa randconfig-001-20260507 gcc-12.5.0
xtensa randconfig-002-20260507 gcc-12.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 12/12] Bluetooth: hci_qca: Fix the broken BT_EN GPIO detection for Qcom WCN devices
From: Manivannan Sadhasivam @ 2026-05-07 11:59 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: manivannan.sadhasivam, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Shuai Zhang, linux-pm, linux-kernel,
linux-pci, linux-arm-msm, linux-bluetooth, Wei Deng,
Luiz Augusto von Dentz, stable+noautosel
In-Reply-To: <klxyhlqwzl6dzk76lrhugxqdsv4hushphlfchuorcmvx5yja7q@pdmp3abepldg>
On Wed, Apr 22, 2026 at 09:13:31PM +0300, Dmitry Baryshkov wrote:
> On Wed, Apr 22, 2026 at 04:54:53PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> > From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> >
> > Commit 'db0ff7e15923 ("driver: bluetooth: hci_qca:fix unable to load the BT
> > driver")' tried to check the presence of the BT_EN GPIO in Qcom WCN devices
> > to indicate the HCI layer whether this BT device can be power controlled or
> > not.
> >
> > But it was broken for two reasons:
> >
> > 1. Assumes that when devm_pwrseq_get() API returns an error, BT_EN is not
> > controllable. This is no way true as the API can fail for various reasons
> > and also the pwrseq-qcom-wcn driver treats the BT_EN GPIO as optional. So
> > even if the GPIO is not present, it will not fail the probe and this API
> > will not fail.
> >
> > 2. By skipping the error return, probe deferral is completely broken as the
> > API may return -EPROBE_DEFER to indicate the caller that the pwrseq driver
> > is not yet probed. Skipping the return value means, this driver is not
> > going to depend on pwrseq driver probing again and it just assumes that
> > the pwrseq is not available.
> >
> > So to fix these issues, fail the probe if devm_pwrseq_get() returns an
> > error and if it succeeds, use the newly introduced pwrseq_is_fixed() API to
> > check whether the power sequencer is fixed or not (i.e., whether the
> > Bluetooth interface on the Qcom WCN device is controllable using BT_EN GPIO
> > or not) and set the 'bt_en_available' flag accordingly.
> >
> > Cc: <stable+noautosel@kernel.org> # Depends on pwrseq change
> > Fixes: db0ff7e15923 ("driver: bluetooth: hci_qca:fix unable to load the BT driver")
> > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> > ---
> > drivers/bluetooth/hci_qca.c | 15 ++++++---------
> > 1 file changed, 6 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> > index 27e52b08ec47..dd1d93cbb3d8 100644
> > --- a/drivers/bluetooth/hci_qca.c
> > +++ b/drivers/bluetooth/hci_qca.c
> > @@ -2470,16 +2470,13 @@ static int qca_serdev_probe(struct serdev_device *serdev)
> > qcadev->bt_power->pwrseq = devm_pwrseq_get(&serdev->dev,
> > "bluetooth");
> >
> > - /*
> > - * Some modules have BT_EN enabled via a hardware pull-up,
> > - * meaning it is not defined in the DTS and is not controlled
> > - * through the power sequence. In such cases, fall through
> > - * to follow the legacy flow.
> > - */
> > if (IS_ERR(qcadev->bt_power->pwrseq))
> > - qcadev->bt_power->pwrseq = NULL;
> > - else
> > - break;
> > + return PTR_ERR(qcadev->bt_power->pwrseq);
>
> This will break the case of WCN399x devices without the PMU in device
> tree. There is no enable-gpios since BT is not controllable, but if
> there is no PMU, then devm_pwrseq_get() will always return
> -EPROBE_DEFER.
>
Hmm. I missed that the pwrseq returns -EPROBE_DEFER even if the client doesn't
require power sequencing. It is because, it has no way to figure it out.
But I think the client can parse the regulator phandle, reach the regulator
parent, then check for the '-pmu' suffix in the compatible to make sure that it
has the power sequencing requirement. Then it can call devm_pwrseq_get() only if
that check passes.
I'll do it in a separate series though as this series fixes a different problem
altogether.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH 01/12] power: sequencing: Introduce an API to check whether the pwrseq is fixed or controllable
From: Manivannan Sadhasivam @ 2026-05-07 11:55 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: manivannan.sadhasivam, Manivannan Sadhasivam via B4 Relay,
linux-pm, linux-kernel, linux-pci, linux-arm-msm, linux-bluetooth,
Wei Deng, Luiz Augusto von Dentz, Marcel Holtmann,
Luiz Augusto von Dentz, Shuai Zhang
In-Reply-To: <CAMRc=MfCprFY4QCwEJzbBnROGJzrRE-sRAD89xDxsUsJVfqOiQ@mail.gmail.com>
On Thu, Apr 23, 2026 at 12:24:02PM -0400, Bartosz Golaszewski wrote:
> On Wed, 22 Apr 2026 13:24:42 +0200, Manivannan Sadhasivam via B4 Relay
> <devnull+manivannan.sadhasivam.oss.qualcomm.com@kernel.org> said:
> > From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> >
> > Introduce an API pwrseq_is_fixed() so that the consumers can check whether
> > the given power sequencer is fixed or controllable. This will come handy
> > in situations where the consumers need to know whether the specific power
> > sequencer like 'Bluetooth' can be controllable using properties like BT_EN.
> >
> > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> > ---
> >
>
> I have several concerns about this new function: its name is very vague and
> doesn't really indicate its function (how is it "fixed" if you still control
> it?), it can be used to expose all kinds of things because of this lack of
> precision. I feel like it goes against the goal of pwrseq which is to abstract
> these things away from consumers.
>
> The problem we have here is for now a HW quirk affecting a single driver. I'm
> thinking that we can live with this driver just checking the relevant property
> of the provider device.
>
> Many subsystems provide functions that allow accessing the struct device
> associated with the provider. Could we introduce something like:
>
> struct device *pwrseq_to_device(struct pwrseq_desc);
>
> that would return the address of struct device associated with the provider of
> the descriptor? It wouldn't even have to return a new reference as holding a
> descriptor already implies also holding a reference to the pwrseq device
> backing it.
>
> Then in the bluetooth driver you could do:
>
> struct pwrseq_desc *pwrseq = pwrseq_get(dev, "bluetooth");
> struct device *dev = pwrseq_to_device(pwrseq);
>
> // Big fat comment stating why you do this
> if (!device_property_present(dev, "enable-gpios")) {
> // do whatever quirk is required
> }
>
> Would that make sense?
>
Yeah, sounds good to me. I'll incorporate this in v2, thanks!
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* 回复: About Kernel limitation HCI_MAX_FRAME_SIZE (1024 + 4)
From: yjg0107 @ 2026-05-07 9:55 UTC (permalink / raw)
To: luiz.dentz; +Cc: linux-bluetooth
In-Reply-To: <lot3ns12vglamg8c0b87iaoe.1777272055182@email.vivo.com>
[-- Attachment #1.1: Type: text/plain, Size: 1321 bytes --]
Hi Vudentz,
In the future, BT SIG will introduce the High Data Throughput (HDT), which may require transmit larger data size, not just 1024.
So what's your opinions? Could kernel remove the limitation that HCI_CHANNEL_USER can not change MTU?
Looking forward to your reply, thank you very much.
B.R.
Jigong Yin(殷吉功)---------- 回复的原邮件 ----------
发件人：yjg0107 <yjg0107@163.com>
日期：2026年4月27日 14:40
主题：About Kernel limitation HCI_MAX_FRAME_SIZE (1024 + 4)
收件人："luiz.dentz" <luiz.dentz@gmail.com>
抄送：linux-bluetooth <linux-bluetooth@vger.kernel.org>
About Kernel limitation HCI_MAX_FRAME_SIZE (1024 + 4)
Hi Luiz,
Question is same as https://github.com/bluez/bluez/issues/2073.
About Kernel limitation HCI_MAX_FRAME_SIZE (1024 + 4), you said that this will be fixed to enable user space changed, from #201 (comment).
The patch commit is torvalds/linux@09572fc, right?
However, why HCI_CHANNEL_USER type can not change MTU value? Google bluetooth aidl uses HCI_CHANNEL_USER type from https://cs.android.com/android/platform/superproject/+/android-latest-release:hardware/interfaces/bluetooth/aidl/default/net_bluetooth_mgmt.cpp line 282.
Could kernel remove the limitation that HCI_CHANNEL_USER can not change MTU?
Thanks.
B.R.
Jigong Yin
发自vivo电子邮件
[-- Attachment #1.2: Type: text/html, Size: 3153 bytes --]
^ permalink raw reply
* Re: [PATCH BlueZ] bap: Fix typo in QoS D-Bus dictionary entry names
From: Bastien Nocera @ 2026-05-07 8:13 UTC (permalink / raw)
To: Thomas Kirschner, linux-bluetooth
In-Reply-To: <20260506230051.27436-1-thomaskirschner85@yahoo.de>
LGTM
On Thu, 2026-05-07 at 01:00 +0200, Thomas Kirschner wrote:
> MinimumDelay and PreferredMinimumDelay had wrong spelling, causing
> them to be exposed incorrectly over D-Bus. Any client relying on
> the correct spelling would fail to find these entries, breaking
> LE Audio QoS negotiation.
> ---
> profiles/audio/bap.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/profiles/audio/bap.c b/profiles/audio/bap.c
> index 5333267f7..b35542488 100644
> --- a/profiles/audio/bap.c
> +++ b/profiles/audio/bap.c
> @@ -432,11 +432,11 @@ static gboolean get_qos(const
> GDBusPropertyTable *property,
> dict_append_entry(&dict, "Retransmissions", DBUS_TYPE_BYTE,
> &qos->rtn);
> dict_append_entry(&dict, "MaximumLatency", DBUS_TYPE_UINT16,
> &qos->latency);
> - dict_append_entry(&dict, "MimimumDelay", DBUS_TYPE_UINT32,
> + dict_append_entry(&dict, "MinimumDelay", DBUS_TYPE_UINT32,
> &qos->pd_min);
> dict_append_entry(&dict, "MaximumDelay", DBUS_TYPE_UINT32,
> &qos->pd_max);
> - dict_append_entry(&dict, "PreferredMimimumDelay",
> DBUS_TYPE_UINT32,
> + dict_append_entry(&dict, "PreferredMinimumDelay",
> DBUS_TYPE_UINT32,
> &qos->ppd_min);
> dict_append_entry(&dict, "PreferredMaximumDelay",
> DBUS_TYPE_UINT32,
> &qos->ppd_max);
^ permalink raw reply
* RE: [BlueZ] bap: Fix typo in QoS D-Bus dictionary entry names
From: bluez.test.bot @ 2026-05-07 0:58 UTC (permalink / raw)
To: linux-bluetooth, thomaskirschner85
In-Reply-To: <20260506230051.27436-1-thomaskirschner85@yahoo.de>
[-- Attachment #1: Type: text/plain, Size: 989 bytes --]
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1090721
---Test result---
Test Summary:
CheckPatch PASS 0.28 seconds
GitLint PASS 0.20 seconds
BuildEll PASS 19.93 seconds
BluezMake PASS 664.48 seconds
MakeCheck PASS 3.73 seconds
MakeDistcheck PASS 242.46 seconds
CheckValgrind PASS 224.20 seconds
CheckSmatch PASS 345.16 seconds
bluezmakeextell PASS 180.63 seconds
IncrementalBuild PASS 652.49 seconds
ScanBuild PASS 1008.10 seconds
https://github.com/bluez/bluez/pull/2105
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [bluez/bluez] 67706c: bap: Fix typo in QoS D-Bus dictionary entry names
From: qarnet @ 2026-05-07 0:02 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1090721
Home: https://github.com/bluez/bluez
Commit: 67706c7563c90ddffb9b642f4a77143670b362c4
https://github.com/bluez/bluez/commit/67706c7563c90ddffb9b642f4a77143670b362c4
Author: Thomas Kirschner <thomaskirschner85@yahoo.de>
Date: 2026-05-07 (Thu, 07 May 2026)
Changed paths:
M profiles/audio/bap.c
Log Message:
-----------
bap: Fix typo in QoS D-Bus dictionary entry names
MinimumDelay and PreferredMinimumDelay had wrong spelling, causing
them to be exposed incorrectly over D-Bus. Any client relying on
the correct spelling would fail to find these entries, breaking
LE Audio QoS negotiation.
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [PATCH BlueZ] bap: Fix typo in QoS D-Bus dictionary entry names
From: Thomas Kirschner @ 2026-05-06 23:00 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Thomas Kirschner
In-Reply-To: <20260506230051.27436-1-thomaskirschner85.ref@yahoo.de>
MinimumDelay and PreferredMinimumDelay had wrong spelling, causing
them to be exposed incorrectly over D-Bus. Any client relying on
the correct spelling would fail to find these entries, breaking
LE Audio QoS negotiation.
---
profiles/audio/bap.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/profiles/audio/bap.c b/profiles/audio/bap.c
index 5333267f7..b35542488 100644
--- a/profiles/audio/bap.c
+++ b/profiles/audio/bap.c
@@ -432,11 +432,11 @@ static gboolean get_qos(const GDBusPropertyTable *property,
dict_append_entry(&dict, "Retransmissions", DBUS_TYPE_BYTE, &qos->rtn);
dict_append_entry(&dict, "MaximumLatency", DBUS_TYPE_UINT16,
&qos->latency);
- dict_append_entry(&dict, "MimimumDelay", DBUS_TYPE_UINT32,
+ dict_append_entry(&dict, "MinimumDelay", DBUS_TYPE_UINT32,
&qos->pd_min);
dict_append_entry(&dict, "MaximumDelay", DBUS_TYPE_UINT32,
&qos->pd_max);
- dict_append_entry(&dict, "PreferredMimimumDelay", DBUS_TYPE_UINT32,
+ dict_append_entry(&dict, "PreferredMinimumDelay", DBUS_TYPE_UINT32,
&qos->ppd_min);
dict_append_entry(&dict, "PreferredMaximumDelay", DBUS_TYPE_UINT32,
&qos->ppd_max);
--
2.51.2
^ permalink raw reply related
* Re: [GIT PULL] bluetooth 2026-05-06
From: patchwork-bot+netdevbpf @ 2026-05-06 22:50 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: davem, kuba, linux-bluetooth, netdev
In-Reply-To: <20260506204553.58686-1-luiz.dentz@gmail.com>
Hello:
This pull request was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 6 May 2026 16:45:53 -0400 you wrote:
> The following changes since commit b89e0100a5f6885f9748bbacc3f4e3bcff654e4c:
>
> Merge tag 'wireless-2026-05-06' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless (2026-05-06 07:29:31 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2026-05-06
>
> [...]
Here is the summary with links:
- [GIT,PULL] bluetooth 2026-05-06
https://git.kernel.org/netdev/net/c/bd75e1003d3e
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* RE: Add helper for "cleanup" variable attribute
From: bluez.test.bot @ 2026-05-06 21:28 UTC (permalink / raw)
To: linux-bluetooth, hadess
In-Reply-To: <20260506143220.3076135-2-hadess@hadess.net>
[-- Attachment #1: Type: text/plain, Size: 1922 bytes --]
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1090532
---Test result---
Test Summary:
CheckPatch PASS 2.00 seconds
GitLint PASS 1.32 seconds
BuildEll PASS 21.42 seconds
BluezMake PASS 638.21 seconds
MakeCheck PASS 18.99 seconds
MakeDistcheck PASS 232.55 seconds
CheckValgrind PASS 272.18 seconds
CheckSmatch WARNING 331.14 seconds
bluezmakeextell PASS 163.78 seconds
IncrementalBuild PASS 1203.38 seconds
ScanBuild PASS 924.01 seconds
Details
##############################
Test: CheckSmatch - WARNING
Desc: Run smatch tool with source
Output:
src/main.c: note: in included file (through src/device.h):src/shared/gatt-server.c:271:25: warning: Variable length array is used.src/shared/gatt-server.c:614:25: warning: Variable length array is used.src/shared/gatt-server.c:712:25: warning: Variable length array is used.src/shared/gatt-server.c:271:25: warning: Variable length array is used.src/shared/gatt-server.c:614:25: warning: Variable length array is used.src/shared/gatt-server.c:712:25: warning: Variable length array is used.src/shared/gatt-server.c:271:25: warning: Variable length array is used.src/shared/gatt-server.c:614:25: warning: Variable length array is used.src/shared/gatt-server.c:712:25: warning: Variable length array is used.src/main.c: note: in included file (through src/device.h):src/main.c: note: in included file (through src/device.h):
https://github.com/bluez/bluez/pull/2102
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: [BlueZ,v1,1/3] tools/tester: Fix crash when hciemu_new fails
From: bluez.test.bot @ 2026-05-06 21:12 UTC (permalink / raw)
To: linux-bluetooth, luiz.dentz
In-Reply-To: <20260506194150.1701855-1-luiz.dentz@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2246 bytes --]
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1090665
---Test result---
Test Summary:
CheckPatch FAIL 1.10 seconds
GitLint PASS 0.74 seconds
BuildEll PASS 20.80 seconds
BluezMake PASS 652.47 seconds
CheckSmatch WARNING 352.56 seconds
bluezmakeextell PASS 184.99 seconds
IncrementalBuild PASS 680.38 seconds
ScanBuild PASS 1001.16 seconds
Details
##############################
Test: CheckPatch - FAIL
Desc: Run checkpatch.pl script
Output:
[BlueZ,v1,3/3] tools/tester: Retry with debug on hciemu_new failure
WARNING:LONG_LINE: line length of 81 exceeds 80 columns
#241: FILE: tools/sco-tester.c:196:
+ data->hciemu = hciemu_new_debug(HCIEMU_TYPE_BREDRLE, print_debug,
/github/workspace/src/patch/14557929.patch total: 0 errors, 1 warnings, 100 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
/github/workspace/src/patch/14557929.patch has style problems, please review.
NOTE: Ignored message types: COMMIT_MESSAGE COMPLEX_MACRO CONST_STRUCT FILE_PATH_CHANGES MISSING_SIGN_OFF PREFER_PACKED SPDX_LICENSE_TAG SPLIT_STRING SSCANF_TO_KSTRTO
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
##############################
Test: CheckSmatch - WARNING
Desc: Run smatch tool with source
Output:
tools/sco-tester.c: note: in included file:./lib/bluetooth/bluetooth.h:232:15: warning: array of flexible structures./lib/bluetooth/bluetooth.h:237:31: warning: array of flexible structurestools/sco-tester.c: note: in included file:./lib/bluetooth/bluetooth.h:232:15: warning: array of flexible structures./lib/bluetooth/bluetooth.h:237:31: warning: array of flexible structures
https://github.com/bluez/bluez/pull/2103
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [GIT PULL] bluetooth 2026-05-06
From: Luiz Augusto von Dentz @ 2026-05-06 20:45 UTC (permalink / raw)
To: davem, kuba; +Cc: linux-bluetooth, netdev
The following changes since commit b89e0100a5f6885f9748bbacc3f4e3bcff654e4c:
Merge tag 'wireless-2026-05-06' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless (2026-05-06 07:29:31 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2026-05-06
for you to fetch changes up to c5d415596cb6fbdf6334b06cc87a1a5a268d8725:
Bluetooth: HIDP: serialise l2cap_unregister_user via hidp_session_sem (2026-05-06 16:27:53 -0400)
----------------------------------------------------------------
bluetooth pull request for net:
- hci_conn: fix potential UAF in create_big_sync
- hci_event: fix memset typo
- hci_event: Fix OOB read and infinite loop in hci_le_create_big_complete_evt
- L2CAP: fix MPS check in l2cap_ecred_reconf_req
- L2CAP: defer conn param update to avoid conn->lock/hdev->lock inversion
- L2CAP: Fix null-ptr-deref in l2cap_sock_state_change_cb()
- L2CAP: Fix null-ptr-deref in l2cap_sock_get_sndtimeo_cb()
- L2CAP: Fix null-ptr-deref in l2cap_sock_new_connection_cb()
- RFCOMM: pull credit byte with skb_pull_data()
- SCO: fix sleeping under spinlock in sco_conn_ready
- SCO: hold sk properly in sco_conn_ready
- ISO: Fix data-race on dst in iso_sock_connect()
- ISO: Fix data-race on iso_pi(sk) in socket and HCI event paths
- bnep: fix incorrect length parsing in bnep_rx_frame() extension handling
- hci_uart: Fix NULL deref in recv callbacks when priv is uninitialized
- virtio_bt: clamp rx length before skb_put
- virtio_bt: validate rx pkt_type header length
- HIDP: serialise l2cap_unregister_user via hidp_session_sem
- btintel_pcie: treat boot stage bit 12 as warning
- btmtk: validate WMT event SKB length before struct access
----------------------------------------------------------------
Aurelien DESBRIERES (1):
Bluetooth: hci_uart: Fix NULL deref in recv callbacks when priv is uninitialized
David Carlier (1):
Bluetooth: hci_conn: fix potential UAF in create_big_sync
Dudu Lu (2):
Bluetooth: bnep: fix incorrect length parsing in bnep_rx_frame() extension handling
Bluetooth: l2cap: fix MPS check in l2cap_ecred_reconf_req
Jann Horn (1):
Bluetooth: hci_event: fix memset typo
Luiz Augusto von Dentz (1):
Bluetooth: hci_event: Fix OOB read and infinite loop in hci_le_create_big_complete_evt
Michael Bommarito (3):
Bluetooth: virtio_bt: clamp rx length before skb_put
Bluetooth: virtio_bt: validate rx pkt_type header length
Bluetooth: HIDP: serialise l2cap_unregister_user via hidp_session_sem
Mikhail Gavrilov (1):
Bluetooth: l2cap: defer conn param update to avoid conn->lock/hdev->lock inversion
Pauli Virtanen (2):
Bluetooth: SCO: fix sleeping under spinlock in sco_conn_ready
Bluetooth: SCO: hold sk properly in sco_conn_ready
Pengpeng Hou (1):
Bluetooth: RFCOMM: pull credit byte with skb_pull_data()
Sai Teja Aluvala (1):
Bluetooth: btintel_pcie: treat boot stage bit 12 as warning
SeungJu Cheon (2):
Bluetooth: ISO: Fix data-race on dst in iso_sock_connect()
Bluetooth: ISO: Fix data-race on iso_pi(sk) in socket and HCI event paths
Siwei Zhang (3):
Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_state_change_cb()
Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_get_sndtimeo_cb()
Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_new_connection_cb()
Tristan Madani (1):
Bluetooth: btmtk: validate WMT event SKB length before struct access
drivers/bluetooth/btintel_pcie.c | 13 +++-
drivers/bluetooth/btintel_pcie.h | 2 +-
drivers/bluetooth/btmtk.c | 15 ++++-
drivers/bluetooth/hci_ath.c | 3 +
drivers/bluetooth/hci_bcsp.c | 3 +
drivers/bluetooth/hci_h4.c | 3 +
drivers/bluetooth/hci_h5.c | 3 +
drivers/bluetooth/virtio_bt.c | 39 +++++++++---
include/net/bluetooth/hci_core.h | 2 +-
net/bluetooth/bnep/core.c | 13 +++-
net/bluetooth/hci_conn.c | 124 ++++++++++++++++++++++++++++++++-------
net/bluetooth/hci_event.c | 29 ++++++++-
net/bluetooth/hidp/core.c | 27 ++++++++-
net/bluetooth/iso.c | 56 ++++++++++--------
net/bluetooth/l2cap_core.c | 14 +----
net/bluetooth/l2cap_sock.c | 9 +++
net/bluetooth/rfcomm/core.c | 7 ++-
net/bluetooth/sco.c | 60 ++++++++++++-------
18 files changed, 320 insertions(+), 102 deletions(-)
^ permalink raw reply
* [bluez/bluez] 331e9d: tools/tester: Fix crash when hciemu_new fails
From: Luiz Augusto von Dentz @ 2026-05-06 20:23 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1090665
Home: https://github.com/bluez/bluez
Commit: 331e9d2b22eb2abd7d4f46268ac86c2276091283
https://github.com/bluez/bluez/commit/331e9d2b22eb2abd7d4f46268ac86c2276091283
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: 2026-05-06 (Wed, 06 May 2026)
Changed paths:
M tools/6lowpan-tester.c
M tools/bnep-tester.c
M tools/ioctl-tester.c
M tools/iso-tester.c
M tools/l2cap-tester.c
M tools/mesh-tester.c
M tools/mgmt-tester.c
M tools/rfcomm-tester.c
M tools/sco-tester.c
M tools/smp-tester.c
M tools/userchan-tester.c
Log Message:
-----------
tools/tester: Fix crash when hciemu_new fails
When hciemu_new returns NULL, the mgmt object was not being unreferenced
before returning from the pre-setup failure path. This could lead to a
NULL dereference in read_info_callback when it later calls
hciemu_get_address on the NULL hciemu pointer.
Add mgmt_unref and return to the error path across all testers.
Commit: a00fdf8c694eb05d2099f3d8a110296eafc77453
https://github.com/bluez/bluez/commit/a00fdf8c694eb05d2099f3d8a110296eafc77453
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: 2026-05-06 (Wed, 06 May 2026)
Changed paths:
M emulator/hciemu.c
M emulator/hciemu.h
Log Message:
-----------
emulator/hciemu: Add hciemu_new_debug/hciemu_new_num_debug
Add new constructors that accept debug callback and user_data parameters,
setting them up immediately after allocation so errors during early
initialization (create_vhci, hciemu_client_new) are captured by the debug
output.
Commit: 63ea27eca0e63307069d4966248fe7a8610560a2
https://github.com/bluez/bluez/commit/63ea27eca0e63307069d4966248fe7a8610560a2
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: 2026-05-06 (Wed, 06 May 2026)
Changed paths:
M tools/6lowpan-tester.c
M tools/bnep-tester.c
M tools/ioctl-tester.c
M tools/iso-tester.c
M tools/l2cap-tester.c
M tools/mesh-tester.c
M tools/mgmt-tester.c
M tools/rfcomm-tester.c
M tools/sco-tester.c
M tools/smp-tester.c
M tools/userchan-tester.c
Log Message:
-----------
tools/tester: Retry with debug on hciemu_new failure
When hciemu_new fails, retry using hciemu_new_debug to capture early
initialization errors before reporting the failure. This helps diagnose
issues like vhci or client creation failures in CI.
Compare: https://github.com/bluez/bluez/compare/331e9d2b22eb%5E...63ea27eca0e6
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox