From: Kyle Pepper <cochcoder@proton.me>
To: linux-bluetooth@vger.kernel.org
Cc: Marcel Holtmann <marcel@holtmann.org>,
Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
linux-kernel@vger.kernel.org
Subject: [RFC PATCH v2] Bluetooth: l2cap: prefer compatible local LE intervals
Date: Thu, 15 Oct 2026 04:34:04 +0000 [thread overview]
Message-ID: <20261015043336.47734-1-cochcoder@proton.me> (raw)
In-Reply-To: <20261013033118.501182-1-cochcoder@proton.me>
Use a valid intersection of a peer interval range and local preferences
when they overlap. Otherwise retain the peer request instead of treating
an initial preference as a hard supported bound.
Validate the original wire request first. Only narrow its interval range;
leave latency, timeout and disjoint-range acceptance unchanged.
Assisted-by: OpenCode:gpt-6.1-sol
Signed-off-by: Kyle Pepper <cochcoder@proton.me>
---
Changes from v1:
- Treat local ranges as preferences, not supported bounds.
- Prefer a valid intersection; otherwise keep the original valid peer request.
- Never repair an invalid original request by clipping.
- Preserve latency, supervision timeout and disjoint-range acceptance.
Four native controls check both the accepted L2CAP response and resulting HCI
update range: overlap, fast HID fallback, slow idle fallback and exact match.
Baseline passes 3/4 (no narrower overlap); the strict-bound negative control
passes 2/4 (rejects HID/idle); this revision passes 4/4. Its full reference-guest
L2CAP suite passes 115/115 without skips or captured KASAN/lockdep alerts.
The source-extracted sanitizer fixture passes 397,723 parameter cases plus two
framing/role cases. These are finite tests, not proof for every controller.
The independent BlueZ interval-test companion is not yet sent. Its overlap test
intentionally fails without this Linux change. ASHA completed-interval startup
and stream gating are separate profile work, not a new kernel ABI or hard bound.
A combined Arch 7.2.9 trial with this change and revised BlueZ was built in a
clean chroot. I report that stack working on hardware; the running test kernel
and BlueZ package versions were verified. This is combined-stack evidence,
not isolated attribution or complete N7/paired-device/negative-path coverage.
It is not hardware testing of the bluetooth-next kernel itself. Remote CI for
this revision has not run. Target master still matches the tested source base.
net/bluetooth/l2cap_core.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 4dd56e007..afde04a19 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -5031,6 +5031,19 @@ static inline int l2cap_conn_param_update_req(struct l2cap_conn *conn,
memset(&rsp, 0, sizeof(rsp));
err = hci_check_conn_params(min, max, latency, to_multiplier);
+ if (!err) {
+ u16 pref_min = max_t(u16, min, hcon->le_conn_min_interval);
+ u16 pref_max = min_t(u16, max, hcon->le_conn_max_interval);
+
+ /* Local preferences must not reject a valid peer request. */
+ if (pref_min <= pref_max &&
+ !hci_check_conn_params(pref_min, pref_max, latency,
+ to_multiplier)) {
+ min = pref_min;
+ max = pref_max;
+ }
+ }
+
if (err)
rsp.result = cpu_to_le16(L2CAP_CONN_PARAM_REJECTED);
else
base-commit: 397464709a204da9b8dc3b01d6ea42539d951cd2
next prev parent reply other threads:[~2026-10-15 4:34 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-13 3:31 [RFC PATCH] Bluetooth: l2cap: honor local LE connection interval range Kyle Pepper
2026-10-13 4:26 ` [RFC] " bluez.test.bot
2026-10-13 14:33 ` [RFC PATCH] " Luiz Augusto von Dentz
2026-10-15 18:12 ` cochcoder
2026-10-15 4:34 ` Kyle Pepper [this message]
2026-10-15 7:12 ` [RFC,v2] Bluetooth: l2cap: prefer compatible local LE intervals bluez.test.bot
2026-10-15 18:11 ` [RFC PATCH v3] " Kyle Pepper
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261015043336.47734-1-cochcoder@proton.me \
--to=cochcoder@proton.me \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luiz.dentz@gmail.com \
--cc=marcel@holtmann.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.