* Re: [PATCH v5 5/9] block: implement NVMEM provider
From: Loic Poulain @ 2026-06-15 9:28 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-msm, linux-block,
linux-wireless, ath10k, linux-bluetooth, netdev, daniel,
Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Jens Axboe, Johannes Berg,
Jeff Johnson, 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
In-Reply-To: <CAMRc=McQkLnz2OS2RREAbcrsp47cL-W3bCduq8LwPBBUcVNyJw@mail.gmail.com>
On Mon, Jun 15, 2026 at 10:53 AM Bartosz Golaszewski <brgl@kernel.org> wrote:
>
> On Fri, 12 Jun 2026 15:20:57 +0200, Loic Poulain
> <loic.poulain@oss.qualcomm.com> said:
> > 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.
> >
> > For now, NVMEM is only registered for the whole disk block device, as the
> > OF node is currently only associated to it.
> >
> > 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 | 109 ++++++++++++++++++++++++++++++++++++++++++++++
> > block/blk.h | 8 ++++
> > block/genhd.c | 4 ++
> > include/linux/blk_types.h | 3 ++
> > include/linux/blkdev.h | 1 +
> > 7 files changed, 135 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..c005f059d9fe56242ebaef9905673dff902b5686
> > --- /dev/null
> > +++ b/block/blk-nvmem.c
> > @@ -0,0 +1,109 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * block device NVMEM provider
> > + *
> > + * Copyright (c) 2024 Daniel Golle <daniel@makrotopia.org>
> > + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> > + *
> > + * Useful on devices using a partition on an eMMC for MAC addresses or
> > + * Wi-Fi calibration EEPROM data.
> > + */
> > +
> > +#include <linux/file.h>
> > +#include <linux/nvmem-provider.h>
> > +#include <linux/nvmem-consumer.h>
> > +#include <linux/of.h>
> > +#include <linux/pagemap.h>
> > +#include <linux/property.h>
> > +
> > +#include "blk.h"
> > +
> > +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;
> > + dev_t devt = (dev_t)(uintptr_t)priv;
> > + size_t bytes_left = bytes;
> > + loff_t pos = from;
> > + int ret = 0;
> > +
> > + struct file *bdev_file __free(fput) = bdev_file_open_by_dev(devt, mode, priv, NULL);
> > + if (IS_ERR(bdev_file))
> > + return PTR_ERR(bdev_file);
> > +
> > + while (bytes_left) {
> > + pgoff_t f_index = pos >> PAGE_SHIFT;
> > + struct folio *folio;
> > + size_t folio_off;
> > + size_t to_read;
> > +
> > + folio = read_mapping_folio(bdev_file->f_mapping, f_index, NULL);
> > + if (IS_ERR(folio)) {
> > + ret = PTR_ERR(folio);
> > + break;
> > + }
> > +
> > + folio_off = offset_in_folio(folio, pos);
> > + to_read = min(bytes_left, folio_size(folio) - folio_off);
> > + memcpy_from_folio(val, folio, folio_off, to_read);
> > + pos += to_read;
> > + bytes_left -= to_read;
> > + val += to_read;
> > + folio_put(folio);
> > + }
> > +
> > + return ret;
> > +}
> > +
> > +void blk_nvmem_add(struct block_device *bdev)
> > +{
> > + struct device *dev = &bdev->bd_device;
> > + struct nvmem_config config = {};
> > +
> > + /* skip devices which do not have a device tree node */
> > + if (!dev_of_node(dev))
> > + return;
> > +
> > + /* skip devices without an nvmem layout defined */
> > + struct device_node *child __free(device_node) =
> > + of_get_child_by_name(dev_of_node(dev), "nvmem-layout");
> > + if (!child)
> > + return;
> > +
> > + /*
> > + * skip block device too large to be represented as NVMEM devices,
> > + * the NVMEM reg_read callback uses an unsigned int offset
> > + */
> > + if (bdev_nr_bytes(bdev) > UINT_MAX) {
> > + dev_warn(dev, "block device too large to be an NVMEM provider\n");
> > + return;
> > + }
> > +
> > + config.id = NVMEM_DEVID_NONE;
> > + config.dev = dev;
> > + config.name = dev_name(dev);
> > + config.owner = THIS_MODULE;
> > + config.priv = (void *)(uintptr_t)dev->devt;
> > + 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);
> > +
> > + bdev->bd_nvmem = nvmem_register(&config);
> > + if (IS_ERR(bdev->bd_nvmem)) {
> > + dev_err_probe(dev, PTR_ERR(bdev->bd_nvmem),
> > + "Failed to register NVMEM device\n");
>
> Using dev_err_probe() only makes sense with a return value. Which makes me
> think: we won't retry this after a probe deferral. I think we should return
Yes, so here with the nvmem fixed-layout, there is no way to get a
deferred probe error, but better to be ready to handle this anyway.
> int from this function just for this use-case. Also: if we *do* have
> a layout, shouldn't we treat a failure to register the nvmem provider as
> a an error and propagate it up the stack?
From an API perspective we should indeed return the error. From block
core, Do we want to fail the entire disk addition just because the
'companion' NVMEM provider couldn't be registered, or should we only
abort/return in case of EPROBE_DEFER?
>
> > + bdev->bd_nvmem = NULL;
> > + }
> > +}
> > +
> > +void blk_nvmem_del(struct block_device *bdev)
> > +{
> > + if (bdev->bd_nvmem)
>
> Nvmem core already performs a NULL check.
Ok, thanks!
>
> > + nvmem_unregister(bdev->bd_nvmem);
> > +
> > + bdev->bd_nvmem = NULL;
> > +}
> > diff --git a/block/blk.h b/block/blk.h
> > index ec4674cdf2ead4fd259ff5fc42401f591e684ee9..cd3c7ca723391c40be56f1dd4810e641b7c8a2b3 100644
> > --- a/block/blk.h
> > +++ b/block/blk.h
> > @@ -757,4 +757,12 @@ static inline void blk_debugfs_unlock(struct request_queue *q,
> > memalloc_noio_restore(memflags);
> > }
> >
> > +#ifdef CONFIG_BLK_NVMEM
> > +void blk_nvmem_add(struct block_device *bdev);
> > +void blk_nvmem_del(struct block_device *bdev);
> > +#else
> > +static inline void blk_nvmem_add(struct block_device *bdev) {}
> > +static inline void blk_nvmem_del(struct block_device *bdev) {}
> > +#endif
> > +
> > #endif /* BLK_INTERNAL_H */
> > diff --git a/block/genhd.c b/block/genhd.c
> > index 7d6854fd28e95ae9134309679a7c6a937f5b7db8..1b2382de6fb30c1e5f60f45c04dc03ed3bf5d5f2 100644
> > --- a/block/genhd.c
> > +++ b/block/genhd.c
> > @@ -421,6 +421,8 @@ static void add_disk_final(struct gendisk *disk)
> > */
> > dev_set_uevent_suppress(ddev, 0);
> > disk_uevent(disk, KOBJ_ADD);
> > +
> > + blk_nvmem_add(disk->part0);
> > }
> >
> > blk_apply_bdi_limits(disk->bdi, &disk->queue->limits);
> > @@ -704,6 +706,8 @@ static void __del_gendisk(struct gendisk *disk)
> >
> > disk_del_events(disk);
> >
> > + blk_nvmem_del(disk->part0);
> > +
> > /*
> > * Prevent new openers by unlinked the bdev inode.
> > */
> > diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h
> > index 8808ee76e73c09e0ceaac41ba59e86fb0c4efc64..ace6f59b860d0813665b2f62a1c03a1f4be94059 100644
> > --- a/include/linux/blk_types.h
> > +++ b/include/linux/blk_types.h
> > @@ -73,6 +73,9 @@ struct block_device {
> > int bd_writers;
> > #ifdef CONFIG_SECURITY
> > void *bd_security;
> > +#endif
> > +#ifdef CONFIG_BLK_NVMEM
> > + struct nvmem_device *bd_nvmem;
> > #endif
> > /*
> > * keep this out-of-line as it's both big and not needed in the fast
> > diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
> > index 890128cdea1ce66863c5baa36f3b336ec4550807..f15d2b5bf9e4fd2368b8a70416a978e22c0d4333 100644
> > --- a/include/linux/blkdev.h
> > +++ b/include/linux/blkdev.h
> > @@ -30,6 +30,7 @@
> >
> > struct module;
> > struct request_queue;
> > +struct nvmem_device;
> > struct elevator_queue;
> > struct blk_trace;
> > struct request;
> >
> > --
> > 2.34.1
> >
> >
>
> I like this approach better than the previous one.
>
> Thanks,
> Bartosz
^ permalink raw reply
* Re: [PATCH v5 5/9] block: implement NVMEM provider
From: Bartosz Golaszewski @ 2026-06-15 8:53 UTC (permalink / raw)
To: Loic Poulain
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-msm, linux-block,
linux-wireless, ath10k, linux-bluetooth, netdev, daniel,
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
In-Reply-To: <20260612-block-as-nvmem-v5-5-95e0b30fff90@oss.qualcomm.com>
On Fri, 12 Jun 2026 15:20:57 +0200, Loic Poulain
<loic.poulain@oss.qualcomm.com> said:
> 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.
>
> For now, NVMEM is only registered for the whole disk block device, as the
> OF node is currently only associated to it.
>
> 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 | 109 ++++++++++++++++++++++++++++++++++++++++++++++
> block/blk.h | 8 ++++
> block/genhd.c | 4 ++
> include/linux/blk_types.h | 3 ++
> include/linux/blkdev.h | 1 +
> 7 files changed, 135 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..c005f059d9fe56242ebaef9905673dff902b5686
> --- /dev/null
> +++ b/block/blk-nvmem.c
> @@ -0,0 +1,109 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * block device NVMEM provider
> + *
> + * Copyright (c) 2024 Daniel Golle <daniel@makrotopia.org>
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + *
> + * Useful on devices using a partition on an eMMC for MAC addresses or
> + * Wi-Fi calibration EEPROM data.
> + */
> +
> +#include <linux/file.h>
> +#include <linux/nvmem-provider.h>
> +#include <linux/nvmem-consumer.h>
> +#include <linux/of.h>
> +#include <linux/pagemap.h>
> +#include <linux/property.h>
> +
> +#include "blk.h"
> +
> +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;
> + dev_t devt = (dev_t)(uintptr_t)priv;
> + size_t bytes_left = bytes;
> + loff_t pos = from;
> + int ret = 0;
> +
> + struct file *bdev_file __free(fput) = bdev_file_open_by_dev(devt, mode, priv, NULL);
> + if (IS_ERR(bdev_file))
> + return PTR_ERR(bdev_file);
> +
> + while (bytes_left) {
> + pgoff_t f_index = pos >> PAGE_SHIFT;
> + struct folio *folio;
> + size_t folio_off;
> + size_t to_read;
> +
> + folio = read_mapping_folio(bdev_file->f_mapping, f_index, NULL);
> + if (IS_ERR(folio)) {
> + ret = PTR_ERR(folio);
> + break;
> + }
> +
> + folio_off = offset_in_folio(folio, pos);
> + to_read = min(bytes_left, folio_size(folio) - folio_off);
> + memcpy_from_folio(val, folio, folio_off, to_read);
> + pos += to_read;
> + bytes_left -= to_read;
> + val += to_read;
> + folio_put(folio);
> + }
> +
> + return ret;
> +}
> +
> +void blk_nvmem_add(struct block_device *bdev)
> +{
> + struct device *dev = &bdev->bd_device;
> + struct nvmem_config config = {};
> +
> + /* skip devices which do not have a device tree node */
> + if (!dev_of_node(dev))
> + return;
> +
> + /* skip devices without an nvmem layout defined */
> + struct device_node *child __free(device_node) =
> + of_get_child_by_name(dev_of_node(dev), "nvmem-layout");
> + if (!child)
> + return;
> +
> + /*
> + * skip block device too large to be represented as NVMEM devices,
> + * the NVMEM reg_read callback uses an unsigned int offset
> + */
> + if (bdev_nr_bytes(bdev) > UINT_MAX) {
> + dev_warn(dev, "block device too large to be an NVMEM provider\n");
> + return;
> + }
> +
> + config.id = NVMEM_DEVID_NONE;
> + config.dev = dev;
> + config.name = dev_name(dev);
> + config.owner = THIS_MODULE;
> + config.priv = (void *)(uintptr_t)dev->devt;
> + 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);
> +
> + bdev->bd_nvmem = nvmem_register(&config);
> + if (IS_ERR(bdev->bd_nvmem)) {
> + dev_err_probe(dev, PTR_ERR(bdev->bd_nvmem),
> + "Failed to register NVMEM device\n");
Using dev_err_probe() only makes sense with a return value. Which makes me
think: we won't retry this after a probe deferral. I think we should return
int from this function just for this use-case. Also: if we *do* have
a layout, shouldn't we treat a failure to register the nvmem provider as
a an error and propagate it up the stack?
> + bdev->bd_nvmem = NULL;
> + }
> +}
> +
> +void blk_nvmem_del(struct block_device *bdev)
> +{
> + if (bdev->bd_nvmem)
Nvmem core already performs a NULL check.
> + nvmem_unregister(bdev->bd_nvmem);
> +
> + bdev->bd_nvmem = NULL;
> +}
> diff --git a/block/blk.h b/block/blk.h
> index ec4674cdf2ead4fd259ff5fc42401f591e684ee9..cd3c7ca723391c40be56f1dd4810e641b7c8a2b3 100644
> --- a/block/blk.h
> +++ b/block/blk.h
> @@ -757,4 +757,12 @@ static inline void blk_debugfs_unlock(struct request_queue *q,
> memalloc_noio_restore(memflags);
> }
>
> +#ifdef CONFIG_BLK_NVMEM
> +void blk_nvmem_add(struct block_device *bdev);
> +void blk_nvmem_del(struct block_device *bdev);
> +#else
> +static inline void blk_nvmem_add(struct block_device *bdev) {}
> +static inline void blk_nvmem_del(struct block_device *bdev) {}
> +#endif
> +
> #endif /* BLK_INTERNAL_H */
> diff --git a/block/genhd.c b/block/genhd.c
> index 7d6854fd28e95ae9134309679a7c6a937f5b7db8..1b2382de6fb30c1e5f60f45c04dc03ed3bf5d5f2 100644
> --- a/block/genhd.c
> +++ b/block/genhd.c
> @@ -421,6 +421,8 @@ static void add_disk_final(struct gendisk *disk)
> */
> dev_set_uevent_suppress(ddev, 0);
> disk_uevent(disk, KOBJ_ADD);
> +
> + blk_nvmem_add(disk->part0);
> }
>
> blk_apply_bdi_limits(disk->bdi, &disk->queue->limits);
> @@ -704,6 +706,8 @@ static void __del_gendisk(struct gendisk *disk)
>
> disk_del_events(disk);
>
> + blk_nvmem_del(disk->part0);
> +
> /*
> * Prevent new openers by unlinked the bdev inode.
> */
> diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h
> index 8808ee76e73c09e0ceaac41ba59e86fb0c4efc64..ace6f59b860d0813665b2f62a1c03a1f4be94059 100644
> --- a/include/linux/blk_types.h
> +++ b/include/linux/blk_types.h
> @@ -73,6 +73,9 @@ struct block_device {
> int bd_writers;
> #ifdef CONFIG_SECURITY
> void *bd_security;
> +#endif
> +#ifdef CONFIG_BLK_NVMEM
> + struct nvmem_device *bd_nvmem;
> #endif
> /*
> * keep this out-of-line as it's both big and not needed in the fast
> diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
> index 890128cdea1ce66863c5baa36f3b336ec4550807..f15d2b5bf9e4fd2368b8a70416a978e22c0d4333 100644
> --- a/include/linux/blkdev.h
> +++ b/include/linux/blkdev.h
> @@ -30,6 +30,7 @@
>
> struct module;
> struct request_queue;
> +struct nvmem_device;
> struct elevator_queue;
> struct blk_trace;
> struct request;
>
> --
> 2.34.1
>
>
I like this approach better than the previous one.
Thanks,
Bartosz
^ permalink raw reply
* Re: [PATCH v5 1/9] block: partitions: of: Skip child nodes without reg property
From: Bartosz Golaszewski @ 2026-06-15 8:47 UTC (permalink / raw)
To: Loic Poulain
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-msm, linux-block,
linux-wireless, ath10k, linux-bluetooth, netdev, daniel,
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
In-Reply-To: <20260612-block-as-nvmem-v5-1-95e0b30fff90@oss.qualcomm.com>
On Fri, 12 Jun 2026 15:20:53 +0200, Loic Poulain
<loic.poulain@oss.qualcomm.com> said:
> Child nodes of a fixed-partitions node are not necessarily partition
> entries, for example an nvmem-layout node has no reg property. The
> current code passes a NULL reg pointer and uninitialized len to the
> length check, which can result in a kernel panic or silent failure to
> register any partitions.
>
> Fix validate_of_partition() to return a skip indicator when no reg
> property is present. Guard add_of_partition() with a reg property
> check for the same reason.
>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
I think this warrants a Cc: stable and backporting as well as a Fixes tag.
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* [Bug 221637] Regression for Intel Corporation Device a876 (rev 10)
From: bugzilla-daemon @ 2026-06-15 5:48 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221637-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221637
--- Comment #8 from The Linux kernel's regression tracker (Thorsten Leemhuis) (regressions@leemhuis.info) ---
Krian:
> the below patch.
FWIW a quick reminder, "[…] updated firmware files must not cause any
regressions for users of older kernel releases." -- that is a quote from
https://docs.kernel.org/driver-api/firmware/firmware-usage-guidelines.html
So fixing this with a kernel patch is nice, but by kernel standards this from
what I see still qualifies as a regression where the firmware change needs to
be reverted to avoid the problem.
That being said: if we assume that this is a corner case that only Bianca and
maybe one or two others hits, then using a patch is fine if it's fine for the
affected people. Is that the case?
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* Re: [PATCH v2] Bluetooth: qca: Add BT FW build version to kernel log
From: Xiuzhuo Shang @ 2026-06-15 3:27 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bartosz Golaszewski, linux-arm-msm, linux-bluetooth, linux-kernel,
cheng.jiang, quic_chezhou, wei.deng, shuai.zhang, mengshi.wu,
jinwang.li, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz
In-Reply-To: <ofpsjpkxrnzbnfza2emhli7xp2gwunknywbig6x7pzhis7yqyy@5z75psmjf5s6>
On 6/12/2026 3:42 PM, Dmitry Baryshkov wrote:
> On Wed, Jun 10, 2026 at 03:36:46PM +0800, Xiuzhuo Shang wrote:
>> Hi Bart,
>>
>> The main change in v2 was the commit message — I added the motivation and an example log line as
>>
>> Paul requested on v1. Carrying your Acked-by (given on v1) forward was just to avoid losing it. So
>>
>> v2 wasn't sent solely to collect a tag.
>
> Please don't send new revisions as a response to the previous
> iterations. Also don't top-post. Responses should go below the questions
> / comments they are intended to answer.
>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Got it, thanks for your suggestions.
>
>
>
>>
>>
>> Thanks,
>>
>> Xiuzhuo
>>
>>
>> On 6/10/2026 3:07 PM, Bartosz Golaszewski wrote:
>>> On Wed, 10 Jun 2026 08:42:32 +0200, Xiuzhuo Shang
>>> <xiuzhuo.shang@oss.qualcomm.com> said:
>>>> Firmware version is critical for bug triage. Users reporting issues
>>>> typically share dmesg output rather than debugfs contents, requiring
>>>> extra communication rounds to collect this information. Log the FW
>>>> build version directly to the kernel log so it is immediately
>>>> available in bug reports.
>>>>
>>>> Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
>>>> Signed-off-by: Xiuzhuo Shang <xiuzhuo.shang@oss.qualcomm.com>
>>>> ---
>>>
>>> Please don't send a new version if all you did is collected a single tag.
>>>
>>> Bart
>>
>
^ permalink raw reply
* [Bug 221637] Regression for Intel Corporation Device a876 (rev 10)
From: bugzilla-daemon @ 2026-06-14 23:41 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221637-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221637
Kiran (kiran.k@intel.com) changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kiran.k@intel.com
--- Comment #7 from Kiran (kiran.k@intel.com) ---
Hi Biance, Paul,
Appreciate if you can test and feedback with the below patch.
https://kernel.googlesource.com/pub/scm/linux/kernel/git/bluetooth/bluetooth-next/+/5917dd39db2bfc8b1b4c6ea8ed99adb4badef707
Seeing the error pattern in dmesg, appears like the issue has been fixed
already and the patch is present in bluetooth-next,
Thanks,
Kiran
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* RE: [RESEND] Bluetooth: btusb: Add new VID/PID 0x0489/0xe156 for MT7902
From: bluez.test.bot @ 2026-06-14 14:54 UTC (permalink / raw)
To: linux-bluetooth, kirill.kz.902
In-Reply-To: <20260614141258.1011-1-kirill.kz.902@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 988 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=1111290
---Test result---
Test Summary:
CheckPatch PASS 0.42 seconds
VerifyFixes PASS 0.08 seconds
VerifySignedoff PASS 0.08 seconds
GitLint PASS 0.19 seconds
SubjectPrefix PASS 0.08 seconds
BuildKernel PASS 15.77 seconds
CheckAllWarning PASS 17.33 seconds
CheckSparse PASS 17.61 seconds
BuildKernel32 PASS 15.26 seconds
TestRunnerSetup PASS 314.57 seconds
IncrementalBuild PASS 14.93 seconds
https://github.com/bluez/bluetooth-next/pull/315
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [PATCH RESEND] Bluetooth: btusb: Add new VID/PID 0x0489/0xe156 for MT7902
From: Kirill Shubin @ 2026-06-14 14:12 UTC (permalink / raw)
To: Luiz Augusto von Dentz, Marcel Holtmann
Cc: linux-bluetooth, linux-mediatek, Sean Wang, Sean Wang,
Kirill Shubin
From: Sean Wang <sean.wang@mediatek.com>
Add VID 0489 & PID e156 for MediaTek MT7902 USB Bluetooth chip.
The information in /sys/kernel/debug/usb/devices about the Bluetooth
device is listed as the below.
T: Bus=01 Lev=01 Prnt=01 Port=09 Cnt=05 Dev#= 6 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0489 ProdID=e156 Rev= 1.00
S: Manufacturer=MediaTek Inc.
S: Product=Wireless_Device
S: SerialNumber=000000000
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA
A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms
I: If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=8a(I) Atr=03(Int.) MxPS= 64 Ivl=125us
E: Ad=0a(O) Atr=03(Int.) MxPS= 64 Ivl=125us
I:* If#= 2 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us
E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us
Co-developed-by: Kirill Shubin <kirill.kz.902@gmail.com>
Signed-off-by: Kirill Shubin <kirill.kz.902@gmail.com>
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
---
Resend of the patch originally posted on 2026-05-04 [1], which has
received no maintainer feedback for ~6 weeks. No functional changes;
only rebased onto the current bluetooth-next (the quirks_table layout
shifted in the meantime). CI passed on the original posting
(CheckPatch/BuildKernel/Sparse, patchwork series 1089463).
[1] https://lore.kernel.org/linux-bluetooth/20260504190353.9358-1-sean.wang@kernel.org/
drivers/bluetooth/btusb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 08c0a99..7f14ce9 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -679,6 +679,8 @@ static const struct usb_device_id quirks_table[] = {
{ USB_DEVICE(0x13d3, 0x3606), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
/* MediaTek MT7902 Bluetooth devices */
+ { USB_DEVICE(0x0489, 0xe156), .driver_info = BTUSB_MEDIATEK |
+ BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0e8d, 0x1ede), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x13d3, 0x3579), .driver_info = BTUSB_MEDIATEK |
--
2.39.5
^ permalink raw reply related
* RE: [BlueZ,v2,1/2] shared/bap: Transition ASE to QoS Configured on CIS loss
From: bluez.test.bot @ 2026-06-14 13:12 UTC (permalink / raw)
To: linux-bluetooth, simon.mikuda
In-Reply-To: <20260614100208.1091560-1-simon.mikuda@streamunlimited.com>
[-- Attachment #1: Type: text/plain, Size: 2577 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=1111249
---Test result---
Test Summary:
CheckPatch FAIL 0.85 seconds
GitLint PASS 0.58 seconds
BuildEll PASS 20.31 seconds
BluezMake PASS 653.75 seconds
MakeCheck PASS 19.29 seconds
MakeDistcheck PASS 248.27 seconds
CheckValgrind PASS 296.98 seconds
CheckSmatch WARNING 353.24 seconds
bluezmakeextell PASS 184.97 seconds
IncrementalBuild PASS 975.52 seconds
ScanBuild PASS 1043.13 seconds
Details
##############################
Test: CheckPatch - FAIL
Desc: Run checkpatch.pl script
Output:
[BlueZ,v2,2/2] unit/bap: Add CIS loss test
WARNING:BAD_SIGN_OFF: Non-standard signature: Assisted-by:
#102:
Assisted-by: ClaudeCode:claude-opus-4.8
ERROR:BAD_SIGN_OFF: Unrecognized email address: 'ClaudeCode:claude-opus-4.8'
#102:
Assisted-by: ClaudeCode:claude-opus-4.8
/github/workspace/src/patch/14628094.patch total: 1 errors, 1 warnings, 92 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/14628094.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:
src/shared/bap.c:317:25: warning: array of flexible structuressrc/shared/bap.c: note: in included file:./src/shared/ascs.h:88:25: warning: array of flexible structuressrc/shared/bap.c:317:25: warning: array of flexible structuressrc/shared/bap.c: note: in included file:./src/shared/ascs.h:88:25: warning: array of flexible structuressrc/shared/bap.c:317:25: warning: array of flexible structuressrc/shared/bap.c: note: in included file:./src/shared/ascs.h:88:25: warning: array of flexible structures
https://github.com/bluez/bluez/pull/2230
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: [BlueZ,v3,1/2] shared/bap: Initialize ucast/bcast IDs as unset
From: bluez.test.bot @ 2026-06-14 13:03 UTC (permalink / raw)
To: linux-bluetooth, simon.mikuda
In-Reply-To: <20260614105016.1147112-1-simon.mikuda@streamunlimited.com>
[-- Attachment #1: Type: text/plain, Size: 2396 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=1111255
---Test result---
Test Summary:
CheckPatch PASS 0.63 seconds
GitLint FAIL 0.44 seconds
BuildEll PASS 17.83 seconds
BluezMake PASS 638.03 seconds
MakeCheck PASS 18.06 seconds
MakeDistcheck PASS 222.41 seconds
CheckValgrind PASS 278.79 seconds
CheckSmatch WARNING 316.71 seconds
bluezmakeextell PASS 168.90 seconds
IncrementalBuild PASS 639.69 seconds
ScanBuild PASS 926.11 seconds
Details
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
[BlueZ,v3,2/2] shared/bap: Don't link server ucast streams before CIS IDs are assigned
1: T1 Title exceeds max length (86>80): "[BlueZ,v3,2/2] shared/bap: Don't link server ucast streams before CIS IDs are assigned"
##############################
Test: CheckSmatch - WARNING
Desc: Run smatch tool with source
Output:
src/shared/bap.c:317:25: warning: array of flexible structuressrc/shared/bap.c: note: in included file:./src/shared/ascs.h:88:25: warning: array of flexible structuressrc/shared/bap.c:317:25: warning: array of flexible structuressrc/shared/bap.c: note: in included file:./src/shared/ascs.h:88:25: warning: array of flexible structuressrc/shared/bap.c:317:25: warning: array of flexible structuressrc/shared/bap.c: note: in included file:./src/shared/ascs.h:88:25: warning: array of flexible structuressrc/shared/bap.c:317:25: warning: array of flexible structuressrc/shared/bap.c: note: in included file:./src/shared/ascs.h:88:25: warning: array of flexible structuressrc/shared/bap.c:317:25: warning: array of flexible structuressrc/shared/bap.c: note: in included file:./src/shared/ascs.h:88:25: warning: array of flexible structuressrc/shared/bap.c:317:25: warning: array of flexible structuressrc/shared/bap.c: note: in included file:./src/shared/ascs.h:88:25: warning: array of flexible structures
https://github.com/bluez/bluez/pull/2232
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: Bluetooth: enable context analysis
From: bluez.test.bot @ 2026-06-14 12:57 UTC (permalink / raw)
To: linux-bluetooth, pav
In-Reply-To: <ad7f2913bb19e81661bae8bc51ae89144fce433e.1781432726.git.pav@iki.fi>
[-- Attachment #1: Type: text/plain, Size: 2794 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=1111252
---Test result---
Test Summary:
CheckPatch PASS 3.44 seconds
VerifyFixes PASS 0.07 seconds
VerifySignedoff PASS 0.07 seconds
GitLint PASS 0.98 seconds
SubjectPrefix PASS 0.54 seconds
BuildKernel PASS 26.52 seconds
CheckAllWarning PASS 29.29 seconds
CheckSparse PASS 28.58 seconds
BuildKernel32 PASS 26.00 seconds
TestRunnerSetup PASS 575.93 seconds
TestRunner_l2cap-tester PASS 58.42 seconds
TestRunner_iso-tester PASS 87.26 seconds
TestRunner_bnep-tester PASS 19.12 seconds
TestRunner_mgmt-tester FAIL 208.56 seconds
TestRunner_rfcomm-tester PASS 25.04 seconds
TestRunner_sco-tester PASS 32.00 seconds
TestRunner_ioctl-tester PASS 25.73 seconds
TestRunner_mesh-tester FAIL 25.83 seconds
TestRunner_smp-tester PASS 24.88 seconds
TestRunner_userchan-tester PASS 19.72 seconds
TestRunner_6lowpan-tester FAIL 45.81 seconds
IncrementalBuild PASS 33.20 seconds
Details
##############################
Test: TestRunner_mgmt-tester - FAIL
Desc: Run mgmt-tester with test-runner
Output:
Total: 494, Passed: 489 (99.0%), Failed: 1, Not Run: 4
Failed Test Cases
Read Exp Feature - Success Failed 0.236 seconds
##############################
Test: TestRunner_mesh-tester - FAIL
Desc: Run mesh-tester with test-runner
Output:
Total: 10, Passed: 8 (80.0%), Failed: 2, Not Run: 0
Failed Test Cases
Mesh - Send cancel - 1 Timed out 2.574 seconds
Mesh - Send cancel - 2 Timed out 1.991 seconds
##############################
Test: TestRunner_6lowpan-tester - FAIL
Desc: Run 6lowpan-tester with test-runner
Output:
Total: 8, Passed: 3 (37.5%), Failed: 5, Not Run: 0
Failed Test Cases
Client Connect - Disconnect Timed out 5.323 seconds
Client Recv Dgram - Success Timed out 4.988 seconds
Client Recv Raw - Success Timed out 5.015 seconds
Client Recv IPHC Dgram - Success Timed out 4.978 seconds
Client Recv IPHC Raw - Success Timed out 5.004 seconds
https://github.com/bluez/bluetooth-next/pull/314
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: [BlueZ,v2] media: use custom DBus timeouts only when remote side is waiting
From: bluez.test.bot @ 2026-06-14 12:45 UTC (permalink / raw)
To: linux-bluetooth, pav
In-Reply-To: <499a2bfcdd6ed488104bad57b285ddc9c7788f7e.1781436012.git.pav@iki.fi>
[-- Attachment #1: Type: text/plain, Size: 988 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=1111256
---Test result---
Test Summary:
CheckPatch PASS 0.28 seconds
GitLint PASS 0.19 seconds
BuildEll PASS 13.32 seconds
BluezMake PASS 468.50 seconds
MakeCheck PASS 3.02 seconds
MakeDistcheck PASS 152.22 seconds
CheckValgrind PASS 130.35 seconds
CheckSmatch PASS 204.38 seconds
bluezmakeextell PASS 102.95 seconds
IncrementalBuild PASS 462.75 seconds
ScanBuild PASS 580.85 seconds
https://github.com/bluez/bluez/pull/2233
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [bluez/bluez]
From: BluezTestBot @ 2026-06-14 12:08 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1096011
Home: https://github.com/bluez/bluez
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [bluez/bluez]
From: BluezTestBot @ 2026-06-14 12:08 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1108825
Home: https://github.com/bluez/bluez
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [bluez/bluez]
From: BluezTestBot @ 2026-06-14 12:08 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1111248
Home: https://github.com/bluez/bluez
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [bluez/bluez] ddb5d4: media: use custom DBus timeouts only when remote s...
From: Pauli Virtanen @ 2026-06-14 12:08 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1111256
Home: https://github.com/bluez/bluez
Commit: ddb5d4c135465f5645d42dbe978912fbf0552ee1
https://github.com/bluez/bluez/commit/ddb5d4c135465f5645d42dbe978912fbf0552ee1
Author: Pauli Virtanen <pav@iki.fi>
Date: 2026-06-14 (Sun, 14 Jun 2026)
Changed paths:
M profiles/audio/media.c
Log Message:
-----------
media: use custom DBus timeouts only when remote side is waiting
Under high system load (VM instance on boot) it's observed the 3 sec
timeout BlueZ uses for BAP broadcast SetConfiguration may be missed by
Wireplumber, as these are set up immediately on startup together with
any other setup (eg ALSA) that may need time.
There's no actual need for using a short custom timeout in BlueZ for
this, as in this case there is no remote side that is waiting for a reply.
Fix by limiting custom timeouts to cases where there is a waiting
remote, and use separate defines for A2DP and BAP.
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [bluez/bluez] 9a87a6: shared/bap: Initialize ucast/bcast IDs as unset
From: Šimon Mikuda @ 2026-06-14 12:08 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1111255
Home: https://github.com/bluez/bluez
Commit: 9a87a631641c71b07e2c56a71c5ec144c5a01d17
https://github.com/bluez/bluez/commit/9a87a631641c71b07e2c56a71c5ec144c5a01d17
Author: Simon Mikuda <simon.mikuda@streamunlimited.com>
Date: 2026-06-14 (Sun, 14 Jun 2026)
Changed paths:
M src/shared/bap.c
M unit/test-bap.c
Log Message:
-----------
shared/bap: Initialize ucast/bcast IDs as unset
Also change some lines where CIS should be used instead of CIG
Commit: 06237947f55082754809d11340a6639c87a2e295
https://github.com/bluez/bluez/commit/06237947f55082754809d11340a6639c87a2e295
Author: Simon Mikuda <simon.mikuda@streamunlimited.com>
Date: 2026-06-14 (Sun, 14 Jun 2026)
Changed paths:
M src/shared/bap.c
Log Message:
-----------
shared/bap: Don't link server ucast streams before CIS IDs are assigned
bap_ucast_io_link pairs streams whose CIG/CIS IDs match, but the IDs
are unset in Codec Configured state, so a Sink and Source bound for
different CISes get linked. The stray link later propagates a
disconnect to the wrong ASE and breaks Receiver Start Ready.
Skip linking until QoS Configured assigns the IDs.
Fixes PTS test BAP/USR/STR/BV-362-C
Compare: https://github.com/bluez/bluez/compare/9a87a631641c%5E...06237947f550
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [bluez/bluez] 5b79ca: gatt-database: Prefer notifications over indications
From: Šimon Mikuda @ 2026-06-14 12:08 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1111253
Home: https://github.com/bluez/bluez
Commit: 5b79ca3d0746d5f3baaf1cabc63c7daf898db7af
https://github.com/bluez/bluez/commit/5b79ca3d0746d5f3baaf1cabc63c7daf898db7af
Author: Simon Mikuda <simon.mikuda@streamunlimited.com>
Date: 2026-06-14 (Sun, 14 Jun 2026)
Changed paths:
M src/gatt-database.c
Log Message:
-----------
gatt-database: Prefer notifications over indications
When both notifications and indications are enabled (CCC value=0x0003)
we will send notifications by default.
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [bluez/bluez] 038ea1: shared/bap: Transition ASE to QoS Configured on CI...
From: Šimon Mikuda @ 2026-06-14 12:08 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1111249
Home: https://github.com/bluez/bluez
Commit: 038ea13b8cc1c3e46a4ef8d4956af74696470a39
https://github.com/bluez/bluez/commit/038ea13b8cc1c3e46a4ef8d4956af74696470a39
Author: Simon Mikuda <simon.mikuda@streamunlimited.com>
Date: 2026-06-14 (Sun, 14 Jun 2026)
Changed paths:
M src/shared/bap.c
Log Message:
-----------
shared/bap: Transition ASE to QoS Configured on CIS loss
stream_io_disconnected() only handled the Releasing state, leaving
Enabling, Streaming and Disabling ASEs stuck when the CIS was lost
unexpectedly.
The ASE shall autonomously move to QoS Configured on loss of the
CIS and notify the peer
Fixes PTS test BAP/USR/SCC/BV-167-C
Commit: df54038451324d0a5be729ba7cd155b5a8c0b27e
https://github.com/bluez/bluez/commit/df54038451324d0a5be729ba7cd155b5a8c0b27e
Author: Simon Mikuda <simon.mikuda@streamunlimited.com>
Date: 2026-06-14 (Sun, 14 Jun 2026)
Changed paths:
M unit/test-bap.c
Log Message:
-----------
unit/bap: Add CIS loss test
Verify a Source ASE in the Enabling state transitions to QoS Configured
rather than Disabling when its CIS is lost.
Assisted-by: ClaudeCode:claude-opus-4.8
Compare: https://github.com/bluez/bluez/compare/038ea13b8cc1%5E...df5403845132
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [PATCH BlueZ v2] media: use custom DBus timeouts only when remote side is waiting
From: Pauli Virtanen @ 2026-06-14 11:22 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Pauli Virtanen
Under high system load (VM instance on boot) it's observed the 3 sec
timeout BlueZ uses for BAP broadcast SetConfiguration may be missed by
Wireplumber, as these are set up immediately on startup together with
any other setup (eg ALSA) that may need time.
There's no actual need for using a short custom timeout in BlueZ for
this, as in this case there is no remote side that is waiting for a reply.
Fix by limiting custom timeouts to cases where there is a waiting
remote, and use separate defines for A2DP and BAP.
---
Notes:
v2: shorter BAP_REQUEST_TIMEOUT_MSEC, no particular reason to have
it 20 sec. Use that for cases where there may be remote side,
i.e. all except us being bcast source.
profiles/audio/media.c | 30 ++++++++++++++++++++++--------
1 file changed, 22 insertions(+), 8 deletions(-)
diff --git a/profiles/audio/media.c b/profiles/audio/media.c
index cdaafb04e..5d9ea2cbc 100644
--- a/profiles/audio/media.c
+++ b/profiles/audio/media.c
@@ -71,7 +71,11 @@
#define MEDIA_ENDPOINT_INTERFACE "org.bluez.MediaEndpoint1"
#define MEDIA_PLAYER_INTERFACE "org.mpris.MediaPlayer2.Player"
-#define REQUEST_TIMEOUT (3 * 1000) /* 3 seconds */
+/* Timeout should be less than avdtp request timeout (4 seconds) */
+#define A2DP_REQUEST_TIMEOUT_MSEC (3 * 1000)
+
+/* Timeout should be less than ATT timeout (30 seconds) */
+#define BAP_REQUEST_TIMEOUT_MSEC (3 * 1000)
struct media_app {
struct media_adapter *adapter;
@@ -465,16 +469,16 @@ static gboolean media_endpoint_async_call(DBusMessage *msg,
struct media_transport *transport,
media_endpoint_cb_t cb,
void *user_data,
- GDestroyNotify destroy)
+ GDestroyNotify destroy,
+ int timeout_msec)
{
struct endpoint_request *request;
request = g_new0(struct endpoint_request, 1);
- /* Timeout should be less than avdtp request timeout (4 seconds) */
if (g_dbus_send_message_with_reply(btd_get_dbus_connection(),
msg, &request->call,
- REQUEST_TIMEOUT) == FALSE) {
+ timeout_msec) == FALSE) {
error("D-Bus send failed");
g_free(request);
return FALSE;
@@ -521,7 +525,7 @@ static gboolean select_configuration(struct media_endpoint *endpoint,
DBUS_TYPE_INVALID);
return media_endpoint_async_call(msg, endpoint, NULL,
- cb, user_data, destroy);
+ cb, user_data, destroy, -1);
}
static int transport_device_cmp(gconstpointer data, gconstpointer user_data)
@@ -604,7 +608,8 @@ static gboolean set_configuration(struct media_endpoint *endpoint,
g_dbus_get_properties(conn, path, "org.bluez.MediaTransport1", &iter);
return media_endpoint_async_call(msg, endpoint, transport,
- cb, user_data, destroy);
+ cb, user_data, destroy,
+ A2DP_REQUEST_TIMEOUT_MSEC);
}
#endif
@@ -1093,7 +1098,7 @@ static int pac_select(struct bt_bap_pac *lpac, struct bt_bap_pac *rpac,
dbus_message_iter_close_container(&iter, &dict);
if (!media_endpoint_async_call(msg, endpoint, NULL, pac_select_cb,
- data, free))
+ data, free, -1))
return -EIO;
return 0;
@@ -1233,6 +1238,7 @@ static int pac_config(struct bt_bap_stream *stream, struct iovec *cfg,
DBusMessage *msg;
DBusMessageIter iter;
const char *path;
+ int timeout_msec;
DBG("endpoint %p stream %p", endpoint, stream);
@@ -1243,9 +1249,16 @@ static int pac_config(struct bt_bap_stream *stream, struct iovec *cfg,
switch (bt_bap_stream_get_type(stream)) {
case BT_BAP_STREAM_TYPE_UCAST:
transport = pac_ucast_config(stream, cfg, endpoint);
+ timeout_msec = BAP_REQUEST_TIMEOUT_MSEC;
break;
case BT_BAP_STREAM_TYPE_BCAST:
transport = pac_bcast_config(stream, cfg, endpoint);
+
+ /* If we are sink, BASS remote may be waiting: custom timeout */
+ if (bt_bap_stream_get_dir(stream) == BT_BAP_SOURCE)
+ timeout_msec = BAP_REQUEST_TIMEOUT_MSEC;
+ else
+ timeout_msec = -1;
break;
default:
transport = NULL;
@@ -1279,7 +1292,8 @@ static int pac_config(struct bt_bap_stream *stream, struct iovec *cfg,
g_dbus_get_properties(conn, path, "org.bluez.MediaTransport1", &iter);
if (!media_endpoint_async_call(msg, endpoint, transport,
- pac_config_cb, data, free))
+ pac_config_cb, data, free,
+ timeout_msec))
return -EIO;
return 0;
--
2.54.0
^ permalink raw reply related
* RE: [BlueZ,v2,1/2] shared/bap: Initialize ucast/bcast IDs as unset
From: bluez.test.bot @ 2026-06-14 11:05 UTC (permalink / raw)
To: linux-bluetooth, simon.mikuda
In-Reply-To: <20260614095520.1090106-1-simon.mikuda@streamunlimited.com>
[-- Attachment #1: Type: text/plain, Size: 2397 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=1111248
---Test result---
Test Summary:
CheckPatch PASS 0.92 seconds
GitLint FAIL 0.63 seconds
BuildEll PASS 20.70 seconds
BluezMake PASS 656.66 seconds
MakeCheck PASS 18.62 seconds
MakeDistcheck PASS 246.18 seconds
CheckValgrind PASS 294.94 seconds
CheckSmatch WARNING 355.15 seconds
bluezmakeextell PASS 183.39 seconds
IncrementalBuild PASS 673.90 seconds
ScanBuild PASS 1033.04 seconds
Details
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
[BlueZ,v2,2/2] shared/bap: Don't link server ucast streams before CIS IDs are assigned
1: T1 Title exceeds max length (86>80): "[BlueZ,v2,2/2] shared/bap: Don't link server ucast streams before CIS IDs are assigned"
##############################
Test: CheckSmatch - WARNING
Desc: Run smatch tool with source
Output:
src/shared/bap.c:317:25: warning: array of flexible structuressrc/shared/bap.c: note: in included file:./src/shared/ascs.h:88:25: warning: array of flexible structuressrc/shared/bap.c:317:25: warning: array of flexible structuressrc/shared/bap.c: note: in included file:./src/shared/ascs.h:88:25: warning: array of flexible structuressrc/shared/bap.c:317:25: warning: array of flexible structuressrc/shared/bap.c: note: in included file:./src/shared/ascs.h:88:25: warning: array of flexible structuressrc/shared/bap.c:317:25: warning: array of flexible structuressrc/shared/bap.c: note: in included file:./src/shared/ascs.h:88:25: warning: array of flexible structuressrc/shared/bap.c:317:25: warning: array of flexible structuressrc/shared/bap.c: note: in included file:./src/shared/ascs.h:88:25: warning: array of flexible structuressrc/shared/bap.c:317:25: warning: array of flexible structuressrc/shared/bap.c: note: in included file:./src/shared/ascs.h:88:25: warning: array of flexible structures
https://github.com/bluez/bluez/pull/2229
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [PATCH BlueZ v3 2/2] shared/bap: Don't link server ucast streams before CIS IDs are assigned
From: Simon Mikuda @ 2026-06-14 10:50 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Simon Mikuda
In-Reply-To: <20260614105016.1147112-1-simon.mikuda@streamunlimited.com>
bap_ucast_io_link pairs streams whose CIG/CIS IDs match, but the IDs
are unset in Codec Configured state, so a Sink and Source bound for
different CISes get linked. The stray link later propagates a
disconnect to the wrong ASE and breaks Receiver Start Ready.
Skip linking until QoS Configured assigns the IDs.
Fixes PTS test BAP/USR/STR/BV-362-C
---
src/shared/bap.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/src/shared/bap.c b/src/shared/bap.c
index e8fbf0899..6ba9d3e06 100644
--- a/src/shared/bap.c
+++ b/src/shared/bap.c
@@ -2679,6 +2679,15 @@ static int bap_ucast_io_link(struct bt_bap_stream *stream,
stream->ep->dir == link->ep->dir)
return -EINVAL;
+ /* The server pairs Sink and Source by matching CIG/CIS, but those are
+ * unset until QoS Configured, so it would link unrelated ASEs (CIS 0
+ * is otherwise a valid ID). Clients gate linking on the lock instead.
+ */
+ if (!stream->client &&
+ (stream->qos.ucast.cis_id == BT_ISO_QOS_CIS_UNSET ||
+ link->qos.ucast.cis_id == BT_ISO_QOS_CIS_UNSET))
+ return -EINVAL;
+
if (stream->client && !(stream->locked && link->locked))
return -EINVAL;
--
2.43.0
^ permalink raw reply related
* [PATCH BlueZ v3 1/2] shared/bap: Initialize ucast/bcast IDs as unset
From: Simon Mikuda @ 2026-06-14 10:50 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Simon Mikuda
In-Reply-To: <fa0febe1-5866-4a3f-9f86-ae70e9d4b22d@streamunlimited.com>
Also change some lines where CIS should be used instead of CIG
---
src/shared/bap.c | 13 +++++++++++++
unit/test-bap.c | 4 ++--
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/src/shared/bap.c b/src/shared/bap.c
index deb85b264..e8fbf0899 100644
--- a/src/shared/bap.c
+++ b/src/shared/bap.c
@@ -2902,6 +2902,19 @@ static struct bt_bap_stream *bap_stream_new(struct bt_bap *bap,
stream->ops = bap_stream_new_ops(stream);
stream->pending_states = queue_new();
+ switch (bt_bap_pac_get_type(lpac)) {
+ case BT_BAP_SINK:
+ case BT_BAP_SOURCE:
+ stream->qos.ucast.cig_id = BT_ISO_QOS_CIG_UNSET;
+ stream->qos.ucast.cis_id = BT_ISO_QOS_CIS_UNSET;
+ break;
+ case BT_BAP_BCAST_SOURCE:
+ case BT_BAP_BCAST_SINK:
+ stream->qos.bcast.big = BT_ISO_QOS_BIG_UNSET;
+ stream->qos.bcast.bis = BT_ISO_QOS_BIS_UNSET;
+ break;
+ }
+
queue_push_tail(bap->streams, stream);
return bt_bap_stream_ref(stream);
diff --git a/unit/test-bap.c b/unit/test-bap.c
index 03b19678e..4ac9a207c 100644
--- a/unit/test-bap.c
+++ b/unit/test-bap.c
@@ -9894,7 +9894,7 @@ static int streaming_ucl_create_io(struct bt_bap_stream *stream,
i = qos[0] ? qos[0]->ucast.cis_id : qos[1]->ucast.cis_id;
- if (i == BT_ISO_QOS_CIG_UNSET) {
+ if (i == BT_ISO_QOS_CIS_UNSET) {
for (i = 0; i < ARRAY_SIZE(data->fds); ++i) {
if (data->fds[i][0] > 0)
continue;
@@ -10000,7 +10000,7 @@ static void test_select_cb(struct bt_bap_pac *pac, int err,
if (!data->cfg->streams) {
qos->ucast.cig_id = BT_ISO_QOS_CIG_UNSET;
- qos->ucast.cis_id = BT_ISO_QOS_CIG_UNSET;
+ qos->ucast.cis_id = BT_ISO_QOS_CIS_UNSET;
} else {
/* All streams to separate CIS.
*
--
2.43.0
^ permalink raw reply related
* Re: [PATCH BlueZ] gatt-client: Add PreferredNotifyType property
From: Simon Mikuda @ 2026-06-14 10:34 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <CABBYNZL-A=NpnfiO9GO66TNX5QaEuvpSZ9fuBk0Jo+aNtr7huA@mail.gmail.com>
I send a patch that will use notifications by default, when both
indications+notifications are enabled.
I am not sure what is meant by this:
> when an acknowledgment is not required by a higher-layer specification
in that case we should send indication, which was previous behavior...
On 6/8/26 17:21, Luiz Augusto von Dentz wrote:
> Hi Simon,
>
> On Mon, Jun 8, 2026 at 10:31 AM Simon Mikuda
> <simon.mikuda@streamunlimited.com> wrote:
>> When a characteristic supports both notifications and indications the
>> CCC we always register for notifications, leaving no way to choose
>> indications from D-Bus.
>>
>> Add PreferredNotifyType (string, "notification"/"indication") to
>> org.bluez.GattCharacteristic1, only present when both flags are set.
>> StartNotify() and AcquireNotify() honor it on the next CCC write.
>> ---
>> doc/org.bluez.GattCharacteristic.rst | 21 +++++++
>> src/gatt-client.c | 85 ++++++++++++++++++++++++++++
>> src/shared/gatt-client.c | 31 +++++++++-
>> src/shared/gatt-client.h | 3 +
>> 4 files changed, 138 insertions(+), 2 deletions(-)
>>
>> diff --git a/doc/org.bluez.GattCharacteristic.rst b/doc/org.bluez.GattCharacteristic.rst
>> index 805f39593..f7e541590 100644
>> --- a/doc/org.bluez.GattCharacteristic.rst
>> +++ b/doc/org.bluez.GattCharacteristic.rst
>> @@ -401,3 +401,24 @@ uint16 MTU [read-only]
>>
>> Characteristic MTU, this is valid both for **ReadValue()** and **WriteValue()**
>> but either method can use long procedures when supported.
>> +
>> +string PreferredNotifyType [readwrite, optional, experimental]
>> +``````````````````````````````````````````````````````````````
>> +
>> +Selects whether **StartNotify()** and **AcquireNotify()** enable notifications
>> +or indications when the characteristic supports both. Only present when both
>> +"notify" and "indicate" flags are set.
>> +
>> +Possible values:
>> +
>> +:"notification":
>> +
>> + Enable notifications (CCC = 0x0001). Default.
>> +
>> +:"indication":
>> +
>> + Enable indications (CCC = 0x0002).
>> +
>> +Note: the preference applies on the next CCC write. If another client has
>> +already enabled the CCC on this characteristic, the existing setting is kept
>> +and the new preference takes effect only after the last subscriber stops.
> Well the spec seems to have changed to allow setting both notify and
> indicate simultaneously as well:
>
> If both the Notification and Indication bits are set, then the server
> shall use the notification procedure (see Section 4.10) when an
> acknowledgment is not required by a higher-layer specification or
> shall use the indication procedure (see Section 4.11) when an
> acknowledgment is required. The server should not use both procedures
> to send the same characteristic value.
>
> So perhaps we need to handle that as well, that said I don't know if
> it wouldn't be more efficient to add another method which would enable
> passing the value directly rather modifying the
> StartNotify/AcquireNotify behavior, but then we would need to create a
> different interface name in order to break the existing methods, so
> maybe going wit this is better and we just need to handle 0x0003 as
> being both enabled and the server decides what to do with it.
>
>> diff --git a/src/gatt-client.c b/src/gatt-client.c
>> index 3baf95c4f..29564a87d 100644
>> --- a/src/gatt-client.c
>> +++ b/src/gatt-client.c
>> @@ -115,6 +115,7 @@ struct characteristic {
>> struct queue *descs;
>>
>> bool notifying;
>> + bool prefer_indicate;
>> struct queue *notify_clients;
>> };
>>
>> @@ -1595,6 +1596,9 @@ static DBusMessage *characteristic_acquire_notify(DBusConnection *conn,
>> if (!client)
>> return btd_error_failed(msg, "Failed allocate notify session");
>>
>> + bt_gatt_client_set_notify_prefer_indicate(gatt, chrc->value_handle,
>> + chrc->prefer_indicate);
>> +
>> client->notify_id = bt_gatt_client_register_notify(gatt,
>> chrc->value_handle,
>> register_notify_io_cb,
>> @@ -1673,6 +1677,9 @@ static DBusMessage *characteristic_start_notify(DBusConnection *conn,
>>
>> op = async_dbus_op_new(msg, client);
>>
>> + bt_gatt_client_set_notify_prefer_indicate(gatt, chrc->value_handle,
>> + chrc->prefer_indicate);
>> +
>> client->notify_id = bt_gatt_client_register_notify(gatt,
>> chrc->value_handle,
>> register_notify_cb, notify_cb,
>> @@ -1719,6 +1726,76 @@ static DBusMessage *characteristic_stop_notify(DBusConnection *conn,
>> return dbus_message_new_method_return(msg);
>> }
>>
>> +static gboolean
>> +characteristic_get_prefer_notify_type(const GDBusPropertyTable *property,
>> + DBusMessageIter *iter, void *data)
>> +{
>> + struct characteristic *chrc = data;
>> + const char *str = chrc->prefer_indicate ? "indication" : "notification";
>> +
>> + dbus_message_iter_append_basic(iter, DBUS_TYPE_STRING, &str);
>> +
>> + return TRUE;
>> +}
>> +
>> +static void
>> +characteristic_set_prefer_notify_type(const GDBusPropertyTable *property,
>> + DBusMessageIter *iter,
>> + GDBusPendingPropertySet id, void *data)
>> +{
>> + struct characteristic *chrc = data;
>> + struct bt_gatt_client *gatt = chrc->service->client->gatt;
>> + const char *str;
>> + bool prefer;
>> +
>> + if (dbus_message_iter_get_arg_type(iter) != DBUS_TYPE_STRING) {
>> + g_dbus_pending_property_error(id,
>> + ERROR_INTERFACE ".InvalidArguments",
>> + "Invalid arguments in method call");
>> + return;
>> + }
>> +
>> + dbus_message_iter_get_basic(iter, &str);
>> +
>> + if (!strcmp(str, "notification"))
>> + prefer = false;
>> + else if (!strcmp(str, "indication"))
>> + prefer = true;
>> + else {
>> + g_dbus_pending_property_error(id,
>> + ERROR_INTERFACE ".InvalidArguments",
>> + "Invalid arguments in method call");
>> + return;
>> + }
>> +
>> + if (chrc->prefer_indicate == prefer) {
>> + g_dbus_pending_property_success(id);
>> + return;
>> + }
>> +
>> + chrc->prefer_indicate = prefer;
>> +
>> + if (gatt)
>> + bt_gatt_client_set_notify_prefer_indicate(gatt,
>> + chrc->value_handle, prefer);
>> +
>> + g_dbus_emit_property_changed(btd_get_dbus_connection(), chrc->path,
>> + GATT_CHARACTERISTIC_IFACE,
>> + "PreferredNotifyType");
>> +
>> + g_dbus_pending_property_success(id);
>> +}
>> +
>> +static gboolean
>> +characteristic_prefer_notify_type_exists(const GDBusPropertyTable *property,
>> + void *data)
>> +{
>> + struct characteristic *chrc = data;
>> +
>> + return (chrc->props & BT_GATT_CHRC_PROP_NOTIFY) &&
>> + (chrc->props & BT_GATT_CHRC_PROP_INDICATE);
>> +}
>> +
>> static const GDBusPropertyTable characteristic_properties[] = {
>> { "Handle", "q", characteristic_get_handle },
>> { "UUID", "s", characteristic_get_uuid, NULL, NULL },
>> @@ -1733,6 +1810,10 @@ static const GDBusPropertyTable characteristic_properties[] = {
>> { "NotifyAcquired", "b", characteristic_get_notify_acquired, NULL,
>> characteristic_notify_acquired_exists },
>> { "MTU", "q", characteristic_get_mtu, NULL, characteristic_mtu_exists },
>> + { "PreferredNotifyType", "s", characteristic_get_prefer_notify_type,
>> + characteristic_set_prefer_notify_type,
>> + characteristic_prefer_notify_type_exists,
>> + G_DBUS_PROPERTY_FLAG_EXPERIMENTAL },
>> { }
>> };
>>
>> @@ -2282,6 +2363,10 @@ static void register_notify(void *data, void *user_data)
>> op = new0(struct async_dbus_op, 1);
>> op->data = notify_client;
>>
>> + bt_gatt_client_set_notify_prefer_indicate(client->gatt,
>> + notify_client->chrc->value_handle,
>> + notify_client->chrc->prefer_indicate);
>> +
>> notify_client->notify_id = bt_gatt_client_register_notify(client->gatt,
>> notify_client->chrc->value_handle,
>> register_notify_cb, notify_cb,
>> diff --git a/src/shared/gatt-client.c b/src/shared/gatt-client.c
>> index a6abe8ac2..403d22758 100644
>> --- a/src/shared/gatt-client.c
>> +++ b/src/shared/gatt-client.c
>> @@ -217,6 +217,7 @@ struct notify_chrc {
>> uint16_t properties;
>> unsigned int notify_id;
>> int notify_count; /* Reference count of registered notify callbacks */
>> + bool prefer_indicate;
>>
>> /* Pending calls to register_notify are queued here so that they can be
>> * processed after a write that modifies the CCC descriptor.
>> @@ -1671,9 +1672,13 @@ static bool notify_data_write_ccc(struct notify_data *notify_data, bool enable,
>>
>> if (enable) {
>> /* Try to enable notifications or indications based on
>> - * whatever the characteristic supports.
>> + * whatever the characteristic supports. If both are
>> + * available honor the per-chrc prefer_indicate flag.
>> */
>> - if (properties & BT_GATT_CHRC_PROP_NOTIFY)
>> + if (notify_data->chrc->prefer_indicate &&
>> + (properties & BT_GATT_CHRC_PROP_INDICATE))
>> + value = cpu_to_le16(0x0002);
>> + else if (properties & BT_GATT_CHRC_PROP_NOTIFY)
>> value = cpu_to_le16(0x0001);
>> else if (properties & BT_GATT_CHRC_PROP_INDICATE)
>> value = cpu_to_le16(0x0002);
>> @@ -3838,6 +3843,28 @@ unsigned int bt_gatt_client_register_notify(struct bt_gatt_client *client,
>> user_data, destroy);
>> }
>>
>> +bool bt_gatt_client_set_notify_prefer_indicate(struct bt_gatt_client *client,
>> + uint16_t value_handle,
>> + bool prefer)
>> +{
>> + struct notify_chrc *chrc;
>> +
>> + if (!client || !client->db || !value_handle)
>> + return false;
>> +
>> + chrc = queue_find(client->notify_chrcs, match_notify_chrc_value_handle,
>> + UINT_TO_PTR(value_handle));
>> + if (!chrc) {
>> + chrc = notify_chrc_create(client, value_handle);
>> + if (!chrc)
>> + return false;
>> + }
>> +
>> + chrc->prefer_indicate = prefer;
>> +
>> + return true;
>> +}
>> +
>> bool bt_gatt_client_unregister_notify(struct bt_gatt_client *client,
>> unsigned int id)
>> {
>> diff --git a/src/shared/gatt-client.h b/src/shared/gatt-client.h
>> index 63cf99500..0d08f8014 100644
>> --- a/src/shared/gatt-client.h
>> +++ b/src/shared/gatt-client.h
>> @@ -124,6 +124,9 @@ unsigned int bt_gatt_client_register_notify(struct bt_gatt_client *client,
>> bt_gatt_client_destroy_func_t destroy);
>> bool bt_gatt_client_unregister_notify(struct bt_gatt_client *client,
>> unsigned int id);
>> +bool bt_gatt_client_set_notify_prefer_indicate(struct bt_gatt_client *client,
>> + uint16_t value_handle,
>> + bool prefer);
>>
>> bool bt_gatt_client_set_security(struct bt_gatt_client *client, int level);
>> int bt_gatt_client_get_security(struct bt_gatt_client *client);
>> --
>> 2.43.0
>>
>>
>
^ permalink raw reply
* [PATCH BlueZ 2/2] gatt-database: Prefer notifications over indications
From: Simon Mikuda @ 2026-06-14 10:29 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Simon Mikuda
In-Reply-To: <CABBYNZL-A=NpnfiO9GO66TNX5QaEuvpSZ9fuBk0Jo+aNtr7huA@mail.gmail.com>
When both notifications and indications are enabled (CCC value=0x0003)
we will send notifications by default.
---
src/gatt-database.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gatt-database.c b/src/gatt-database.c
index 680a52952..dfa83b31a 100644
--- a/src/gatt-database.c
+++ b/src/gatt-database.c
@@ -1446,7 +1446,7 @@ static void send_notification_to_device(void *data, void *user_data)
* TODO: If the device is not connected but bonded, send the
* notification/indication when it becomes connected.
*/
- if (!(ccc->value & 0x0002)) {
+ if (ccc->value & 0x0001) {
DBG("GATT server sending notification");
bt_gatt_server_send_notification(server,
notify->handle, notify->value,
--
2.43.0
^ permalink raw reply related
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