[PATCH v5 1/1] Bluetooth: btusb: support larger LE packets on TP-Link UB500

[Kyle Pepper <cochcoder@proton.me>]

The TP-Link UB500 (2357:0604) reports a 27-byte LE ACL packet length and
eight LE packets, although its reported maximum LE TX data length is
251 bytes. The small HCI packet length fragments ASHA audio packets.
Direct controller testing received 251-byte LE HCI packets intact.

Set the host LE ACL MTU to the reported maximum after initialization for
the observed 27/eight/eight-available/251 reports. Skip other reports
without failing controller initialization.

Keep the controller-reported packet count and available credits unchanged
so transfers can use all eight credits. Leave BR/EDR accounting unchanged.

Assisted-by: LLM
Signed-off-by: Kyle Pepper <cochcoder@proton.me>
---
v5:
- Keep the reported eight LE packet credits instead of reducing them to
  one, addressing Luiz's throughput concern.
- Keep automatic MTU selection and nonfatal handling of mismatched reports.

Matched 60-second single-N8 playback tests on the UB500 passed at host MTU
167/eight and 251/eight, with CLEAR listening and verified stock restoration
between tests. The control had 3,236 complete audio SDUs and 3,262/3,262 HCI
completions; the 251-byte setting had 3,234 SDUs and 3,260/3,260 completions.
Both used whole 167-byte HCI audio packets, reached three outstanding packets,
returned all credits and had no socket EAGAIN or disconnection. PipeWire's
actual SO_SNDBUF stayed 4608. Tests used the exact callback ported to the
Arch-based ASHA 7.2.9 kernel; fresh upstream object builds run before sending.

An earlier 251/eight trial sounded clear but stalled after about 40 seconds
of audio transmission and ended with HCI Connection Timeout (0x08), with seven
completions pending. Restoration succeeded. Its cause remains unexplained;
the successful comparison does not erase that failure.

These are normal single-CI playback results. They do not establish eight
physical 251-byte slots, mixed BR/EDR+LE capacity, bilateral recovery,
exceptional congestion behavior, other firmware or long-duration reliability.

 drivers/bluetooth/btusb_main.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/drivers/bluetooth/btusb_main.c b/drivers/bluetooth/btusb_main.c
index 92a78a7e6..9cc3dd240 100644
--- a/drivers/bluetooth/btusb_main.c
+++ b/drivers/bluetooth/btusb_main.c
@@ -2972,6 +2972,19 @@ static int btusb_setup_realtek(struct hci_dev *hdev)
 	return ret;
 }
 
+static int btusb_ub500_post_init(struct hci_dev *hdev)
+{
+	if (hdev->le_mtu != 27 ||
+	    hdev->le_pkts != 8 || hdev->le_cnt != 8 ||
+	    hdev->le_max_tx_len != 251)
+		return 0;
+
+	bt_dev_info(hdev, "LE ACL MTU 27 -> %u; LE packets 8 unchanged",
+		    hdev->le_max_tx_len);
+	hdev->le_mtu = hdev->le_max_tx_len;
+	return 0;
+}
+
 static int btusb_recv_event_realtek(struct hci_dev *hdev, struct sk_buff *skb)
 {
 	if (skb->len >= HCI_EVENT_HDR_SIZE + 1 &&
@@ -4715,6 +4728,9 @@ static int btusb_probe(struct usb_interface *intf,
 	    (id->driver_info & BTUSB_REALTEK)) {
 		btrtl_set_driver_name(hdev, btusb_driver.name);
 		hdev->setup = btusb_setup_realtek;
+		if (le16_to_cpu(data->udev->descriptor.idVendor) == 0x2357 &&
+		    le16_to_cpu(data->udev->descriptor.idProduct) == 0x0604)
+			hdev->post_init = btusb_ub500_post_init;
 		hdev->shutdown = btrtl_shutdown_realtek;
 		hdev->reset = btusb_rtl_reset;
 		hdev->hw_error = btusb_rtl_hw_error;

base-commit: 1081a6ef8f1e0661fd52eb3f878691b0b96cdff9
-- 
2.56.0