Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 25 Oct 2022 14:00:24 -0400
From:   Jack <ostroffjh@users.sourceforge.net>
Subject: Re: [Regression] Cambridge Silicon Radio, Ltd Bluetooth Dongle
 unusable again with kernel 6.0
To:     linux-bluetooth@vger.kernel.org
Cc:     Paul Menzel <pmenzel@molgen.mpg.de>
MIME-Version: 1.0
In-Reply-To: <ab082d3c-9ba6-b1bd-a895-65ea58cec926@molgen.mpg.de>
Message-Id: <O224FXKX.42565NIW.L5YD2R5Q@C37RPHFZ.QBNZTYLX.ESJXSIHV>
Content-Type: text/plain; charset=UTF-8; DelSp=Yes; Format=Flowed
Content-Disposition: inline
Content-Transfer-Encoding: 8BIT
Precedence: bulk

On 2022.10.25 03:02, Paul Menzel wrote:
> Thank you for your work on this driver.
> 
> Am 24.10.22 um 23:11 schrieb Jack:
>> Cheap USB BT dongles that are bad clones of CSR  "ID 0a12:0001  
>> Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)" have had  
>> historic problems, due to various bad behaviors.  See [Bug 60824]  
>> [PATCH][regression] Cambridge Silicon Radio, Ltd Bluetooth Dongle  
>> unusable (https://bugzilla.kernel.org/show_bug.cgi) for more details  
>> and background.  The patch in that bug was initially mainlined in  
>> 5.9, and underwent several revisions since then.  It has continued  
>> to work through all of the 5.19 series, but it does not work with  
>> any of the 6.0 kernels.
>> 
>> I have made three unsuccessful attempts to git bisect using vanilla  
>> sources.  All settled on totally irrelevant commits.  These have all  
>> used v6.0-rc1 and v5.19 as the starting bad and good commits.
> 
Before receiving your reply, I made another start at bisect

# bad: [5030a9a03f0107f645772450bcba521b2ec19a51] dt-bindings: net:  
fsl,fec: Add nvmem-cells / nvmem-cell-names properties
# good: [8a958732818bc27f7da4d41ecf2c5c99d9aa8b0e] tls: rx: factor out  
device darg update
git bisect start '5030a9a03f0107f645772450bcba521b2ec19a51'  
'8a958732818bc27f7da4d41ecf2c5c99d9aa8b0e'
# good: [7ca433dc6dedb2ec98dfc943f6db0c9b8996ed11] Merge tag  
'net-5.19-rc8' of  
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
git bisect good 7ca433dc6dedb2ec98dfc943f6db0c9b8996ed11
# bad: [e168f690087735ad12604ee6ee2db1b93e323072] Bluetooth: btusb:  
Remove HCI_QUIRK_BROKEN_ERR_DATA_REPORTING for fake CSR
git bisect bad e168f690087735ad12604ee6ee2db1b93e323072
# good: [5fb859f79f4f49d9df16bac2b3a84a6fa3aaccf1] net: ipa: initialize  
ring indexes to 0
git bisect good 5fb859f79f4f49d9df16bac2b3a84a6fa3aaccf1
# good: [ec2ea5e06c67f85c6541a74b661722a176be086f] net: ipa: list  
supported IPA versions in the Makefile
git bisect good ec2ea5e06c67f85c6541a74b661722a176be086f
# good: [df332800a914e9fd97b83aa63832979227fd8a8d] Bluetooth:  
btmtksdio: Add in-band wakeup support
git bisect good df332800a914e9fd97b83aa63832979227fd8a8d
# good: [6f43f6169a8229bb6ddbf483d3be760d48c4cdd1] Bluetooth: clean up  
error pointer checking
git bisect good 6f43f6169a8229bb6ddbf483d3be760d48c4cdd1
# good: [46459cb6d4e63066e227a496ae8af35ba8c0b23b] Bluetooth: hci_bcm:  
Increase host baudrate for CYW55572 in autobaud mode
git bisect good 46459cb6d4e63066e227a496ae8af35ba8c0b23b
# good: [0feb8af0275d196a29e321bedc15319673923cb6] Bluetooth: hci_sync:  
Correct hci_set_event_mask_page_2_sync() event mask
git bisect good 0feb8af0275d196a29e321bedc15319673923cb6
# bad: [1172c59f451f524a14bac5e7b047781883dfe441] Bluetooth: btusb:  
Remove HCI_QUIRK_BROKEN_ERR_DATA_REPORTING for QCA
git bisect bad 1172c59f451f524a14bac5e7b047781883dfe441
# bad: [766ae2422b4312a73510ebee9266bc23b466fbbb] Bluetooth: hci_sync:  
Check LMP feature bit instead of quirk
git bisect bad 766ae2422b4312a73510ebee9266bc23b466fbbb
# first bad commit: [766ae2422b4312a73510ebee9266bc23b466fbbb]  
Bluetooth: hci_sync: Check LMP feature bit instead of quirk

And 766ae2422b4312a73510ebee9266bc23b466fbbb does make sense as a  
likely culprit.

> Thank you for trying to bisect the issue. Too bad, it’s inconclusive.  
> Did you or can you please test the commits below, relating to the  
> merges of the Bluetooth trees.
> 
> 1.  b8c3bf0ed2edf2deaedba5f0bf0bb54c76dee71d
> 2.  1d1ab5d39be7590bb2400418877bff43da9e75ec
> 3.  2e64fe4624d19bc71212aae434c54874e5c49c5a
> 4.  4a934eca7b39df35569f97a070701d6846ce46df
> 5.  14202eff214e1e941fefa0366d4c3bc4b1a0d500
> 6.  c69ecb0ea4c96b8b191cbaa0b420222a37867655
> 7.  6e0e846ee2ab01bc44254e6a0a6a6a0db1cba16d
> 8.  5588d628027092e66195097bdf6835ddf64418b3
Let me know if you think there is still any need to test these.
> 
>> Having read all the pages on filing a [REGRESSION} bug, I'm a bit  
>> intimidated to file something without sufficient information to be  
>> taken seriously, but will do so using this information, if that  
>> seems the best course of action.
> 
> Having the regression documented is the most important thing, and it  
> will be taken seriously even if the reporter has not fully analyzed  
> or solved it.
Questions on actually filing the bug:  my understanding is that as a BT  
bug, this list will be notified, or do I need to explicitly do  
anything.  Do I just add regressions@lists.linux.dev as a cc?

> 
> […]
> 
> 
> Kind regards,
> 
> Paul
Jack