kernel/drivers/bluetooth/hci_uart.h, branch linux-4.16.y

Bluetooth: hci_ldisc: Allow sleeping while proto locks are held.

2017-10-29T13:03:28Z

Commit dec2c92880cc5435381d50e3045ef018a762a917 ("Bluetooth: hci_ldisc: Use rwlocking to avoid closing proto races") introduced locks in hci_ldisc that are held while calling the proto functions. These locks are rwlock's, and hence do not allow sleeping while they are held. However, the proto functions that hci_bcm registers use mutexes and hence need to be able to sleep. In more detail: hci_uart_tty_receive() and hci_uart_dequeue() both acquire the rwlock, after which they call proto->recv() and proto->dequeue(), respectively. In the case of hci_bcm these point to bcm_recv() and bcm_dequeue(). The latter both acquire the bcm_device_lock, which is a mutex, so doing so results in a call to might_sleep(). But since we're holding a rwlock in hci_ldisc, that results in the following BUG (this for the dequeue case - a similar one for the receive case is omitted for brevity): BUG: sleeping function called from invalid context at kernel/locking/mutex.c in_atomic(): 1, irqs_disabled(): 0, pid: 7303, name: kworker/7:3 INFO: lockdep is turned off. CPU: 7 PID: 7303 Comm: kworker/7:3 Tainted: G W OE 4.13.2+ #17 Hardware name: Apple Inc. MacBookPro13,3/Mac-A5C67F76ED83108C, BIOS MBP133.8 Workqueue: events hci_uart_write_work [hci_uart] Call Trace: dump_stack+0x8e/0xd6 ___might_sleep+0x164/0x250 __might_sleep+0x4a/0x80 __mutex_lock+0x59/0xa00 ? lock_acquire+0xa3/0x1f0 ? lock_acquire+0xa3/0x1f0 ? hci_uart_write_work+0xd3/0x160 [hci_uart] mutex_lock_nested+0x1b/0x20 ? mutex_lock_nested+0x1b/0x20 bcm_dequeue+0x21/0xc0 [hci_uart] hci_uart_write_work+0xe6/0x160 [hci_uart] process_one_work+0x253/0x6a0 worker_thread+0x4d/0x3b0 kthread+0x133/0x150 We can't replace the mutex in hci_bcm, because there are other calls there that might sleep. Therefore this replaces the rwlock's in hci_ldisc with rw_semaphore's (which allow sleeping). This is a safer approach anyway as it reduces the restrictions on the proto callbacks. Also, because acquiring write-lock is very rare compared to acquiring the read-lock, the percpu variant of rw_semaphore is used. Lastly, because hci_uart_tx_wakeup() may be called from an IRQ context, we can't block (sleep) while trying acquire the read lock there, so we use the trylock variant. Signed-off-by: Ronald Tschalär Reviewed-by: Lukas Wunner Signed-off-by: Marcel Holtmann

Bluetooth: hci_serdev: Introduce hci_uart_unregister_device()

2017-07-20T09:18:36Z

Several drivers have the same (and incorrect) code in their _remove() handler. Coalesce this into a shared function. Signed-off-by: Ian Molton Reviewed-by: Sebastian Reichel Signed-off-by: Marcel Holtmann

Bluetooth: hci_ldisc: Use rwlocking to avoid closing proto races

2017-05-18T11:52:50Z

When HCI_UART_PROTO_READY is in the set state, the Data Link protocol layer (proto) is bound to the HCI UART driver. This state allows the registered proto function pointers to be used by the HCI UART driver. When unbinding (closing) the Data Link protocol layer, the proto function pointers much be prevented from being used immediately before running the proto close function pointer. Otherwise, there is a risk that a proto non-close function pointer is used during or after the proto close function pointer is used. The consequences are likely to be a kernel crash because the proto close function pointer will free resources used in the Data Link protocol layer. Therefore, add a reader writer lock (rwlock) solution to prevent the close proto function pointer from running by using write_lock_irqsave() whilst the other proto function pointers are protected using read_lock(). This means HCI_UART_PROTO_READY can safely be cleared in the knowledge that no proto function pointers are running. When flag HCI_UART_PROTO_READY is put into the clear state, proto close function pointer can safely be run. Note flag HCI_UART_PROTO_SET being in the set state prevents the proto open function pointer from being run so there is no race condition between proto open and close function pointers. Signed-off-by: Dean Jenkins Signed-off-by: Marcel Holtmann

bluetooth: hci_uart: remove unused hci_uart_init_tty

2017-04-13T17:22:53Z

There are no users of hci_uart_init_tty, so remove it. Signed-off-by: Rob Herring Cc: Marcel Holtmann Cc: Gustavo Padovan Cc: Johan Hedberg Cc: linux-bluetooth@vger.kernel.org Signed-off-by: Marcel Holtmann

Bluetooth: hci_uart: add serdev driver support library

2017-04-12T20:12:17Z

This adds library functions for serdev based BT drivers. This is largely copied from hci_ldisc.c and modified to use serdev calls. There's a little bit of duplication, but I avoided intermixing this as the ldisc code should eventually go away. Signed-off-by: Rob Herring Cc: Marcel Holtmann Cc: Gustavo Padovan Cc: Johan Hedberg Cc: linux-bluetooth@vger.kernel.org Acked-by: Pavel Machek [Fix style issues reported by Pavel] Signed-off-by: Sebastian Reichel Signed-off-by: Marcel Holtmann

Bluetooth: hci_uart: add support for word alignment

2017-04-12T20:12:17Z

This will be used by Nokia's H4+ protocol, which uses 2-byte aligned packets. Acked-by: Pavel Machek Signed-off-by: Sebastian Reichel Signed-off-by: Marcel Holtmann

Bluetooth: hci_uart: Add Marvell support

2016-09-19T18:32:03Z

This patch introduces support for Marvell Bluetooth controller over UART (8897 for now). In order to send the final firmware at full speed, a helper firmware is firstly sent. Firmware download is driven by the controller which sends request firmware packets (including expected size). This driver is a global rework of the one proposed by Amitkumar Karwar . Signed-off-by: Loic Poulain Signed-off-by: Marcel Holtmann

Bluetooth: hci_uart: Add Nokia Protocol identifier

2016-09-19T18:25:37Z

Will be used by hci_nokia extra protocol. Signed-off-by: Loic Poulain Signed-off-by: Marcel Holtmann

Bluetooth: hci_ldisc: Fix null pointer derefence in case of early data

2016-04-08T16:58:56Z

HCI_UART_PROTO_SET flag is set before hci_uart_set_proto call. If we receive data from tty layer during this procedure, proto pointer may not be assigned yet, leading to null pointer dereference in rx method hci_uart_tty_receive. This patch fixes this issue by introducing HCI_UART_PROTO_READY flag in order to avoid any proto operation before proto opening and assignment. Signed-off-by: Loic Poulain Signed-off-by: Marcel Holtmann

Bluetooth: hci_uart: Add Intel/AG6xx support

2016-02-24T15:34:23Z

This driver implements support for iBT2.1 Bluetooth controller embedded in the AG620 communication combo. The controller needs to be configured with bddata and can be patched with a binary patch file (pbn). These operations are performed in manufacturing mode. Signed-off-by: Loic Poulain Signed-off-by: Marcel Holtmann