Hi Marcel On Tue, Jul 7, 2020 at 9:09 AM Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote: > > Hi Luiz, > > > This enables btusb to inform the polling interval used for receiving > > packets, the interval is then used wih rx_work which has been changed > > to be a delayed work. > > > > The interval is then used as a time window where frames received from > > different endpoints are considered to be arrived at same time. > > > > In order to resolve potential conflicts between endpoints a dedicated > > queue for events was introduced and it is now processed before the ACL > > packets. > > > > It worth noting though that priorizing events over ACL data may result > > in inverting the order of the packets over the air, for instance there > > may be packets received before a disconnect event that will be > > discarded and unencrypted packets received before encryption change > > which would considered encrypted, because of these potential inversions > > the support for polling interval is not enabled by default so platforms > > have the following means to enable it: > > we can not touch the core that impacts all transport layers even if they are not broken. So adding the second queue is not something that I think is a good idea. And again, we are just papering over a hole. I guess you are referring to hdev->ev_q, that is only used if the driver calls hci_recv_evt so it doesn't affect the user of hci_recv_frame. > However if you want to queue within btusb driver before sending it to the core, then maybe. That might require introducing a workqueue into btusb though, but perhaps that is not such a big deal given that we are not that concerned on the memory usage, are there any other remarks about the conflict resolution though? I probably will add some text to the Kconfig option stating this is a workaround which may cause reordering of events vs ACL data, but imo it is much cleaner then trying to handle these races on the upper layers since they might not be limited to just Connection Complete and Encryption Change, so instead of papering each hole separately we just use a bigger paper to cover everything up, it is still just a workaround so platforms would have to decide if they want to run with it or not. > Regards > > Marcel > -- Luiz Augusto von Dentz
