30601c09bb
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> |
||
|---|---|---|
| .. | ||
| src | ||
| Makefile | ||
| prj.conf | ||
| prj.mdef | ||
| testcase.ini | ||