When a Bluetooth controller encounters a coredump, it triggers the
Subsystem Restart (SSR) mechanism. The controller first reports the
coredump data and, once the upload is complete, sends a hw_error
event. The host relies on this event to proceed with subsequent
recovery actions.
If the host has not finished processing the coredump data when the
hw_error event is received, it waits until either the processing is
complete or the 8-second timeout expires before handling the event.
The current implementation clears QCA_MEMDUMP_COLLECTION using
clear_bit(), which does not wake up waiters sleeping in
wait_on_bit_timeout(). As a result, the waiting thread may remain
blocked until the timeout expires even if the coredump collection
has already completed.
Fix this by clearing QCA_MEMDUMP_COLLECTION with
clear_and_wake_up_bit(), which also wakes up the waiting thread and
allows the hw_error handling to proceed immediately.
Test case:
- Trigger a controller coredump using:
hcitool cmd 0x3f 0c 26
- Tested on QCA6390.
- Capture HCI logs using btmon.
- Verify that the delay between receiving the hw_error event and
initiating the power-off sequence is reduced compared to the
timeout-based behavior.
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Use strscpy() instead of snprintf() to copy plain strings with no format
specifiers.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Align each descriptor/index/context region to 128 bytes before
calculating the total DMA pool size. This ensures the memory layout
shared with firmware meets the 128-byte alignment requirement.
The DMA pool alignment is also set to 128 bytes to match the firmware
expectation for all shared structures.
Signed-off-by: Kiran K <kiran.k@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
TI WL183x controllers advertise support for the HCI Enhanced Setup
Synchronous Connection command, but SCO setup fails when the enhanced
path is used. The only working configuration is to fall back to the
legacy HCI Setup Synchronous Connection (0x0028).
This matches the scenario described in commit 05abad8572
("Bluetooth: HCI: Add HCI_QUIRK_BROKEN_ENHANCED_SETUP_SYNC_CONN quirk").
Enable HCI_QUIRK_BROKEN_ENHANCED_SETUP_SYNC_CONN automatically for
devices compatible with:
- ti,wl1831-st
- ti,wl1835-st
- ti,wl1837-st
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Add VID 0489 & PID e11d for MediaTek MT7922 USB Bluetooth chip.
Found in Dynabook GA/ZY (W6GAZY5RCL).
The information in /sys/kernel/debug/usb/devices about the Bluetooth
device is listed as the below.
T: Bus=03 Lev=01 Prnt=01 Port=03 Cnt=02 Dev#= 3 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0489 ProdID=e11d Rev= 1.00
S: Manufacturer=MediaTek Inc.
S: Product=Wireless_Device
S: SerialNumber=000000000
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: Kamiyama Chiaki <nercone@nercone.dev>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
When USB support is disabled, the array is not referenced anywhere,
causing a warning:
drivers/bluetooth/btmtk.c:35:3: error: 'btmtk_mt6639_devs' defined but not used [-Werror=unused-const-variable=]
35 | } btmtk_mt6639_devs[] = {
| ^~~~~~~~~~~~~~~~~
Move it into the #ifdef block.
Fixes: 28b7c5a6db ("Bluetooth: btmtk: Add MT6639 (MT7927) Bluetooth support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Some MT6639 Bluetooth USB interfaces (e.g. IMC Networks 13d3:3588 on
ASUS ROG STRIX X870E-E and ProArt X870E-Creator boards) expose only a
single alternate setting (alt 0) on the ISO interface. The driver
unconditionally requests alt setting 1, which fails with EINVAL on
these devices, causing a ~20 second initialization delay and no LE
audio support.
Check the number of available alternate settings before selecting one.
If only alt 0 exists, use it; otherwise request alt 1 as before.
Closes: https://github.com/jetm/mediatek-mt7927-dkms/pull/39
Signed-off-by: Javier Tia <floss@jetm.me>
Reported-by: Ryan Gilbert <xelnaga@gmail.com>
Tested-by: Ryan Gilbert <xelnaga@gmail.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
The MediaTek MT7927 (Filogic 380) combo WiFi 7 + BT 5.4 module uses
hardware variant 0x6639 for its Bluetooth subsystem. Without this patch,
the chip fails with "Unsupported hardware variant (00006639)" or hangs
during firmware download.
Three changes are needed to support MT6639:
1. CHIPID workaround: On some boards the BT USB MMIO register reads
0x0000 for dev_id, causing the driver to skip the 0x6639 init path.
Force dev_id to 0x6639 only when the USB VID/PID matches a known
MT6639 device, avoiding misdetection if a future chip also reads
zero. This follows the WiFi-side pattern that uses PCI device IDs
to scope the same workaround.
2. Firmware naming: MT6639 uses firmware version prefix "2_1" instead of
"1_1" used by MT7925 and other variants. The firmware path is
mediatek/mt7927/BT_RAM_CODE_MT6639_2_1_hdr.bin, using the mt7927
directory to match the WiFi firmware convention. The filename will
likely change to use MT7927 once MediaTek submits a dedicated
Linux firmware binary.
3. Section filtering: The MT6639 firmware binary contains 9 sections, but
only sections with (dlmodecrctype & 0xff) == 0x01 are Bluetooth-related.
Sending the remaining WiFi/other sections causes an irreversible BT
subsystem hang requiring a full power cycle. This matches the Windows
driver behavior observed via USB captures.
Also add 0x6639 to the reset register (CONNV3) and firmware setup switch
cases alongside the existing 0x7925 handling.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221096
Link: https://github.com/openwrt/mt76/issues/927
Reported-by: Ryan Gilbert <xelnaga@gmail.com>
Signed-off-by: Javier Tia <floss@jetm.me>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Use the common USB helper for looking up bulk and interrupt endpoints
instead of open coding.
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Use the common USB helper for looking up bulk and interrupt endpoints
instead of open coding.
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
When hci_register_dev() fails in hci_uart_register_dev()
HCI_UART_PROTO_INIT is not cleared before calling hu->proto->close(hu)
and setting hu->hdev to NULL. This means incoming UART data will reach
the protocol-specific recv handler in hci_uart_tty_receive() after
resources are freed.
Clear HCI_UART_PROTO_INIT with a write lock before calling
hu->proto->close() and setting hu->hdev to NULL. The write lock ensures
all active readers have completed and no new reader can enter the
protocol recv path before resources are freed.
This allows the protocol-specific recv functions to remove the
"HCI_UART_REGISTERED" guard without risking a null pointer dereference
if hci_register_dev() fails.
Fixes: 5df5dafc17 ("Bluetooth: hci_uart: Fix another race during initialization")
Signed-off-by: Jonathan Rissanen <jonathan.rissanen@axis.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
On platforms using an M.2 slot with both UART and USB support, bt_en is
pulled high by hardware. In this case, software-based power control
should be disabled. The current platforms are Lemans-EVK and Monaco-EVK.
Add QCA_WCN7850 to the existing condition so that power_ctrl_enabled is
cleared when bt_en is not software-controlled (or absent), aligning its
behavior with WCN6750 and WCN6855
Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Replace single space with tab and insert blank line after declaration, according to checkpatch
Signed-off-by: Lukas Kraft <rebootrequired42@gmail.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
The WCN39xx family of WiFi/BT chips incorporates a simple PMU, spreading
voltages over internal rails. Implement support for using powersequencer
for this family of QCA devices in addition to using regulators.
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Add device coredump support for Scorpious Peak2F product.
Signed-off-by: Kiran K <kiran.k@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Add device coredump support for Scorpious Peak2 product.
Signed-off-by: Kiran K <kiran.k@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Add DSBR support for Scorpious Peak2 cores onwards.
Refer commit eb9e749c01 ("Bluetooth: btintel: Allow configuring drive
strength of BRI") for details about DSBR.
Signed-off-by: Kiran K <kiran.k@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Use hardware variant instead of CNVi to send dsbr command.
Signed-off-by: Kiran K <kiran.k@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
If FW image has hybrid signature (ECDSA and LMS) then send CSS header,
ECDSA public key, ECDSA signature, LMS public key, LMS signature and
command buffer to device.
Signed-off-by: Kiran K <kiran.k@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Add MT7902 Bluetooth SDIO support by introducing chip data and
registering the device ID.
Runtime PM is not yet supported by the driver, but normal operation
is unaffected.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Add MT7902 device ID and firmware filename to enable MCU firmware
loading.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Use struct_size(), which provides additional compile-time checks for
structures with flexible array members (e.g., __must_be_array()), to
determine the allocation size for a new 'struct hci_drv_rp_read_info'.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Add USB device ID (04ca:3807) for a Lite-On Wireless_Device containing
a MediaTek MT7921 (MT7920) Bluetooth chipset found in Acer laptops.
Without this entry, btusb binds via the generic USB class-based wildcard
match but never sets the BTUSB_MEDIATEK flag. This means btmtk never
triggers firmware loading, and the driver sends a raw HCI Reset that
the uninitialized chip cannot respond to, resulting in:
Bluetooth: hci0: Opcode 0x0c03 failed: -110
The information in /sys/kernel/debug/usb/devices about the Bluetooth
device is listed as the below:
T: Bus=03 Lev=01 Prnt=01 Port=09 Cnt=01 Dev#=5 Spd=480 MxCh=0
P: Vendor=04ca ProdID=3807 Rev=1.00
S: Manufacturer=MediaTek Inc.
S: Product=Wireless_Device
S: SerialNumber=000000000
C: #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: Dylan Eray <dylan.eray6@gmail.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Replace snprintf("%s", ...) with the faster and more direct strscpy().
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
The BT core skips calling the hci_dev's shutdown method when the HCI
is unregistered. This means that qca_power_off() was not getting called
leaving BT powered on.
This causes regulators / pwrseq providers to not get disabled which also
causes problem when re-loading the module because regulators and pwrseq
providers have an enablecount which now has never dropped to 0, causing
the BT to not get properly reset between rmmod and re-load which causes
initialization failure on the re-load.
Fix this by calling qca_power_off() from qca_close() when BT has not
already been powered off through a qca_hci_shutdown() call.
hci_ldisc.c will call qca_close() after freeing the hdev, so this
means that qca_power_off() can now no longer deref hu->hdev, change
the logging in qca_power_off() to no longer use hu->hdev.
Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
The function called qca_power_off() is actually the hci_dev shutdown
handler, rename it to qca_hci_shutdown() to make this clear.
While the qca_power_shutdown() function is actually the counter-part
of qca_power_on() rename it to qca_power_off() to make this clear.
Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This patch adds the device ID for the BCM4343A2 module, found e.g.
in the muRata 1YN WiFi+BT combined device. The required firmware
file is named 'BCM4343A2.hcd'.
Signed-off-by: Marek Vasut <marex@nabladev.com>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Whenever new chipset support is added to the driver code,
we ended up adding chipset name to the last of the switch case
arising code readability issue because of improper sorting of
the chipset names in various places of the code.
Refactor code such a way that new chipset can be added easily
in the code without compromising code readability.
Signed-off-by: Vivek Sahu <vivek.sahu@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Add a new flag 'BTMTK_FIRMWARE_DL_RETRY'.
If an error occurs during mt79xx firmware download process, this flag
will be set and cleared after a reset. If the flag is already set and
firmware still cannot be loaded successfully after a reset, no further
reset attempts will be made. In other words, if there is a problem during
firmware download, only one reset will be attempted.
Signed-off-by: Chris Lu <chris.lu@mediatek.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
To prevent abnormal controller states, it is necessary to check
status in another part of the mt79xx firmware setup. During this
process, receiving the 'BTMTK_WMT_PATCH_PROGRESS' status is unexpected.
If this occurs, it should be treated as an error, and driver must be
prevented from continuing execution.
Signed-off-by: Chris Lu <chris.lu@mediatek.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
If retries are exhausted, driver should not do futher operation.
During mt79xx firmware download process, if the retry count reaches0,
driver will return an -EIO error and release the firmware resources.
Signed-off-by: Chris Lu <chris.lu@mediatek.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
There is no point in having the label since all it does is return the
value in the 'err' variable. Instead make every goto return directly
and remove the label.
Signed-off-by: Dongyang Jin <jindongyang@kylinos.cn>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Commit 5df5dafc17 ("Bluetooth: hci_uart: Fix another race during
initialization") fixed a race for hci commands sent during initialization.
However, there is still a race that happens if an hci event from one of
these commands is received before HCI_UART_REGISTERED has been set at
the end of hci_uart_register_dev(). The event will be ignored which
causes the command to fail with a timeout in the log:
"Bluetooth: hci0: command 0x1003 tx timeout"
This is because the hci event receive path (hci_uart_tty_receive ->
h4_recv) requires HCI_UART_REGISTERED to be set in h4_recv(), while the
hci command transmit path (hci_uart_send_frame -> h4_enqueue) only
requires HCI_UART_PROTO_INIT to be set in hci_uart_send_frame().
The check for HCI_UART_REGISTERED was originally added in commit
c257820291 ("Bluetooth: Fix H4 crash from incoming UART packets")
to fix a crash caused by hu->hdev being null dereferenced. That can no
longer happen: once HCI_UART_PROTO_INIT is set in hci_uart_register_dev()
all pointers (hu, hu->priv and hu->hdev) are valid, and
hci_uart_tty_receive() already calls h4_recv() on HCI_UART_PROTO_INIT
or HCI_UART_PROTO_READY.
Remove the check for HCI_UART_REGISTERED in h4_recv() to fix the race
condition.
Fixes: 5df5dafc17 ("Bluetooth: hci_uart: Fix another race during initialization")
Signed-off-by: Jonathan Rissanen <jonathan.rissanen@axis.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
