- 15 Jul, 2024 40 commits
-
-
Luiz Augusto von Dentz authored
hci_request functions are considered deprecated so this replaces the usage of hci_req_sync with hci_inquiry_sync. Signed-off-by:Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Rafał Miłecki authored
This helps validating DTS files. Introduced changes: 1. Dropped serial details from example 2. Added required example include Signed-off-by:
Rafał Miłecki <rafal@milecki.pl> Reviewed-by:
Rob Herring (Arm) <robh@kernel.org> Signed-off-by:
-
Luiz Augusto von Dentz authored
__hci_cmd_sync_status shall only be used if hci_req_sync_lock is _not_ required which is not the case of hci_dev_cmd so it needs to use hci_cmd_sync_status which uses hci_req_sync_lock internally. Fixes: f1a8f402 ("Bluetooth: L2CAP: Fix deadlock") Reported-by:
Pauli Virtanen <pav@iki.fi> Signed-off-by:
-
WangYuli authored
Add the support ID(0x13d3, 0x3591) to usb_device_id table for Realtek RTL8852BE. The device table is as follows: T: Bus=01 Lev=02 Prnt=03 Port=00 Cnt=01 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3591 Rev= 0.00 S: Manufacturer=Realtek S: Product=Bluetooth Radio S: SerialNumber=00e04c000001 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA 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=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) 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=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms Cc: stable@vger.kernel.org Signed-off-by:
Wentao Guan <guanwentao@uniontech.com> Signed-off-by:
WangYuli <wangyuli@uniontech.com> Signed-off-by:
-
Dmitry Antipov authored
Remove unused and set but otherwise unused 'discovery_old_state' and 'sco_last_tx' members of 'struct hci_dev'. The first one is a leftover after commit 182ee45d ("Bluetooth: hci_sync: Rework hci_suspend_notifier"); the second one is originated from ancient 2.4.19 and I was unable to find any actual use since that. Signed-off-by:
Dmitry Antipov <dmantipov@yandex.ru> Reviewed-by:
Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by:
-
Kiran K authored
Use INTEL_HW_VARIANT() instead of CNVi Id to decide to load Intermediate Loader (IML) image. Fix the driver loading incorrect firmware for BlazarU product. dmesg: ..... [146.111834] Bluetooth: hci0: Minimum firmware build 1 week 10 2014 [146.111839] Bluetooth: hci0: Bootloader timestamp 2022.18 buildtype 1 build 16362 [146.111848] Bluetooth: hci0: No support for _PRR ACPI method [146.112204] Bluetooth: hci0: Failed to load Intel firmware file intel/ibt-0291-0291-iml.sfi (-2) Fixes: 164c62f9 ("Bluetooth: btintel: Add firmware ID to firmware name") Reported-by:
Tsigan, Vladislav <vladislav.tsigan@intel.com> Signed-off-by:
Kiran K <kiran.k@intel.com> Signed-off-by:
-
Bartosz Golaszewski authored
We unnecessarily fallthrough the case for QCA6390 when initializing the device and hit the condition where - due to the lack of the enable-gpio - we disable power management despite using the power sequencer. We don't need to look for clocks on this model so it makes more sense to just register the hci device and break the switch. Reported-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Fixes: 9a15ce68 ("Bluetooth: qca: use the power sequencer for QCA6390") Signed-off-by:
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Acked-by:
-
Krzysztof Kozlowski authored
BT_HCIUART_QCA, which is a bool and an HCI UART component, uses now power sequencing, so we need to be sure BT_HCIUART_QCA=y and POWER_SEQUENCING=m cannot happen: /usr/bin/aarch64-linux-gnu-ld: drivers/bluetooth/hci_qca.o: in function `qca_serdev_probe': drivers/bluetooth/hci_qca.c:2401:(.text+0xc48): undefined reference to `devm_pwrseq_get' /usr/bin/aarch64-linux-gnu-ld: drivers/bluetooth/hci_qca.o: in function `qca_power_shutdown': drivers/bluetooth/hci_qca.c:2192:(.text+0x29e8): undefined reference to `pwrseq_power_off' /usr/bin/aarch64-linux-gnu-ld: drivers/bluetooth/hci_qca.o: in function `qca_power_on': drivers/bluetooth/hci_qca.c:1808:(.text+0x3390): undefined reference to `pwrseq_power_on' Fixes: 9a15ce68 ("Bluetooth: qca: use the power sequencer for QCA6390") Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
-
Paul Menzel authored
Fixes: f3b845e0 ("Bluetooth: btintel: Add support to download intermediate loader") Cc: Kiran K <kiran.k@intel.com> Signed-off-by:
-
Bartosz Golaszewski authored
Use the pwrseq subsystem's consumer API to run the power-up sequence for the Bluetooth module of the QCA6390 package. Tested-by:
Amit Pundir <amit.pundir@linaro.org> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-QRD, SM8650-QRD & SM8650-HDK Tested-by: Caleb Connolly <caleb.connolly@linaro.org> # OnePlus 8T Signed-off-by:
-
Bartosz Golaszewski authored
QCA6390 has a compatible listed in the bindings but is missing the regulators description. Add the missing supply property and list the required ones in the allOf section. Reviewed-by:
-
Luiz Augusto von Dentz authored
Merge tag 'pwrseq-initial-for-v6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux into HEAD Initial implementation of the power sequencing subsystem for linux v6.11
-
Kiran K authored
From BlazarI onwards, driver shall append the firmware ID (usually represents transport type) while constructing the firmware name. Firmware ID is returned on Intel Read Version command. The new firmware file name for operational image and ddc file shall be, ibt-<cnvi_top type+cnvi_top step>-<cnvr_top type+cnvr_top step-fw_id>.[sfi|ddc] dmesg snippet from BlazarI pcie product: ...... [17.098858] Bluetooth: hci0: Found device firmware: intel/ibt-0190-0291-pci.sfi [17.098871] Bluetooth: hci0: Boot Address: 0x10000800 [17.098872] Bluetooth: hci0: Firmware Version: 214-25.24 [17.158229] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [17.158236] Bluetooth: BNEP filters: protocol multicast [17.158241] Bluetooth: BNEP socket layer initialized [17.468789] Bluetooth: hci0: Waiting for firmware download to complete [17.468793] Bluetooth: hci0: Firmware loaded in 361262 usecs [17.468872] Bluetooth: hci0: Waiting for device to boot [17.504148] Bluetooth: hci0: Device booted in 34512 usecs [17.504148] Bluetooth: hci0: Malformed MSFT vendor event: 0x02 [17.504682] Bluetooth: hci0: Found Intel DDC parameters: intel/ibt-0190-0291-pci.ddc [17.505380] Bluetooth: hci0: Applying Intel DDC parameters completed [17.505622] Bluetooth: hci0: Firmware timestamp 2024.25 buildtype 3 build 64726 [17.505624] Bluetooth: hci0: Firmware SHA1: 0x9f4adddc [17.505838] Bluetooth: hci0: Fseq status: Success (0x00) [17.505839] Bluetooth: hci0: Fseq executed: 00.00.04.183 [17.505840] Bluetooth: hci0: Fseq BT Top: 00.00.04.183 dmesg snippet from BlazarI usb product: ....... [14.212072] Bluetooth: hci0: Found device firmware: intel/ibt-0190-0291-usb.sfi [14.212091] Bluetooth: hci0: Boot Address: 0x10000800 [14.212093] Bluetooth: hci0: Firmware Version: 79-21.24 [14.262125] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [14.262129] Bluetooth: BNEP filters: protocol multicast [14.262133] Bluetooth: BNEP socket layer initialized [15.865421] Bluetooth: hci0: Waiting for firmware download to complete [15.865991] Bluetooth: hci0: Firmware loaded in 1615150 usecs [15.866017] Bluetooth: hci0: Waiting for device to boot [15.899934] Bluetooth: hci0: Malformed MSFT vendor event: 0x02 [15.899942] Bluetooth: hci0: Device booted in 33139 usecs [15.900172] Bluetooth: hci0: Found Intel DDC parameters: intel/ibt-0190-0291-usb.ddc [15.901928] Bluetooth: hci0: Applying Intel DDC parameters completed [15.904993] Bluetooth: hci0: Firmware timestamp 2024.21 buildtype 3 build 63311 [15.904996] Bluetooth: hci0: Firmware SHA1: 0x8b217cf7 [15.908929] Bluetooth: hci0: Fseq status: Success (0x00) [15.908934] Bluetooth: hci0: Fseq executed: 00.00.04.180 [15.908935] Bluetooth: hci0: Fseq BT Top: 00.00.04.180 Signed-off-by:
-
Dmitry Antipov authored
After commit 78db544b ("Bluetooth: hci_core: Remove le_restart_scan work"), 'scan_start' and 'scan_duration' of 'struct discovery_state' are still initialized but actually unused. So remove the aforementioned fields and adjust 'hci_discovery_filter_clear()' and 'le_scan_disable()' accordingly. Compile tested only. Fixes: 78db544b ("Bluetooth: hci_core: Remove le_restart_scan work") Signed-off-by:
-
Hilda Wu authored
Add the support ID 0489:e125 to usb_device_id table for Realtek RTL8852B chip. The device info from /sys/kernel/debug/usb/devices as below. T: Bus=01 Lev=01 Prnt=01 Port=07 Cnt=03 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e125 Rev= 0.00 S: Manufacturer=Realtek S: Product=Bluetooth Radio S: SerialNumber=00e04c000001 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA 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=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) 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=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by:
Hilda Wu <hildawu@realtek.com> Signed-off-by:
-
Iulia Tanasescu authored
On a Broadcast Sink, after synchronizing to the PA transimitted by a Broadcast Source, the BIGInfo advertising reports emitted by the Controller hold the encryption field, which indicates whether the Broadcast Source is transmitting encrypted streams. This updates the PA sync hcon QoS with the encryption value reported in the BIGInfo report, so that this information is accurate if the userspace tries to access the QoS struct via getsockopt. Fixes: 1d11d70d ("Bluetooth: ISO: Pass BIG encryption info through QoS") Signed-off-by:
Iulia Tanasescu <iulia.tanasescu@nxp.com> Signed-off-by:
-
Neeraj Sanjay Kale authored
This handles the timeout error codes sent by the chip as part of the bootloader signatures during firmware download process. When the bootloader does not receive a response packet from the host within a specific time, it adds an error code to the bootloader signature while requesting for the FW chunk from the same offset. The host is expected to clear this error code with a NAK, and reply to only those bootloader signatures which have error code 0. However, the driver was ignoring this error code and replying with the firmware chunks instead, which is apparently ignored by the chip and the chip resends the same bootloader signature with the error code again. This happens in a loop until the error code self clears and firmware download proceeds ahead, adding a couple of milliseconds to the total firmware download time. Commit 689ca16e was an initial implementation which simply printed the following line during driver debug: - FW Download received err 0x04 from chip This commit adds the expected handling to the error codes. This error handling is valid for data_req bootloader signatures for V3 and future bootloader versions. Signed-off-by:
Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com> Fixes: 689ca16e ("Bluetooth: NXP: Add protocol support for NXP Bluetooth chipsets") Signed-off-by:
-
Neeraj Sanjay Kale authored
This updates the firmware names of 3 chipsets: w8987, w8997, w9098. These changes are been done to standardize chip specific firmware file names to be in sync with firmware names of newer chipsets. The naming convention for BT-only files would be as follows: For dual-radio WiFi+BT chipsets: - <protocol-BT><chip-name>_bt_v<HW-version>.bin For tri-radio WiFi+BT+15.4 chipsets: - <protocol-BT><protocol-15.4><chip-name>_bt_v<HW-version>.bin To maintain backward compatibility, this commit adds a provision to request older firmware file name, if new firmware file name not found in /lib/firmware/nxp/. A new device tree property has been introduced called firmware-name, to override the hardcoded firmware names (old and new) in the driver. Signed-off-by:
-
Neeraj Sanjay Kale authored
This adds a new optional device tree property called firware-name. Signed-off-by:
-
Hector Martin authored
This new variant needs a different core2_window1 and always uses beamforming. The BAR2 also has an offset (RAM start, presumably), so add that. Signed-off-by:
Hector Martin <marcan@marcan.st> Reviewed-by:
Sven Peter <sven@svenpeter.dev> [sven: rebased, updated some comments, mentioned 4388 in Kconfig] Signed-off-by:
-
Ying Hsu authored
When HCI raw sockets are opened, the Bluetooth kernel module doesn't track CIS/BIS connections. User-space applications have to identify ISO data by maintaining connection information and look up the mapping for each ACL data packet received. Besides, btsnoop log captured in kernel couldn't tell ISO data from ACL data in this case. To avoid additional lookups, this patch introduces vendor-specific packet classification for Intel BT controllers to distinguish ISO data packets from ACL data packets. Signed-off-by:
Ying Hsu <yinghsu@chromium.org> Signed-off-by:
-
Dr. David Alan Gilbert authored
'iso_list_data' has been unused since the original commit ccf74f23 ("Bluetooth: Add BTPROTO_ISO socket type"). Remove it. Signed-off-by:
Dr. David Alan Gilbert <linux@treblig.org> Signed-off-by:
-
Thorsten Blum authored
Remove memset(0) after dma_alloc_coherent(), which already zeroes out the memory, and fix the following two Coccinelle/coccicheck warnings reported by zalloc-simple.cocci: btintel_pcie.c:837:19-37: WARNING: dma_alloc_coherent used in /* Allocate full chunk of data buffer for DMA first and do indexing and * initialization next, so it can be freed easily */ rxq->buf_v_addr already zeroes out memory, so memset is not needed btintel_pcie.c:792:19-37: WARNING: dma_alloc_coherent used in /* Allocate full chunk of data buffer for DMA first and do indexing and * initialization next, so it can be freed easily */ txq->buf_v_addr already zeroes out memory, so memset is not needed Fixes: c2b636b3 ("Bluetooth: btintel_pcie: Add support for PCIe transport") Signed-off-by:
Thorsten Blum <thorsten.blum@toblux.com> Signed-off-by:
-
Erick Archer authored
It is preferred to use sizeof(*pointer) instead of sizeof(type) due to the type of the variable can change and one needs not change the former (unlike the latter). This patch has no effect on runtime behavior. Signed-off-by:
Erick Archer <erick.archer@outlook.com> Signed-off-by:
-
Dan Carpenter authored
The "update" variable needs to be initialized to false. Fixes: 0ece498c ("Bluetooth: MGMT: Make MGMT_OP_LOAD_CONN_PARAM update existing connection") Signed-off-by:
Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by:
-
Dr. David Alan Gilbert authored
'hci_nokia_radio_hdr' looks like it was unused since it's initial commit. Signed-off-by:
-
Erick Archer authored
Refactor the list_for_each_entry() loop of rfcomm_get_dev_list() function to use array indexing instead of pointer arithmetic. This way, the code is more readable and idiomatic. Reviewed-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
Erick Archer authored
This is an effort to get rid of all multiplications from allocation functions in order to prevent integer overflows [1][2]. As the "dl" variable is a pointer to "struct rfcomm_dev_list_req" and this structure ends in a flexible array: struct rfcomm_dev_list_req { [...] struct rfcomm_dev_info dev_info[]; }; the preferred way in the kernel is to use the struct_size() helper to do the arithmetic instead of the calculation "size + count * size" in the kzalloc() and copy_to_user() functions. At the same time, prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). In this case, it is important to note that the logic needs a little refactoring to ensure that the "dev_num" member is initialized before the first access to the flex array. Specifically, add the assignment before the list_for_each_entry() loop. Also remove the "size" variable as it is no longer needed. This way, the code is more readable and safer. This code was detected with the help of Coccinelle, and audited and modified manually. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments [1] Link: https://github.com/KSPP/linux/issues/160 [2] Reviewed-by: -
Erick Archer authored
Refactor the list_for_each_entry() loop of hci_get_dev_list() function to use array indexing instead of pointer arithmetic. This way, the code is more readable and idiomatic. Reviewed-by:
-
Erick Archer authored
This is an effort to get rid of all multiplications from allocation functions in order to prevent integer overflows [1][2]. As the "dl" variable is a pointer to "struct hci_dev_list_req" and this structure ends in a flexible array: struct hci_dev_list_req { [...] struct hci_dev_req dev_req[]; /* hci_dev_req structures */ }; the preferred way in the kernel is to use the struct_size() helper to do the arithmetic instead of the calculation "size + count * size" in the kzalloc() and copy_to_user() functions. At the same time, prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). In this case, it is important to note that the logic needs a little refactoring to ensure that the "dev_num" member is initialized before the first access to the flex array. Specifically, add the assignment before the list_for_each_entry() loop. Also remove the "size" variable as it is no longer needed. This way, the code is more readable and safer. This code was detected with the help of Coccinelle, and audited and modified manually. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments [1] Link: https://github.com/KSPP/linux/issues/160 [2] Reviewed-by: -
Kiran K authored
Free irq before releasing irq vector. Fixes: c2b636b3 ("Bluetooth: btintel_pcie: Add support for PCIe transport") Signed-off-by:
-
Kiran K authored
Firmware sequencer (FSEQ) is a common code shared across Bluetooth and Wifi. Printing FSEQ will help to debug if there is any mismatch between Bluetooth and Wifi FSEQ. Make 'btintel_print_fseq_info' public and use it in btintel_pcie.c. dmesg: .... [ 5335.695740] Bluetooth: hci0: Device booted in 33872 usecs [ 5335.695918] Bluetooth: hci0: Found Intel DDC parameters: intel/ibt-0190-0291.ddc [ 5335.697011] Bluetooth: hci0: Applying Intel DDC parameters completed [ 5335.697837] Bluetooth: hci0: Firmware timestamp 2024.20 buildtype 0 build 62871 [ 5335.697848] Bluetooth: hci0: Firmware SHA1: 0xeffdce06 [ 5335.698655] Bluetooth: hci0: Fseq status: Success (0x00) [ 5335.698666] Bluetooth: hci0: Fseq executed: 00.00.04.176 [ 5335.698670] Bluetooth: hci0: Fseq BT Top: 00.00.04.176 [ 5335.750204] Bluetooth: MGMT ver 1.22 Signed-off-by:
-
Hao Qin authored
Add the support of MT7922 bluetooth subsystem reset that was called the auto revert to self-recover from the fatal error in the controller like the host encounters HCI cmd timeout or the controller crashes. Co-developed-by:
Sean Wang <sean.wang@mediatek.com> Signed-off-by:
Hao Qin <hao.qin@mediatek.com> Signed-off-by:
-
Hao Qin authored
Reset the controller before downloading the firmware to improve its reliability. This includes situations like cold or warm reboots, ensuring the controller is in its initial state before starting the firmware download. Co-developed-by:
Chris Lu <chris.lu@mediatek.com> Signed-off-by:
-
Hao Qin authored
Extract the function btusb_mtk_subsys_reset from the btusb_mtk_reset for the future handling of resetting bluetooth controller without the USB reset. Co-developed-by:
-
Sean Wang authored
Apply the common btmtk_fw_get_filename to avoid the similar coding in each driver. Signed-off-by:
-
Sean Wang authored
Include a shared function to get the firmware name, to prevent repeating code for similar chipsets. Signed-off-by:
-
Kiran K authored
Current flow iterates the ACPI table associated with Bluetooth controller looking for PPAG method. Method name can be directly passed to acpi_evaluate_object function instead of iterating the table. Fixes: c585a92b ("Bluetooth: btintel: Set Per Platform Antenna Gain(PPAG)") Signed-off-by:
-
Luke Wang authored
When unload the btnxpuart driver, its associated timer will be deleted. If the timer happens to be modified at this moment, it leads to the kernel call this timer even after the driver unloaded, resulting in kernel panic. Use timer_shutdown_sync() instead of del_timer_sync() to prevent rearming. panic log: Internal error: Oops: 0000000086000007 [#1] PREEMPT SMP Modules linked in: algif_hash algif_skcipher af_alg moal(O) mlan(O) crct10dif_ce polyval_ce polyval_generic snd_soc_imx_card snd_soc_fsl_asoc_card snd_soc_imx_audmux mxc_jpeg_encdec v4l2_jpeg snd_soc_wm8962 snd_soc_fsl_micfil snd_soc_fsl_sai flexcan snd_soc_fsl_utils ap130x rpmsg_ctrl imx_pcm_dma can_dev rpmsg_char pwm_fan fuse [last unloaded: btnxpuart] CPU: 5 PID: 723 Comm: memtester Tainted: G O 6.6.23-lts-next-06207-g4aef2658ac28 #1 Hardware name: NXP i.MX95 19X19 board (DT) pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0xffff80007a2cf464 lr : call_timer_fn.isra.0+0x24/0x80 ... Call trace: 0xffff80007a2cf464 __run_timers+0x234/0x280 run_timer_softirq+0x20/0x40 __do_softirq+0x100/0x26c ____do_softirq+0x10/0x1c call_on_irq_stack+0x24/0x4c do_softirq_own_stack+0x1c/0x2c irq_exit_rcu+0xc0/0xdc el0_interrupt+0x54/0xd8 __el0_irq_handler_common+0x18/0x24 el0t_64_irq_handler+0x10/0x1c el0t_64_irq+0x190/0x194 Code: ???????? ???????? ???????? ???????? (????????) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception in interrupt SMP: stopping secondary CPUs Kernel Offset: disabled CPU features: 0x0,c0000000,40028143,1000721b Memory Limit: none ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]--- Signed-off-by:
Luke Wang <ziniu.wang_1@nxp.com> Signed-off-by:
-
Neeraj Sanjay Kale authored
This adds a new flag BTNXPUART_FW_DOWNLOAD_ABORT which handles the situation where driver is removed while firmware download is in progress. logs: modprobe btnxpuart [65239.230431] Bluetooth: hci0: ChipID: 7601, Version: 0 [65239.236670] Bluetooth: hci0: Request Firmware: nxp/uartspi_n61x_v1.bin.se rmmod btnxpuart [65241.425300] Bluetooth: hci0: FW Download Aborted Signed-off-by:
Guillaume Legoupil <guillaume.legoupil@nxp.com> Signed-off-by:
-
