linux-stable.git/drivers/bluetooth, branch v5.10.22

Bluetooth: hci_h5: Set HCI_QUIRK_SIMULTANEOUS_DISCOVERY for btrtl

2021-03-07T11:34:09+00:00

[ 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

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

2021-03-04T10:37:36+00:00

[ 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: btusb: Fix memory leak in btusb_mtk_wmt_recv

2021-03-04T10:37:27+00:00

[ 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-04T10:37:22+00:00

[ 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-04T10:37:20+00:00

[ 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-04T10:37:20+00:00

[ 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:13:00+00:00

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

Bluetooth: btusb: Always fallback to alt 1 for WBS

2021-02-23T14:53:25+00:00

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

Bluetooth: revert: hci_h5: close serdev device and free hu in h5_close

2021-01-12T19:18:16+00:00

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 
Signed-off-by: Hans de Goede 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: hci_h5: close serdev device and free hu in h5_close

2021-01-06T13:56:51+00:00

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