Re: [RFC] Bluetooth: btusb: Add support for notifying the polling interval

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux