summaryrefslogtreecommitdiff
path: root/drivers/bluetooth
AgeCommit message (Collapse)AuthorFilesLines
2021-07-19Bluetooth: btusb: fix bt fiwmare downloading failure issue for qca btsoc.Tim Jiang1-0/+5
[ Upstream commit 4f00bfb372674d586c4a261bfc595cbce101fbb6 ] This is btsoc timing issue, after host start to downloading bt firmware, ep2 need time to switch from function acl to function dfu, so host add 20ms delay as workaround. Signed-off-by: Tim Jiang <tjiang@codeaurora.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19Bluetooth: btusb: Add support USB ALT 3 for WBSHilda Wu1-0/+7
[ Upstream commit e848dbd364aca44c9d23c04bef964fab79e2b34f ] Because mSBC frames do not need to be aligned to the SCO packet boundary. Using USB ALT 3 let HCI payload >= 60 bytes, let mSBC data satisfy 60 Bytes avoid payload unaligned situation and fixed some headset no voise issue. USB Alt 3 supported also need HFP support transparent MTU in 72 Bytes. Signed-off-by: Hilda Wu <hildawu@realtek.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19Bluetooth: btusb: Add a new QCA_ROME device (0cf3:e500)Daniel Lenski1-0/+2
[ Upstream commit 0324d19cb99804d99e42c990b8b1e191575a091b ] This patch adds the 0cf3:e500 Bluetooth device (from a QCA9377 board) as a QCA_ROME device. It appears to be functionally identical to another device ID, also from a QCA9377 board, which was previously marked as QCA_ROME in 0a03f98b98c201191e3ba15a0e33f46d8660e1fd ("Bluetooth: Add a new 04ca:3015 QCA_ROME device"). Without this patch, the WiFi side of the QCA9377 board is slow or unusable when the Bluetooth side is in use. See https://askubuntu.com/a/1137852 for another report of QCA_ROME fixing this issue for this device ID. /sys/kernel/debug/usb/devices: T: Bus=05 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 2.01 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0cf3 ProdID=e500 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 Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19Bluetooth: btusb: Fixed too many in-token issue for Mediatek Chip.mark-yw.chen1-5/+5
[ Upstream commit 8454ed9ff9647e31e061fb5eb2e39ce79bc5e960 ] This patch reduce in-token during download patch procedure. Don't submit urb for polling event before sending hci command. Signed-off-by: mark-yw.chen <mark-yw.chen@mediatek.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-14Bluetooth: btqca: Don't modify firmware contents in-placeConnor Abbott1-7/+20
commit b43ca511178ed0ab6fd2405df28cf9e100273020 upstream. struct firmware::data is marked const, and when the firmware is compressed with xz (default at least with Fedora) it's mapped read-only which results in a crash: BUG: unable to handle page fault for address: ffffae57c0ca5047 PGD 100000067 P4D 100000067 PUD 1001ce067 PMD 10165a067 PTE 8000000112bba161 Oops: 0003 [#1] SMP NOPTI CPU: 3 PID: 204 Comm: kworker/u17:0 Not tainted 5.12.1-test+ #1 Hardware name: Dell Inc. XPS 13 9310/0F7M4C, BIOS 1.2.5 12/10/2020 Workqueue: hci0 hci_power_on [bluetooth] RIP: 0010:qca_download_firmware+0x27c/0x4e0 [btqca] Code: 1b 75 04 80 48 0c 01 0f b7 c6 8d 54 02 0c 41 39 d7 0f 8e 62 fe ff ff 48 63 c2 4c 01 e8 0f b7 38 0f b7 70 02 66 83 ff 11 75 d3 <80> 48 0c 80 41 83 fc 03 7e 6e 88 58 0d eb ce 41 0f b6 45 0e 48 8b RSP: 0018:ffffae57c08dfc68 EFLAGS: 00010246 RAX: ffffae57c0ca503b RBX: 000000000000000e RCX: 0000000000000000 RDX: 0000000000000037 RSI: 0000000000000006 RDI: 0000000000000011 RBP: ffff978d9949e000 R08: ffff978d84ed7540 R09: ffffae57c0ca5000 R10: 000000000010cd00 R11: 0000000000000001 R12: 0000000000000005 R13: ffffae57c0ca5004 R14: ffff978d98ca8680 R15: 00000000000016a9 FS: 0000000000000000(0000) GS:ffff9794ef6c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffae57c0ca5047 CR3: 0000000113d5a004 CR4: 0000000000770ee0 PKRU: 55555554 Call Trace: qca_uart_setup+0x2cb/0x1390 [btqca] ? qca_read_soc_version+0x136/0x220 [btqca] qca_setup+0x288/0xab0 [hci_uart] hci_dev_do_open+0x1f3/0x780 [bluetooth] ? try_to_wake_up+0x1c1/0x4f0 hci_power_on+0x3f/0x200 [bluetooth] process_one_work+0x1ec/0x380 worker_thread+0x53/0x3e0 ? process_one_work+0x380/0x380 kthread+0x11b/0x140 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork+0x1f/0x30 Modules linked in: llc ip_set nf_tables nfnetlink snd_soc_skl_hda_dsp(+) ip6table_filter snd_soc_hdac_hdmi ip6_tables qrtr_mhi iptable_filter snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic s> dell_wmi_sysman(+) dell_smbios snd dcdbas mhi vfat videobuf2_vmalloc i2c_i801 videobuf2_memops videobuf2_v4l2 dell_wmi_descriptor fat wmi_bmof soundcore i2c_smbus videobuf2_common libarc4 mei_me mei hid_se> i2c_hid_acpi i2c_hid video pinctrl_tigerlake fuse CR2: ffffae57c0ca5047 This also seems to fix a failure to suspend due to the firmware download on bootup getting interrupted by the crash: Bluetooth: hci0: SSR or FW download time out PM: dpm_run_callback(): acpi_subsys_suspend+0x0/0x60 returns -110 PM: Device serial0-0 failed to suspend: error -110 PM: Some devices failed to suspend, or early wake event detected Fixes: 83e8196 ("Bluetooth: btqca: Introduce generic QCA ROME support") Cc: Venkata Lakshmi Narayana Gubba <gubbaven@codeaurora.org> Cc: stable@vger.kernel.org Signed-off-by: Connor Abbott <cwabbott0@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-14Bluetooth: hci_qca: fix potential GPFPavel Skripkin1-2/+2
commit 59f90f1351282ea2dbd0c59098fd9bb2634e920e upstream. In qca_power_shutdown() qcadev local variable is initialized by hu->serdev.dev private data, but hu->serdev can be NULL and there is a check for it. Since, qcadev is not used before if (!hu->serdev) return; we can move its initialization after this "if" to prevent GPF. Fixes: 5559904ccc08 ("Bluetooth: hci_qca: Add QCA Rome power off support to the qca_power_shutdown()") Cc: stable@vger.kernel.org # v5.6+ Cc: Rocky Liao <rjliao@codeaurora.org> Signed-off-by: Pavel Skripkin <paskripkin@gmail.com> Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-18Bluetooth: Add a new USB ID for RTL8822CELarry Finger1-0/+2
[ Upstream commit 4d96d3b0efee6416ef0d61b76aaac6f4a2e15b12 ] Some models of the RTL8822ce utilize a different USB ID. Add this new one to the Bluetooth driver. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-19Bluetooth: btusb: Enable quirk boolean flag for Mediatek Chip.mark-yw.chen1-1/+3
[ Upstream commit 27e554a4fcd84e499bf0a82122b8c4c3f1de38b6 ] Adding support LE scatternet and WBS for Mediatek Chip Signed-off-by: mark-yw.chen <mark-yw.chen@mediatek.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-11Bluetooth: btqca: Add valid le states quirkAbhishek Pandit-Subedi1-6/+13
[ Upstream commit 547801380ec7e6104ea679f599d03c342b4b39a0 ] WCN3991 supports connectable advertisements so we need to add the valid le states quirk so the 'central-peripheral' role is exposed in userspace. Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-07Bluetooth: hci_h5: Set HCI_QUIRK_SIMULTANEOUS_DISCOVERY for btrtlClaire Chang1-0/+5
[ Upstream commit 7f9f2c3f7d99b8ae773459c74ac5e99a0dd46db9 ] Realtek Bluetooth controllers can do both LE scan and BR/EDR inquiry at once, need to set HCI_QUIRK_SIMULTANEOUS_DISCOVERY quirk. Signed-off-by: Claire Chang <tientzu@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-04tty: convert tty_ldisc_ops 'read()' function to take a kernel pointerLinus Torvalds1-17/+17
[ Upstream commit 3b830a9c34d5897be07176ce4e6f2d75e2c8cfd7 ] The tty line discipline .read() function was passed the final user pointer destination as an argument, which doesn't match the 'write()' function, and makes it very inconvenient to do a splice method for ttys. This is a conversion to use a kernel buffer instead. NOTE! It does this by passing the tty line discipline ->read() function an additional "cookie" to fill in, and an offset into the cookie data. The line discipline can fill in the cookie data with its own private information, and then the reader will repeat the read until either the cookie is cleared or it runs out of data. The only real user of this is N_HDLC, which can use this to handle big packets, even if the kernel buffer is smaller than the whole packet. Cc: Christoph Hellwig <hch@lst.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-04Bluetooth: btusb: Fix memory leak in btusb_mtk_wmt_recvJupeng Zhong1-10/+10
[ Upstream commit de71a6cb4bf24d8993b9ca90d1ddb131b60251a1 ] In btusb_mtk_wmt_recv if skb_clone fails, the alocated skb should be released. Omit the labels “err_out” and “err_free_skb” in this function implementation so that the desired exception handling code would be directly specified in the affected if branches. Fixes: a1c49c434e15 ("btusb: Add protocol support for MediaTek MT7668U USB devices") Signed-off-by: Jupeng Zhong <zhongjupeng@yulong.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-04Bluetooth: hci_qca: Fix memleak in qca_controller_memdumpDinghao Liu1-0/+2
[ Upstream commit 71f8e707557b9bc25dc90a59a752528d4e7c1cbf ] When __le32_to_cpu() fails, qca_memdump should be freed just like when vmalloc() fails. Fixes: d841502c79e3f ("Bluetooth: hci_qca: Collect controller memory dump during SSR") Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-04Bluetooth: hci_uart: Fix a race for write_work schedulingClaire Chang2-6/+5
[ Upstream commit afe0b1c86458f121b085271e4f3034017a90d4a3 ] In hci_uart_write_work, there is a loop/goto checking the value of HCI_UART_TX_WAKEUP. If HCI_UART_TX_WAKEUP is set again, it keeps trying hci_uart_dequeue; otherwise, it clears HCI_UART_SENDING and returns. In hci_uart_tx_wakeup, if HCI_UART_SENDING is already set, it sets HCI_UART_TX_WAKEUP, skips schedule_work and assumes the running/pending hci_uart_write_work worker will do hci_uart_dequeue properly. However, if the HCI_UART_SENDING check in hci_uart_tx_wakeup is done after the loop breaks, but before HCI_UART_SENDING is cleared in hci_uart_write_work, the schedule_work is skipped incorrectly. Fix this race by changing the order of HCI_UART_SENDING and HCI_UART_TX_WAKEUP modification. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Fixes: 82f5169bf3d3 ("Bluetooth: hci_uart: add serdev driver support library") Signed-off-by: Claire Chang <tientzu@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-04Bluetooth: btqcomsmd: Fix a resource leak in error handling paths in the ↵Christophe JAILLET1-8/+19
probe function [ Upstream commit 9a39a927be01d89e53f04304ab99a8761e08910d ] Some resource should be released in the error handling path of the probe function, as already done in the remove function. The remove function was fixed in commit 5052de8deff5 ("soc: qcom: smd: Transition client drivers from smd to rpmsg") Fixes: 1511cc750c3d ("Bluetooth: Introduce Qualcomm WCNSS SMD based HCI driver") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-02-26Bluetooth: btusb: Some Qualcomm Bluetooth adapters stop workingHui Wang1-0/+7
commit 234f414efd1164786269849b4fbb533d6c9cdbbf upstream. This issue starts from linux-5.10-rc1, I reproduced this issue on my Dell Inspiron 7447 with BT adapter 0cf3:e005, the kernel will print out: "Bluetooth: hci0: don't support firmware rome 0x31010000", and someone else also reported the similar issue to bugzilla #211571. I found this is a regression introduced by 'commit b40f58b97386 ("Bluetooth: btusb: Add Qualcomm Bluetooth SoC WCN6855 support"), the patch assumed that if high ROM version is not zero, it is an adapter on WCN6855, but many old adapters don't need to load rampatch or nvm, and they have non-zero high ROM version. To fix it, let the driver match the rom_version in the qca_devices_table first, if there is no entry matched, check the high ROM version, if it is not zero, we assume this adapter is ready to work and no need to load rampatch and nvm like previously. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=211571 Fixes: b40f58b97386 ("Bluetooth: btusb: Add Qualcomm Bluetooth SoC WCN6855 support") Signed-off-by: Hui Wang <hui.wang@canonical.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Cc: Salvatore Bonaccorso <carnil@debian.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-02-23Bluetooth: btusb: Always fallback to alt 1 for WBSTrent Piepho1-14/+6
commit 517b693351a2d04f3af1fc0e506ac7e1346094de upstream. When alt mode 6 is not available, fallback to the kernel <= 5.7 behavior of always using alt mode 1. Prior to kernel 5.8, btusb would always use alt mode 1 for WBS (Wide Band Speech aka mSBC aka transparent SCO). In commit baac6276c0a9 ("Bluetooth: btusb: handle mSBC audio over USB Endpoints") this was changed to use alt mode 6, which is the recommended mode in the Bluetooth spec (Specifications of the Bluetooth System, v5.0, Vol 4.B §2.2.1). However, many if not most BT USB adapters do not support alt mode 6. In fact, I have been unable to find any which do. In kernel 5.8, this was changed to use alt mode 6, and if not available, use alt mode 0. But mode 0 has a zero byte max packet length and can not possibly work. It is just there as a zero-bandwidth dummy mode to work around a USB flaw that would prevent device enumeration if insufficient bandwidth were available for the lowest isoc mode supported. In effect, WBS was broken for all USB-BT adapters that do not support alt 6, which appears to nearly all of them. Then in commit 461f95f04f19 ("Bluetooth: btusb: USB alternate setting 1 for WBS") the 5.7 behavior was restored, but only for Realtek adapters. I've tested a Broadcom BRCM20702A and CSR 8510 adapter, both work with the 5.7 behavior and do not with the 5.8. So get rid of the Realtek specific flag and use the 5.7 behavior for all adapters as a fallback when alt 6 is not available. This was the kernel's behavior prior to 5.8 and I can find no adapters for which it is not correct. And even if there is an adapter for which this does not work, the current behavior would be to fall back to alt 0, which can not possibly work either, and so is no better. Signed-off-by: Trent Piepho <tpiepho@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Cc: Salvatore Bonaccorso <carnil@debian.org> Cc: Sjoerd Simons <sjoerd@luon.net> Cc: Sebastian Reichel <sre@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-01-12Bluetooth: revert: hci_h5: close serdev device and free hu in h5_closeHans de Goede1-6/+2
commit 5c3b5796866f85354a5ce76a28f8ffba0dcefc7e upstream. There have been multiple revisions of the patch fix the h5->rx_skb leak. Accidentally the first revision (which is buggy) and v5 have both been merged: v1 commit 70f259a3f427 ("Bluetooth: hci_h5: close serdev device and free hu in h5_close"); v5 commit 855af2d74c87 ("Bluetooth: hci_h5: fix memory leak in h5_close") The correct v5 makes changes slightly higher up in the h5_close() function, which allowed both versions to get merged without conflict. The changes from v1 unconditionally frees the h5 data struct, this is wrong because in the serdev enumeration case the memory is allocated in h5_serdev_probe() like this: h5 = devm_kzalloc(dev, sizeof(*h5), GFP_KERNEL); So its lifetime is tied to the lifetime of the driver being bound to the serdev and it is automatically freed when the driver gets unbound. In the serdev case the same h5 struct is re-used over h5_close() and h5_open() calls and thus MUST not be free-ed in h5_close(). The serdev_device_close() added to h5_close() is incorrect in the same way, serdev_device_close() is called on driver unbound too and also MUST no be called from h5_close(). This reverts the changes made by merging v1 of the patch, so that just the changes of the correct v5 remain. Cc: Anant Thazhemadam <anant.thazhemadam@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-01-06Bluetooth: hci_h5: close serdev device and free hu in h5_closeAnant Thazhemadam1-2/+6
commit 70f259a3f4276b71db365b1d6ff1eab805ea6ec3 upstream. When h5_close() gets called, the memory allocated for the hu gets freed only if hu->serdev doesn't exist. This leads to a memory leak. So when h5_close() is requested, close the serdev device instance and free the memory allocated to the hu entirely instead. Fixes: https://syzkaller.appspot.com/bug?extid=6ce141c55b2f7aafd1c4 Reported-by: syzbot+6ce141c55b2f7aafd1c4@syzkaller.appspotmail.com Tested-by: syzbot+6ce141c55b2f7aafd1c4@syzkaller.appspotmail.com Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-30Bluetooth: btusb: Fix detection of some fake CSR controllers with a ↵Hans de Goede1-0/+8
bcdDevice val of 0x0134 [ Upstream commit d74e0ae7e03032b47b8631cc1e52a7ae1ce988c0 ] Commit cde1a8a99287 ("Bluetooth: btusb: Fix and detect most of the Chinese Bluetooth controllers") made the detection of fake controllers more generic fixing it for much of the newer fakes / clones. But this does not work for a fake CSR controller with a bcdDevice value of 0x0134, which was correctly identified as fake before this change. Add an extra check for this special case, checking for a combination of a bcdDevice value of 0x0134, together with a lmp_subver of 0x0c5c and a hci_ver of BLUETOOTH_VER_2_0. The chip inside this fake dongle is marked as with "clockwise cw6629d". Fixes: cde1a8a99287 ("Bluetooth: btusb: Fix and detect most of the Chinese Bluetooth controllers") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30Bluetooth: btmtksdio: Add the missed release_firmware() in mtk_setup_firmware()Jing Xiangfeng1-1/+1
[ Upstream commit b73b5781a85c03113476f62346c390f0277baa4b ] mtk_setup_firmware() misses to call release_firmware() in an error path. Jump to free_fw to fix it. Fixes: 737cd06072a7 ("Bluetooth: btmtksdio: fix up firmware download sequence") Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30Bluetooth: btusb: Add the missed release_firmware() in ↵Jing Xiangfeng1-1/+1
btusb_mtk_setup_firmware() [ Upstream commit d1e9d232e1e60fa63df1b836ec3ecba5abd3fa9d ] btusb_mtk_setup_firmware() misses to call release_firmware() in an error path. Jump to err_release_fw to fix it. Fixes: f645125711c8 ("Bluetooth: btusb: fix up firmware download sequence") Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30Bluetooth: hci_h5: fix memory leak in h5_closeAnant Thazhemadam1-0/+3
[ Upstream commit 855af2d74c870d747bf53509f8b2d7b9dc9ee2c3 ] When h5_close() is called, h5 is directly freed when !hu->serdev. However, h5->rx_skb is not freed, which causes a memory leak. Freeing h5->rx_skb and setting it to NULL, fixes this memory leak. Fixes: ce945552fde4 ("Bluetooth: hci_h5: Add support for serdev enumerated devices") Reported-by: syzbot+6ce141c55b2f7aafd1c4@syzkaller.appspotmail.com Tested-by: syzbot+6ce141c55b2f7aafd1c4@syzkaller.appspotmail.com Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-30Bluetooth: btintel: Replace zero-length array with flexible-array memberGustavo A. R. Silva1-1/+1
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9/process/deprecated.html#zero-length-and-one-element-arrays Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
2020-10-15Merge tag 'net-next-5.10' of ↵Linus Torvalds10-137/+533
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next Pull networking updates from Jakub Kicinski: - Add redirect_neigh() BPF packet redirect helper, allowing to limit stack traversal in common container configs and improving TCP back-pressure. Daniel reports ~10Gbps => ~15Gbps single stream TCP performance gain. - Expand netlink policy support and improve policy export to user space. (Ge)netlink core performs request validation according to declared policies. Expand the expressiveness of those policies (min/max length and bitmasks). Allow dumping policies for particular commands. This is used for feature discovery by user space (instead of kernel version parsing or trial and error). - Support IGMPv3/MLDv2 multicast listener discovery protocols in bridge. - Allow more than 255 IPv4 multicast interfaces. - Add support for Type of Service (ToS) reflection in SYN/SYN-ACK packets of TCPv6. - In Multi-patch TCP (MPTCP) support concurrent transmission of data on multiple subflows in a load balancing scenario. Enhance advertising addresses via the RM_ADDR/ADD_ADDR options. - Support SMC-Dv2 version of SMC, which enables multi-subnet deployments. - Allow more calls to same peer in RxRPC. - Support two new Controller Area Network (CAN) protocols - CAN-FD and ISO 15765-2:2016. - Add xfrm/IPsec compat layer, solving the 32bit user space on 64bit kernel problem. - Add TC actions for implementing MPLS L2 VPNs. - Improve nexthop code - e.g. handle various corner cases when nexthop objects are removed from groups better, skip unnecessary notifications and make it easier to offload nexthops into HW by converting to a blocking notifier. - Support adding and consuming TCP header options by BPF programs, opening the doors for easy experimental and deployment-specific TCP option use. - Reorganize TCP congestion control (CC) initialization to simplify life of TCP CC implemented in BPF. - Add support for shipping BPF programs with the kernel and loading them early on boot via the User Mode Driver mechanism, hence reusing all the user space infra we have. - Support sleepable BPF programs, initially targeting LSM and tracing. - Add bpf_d_path() helper for returning full path for given 'struct path'. - Make bpf_tail_call compatible with bpf-to-bpf calls. - Allow BPF programs to call map_update_elem on sockmaps. - Add BPF Type Format (BTF) support for type and enum discovery, as well as support for using BTF within the kernel itself (current use is for pretty printing structures). - Support listing and getting information about bpf_links via the bpf syscall. - Enhance kernel interfaces around NIC firmware update. Allow specifying overwrite mask to control if settings etc. are reset during update; report expected max time operation may take to users; support firmware activation without machine reboot incl. limits of how much impact reset may have (e.g. dropping link or not). - Extend ethtool configuration interface to report IEEE-standard counters, to limit the need for per-vendor logic in user space. - Adopt or extend devlink use for debug, monitoring, fw update in many drivers (dsa loop, ice, ionic, sja1105, qed, mlxsw, mv88e6xxx, dpaa2-eth). - In mlxsw expose critical and emergency SFP module temperature alarms. Refactor port buffer handling to make the defaults more suitable and support setting these values explicitly via the DCBNL interface. - Add XDP support for Intel's igb driver. - Support offloading TC flower classification and filtering rules to mscc_ocelot switches. - Add PTP support for Marvell Octeontx2 and PP2.2 hardware, as well as fixed interval period pulse generator and one-step timestamping in dpaa-eth. - Add support for various auth offloads in WiFi APs, e.g. SAE (WPA3) offload. - Add Lynx PHY/PCS MDIO module, and convert various drivers which have this HW to use it. Convert mvpp2 to split PCS. - Support Marvell Prestera 98DX3255 24-port switch ASICs, as well as 7-port Mediatek MT7531 IP. - Add initial support for QCA6390 and IPQ6018 in ath11k WiFi driver, and wcn3680 support in wcn36xx. - Improve performance for packets which don't require much offloads on recent Mellanox NICs by 20% by making multiple packets share a descriptor entry. - Move chelsio inline crypto drivers (for TLS and IPsec) from the crypto subtree to drivers/net. Move MDIO drivers out of the phy directory. - Clean up a lot of W=1 warnings, reportedly the actively developed subsections of networking drivers should now build W=1 warning free. - Make sure drivers don't use in_interrupt() to dynamically adapt their code. Convert tasklets to use new tasklet_setup API (sadly this conversion is not yet complete). * tag 'net-next-5.10' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next: (2583 commits) Revert "bpfilter: Fix build error with CONFIG_BPFILTER_UMH" net, sockmap: Don't call bpf_prog_put() on NULL pointer bpf, selftest: Fix flaky tcp_hdr_options test when adding addr to lo bpf, sockmap: Add locking annotations to iterator netfilter: nftables: allow re-computing sctp CRC-32C in 'payload' statements net: fix pos incrementment in ipv6_route_seq_next net/smc: fix invalid return code in smcd_new_buf_create() net/smc: fix valid DMBE buffer sizes net/smc: fix use-after-free of delayed events bpfilter: Fix build error with CONFIG_BPFILTER_UMH cxgb4/ch_ipsec: Replace the module name to ch_ipsec from chcr net: sched: Fix suspicious RCU usage while accessing tcf_tunnel_info bpf: Fix register equivalence tracking. rxrpc: Fix loss of final ack on shutdown rxrpc: Fix bundle counting for exclusive connections netfilter: restore NF_INET_NUMHOOKS ibmveth: Identify ingress large send packets. ibmveth: Switch order of ibmveth_helper calls. cxgb4: handle 4-tuple PEDIT to NAT mode translation selftests: Add VRF route leaking tests ...
2020-09-27Bluetooth: btusb: Add Qualcomm Bluetooth SoC WCN6855 supportRocky Liao1-13/+53
This patch add support for WCN6855 i.e. patch and nvm download support. T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0cf3 ProdID=e600 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: Rocky Liao <rjliao@codeaurora.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-09-25Bluetooth: ath3k: use usb_control_msg_send() and usb_control_msg_recv()Greg Kroah-Hartman1-64/+29
The usb_control_msg_send() and usb_control_msg_recv() calls can return an error if a "short" write/read happens, and they can handle data off of the stack, so move the driver over to using those calls instead, saving some logic when dynamically allocating memory. v2: changed API of use usb_control_msg_send() and usb_control_msg_recv() Cc: Marcel Holtmann <marcel@holtmann.org> Cc: Johan Hedberg <johan.hedberg@gmail.com> Link: https://lore.kernel.org/r/20200914153756.3412156-11-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20200923134348.23862-15-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-25Revert "Bluetooth: ath3k: use usb_control_msg_send() and usb_control_msg_recv()"Oliver Neukum1-26/+64
This reverts commit e9b20f0fe17ab06c3b55153046209987749daa48. The API has to be changed Signed-off-by: Oliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/20200923134348.23862-3-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-20Bluetooth: btusb: Enable wide band speech support for BTUSB_QCA_ROMERocky Liao1-18/+36
QCA Rome supports wide band speech, this patch enables the wide band speech support by set the BTUSB_WIDEBAND_SPEECH flag. Signed-off-by: Rocky Liao <rjliao@codeaurora.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-09-16Bluetooth: ath3k: use usb_control_msg_send() and usb_control_msg_recv()Greg Kroah-Hartman1-64/+26
The usb_control_msg_send() and usb_control_msg_recv() calls can return an error if a "short" write/read happens, and they can handle data off of the stack, so move the driver over to using those calls instead, saving some logic when dynamically allocating memory. Cc: Marcel Holtmann <marcel@holtmann.org> Cc: Johan Hedberg <johan.hedberg@gmail.com> Link: https://lore.kernel.org/r/20200914153756.3412156-11-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-14Bluetooth: btintel: Functions to send firmware header / payloadKiran K2-2/+129
New generation controllers supports ECDSA secure boot engine. This patch adds, 1) function to send ECDSA header 2) function to download complete firmware for new generation Intel controllers Signed-off-by: Kiran K <kiran.k@intel.com> Signed-off-by: Amit K Bag <amit.k.bag@intel.com> Signed-off-by: Raghuram Hegde <raghuram.hegde@intel.com> Reviewed-by: Chethan T N <chethan.tumkur.narayan@intel.com> Reviewed-by: Srivatsa Ravishankar <ravishankar.srivatsa@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-09-14Bluetooth: btintel: Add infrastructure to read controller informationKiran K2-0/+217
New generation Intel controllers returns version information in TLV format. This patch adds, 1) Enums, structures for TLV 2) function to read controller information, parse TLV data and populate intel_version_tlv structure 3) function to print version information Signed-off-by: Kiran K <kiran.k@intel.com> Signed-off-by: Amit K Bag <amit.k.bag@intel.com> Signed-off-by: Raghuram Hegde <raghuram.hegde@intel.com> Reviewed-by: Chethan T N <chethan.tumkur.narayan@intel.com> Reviewed-by: Srivatsa Ravishankar <ravishankar.srivatsa@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-09-13Bluetooth: btintel: Refactor firmware download functionKiran K1-5/+31
Split firmware download code into two functions - one to download header and other to download payload. This patch enhances readability and reusabiltiy of code Signed-off-by: Kiran K <kiran.k@intel.com> Reviewed-by: Chethan T N <chethan.tumkur.narayan@intel.com> Reviewed-by: Sathish Narasimman <Sathish.Narasimman@intel.com> Reviewed-by: Srivatsa Ravishankar <ravishankar.srivatsa@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-09-11Bluetooth: hci_qca: Remove duplicate power off in proto closeVenkata Lakshmi Narayana Gubba1-3/+2
During serdev unregister, hdev->shutdown is called before proto close. Removing duplicates power OFF call. Signed-off-by: Venkata Lakshmi Narayana Gubba <gubbaven@codeaurora.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-09-11Bluetooth: hci_serdev: Close UART port if NON_PERSISTENT_SETUP is setVenkata Lakshmi Narayana Gubba1-3/+33
When HCI_QUIRK_NON_PERSISTENT_SETUP is set by drivers, it indicates that BT SoC will be completely powered OFF during BT OFF. On next BT ON firmware must be downloaded again. Holding UART port open during BT OFF is draining the battery. Now during BT OFF, UART port is closed if qurik HCI_QUIRK_NON_PERSISTENT_SETUP is set by clearing HCI_UART_PROTO_READY proto flag. On next BT ON, UART port is opened if HCI_UART_PROTO_READY proto flag is cleared. Signed-off-by: Venkata Lakshmi Narayana Gubba <gubbaven@codeaurora.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-09-11Bluetooth: hci_intel: enable on new platformAndy Shevchenko1-4/+5
On new Intel platform the device is provided with INT33E3 ID. Append it to the list. This will require ACPI_GPIO_QUIRK_ONLY_GPIOIO to be enabled because the relevant ASL looks like: UartSerialBusV2 ( ... ) GpioInt ( ... ) { ... } GpioIo ( ... ) { ... } which means that first GPIO resource is an interrupt, while we are expecting it to be reset one (output). Do the same for host-wake because in case of GpioInt() the platform_get_irq() will do the job and should return correct Linux IRQ number. That said, host-wake GPIO can only be GpioIo() resource. While here, drop commas in terminator lines. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-09-11Bluetooth: btmtksdio: use NULL instead of zeroYueHaibing1-2/+2
Fix sparse warnings: drivers/bluetooth/btmtksdio.c:499:57: warning: Using plain integer as NULL pointer drivers/bluetooth/btmtksdio.c:533:57: warning: Using plain integer as NULL pointer Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-09-11Bluetooth: hci_intel: switch to list_for_each_entry()Andy Shevchenko1-21/+10
There is no need to have list_for_each() followed by list_entry() when we simply may use list_for_each_entry() directly. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-09-11Bluetooth: hci_intel: drop strange le16_to_cpu() against u8 valuesAndy Shevchenko1-10/+4
Sparse rightfully complains: hci_intel.c:696:26: warning: cast to restricted __le16 hci_intel.c:701:26: warning: cast to restricted __le16 hci_intel.c:702:26: warning: cast to restricted __le16 hci_intel.c:703:26: warning: cast to restricted __le16 hci_intel.c:725:26: warning: cast to restricted __le16 hci_intel.c:730:26: warning: cast to restricted __le16 hci_intel.c:731:26: warning: cast to restricted __le16 hci_intel.c:732:26: warning: cast to restricted __le16 because we access non-restricted types with le16_to_cpu(). More confusion is added by using above against u8. On big-endian architecture we will get all zeroes. I bet it's not what should be in such case. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-09-11Bluetooth: hci_qca: remove redundant null checkXu Wang1-2/+1
Because clk_disable_unprepare already checked NULL clock parameter, so the additional check is unnecessary, just remove it. Signed-off-by: Xu Wang <vulab@iscas.ac.cn> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-08-31Bluetooth: btusb: Fix memleak in btusb_mtk_submit_wmt_recv_urbDinghao Liu1-0/+1
When kmalloc() on buf fails, urb should be freed just like when kmalloc() on dr fails. Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-08-31Bluetooth: btusb: Update boot parameter specific to SKUKiran K1-4/+4
boot parameter gets updated during firmware download process. Use the updated boot parameter while doing soft reset of controller. This patch fixes updating of boot parameter. Signed-off-by: Kiran K <kiran.k@intel.com> Reviewed-by: Chethan T N <chethan.tumkur.narayan@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-08-02Bluetooth: hci_uart: Cancel init work before unregisteringSamuel Holland2-0/+3
If hci_uart_tty_close() or hci_uart_unregister_device() is called while hu->init_ready is scheduled, hci_register_dev() could be called after the hci_uart is torn down. Avoid this by ensuring the work is complete or canceled before checking the HCI_UART_REGISTERED flag. Fixes: 9f2aee848fe6 ("Bluetooth: Add delayed init sequence support for UART controllers") Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-08-02Bluetooth: hci_h5: Remove ignored flag HCI_UART_RESET_ON_INITSamuel Holland1-2/+0
Since commit cba736465e5c ("Bluetooth: hci_serdev: Remove setting of HCI_QUIRK_RESET_ON_CLOSE."), this flag is ignored for hci_serdev users, so let's remove setting it. Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-08-02Bluetooth: btmrvl: eliminate duplicates introducing btmrvl_reg_89xxTamás Szűcs1-50/+4
SD89xx devices use identical card register settings. Make sure a single common instance is used to describe them. Signed-off-by: Tamás Szűcs <tszucs@protonmail.ch> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-07-31Merge branch 'for-upstream' of ↵David S. Miller14-157/+448
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next Johan Hedberg says: ==================== pull request: bluetooth-next 2020-07-31 Here's the main bluetooth-next pull request for 5.9: - Fix firmware filenames for Marvell chipsets - Several suspend-related fixes - Addedd mgmt commands for runtime configuration - Multiple fixes for Qualcomm-based controllers - Add new monitoring feature for mgmt - Fix handling of legacy cipher (E4) together with security level 4 - Add support for Realtek 8822CE controller - Fix issues with Chinese controllers using fake VID/PID values - Multiple other smaller fixes & improvements ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-30Revert "Bluetooth: btusb: Disable runtime suspend on Realtek devices"Abhishek Pandit-Subedi1-4/+0
This reverts commit 7ecacafc240638148567742cca41aa7144b4fe1e. Testing this change on a board with RTL8822CE, I found that enabling autosuspend has no effect on the stability of the system. The board continued working after autosuspend, suspend and reboot. The original commit makes it impossible to enable autosuspend on working systems so it should be reverted. Disabling autosuspend should be done via module param or udev in userspace instead. Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Acked-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-07-28Bluetooth: hci_qca: Stop collecting memdump ag