linux-toradex.git/drivers/bluetooth, branch v6.17-rc1 Linux kernel for Apalis and Colibri modules Bluetooth: btintel_pcie: Fix Alive Context State Handling 2025-07-23T14:34:30+00:00 Kiran K kiran.k@intel.com 2025-07-21T09:44:37+00:00 54713670372e17903bff948f5d0859da02106f09 The firmware raises an alive interrupt upon sending the HCI_RESET or BTINTEL_HCI_OP_RESET command. As part of handling the reset command, firmware initializes the hardware and data path and raises the alive interrupt. Upon receiving the alive interrupt, the driver must enable the data path and grant RX buffers to the firmware before sending any commands. The alive context maintained in the driver must be updated before sending BTINTEL_HCI_OP_RESET or HCI_OP_RESET to prevent a potential race condition where the context is also updated in the threaded IRQ. The issue was observed in a stress reboot usecase (1/25) using "sudo reboot" command where the firmware download was failing as the driver was not granting RX buffer to firmware due to race condition. Bluetooth: hci0: API lock is disabled Bluetooth: hci0: Debug lock is disabled Bluetooth: hci0: Minimum firmware build 1 week 10 2014 Bluetooth: hci0: Bootloader timestamp 2023.43 buildtype 1 build 11631 Bluetooth: hci0: Found device firmware: intel/ibt-00a0-00a1-iml.sfi Bluetooth: hci0: Boot Address: 0xb0301000 Bluetooth: hci0: Firmware Version: 167-12.25 Bluetooth: hci0: Waiting for firmware download to complete Bluetooth: hci0: Firmware loaded in 99902 usecs Bluetooth: hci0: Alive context: fw_dl old_boot_stage: 0xa0db0003 new_boot_stage: 0xa0db0003 Bluetooth: hci0: sent cmd: 0xfc01 alive context changed: fw_dl -> intel_reset1 Bluetooth: hci0: Waiting for device to boot Bluetooth: hci0: Device boot timeout Bluetooth: hci0: Firmware download retry count: 1 Fixes: 05c200c8f029 ("Bluetooth: btintel_pcie: Add handshake between driver and firmware") Signed-off-by: Kiran K <kiran.k@intel.com> Signed-off-by: Sai Teja Aluvala <aluvala.sai.teja@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> 
The firmware raises an alive interrupt upon sending the HCI_RESET or
BTINTEL_HCI_OP_RESET command. As part of handling the reset command,
firmware initializes the hardware and data path and raises the alive
interrupt. Upon receiving the alive interrupt, the driver must enable
the data path and grant RX buffers to the firmware before sending any
commands.

The alive context maintained in the driver must be updated before
sending BTINTEL_HCI_OP_RESET or HCI_OP_RESET to prevent a potential race
condition where the context is also updated in the threaded IRQ.

The issue was observed in a stress reboot usecase (1/25) using "sudo
reboot" command where the firmware download was failing as the driver
was not granting RX buffer to firmware due to race condition.

Bluetooth: hci0: API lock is disabled
Bluetooth: hci0: Debug lock is disabled
Bluetooth: hci0: Minimum firmware build 1 week 10 2014
Bluetooth: hci0: Bootloader timestamp 2023.43 buildtype 1 build 11631
Bluetooth: hci0: Found device firmware: intel/ibt-00a0-00a1-iml.sfi
Bluetooth: hci0: Boot Address: 0xb0301000
Bluetooth: hci0: Firmware Version: 167-12.25
Bluetooth: hci0: Waiting for firmware download to complete
Bluetooth: hci0: Firmware loaded in 99902 usecs
Bluetooth: hci0: Alive context: fw_dl old_boot_stage: 0xa0db0003
           new_boot_stage: 0xa0db0003
Bluetooth: hci0: sent cmd: 0xfc01 alive context changed:
           fw_dl  ->  intel_reset1
Bluetooth: hci0: Waiting for device to boot
Bluetooth: hci0: Device boot timeout
Bluetooth: hci0: Firmware download retry count: 1

Fixes: 05c200c8f029 ("Bluetooth: btintel_pcie: Add handshake between driver and firmware")
Signed-off-by: Kiran K <kiran.k@intel.com>
Signed-off-by: Sai Teja Aluvala <aluvala.sai.teja@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Bluetooth: btintel_pcie: Make driver wait for alive interrupt 2025-07-23T14:34:14+00:00 Kiran K kiran.k@intel.com 2025-07-21T09:44:36+00:00 69b3d3acf3dba21e2abad863c80c7114eb110b3d The firmware raises an alive interrupt upon receiving the HCI_RESET or BTINTEL_HCI_OP_RESET (Intel reset - 0xfc01) command. This change fixes the driver to properly wait for the alive interrupt to avoid driver sending commands to firmware before it is ready to process. For details on the handshake between the driver and firmware, refer to commit 05c200c8f029 ("Bluetooth: btintel_pcie: Add handshake between driver and firmware"). As the driver needs to handle two interrupts for HCI_OP_RESET and BTINTEL_HCI_OP_RESET, the firmware ensures that the TX completion interrupt is always followed by the alive interrupt. Fixes: 05c200c8f029 ("Bluetooth: btintel_pcie: Add handshake between driver and firmware") Signed-off-by: Sai Teja Aluvala <aluvala.sai.teja@intel.com> Signed-off-by: Kiran K <kiran.k@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> 
The firmware raises an alive interrupt upon receiving the HCI_RESET or
BTINTEL_HCI_OP_RESET (Intel reset - 0xfc01) command. This change fixes
the driver to properly wait for the alive interrupt to avoid driver
sending commands to firmware before it is ready to process.

For details on the handshake between the driver and firmware, refer to
commit 05c200c8f029 ("Bluetooth: btintel_pcie: Add handshake between
driver and firmware").

As the driver needs to handle two interrupts for HCI_OP_RESET and
BTINTEL_HCI_OP_RESET, the firmware ensures that the TX completion
interrupt is always followed by the alive interrupt.

Fixes: 05c200c8f029 ("Bluetooth: btintel_pcie: Add handshake between driver and firmware")
Signed-off-by: Sai Teja Aluvala <aluvala.sai.teja@intel.com>
Signed-off-by: Kiran K <kiran.k@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Bluetooth: btusb: Add one more ID 0x28de:0x1401 for Qualcomm WCN6855 2025-07-23T14:33:13+00:00 Zijun Hu Zijun.Hu@oss.qualcomm.com 2025-07-15T14:27:08+00:00 c20284f73417581a6097401a4a93843ed670f23b Add one more part with ID (0x28de, 0x1401) to usb_device_id table for Qualcomm WCN6855, and its device info from /sys/kernel/debug/usb/devices is shown below: T: Bus=03 Lev=01 Prnt=01 Port=09 Cnt=03 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=28de ProdID=1401 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= 16 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 <Zijun.Hu@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> 
Add one more part with ID (0x28de, 0x1401) to usb_device_id table for
Qualcomm WCN6855, and its device info from /sys/kernel/debug/usb/devices
is shown below:

T:  Bus=03 Lev=01 Prnt=01 Port=09 Cnt=03 Dev#=  4 Spd=12   MxCh= 0
D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=28de ProdID=1401 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=  16 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 <Zijun.Hu@oss.qualcomm.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Bluetooth: btusb: Sort WCN6855 device IDs by VID and PID 2025-07-23T14:32:59+00:00 Zijun Hu Zijun.Hu@oss.qualcomm.com 2025-07-15T14:27:07+00:00 986cb42191b6125dfccbc7ac2ea5ae5f3661eb3b Sort WCN6855 device IDs to more easily manage them. Signed-off-by: Zijun Hu <Zijun.Hu@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> 
Sort WCN6855 device IDs to more easily manage them.

Signed-off-by: Zijun Hu <Zijun.Hu@oss.qualcomm.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Bluetooth: btusb: QCA: Support downloading custom-made firmwares 2025-07-23T14:32:42+00:00 Zijun Hu zijun.hu@oss.qualcomm.com 2025-07-15T12:40:14+00:00 a3f9f6dd047af711341a2367a8b08a3ade31438d There are custom-made firmwares based on board ID for a given QCA BT chip sometimes, and they are different with existing firmwares and put in a separate subdirectory to avoid conflict, for example: QCA2066, as a variant of WCN6855, has firmwares under 'qca/QCA2066/' of linux-firmware repository. Support downloading custom-made firmwares based on a table newly added. Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> 
There are custom-made firmwares based on board ID for a given QCA BT
chip sometimes, and they are different with existing firmwares and put
in a separate subdirectory to avoid conflict, for example:
QCA2066, as a variant of WCN6855, has firmwares under 'qca/QCA2066/'
of linux-firmware repository.

Support downloading custom-made firmwares based on a table newly added.

Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Bluetooth: btnxpuart: Add uevents for FW dump and FW download complete 2025-07-23T14:32:23+00:00 Neeraj Sanjay Kale neeraj.sanjaykale@nxp.com 2025-07-14T07:30:16+00:00 085ee7cf937ce1f524cc6e68e81f109ddb1682c7 This adds uevents which will be generated whenever FW dump is triggered, FW dump is complete and FW (re)download is done. This feature is needed for IW612 chipset, which is a tri-radio chipset, where WLAN runs on CPU1 and BT and Zigbee runs on CPU2. Currently, whenever BT FW crashes, and FW dump is in progress, there is no way for 15.4 application to know that CPU2 is in bad state, and when it will be recovered. With the help of these uevents and udev rules, the 15.4 app, or any userspace application can be alerted whenever CPU2 goes in bad state and recoveres after BTNXPUART reloads the firmware. [ 334.255154] Bluetooth: hci0: ==== Start FW dump === [ 334.261003] Bluetooth: hci0: ==== Send uevent: BTNXPUART_DEV=serial0-0:BTNXPUART_STATE=FW_DUMP_ACTIVE === [ 351.486048] Bluetooth: hci0: ==== FW dump complete === [ 351.491356] Bluetooth: hci0: ==== Send uevent: BTNXPUART_DEV=serial0-0:BTNXPUART_STATE=FW_DUMP_DONE === [ 352.028974] Bluetooth: hci0: ChipID: 7601, Version: 0 [ 352.034490] Bluetooth: hci0: Request Firmware: nxp/uartspi_n61x_v1.bin.se [ 353.979977] Bluetooth: hci0: FW Download Complete: 417064 bytes [ 355.197222] Bluetooth: hci0: ==== Send uevent: BTNXPUART_DEV=serial0-0:BTNXPUART_STATE=FW_READY === Tested this change by creating a simple udev rule to store the BTNXPUART_STATE value in a ~/<BTNXPUART_DEV>/state file, and running 15.4 traffic. The 15.4 packets were sent over SPI only when BTNXPUART_STATE was FW_READY. Signed-off-by: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com> Tested-by: Jean-Yves Salaün <jean-yves.salaun@nxp.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> 
This adds uevents which will be generated whenever FW dump is triggered,
FW dump is complete and FW (re)download is done.

This feature is needed for IW612 chipset, which is a tri-radio chipset,
where WLAN runs on CPU1 and BT and Zigbee runs on CPU2.

Currently, whenever BT FW crashes, and FW dump is in progress, there is
no way for 15.4 application to know that CPU2 is in bad state, and when
it will be recovered.

With the help of these uevents and udev rules, the 15.4 app, or any
userspace application can be alerted whenever CPU2 goes in bad state and
recoveres after BTNXPUART reloads the firmware.

[  334.255154] Bluetooth: hci0: ==== Start FW dump ===
[  334.261003] Bluetooth: hci0: ==== Send uevent: BTNXPUART_DEV=serial0-0:BTNXPUART_STATE=FW_DUMP_ACTIVE ===
[  351.486048] Bluetooth: hci0: ==== FW dump complete ===
[  351.491356] Bluetooth: hci0: ==== Send uevent: BTNXPUART_DEV=serial0-0:BTNXPUART_STATE=FW_DUMP_DONE ===
[  352.028974] Bluetooth: hci0: ChipID: 7601, Version: 0
[  352.034490] Bluetooth: hci0: Request Firmware: nxp/uartspi_n61x_v1.bin.se
[  353.979977] Bluetooth: hci0: FW Download Complete: 417064 bytes
[  355.197222] Bluetooth: hci0: ==== Send uevent: BTNXPUART_DEV=serial0-0:BTNXPUART_STATE=FW_READY ===

Tested this change by creating a simple udev rule to store the
BTNXPUART_STATE value in a ~/<BTNXPUART_DEV>/state file, and running
15.4 traffic.

The 15.4 packets were sent over SPI only when BTNXPUART_STATE was
FW_READY.

Signed-off-by: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com>
Tested-by: Jean-Yves Salaün <jean-yves.salaun@nxp.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Bluetooth: btnxpuart: Correct the Independent Reset handling after FW dump 2025-07-23T14:32:06+00:00 Neeraj Sanjay Kale neeraj.sanjaykale@nxp.com 2025-07-14T07:30:15+00:00 634fd53a63be4798da356dbc7251046b713d992a This adds proper handling for the independent reset command sent by the driver after FW dump is complete. In normal scenario, the independent reset vendor command gives a success response before jumping to bootcode. However, when FW goes in a bad state, and sends out FW dump packets, the independent reset command does not get any response from the controller. [ 159.807732] Bluetooth: hci0: ==== Start FW dump === [ 180.759060] Bluetooth: hci0: ==== FW dump complete === [ 182.779208] Bluetooth: hci0: command 0xfcfc tx timeout [ 183.364974] Bluetooth: hci0: ChipID: 7601, Version: 0 [ 183.368490] Bluetooth: hci0: Request Firmware: nxp/uartspi_n61x_v1.bin.se [ 184.679977] Bluetooth: hci0: FW Download Complete: 417064 bytes [ 187.963102] Bluetooth: hci0: Opcode 0x0c03 failed: -110 As a fix for such scenario, the independent reset vendor command is sent using the __hci_cmd_send() API, which does not expect any response for vendor commands. __hci_cmd_send is non blocking, so before the tx_work is scheduled, it sometimes gets canceled and 3F|FC command is never sent. Adding a small delay after __hci_cmd_send allows the command to be sent to the controller. Signed-off-by: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com> Tested-by: Jean-Yves Salaün <jean-yves.salaun@nxp.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> 
This adds proper handling for the independent reset command sent by the
driver after FW dump is complete.

In normal scenario, the independent reset vendor command gives a success
response before jumping to bootcode.

However, when FW goes in a bad state, and sends out FW dump packets, the
independent reset command does not get any response from the controller.

[  159.807732] Bluetooth: hci0: ==== Start FW dump ===
[  180.759060] Bluetooth: hci0: ==== FW dump complete ===
[  182.779208] Bluetooth: hci0: command 0xfcfc tx timeout
[  183.364974] Bluetooth: hci0: ChipID: 7601, Version: 0
[  183.368490] Bluetooth: hci0: Request Firmware: nxp/uartspi_n61x_v1.bin.se
[  184.679977] Bluetooth: hci0: FW Download Complete: 417064 bytes
[  187.963102] Bluetooth: hci0: Opcode 0x0c03 failed: -110

As a fix for such scenario, the independent reset vendor command is sent
using the __hci_cmd_send() API, which does not expect any response for
vendor commands.

__hci_cmd_send is non blocking, so before the tx_work is scheduled, it
sometimes gets canceled and 3F|FC command is never sent. Adding a small
delay after __hci_cmd_send allows the command to be sent to the
controller.

Signed-off-by: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com>
Tested-by: Jean-Yves Salaün <jean-yves.salaun@nxp.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Bluetooth: btintel: Define a macro for Intel Reset vendor command 2025-07-23T14:31:03+00:00 Kiran K kiran.k@intel.com 2025-07-11T10:07:25+00:00 15843c7fdba65568704245fd3ea2aa3aa2d50825 Use macro for Intel Reset command (0xfc01) instead of hard coded value. Signed-off-by: Kiran K <kiran.k@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> 
Use macro for Intel Reset command (0xfc01) instead of hard coded value.

Signed-off-by: Kiran K <kiran.k@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Bluetooth: hci_bcm4377: Fix typo in comment 2025-07-23T14:30:04+00:00 Bastien Nocera hadess@hadess.net 2025-07-03T17:16:58+00:00 0e77524dbc09e3d9f1cfa7d4a15b988466f89b1f Found by codespell. Signed-off-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> 
Found by codespell.

Signed-off-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Bluetooth: btrtl: Fix typo in comment 2025-07-23T14:29:50+00:00 Bastien Nocera hadess@hadess.net 2025-07-03T17:16:57+00:00 887f83d4f2fac7c2029f345eac649aff7679db47 Found by codespell. Signed-off-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> 
Found by codespell.

Signed-off-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>