Bluetooth: ATT: Fix not responding when there is a request in parallel

If there is a request ongoing it may block responses to be generated
since they were using the same buffer pool, so this introduces a
dedicated pool for responses making the code able to act as both
server and client at same time.

Change-Id: I5fe3e19f9c5c0c2e0dfadedf77b7684f0960572c
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This commit is contained in:
Luiz Augusto von Dentz 2016-10-28 18:44:18 +03:00 committed by Johan Hedberg
parent 900fbc20ba
commit bbe538fde2

View file

@ -97,6 +97,15 @@ static NET_BUF_POOL(req_pool,
BT_L2CAP_BUF_SIZE(CONFIG_BLUETOOTH_ATT_MTU),
&req_data, NULL, BT_BUF_USER_DATA_MIN);
/*
* Pool for outgoing ATT responses packets.
*/
static struct nano_fifo rsp_data;
static NET_BUF_POOL(rsp_pool,
CONFIG_BLUETOOTH_ATT_REQ_COUNT * CONFIG_BLUETOOTH_MAX_CONN,
BT_L2CAP_BUF_SIZE(CONFIG_BLUETOOTH_ATT_MTU),
&rsp_data, NULL, BT_BUF_USER_DATA_MIN);
/*
* Pool for ATT indications packets. This is required since indication can be
* sent in parallel to requests.
@ -1803,6 +1812,23 @@ struct net_buf *bt_att_create_pdu(struct bt_conn *conn, uint8_t op, size_t len)
*/
buf = bt_l2cap_create_pdu(&ind_data, 0);
break;
case BT_ATT_OP_ERROR_RSP:
case BT_ATT_OP_MTU_RSP:
case BT_ATT_OP_FIND_INFO_RSP:
case BT_ATT_OP_FIND_TYPE_RSP:
case BT_ATT_OP_READ_TYPE_RSP:
case BT_ATT_OP_READ_RSP:
case BT_ATT_OP_READ_BLOB_RSP:
case BT_ATT_OP_READ_MULT_RSP:
case BT_ATT_OP_READ_GROUP_RSP:
case BT_ATT_OP_WRITE_RSP:
case BT_ATT_OP_PREPARE_WRITE_RSP:
case BT_ATT_OP_EXEC_WRITE_RSP:
/* Use a different buffer pool for responses since they can be
* sent in parallel.
*/
buf = bt_l2cap_create_pdu(&rsp_data, 0);
break;
default:
buf = bt_l2cap_create_pdu(&req_data, 0);
}
@ -1984,6 +2010,7 @@ void bt_att_init(void)
};
net_buf_pool_init(ind_pool);
net_buf_pool_init(rsp_pool);
net_buf_pool_init(req_pool);
net_buf_pool_init(clone_pool);
#if CONFIG_BLUETOOTH_ATT_PREPARE_COUNT > 0