user/sven/linux.git/drivers/bluetooth/hci_serdev.c, branch v5.19.3

Bluetooth: Add default wakeup callback for HCI UART driver

2022-08-17T13:14:54Z

[ Upstream commit bee5395ced44c5a312348557eb2dfb0c2a7bfaa2 ] Bluetooth HCI devices indicate if they are able to wakeup in the wakeup callback since 'commit 4539ca67fe8e ("Bluetooth: Rename driver .prevent_wake to .wakeup")'. This patch adds a default wakeup callback for Bluetooth HCI UAR devices. It assumes Bluetooth HCI UART devices are wakeable for backward compatibility. For those who need a customized behavior, one can override it before calling hci_uart_register_device(). Fixes: 4539ca67fe8e ("Bluetooth: Rename driver .prevent_wake to .wakeup") Signed-off-by: Ying Hsu Reviewed-by: Alain Michaud Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin

Bluetooth: hci_serdev: call init_rwsem() before p->open()

2022-01-21T22:46:48Z

kvartet reported, that hci_uart_tx_wakeup() uses uninitialized rwsem. The problem was in wrong place for percpu_init_rwsem() call. hci_uart_proto::open() may register a timer whose callback may call hci_uart_tx_wakeup(). There is a chance, that hci_uart_register_device() thread won't be fast enough to call percpu_init_rwsem(). Fix it my moving percpu_init_rwsem() call before p->open(). INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 2 PID: 18524 Comm: syz-executor.5 Not tainted 5.16.0-rc6 #9 ... Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 assign_lock_key kernel/locking/lockdep.c:951 [inline] register_lock_class+0x148d/0x1950 kernel/locking/lockdep.c:1263 __lock_acquire+0x106/0x57e0 kernel/locking/lockdep.c:4906 lock_acquire kernel/locking/lockdep.c:5637 [inline] lock_acquire+0x1ab/0x520 kernel/locking/lockdep.c:5602 percpu_down_read_trylock include/linux/percpu-rwsem.h:92 [inline] hci_uart_tx_wakeup+0x12e/0x490 drivers/bluetooth/hci_ldisc.c:124 h5_timed_event+0x32f/0x6a0 drivers/bluetooth/hci_h5.c:188 call_timer_fn+0x1a5/0x6b0 kernel/time/timer.c:1421 Fixes: d73e17281665 ("Bluetooth: hci_serdev: Init hci_uart proto_lock to avoid oops") Reported-by: Yiru Xu Signed-off-by: Pavel Skripkin Signed-off-by: Marcel Holtmann

Bluetooth: hci_h5: Disable the hci_suspend_notifier for btrtl devices

2021-07-22T14:06:09Z

The hci_suspend_notifier which was introduced last year, is causing problems for uart attached btrtl devices. These devices may loose their firmware and their baudrate setting over a suspend/resume. Since we don't even know the baudrate after a suspend/resume recovering from this is tricky. The driver solves this by treating these devices the same as USB BT HCIs which drop of the bus during suspend. Specifically the driver: 1. Simply unconditionally turns the device fully off during system-suspend to save maximum power. 2. Calls device_reprobe() from a workqueue to fully re-init the device from scratch on system-resume (unregistering the old HCI and registering a new HCI). This means that these devices do not benefit from the suspend / resume handling work done by the hci_suspend_notifier. At best this unnecessarily adds some time to the suspend/resume time. But in practice this is actually causing problems: 1. These btrtl devices seem to not like the HCI_OP_WRITE_SCAN_ENABLE( SCAN_DISABLED) request being send to them when entering the BT_SUSPEND_CONFIGURE_WAKE state. The same request send on BT_SUSPEND_DISCONNECT works fine, but the second one send (unnecessarily?) from the BT_SUSPEND_CONFIGURE_WAKE transition causes the device to hang: [ 573.497754] PM: suspend entry (s2idle) [ 573.554615] Filesystems sync: 0.056 seconds [ 575.837753] Bluetooth: hci0: Timed out waiting for suspend events [ 575.837801] Bluetooth: hci0: Suspend timeout bit: 4 [ 575.837925] Bluetooth: hci0: Suspend notifier action (3) failed: -110 2. The PM_POST_SUSPEND / BT_RUNNING transition races with the driver-unbinding done by the device_reprobe() work. If the hci_suspend_notifier wins the race it is talking to a dead device leading to the following errors being logged: [ 598.686060] Bluetooth: hci0: Timed out waiting for suspend events [ 598.686124] Bluetooth: hci0: Suspend timeout bit: 5 [ 598.686237] Bluetooth: hci0: Suspend notifier action (4) failed: -110 In both cases things still work, but the suspend-notifier is causing these ugly errors getting logged and ut increase both the suspend- and the resume-time by 2 seconds. This commit avoids these problems by disabling the hci_suspend_notifier. Cc: Luiz Augusto von Dentz Cc: Vasily Khoruzhick Cc: Abhishek Pandit-Subedi Signed-off-by: Hans de Goede Signed-off-by: Marcel Holtmann

Bluetooth: hci_uart: Fix a race for write_work scheduling

2020-12-18T21:25:30Z

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

Bluetooth: hci_serdev: Close UART port if NON_PERSISTENT_SETUP is set

2020-09-11T07:09:48Z

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

Bluetooth: hci_uart: Cancel init work before unregistering

2020-08-02T18:01:27Z

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

Bluetooth: hci_serdev: Only unregister device if it was registered

2020-07-28T07:17:19Z

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

Bluetooth: serdev: Constify serdev_device_ops

2020-05-13T07:27:36Z

serdev_device_ops is not modified and can be const. Also, remove the unneeded declaration of it. Output from the file command before and after: Before: text data bss dec hex filename 7192 2408 192 9792 2640 drivers/bluetooth/hci_serdev.o After: text data bss dec hex filename 7256 2344 192 9792 2640 drivers/bluetooth/hci_serdev.o Signed-off-by: Rikard Falkeborn Signed-off-by: Marcel Holtmann

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 157

2019-05-30T18:26:37Z

Based on 3 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version [author] [kishon] [vijay] [abraham] [i] [kishon]@[ti] [com] this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version [author] [graeme] [gregory] [gg]@[slimlogic] [co] [uk] [author] [kishon] [vijay] [abraham] [i] [kishon]@[ti] [com] [based] [on] [twl6030]_[usb] [c] [author] [hema] [hk] [hemahk]@[ti] [com] this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 1105 file(s). Signed-off-by: Thomas Gleixner Reviewed-by: Allison Randal Reviewed-by: Richard Fontana Reviewed-by: Kate Stewart Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070033.202006027@linutronix.de Signed-off-by: Greg Kroah-Hartman

Bluetooth: hci_serdev: Remove setting of HCI_QUIRK_RESET_ON_CLOSE.

2018-12-18T23:41:59Z

HCI_QUIRK_RESET_ON_CLOSE quirk is required for BT v1.0 based devices, to send a reset command to the chip during hci device close. Serdev architecture is used for the latest BT chips, which doesn't require to send the reset command during close. If still chips required reset command during close, it would be better enabling it in the vendor probes or in proto setup. Signed-off-by: Balakrishna Godavarthi Signed-off-by: Marcel Holtmann