From: Swyter <swyterzone@gmail.com>
To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
Jack <ostroffjh@users.sourceforge.net>
Cc: linux-bluetooth@vger.kernel.org,
Paul Menzel <pmenzel@molgen.mpg.de>,
Marcel Holtmann <marcel@holtmann.org>,
Hans de Goede <hdegoede@redhat.com>
Subject: Re: [Regression] Cambridge Silicon Radio, Ltd Bluetooth Dongle
Date: Wed, 9 Nov 2022 22:14:36 +0100 [thread overview]
Message-ID: <7ea187e5-7c70-db36-1fa8-148507b2e7c5@gmail.com> (raw)
In-Reply-To: <CABBYNZKDEjYOW+b1snUsvBgidW37+tPbsidq0pXaOqWKvRC8uQ@mail.gmail.com>
>> In case it helps any, I have applied Swyter's patch referenced at
>> comment #243 of the bug referenced above, and it does restore function
>> to my particular dongle (Gentoo linux, with gentoo-sources kernel
>> 6.0.6.) (I believe I provided the git bisect quoted at the top of this
>> message.)
>
> Ive applied the first 2 patches, the third one I'm not so sure I'd
> like to introduce another module parameter.
Thanks for that, Luiz. The module parameter does help a lot and it
has been requested a few times in the Bugzilla thread.
I have been thinking about this problem for a long time.
Essentially nulls-out any potential drawback the suspend workaround
may ever cause. In the past for this we used a very spotty whitelist,
but we can't really work with that here. When I'm talking about hundreds
to thousands of dongles in various states of brokenness I mean it.
The generic catch-all-as-best-as-we-can is the best way forward here.
Detecting fakes is hard enough, detecting dongles that don't like
the suspend workaround is essentially impossible. As they all
share the same identifiers than the ones that do.
Some fakes NEED the suspend workaround to work at all while a *much*
smaller subset of otherwise identical dongles have trouble with it.
Thanks to this last-effort parameter we can cover that last mile
without people having to recompile custom versions of btusb.
My dongle doesn't work? Easy, add this here. Most people won't
have to bother with this, but that final ~3% would be screwed.
next prev parent reply other threads:[~2022-11-09 21:14 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-24 21:11 [Regression] Cambridge Silicon Radio, Ltd Bluetooth Dongle unusable again with kernel 6.0 Jack
2022-10-25 7:02 ` Paul Menzel
2022-10-25 18:00 ` Jack
2022-10-25 19:38 ` Luiz Augusto von Dentz
2022-10-26 3:41 ` quic_zijuhu
2022-10-27 9:48 ` quic_zijuhu
2022-11-09 19:12 ` [Regression] Cambridge Silicon Radio, Ltd Bluetooth Dongle Swyter
2022-11-09 19:40 ` Jack
2022-11-09 20:43 ` Luiz Augusto von Dentz
2022-11-09 21:14 ` Swyter [this message]
2022-11-15 6:20 ` Mika Laitio
2022-11-15 6:41 ` Swyter
2022-10-26 9:17 ` [Regression] Cambridge Silicon Radio, Ltd Bluetooth Dongle unusable again with kernel 6.0 #forregzbot Thorsten Leemhuis
2022-12-01 14:41 ` Thorsten Leemhuis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7ea187e5-7c70-db36-1fa8-148507b2e7c5@gmail.com \
--to=swyterzone@gmail.com \
--cc=hdegoede@redhat.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=luiz.dentz@gmail.com \
--cc=marcel@holtmann.org \
--cc=ostroffjh@users.sourceforge.net \
--cc=pmenzel@molgen.mpg.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox