summaryrefslogtreecommitdiffstats
path: root/drivers/bluetooth
Commit message (Collapse)AuthorAgeFilesLines
...
* Bluetooth: hci_qca: Bug fixes while collecting controller memory dumpVenkata Lakshmi Narayana Gubba2020-02-181-34/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch will fix the below issues 1. Discarding memory dump events if memdump state is moved to MEMDUMP_TIMEOUT. 2. Fixed race conditions between qca_hw_error() and qca_controller_memdump while free memory dump buffers using mutex lock 3. Moved timeout timer to delayed work queue 4. Injecting HW error event in a case when dumps failed to receive and HW error event is not yet received. 5. Clearing hw error and command timeout function callbacks before sending pre shutdown command. Collecting memory dump will follow any of the below sequence. Sequence 1: Receiving Memory dump events from the controller Received entire dump in stipulated time Received HW error event from the controller Controller Reset from HOST Sequence 2: Receiving Memory dump events from the controller Failed to Receive entire dump in stipulated time A Timeout schedules and if no HW error event received a fake HW error event will be injected. Controller Reset from HOST. Sequence 3: Received HW error event HOST trigger SSR by sending crash packet to controller. Received entire dump in stipulated time Controller Reset from HOST Fixes: d841502c79e3 ("Bluetooth: hci_qca: Collect controller memory dump during SSR") Reported-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Venkata Lakshmi Narayana Gubba <gubbaven@codeaurora.org> Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: hci_h5: btrtl: Add support for RTL8822CMax Chou2020-02-183-1/+33
| | | | | | | Add new compatible and FW loading support for RTL8822C. Signed-off-by: Max Chou <max.chou@realtek.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix a typo in KconfigChristophe JAILLET2020-02-161-1/+1
| | | | | | | 'internface' has an extra 'n'. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: hci_uart: Replace zero-length array with flexible-array memberGustavo A. R. Silva2020-02-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertenly introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: hci_intel: Replace zero-length array with flexible-array memberGustavo A. R. Silva2020-02-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertenly introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btintel: Replace zero-length array with flexible-array memberGustavo A. R. Silva2020-02-131-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertenly introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btusb: Add support for 13d3:3548 Realtek 8822CE deviceSergey Shatunov2020-02-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ASUS FX505DV laptop contains RTL8822CE device with an associated BT chip using a USB ID of 13d3:3548. This patch add fw download support for it. T: Bus=03 Lev=01 Prnt=01 Port=03 Cnt=03 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3548 Rev= 0.00 S: Manufacturer=Realtek S: Product=Bluetooth Radio S: SerialNumber=00e04c000001 C:* #Ifs= 2 Cfg#= 1 Atr=a0 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: Sergey Shatunov <me@prok.pw> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: hci_qca: Optimized code while enabling clocks for BT SOCVenkata Lakshmi Narayana Gubba2020-02-051-7/+3
| | | | | | | | | | * Directly passing clock pointer to clock code without checking for NULL as clock code takes care of it * Removed the comment which was not necessary * Updated code for return in qca_regulator_enable() Signed-off-by: Venkata Lakshmi Narayana Gubba <gubbaven@codeaurora.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: hci_qca: Enable clocks required for BT SOCVenkata Lakshmi Narayana Gubba2020-02-031-0/+16
| | | | | | | | Instead of relying on other subsytem to turn ON clocks required for BT SoC to operate, voting them from the driver. Signed-off-by: Venkata Lakshmi Narayana Gubba <gubbaven@codeaurora.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btrtl: Use kvmalloc for FW allocationsMaxim Mikityanskiy2020-01-241-9/+11
| | | | | | | | | | | | | | | | | | | | | | | | | Currently, kmemdup is applied to the firmware data, and it invokes kmalloc under the hood. The firmware size and patch_length are big (more than PAGE_SIZE), and on some low-end systems (like ASUS E202SA) kmalloc may fail to allocate a contiguous chunk under high memory usage and fragmentation: Bluetooth: hci0: RTL: examining hci_ver=06 hci_rev=000a lmp_ver=06 lmp_subver=8821 Bluetooth: hci0: RTL: rom_version status=0 version=1 Bluetooth: hci0: RTL: loading rtl_bt/rtl8821a_fw.bin kworker/u9:2: page allocation failure: order:4, mode:0x40cc0(GFP_KERNEL|__GFP_COMP), nodemask=(null),cpuset=/,mems_allowed=0 <stack trace follows> As firmware load happens on each resume, Bluetooth will stop working after several iterations, when the kernel fails to allocate an order-4 page. This patch replaces kmemdup with kvmalloc+memcpy. It's not required to have a contiguous chunk here, because it's not mapped to the device directly. Signed-off-by: Maxim Mikityanskiy <maxtram95@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: hci_qca: Enable power off/on support during hci down/up for QCA RomeRocky Liao2020-01-161-9/+11
| | | | | | | | | | | | This patch registers hdev->shutdown() callback and also sets HCI_QUIRK_NON_PERSISTENT_SETUP for QCA Rome. It will power-off the BT chip during hci down and power-on/initialize the chip again during hci up. As wcn399x already enabled this, this patch also removed the callback register and QUIRK setting in qca_setup() for wcn399x and uniformly do this in the probe() routine. Signed-off-by: Rocky Liao <rjliao@codeaurora.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: hci_qca: Retry btsoc initialize when it failsRocky Liao2020-01-151-0/+19
| | | | | | | | | | | | | | This patch adds the retry of btsoc initialization when it fails. There are reports that the btsoc initialization may fail on some platforms but the repro ratio is very low. The symptoms is the firmware downloading failed due to the UART write timed out. The failure may be caused by UART, platform HW or the btsoc itself but it's very difficlut to root cause, given the repro ratio is very low. Add a retry for the btsoc initialization can work around most of the failures and make Bluetooth finally works. Signed-off-by: Rocky Liao <rjliao@codeaurora.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: hci_qca: Add QCA Rome power off support to the qca_power_shutdown()Rocky Liao2020-01-151-12/+16
| | | | | | | | | | | Current qca_power_shutdown() only supports wcn399x, this patch adds Rome power off support to it. For Rome it just needs to pull down the bt_en GPIO to power off it. This patch also replaces all the power off operation in qca_close() with the unified qca_power_shutdown() call. Signed-off-by: Rocky Liao <rjliao@codeaurora.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: hci_bcm: enable IRQ capability from devicetreeGuillaume La Roque2020-01-151-0/+3
| | | | | | | | | | Add support for getting IRQ directly from DT instead of relying on converting a GPIO to IRQ. This is needed for platforms with GPIO controllers that that do not support gpiod_to_irq(). Reviewed-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Guillaume La Roque <glaroque@baylibre.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btsdio: Check for valid packet typeLuiz Augusto von Dentz2020-01-151-5/+14
| | | | | | | | Check for valid packet type before calling hci_recv_frame which is inline with what other drivers are doing. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: hci_h5: Add support for ISO packetsLuiz Augusto von Dentz2020-01-151-0/+3
| | | | | | | This enables H5 driver to properly handle ISO packets. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: hci_h4: Add support for ISO packetsLuiz Augusto von Dentz2020-01-152-0/+8
| | | | | | | This enables H4 driver to properly handle ISO packets. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: hci_vhci: Add support for ISO packetsLuiz Augusto von Dentz2020-01-151-0/+1
| | | | | | | This make virtual controllers to pass ISO packets around. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: hci_qca: Add qca_power_on() API to support both wcn399x and Rome ↵Rocky Liao2020-01-141-21/+33
| | | | | | | | | | | | | | power up This patch adds a unified API qca_power_on() to support both wcn399x and Rome power on. For wcn399x it calls the qca_wcn3990_init() to init the regulators, and for Rome it pulls up the bt_en GPIO to power up the btsoc. It also moves all the power up operation from hdev->open() to hdev->setup(). Signed-off-by: Rocky Liao <rjliao@codeaurora.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btbcm : Fix warning about missing blank lines after declarationsChangqi Du2020-01-091-0/+2
| | | | | | | | This patches fixes two warnings of checkpatch.pl, both of the type WARNING: Missing a blank line after declarations Signed-off-by: Changqi Du <d.changqi@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: hci_qca: Remove set but not used variable 'opcode'YueHaibing2020-01-081-2/+1
| | | | | | | | | | | | | | | Fixes gcc '-Wunused-but-set-variable' warning: drivers/bluetooth/hci_qca.c: In function 'qca_controller_memdump': drivers/bluetooth/hci_qca.c:980:6: warning: variable 'opcode' set but not used [-Wunused-but-set-variable] It is never used since commit d841502c79e3 ("Bluetooth: hci_qca: Collect controller memory dump during SSR"), so remove it. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: hci_qca: Use vfree() instead of kfree()Wei Yongjun2020-01-081-2/+2
| | | | | | | | | | Use vfree() instead of kfree() to free vmalloc() allocated data. Fixes: d841502c79e3 ("Bluetooth: hci_qca: Collect controller memory dump during SSR") Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by: Balakrishna Godavarthi <bgodavar@codeaurora.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btusb: Add support for 04ca:3021 QCA_ROME deviceRocky Liao2020-01-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | USB "VendorID:04ca ProductID:3021" is a new QCA ROME USB Bluetooth device, this patch will support firmware downloading for it. T: Bus=02 Lev=02 Prnt=02 Port=05 Cnt=01 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 2.01 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04ca ProdID=3021 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: Rocky Liao <rjliao@codeaurora.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: hci_qca: Collect controller memory dump during SSRBalakrishna Godavarthi2020-01-041-5/+291
| | | | | | | | | | | | | | We will collect the ramdump of BT controller when hardware error event received before rebooting the HCI layer. Before restarting a subsystem or a process running on a subsystem, it is often required to request either a subsystem or a process to perform proper cache dump and software failure reason into a memory buffer which application processor can retrieve afterwards. SW developers can often provide initial investigation by looking into that debugging information. Signed-off-by: Balakrishna Godavarthi <bgodavar@codeaurora.org> Signed-off-by: Venkata Lakshmi Narayana Gubba <gubbaven@codeaurora.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: hci_bcm: Drive RTS only for BCM43438Stefan Wahren2020-01-041-4/+17
| | | | | | | | | | | The commit 3347a80965b3 ("Bluetooth: hci_bcm: Fix RTS handling during startup") is causing at least a regression for AP6256 on Orange Pi 3. So do the RTS line handing during startup only on the necessary platform. Fixes: 3347a80965b3 ("Bluetooth: hci_bcm: Fix RTS handling during startup") Reported-by: Ondřej Jirman <megous@megous.com> Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btbcm: Add missing static inline in headerAbhishek Pandit-Subedi2020-01-041-2/+2
| | | | | | | | This fixes a double definition error when CONFIG_BT_BCM is not set. Fixes: 528379902337 ("Bluetooth: btbcm: Support pcm configuration") Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: hci_qca: Replace of_device_get_match_data with device_get_match_dataRocky Liao2020-01-041-1/+1
| | | | | | | | Replace of_device_get_match_data with device_get_match_data to make driver work across platforms. Signed-off-by: Rocky Liao <rjliao@codeaurora.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: hci_bcm: Add device-tree compatible for BCM4329Dmitry Osipenko2020-01-041-0/+1
| | | | | | | | | | Driver supports BCM4329, but there is no device-tree compatible for that chip. Let's add it in order to allow boards to specify Bluetooth in theirs device-trees, in particular this is useful for NVIDIA Tegra20 boards. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btusb: Disable runtime suspend on Realtek devicesKai-Heng Feng2019-12-051-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | After commit 9e45524a0111 ("Bluetooth: btusb: Fix suspend issue for Realtek devices") both WiFi and Bluetooth stop working after reboot: [ 34.322617] usb 1-8: reset full-speed USB device number 3 using xhci_hcd [ 34.450401] usb 1-8: device descriptor read/64, error -71 [ 34.694375] usb 1-8: device descriptor read/64, error -71 ... [ 44.599111] rtw_pci 0000:02:00.0: failed to poll offset=0x5 mask=0x3 value=0x0 [ 44.599113] rtw_pci 0000:02:00.0: mac power on failed [ 44.599114] rtw_pci 0000:02:00.0: failed to power on mac [ 44.599114] rtw_pci 0000:02:00.0: leave idle state failed [ 44.599492] rtw_pci 0000:02:00.0: failed to leave ips state [ 44.599493] rtw_pci 0000:02:00.0: failed to leave idle state That commit removed USB_QUIRK_RESET_RESUME, which not only resets the USB device after resume, it also prevents the device from being runtime suspended by USB core. My experiment shows if the Realtek btusb device ever runtime suspends once, the entire wireless module becomes useless after reboot. So let's explicitly disable runtime suspend on Realtek btusb device for now. Fixes: 9e45524a0111 ("Bluetooth: btusb: Fix suspend issue for Realtek devices") Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btusb: fix memory leak on fwColin Ian King2019-11-291-1/+1
| | | | | | | | | | | Currently the error return path when the call to btusb_mtk_hci_wmt_sync fails does not free fw. Fix this by returning via the error_release_fw label that performs the free'ing. Addresses-Coverity: ("Resource leak") Fixes: a1c49c434e15 ("Bluetooth: btusb: Add protocol support for MediaTek MT7668U USB devices") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btusb: fix non-atomic allocation in completion handlerJohan Hovold2019-11-281-1/+1
| | | | | | | | | | | USB completion handlers are called in atomic context and must specifically not allocate memory using GFP_KERNEL. Fixes: a1c49c434e15 ("Bluetooth: btusb: Add protocol support for MediaTek MT7668U USB devices") Cc: stable <stable@vger.kernel.org> # 5.3 Cc: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: hci_bcm: Support pcm params in dtsAbhishek Pandit-Subedi2019-11-271-0/+19
| | | | | | | | | | BCM chips may require configuration of PCM to operate correctly and there is a vendor specific HCI command to do this. Add support in the hci_bcm driver to parse this from devicetree and configure the chip. Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: btbcm: Support pcm configurationAbhishek Pandit-Subedi2019-11-272-0/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Add BCM vendor specific command to configure PCM parameters. The new vendor opcode allows us to set the sco routing, the pcm interface rate, and a few other pcm specific options (frame sync, sync mode, and clock mode). See broadcom-bluetooth.txt in Documentation for more information about valid values for those settings. Here is an example trace where this opcode was used to configure a BCM4354: < HCI Command: Vendor (0x3f|0x001c) plen 5 01 02 00 01 01 > HCI Event: Command Complete (0x0e) plen 4 Vendor (0x3f|0x001c) ncmd 1 Status: Success (0x00) We can read back the values as well with ocf 0x001d to confirm the values that were set: $ hcitool cmd 0x3f 0x001d < HCI Command: ogf 0x3f, ocf 0x001d, plen 0 > HCI Event: 0x0e plen 9 01 1D FC 00 01 02 00 01 01 Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: hci_bcm: Disallow set_baudrate for BCM4354Abhishek Pandit-Subedi2019-11-271-2/+29
| | | | | | | | | | | | Without updating the patchram, the BCM4354 does not support a higher operating speed. The normal bcm_setup follows the correct order (init_speed, patchram and then oper_speed) but the serdev driver will set the operating speed before calling the hu->setup function. Thus, for the BCM4354, don't set the operating speed before patchram. Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: btusb: Edit the logical value for Realtek Bluetooth resetMax Chou2019-11-271-2/+2
| | | | | | | | | It should be pull low and pull high on the physical line for the Realtek Bluetooth reset. gpiod_set_value_cansleep() takes ACTIVE_LOW status for the logical value settings, so the original commit should be corrected. Signed-off-by: Max Chou <max.chou@realtek.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btbcm: Use the BDADDR_PROPERTY quirkAndre Heider2019-11-221-0/+6
| | | | | | | | | | Some devices ship with the controller default address, like the Orange Pi 3 (BCM4345C5). Allow the bootloader to set a valid address through the device tree. Signed-off-by: Andre Heider <a.heider@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btbcm: Add entry for BCM4335A0 UART bluetoothMohammad Rasim2019-11-212-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds the device ID for the BCM4335A0 module (part of the AMPAK AP6335 WIFI/Bluetooth combo) hciconfig output: ``` hci1: Type: Primary Bus: UART BD Address: 43:35:B0:07:1F:AC ACL MTU: 1021:8 SCO MTU: 64:1 UP RUNNING RX bytes:5079 acl:0 sco:0 events:567 errors:0 TX bytes:69065 acl:0 sco:0 commands:567 errors:0 Features: 0xbf 0xfe 0xcf 0xff 0xdf 0xff 0x7b 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH SNIFF Link mode: SLAVE ACCEPT Name: 'alarm' Class: 0x000000 Service Classes: Unspecified Device Class: Miscellaneous, HCI Version: 4.0 (0x6) Revision: 0x161 LMP Version: 4.0 (0x6) Subversion: 0x4106 Manufacturer: Broadcom Corporation (15) ``` Signed-off-by: Mohammad Rasim <mohammad.rasim96@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btbcm: Add entry for BCM4334B0 UART BluetoothStephan Gerhold2019-11-191-0/+3
| | | | | | | | | | | Add the device ID for the WiFi/BT/FM combo chip BCM4334 (rev B0). The chip seems to use 43:34:b0:00:00:00 as default address, so add it to the list of default addresses and leave it up to the user to configure a valid one. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btusb: fix PM leak in error case of setupOliver Neukum2019-11-151-1/+2
| | | | | | | | | | If setup() fails a reference for runtime PM has already been taken. Proper use of the error handling in btusb_open()is needed. You cannot just return. Fixes: ace31982585a3 ("Bluetooth: btusb: Add setup callback for chip init on USB") Signed-off-by: Oliver Neukum <oneukum@suse.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: hci_qca: Add support for Qualcomm Bluetooth SoC WCN3991Balakrishna Godavarthi2019-11-093-20/+74
| | | | | | | | This patch add support for WCN3991 i.e. current values and fw download support. Signed-off-by: Balakrishna Godavarthi <bgodavar@codeaurora.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btqca: Rename ROME specific variables to generic variablesBalakrishna Godavarthi2019-11-092-25/+25
| | | | | | | | | Variables which are named with rome are commonly used for all the BT SoC's. Instead of continuing further, renamed them to generic name. Signed-off-by: Balakrishna Godavarthi <bgodavar@codeaurora.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btmtksdio: add MODULE_DEVICE_TABLE()Bartosz Golaszewski2019-11-071-0/+1
| | | | | | | | | | This adds the missing MODULE_DEVICE_TABLE() for SDIO IDs. While certain platforms using this driver indeed have HW issues causing problems if the module is loaded too early - this should be handled from user-space by blacklisting it or delaying the loading. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix invalid-free in bcsp_close()Tomas Bortoli2019-11-041-0/+3
| | | | | | | | | | | Syzbot reported an invalid-free that I introduced fixing a memleak. bcsp_recv() also frees bcsp->rx_skb but never nullifies its value. Nullify bcsp->rx_skb every time it is freed. Signed-off-by: Tomas Bortoli <tomasbortoli@gmail.com> Reported-by: syzbot+a0d209a4676664613e76@syzkaller.appspotmail.com Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: hci_qca: add PM supportClaire Chang2019-11-041-3/+124
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add PM suspend/resume callbacks for hci_qca driver. BT host will make sure both Rx and Tx go into sleep state in qca_suspend. Without this, Tx may still remain in awake state, which prevents BTSOC from entering deep sleep. For example, BlueZ will send Set Event Mask to device when suspending and this will wake the device Rx up. However, the Tx idle timeout on the host side is 2000 ms. If the host is suspended before its Tx idle times out, it won't send HCI_IBS_SLEEP_IND to the device and the device Rx will remain awake. We implement this by canceling relevant work in workqueue, sending HCI_IBS_SLEEP_IND to the device and then waiting HCI_IBS_SLEEP_IND sent by the device. In order to prevent the device from being awaken again after qca_suspend is called, we introduce QCA_SUSPEND flag. QCA_SUSPEND is set in the beginning of qca_suspend to indicate system is suspending and that we'd like to ignore any further wake events. With QCA_SUSPEND and spinlock, we can avoid race condition, e.g. if qca_enqueue acquires qca->hci_ibs_lock before qca_suspend calls cancel_work_sync and then qca_enqueue adds a new qca->ws_awake_device work after the previous one is cancelled. If BTSOC wants to wake the whole system up after qca_suspend is called, it will keep sending HCI_IBS_WAKE_IND and uart driver will take care of waking the system. For example, uart driver will reconfigure its Rx pin to a normal GPIO pin and enable irq wake on that pin when suspending. Once host detects Rx falling, the system will begin resuming. Then, the BT host clears QCA_SUSPEND flag in qca_resume and begins dealing with normal HCI packets. By doing so, only a few HCI_IBS_WAKE_IND packets are lost and there is no data packet loss. Signed-off-by: Claire Chang <tientzu@chromium.org> Reviewed-by: Balakrishna Godavarthi <bgodavar@codeaurora.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: hci_bcm: Add compatible string for BCM43540Abhishek Pandit-Subedi2019-10-261-0/+1
| | | | | | | | | The BCM43540 chip is a 802.11 a/b/g/n/ac + Bluetooth 4.1 combo module. This patch adds a compatible string match to the serdev driver for the Bluetooth part of the chip. Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btrtl: remove unneeded semicolonYueHaibing2019-10-261-1/+1
| | | | | | | | Remove unneeded semicolon. This is detected by coccinelle. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: hci_bcm: Fix RTS handling during startupStefan Wahren2019-10-211-0/+2
| | | | | | | | | | | The RPi 4 uses the hardware handshake lines for CYW43455, but the chip doesn't react to HCI requests during DT probe. The reason is the inproper handling of the RTS line during startup. According to the startup signaling sequence in the CYW43455 datasheet, the hosts RTS line must be driven after BT_REG_ON and BT_HOST_WAKE. Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Revert "Bluetooth: hci_qca: Add delay for wcn3990 stability"Jeffrey Hugo2019-10-211-3/+1
| | | | | | | | | | | | This reverts commit cde9dde6e11a5ab54b6462cd46d82878926783bc. The frame reassembly errors were root caused to a transient gpio issue. The missing response was root caused to an issue with properly managing RFR in the uart driver. Addressing those root causes occurs outside of hci_qca and eliminates the need for the 50ms delay, so remove it. Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btusb: Remove return statement in btintel_reset_to_bootloaderNathan Chancellor2019-10-191-1/+0
| | | | | | | | | | | | | | | | | | | | | | When building with Clang and CONFIG_BT_INTEL unset, the following error occurs: In file included from drivers/bluetooth/hci_ldisc.c:34: drivers/bluetooth/btintel.h:188:2: error: void function 'btintel_reset_to_bootloader' should not return a value [-Wreturn-type] return -EOPNOTSUPP; ^ ~~~~~~~~~~~ 1 error generated. Remove the unneeded return statement to fix this. Fixes: b9a2562f4918 ("Bluetooth: btusb: Trigger Intel FW download error recovery") Link: https://github.com/ClangBuiltLinux/linux/issues/743 Reported-by: <ci_notify@linaro.org> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: hci_qca: Split qca_power_setup()Bjorn Andersson2019-10-171-25/+36
| | | | | | | | | Split and rename qca_power_setup() in order to simplify each code path and to clarify that it is unrelated to qca_power_off() and qca_power_setup(). Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>