user/sven/linux.git/drivers/bluetooth, branch v5.11.9

Bluetooth: hci_h5: Set HCI_QUIRK_SIMULTANEOUS_DISCOVERY for btrtl

2021-03-07T11:35:49Z

[ 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 Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin

Bluetooth: hci_qca: Fixed issue during suspend

2021-03-04T11:14:02Z

[ Upstream commit 55c0bd77479b60ea29fd390faf4545cfb3a1d79e ] If BT SoC is running with ROM FW then just return in qca_suspend function as ROM FW does not support in-band sleep. Fixes: 2be43abac5a8 ("Bluetooth: hci_qca: Wait for timeout during suspend") Signed-off-by: Venkata Lakshmi Narayana Gubba Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin

Bluetooth: hci_qca: check for SSR triggered flag while suspend

2021-03-04T11:14:02Z

[ Upstream commit 1bb0c66332babc5cbc4581d962da0b03af9f23e8 ] QCA_IBS_DISABLED flag will be set after memorydump started from controller.Currently qca_suspend() is waiting for SSR to complete based on flag QCA_IBS_DISABLED.Added to check for QCA_SSR_TRIGGERED flag too. Fixes: 2be43abac5a8 ("Bluetooth: hci_qca: Wait for timeout during suspend") Signed-off-by: Venkata Lakshmi Narayana Gubba Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin

tty: convert tty_ldisc_ops 'read()' function to take a kernel pointer

2021-03-04T11:14:00Z

[ 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 Cc: Greg Kroah-Hartman Cc: Al Viro Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin

Bluetooth: hci_qca: Wait for SSR completion during suspend

2021-03-04T11:13:59Z

[ Upstream commit ad3a9c0ec2d2baed936cfdd05870f9d1e1f40e0e ] During SSR after memory dump collection,BT controller will be powered off, powered on and then FW will be downloaded.During suspend if BT controller is powered off due to SSR then we should wait until SSR is completed and then suspend. Fixes: 2be43abac5a8 ("Bluetooth: hci_qca: Wait for timeout during suspend") Signed-off-by: Venkata Lakshmi Narayana Gubba Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin

Bluetooth: btusb: Fix memory leak in btusb_mtk_wmt_recv

2021-03-04T11:13:46Z

[ 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 Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin

Bluetooth: hci_qca: Fix memleak in qca_controller_memdump

2021-03-04T11:13:39Z

[ 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 Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin

Bluetooth: hci_uart: Fix a race for write_work scheduling

2021-03-04T11:13:36Z

[ 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 Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin

Bluetooth: btqcomsmd: Fix a resource leak in error handling paths in the probe function

2021-03-04T11:13:36Z

[ 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 Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin

Bluetooth: btusb: Some Qualcomm Bluetooth adapters stop working

2021-02-26T09:08:37Z

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 Signed-off-by: Marcel Holtmann Cc: Salvatore Bonaccorso Signed-off-by: Greg Kroah-Hartman