Message ID | 20240605195610.534491-1-luiz.dentz@gmail.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [BlueZ,v1] transport: Fix not always being able to Acquire when linked | expand |
Context | Check | Description |
---|---|---|
tedd_an/pre-ci_am | success | Success |
tedd_an/CheckPatch | success | CheckPatch PASS |
tedd_an/GitLint | success | Gitlint PASS |
tedd_an/BuildEll | success | Build ELL PASS |
tedd_an/BluezMake | success | Bluez Make PASS |
tedd_an/MakeCheck | success | Bluez Make Check PASS |
tedd_an/MakeDistcheck | success | Make Distcheck PASS |
tedd_an/CheckValgrind | success | Check Valgrind PASS |
tedd_an/CheckSmatch | success | CheckSparse PASS |
tedd_an/bluezmakeextell | success | Make External ELL PASS |
tedd_an/IncrementalBuild | success | Incremental Build PASS |
tedd_an/ScanBuild | success | Scan Build PASS |
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=859222 ---Test result--- Test Summary: CheckPatch PASS 0.42 seconds GitLint PASS 0.29 seconds BuildEll PASS 25.78 seconds BluezMake PASS 1716.00 seconds MakeCheck PASS 13.53 seconds MakeDistcheck PASS 182.51 seconds CheckValgrind PASS 253.03 seconds CheckSmatch PASS 356.44 seconds bluezmakeextell PASS 122.46 seconds IncrementalBuild PASS 1477.12 seconds ScanBuild PASS 1036.21 seconds --- Regards, Linux Bluetooth
diff --git a/profiles/audio/transport.c b/profiles/audio/transport.c index 5b11bfeb6ab6..64d38ae669da 100644 --- a/profiles/audio/transport.c +++ b/profiles/audio/transport.c @@ -1492,11 +1492,20 @@ static guint transport_bap_resume(struct media_transport *transport, if (!bap->stream) return 0; + if (bap->resume_id) - return 0; + return bap->resume_id; bap_update_links(transport); + /* If there is already an fd set consider it ready and proceed to + * complete the resume process. + */ + if (transport->fd >= 0) { + bap->resume_id = g_idle_add(bap_resume_complete_cb, transport); + return bap->resume_id; + } + switch (bt_bap_stream_get_state(bap->stream)) { case BT_BAP_STREAM_STATE_ENABLING: bap_enable_complete(bap->stream, 0x00, 0x00, owner); @@ -1671,6 +1680,22 @@ static void bap_state_changed(struct bt_bap_stream *stream, uint8_t old_state, g_io_channel_unref(chan); media_transport_set_fd(transport, fd, imtu, omtu); + + /* If the transport is linked update the fd in the link as well as they + * share the same io channel. + */ + if (bap->linked) { + struct bt_bap_stream *link = bt_bap_stream_io_get_link(stream); + + if (link) { + struct media_transport *t; + + t = find_transport_by_bap_stream(link); + if (t) + media_transport_set_fd(t, fd, imtu, omtu); + } + } + transport_update_playing(transport, TRUE); done:
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> If a linked transport becomes ready and sets an fd it means it can be acquired via Acquire/TryAcquire methods but that shall also be valid for linked transports as well since they share the same fd/IO it can already be transferred despite the state of the stream. Fixes: https://github.com/bluez/bluez/issues/862 --- profiles/audio/transport.c | 27 ++++++++++++++++++++++++++- 1 file changed, 26 insertions(+), 1 deletion(-)