Hi Hans, >> With the recent btusb change to detect and deal with more fake CSR >> controllers, I decided to see if one of the fakes which I have >> lying around would now work. >> >> After much experimentation I came to the conclusion that it works, if I >> have autosuspend enabled initially and then disable it after the device >> has suspended at least once. Yes this is very weird, but I've tried many >> things, like manually clearing the remote-wakeup feature. Doing a >> runtime-resume + runtime suspend is the only way to get the receiver >> to actually report received data (and/or pairing info) through its >> bulk rx endpoint. >> >> But the funkyness of the bulk-endpoint does not stop there, I mainly >> found out about this problem, because with autosuspend enabled >> (which usually ensures the suspend at least once condition is met), >> the receiver stops reporting received data through its bulk rx endpoint >> as soon as autosuspend kicks in. So I initially just disabled >> autosuspend, but then the receiver does not work at all. >> >> This was with a fake CSR receiver with a bcdDevice value of 0x8891, >> a lmp_subver of 0x0x1012, a hci_rev of 0x0810 and a hci_ver of >> BLUETOOTH_VER_4_0. > > I just realized that I should have opened this one and add the > chipmarkings to the commit msg here too. So I've just opened it > and took a look. > > This one has a Barrot 8041a02 chip and searching for 8041a92 shows that > the internet is full of reports of how crappy it is. > > I guess this patch probably will get some review remarks anyways, > but let me know if you want a v3 with just the chip added to the > commit msg. yes please. The more info we add the better. Regards Marcel
