Bluetooth: Refactor buffer handling for non-host managed buffers

So far the assumption has been that the host stack manages all
incoming and outgoing buffers. For the incoming buffers (from the
controller) this has required hci_core.c to manage its own pools and
do the host flow control. This setup makes perfect sense for an
architecture where the controller resides remotely on a different CPU
& address space (i.e. the "traditional" HCI transport case).

When the stack runs on a system where the controller resides in the
same address space this setup doesn't work that well. In such a
scenario the incoming buffers are ideally created as low down in the
stack as possible (i.e. below HCI), which means that the current
hci_core.c cannot be responsible for managing their pools.

To allow for both types of architectures this patch introduces a new
BLUETOOTH_HOST_BUFFERS Kconfig option that can be selected to say that
host-side management is desired, or deselected to say that the
controller (residing in the same address space) takes care of managing
the incoming buffers.

So far the incoming buffer types were identified by hci_core.c by
looking at their "free pool" pointers, however as soon as the pools
are allowed to be somewhere else this doesn't work. To solve this we
now require a minimum user data size for all Bluetooth buffers and use
that to store the buffer type.

Change-Id: I14bc32007e3e3f17c654f71f79b520650028d7ce
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>

1 files changed, 1 insertions, 1 deletions

diff --git a/tests/bluetooth/test_bluetooth/src/bluetooth.c b/tests/bluetooth/test_bluetooth/src/bluetooth.c
index 555716bc7..77824dc02 100644
--- a/tests/bluetooth/test_bluetooth/src/bluetooth.c
+++ b/tests/bluetooth/test_bluetooth/src/bluetooth.c
@@ -34,7 +34,7 @@ static int driver_open(void)
 	return EXPECTED_ERROR;
 }
 
-static int driver_send(enum bt_buf_type type, struct net_buf *buf)
+static int driver_send(struct net_buf *buf)
 {
 	return 0;
 }