[BUG] Bluetooth: btusb: poll_sync can fail to preserve HCI event/data ordering

[Amir Abudubai]

Hello,

I encountered a bug that shows up as a GATT table discovery problem.
Client sees a GATT table resolved but empty. Eventually I tracked the
problem down to discovery failing when the peripheral drops the MTU
request for invalid handle because it arrives before the connection
complete event.

Digging deeper, the problem appears to be a bad assumption in btusb.c.
Its poll_sync assumes polling jitter is the only thing skewing the
arrival time between bulk and interrupt interfaces, which may be true
for some devices, but isn't typically true. I tested 3 different
devices and all 3 have different behaviors. An Intel adapter that is
async and guarantees interrupts arrive within 2 intervals, a
MediaTek([VID] [0e8d:0616]) that cannot recreate this bug because it
internally delays bulk until after interrupts have been delivered, and
a Realtek[7392] that synchronizes them, but always delivers interrupts
3.109 ms late. This is only a problem with the kernel configured to
1000Hz because of the minimum 1 jiffy delay in poll sync.

I made a test bench that recreates the bug while capturing logs. It
parses them and reports the time delta between MTU and Connection
Complete on both the USB and HCI.
https://github.com/Yes-it-was/btusb_interupt_bulk_sync_bench#