This commit organizes the bluetooth Ksymbols in:
- Driver symbols at drivers/bluetooth/Kconfig
- Stack symbols at net/bluetooth/Kconfig
Change-Id: I8ebadeb8ac7f8a769d7620e4e44077a05915dc86
Signed-off-by: Juan Manuel Cruz <juan.m.cruz.alcaraz@linux.intel.com>
This commit adds the Makefile and Kconfig files
to support the bluetooth driver in the Kbuild system.
Signed-off-by: Juan Manuel Cruz <juan.m.cruz.alcaraz@linux.intel.com>
Change-Id: I1f72b13aca8fb098eece04c4f0e1b680639b520f
Now that UART drivers are configured internally when it comes to
hardware specific information such as IRQ and registers (or mmaped
registers), bluetooth UART driver no longer needs to do it by itself. It
only requires to select the port it wants to use.
Change-Id: I5a30500f4b6f4155292609d0ed4a758f91930817
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
The coding guidelines make an exception to the Linux kernel style
where all branches, even one-liners, should use braces.
Change-Id: I368930af3033eac15f0152a6671909e401d332e6
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Configuration option BLUETOOTH_DEBUG_UART enables debug support for
Bluetooth UART driver.
Change-Id: I192f380be492df1a52ad212239447b6ee4b50aac
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
When the 'len' and 'min' parameters passed to bt_uart_read() are equal
the function is guaranteed to always return 'len' (it will keep
looping until that). This patch removes bt_uart_read() error checks
which would never occur in practice.
Change-Id: Icd879f1e15c6d33acc549155aabd24490098ffc5
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
There are some places where it's forgivable if bt_uart_read() wasn't
able to read as many bytes as requested. In other places it's not
acceptable (e.g. when reading ACL or event header). To avoid failing
in situations where we can handle receiving less data than requested
this patch adds a new parameter to bt_uart_read() to specify the
minimum required data amount.
Change-Id: I372e3af7aaa6bfabe14896eb10cc71c3deff94f2
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
If we're out of buffers the UART driver would previously loose sync of
where the packet boundaries go, because it was using the buffer itself
to store and parse the HCI packet headers. This patch modifies the
UART driver to use stack variable for initial header parsing, thereby
being able to always determine how many remaining bytes there are and
cleanly discard the bytes until the beginning of the next packet.
Change-Id: I278f3fc0c983e6a2a6904356ef1af1d25c9f06e4
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
If we get an invalid packet type here the buf pointer will be NULL.
Going to the cleanup section at the end of the function would trigger
a bt_but_put() call which would cause a NULL pointer access. Directly
returning from the function is the right thing to do instead.
Change-Id: I0c18646e0820cf829ef8aa3f77835ba0a14375b5
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
We may soon want to have a _wait() variant of bt_buf_get, so to avoid
the number of 'get' function growing too large consolidate the
existing get() and get_reserve() functions into a single one. The new
consolidated function also takes the type as input parameter so that
we know this from the very start and thereby plan for the split into
multiple buffer pools.
Change-Id: Ia09448565349def2be9bc08d9510fedd029480b4
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
We'll soon want to have dedicated pools for outgoing and incoming ACL
data. To know from which pool to get and put the buffers each buffer
should contain enough information to distinguish the two types. This
patch splits the old BT_ACL type into two new BT_ACL_IN & BT_ACL_OUT
types.
Change-Id: I7d3c05c26d2a70f80fb1229e245aa21673ec378b
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
This patch adds a simple HCI UART (H4) driver that currently maps to
the second UART in the system. The main intention is to use this
together with qemu for accessing the Bluetooth controller available on
the host OS side.
The H4 HCI transport protocol is perhaps the simplest of the standard
HCI transports. It consists of a single byte in the beginning of each
packet which indicates the type of the packet: HCI event, HCI command,
ACL data, or SCO data (which we don't use at the moment).
Change-Id: I225a2a2361fbd7cd4ba82ea1f81ddc1271e9e7c2
Co-authored-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Anas Nashif