Re: [PATCH 3/3] Bluetooth: btusb: Add a parameter to let users disable the fake CSR force-suspend hack

[Swyter]

On 09/11/2022 23:39, Luiz Augusto von Dentz wrote:
>>> Is this specific to Barrot 8041a02? Why don't we add a quirk then?
>>>
>>
>> We don't know how specific it is, we suspect the getting stuck thing happens with Barrot controllers,
>> but in this world of lasered-out counterfeit chip IDs you can never be sure. Unless someone decaps them.
>>
>> Hans added that name because it's the closest thing we have, but this applies to a lot of chips.
>> So much that now we do the hack by default, for very good reasons.
>>
>> So please reconsider, this closes the gap.
>>
>> With this last patch we go from ~+90% to almost ~100%, as the rest of generic quirks we added
>> don't really hurt; even if a particular dongle only needs a few of the zoo of quirks we set,
>> it's alright if we vaccinate them against all of these, except some are "allergic"
>> against this particular "vaccine". Let people skip this one. :-)
>>
>> You know how normal BT controllers are utterly and inconsistently broken, now imagine you have a whole host
>> of vendors reusing a VID/PID/version/subversion, masking as a CSR for bizarre reasons to avoid paying
>> any USB-IF fees, or whatever. That's what we are fighting against here.
> 
> I see, but for suspend in particular, can't we actually handle it
> somehow? I mean if we can detect the controller is getting stuck and
> print some information and flip the quirk? Otherwise Im afraid this
> parameter will end up always being set by distros to avoid suspend
> problems.

Maybe, auto-detection is certainly a better way and a potential improvement,
assuming we cover all the edge cases. Which I'm not too sure about.

The controllers don't get totally stuck, they just act weird and give funky
HCI responses at certain points if we don't do this, if I remember correctly.

Unfortunately I can't really justify spending that much time *right now* on
this hobby project. Distros should *definitely* keep doing the hack by default
if they want the widest compatibility. This is comparatively a niche issue.


But yeah, to sum things up; I'm not sure going back to a whitelist of a
whitelist is a good idea without a foolproof method. We want the widest
possible reach by doing it in the most generic way with the smallest
possible side effects. If we can find a way to blacklist this quirk
when we are super sure it's going to cause issues I'm all for it.

Right now I think this is an acceptable solution, as long as
people in charge of distros don't flip these toggles.

Nobody has cared until now, barely any of these devices worked.
Now that most of them work it would be very funny to see
them break the majority to fix a few.

With the amount of effort it takes an outsider like me to
get stuff into the kernel and fight to avoid random reverts
I don't know if I'd be able to get something as involved as
that to work in a satisfying, automatic and simple way.

Perfect is the enemy of good, diminishing returns, and all that. ¯\_(ツ)_/¯