This version number is more cosmetic and for debugging purposes, but
since there has been a few changes lately, increase it now.
Two left-over and not used version constants that were never exposed
anywhere are removed since they have no actual value.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The init function for each HCI UART protocol prints the same on success
and failure. This information is so generic, remove it and let the main
HCI UART handling print it instead.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
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>
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>
Instead of using hci_recv_stream_fragment, use the local available
h4_recv_buf helper function.
To ensure that the function is available select BT_HCIUART_H4.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Instead of using hci_recv_stream_fragment, use the local available
h4_recv_buf helper function.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
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>
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>
The fields h4->rx_state and h4->rx_count are not used at all and with
that they can be just removed.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The h4->rx_skb is not used anymore and with that just remove it. Seems
this was a leftover and even the kfree_skb call freeing it is rather
pointless since it got never allocated.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Casting the tty->disc_data to (void *) is not needed at all. So just
remove this cast and assign the object without a cast.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
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>
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>
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>
For all modern Bluetooth USB devices from Broadcom it makes a lot more
sense to use USB_VENDOR_AND_INTERFACE_INFO instead of manually adding
USB_DEVICE for each one of them. There are already interface entries
for these vendors and so just remove the duplicate device entries.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
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>
For the Apple Bluetooth devices that are Broadcom based, it makes sense
to read the chip information. It is a single HCI command and might help
gathering more information about these devices.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The Broadcom devices expose their chip id via Read Verbose Config
Version Info command. While this information is not used at the
moment, it might be useful for debugging purposes and so read it
before patching the firmware. This makes it show up in dmesg and
HCI traces taken for the system.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Atheros controllers can do both LE scan and BR/EDR inquiry at once.
Signed-off-by: Jakub Pawlowski <jpawlowski@google.com>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Johan Hedberg says:
====================
Here's another set of Bluetooth & ieee802154 patches intended for 4.1:
- Added support for QCA ROME chipset family in the btusb driver
- at86rf230 driver fixes & cleanups
- ieee802154 cleanups
- Refactoring of Bluetooth mgmt API to allow new users
- New setting for static Bluetooth address exposed to user space
- Refactoring of hci_dev flags to remove limit of 32
- Remove unnecessary fast-connectable setting usage restrictions
- Fix behavior to be consistent when trying to pair already paired device
- Service discovery corner-case fixes
Please let me know if there are any issues pulling. Thanks.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>