[PW_SID:929013] [BlueZ,v2,1/2] audio: actually try to enable MTU auto-tuning #2644
Conversation
This patch adds workflow files for ci:
[sync.yml]
- runs every 30 mins.
- sync repo with upstream repo and rebase workflow branch to tip of
master.
- creates PR after reading patches from patchwork.kernel.org
[ci.yml]
- Tests the following checks:
- checkpatch
- gitlint
- make
- make check
[code_scan.yml]
- Static code checker: Coverity and Clang
- Coverity: Submit the result to the coverity website
- Clang Code Scan: Send email with result file to the internal team
To simplify the history, new change will amend to this patch without
creating new patch.
A "0" for the input MTU passed to the underlying socket is supposed to indicate that its value should be determined by the L2CAP layer. However, the current code treats a zero imtu just as if there is nothing to change. Introduce an additional flag to indicate that the zero imtu is explicitly requested by the caller for the purpose of auto-tuning. Otherwise, the similar behavior remains. Found by Linux Verification Center (linuxtesting.org). Fixes: ae5be37 ("avdtp: Enable MTU auto tunning")
L2CAP frames are lost while utilizing some exotic A2DP transports usually coming up with weird custom MTU sizes so take advantage of auto-tuning it for such cases. Found by Linux Verification Center (linuxtesting.org). Fixes: bluez#1080
|
CheckPatch |
|
GitLint |
|
BuildEll |
|
BluezMake |
|
MakeCheck |
|
MakeDistcheck |
|
CheckValgrind |
|
CheckSmatch |
|
bluezmakeextell |
|
IncrementalBuild |
|
ScanBuild |
github-actions
bot
force-pushed
the
workflow
branch
6 times, most recently
from
7a793c4 to
bef7d63
Compare
github-actions
bot
force-pushed
the
workflow
branch
6 times, most recently
from
d2e8011 to
243e77e
Compare
github-actions
bot
force-pushed
the
workflow
branch
2 times, most recently
from
8a2a355 to
32dfcd7
Compare
A "0" for the input MTU passed to the underlying socket is supposed to
indicate that its value should be determined by the L2CAP layer.
However, the current code treats a zero imtu just as if there is
nothing to change.
Introduce an additional flag to indicate that the zero imtu is
explicitly requested by the caller for the purpose of auto-tuning.
Otherwise, the similar behavior remains.
Found by Linux Verification Center (linuxtesting.org).
Fixes: ae5be37 ("avdtp: Enable MTU auto tunning")
v1->v2: incorporate error handling in case the kernel still doesn't
support MTU auto-tuning
btio/btio.c | 34 ++++++++++++++++++++++------------
1 file changed, 22 insertions(+), 12 deletions(-)