[RFC PATCH 4/4] Bluetooth: hci_intel: download the CcP firmware at 921.6 kbaud

From: Cai Yu

Date: Fri Sep 25 2026 - 19:42:49 EST


The CcP bootloader stops acknowledging firmware fragments when the image
is transferred at the operating speed of the driver (3 Mbaud): on a
ThinkPad X1 Fold Gen1 the 801 KB image aborts with a "command 0xfc09 tx
timeout" after ~4 s at 2 and at 3 Mbaud (3 Mbaud completed only 3 out of
11 boots), while 921.6 kbaud completed on every boot in 12.5 s (115.2
kbaud needs 83 s).

This is not a baudrate mismatch: the host divisor is exact for all of
these rates (verified through the clock framework and the dw8250 divisor
helpers) and short commands are answered correctly at 2 and 3 Mbaud - the
link loses a frame on long transfers.

Switch to 921.6 kbaud for the download and restore init_speed before the
firmware is started, which is where the operational firmware expects to
be: this controller does not follow a vendor speed change once its
firmware is running.

Speed measurements for the same controller and image:
115200 -> 83 s 230400 -> 43 s 921600 -> 12.5 s (5/5)
2000000 -> aborts immediately 3000000 -> 3/11

Signed-off-by: Cai Yu <caiyu7372@xxxxxxxxx>
---
drivers/bluetooth/hci_intel.c | 31 ++++++++++++++++++++++++++++++-
1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/drivers/bluetooth/hci_intel.c b/drivers/bluetooth/hci_intel.c
index 5926d1f..41f8e1a 100644
--- a/drivers/bluetooth/hci_intel.c
+++ b/drivers/bluetooth/hci_intel.c
@@ -36,6 +36,11 @@
#define STATE_SUSPENDED 7
#define STATE_LPM_TRANSACTION 8

+/* The CcP bootloader cannot transfer the firmware image at the rates the
+ * driver uses for the operating mode: see the comment in intel_setup().
+ */
+#define INTEL_CCP_DOWNLOAD_SPEED 921600
+
#define HCI_LPM_WAKE_PKT 0xf0
#define HCI_LPM_PKT 0xf1
#define HCI_LPM_MAX_SIZE 10
@@ -539,6 +544,7 @@ static int intel_setup(struct hci_uart *hu)
ktime_t calltime, delta, rettime;
unsigned long long duration;
unsigned int init_speed, oper_speed;
+ bool download_speed_change = false;
int speed_change = 0;
int err;

@@ -652,6 +658,29 @@ static int intel_setup(struct hci_uart *hu)
return -ENODEV;
}

+ /* The controller starts in bootloader mode and does not keep its
+ * firmware across a power cycle, so the image has to be downloaded on
+ * every boot. This bootloader stops acknowledging firmware fragments
+ * when the transfer runs at the operating speed of the driver: on the
+ * ThinkPad X1 Fold Gen1 the 801 KB image aborts with a "command 0xfc09
+ * tx timeout" after ~4 s at 2 and at 3 Mbaud (3 Mbaud completed only 3
+ * out of 11 boots), while 921.6 kbaud completed on every boot in 12.5 s
+ * and 115.2 kbaud needs 83 s. Short commands at the same speeds are
+ * answered correctly, so this is not a baudrate mismatch - the link
+ * loses a frame on long transfers.
+ *
+ * Use 921.6 kbaud for the download and restore init_speed before the
+ * firmware is started: this controller does not follow a vendor speed
+ * change once its firmware is running.
+ */
+ if (hu->serdev && ver.hw_variant == 0x14) {
+ err = intel_set_baudrate(hu, INTEL_CCP_DOWNLOAD_SPEED);
+ if (err)
+ return err;
+
+ download_speed_change = true;
+ }
+
/* Read the secure boot parameters to identify the operating
* details of the bootloader.
*/
@@ -807,7 +836,7 @@ done:
return err;

/* We need to restore the default speed before Intel reset */
- if (speed_change) {
+ if (speed_change || download_speed_change) {
err = intel_set_baudrate(hu, init_speed);
if (err)
return err;