9028e8e75b
HCI drivers are obliged to send HCI Command Status/Complete events from a separate context than all other data, however the ECC wrapper was violating this rule (sending everything from the same ECC thread). This could lead to a deadlock if e.g. the ECC API user decides to generate a DHKey from the same callback that it got notified of local key-pair generation. The obvious solution is to emit the Command Status directly from the send function, before passing the command to be processed by the ECC therad (through a k_fifo). However, this is not quite so simple since bt_buf_get_cmd_complete() reuses the original command buffer, meaning we'd loose the original parameters after sending a Command Status. To work around this limitation with bt_buf_get_cmd_complete() we stop passing the command buffer to the thread and instead store the parameters in static variables and do the thread communication using flags and a semaphore. One side effect is that only one command can be pending at a time, however that works out fine for all of the users of ECC. A nice side effect of moving some things to static variables is that we end up reducing call stack usage in the ECC thread, allowing it to be shrunk by 180 bytes (verified to be sufficient for both ARM and x86 boards). Change-Id: Ic41f0316d3fe4d14b64fd3d0a549b221d168411a Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> |
||
|---|---|---|
| .. | ||
| bluetooth | ||
| console | ||
| debug | ||
| disk | ||
| fs | ||
| logging | ||
| net | ||
| shell | ||
| usb | ||
| Kconfig | ||
| Makefile | ||