History log of /linux-master/drivers/bluetooth/hci_uart.h
Revision Date Author Comments
# 7a6d793e 23-Feb-2024 Andrey Skvortsov <andrej.skvortzov@gmail.com>

Bluetooth: hci_h5: Add ability to allocate memory for private data

In some cases uart-base drivers may need to use priv data. For
example, to store information needed for devcoredump.

Fixes: 044014ce85a1 ("Bluetooth: btrtl: Add Realtek devcoredump support")
Signed-off-by: Andrey Skvortsov <andrej.skvortzov@gmail.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>


# b4a46996 29-Jun-2021 Hans de Goede <hdegoede@redhat.com>

Bluetooth: hci_h5: Disable the hci_suspend_notifier for btrtl devices

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 <luiz.von.dentz@intel.com>
Cc: Vasily Khoruzhick <anarsoul@gmail.com>
Cc: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>


# ef564119 15-Jan-2020 Luiz Augusto von Dentz <luiz.von.dentz@intel.com>

Bluetooth: hci_h4: Add support for ISO packets

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>


# b36a1552 30-Jul-2019 Vladis Dronov <vdronov@redhat.com>

Bluetooth: hci_uart: check for missing tty operations

Certain ttys operations (pty_unix98_ops) lack tiocmget() and tiocmset()
functions which are called by the certain HCI UART protocols (hci_ath,
hci_bcm, hci_intel, hci_mrvl, hci_qca) via hci_uart_set_flow_control()
or directly. This leads to an execution at NULL and can be triggered by
an unprivileged user. Fix this by adding a helper function and a check
for the missing tty operations in the protocols code.

This fixes CVE-2019-10207. The Fixes: lines list commits where calls to
tiocm[gs]et() or hci_uart_set_flow_control() were added to the HCI UART
protocols.

Link: https://syzkaller.appspot.com/bug?id=1b42faa2848963564a5b1b7f8c837ea7b55ffa50
Reported-by: syzbot+79337b501d6aa974d0f6@syzkaller.appspotmail.com
Cc: stable@vger.kernel.org # v2.6.36+
Fixes: b3190df62861 ("Bluetooth: Support for Atheros AR300x serial chip")
Fixes: 118612fb9165 ("Bluetooth: hci_bcm: Add suspend/resume PM functions")
Fixes: ff2895592f0f ("Bluetooth: hci_intel: Add Intel baudrate configuration support")
Fixes: 162f812f23ba ("Bluetooth: hci_uart: Add Marvell support")
Fixes: fa9ad876b8e0 ("Bluetooth: hci_qca: Add support for Qualcomm Bluetooth chip wcn3990")
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Reviewed-by: Yu-Chen, Cho <acho@suse.com>
Tested-by: Yu-Chen, Cho <acho@suse.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>


# 40fbb915 14-Jun-2019 Sascha Hauer <s.hauer@pengutronix.de>

Bluetooth: hci_ldisc: Add function to wait for characters to be sent

The hci UART line discipline sends its characters in a workqueue. Some
devices like the Marvell Bluetooth chips need to make sure that all
queued characters are sent before switching the baudrate. This adds
a function to synchronize with the workqueue.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>


# 1a59d1b8 27-May-2019 Thomas Gleixner <tglx@linutronix.de>

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

Based on 1 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 you
should have received a copy of the gnu general public license along
with this program if not write to the free software foundation inc
59 temple place suite 330 boston ma 02111 1307 usa

extracted by the scancode license scanner the SPDX license identifier

GPL-2.0-or-later

has been chosen to replace the boilerplate/reference in 1334 file(s).

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Allison Randal <allison@lohutok.net>
Reviewed-by: Richard Fontana <rfontana@redhat.com>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190527070033.113240726@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>


# fdee6d8f 27-May-2018 Hans de Goede <hdegoede@redhat.com>

Bluetooth: hci_serdev: Fix HCI_UART_INIT_PENDING not working

Init hci_uart->init_ready so that hci_uart_init_ready() works properly.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>


# 67d2f878 25-Oct-2017 Ronald Tschalär <ronald@innovation.ch>

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

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 <ronald@innovation.ch>
Reviewed-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>


# c34dc3bf 08-Jul-2017 Ian Molton <ian@mnementh.co.uk>

Bluetooth: hci_serdev: Introduce hci_uart_unregister_device()

Several drivers have the same (and incorrect) code in their
_remove() handler.

Coalesce this into a shared function.

Signed-off-by: Ian Molton <ian@mnementh.co.uk>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>


# dec2c928 05-May-2017 Dean Jenkins <Dean_Jenkins@mentor.com>

Bluetooth: hci_ldisc: Use rwlocking to avoid closing proto races

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 <Dean_Jenkins@mentor.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>


# 31927e5a 13-Apr-2017 Rob Herring <robh@kernel.org>

bluetooth: hci_uart: remove unused hci_uart_init_tty

There are no users of hci_uart_init_tty, so remove it.

Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Cc: linux-bluetooth@vger.kernel.org
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>


# 82f5169b 28-Mar-2017 Rob Herring <robh@kernel.org>

Bluetooth: hci_uart: add serdev driver support library

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 <robh@kernel.org>
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Cc: linux-bluetooth@vger.kernel.org
Acked-by: Pavel Machek <pavel@ucw.cz>
[Fix style issues reported by Pavel]
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>


# aeac3014 28-Mar-2017 Sebastian Reichel <sre@kernel.org>

Bluetooth: hci_uart: add support for word alignment

This will be used by Nokia's H4+ protocol, which
uses 2-byte aligned packets.

Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>


# 162f812f 19-Sep-2016 Loic Poulain <loic.poulain@intel.com>

Bluetooth: hci_uart: Add Marvell support

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 <akarwar@marvell.com>.

Signed-off-by: Loic Poulain <loic.poulain@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>


# 9e69130c 19-Sep-2016 Loic Poulain <loic.poulain@intel.com>

Bluetooth: hci_uart: Add Nokia Protocol identifier

Will be used by hci_nokia extra protocol.

Signed-off-by: Loic Poulain <loic.poulain@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>


# 84cb3df0 04-Apr-2016 Loic Poulain <loic.poulain@intel.com>

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

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 <loic.poulain@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>


# 395174bb 22-Feb-2016 Loic Poulain <loic.poulain@intel.com>

Bluetooth: hci_uart: Add Intel/AG6xx support

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 <loic.poulain@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>


# aee61f7a 20-Oct-2015 Marcel Holtmann <marcel@holtmann.org>

Bluetooth: hci_uart: Provide initial manufacturer information

Provide an early indication about the manufacturer information so that
it can be forwarded into monitor channel.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>


# 7649faff 23-Sep-2015 Frederic Danis <frederic.danis@linux.intel.com>

Bluetooth: Remove useless rx_lock spinlock

rx_lock spinlock is only used in hci_uart_tty_receive() which is the
receive_buf ldisc callback.

hci_uart_tty_receive() is protected from re-entrance by its only
caller (flush_to_ldisc() in drivers/tty/tty_buffer.c) which held a
mutex (buf->lock) for this section.
This lock allows "safe use of the line discipline's receive_buf()
method by excluding the buffer work and any pending flush from using
the flip buffer." (comments from tty_buffer_lock_exclusive() in
drivers/tty/tty_buffer.c)

So, no need to double protect this resource with rx_lock.

Signed-off-by: Frederic Danis <frederic.danis@linux.intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>


# 0ff252c1 10-Aug-2015 Ben Young Tae Kim <ytkim@qca.qualcomm.com>

Bluetooth: hciuart: Add support QCA chipset for UART

QCA61x4 chips have supported sleep feature using In-Band-Sleep commands
to enable sleep feature based on H4 protocol. After sending
patch/nvm configuration is done, IBS mode will be up and running

Signed-off-by: Ben Young Tae Kim <ytkim@qca.qualcomm.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>


# ca93cee5 30-Jun-2015 Loic Poulain <loic.poulain@intel.com>

Bluetooth: hci_uart: Add basic support for Intel Lightning Peak devices

The Intel Lightning Peak devices do not come with Bluetooth firmware
loaded and thus require a full download of the operational Bluetooth
firmware when the device is attached via the Bluetooth line discipline.

Lightning Peak devices start with a bootloader mode that only accepts
a very limited set of HCI commands. The supported commands are enough
to identify the hardware and select the right firmware to load.

Signed-off-by: Loic Poulain <loic.poulain@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>


# 2a973dfa 17-Jun-2015 Ilya Faenson <ifaenson@broadcom.com>

Bluetooth: hci_uart: Add new line discipline enhancements

Added the ability to flow control the UART, improved the UART baud
rate setting, transferred the speeds into line discipline from the
protocol and introduced the tty init function.

Signed-off-by: Ilya Faenson <ifaenson@broadcom.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>


# 7721383f 28-May-2015 Frederic Danis <frederic.danis@linux.intel.com>

Bluetooth: hci_uart: Support operational speed during setup

Add initial and operational speeds.
Change to operational speed as soon as possible. If controller
set_baudrate() fails, continue at initial speed.

Signed-off-by: Frederic Danis <frederic.danis@linux.intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>


# bca03c95 06-Apr-2015 Marcel Holtmann <marcel@holtmann.org>

Bluetooth: hci_uart: Use generic Intel support for address setting

The Bluetooth address setting for Intel devices is provided by a generic
module now. Start using that module instead of relying it being included
in the driver.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>


# 79b8df93 06-Apr-2015 Marcel Holtmann <marcel@holtmann.org>

Bluetooth: hci_uart: Provide generic H:4 receive framework

Future H:4 based UART drivers require custom packet types and custom
receive functions. To support this, extended the h4_recv_buf function
with a packet definition table.

For the default H:4 packets types of ACL data, SCO data and events,
provide helpers to reduce the amount of code duplication.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>


# bdd8818e 05-Apr-2015 Marcel Holtmann <marcel@holtmann.org>

Bluetooth: hci_uart: Add protocol support for Broadcom UART devices

This adds the protocol support for Broadcom based UART devices to
enable firmware and patchram download procedure. It is a pretty
straight forward H:4 driver with the exception of actually having
its own setup and address configuration callbacks.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>


# 6ae4fddf 05-Apr-2015 Marcel Holtmann <marcel@holtmann.org>

Bluetooth: hci_uart: Move setup callback into different location

The setup callback got wrongly inserted between the enqueue and dequeue
callbacks. Move it to a better location.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>


# 3e0ac12a 05-Apr-2015 Marcel Holtmann <marcel@holtmann.org>

Bluetooth: hci_uart: Use generic functionality from Broadcom module

The new Broadcom Bluetooth support module provides generic functionality
for changing and checking the Bluetooth device address. Use these new
features instead of keeping a duplicate in the driver.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>


# 7c40fb8d 04-Apr-2015 Marcel Holtmann <marcel@holtmann.org>

Bluetooth: hci_uart: Add name information to hci_uart_proto struct

This adds an extra name field to the hci_uart_proto struct that provides
a simple way of adding a string identifier to the protocol.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>


# 4ee7ef19 04-Apr-2015 Marcel Holtmann <marcel@holtmann.org>

Bluetooth: hci_uart: Make struct hci_uart_proto always const

The usage of struct hci_uart_proto should always be const. Change the
function headers and individual protocol drivers.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>


# e1a38d70 04-Apr-2015 Marcel Holtmann <marcel@holtmann.org>

Bluetooth: hci_uart: Introduce h4_recv_buf helper function

The h4_recv_buf helper function can be used for receiving H:4 packets
out of a TTY stream. It is self-contained and allows for reuse by all
HCI UART protocols.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>


# 9d1c40eb 04-Apr-2015 Marcel Holtmann <marcel@holtmann.org>

Bluetooth: hci_uart: Use const data pointer for received data

The TTY layer provides its data pointers as const, but the HCI UART
callbacks expect them as general data pointers. This is of course
wrong and instead of casting them, just fix the individual drivers
to actually take a const data pointer.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>


# e9a2dd26 04-Apr-2015 Marcel Holtmann <marcel@holtmann.org>

Bluetooth: hci_uart: Add support Broadcom address configuration

When using vendor detection, this adds support for the Broadcom
specific address configuration command.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>


# 16e3887f 04-Apr-2015 Marcel Holtmann <marcel@holtmann.org>

Bluetooth: hci_uart: Add support Intel address configuration

When using vendor detection, this adds support for the Intel specific
address configuration command.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>


# fb2ce8d1 04-Apr-2015 Marcel Holtmann <marcel@holtmann.org>

Bluetooth: hci_uart: Add support for vendor detection flag

This adds a new HCI_UART_VND_DETECT flag to allow automatic vendor
detection. This allows to enable known vendor commands (for example
for setting the public device address) when using a standard H:4
UART protocol or when running in virtual machines.

When this new flag is configured and no vendor specific setup
routine is provided, then the local version information are read
and the provided manufacturer information can be evaluated to
configure extra vendor callbacks.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>


# eb173809 25-Mar-2015 Loic Poulain <loic.poulain@intel.com>

Bluetooth: hci_uart: Add setup callback

Some Bluetooth controllers require initialization before being
used (vendor config, firmware download). Add possibility for a
HCI UART proto to implement this early init via the setup callback.

Signed-off-by: Loic Poulain <loic.poulain@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>


# 6afd04ad 10-Jul-2014 Marcel Holtmann <marcel@holtmann.org>

Bluetooth: Add support for external configuration with UART driver

The quirk for enabling external configuration with UART needs to be
provided via the HCI UART flags. Add a new flag for it and declare
it as valid.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>


# da64c27d 23-Apr-2014 Felipe Balbi <balbi@ti.com>

bluetooth: hci_ldisc: fix deadlock condition

LDISCs shouldn't call tty->ops->write() from within
->write_wakeup().

->write_wakeup() is called with port lock taken and
IRQs disabled, tty->ops->write() will try to acquire
the same port lock and we will deadlock.

Acked-by: Marcel Holtmann <marcel@holtmann.org>
Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
Reported-by: Huang Shijie <b32955@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Tested-by: Andreas Bießmann <andreas@biessmann.de>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>


# 9f2aee84 16-Jul-2012 Johan Hedberg <johan.hedberg@intel.com>

Bluetooth: Add delayed init sequence support for UART controllers

This patch makes it possible to have UART drivers perform an internal
initialization before calling hci_register_dev. This allows moving a lot
of init code from user space (hciattach) to the kernel side, thereby
creating a more controlled/robust initialization process.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>


# 7dec65c8 16-Jul-2012 Johan Hedberg <johan.hedberg@intel.com>

Bluetooth: Initial skeleton for Three-wire UART (H5) support

This patch adds the initial skeleton for Three-wire UART (H5) support
and hooks it up to the HCI UART framework.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>


# 8a7a3fd6 24-Feb-2012 Marcel Holtmann <marcel@holtmann.org>

Bluetooth: Add support for creating HCI UART based AMP controllers

In reality this might never be used for real hardware, but it is a nice
feature for emulating AMP controllers within a virtual machine.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>


# a55e1f38 24-Feb-2012 Marcel Holtmann <marcel@holtmann.org>

Bluetooth: Allow HCI UART reset parameter via flags ioctl

The flags ioctl for HCI UART drivers already allows setting of certain
Bluetooth core quirks. The reset parameter fits right in here. So allow
this as well.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>


# b3190df6 18-Jul-2010 Suraj Sumangala <suraj@atheros.com>

Bluetooth: Support for Atheros AR300x serial chip

Implements Atheros AR300x serial HCI protocol.

This protocol extends H4 serial protocol to implement enhanced power
management features supported by Atheros AR300x serial Bluetooth chipsets.

Signed-off-by: Suraj Sumangala <suraj@atheros.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>


# 63c7d09c 12-Jul-2010 Johan Hedberg <johan.hedberg@nokia.com>

Bluetooth: Add HCIUARTSETFLAGS and HCIUARTGETFLAGS ioctls

This patch introduces two new ioctls: HCIUARTSETFLAGS and
HCIUARTGETFLAGS. The only flag available for now is HCI_UART_RAW_DEVICE
which allows to initialize a UART device into RAW mode from userspace.
This is particularly useful for experimenting with Bluetooth controllers
that don't yet have proper support in BlueZ.

Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>


# 166d2f6a 20-Oct-2007 Ohad Ben-Cohen <ohad@bencohen.org>

[Bluetooth] Add UART driver for Texas Instruments' BRF63xx chips

Add support for Texas Instruments' HCI Low Level (HCILL) Bluetooth
protocol, which is a power management extension to H4. The HCILL is
widely used by TI's BRF63xx Bluetooth chips.

Signed-off-by: Ohad Ben-Cohen <ohad@bencohen.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>


# d2158744 09-May-2007 Marcel Holtmann <marcel@holtmann.org>

[Bluetooth] Add HCIUARTGETDEVICE support for HCI line discipline

Adding HCIUARTGETDEVICE makes it possible to get the HCI device number
that is attached to a given serial device. This is required during the
initialization process of some Bluetooth chips.

Signed-off-by: Ohad Ben-Cohen <ohad@bencohen.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>


# 0372a662 28-Oct-2005 Marcel Holtmann <marcel@holtmann.org>

[Bluetooth] Cleanup of the HCI UART driver

This patch contains the big cleanup of the HCI UART driver. The uneeded
header files are removed and their structure declarations are moved into
the protocol implementations.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>


# 1da177e4 16-Apr-2005 Linus Torvalds <torvalds@ppc970.osdl.org>

Linux-2.6.12-rc2

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!