Marcel Holtmann wrote:
Hi David,
Signed-off-by: Marcel Holtmann <marcel@xxxxxxxxxxxx>
---
include/net/bluetooth/hci_core.h | 2 +
net/bluetooth/hci_core.c | 58 ++++++++++++++++++++++++++++++++-----
2 files changed, 52 insertions(+), 8 deletions(-)
so I stuffed this now into bluetooth-testing tree and would like to see
some extra testing exposure. So far this has only been tested by myself.
If there are no regression then this should make a lot of HCI and L2CAP
handling a lot simple.
This may result in packets being processed in a different order to that
which they were received in.
e.g., what happens to an ACL packet processed before the connection
complete event for that connection?
good point. So we would either a) need to disable the RX tasklet when we
receive an event and schedule it for processing or b) process the ACL
data also in a workqueue.
I think my preferred solution would be for the rx function called by the
HCI transport drivers to be called in a thread context. There should be
a helper function that is callable in atomic context that queues the
packets to be processed in a workqueue.
Our UWB drivers already process packets in a thread so would prefer to
avoid another thread context switch.
Shall I prepare a patch?
David
--
David Vrabel, Senior Software Engineer, Drivers
CSR, Churchill House, Cambridge Business Park, Tel: +44 (0)1223 692562
Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/
Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
