All of lore.kernel.org
 help / color / mirror / Atom feed
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 v3] Bluetooth: l2cap: prefer compatible local LE intervals
Date: Thu, 15 Oct 2026 18:11:14 +0000	[thread overview]
Message-ID: <20261015181041.42873-1-cochcoder@proton.me> (raw)
In-Reply-To: <20261015043336.47734-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 since v2:
- Wrap test notes to avoid the GitLint B1 failure in series 1186108.
- Refresh onto bluetooth-next ff8b09806b7b; no source delta from v2.

Changes from v1 retained:
- Treat local ranges as preferences, not supported bounds.
- Prefer a valid intersection; otherwise keep the valid peer request.
- Never repair an invalid original request by clipping.
- Preserve latency, supervision timeout and disjoint-range acceptance.

Prior native controls check the accepted L2CAP response and HCI range:
overlap, fast HID fallback, slow idle fallback and exact match. Baseline
passes 3/4; strict bounds pass 2/4 (reject HID/idle); v2 passes 4/4.
The prior reference-guest full L2CAP suite passes 115/115, without skips
or captured KASAN/lockdep alerts. These are prior runs, not fresh v3 VMs.

The independent BlueZ test companion was sent as:
https://lore.kernel.org/r/20261015044221.55631-1-cochcoder@proton.me
Its overlap case intentionally fails without this kernel change.
Completed-interval startup/stream gating remains separate profile work.

The saved v2 CI report lists all jobs except GitLint passing, including
the native L2CAP tester. This is not a remote CI result for v3.
The combined Arch trial is reported working on hardware, not isolated
testing of bluetooth-next or exhaustive device/negative-path coverage.

 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: ff8b09806b7b18884ad8d3a2b3d702da534a4e21


  parent reply	other threads:[~2026-10-15 18:11 UTC|newest]

Thread overview: 8+ 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 ` [RFC PATCH v2] Bluetooth: l2cap: prefer compatible local LE intervals Kyle Pepper
2026-10-15  7:12   ` [RFC,v2] " bluez.test.bot
2026-10-15 18:11   ` Kyle Pepper [this message]
2026-10-15 20:17     ` [RFC,v3] " bluez.test.bot

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=20261015181041.42873-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.