Linux bluetooth development
 help / color / mirror / Atom feed
* RE: [BlueZ,v2,1/3] audio: Add ability to force CIS transport Links property
From: bluez.test.bot @ 2026-04-23  9:11 UTC (permalink / raw)
  To: linux-bluetooth, frederic.danis
In-Reply-To: <20260423075309.493820-1-frederic.danis@collabora.com>

[-- Attachment #1: Type: text/plain, Size: 2545 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=1084559

---Test result---

Test Summary:
CheckPatch                    FAIL      1.65 seconds
GitLint                       FAIL      1.02 seconds
BuildEll                      PASS      20.80 seconds
BluezMake                     PASS      660.92 seconds
MakeCheck                     PASS      19.20 seconds
MakeDistcheck                 PASS      248.30 seconds
CheckValgrind                 PASS      297.58 seconds
CheckSmatch                   PASS      352.78 seconds
bluezmakeextell               PASS      183.93 seconds
IncrementalBuild              PASS      654.86 seconds
ScanBuild                     PASS      1020.42 seconds

Details
##############################
Test: CheckPatch - FAIL
Desc: Run checkpatch.pl script
Output:
[BlueZ,v2,1/3] audio: Add ability to force CIS transport Links property
WARNING:BLOCK_COMMENT_STYLE: Block comments use a trailing */ on a separate line
#109: FILE: profiles/audio/bap.c:2672:
+	 * by bap_stream_set_io() */

/github/workspace/src/patch/14534951.patch total: 0 errors, 1 warnings, 204 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/14534951.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: GitLint - FAIL
Desc: Run gitlint
Output:
[BlueZ,v2,1/3] audio: Add ability to force CIS transport Links property

WARNING: I3 - ignore-body-lines: gitlint will be switching from using Python regex 'match' (match beginning) to 'search' (match anywhere) semantics. Please review your ignore-body-lines.regex option accordingly. To remove this warning, set general.regex-style-search=True. More details: https://jorisroovers.github.io/gitlint/configuration/#regex-style-search
15: B2 Line has trailing whitespace: "    before passing the connect event to all streams belonging to same "


https://github.com/bluez/bluez/pull/2064

---
Regards,
Linux Bluetooth


^ permalink raw reply

* [bluez/bluez] f8f43f: audio: Add ability to force CIS transport Links pr...
From: fdanis-oss @ 2026-04-23  8:13 UTC (permalink / raw)
  To: linux-bluetooth

  Branch: refs/heads/1084559
  Home:   https://github.com/bluez/bluez
  Commit: f8f43f9bcd6f3507e7e258fb7abeda0e43168a16
      https://github.com/bluez/bluez/commit/f8f43f9bcd6f3507e7e258fb7abeda0e43168a16
  Author: Frédéric Danis <frederic.danis@collabora.com>
  Date:   2026-04-23 (Thu, 23 Apr 2026)

  Changed paths:
    M profiles/audio/bap.c
    M profiles/audio/transport.c

  Log Message:
  -----------
  audio: Add ability to force CIS transport Links property

If bluetoothd is started in testing mode the Links property for CIS
is readwrite and can be used to force transport objects Links.
This can used to unlink transport objects by sending an empty array.

For unlinked transport objects, each transports needs to be acquired
separately.

This allows to pass PTS tests BAP/UCL/STR/BV-543-C and BV-546-C.


  Commit: 7bd76e0b3708985aade4e5db8457142e19a973fc
      https://github.com/bluez/bluez/commit/7bd76e0b3708985aade4e5db8457142e19a973fc
  Author: Frédéric Danis <frederic.danis@collabora.com>
  Date:   2026-04-23 (Thu, 23 Apr 2026)

  Changed paths:
    M doc/org.bluez.MediaTransport.rst

  Log Message:
  -----------
  doc: Add documentation for readwrite CIS transport Links property

This is only supported when bluetoothd is started in testing mode.


  Commit: f44f8c555c8b923e7b8f1c01b71a9e68a79477b2
      https://github.com/bluez/bluez/commit/f44f8c555c8b923e7b8f1c01b71a9e68a79477b2
  Author: Frédéric Danis <frederic.danis@collabora.com>
  Date:   2026-04-23 (Thu, 23 Apr 2026)

  Changed paths:
    M client/player.c

  Log Message:
  -----------
  client/player: Add support to unlink transports

This is used to pass PTS tests BAP/UCL/STR/BV-543-C and BV-546-C.


Compare: https://github.com/bluez/bluez/compare/f8f43f9bcd6f%5E...f44f8c555c8b

To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications

^ permalink raw reply

* [PATCH BlueZ v2 1/3] audio: Add ability to force CIS transport Links property
From: Frédéric Danis @ 2026-04-23  7:53 UTC (permalink / raw)
  To: linux-bluetooth

If bluetoothd is started in testing mode the Links property for CIS
is readwrite and can be used to force transport objects Links.
This can used to unlink transport objects by sending an empty array.

For unlinked transport objects, each transports needs to be acquired
separately.

This allows to pass PTS tests BAP/UCL/STR/BV-543-C and BV-546-C.
---
v1 -> v2:
  - Add testing mode check in bap_connect_io_cb()
  - Replace stream state check by checking that the stream is not linked
    before passing the connect event to all streams belonging to same 
    CIG/CIS.

 profiles/audio/bap.c       | 46 ++++++++++++++++++++++++++++++
 profiles/audio/transport.c | 57 +++++++++++++++++++++++++++++++-------
 2 files changed, 95 insertions(+), 10 deletions(-)

diff --git a/profiles/audio/bap.c b/profiles/audio/bap.c
index 5333267f7..e20456436 100644
--- a/profiles/audio/bap.c
+++ b/profiles/audio/bap.c
@@ -2655,13 +2655,61 @@ static void bap_connect_bcast_io_cb(GIOChannel *chan, GError *err,
 	iso_connect_bcast_cb(chan, err, setup->stream);
 }
 
+struct connect_io_data {
+	GIOChannel *chan;
+	GError *err;
+	uint8_t cig_id;
+	uint8_t cis_id;
+};
+
+static void connect_stream(void *data, void *user_data)
+{
+	struct bap_setup *setup = data;
+	struct connect_io_data *d = user_data;
+	uint8_t state;
+
+	/* Check stream state to only pass the connect event managed
+	 * by bap_stream_set_io() */
+	state = bt_bap_stream_get_state(setup->stream);
+	if ((state == BT_BAP_STREAM_STATE_ENABLING ||
+			state == BT_BAP_STREAM_STATE_DISABLING) &&
+			setup->qos.ucast.cig_id == d->cig_id &&
+			setup->qos.ucast.cis_id == d->cis_id)
+		iso_connect_cb(d->chan, d->err, setup->stream);
+}
+
+static void connect_ep(void *data, void *user_data)
+{
+	struct bap_ep *ep = data;
+
+	if (ep->setups)
+		queue_foreach(ep->setups, connect_stream, user_data);
+}
+
 static void bap_connect_io_cb(GIOChannel *chan, GError *err, gpointer user_data)
 {
 	struct bap_setup *setup = user_data;
+	struct connect_io_data data;
 
 	if (!setup->stream)
 		return;
 
+	if (queue_isempty(bt_bap_stream_io_get_links(setup->stream)) &&
+		btd_opts.testing) {
+		/* The stream may have manually been unliked for PTS tests,
+		 * e.g. BAP/UCL/STR/BV-543-C or BAP/UCL/STR/BV-546-C,
+		 * in this case send the connect event to all streams
+		 * belonging to the same CIG/CIS.
+		 */
+		data.chan = chan;
+		data.err = err;
+		data.cig_id = setup->qos.ucast.cig_id;
+		data.cis_id = setup->qos.ucast.cis_id;
+		queue_foreach(setup->ep->data->snks, connect_ep, &data);
+		queue_foreach(setup->ep->data->srcs, connect_ep, &data);
+		return;
+	}
+
 	iso_connect_cb(chan, err, setup->stream);
 }
 
diff --git a/profiles/audio/transport.c b/profiles/audio/transport.c
index 5c2a2777e..b6a5dd1fd 100644
--- a/profiles/audio/transport.c
+++ b/profiles/audio/transport.c
@@ -37,6 +37,7 @@
 #include "src/shared/bap.h"
 #include "src/shared/bass.h"
 #include "src/shared/io.h"
+#include "src/btd.h"
 
 #ifdef HAVE_A2DP
 #include "avdtp.h"
@@ -114,6 +115,7 @@ struct bap_transport {
 struct media_transport_ops {
 	const char *uuid;
 	const GDBusPropertyTable *properties;
+	const GDBusPropertyTable *test_properties;
 	void (*set_owner)(struct media_transport *transport,
 				struct media_owner *owner);
 	void (*remove_owner)(struct media_transport *transport,
@@ -1419,6 +1421,9 @@ static struct media_transport *find_transport_by_path(const char *path)
 	return NULL;
 }
 
+static void bap_update_links(const struct media_transport *transport);
+static void transport_unlink(void *data, void *user_data);
+
 static void set_links(const GDBusPropertyTable *property,
 				DBusMessageIter *iter,
 				GDBusPendingPropertySet id, void *user_data)
@@ -1436,6 +1441,16 @@ static void set_links(const GDBusPropertyTable *property,
 
 	dbus_message_iter_recurse(iter, &array);
 
+	if (dbus_message_iter_get_arg_type(&array) == DBUS_TYPE_INVALID) {
+		struct queue *links = bt_bap_stream_io_get_links(bap->stream);
+
+		/* Unlink stream from all its links */
+		queue_foreach(links, transport_unlink, bap->stream);
+
+		bt_bap_stream_io_unlink(bap->stream, NULL);
+		bap_update_links(transport);
+	}
+
 	while (dbus_message_iter_get_arg_type(&array) ==
 						DBUS_TYPE_OBJECT_PATH) {
 		struct media_transport *link;
@@ -1486,6 +1501,21 @@ static const GDBusPropertyTable transport_bap_uc_properties[] = {
 	{ }
 };
 
+static const GDBusPropertyTable transport_bap_uc_test_properties[] = {
+	{ "Device", "o", get_device },
+	{ "UUID", "s", get_uuid },
+	{ "Codec", "y", get_codec },
+	{ "Configuration", "ay", get_configuration },
+	{ "State", "s", get_state },
+	{ "QoS", "a{sv}", get_ucast_qos, NULL, qos_ucast_exists },
+	{ "Endpoint", "o", get_endpoint, NULL, endpoint_exists },
+	{ "Location", "u", get_location },
+	{ "Metadata", "ay", get_metadata, set_metadata },
+	{ "Links", "ao", get_links, set_links, links_exists },
+	{ "Volume", "q", get_volume, set_volume, volume_exists },
+	{ }
+};
+
 static gboolean get_bcast_qos(const GDBusPropertyTable *property,
 					DBusMessageIter *iter, void *data)
 {
@@ -1884,8 +1914,6 @@ static void bap_resume_complete(struct media_transport *transport)
 	transport_set_state(transport, TRANSPORT_STATE_ACTIVE);
 }
 
-static void bap_update_links(const struct media_transport *transport);
-
 static bool match_link_transport(const void *data, const void *user_data)
 {
 	const struct bt_bap_stream *stream = data;
@@ -2540,10 +2568,11 @@ static void *transport_asha_init(struct media_transport *transport, void *data)
 #define TRANSPORT_OPS(_uuid, _props, _set_owner, _remove_owner, _init, \
 		      _resume, _suspend, _cancel, _set_state, _get_stream, \
 		      _get_volume, _set_volume, _set_delay, _update_links, \
-		      _destroy) \
+		      _destroy, _test_props) \
 { \
 	.uuid = _uuid, \
 	.properties = _props, \
+	.test_properties = _test_props, \
 	.set_owner = _set_owner, \
 	.remove_owner = _remove_owner, \
 	.init = _init, \
@@ -2565,26 +2594,28 @@ static void *transport_asha_init(struct media_transport *transport, void *data)
 			transport_a2dp_resume, transport_a2dp_suspend, \
 			transport_a2dp_cancel, NULL, \
 			transport_a2dp_get_stream, transport_a2dp_get_volume, \
-			_set_volume, _set_delay, NULL, _destroy)
+			_set_volume, _set_delay, NULL, _destroy, NULL)
 
 #define BAP_OPS(_uuid, _props, _set_owner, _remove_owner, _update_links, \
-		_set_state) \
+		_set_state, _test_props) \
 	TRANSPORT_OPS(_uuid, _props, _set_owner, _remove_owner,\
 			transport_bap_init, \
 			transport_bap_resume, transport_bap_suspend, \
 			transport_bap_cancel, _set_state, \
 			transport_bap_get_stream, transport_bap_get_volume, \
 			transport_bap_set_volume, NULL, \
-			_update_links, transport_bap_destroy)
+			_update_links, transport_bap_destroy, _test_props)
 
 #define BAP_UC_OPS(_uuid) \
 	BAP_OPS(_uuid, transport_bap_uc_properties, \
 			transport_bap_set_owner, transport_bap_remove_owner, \
-			transport_bap_update_links_uc, transport_bap_set_state)
+			transport_bap_update_links_uc, \
+			transport_bap_set_state, \
+			transport_bap_uc_test_properties)
 
 #define BAP_BC_OPS(_uuid) \
 	BAP_OPS(_uuid, transport_bap_bc_properties, NULL, NULL, \
-			transport_bap_update_links_bc, NULL)
+			transport_bap_update_links_bc, NULL, NULL)
 
 #define ASHA_OPS(_uuid) \
 	TRANSPORT_OPS(_uuid, transport_asha_properties, NULL, NULL, \
@@ -2592,7 +2623,7 @@ static void *transport_asha_init(struct media_transport *transport, void *data)
 			transport_asha_resume, transport_asha_suspend, \
 			transport_asha_cancel, NULL, NULL, \
 			transport_asha_get_volume, transport_asha_set_volume, \
-			NULL, NULL, NULL)
+			NULL, NULL, NULL, NULL)
 
 static const struct media_transport_ops transport_ops[] = {
 #ifdef HAVE_A2DP
@@ -2647,6 +2678,7 @@ struct media_transport *media_transport_create(struct btd_device *device,
 	struct media_transport *transport;
 	const struct media_transport_ops *ops;
 	int fd;
+	const GDBusPropertyTable *properties;
 
 	transport = g_new0(struct media_transport, 1);
 	if (device)
@@ -2701,9 +2733,14 @@ struct media_transport *media_transport_create(struct btd_device *device,
 			goto fail;
 	}
 
+	if (btd_opts.testing && ops->test_properties)
+		properties = ops->test_properties;
+	else
+		properties = ops->properties;
+
 	if (g_dbus_register_interface(btd_get_dbus_connection(),
 				transport->path, MEDIA_TRANSPORT_INTERFACE,
-				transport_methods, NULL, ops->properties,
+				transport_methods, NULL, properties,
 				transport, media_transport_free) == FALSE) {
 		error("Could not register transport %s", transport->path);
 		goto fail;
-- 
2.43.0


^ permalink raw reply related

* [PATCH BlueZ v2 3/3] client/player: Add support to unlink transports
From: Frédéric Danis @ 2026-04-23  7:53 UTC (permalink / raw)
  To: linux-bluetooth
In-Reply-To: <20260423075309.493820-1-frederic.danis@collabora.com>

This is used to pass PTS tests BAP/UCL/STR/BV-543-C and BV-546-C.
---
 client/player.c | 57 ++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 56 insertions(+), 1 deletion(-)

diff --git a/client/player.c b/client/player.c
index 1444e939d..e3bd28fea 100644
--- a/client/player.c
+++ b/client/player.c
@@ -5003,6 +5003,9 @@ static bool transport_recv(struct io *io, void *user_data)
 static void transport_new(GDBusProxy *proxy, int sk, uint16_t mtu[2])
 {
 	struct transport *transport;
+	DBusMessageIter iter;
+	const char *uuid;
+	bool reader = true;
 
 	transport = new0(struct transport, 1);
 	transport->proxy = proxy;
@@ -5014,7 +5017,23 @@ static void transport_new(GDBusProxy *proxy, int sk, uint16_t mtu[2])
 
 	io_set_disconnect_handler(transport->io, transport_disconnected,
 							transport, NULL);
-	io_set_read_handler(transport->io, transport_recv, transport, NULL);
+
+	if (!g_dbus_proxy_get_property(proxy, "UUID", &iter))
+		return;
+
+	dbus_message_iter_get_basic(&iter, &uuid);
+
+	/* For BAP testing, streams may have been manually unlinked.
+	 * In this case source and sink streams are acquired separately and
+	 * read handler should not be started for source local endpoint.
+	 */
+	if (!g_dbus_proxy_get_property(proxy, "Links", &iter) &&
+			!strcmp(uuid, PAC_SOURCE_UUID))
+		reader = false;
+
+	if (reader)
+		io_set_read_handler(transport->io, transport_recv, transport,
+									NULL);
 
 	if (!ios)
 		ios = queue_new();
@@ -6091,6 +6110,39 @@ static void cmd_metadata_transport(int argc, char *argv[])
 	}
 }
 
+static void unlink_cb(const DBusError *error, void *user_data)
+{
+	if (dbus_error_is_set(error)) {
+		bt_shell_printf("Failed to unlink: %s\n", error->name);
+		return bt_shell_noninteractive_quit(EXIT_FAILURE);
+	}
+
+	bt_shell_printf("Unlink succeeded\n");
+
+	return bt_shell_noninteractive_quit(EXIT_SUCCESS);
+}
+
+static void cmd_unlink_transport(int argc, char *argv[])
+{
+	GDBusProxy *proxy;
+	char *value[0];
+
+	proxy = g_dbus_proxy_lookup(transports, NULL, argv[1],
+					BLUEZ_MEDIA_TRANSPORT_INTERFACE);
+	if (!proxy) {
+		bt_shell_printf("Transport %s not found\n", argv[1]);
+		return bt_shell_noninteractive_quit(EXIT_FAILURE);
+	}
+
+	if (g_dbus_proxy_set_property_array(proxy, "Links",
+				DBUS_TYPE_OBJECT_PATH,
+				value, 0, unlink_cb,
+				NULL, NULL) == FALSE) {
+		bt_shell_printf("Failed to unlink transport\n");
+		return bt_shell_noninteractive_quit(EXIT_FAILURE);
+	}
+}
+
 static const struct bt_shell_menu transport_menu = {
 	.name = "transport",
 	.desc = "Media Transport Submenu",
@@ -6126,6 +6178,9 @@ static const struct bt_shell_menu transport_menu = {
 	{ "metadata",    "<transport> [value...]", cmd_metadata_transport,
 						"Get/Set Transport Metadata",
 						transport_generator },
+	{ "unlink",      "<transport>", cmd_unlink_transport,
+						"Unlink Transport",
+						transport_generator },
 	{} },
 };
 
-- 
2.43.0


^ permalink raw reply related

* [PATCH BlueZ v2 2/3] doc: Add documentation for readwrite CIS transport Links property
From: Frédéric Danis @ 2026-04-23  7:53 UTC (permalink / raw)
  To: linux-bluetooth
In-Reply-To: <20260423075309.493820-1-frederic.danis@collabora.com>

This is only supported when bluetoothd is started in testing mode.
---
 doc/org.bluez.MediaTransport.rst | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/doc/org.bluez.MediaTransport.rst b/doc/org.bluez.MediaTransport.rst
index 81cf9e4da..fe69f948b 100644
--- a/doc/org.bluez.MediaTransport.rst
+++ b/doc/org.bluez.MediaTransport.rst
@@ -180,6 +180,11 @@ array{object} Links [readonly, optional, CIS only, experimental]
 
 Linked transport objects which the transport is associated with.
 
+If D-Bus testing interfaces as been enabled this property is readwrite.
+
+This can be used to manually unlink transport objects by sending empty array.
+Then, each link needs be acquired separately.
+
 array{object} Links [readwrite, BIS only, experimental]
 ```````````````````````````````````````````````````````
 
-- 
2.43.0


^ permalink raw reply related

* [RFC PATCH] net: skb: on zero-copy formatted output to skb
From: Dmitry Antipov @ 2026-04-23  7:36 UTC (permalink / raw)
  To: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni
  Cc: netdev, linux-bluetooth, Dmitry Antipov

Some code, most notably the Bluetooth drivers, uses something like
the following:

char buf[80];
snprintf(buf, sizeof(buf), "Driver: %s\n", driver_name);
skb_put_data(skb, buf, strlen(buf));

This looks suboptimal at least because:

1) It yields in BUG() just in case the developer underestimates
   the size of an skb being used;
2) It requires extra data copy from an external buffer;
3) It uses 'strlen()' redundantly because actual data length
   is calculated by 'snprintf()' itself.

So introduce 'skb_printf()' which aims to address all of these
issues. As usual, thoughts and comments are highly appreciated.

Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
---
 include/linux/skbuff.h |  1 +
 net/core/skbuff.c      | 18 ++++++++++++++++++
 2 files changed, 19 insertions(+)

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 2bcf78a4de7b..fb4ef55a8f86 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -4292,6 +4292,7 @@ int skb_mpls_update_lse(struct sk_buff *skb, __be32 mpls_lse);
 int skb_mpls_dec_ttl(struct sk_buff *skb);
 struct sk_buff *pskb_extract(struct sk_buff *skb, int off, int to_copy,
 			     gfp_t gfp);
+int skb_printf(struct sk_buff *skb, const char *fmt, ...);
 
 static inline int memcpy_from_msg(void *data, struct msghdr *msg, int len)
 {
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 7dad68e3b518..051ab4f28c75 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -6992,6 +6992,24 @@ struct sk_buff *pskb_extract(struct sk_buff *skb, int off,
 }
 EXPORT_SYMBOL(pskb_extract);
 
+int skb_printf(struct sk_buff *skb, const char *fmt, ...)
+{
+	int len, size = skb_availroom(skb);
+	va_list args;
+
+	va_start(args, fmt);
+	len = vsnprintf(skb_tail_pointer(skb), size, fmt, args);
+	va_end(args);
+
+	if (unlikely(len >= size))
+		return -ENOSPC;
+
+	skb->tail += len;
+	skb->len += len;
+	return len;
+}
+EXPORT_SYMBOL(skb_printf);
+
 /**
  * skb_condense - try to get rid of fragments/frag_list if possible
  * @skb: buffer
-- 
2.53.0


^ permalink raw reply related

* Re: [BlueZ,v2] sixaxis: Fix pairing Esperanza EGG109k controller
From: Marek Czerski @ 2026-04-23  7:05 UTC (permalink / raw)
  To: linux-bluetooth
In-Reply-To: <69e949b0.d40a0220.217dff.c3a9@mx.google.com>

> WARNING: I3 - ignore-body-lines: gitlint will be switching from using Python regex 'match' (match beginning) to 'search' (match anywhere) semantics. Please review your ignore-body-lines.regex option accordingly. To remove this warning, set general.regex-style-search=True. More details: https://jorisroovers.github.io/gitlint/configuration/#regex-style-search
> 11: B1 Line exceeds max length (84>80): "https://esperanza.pl/esperanza-gamepad-bezprzewodowy-ps3-marine-czarny,176,1701.html"


Should I split the link in commit message into two lines ?

^ permalink raw reply

* Re: Bluetooth: Use AES-CMAC library API
From: Eric Biggers @ 2026-04-22 23:02 UTC (permalink / raw)
  To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <CABBYNZJHdfByt_Tg7WV2S-fZ9xxJYVH4MyBxT3MGTNkbX5f4rA@mail.gmail.com>

On Wed, Apr 22, 2026 at 11:11:25AM -0400, Luiz Augusto von Dentz wrote:
> > net/bluetooth/smp.c:25:10: fatal error: crypto/aes-cbc-macs.h: No such file or directory
> >    25 | #include <crypto/aes-cbc-macs.h>
> >       |          ^~~~~~~~~~~~~~~~~~~~~~~
> 
> I guess this is expected since rc1 wasn't tagged yet, right? In that
> case we will probably need to rebase once rc1 is tagged to integrate
> these changes.

Well, the bluez.test.bot seems to have ignored the
"base-commit: d46dd0d88341e45f8e0226fdef5462f5270898fc" and applied the
series to something a bit older.  In that case, yes this is expected.
Once the bluetooth branch has been updated to v7.1-rc1 or another commit
that has the prerequisite, this can be applied.  Thanks,

- Eric

^ permalink raw reply

* RE: [BlueZ,v2] sixaxis: Fix pairing Esperanza EGG109k controller
From: bluez.test.bot @ 2026-04-22 22:20 UTC (permalink / raw)
  To: linux-bluetooth, ma.czerski
In-Reply-To: <20260422212045.1325603-1-ma.czerski@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2421 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=1084434

---Test result---

Test Summary:
CheckPatch                    FAIL      1.76 seconds
GitLint                       FAIL      4.05 seconds
BuildEll                      PASS      20.38 seconds
BluezMake                     PASS      655.42 seconds
CheckSmatch                   PASS      347.82 seconds
bluezmakeextell               PASS      179.48 seconds
IncrementalBuild              PASS      647.34 seconds
ScanBuild                     PASS      1012.64 seconds

Details
##############################
Test: CheckPatch - FAIL
Desc: Run checkpatch.pl script
Output:
[BlueZ,v2] sixaxis: Fix pairing Esperanza EGG109k controller
WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line)
#107: 
https://esperanza.pl/esperanza-gamepad-bezprzewodowy-ps3-marine-czarny,176,1701.html

/github/workspace/src/patch/14534484.patch total: 0 errors, 1 warnings, 37 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/14534484.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: GitLint - FAIL
Desc: Run gitlint
Output:
[BlueZ,v2] sixaxis: Fix pairing Esperanza EGG109k controller

WARNING: I3 - ignore-body-lines: gitlint will be switching from using Python regex 'match' (match beginning) to 'search' (match anywhere) semantics. Please review your ignore-body-lines.regex option accordingly. To remove this warning, set general.regex-style-search=True. More details: https://jorisroovers.github.io/gitlint/configuration/#regex-style-search
11: B1 Line exceeds max length (84>80): "https://esperanza.pl/esperanza-gamepad-bezprzewodowy-ps3-marine-czarny,176,1701.html"


https://github.com/bluez/bluez/pull/2063

---
Regards,
Linux Bluetooth


^ permalink raw reply

* Re: [PATCH v1] mediatek MT7925: update bluetooth firmware to 20260414153243
From: David Ruth @ 2026-04-22 22:17 UTC (permalink / raw)
  To: Chris Lu (陸稚泓)
  Cc: ben, dwmw2, johan.hedberg, jwboyer, linux-bluetooth,
	linux-firmware, linux-kernel, linux-mediatek, marcel, ss.wu,
	steve.lee, will-cy.Lee

Tested-by: David Ruth <druth@chromium.org>

^ permalink raw reply

* RE: Bluetooth: btusb: Add Mercusys MA530 for Realtek RTL8761BUV
From: bluez.test.bot @ 2026-04-22 22:11 UTC (permalink / raw)
  To: linux-bluetooth, hrvoje.nuic
In-Reply-To: <20260422212647.62497-1-hrvoje.nuic@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 882 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=1084436

---Test result---

Test Summary:
CheckPatch                    PASS      0.66 seconds
GitLint                       PASS      0.29 seconds
SubjectPrefix                 PASS      2.64 seconds
BuildKernel                   PASS      26.85 seconds
CheckAllWarning               PASS      28.89 seconds
CheckSparse                   PASS      27.85 seconds
BuildKernel32                 PASS      25.61 seconds
TestRunnerSetup               PASS      570.65 seconds
IncrementalBuild              PASS      25.30 seconds



https://github.com/bluez/bluetooth-next/pull/116

---
Regards,
Linux Bluetooth


^ permalink raw reply

* [bluez/bluez] e0de29: sixaxis: Fix pairing Esperanza EGG109k controller
From: Marek Czerski @ 2026-04-22 21:31 UTC (permalink / raw)
  To: linux-bluetooth

  Branch: refs/heads/1084434
  Home:   https://github.com/bluez/bluez
  Commit: e0de2926e912fdcb559946777acc5289ad27380d
      https://github.com/bluez/bluez/commit/e0de2926e912fdcb559946777acc5289ad27380d
  Author: Marek Czerski <ma.czerski@gmail.com>
  Date:   2026-04-22 (Wed, 22 Apr 2026)

  Changed paths:
    M plugins/sixaxis.c

  Log Message:
  -----------
  sixaxis: Fix pairing Esperanza EGG109k controller

This change is required for Esperanza EGG109k ps controller clone.
EGG109k looks like PS3 controller but presents itself to the system
as PS4 controller. It does not respond to 0x81 command.
Command 0x12 contains both the device bluetooth address as well as
configured host bluetooth address, so it can be used to query
both. Kernel driver hid-playstation also uses 0x12 command for that.

Manufacturer link:
https://esperanza.pl/esperanza-gamepad-bezprzewodowy-ps3-marine-czarny,176,1701.html



To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications

^ permalink raw reply

* [PATCH] Bluetooth: btusb: Add Mercusys MA530 for Realtek RTL8761BUV
From: Hrvoje Nuic @ 2026-04-22 21:26 UTC (permalink / raw)
  To: marcel, luiz.dentz; +Cc: linux-bluetooth, linux-kernel, Hrvoje Nuic

Add the USB ID for the Mercusys MA530 Bluetooth adapter. The device uses
a Realtek RTL8761BUV controller and works with the existing Realtek setup
path.

The device reports vendor ID 0x2c4e and product ID 0x0115, and loads the
rtl_bt/rtl8761bu_fw.bin firmware successfully with this quirk.

Signed-off-by: Hrvoje Nuic <hrvoje.nuic@gmail.com>
---
 drivers/bluetooth/btusb.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 5f57953393be..a0a7da498466 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -818,6 +818,8 @@ static const struct usb_device_id quirks_table[] = {
 	{ USB_DEVICE(0x2ff8, 0xb011), .driver_info = BTUSB_REALTEK },
 
 	/* Additional Realtek 8761BUV Bluetooth devices */
+	{ USB_DEVICE(0x2c4e, 0x0115), .driver_info = BTUSB_REALTEK |
+						     BTUSB_WIDEBAND_SPEECH },
 	{ USB_DEVICE(0x2357, 0x0604), .driver_info = BTUSB_REALTEK |
 						     BTUSB_WIDEBAND_SPEECH },
 	{ USB_DEVICE(0x0b05, 0x190e), .driver_info = BTUSB_REALTEK |
-- 
2.34.1


^ permalink raw reply related

* [PATCH BlueZ v2] sixaxis: Fix pairing Esperanza EGG109k controller
From: Marek Czerski @ 2026-04-22 21:20 UTC (permalink / raw)
  To: hadess; +Cc: linux-bluetooth, ma.czerski
In-Reply-To: <59197f235800db69549ec163391ac1ac1f1ffe65.camel@hadess.net>

This change is required for Esperanza EGG109k ps controller clone.
EGG109k looks like PS3 controller but presents itself to the system
as PS4 controller. It does not respond to 0x81 command.
Command 0x12 contains both the device bluetooth address as well as
configured host bluetooth address, so it can be used to query
both. Kernel driver hid-playstation also uses 0x12 command for that.

Manufacturer link:
https://esperanza.pl/esperanza-gamepad-bezprzewodowy-ps3-marine-czarny,176,1701.html
---
 plugins/sixaxis.c | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/plugins/sixaxis.c b/plugins/sixaxis.c
index 27bc09815..a04a76d39 100644
--- a/plugins/sixaxis.c
+++ b/plugins/sixaxis.c
@@ -39,6 +39,9 @@
 #include "profiles/input/server.h"
 #include "profiles/input/sixaxis.h"
 
+#define DS4_FEATURE_REPORT_PAIRING_INFO		0x12
+#define DS4_FEATURE_REPORT_PAIRING_INFO_SIZE	16
+
 struct authentication_closure {
 	guint auth_id;
 	char *sysfs_path;
@@ -111,12 +114,12 @@ static int sixaxis_get_device_bdaddr(int fd, bdaddr_t *bdaddr)
 
 static int ds4_get_device_bdaddr(int fd, bdaddr_t *bdaddr)
 {
-	uint8_t buf[7];
+	uint8_t buf[DS4_FEATURE_REPORT_PAIRING_INFO_SIZE];
 	int ret;
 
 	memset(buf, 0, sizeof(buf));
 
-	buf[0] = 0x81;
+	buf[0] = DS4_FEATURE_REPORT_PAIRING_INFO;
 
 	ret = ioctl(fd, HIDIOCGFEATURE(sizeof(buf)), buf);
 	if (ret < 0) {
@@ -163,12 +166,12 @@ static int sixaxis_get_central_bdaddr(int fd, bdaddr_t *bdaddr)
 
 static int ds4_get_central_bdaddr(int fd, bdaddr_t *bdaddr)
 {
-	uint8_t buf[16];
+	uint8_t buf[DS4_FEATURE_REPORT_PAIRING_INFO_SIZE];
 	int ret;
 
 	memset(buf, 0, sizeof(buf));
 
-	buf[0] = 0x12;
+	buf[0] = DS4_FEATURE_REPORT_PAIRING_INFO;
 
 	ret = ioctl(fd, HIDIOCGFEATURE(sizeof(buf)), buf);
 	if (ret < 0) {
-- 
2.43.0


^ permalink raw reply related

* Re: [PATCH 11/12] Bluetooth: hci_qca: Check whether the M.2 UART interface is fixed or not
From: Dmitry Baryshkov @ 2026-04-22 18:17 UTC (permalink / raw)
  To: manivannan.sadhasivam
  Cc: Bartosz Golaszewski, Manivannan Sadhasivam, 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
In-Reply-To: <20260422-pwrseq-m2-bt-v1-11-720d02545a64@oss.qualcomm.com>

On Wed, Apr 22, 2026 at 04:54:52PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> 
> In the M.2 connector, the UART interface is controlled through the
> W_DISABLE2# signal. But the BT driver cannot know directly whether this
> signal is available or not.
> 
> Hence, use the new pwrseq API 'pwrseq_is_fixed()' to check whether the UART
> interface on the M.2 connector is fixed or controllable and set the
> 'bt_en_available' flag accordingly.
> 
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> ---
>  drivers/bluetooth/hci_qca.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>


-- 
With best wishes
Dmitry

^ permalink raw reply

* Re: [PATCH 10/12] Bluetooth: hci_qca: Rename 'power_ctrl_enabled' to 'bt_en_available'
From: Dmitry Baryshkov @ 2026-04-22 18:16 UTC (permalink / raw)
  To: manivannan.sadhasivam
  Cc: Bartosz Golaszewski, Manivannan Sadhasivam, 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
In-Reply-To: <20260422-pwrseq-m2-bt-v1-10-720d02545a64@oss.qualcomm.com>

On Wed, Apr 22, 2026 at 04:54:51PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> 
> 'power_ctrl_enabled' flag is used to indicate the availability of the BT_EN
> GPIO in devicetree. But the naming causes confusion with the new pwrctrl
> framework.
> 
> So rename it to 'bt_en_available' to make it clear and explicit.
> 
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> ---
>  drivers/bluetooth/hci_qca.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>


-- 
With best wishes
Dmitry

^ permalink raw reply

* Re: [PATCH 09/12] Bluetooth: hci_qca: Add M.2 Bluetooth device support using pwrseq
From: Dmitry Baryshkov @ 2026-04-22 18:14 UTC (permalink / raw)
  To: manivannan.sadhasivam
  Cc: Bartosz Golaszewski, Manivannan Sadhasivam, 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, Bartosz Golaszewski
In-Reply-To: <20260422-pwrseq-m2-bt-v1-9-720d02545a64@oss.qualcomm.com>

On Wed, Apr 22, 2026 at 04:54:50PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> 
> Power supply to the M.2 Bluetooth device attached to the host using M.2
> connector is controlled using the 'uart' pwrseq device. So add support for
> getting the pwrseq device if the OF graph link is present. Once obtained,
> the existing pwrseq APIs can be used to control the power supplies of the
> M.2 card.
> 
> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> ---
>  drivers/bluetooth/hci_qca.c | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>


-- 
With best wishes
Dmitry

^ permalink raw reply

* Re: [PATCH 12/12] Bluetooth: hci_qca: Fix the broken BT_EN GPIO detection for Qcom WCN devices
From: Dmitry Baryshkov @ 2026-04-22 18:13 UTC (permalink / raw)
  To: manivannan.sadhasivam
  Cc: Bartosz Golaszewski, Manivannan Sadhasivam, 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: <20260422-pwrseq-m2-bt-v1-12-720d02545a64@oss.qualcomm.com>

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.

> +
> +			if (pwrseq_is_fixed(qcadev->bt_power->pwrseq))
> +				bt_en_available = false;
> +
> +			break;
>  		}
>  
>  		qcadev->bt_power->dev = &serdev->dev;
> 
> -- 
> 2.51.0
> 
> 

-- 
With best wishes
Dmitry

^ permalink raw reply

* Re: [PATCH v2] Bluetooth: 6lowpan: fix cyclic locking warning on netdev unregister
From: patchwork-bot+bluetooth @ 2026-04-22 17:20 UTC (permalink / raw)
  To: Pauli Virtanen; +Cc: linux-bluetooth
In-Reply-To: <afc0037c7237e101b50b68d969cc4202bede5f92.1775931137.git.pav@iki.fi>

Hello:

This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:

On Sat, 11 Apr 2026 21:15:09 +0300 you wrote:
> 6lowpan.c has theoretically conflicting lock orderings, which lockdep
> complains about:
> 
>     a) rtnl_lock > hdev->workqueue
> 
>     from 6lowpan.c:delete_netdev -> rtnl_lock -> device_del
>     -> put_device(parent) -> hci_release_dev -> destroy_workqueue
> 
> [...]

Here is the summary with links:
  - [v2] Bluetooth: 6lowpan: fix cyclic locking warning on netdev unregister
    https://git.kernel.org/bluetooth/bluetooth-next/c/87151e363b7e

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html



^ permalink raw reply

* [bluez/bluez]
From: BluezTestBot @ 2026-04-22 16:41 UTC (permalink / raw)
  To: linux-bluetooth

  Branch: refs/heads/1084033
  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

* RE: [BlueZ,v1] input: Fix checking LE bonding on HIDP
From: bluez.test.bot @ 2026-04-22 16:40 UTC (permalink / raw)
  To: linux-bluetooth, luiz.dentz
In-Reply-To: <20260422150328.2062359-1-luiz.dentz@gmail.com>

[-- 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=1084336

---Test result---

Test Summary:
CheckPatch                    PASS      0.34 seconds
GitLint                       PASS      0.24 seconds
BuildEll                      PASS      20.31 seconds
BluezMake                     PASS      644.74 seconds
MakeCheck                     PASS      0.92 seconds
MakeDistcheck                 PASS      246.53 seconds
CheckValgrind                 PASS      221.43 seconds
CheckSmatch                   PASS      350.33 seconds
bluezmakeextell               PASS      181.69 seconds
IncrementalBuild              PASS      646.76 seconds
ScanBuild                     PASS      1025.97 seconds



https://github.com/bluez/bluez/pull/2062

---
Regards,
Linux Bluetooth


^ permalink raw reply

* Re: [PATCH v3 0/2] Bluetooth: virtio_bt: harden rx against untrusted backend
From: patchwork-bot+bluetooth @ 2026-04-22 16:00 UTC (permalink / raw)
  To: Michael Bommarito
  Cc: marcel, luiz.dentz, linux-bluetooth, linux-kernel, soenke.huster,
	mst, virtualization
In-Reply-To: <20260421170845.3469513-1-michael.bommarito@gmail.com>

Hello:

This series was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:

On Tue, 21 Apr 2026 13:08:43 -0400 you wrote:
> Respin of the virtio_bt rx hardening patch, split per Luiz's
> request on the v2 thread:
> 
>   https://lore.kernel.org/linux-bluetooth/20260421151659.3326690-1-michael.bommarito@gmail.com/
> 
> v2 bundled two independent hazards in one commit and the commit
> message got convoluted trying to explain them together. This v3
> keeps each hazard in its own patch so the rationale for each is
> self-contained.
> 
> [...]

Here is the summary with links:
  - [v3,1/2] Bluetooth: virtio_bt: clamp rx length before skb_put
    https://git.kernel.org/bluetooth/bluetooth-next/c/041f524fb455
  - [v3,2/2] Bluetooth: virtio_bt: validate rx pkt_type header length
    https://git.kernel.org/bluetooth/bluetooth-next/c/d677b827eea1

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html



^ permalink raw reply

* Re: [PATCH] Bluetooth: HIDP: guard session->conn in hidp_connection_del
From: Luiz Augusto von Dentz @ 2026-04-22 15:49 UTC (permalink / raw)
  To: Michael Bommarito; +Cc: Marcel Holtmann, linux-bluetooth, linux-kernel
In-Reply-To: <CAJJ9bXxCMVzVASz64obn78Ob2CDKBZX3r4B5iE_=+hbnwXDirQ@mail.gmail.com>

Hi Michael,

On Wed, Apr 22, 2026 at 11:09 AM Michael Bommarito
<michael.bommarito@gmail.com> wrote:
>
> On Wed, Apr 22, 2026 at 10:55 AM Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> wrote:
> > We might need a lock in order to access the session->conn:
>
> This one is a little easier than the other txwin_size issue in terms
> of blast radius.
>
> What pattern would you prefer here?
>
> Option 1, smaller but ordering questions: hold the semaphore across
> check and use like this:
>
> down_read(&hidp_session_sem);
> if (session->conn)
>     l2cap_unregister_user(session->conn, &session->user);
> up_read(&hidp_session_sem)
>
>
> Option 2, more correct but more cycles: snapshot the conn and use outside
>
> down_read(&hidp_session_sem);
> conn = session->conn;
> if (conn)
>     l2cap_conn_get(conn);
> up_read(&hidp_session_sem);
> if (conn) {
>     l2cap_unregister_user(conn, &session->user);
>     l2cap_conn_put(conn);
> }

Neither seems completely correct, in my opinion. I guess we want to
use option 2 but set the session->conn to NULL since it will call
l2cap_unregister_user.

> Thanks,
> Mike Bommarito



-- 
Luiz Augusto von Dentz

^ permalink raw reply

* Re: [PATCH] Bluetooth: HIDP: guard session->conn in hidp_connection_del
From: Pauli Virtanen @ 2026-04-22 15:48 UTC (permalink / raw)
  To: Michael Bommarito, Luiz Augusto von Dentz
  Cc: Marcel Holtmann, linux-bluetooth, linux-kernel
In-Reply-To: <CAJJ9bXxCMVzVASz64obn78Ob2CDKBZX3r4B5iE_=+hbnwXDirQ@mail.gmail.com>

Hi,

ke, 2026-04-22 kello 11:09 -0400, Michael Bommarito kirjoitti:
> On Wed, Apr 22, 2026 at 10:55 AM Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> wrote:
> > We might need a lock in order to access the session->conn:
> 
> This one is a little easier than the other txwin_size issue in terms
> of blast radius.
> 
> What pattern would you prefer here?
> 
> Option 1, smaller but ordering questions: hold the semaphore across
> check and use like this:
> 
> down_read(&hidp_session_sem);
> if (session->conn)
>     l2cap_unregister_user(session->conn, &session->user);
> up_read(&hidp_session_sem)
> 
> 
> Option 2, more correct but more cycles: snapshot the conn and use outside
> 
> down_read(&hidp_session_sem);
> conn = session->conn;
> if (conn)
>     l2cap_conn_get(conn);
> up_read(&hidp_session_sem);
> if (conn) {
>     l2cap_unregister_user(conn, &session->user);
>     l2cap_conn_put(conn);
> }

I'm not sure now (would need to rethink it through), but one probably
should check if dbf666e4fc9b is needed or whether 752a6c9596d alone
would be enough to address the original issue.

-- 
Pauli Virtanen

^ permalink raw reply

* [bluez/bluez]
From: BluezTestBot @ 2026-04-22 15:43 UTC (permalink / raw)
  To: linux-bluetooth

  Branch: refs/heads/1081856
  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


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