[RFC PATCH] Bluetooth: btusb: use shared ACL buffers for TP-Link UB500

[RFC PATCH] Bluetooth: btusb: use shared ACL buffers for TP-Link UB500

[Kyle Pepper]

The TP-Link UB500 (2357:0604) reports a dedicated LE ACL pool of 27
bytes by eight packets and a BR/EDR ACL pool of 1021 bytes by six
packets. Sustained large-SDU LE CoC traffic exhausts the small pool,
although this controller accepts LE traffic through the larger ACL pool.

Add an explicit HCI quirk and enable it only for the tested USB ID. When
set, treat the LE buffer as shared so the existing HCI scheduler uses
the ACL pool. Avoid inferring this from buffer sizes globally because
other controllers may have legitimate separate pools.

Assisted-by: OpenCode:gpt-6.1-sol
Signed-off-by: Kyle Pepper <cochcoder@proton.me>
---
Submission review notes (not part of the commit message):
October 12 N8/UB500 no-quirk trial opens CoC, completes START, DLE
and 2M, but sends no audio frames and logs two watchdog stalls. The
host advertises MPS 23 instead of the baseline 512; peer MPS remains
168. Firmware pool semantics and simultaneous BR/EDR/LE accounting are
not established. Keep the quirk device-specific and this proposal RFC.

 drivers/bluetooth/btusb_main.c |  7 ++++++-
 include/net/bluetooth/hci.h    |  7 +++++++
 net/bluetooth/hci_event.c      | 22 ++++++++++++++++++++++
 3 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/drivers/bluetooth/btusb_main.c b/drivers/bluetooth/btusb_main.c
index 71d8dccb2..5e1fb26ab 100644
--- a/drivers/bluetooth/btusb_main.c
+++ b/drivers/bluetooth/btusb_main.c
@@ -70,6 +70,7 @@ static struct usb_driver btusb_driver;
 #define BTUSB_INTEL_NO_WBS_SUPPORT	BIT(26)
 #define BTUSB_ACTIONS_SEMI		BIT(27)
 #define BTUSB_BARROT			BIT(28)
+#define BTUSB_USE_BREDR_ACL_BUFFERS_FOR_LE BIT(29)
 #define BTUSB_QUALCOMM			BIT(30)
 
 static const struct usb_device_id btusb_table[] = {
@@ -872,7 +873,8 @@ static const struct usb_device_id quirks_table[] = {
 	{ USB_DEVICE(0x2c4e, 0x0115), .driver_info = BTUSB_REALTEK |
 						     BTUSB_WIDEBAND_SPEECH },
 	{ USB_DEVICE(0x2357, 0x0604), .driver_info = BTUSB_REALTEK |
-						     BTUSB_WIDEBAND_SPEECH },
+						     BTUSB_WIDEBAND_SPEECH |
+						     BTUSB_USE_BREDR_ACL_BUFFERS_FOR_LE },
 	{ USB_DEVICE(0x2357, 0x0607), .driver_info = BTUSB_REALTEK |
 						     BTUSB_WIDEBAND_SPEECH },
 	{ USB_DEVICE(0x0b05, 0x190e), .driver_info = BTUSB_REALTEK |
@@ -4748,6 +4750,9 @@ static int btusb_probe(struct usb_interface *intf,
 	if (id->driver_info & BTUSB_WIDEBAND_SPEECH)
 		hci_set_quirk(hdev, HCI_QUIRK_WIDEBAND_SPEECH_SUPPORTED);
 
+	if (id->driver_info & BTUSB_USE_BREDR_ACL_BUFFERS_FOR_LE)
+		hci_set_quirk(hdev, HCI_QUIRK_USE_BREDR_ACL_BUFFERS_FOR_LE);
+
 	if (id->driver_info & BTUSB_INVALID_LE_STATES)
 		hci_set_quirk(hdev, HCI_QUIRK_BROKEN_LE_STATES);
 
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index 1641d879d..d39a64663 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -375,6 +375,13 @@ enum {
 	 */
 	HCI_QUIRK_BROKEN_READ_PAGE_SCAN_TYPE,
 
+	/* When this quirk is set, LE connections use the BR/EDR ACL buffer
+	 * pool instead of the dedicated LE pool reported by the controller.
+	 * This is required for controllers that expose an unusably small LE
+	 * pool while accepting LE traffic through their shared ACL pool.
+	 */
+	HCI_QUIRK_USE_BREDR_ACL_BUFFERS_FOR_LE,
+
 	__HCI_NUM_QUIRKS,
 };
 
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index c055d16cf..9936f6365 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -1227,6 +1227,24 @@ static u8 hci_cc_pin_code_neg_reply(struct hci_dev *hdev, void *data,
 	return rp->status;
 }
 
+/* Use the shared ACL pool for controllers whose dedicated LE pool is known to
+ * be unusable for sustained large-SDU traffic.
+ */
+static void hci_le_use_shared_acl_buffer(struct hci_dev *hdev)
+{
+	if (hci_test_quirk(hdev, HCI_QUIRK_USE_BREDR_ACL_BUFFERS_FOR_LE) &&
+	    hdev->le_mtu == HCI_MIN_LE_MTU &&
+	    hdev->acl_mtu > hdev->le_mtu && hdev->acl_pkts) {
+		bt_dev_dbg(hdev,
+			   "LE buffer at minimum (%u:%u), sharing ACL buffer %u:%u",
+			   hdev->le_mtu, hdev->le_pkts,
+			   hdev->acl_mtu, hdev->acl_pkts);
+		hdev->le_mtu = 0;
+		hdev->le_pkts = 0;
+		hdev->le_cnt = 0;
+	}
+}
+
 static u8 hci_cc_le_read_buffer_size(struct hci_dev *hdev, void *data,
 				     struct sk_buff *skb)
 {
@@ -1247,6 +1265,8 @@ static u8 hci_cc_le_read_buffer_size(struct hci_dev *hdev, void *data,
 	if (hdev->le_mtu && hdev->le_mtu < HCI_MIN_LE_MTU)
 		return HCI_ERROR_INVALID_PARAMETERS;
 
+	hci_le_use_shared_acl_buffer(hdev);
+
 	return rp->status;
 }
 
@@ -3939,6 +3959,8 @@ static u8 hci_cc_le_read_buffer_size_v2(struct hci_dev *hdev, void *data,
 	if (hdev->le_mtu && hdev->le_mtu < HCI_MIN_LE_MTU)
 		return HCI_ERROR_INVALID_PARAMETERS;
 
+	hci_le_use_shared_acl_buffer(hdev);
+
 	return rp->status;
 }
 

base-commit: 964430c038967fd06643e866f68115664e1a1bd1

RE: [RFC] Bluetooth: btusb: use shared ACL buffers for TP-Link UB500

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 1815 bytes --]

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/series/1184337/

---Test result---

Test Summary:
CheckPatch                    PASS      0.96 seconds
VerifyFixes                   PASS      0.10 seconds
VerifySignedoff               PASS      0.09 seconds
GitLint                       PASS      0.25 seconds
SubjectPrefix                 PASS      0.09 seconds
BuildKernel                   PASS      23.08 seconds
CheckAllWarning               PASS      26.61 seconds
CheckSparse                   WARNING   28.16 seconds
BuildKernel32                 PASS      23.23 seconds
CheckKernelLLVM               PASS      26.84 seconds
TestRunnerSetup               PASS      535.88 seconds
TestRunner_l2cap-tester       PASS      13.73 seconds
TestRunner_iso-tester         PASS      13.59 seconds
TestRunner_bnep-tester        PASS      2.74 seconds
TestRunner_mgmt-tester        PASS      83.63 seconds
TestRunner_rfcomm-tester      PASS      12.45 seconds
TestRunner_sco-tester         PASS      5.05 seconds
TestRunner_ioctl-tester       PASS      4.23 seconds
TestRunner_mesh-tester        PASS      5.07 seconds
TestRunner_smp-tester         PASS      3.96 seconds
TestRunner_userchan-tester    PASS      2.83 seconds
TestRunner_6lowpan-tester     PASS      3.96 seconds
IncrementalBuild              PASS      22.18 seconds

Details
##############################
Test: CheckSparse - WARNING
Desc: Run sparse tool with linux kernel
Output:
net/bluetooth/hci_event.c: note: in included file (through include/net/bluetooth/hci_core.h):


https://github.com/bluez/bluetooth-next/pull/908

---
Regards,
Linux Bluetooth

Re: [RFC PATCH] Bluetooth: btusb: use shared ACL buffers for TP-Link UB500

[cochcoder]

Just checking in on this patch. Is there anything else I can do to help it move forward?


On Monday, October 12th, 2026 at 11:28 PM, Kyle Pepper <cochcoder@proton.me> wrote:

> The TP-Link UB500 (2357:0604) reports a dedicated LE ACL pool of 27
> bytes by eight packets and a BR/EDR ACL pool of 1021 bytes by six
> packets. Sustained large-SDU LE CoC traffic exhausts the small pool,
> although this controller accepts LE traffic through the larger ACL pool.
> 
> Add an explicit HCI quirk and enable it only for the tested USB ID. When
> set, treat the LE buffer as shared so the existing HCI scheduler uses
> the ACL pool. Avoid inferring this from buffer sizes globally because
> other controllers may have legitimate separate pools.
> 
> Assisted-by: OpenCode:gpt-6.1-sol
> Signed-off-by: Kyle Pepper <cochcoder@proton.me>
> ---
> Submission review notes (not part of the commit message):
> October 12 N8/UB500 no-quirk trial opens CoC, completes START, DLE
> and 2M, but sends no audio frames and logs two watchdog stalls. The
> host advertises MPS 23 instead of the baseline 512; peer MPS remains
> 168. Firmware pool semantics and simultaneous BR/EDR/LE accounting are
> not established. Keep the quirk device-specific and this proposal RFC.
> 
>  drivers/bluetooth/btusb_main.c |  7 ++++++-
>  include/net/bluetooth/hci.h    |  7 +++++++
>  net/bluetooth/hci_event.c      | 22 ++++++++++++++++++++++
>  3 files changed, 35 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/bluetooth/btusb_main.c b/drivers/bluetooth/btusb_main.c
> index 71d8dccb2..5e1fb26ab 100644
> --- a/drivers/bluetooth/btusb_main.c
> +++ b/drivers/bluetooth/btusb_main.c
> @@ -70,6 +70,7 @@ static struct usb_driver btusb_driver;
>  #define BTUSB_INTEL_NO_WBS_SUPPORT	BIT(26)
>  #define BTUSB_ACTIONS_SEMI		BIT(27)
>  #define BTUSB_BARROT			BIT(28)
> +#define BTUSB_USE_BREDR_ACL_BUFFERS_FOR_LE BIT(29)
>  #define BTUSB_QUALCOMM			BIT(30)
>  
>  static const struct usb_device_id btusb_table[] = {
> @@ -872,7 +873,8 @@ static const struct usb_device_id quirks_table[] = {
>  	{ USB_DEVICE(0x2c4e, 0x0115), .driver_info = BTUSB_REALTEK |
>  						     BTUSB_WIDEBAND_SPEECH },
>  	{ USB_DEVICE(0x2357, 0x0604), .driver_info = BTUSB_REALTEK |
> -						     BTUSB_WIDEBAND_SPEECH },
> +						     BTUSB_WIDEBAND_SPEECH |
> +						     BTUSB_USE_BREDR_ACL_BUFFERS_FOR_LE },
>  	{ USB_DEVICE(0x2357, 0x0607), .driver_info = BTUSB_REALTEK |
>  						     BTUSB_WIDEBAND_SPEECH },
>  	{ USB_DEVICE(0x0b05, 0x190e), .driver_info = BTUSB_REALTEK |
> @@ -4748,6 +4750,9 @@ static int btusb_probe(struct usb_interface *intf,
>  	if (id->driver_info & BTUSB_WIDEBAND_SPEECH)
>  		hci_set_quirk(hdev, HCI_QUIRK_WIDEBAND_SPEECH_SUPPORTED);
>  
> +	if (id->driver_info & BTUSB_USE_BREDR_ACL_BUFFERS_FOR_LE)
> +		hci_set_quirk(hdev, HCI_QUIRK_USE_BREDR_ACL_BUFFERS_FOR_LE);
> +
>  	if (id->driver_info & BTUSB_INVALID_LE_STATES)
>  		hci_set_quirk(hdev, HCI_QUIRK_BROKEN_LE_STATES);
>  
> diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
> index 1641d879d..d39a64663 100644
> --- a/include/net/bluetooth/hci.h
> +++ b/include/net/bluetooth/hci.h
> @@ -375,6 +375,13 @@ enum {
>  	 */
>  	HCI_QUIRK_BROKEN_READ_PAGE_SCAN_TYPE,
>  
> +	/* When this quirk is set, LE connections use the BR/EDR ACL buffer
> +	 * pool instead of the dedicated LE pool reported by the controller.
> +	 * This is required for controllers that expose an unusably small LE
> +	 * pool while accepting LE traffic through their shared ACL pool.
> +	 */
> +	HCI_QUIRK_USE_BREDR_ACL_BUFFERS_FOR_LE,
> +
>  	__HCI_NUM_QUIRKS,
>  };
>  
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index c055d16cf..9936f6365 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -1227,6 +1227,24 @@ static u8 hci_cc_pin_code_neg_reply(struct hci_dev *hdev, void *data,
>  	return rp->status;
>  }
>  
> +/* Use the shared ACL pool for controllers whose dedicated LE pool is known to
> + * be unusable for sustained large-SDU traffic.
> + */
> +static void hci_le_use_shared_acl_buffer(struct hci_dev *hdev)
> +{
> +	if (hci_test_quirk(hdev, HCI_QUIRK_USE_BREDR_ACL_BUFFERS_FOR_LE) &&
> +	    hdev->le_mtu == HCI_MIN_LE_MTU &&
> +	    hdev->acl_mtu > hdev->le_mtu && hdev->acl_pkts) {
> +		bt_dev_dbg(hdev,
> +			   "LE buffer at minimum (%u:%u), sharing ACL buffer %u:%u",
> +			   hdev->le_mtu, hdev->le_pkts,
> +			   hdev->acl_mtu, hdev->acl_pkts);
> +		hdev->le_mtu = 0;
> +		hdev->le_pkts = 0;
> +		hdev->le_cnt = 0;
> +	}
> +}
> +
>  static u8 hci_cc_le_read_buffer_size(struct hci_dev *hdev, void *data,
>  				     struct sk_buff *skb)
>  {
> @@ -1247,6 +1265,8 @@ static u8 hci_cc_le_read_buffer_size(struct hci_dev *hdev, void *data,
>  	if (hdev->le_mtu && hdev->le_mtu < HCI_MIN_LE_MTU)
>  		return HCI_ERROR_INVALID_PARAMETERS;
>  
> +	hci_le_use_shared_acl_buffer(hdev);
> +
>  	return rp->status;
>  }
>  
> @@ -3939,6 +3959,8 @@ static u8 hci_cc_le_read_buffer_size_v2(struct hci_dev *hdev, void *data,
>  	if (hdev->le_mtu && hdev->le_mtu < HCI_MIN_LE_MTU)
>  		return HCI_ERROR_INVALID_PARAMETERS;
>  
> +	hci_le_use_shared_acl_buffer(hdev);
> +
>  	return rp->status;
>  }
>  
> 
> base-commit: 964430c038967fd06643e866f68115664e1a1bd1
>

Re: [RFC PATCH] Bluetooth: btusb: use shared ACL buffers for TP-Link UB500

[Luiz Augusto von Dentz]

Hi Kyle,

On Mon, Oct 12, 2026 at 11:28 PM Kyle Pepper <cochcoder@proton.me> wrote:
>
> The TP-Link UB500 (2357:0604) reports a dedicated LE ACL pool of 27
> bytes by eight packets and a BR/EDR ACL pool of 1021 bytes by six
> packets. Sustained large-SDU LE CoC traffic exhausts the small pool,
> although this controller accepts LE traffic through the larger ACL pool.

Are you sure that is the case, or did you just assume it because it
worked? Those are 2 different things, it maybe the at LE pool is not
actually 27 and the firmware is reporting the minimal rather than
maximum for example.

> Add an explicit HCI quirk and enable it only for the tested USB ID. When
> set, treat the LE buffer as shared so the existing HCI scheduler uses
> the ACL pool. Avoid inferring this from buffer sizes globally because
> other controllers may have legitimate separate pools.
>
> Assisted-by: OpenCode:gpt-6.1-sol
> Signed-off-by: Kyle Pepper <cochcoder@proton.me>
> ---
> Submission review notes (not part of the commit message):
> October 12 N8/UB500 no-quirk trial opens CoC, completes START, DLE
> and 2M, but sends no audio frames and logs two watchdog stalls. The
> host advertises MPS 23 instead of the baseline 512; peer MPS remains
> 168. Firmware pool semantics and simultaneous BR/EDR/LE accounting are
> not established. Keep the quirk device-specific and this proposal RFC.
>
>  drivers/bluetooth/btusb_main.c |  7 ++++++-
>  include/net/bluetooth/hci.h    |  7 +++++++
>  net/bluetooth/hci_event.c      | 22 ++++++++++++++++++++++
>  3 files changed, 35 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/bluetooth/btusb_main.c b/drivers/bluetooth/btusb_main.c
> index 71d8dccb2..5e1fb26ab 100644
> --- a/drivers/bluetooth/btusb_main.c
> +++ b/drivers/bluetooth/btusb_main.c
> @@ -70,6 +70,7 @@ static struct usb_driver btusb_driver;
>  #define BTUSB_INTEL_NO_WBS_SUPPORT     BIT(26)
>  #define BTUSB_ACTIONS_SEMI             BIT(27)
>  #define BTUSB_BARROT                   BIT(28)
> +#define BTUSB_USE_BREDR_ACL_BUFFERS_FOR_LE BIT(29)
>  #define BTUSB_QUALCOMM                 BIT(30)
>
>  static const struct usb_device_id btusb_table[] = {
> @@ -872,7 +873,8 @@ static const struct usb_device_id quirks_table[] = {
>         { USB_DEVICE(0x2c4e, 0x0115), .driver_info = BTUSB_REALTEK |
>                                                      BTUSB_WIDEBAND_SPEECH },
>         { USB_DEVICE(0x2357, 0x0604), .driver_info = BTUSB_REALTEK |
> -                                                    BTUSB_WIDEBAND_SPEECH },
> +                                                    BTUSB_WIDEBAND_SPEECH |
> +                                                    BTUSB_USE_BREDR_ACL_BUFFERS_FOR_LE },
>         { USB_DEVICE(0x2357, 0x0607), .driver_info = BTUSB_REALTEK |
>                                                      BTUSB_WIDEBAND_SPEECH },
>         { USB_DEVICE(0x0b05, 0x190e), .driver_info = BTUSB_REALTEK |
> @@ -4748,6 +4750,9 @@ static int btusb_probe(struct usb_interface *intf,
>         if (id->driver_info & BTUSB_WIDEBAND_SPEECH)
>                 hci_set_quirk(hdev, HCI_QUIRK_WIDEBAND_SPEECH_SUPPORTED);
>
> +       if (id->driver_info & BTUSB_USE_BREDR_ACL_BUFFERS_FOR_LE)
> +               hci_set_quirk(hdev, HCI_QUIRK_USE_BREDR_ACL_BUFFERS_FOR_LE);
> +
>         if (id->driver_info & BTUSB_INVALID_LE_STATES)
>                 hci_set_quirk(hdev, HCI_QUIRK_BROKEN_LE_STATES);
>
> diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
> index 1641d879d..d39a64663 100644
> --- a/include/net/bluetooth/hci.h
> +++ b/include/net/bluetooth/hci.h
> @@ -375,6 +375,13 @@ enum {
>          */
>         HCI_QUIRK_BROKEN_READ_PAGE_SCAN_TYPE,
>
> +       /* When this quirk is set, LE connections use the BR/EDR ACL buffer
> +        * pool instead of the dedicated LE pool reported by the controller.
> +        * This is required for controllers that expose an unusably small LE
> +        * pool while accepting LE traffic through their shared ACL pool.
> +        */
> +       HCI_QUIRK_USE_BREDR_ACL_BUFFERS_FOR_LE,
> +
>         __HCI_NUM_QUIRKS,
>  };
>
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index c055d16cf..9936f6365 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -1227,6 +1227,24 @@ static u8 hci_cc_pin_code_neg_reply(struct hci_dev *hdev, void *data,
>         return rp->status;
>  }
>
> +/* Use the shared ACL pool for controllers whose dedicated LE pool is known to
> + * be unusable for sustained large-SDU traffic.
> + */
> +static void hci_le_use_shared_acl_buffer(struct hci_dev *hdev)
> +{
> +       if (hci_test_quirk(hdev, HCI_QUIRK_USE_BREDR_ACL_BUFFERS_FOR_LE) &&
> +           hdev->le_mtu == HCI_MIN_LE_MTU &&
> +           hdev->acl_mtu > hdev->le_mtu && hdev->acl_pkts) {
> +               bt_dev_dbg(hdev,
> +                          "LE buffer at minimum (%u:%u), sharing ACL buffer %u:%u",
> +                          hdev->le_mtu, hdev->le_pkts,
> +                          hdev->acl_mtu, hdev->acl_pkts);
> +               hdev->le_mtu = 0;
> +               hdev->le_pkts = 0;
> +               hdev->le_cnt = 0;
> +       }
> +}
> +
>  static u8 hci_cc_le_read_buffer_size(struct hci_dev *hdev, void *data,
>                                      struct sk_buff *skb)
>  {
> @@ -1247,6 +1265,8 @@ static u8 hci_cc_le_read_buffer_size(struct hci_dev *hdev, void *data,
>         if (hdev->le_mtu && hdev->le_mtu < HCI_MIN_LE_MTU)
>                 return HCI_ERROR_INVALID_PARAMETERS;
>
> +       hci_le_use_shared_acl_buffer(hdev);
> +
>         return rp->status;
>  }
>
> @@ -3939,6 +3959,8 @@ static u8 hci_cc_le_read_buffer_size_v2(struct hci_dev *hdev, void *data,
>         if (hdev->le_mtu && hdev->le_mtu < HCI_MIN_LE_MTU)
>                 return HCI_ERROR_INVALID_PARAMETERS;
>
> +       hci_le_use_shared_acl_buffer(hdev);
> +
>         return rp->status;
>  }
>
>
> base-commit: 964430c038967fd06643e866f68115664e1a1bd1
>


-- 
Luiz Augusto von Dentz

[RFC PATCH v2 0/1] Bluetooth: btusb: UB500 MTU-only revision

[Kyle Pepper]

Hi Luiz,

> Are you sure that is the case, or did you just assume it because it
> worked?

That's my bad for not reviewing the code enough. Turns out that the forced 
BR/EDR buffer selection wasn't needed, only changing the UB500's host LE 
packet length from 27 to 167 bytes was. 

I tested your packet-length alternative on USB 2357:0604 with Realtek
firmware 0xdfc6d922. Initialization still reports LE length 27 and eight
packets. So I removed forced BR/EDR buffer selection and changed only the
host LE length to 167, keeping the reported eight LE credits.

The 60-second single-CI playback sounded clear. The trace contains 3243
whole 167-byte audio HCI packets and 3269/3269 completed target packets,
including control traffic. Maximum outstanding was three, with zero
remaining after the transport suspended. The unchanged PipeWire socket
requested 672 bytes and received 4608; all 3243 audio sends succeeded
without EAGAIN. Increasing only that socket to 8192 with HCI length 27
previously crackled and delivered about 37 audio frames/s instead of 50.

This shows packets larger than the reported 27 bytes work without
changing host LE credit selection. I used 167 because it
was the length already demonstrated by the working ASHA stream; I have
not established if 251 or 1021-byte LE HCI support exists on this firmware.

The accompanying RFC v2 therefore replaces the shared-pool proposal
with the size-only diagnostic. It deliberately retains the TEST ONLY
log and rejects unexpected initialization values. Feedback
on determining the real limit and firmware scope would help settle that
design.

The acoustic evidence is from the existing Arch-based ASHA 7.2.9 kernel
I've been using to test this and the other patches.The mail workflow 
separately refreshes bluetooth-next and builds the baseline and revised 
btusb_main.o with W=1 before sending so it should all still work upstream.

Changes since v1:
- Do not clear LE packet/credit counts or select BR/EDR accounting.
- Test only host LE packet length, using the existing post_init hook.
- Remove the shared-pool/exhaustion explanation and report the limits.

These changes were assisted by an LLM.

Kyle

Kyle Pepper (1):
  Bluetooth: btusb: test larger LE packets on TP-Link UB500

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


base-commit: 1081a6ef8f1e0661fd52eb3f878691b0b96cdff9
-- 
2.56.0

[RFC PATCH v2 1/1] Bluetooth: btusb: test larger LE packets on TP-Link UB500

[Kyle Pepper]

The tested TP-Link UB500 (2357:0604, RTL8761BU firmware 0xdfc6d922)
reports an LE ACL length of 27 bytes and eight packets. It accepts
167-byte LE HCI ACL packets during ASHA playback. A size-only test
streams clearly with the eight reported LE credits retained, so the
previous shared-buffer workaround does not establish shared pools.

Use post_init to test a host LE ACL length of 167 for this USB ID,
without changing LE packet/credit counts or BR/EDR fields. Refuse
unexpected initialization values rather than applying this diagnostic
to a different reported buffer configuration.

This is an experimental RFC: 167 is a demonstrated working length,
not a measured maximum. The appropriate general limit and firmware
scope still need confirmation. Mixed BR/EDR and LE capacity and
exceptional-congestion behavior have not been established.

The ASHA 7.2.9 trial completes all 3269 HCI packets, including 3243
whole audio SDUs, with a maximum of three outstanding packets. The
human listening verdict is CLEAR. PipeWire and its actual 4608-byte
socket send buffer are unchanged. Increasing only that socket buffer
to 8192 with HCI length 27 previously crackled and underfed the stream.

Prepared with AI assistance for source, evidence analysis and text;
hardware playback and listening were performed by the submitter.

Assisted-by: LLM
Signed-off-by: Kyle Pepper <cochcoder@proton.me>
---
 drivers/bluetooth/btusb_main.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/drivers/bluetooth/btusb_main.c b/drivers/bluetooth/btusb_main.c
index 92a78a7e6..2b955ed4b 100644
--- a/drivers/bluetooth/btusb_main.c
+++ b/drivers/bluetooth/btusb_main.c
@@ -2972,6 +2972,18 @@ static int btusb_setup_realtek(struct hci_dev *hdev)
 	return ret;
 }
 
+/* Private diagnostic: test a known accepted packet size, not a pool claim. */
+static int btusb_ub500_test_post_init(struct hci_dev *hdev)
+{
+	if (hdev->le_mtu != 27 || hdev->le_pkts != 8)
+		return -EINVAL;
+
+	bt_dev_info(hdev, "UB500 TEST ONLY: LE ACL MTU 27 -> 167; LE packets %u unchanged",
+		    hdev->le_pkts);
+	hdev->le_mtu = 167;
+	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 +4727,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_test_post_init;
 		hdev->shutdown = btrtl_shutdown_realtek;
 		hdev->reset = btusb_rtl_reset;
 		hdev->hw_error = btusb_rtl_hw_error;
-- 
2.56.0

Re: [RFC PATCH v2 1/1] Bluetooth: btusb: test larger LE packets on TP-Link UB500

[Luiz Augusto von Dentz]

Hi Kyle,

On Wed, Oct 28, 2026 at 8:14 PM Kyle Pepper <cochcoder@proton.me> wrote:
>
> The tested TP-Link UB500 (2357:0604, RTL8761BU firmware 0xdfc6d922)
> reports an LE ACL length of 27 bytes and eight packets. It accepts
> 167-byte LE HCI ACL packets during ASHA playback. A size-only test
> streams clearly with the eight reported LE credits retained, so the
> previous shared-buffer workaround does not establish shared pools.
>
> Use post_init to test a host LE ACL length of 167 for this USB ID,
> without changing LE packet/credit counts or BR/EDR fields. Refuse
> unexpected initialization values rather than applying this diagnostic
> to a different reported buffer configuration.
>
> This is an experimental RFC: 167 is a demonstrated working length,
> not a measured maximum. The appropriate general limit and firmware
> scope still need confirmation. Mixed BR/EDR and LE capacity and
> exceptional-congestion behavior have not been established.
>
> The ASHA 7.2.9 trial completes all 3269 HCI packets, including 3243
> whole audio SDUs, with a maximum of three outstanding packets. The
> human listening verdict is CLEAR. PipeWire and its actual 4608-byte
> socket send buffer are unchanged. Increasing only that socket buffer
> to 8192 with HCI length 27 previously crackled and underfed the stream.
>
> Prepared with AI assistance for source, evidence analysis and text;
> hardware playback and listening were performed by the submitter.
>
> Assisted-by: LLM
> Signed-off-by: Kyle Pepper <cochcoder@proton.me>
> ---
>  drivers/bluetooth/btusb_main.c | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
>
> diff --git a/drivers/bluetooth/btusb_main.c b/drivers/bluetooth/btusb_main.c
> index 92a78a7e6..2b955ed4b 100644
> --- a/drivers/bluetooth/btusb_main.c
> +++ b/drivers/bluetooth/btusb_main.c
> @@ -2972,6 +2972,18 @@ static int btusb_setup_realtek(struct hci_dev *hdev)
>         return ret;
>  }
>
> +/* Private diagnostic: test a known accepted packet size, not a pool claim. */
> +static int btusb_ub500_test_post_init(struct hci_dev *hdev)
> +{
> +       if (hdev->le_mtu != 27 || hdev->le_pkts != 8)
> +               return -EINVAL;
> +
> +       bt_dev_info(hdev, "UB500 TEST ONLY: LE ACL MTU 27 -> 167; LE packets %u unchanged",
> +                   hdev->le_pkts);
> +       hdev->le_mtu = 167;

Try checking what is the maximun data length it supports, since that
is a strong indication of what the buffer size should be.

> +       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 +4727,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_test_post_init;
>                 hdev->shutdown = btrtl_shutdown_realtek;
>                 hdev->reset = btusb_rtl_reset;
>                 hdev->hw_error = btusb_rtl_hw_error;
> --
> 2.56.0
>
>


-- 
Luiz Augusto von Dentz

RE: Bluetooth: btusb: UB500 MTU-only revision

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 1020 bytes --]

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/series/1195798/

---Test result---

Test Summary:
CheckPatch                    PASS      0.84 seconds
VerifyFixes                   PASS      0.13 seconds
VerifySignedoff               PASS      0.13 seconds
GitLint                       PASS      0.36 seconds
SubjectPrefix                 PASS      0.12 seconds
BuildKernel                   PASS      34.07 seconds
CheckAllWarning               PASS      38.94 seconds
CheckSparse                   PASS      41.12 seconds
BuildKernel32                 PASS      33.93 seconds
CheckKernelLLVM               PASS      37.64 seconds
TestRunnerSetup               PASS      773.60 seconds
IncrementalBuild              PASS      31.00 seconds



https://github.com/bluez/bluetooth-next/pull/1019

---
Regards,
Linux Bluetooth

[RFC PATCH v3 0/1] Bluetooth: btusb: UB500 reported maximum data length

[Kyle Pepper]

Hi Luiz,

LE Read Maximum Data Length reports TX/RX251, while LE Read Buffer
Size reports 27/eight. A separate raw HCI test verified sixteen
251-byte packets received byte-for-byte intact and completed, with
one packet outstanding at a time.

RFC v3 replaces 167 with the reported maximum TX length, retaining
eight LE credits. This establishes HCI251 acceptance, not physical
pool capacity or an absolute HCI limit. Audio with the revised
callback remains untested.

Prepared with LLM assistance.

Kyle

Kyle Pepper (1):
  Bluetooth: btusb: test reported maximum LE length on TP-Link UB500

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


base-commit: 1081a6ef8f1e0661fd52eb3f878691b0b96cdff9
-- 
2.56.0

[RFC PATCH v3 1/1] Bluetooth: btusb: test reported maximum LE length on TP-Link UB500

[Kyle Pepper]

The tested TP-Link UB500 (2357:0604, RTL8761BU firmware 0xdfc6d922)
reports maximum TX and RX data lengths of 251 octets through LE Read
Maximum Data Length, while LE Read Buffer Size reports 27 octets and
eight packets. The previous RFC demonstrated 167-byte HCI packets
with unchanged LE credits during ASHA playback.

Use the reported maximum TX data length as the next experimental host
LE ACL length instead of an ASHA-specific 167-byte constant. Require
the observed 251-byte maximum and 27/eight buffer reply; preserve LE
credits and BR/EDR fields. The maximum-data-length value describes
Link Layer capability and is an indication to test, not proof of the
physical HCI buffer size or pool layout.

A direct HCI user-channel experiment sends sixteen whole packets at
each HCI payload length of 27, 167 and 251 octets from UB500 to a
MediaTek receiver. All 48 payloads are received byte-for-byte intact
and all 48 HCI packets complete, with zero pending. This establishes
251-byte HCI acceptance separately from the reported Link Layer limit.
Only one packet is outstanding at a time; the experiment neither
installs the revised callback nor streams audio.

Keep this a TEST ONLY RFC. Eight simultaneous large packets, larger
HCI limits, mixed BR/EDR capacity, other firmware and sustained audio
with the revised callback have not been established.

Assisted-by: LLM
Signed-off-by: Kyle Pepper <cochcoder@proton.me>
---
 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..b654cf5be 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;
 }
 
+/* Private diagnostic: test the reported Link Layer maximum as an HCI size. */
+static int btusb_ub500_test_post_init(struct hci_dev *hdev)
+{
+	if (hdev->le_mtu != 27 || hdev->le_pkts != 8 ||
+	    hdev->le_max_tx_len != 251)
+		return -EINVAL;
+
+	bt_dev_info(hdev, "UB500 TEST ONLY: LE ACL MTU 27 -> %u; LE packets %u unchanged",
+		    hdev->le_max_tx_len, hdev->le_pkts);
+	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_test_post_init;
 		hdev->shutdown = btrtl_shutdown_realtek;
 		hdev->reset = btusb_rtl_reset;
 		hdev->hw_error = btusb_rtl_hw_error;
-- 
2.56.0

Re: [RFC PATCH v3 1/1] Bluetooth: btusb: test reported maximum LE length on TP-Link UB500

[cochcoder]

Accidentally left in the last comment to keep it as a test only RFC, I've tested the changes and haven't noticed any regressions. Please ignore that. 



On Wednesday, October 28th, 2026 at 10:32 PM, Kyle Pepper <cochcoder@proton.me> wrote:

> The tested TP-Link UB500 (2357:0604, RTL8761BU firmware 0xdfc6d922)
> reports maximum TX and RX data lengths of 251 octets through LE Read
> Maximum Data Length, while LE Read Buffer Size reports 27 octets and
> eight packets. The previous RFC demonstrated 167-byte HCI packets
> with unchanged LE credits during ASHA playback.
> 
> Use the reported maximum TX data length as the next experimental host
> LE ACL length instead of an ASHA-specific 167-byte constant. Require
> the observed 251-byte maximum and 27/eight buffer reply; preserve LE
> credits and BR/EDR fields. The maximum-data-length value describes
> Link Layer capability and is an indication to test, not proof of the
> physical HCI buffer size or pool layout.
> 
> A direct HCI user-channel experiment sends sixteen whole packets at
> each HCI payload length of 27, 167 and 251 octets from UB500 to a
> MediaTek receiver. All 48 payloads are received byte-for-byte intact
> and all 48 HCI packets complete, with zero pending. This establishes
> 251-byte HCI acceptance separately from the reported Link Layer limit.
> Only one packet is outstanding at a time; the experiment neither
> installs the revised callback nor streams audio.
> 
> Keep this a TEST ONLY RFC. Eight simultaneous large packets, larger
> HCI limits, mixed BR/EDR capacity, other firmware and sustained audio
> with the revised callback have not been established.
> 
> Assisted-by: LLM
> Signed-off-by: Kyle Pepper <cochcoder@proton.me>
> ---
>  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..b654cf5be 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;
>  }
>  
> +/* Private diagnostic: test the reported Link Layer maximum as an HCI size. */
> +static int btusb_ub500_test_post_init(struct hci_dev *hdev)
> +{
> +	if (hdev->le_mtu != 27 || hdev->le_pkts != 8 ||
> +	    hdev->le_max_tx_len != 251)
> +		return -EINVAL;
> +
> +	bt_dev_info(hdev, "UB500 TEST ONLY: LE ACL MTU 27 -> %u; LE packets %u unchanged",
> +		    hdev->le_max_tx_len, hdev->le_pkts);
> +	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_test_post_init;
>  		hdev->shutdown = btrtl_shutdown_realtek;
>  		hdev->reset = btusb_rtl_reset;
>  		hdev->hw_error = btusb_rtl_hw_error;
> -- 
> 2.56.0
> 
>

RE: Bluetooth: btusb: UB500 reported maximum data length

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 1020 bytes --]

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/series/1195840/

---Test result---

Test Summary:
CheckPatch                    PASS      0.55 seconds
VerifyFixes                   PASS      0.10 seconds
VerifySignedoff               PASS      0.11 seconds
GitLint                       PASS      0.27 seconds
SubjectPrefix                 PASS      0.10 seconds
BuildKernel                   PASS      22.00 seconds
CheckAllWarning               PASS      30.34 seconds
CheckSparse                   PASS      25.31 seconds
BuildKernel32                 PASS      21.14 seconds
CheckKernelLLVM               PASS      23.84 seconds
TestRunnerSetup               PASS      490.03 seconds
IncrementalBuild              PASS      22.09 seconds



https://github.com/bluez/bluetooth-next/pull/1020

---
Regards,
Linux Bluetooth

Re: [RFC PATCH v3 1/1] Bluetooth: btusb: test reported maximum LE length on TP-Link UB500

[Luiz Augusto von Dentz]

Hi Kyle,

On Wed, Oct 28, 2026 at 10:33 PM Kyle Pepper <cochcoder@proton.me> wrote:
>
> The tested TP-Link UB500 (2357:0604, RTL8761BU firmware 0xdfc6d922)
> reports maximum TX and RX data lengths of 251 octets through LE Read
> Maximum Data Length, while LE Read Buffer Size reports 27 octets and
> eight packets. The previous RFC demonstrated 167-byte HCI packets
> with unchanged LE credits during ASHA playback.
>
> Use the reported maximum TX data length as the next experimental host
> LE ACL length instead of an ASHA-specific 167-byte constant. Require
> the observed 251-byte maximum and 27/eight buffer reply; preserve LE
> credits and BR/EDR fields. The maximum-data-length value describes
> Link Layer capability and is an indication to test, not proof of the
> physical HCI buffer size or pool layout.
>
> A direct HCI user-channel experiment sends sixteen whole packets at
> each HCI payload length of 27, 167 and 251 octets from UB500 to a
> MediaTek receiver. All 48 payloads are received byte-for-byte intact
> and all 48 HCI packets complete, with zero pending. This establishes
> 251-byte HCI acceptance separately from the reported Link Layer limit.
> Only one packet is outstanding at a time; the experiment neither
> installs the revised callback nor streams audio.
>
> Keep this a TEST ONLY RFC. Eight simultaneous large packets, larger
> HCI limits, mixed BR/EDR capacity, other firmware and sustained audio
> with the revised callback have not been established.
>
> Assisted-by: LLM
> Signed-off-by: Kyle Pepper <cochcoder@proton.me>
> ---
>  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..b654cf5be 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;
>  }
>
> +/* Private diagnostic: test the reported Link Layer maximum as an HCI size. */
> +static int btusb_ub500_test_post_init(struct hci_dev *hdev)
> +{
> +       if (hdev->le_mtu != 27 || hdev->le_pkts != 8 ||
> +           hdev->le_max_tx_len != 251)
> +               return -EINVAL;
> +
> +       bt_dev_info(hdev, "UB500 TEST ONLY: LE ACL MTU 27 -> %u; LE packets %u unchanged",
> +                   hdev->le_max_tx_len, hdev->le_pkts);
> +       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_test_post_init;
>                 hdev->shutdown = btrtl_shutdown_realtek;
>                 hdev->reset = btusb_rtl_reset;
>                 hdev->hw_error = btusb_rtl_hw_error;
> --
> 2.56.0

Sashiko flagged 2 problem with these changes:

https://sashiko.dev/#/patchset/20261029023235.1280321-1-cochcoder%40proton.me

Both seem valid to me.

-- 
Luiz Augusto von Dentz

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

[Kyle Pepper]

The TP-Link UB500 (2357:0604) with RTL8761BU firmware 0xdfc6d922
reports an LE HCI packet length of 27 bytes and eight packets. It
separately reports a maximum Link Layer TX data length of 251 bytes.
Direct HCI user-channel transfers verified intact reception and
completion of sixteen 251-byte packets, with one outstanding at a time.

Use 251-byte LE HCI packets automatically on this device when its
reported values match. Limit both the initial LE credits and their
refill ceiling to one, matching the verified number of outstanding
enlarged packets. Leave BR/EDR buffer fields unchanged.

Skip the override when the reported values differ instead of failing
controller initialization. A different firmware revision can continue
using its reported HCI buffers.

Assisted-by: LLM
Signed-off-by: Kyle Pepper <cochcoder@proton.me>
---
v4:
- Skip mismatched buffer reports without failing controller bring-up.
- Limit enlarged LE packets to one initial and refill credit.
- Submit as PATCH v4 and shorten the source wording.

The first two changes address Sashiko review 219856:
https://sashiko.dev/#/patchset/20261029023235.1280321-1-cochcoder%40proton.me

Validation: baseline and revised btusb_main.o compile with W=1; strict
checkpatch and compiled callback regression controls pass. The earlier
raw-radio capture verifies 48 intact payloads and completions: sixteen
each at 27, 167 and 251 bytes, with one outstanding packet at a time.

The Link Layer maximum is not a measurement of HCI storage capacity.
The revised callback has not been exercised on hardware. Sustained audio,
mixed BR/EDR traffic, other firmware and exceptional congestion remain
unverified. The override applies automatically only to the matching UB500
device and the observed buffer reports.

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

diff --git a/drivers/bluetooth/btusb_main.c b/drivers/bluetooth/btusb_main.c
index 92a78a7e6..b32d3acc6 100644
--- a/drivers/bluetooth/btusb_main.c
+++ b/drivers/bluetooth/btusb_main.c
@@ -2972,6 +2972,21 @@ 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 -> 1",
+		    hdev->le_max_tx_len);
+	hdev->le_mtu = hdev->le_max_tx_len;
+	hdev->le_pkts = 1;
+	hdev->le_cnt = 1;
+	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 +4730,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

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

[Luiz Augusto von Dentz]

Hi Kyle,

On Thu, Oct 29, 2026 at 1:47 PM Kyle Pepper <cochcoder@proton.me> wrote:
>
> The TP-Link UB500 (2357:0604) with RTL8761BU firmware 0xdfc6d922
> reports an LE HCI packet length of 27 bytes and eight packets. It
> separately reports a maximum Link Layer TX data length of 251 bytes.
> Direct HCI user-channel transfers verified intact reception and
> completion of sixteen 251-byte packets, with one outstanding at a time.
>
> Use 251-byte LE HCI packets automatically on this device when its
> reported values match. Limit both the initial LE credits and their
> refill ceiling to one, matching the verified number of outstanding
> enlarged packets. Leave BR/EDR buffer fields unchanged.
>
> Skip the override when the reported values differ instead of failing
> controller initialization. A different firmware revision can continue
> using its reported HCI buffers.
>
> Assisted-by: LLM
> Signed-off-by: Kyle Pepper <cochcoder@proton.me>
> ---
> v4:
> - Skip mismatched buffer reports without failing controller bring-up.
> - Limit enlarged LE packets to one initial and refill credit.
> - Submit as PATCH v4 and shorten the source wording.
>
> The first two changes address Sashiko review 219856:
> https://sashiko.dev/#/patchset/20261029023235.1280321-1-cochcoder%40proton.me
>
> Validation: baseline and revised btusb_main.o compile with W=1; strict
> checkpatch and compiled callback regression controls pass. The earlier
> raw-radio capture verifies 48 intact payloads and completions: sixteen
> each at 27, 167 and 251 bytes, with one outstanding packet at a time.
>
> The Link Layer maximum is not a measurement of HCI storage capacity.
> The revised callback has not been exercised on hardware. Sustained audio,
> mixed BR/EDR traffic, other firmware and exceptional congestion remain
> unverified. The override applies automatically only to the matching UB500
> device and the observed buffer reports.
>
>  drivers/bluetooth/btusb_main.c | 18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)
>
> diff --git a/drivers/bluetooth/btusb_main.c b/drivers/bluetooth/btusb_main.c
> index 92a78a7e6..b32d3acc6 100644
> --- a/drivers/bluetooth/btusb_main.c
> +++ b/drivers/bluetooth/btusb_main.c
> @@ -2972,6 +2972,21 @@ 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 -> 1",
> +                   hdev->le_max_tx_len);
> +       hdev->le_mtu = hdev->le_max_tx_len;
> +       hdev->le_pkts = 1;
> +       hdev->le_cnt = 1;

Setting this to 1 would make transfers awfully long, as you would only
be able to send one packet at a time.

> +       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 +4730,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
>
>


-- 
Luiz Augusto von Dentz

RE: [v4,1/1] Bluetooth: btusb: support larger LE packets on TP-Link UB500

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 1020 bytes --]

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/series/1196502/

---Test result---

Test Summary:
CheckPatch                    PASS      1.47 seconds
VerifyFixes                   PASS      1.90 seconds
VerifySignedoff               PASS      0.13 seconds
GitLint                       PASS      0.34 seconds
SubjectPrefix                 PASS      0.29 seconds
BuildKernel                   PASS      31.72 seconds
CheckAllWarning               PASS      42.74 seconds
CheckSparse                   PASS      38.52 seconds
BuildKernel32                 PASS      31.66 seconds
CheckKernelLLVM               PASS      35.47 seconds
TestRunnerSetup               PASS      745.10 seconds
IncrementalBuild              PASS      29.63 seconds



https://github.com/bluez/bluetooth-next/pull/1024

---
Regards,
Linux Bluetooth

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

[Kyle Pepper]

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