kernel/git/next/linux-next.git/drivers/bluetooth/Kconfig, branch master

Bluetooth: btusb: Add support for Qualcomm multi-subsystem QCC2072

2026-09-14T14:29:03+00:00

QCC2072 has a Peripheral (PERI) subsystem to support the BT function unit, the transport wire is owned by PERI and carries both BT-HCI and PERI-HCI frames, as shown below: _______________________________ USB I/F | internal link | BTHOST -------- |---- PERI -------------- BT | |_______________________________| (other on-chip subsystems omitted) PERI has its own command/event/ACL traffic, memdump, and firmware (PATCH and NVM), all different from BT's own, and BTHOST needs to interact with PERI directly. To support multi-subsystem controllers, add btusb_qcom.c/.h as a new transport-specific design: - Multi-subsystem memdump collection. - Generic PERI event handling, and sending a PERI frame then syncing an event sequence. - Downloading PERI firmware (rampatch and NVM). - Recovery on command timeout or hardware error event. BTW, it also supports BT-only chips. /sys/kernel/debug/usb/devices: T: Bus=03 Lev=02 Prnt=02 Port=02 Cnt=01 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0cf3 ProdID=ea00 Rev= 0.01 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms I: If#= 1 Alt= 7 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 65 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 65 Ivl=1ms Signed-off-by: Zijun Hu Signed-off-by: Luiz Augusto von Dentz

Bluetooth: hci_bcsp: Use the shared CRC-CCITT byte helper

2026-09-08T16:01:38+00:00

bcsp_crc_update() processes each byte as two nibbles, requiring two dependent table lookups for every header and payload byte when CRC is enabled. The existing crc_ccitt_byte() helper implements the same reflected polynomial with one lookup per byte. Use it instead of the private nibble-based implementation and select CRC_CCITT for BCSP-only UART configurations as well. The initial CRC value and final bit reversal remain unchanged. This replaces the private 16-entry table with the shared 256-entry table, trading table size for fewer dependent lookups. An exhaustive comparison of all 65536 CRC states and 256 input bytes matches both the old code and a bitwise reference implementation. Signed-off-by: Xuhua Zhang Signed-off-by: Luiz Augusto von Dentz

bluetooth: remove all PCMCIA drivers

2026-06-11T18:24:38+00:00

PCMCIA is almost completely obsolete (the last computers supporting it natively were from ~2009), and the general consensus [1] seems to be that support for it should be gradually removed from the kernel. In 2023, an initial step of removing all the PCMCIA char drivers was taken in commit 9b12f050c76f ("char: pcmcia: remove all the drivers"), and that has not been reverted, so it seems logical to continue this process by removing more low-hanging fruit. These three Bluetooth drivers have had no meaningful changes since their status was discussed in 2022 [2], and are unlikely to have any remaining users. The latest functional change to any of them was a patch to bluecard_cs to fix LED blinking behavior in 2017. The other two drivers have not had any meaningful changes made since 2007. Remove them. Note that even with these drivers removed, it is still possible to use other PCMCIA Bluetooth cards that present themselves as a standard serial port via serial_cs and hciattach while the serial_cs driver is still present. [1] https://lore.kernel.org/all/c5b39544-a4fb-4796-a046-0b9be9853787@app.fastmail.com/ [2] https://lore.kernel.org/all/Y07d7rMvd5++85BJ@owl.dominikbrodowski.net/ Signed-off-by: Ethan Nelson-Moore Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btintel_pcie: Support Product level reset

2026-06-11T18:24:37+00:00

When driver encounters a TOP exception, ACPI methods will be called for Product level reset since Wifi and BT share the same TOP. BT driver will first reprobe the wifi driver and then reprobe BT. Signed-off-by: Chandrashekar Devegowda Signed-off-by: Venkat Rao Bagalkote Signed-off-by: Luiz Augusto von Dentz

Bluetooth: hci_h5: implement CRC data integrity

2025-12-01T20:58:54+00:00

The UART-based H5 protocol supports CRC data integrity checks for reliable packets. The host sets bit 5 in the configuration field of the CONFIG link control message to indicate that CRC is supported. The controller sets the same bit in the CONFIG RESPONSE message to indicate that CRC may be used from then on. Tested on a MangoPi MQ-Pro with a Realtek RTL8723DS Bluetooth controller using the tip of the bluetooth-next tree. Signed-off-by: Javier Nieto Signed-off-by: Luiz Augusto von Dentz

Bluetooth: Fix build after header cleanup

2025-09-20T14:57:44+00:00

Some Kconfig dependencies are needed after my recent cleanup, since the core code has its own option. Since btmtksdio does not actually call h4_recv_buf(), move the definitions it uses outside the BT_HCIUART_H4 gate in hci_uart.h to avoid adding a dependency for btmtksdio. The rest I touched (bpa10x, btmtkuart, and btnxpuart) do really call h4_recv_buf(), so the dependency is required, add it for them. Fixes: 0e272fc7e17d ("Bluetooth: remove duplicate h4_recv_buf() in header") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202508300413.OnIedvRh-lkp@intel.com/ Signed-off-by: Calvin Owens Signed-off-by: Luiz Augusto von Dentz

Revert "Bluetooth: btusb: Configure altsetting for HCI_USER_CHANNEL"

2025-05-21T14:28:08+00:00

This reverts commit 75ddcd5ad40ecd9fbc9f5a7a2ed0e1e74921db3c. This patch doesn't work quite well - It's observed that with this patch HFP is flaky on most of the existing USB Bluetooth controllers: Intel chips sometimes send out no packet for Transparent codec; MTK chips may generate SCO data with a wrong handle for CVSD codec; RTK could split the data with a wrong packet size for Transparent codec; ... etc. Cc: chromeos-bluetooth-upstreaming@chromium.org Signed-off-by: Hsin-chen Chuang Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btusb: Configure altsetting for HCI_USER_CHANNEL

2025-03-07T17:43:27+00:00

Automatically configure the altsetting for HCI_USER_CHANNEL when a SCO is connected. The motivation is to enable the HCI_USER_CHANNEL user to send out SCO data through USB Bluetooth chips, which is mainly used for bidirectional audio transfer (voice call). This was not capable because: - Per Bluetooth Core Spec v5, Vol 4, Part B, 2.1, the corresponding alternate setting should be set based on the air mode in order to transfer SCO data, but - The Linux Bluetooth HCI_USER_CHANNEL exposes the Bluetooth Host Controller Interface to the user space, which is something above the USB layer. The user space is not able to configure the USB alt while keeping the channel open. This patch intercepts the HCI_EV_SYNC_CONN_COMPLETE packets in btusb, extracts the air mode, and configures the alt setting in btusb. This patch is tested on ChromeOS devices. The USB Bluetooth models (CVSD, TRANS alt3 and alt6) could work without a customized kernel. Fixes: b16b327edb4d ("Bluetooth: btusb: add sysfs attribute to control USB alt setting") Signed-off-by: Hsin-chen Chuang Signed-off-by: Luiz Augusto von Dentz

Bluetooth: add HAS_IOPORT dependencies

2024-10-28T21:44:27+00:00

In a future patch HAS_IOPORT=n will disable inb()/outb() and friends at compile time. We thus need to add HAS_IOPORT as dependency for those drivers using them. Co-developed-by: Arnd Bergmann Signed-off-by: Arnd Bergmann Signed-off-by: Niklas Schnelle Acked-by: Lucas De Marchi Signed-off-by: Arnd Bergmann

Bluetooth: hci_uart: Add support for Amlogic HCI UART

2024-09-10T16:44:10+00:00

Add a new HCI protocol HCI_UART_AML for the Amlogic Bluetooth controller. It works on the standard H4 protocol via a 4-wire UART interface, with baud rates up to 4 Mbps. The controller supports two types of commands: the TCI commands and the vendor command. The former is for initial setup including setting baud rates, downloading fw, starting chip and etc, while the latter is for dumping firmware versions and setting public address after firmware updates and normal startup. It was verified on board of T602 (S905X4 + W265S2). dmesg: .. [ 5.313450] Bluetooth: HCI UART protocol AML registered [ 6.506052] Bluetooth: hci0: fw_version: date = 42.28, number = 0xb2fd ... Co-developed-by: Ye He Signed-off-by: Ye He Signed-off-by: Yang Li Signed-off-by: Luiz Augusto von Dentz