public inbox for linux-bluetooth@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH BlueZ] shared/bap: handle inverted order of stop ready and disabling->qos
@ 2025-06-22 11:48 Pauli Virtanen
  2025-06-22 13:12 ` [BlueZ] " bluez.test.bot
  2025-06-23 17:20 ` [PATCH BlueZ] " patchwork-bot+bluetooth
  0 siblings, 2 replies; 3+ messages in thread
From: Pauli Virtanen @ 2025-06-22 11:48 UTC (permalink / raw)
  To: linux-bluetooth; +Cc: Pauli Virtanen

DISABLING->QOS transition and Receiver Stop Ready reply may arrive in
any order.  BAP v1.0.2 (Sec. 5.6.5.1): CIS may be terminated by either
side after Receiver Stop Ready has successfully completed.  However,
when we get the reply, the stream may be in either state.

Instead of client detaching the IO on stop ready reply, rely on
detaching IO on entering QOS, where Receiver Stop Ready has then
necessarily completed. On DISABLING, mark stream io as not connecting,
so that it gets detached even if CIS was not yet established.

Seen to occur with Samsung Galaxy Buds2 Pro, when it refuses Enable for
32/32kHz duplex on one of the earbuds.
---
 src/shared/bap.c | 21 +++++++++------------
 1 file changed, 9 insertions(+), 12 deletions(-)

diff --git a/src/shared/bap.c b/src/shared/bap.c
index 9933eeda5..bccbc73ff 100644
--- a/src/shared/bap.c
+++ b/src/shared/bap.c
@@ -1441,15 +1441,6 @@ static bool bap_stream_io_detach(struct bt_bap_stream *stream)
 	return true;
 }
 
-static void stream_stop_complete(struct bt_bap_stream *stream, uint8_t code,
-					uint8_t reason,	void *user_data)
-{
-	DBG(stream->bap, "stream %p stop 0x%02x 0x%02x", stream, code, reason);
-
-	if (stream->ep->state == BT_ASCS_ASE_STATE_DISABLING)
-		bap_stream_io_detach(stream);
-}
-
 static void bap_stream_state_changed(struct bt_bap_stream *stream)
 {
 	struct bt_bap *bap = stream->bap;
@@ -1506,9 +1497,15 @@ static void bap_stream_state_changed(struct bt_bap_stream *stream)
 			bt_bap_stream_start(stream, NULL, NULL);
 		break;
 	case BT_ASCS_ASE_STATE_DISABLING:
-		/* Send Stop Ready, and detach IO after remote replies */
-		if (stream->client)
-			bt_bap_stream_stop(stream, stream_stop_complete, NULL);
+		/* Client may terminate CIS after Receiver Stop Ready completes
+		 * successfully (BAP v1.0.2, 5.6.5.1). Do it when back to QOS.
+		 * Ensure IO is detached also if CIS was not yet established.
+		 */
+		if (stream->client) {
+			bt_bap_stream_stop(stream, NULL, NULL);
+			if (stream->io)
+				stream->io->connecting = false;
+		}
 		break;
 	case BT_ASCS_ASE_STATE_RELEASING:
 		if (stream->client) {
-- 
2.49.0


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

end of thread, other threads:[~2025-06-23 17:19 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-06-22 11:48 [PATCH BlueZ] shared/bap: handle inverted order of stop ready and disabling->qos Pauli Virtanen
2025-06-22 13:12 ` [BlueZ] " bluez.test.bot
2025-06-23 17:20 ` [PATCH BlueZ] " patchwork-bot+bluetooth

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