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

Bluetooth: hci_qca: Stop collecting memdump again for command timeout during SSR

2020-08-19T06:26:47+00:00

[ Upstream commit 58789a1990c1a849a461ac912e72a698a771951a ]

Setting memdump state to idle prior to setting of callback function
pointer for command timeout to NULL,causing the issue.Now moved the
initialisation of memdump state to qca_setup().

Fixes: d841502c79e3 ("Bluetooth: hci_qca: Collect controller memory dump during SSR")
Signed-off-by: Venkata Lakshmi Narayana Gubba 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Sasha Levin

Bluetooth: hci_serdev: Only unregister device if it was registered

2020-08-19T06:26:46+00:00

[ Upstream commit 202798db9570104728dce8bb57dfeed47ce764bc ]

We should not call hci_unregister_dev if the device was not
successfully registered.

Fixes: c34dc3bfa7642fd ("Bluetooth: hci_serdev: Introduce hci_uart_unregister_device()")
Signed-off-by: Nicolas Boichat 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Sasha Levin

Bluetooth: hci_h5: Set HCI_UART_RESET_ON_INIT to correct flags

2020-08-19T06:26:46+00:00

[ Upstream commit a7ad4b6119d740b1ec5788f1b98be0fd1c1b5a5a ]

HCI_UART_RESET_ON_INIT belongs in hdev_flags, not flags.

Fixes: ce945552fde4a09 ("Bluetooth: hci_h5: Add support for serdev enumerated devices")
Signed-off-by: Nicolas Boichat 
Reviewed-by: Hans de Goede 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Sasha Levin

Bluetooth: btusb: Fix and detect most of the Chinese Bluetooth controllers

2020-08-19T06:26:46+00:00

[ Upstream commit cde1a8a992875a7479c4321b2a4a190c2e92ec2a ]

For some reason they tend to squat on the very first CSR/
Cambridge Silicon Radio VID/PID instead of paying fees.

This is an extremely common problem; the issue goes as back as 2013
and these devices are only getting more popular, even rebranded by
reputable vendors and sold by retailers everywhere.

So, at this point in time there are hundreds of modern dongles reusing
the ID of what originally was an early Bluetooth 1.1 controller.

Linux is the only place where they don't work due to spotty checks
in our detection code. It only covered a minimum subset.

So what's the big idea? Take advantage of the fact that all CSR
chips report the same internal version as both the LMP sub-version and
HCI revision number. It always matches, couple that with the manufacturer
code, that rarely lies, and we now have a good idea of who is who.

Additionally, by compiling a list of user-reported HCI/lsusb dumps, and
searching around for legit CSR dongles in similar product ranges we can
find what CSR BlueCore firmware supported which Bluetooth versions.

That way we can narrow down ranges of fakes for each of them.

e.g. Real CSR dongles with LMP subversion 0x73 are old enough that
     support BT 1.1 only; so it's a dead giveaway when some
     third-party BT 4.0 dongle reuses it.

So, to sum things up; there are multiple classes of fake controllers
reusing the same 0A12:0001 VID/PID. This has been broken for a while.

Known 'fake' bcdDevices: 0x0100, 0x0134, 0x1915, 0x2520, 0x7558, 0x8891
  IC markings on 0x7558: FR3191AHAL 749H15143 (???)

https://bugzilla.kernel.org/show_bug.cgi?id=60824

Fixes: 81cac64ba258ae (Deal with USB devices that are faking CSR vendor)
Reported-by: Michał Wiśniewski 
Tested-by: Mike Johnson 
Tested-by: Ricardo Rodrigues 
Tested-by: M.Hanny Sabbagh 
Tested-by: Oussama BEN BRAHIM 
Tested-by: Ismael Ferreras Morezuelas 
Signed-off-by: Ismael Ferreras Morezuelas 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Sasha Levin

Bluetooth: btmtksdio: fix up firmware download sequence

2020-08-19T06:26:27+00:00

[ Upstream commit 737cd06072a72e8984e41af8e5919338d0c5bf2b ]

Data RAM on the device have to be powered on before starting to download
the firmware.

Fixes: 9aebfd4a2200 ("Bluetooth: mediatek: add support for MediaTek MT7663S and MT7668S SDIO devices")
Co-developed-by: Mark Chen 
Signed-off-by: Mark Chen 
Signed-off-by: Sean Wang 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Sasha Levin

Bluetooth: btusb: fix up firmware download sequence

2020-08-19T06:26:27+00:00

[ Upstream commit f645125711c80f9651e4a57403d799070c6ad13b ]

Data RAM on the device have to be powered on before starting to download
the firmware.

Fixes: a1c49c434e15 ("Bluetooth: btusb: Add protocol support for MediaTek MT7668U USB devices")
Co-developed-by: Mark Chen 
Signed-off-by: Mark Chen 
Signed-off-by: Sean Wang 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Sasha Levin

Bluetooth: hci_qca: Increase SoC idle timeout to 200ms

2020-08-19T06:26:25+00:00

[ Upstream commit 2d68476cfc2afa1a1a2d9007a23264ffc6308e77 ]

In some version of WCN399x, SoC idle timeout is configured
as 80ms instead of 20ms or 40ms. To honor all the SoC's
supported in the driver increasing SoC idle timeout to 200ms.

Fixes: 41d5b25fed0a0 ("Bluetooth: hci_qca: add PM support")
Signed-off-by: Balakrishna Godavarthi 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Sasha Levin

Bluetooth: hci_qca: Bug fix during SSR timeout

2020-08-19T06:26:25+00:00

[ Upstream commit f98aa80ff78c34fe328eb9cd3e2cc3058e42bcfd ]

Due to race conditions between qca_hw_error and qca_controller_memdump
during SSR timeout,the same pointer is freed twice. This results in a
double free. Now a lock is acquired before checking the stauts of SSR
state.

Fixes: d841502c79e3 ("Bluetooth: hci_qca: Collect controller memory dump during SSR")
Signed-off-by: Venkata Lakshmi Narayana Gubba 
Reviewed-by: Abhishek Pandit-Subedi 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Sasha Levin

Bluetooth: hci_qca: Only remove TX clock vote after TX is completed

2020-08-19T06:26:25+00:00

[ Upstream commit eff981f6579d5797d68d27afc0eede529ac8778a ]

qca_suspend() removes the vote for the UART TX clock after
writing an IBS sleep request to the serial buffer. This is
not a good idea since there is no guarantee that the request
has been sent at this point. Instead remove the vote after
successfully entering IBS sleep. This also fixes the issue
of the vote being removed in case of an aborted suspend due
to a failure of entering IBS sleep.

Fixes: 41d5b25fed0a0 ("Bluetooth: hci_qca: add PM support")
Signed-off-by: Matthias Kaehlcke 
Reviewed-by: Abhishek Pandit-Subedi 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Sasha Levin

Bluetooth: hci_qca: Fix an error pointer dereference

2020-08-19T06:26:24+00:00

[ Upstream commit 4c07a5d7aeb39f559b29aa58ec9a8a5ab4282cb0 ]

When a function like devm_clk_get_optional() function returns both error
pointers on error and NULL then the NULL return means that the optional
feature is deliberately disabled.  It is a special sort of success and
should not trigger an error message.  The surrounding code should be
written to check for NULL and not crash.

On the other hand, if we encounter an error, then the probe from should
clean up and return a failure.

In this code, if devm_clk_get_optional() returns an error pointer then
the kernel will crash inside the call to:

	clk_set_rate(qcadev->susclk, SUSCLK_RATE_32KHZ);

The error handling must be updated to prevent that.

Fixes: 77131dfec6af ("Bluetooth: hci_qca: Replace devm_gpiod_get() with devm_gpiod_get_optional()")
Signed-off-by: Dan Carpenter 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Sasha Levin