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? yes please. I need something to make the event handling simpler. Otherwise every single subcomponent creates "hundreds" of workqueues to solve exactly the same problem. Regards Marcel -- 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
