| Message ID | 20230829205936.766544-1-luiz.dentz@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | Bluetooth: hci_sync: Fix handling of HCI_QUIRK_STRICT_DUPLICATE_FILTER | expand |
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=780332
---Test result---
Test Summary:
CheckPatch FAIL 0.96 seconds
GitLint FAIL 0.58 seconds
SubjectPrefix PASS 0.10 seconds
BuildKernel PASS 35.95 seconds
CheckAllWarning PASS 35.32 seconds
CheckSparse PASS 39.77 seconds
CheckSmatch PASS 111.71 seconds
BuildKernel32 PASS 30.60 seconds
TestRunnerSetup PASS 472.66 seconds
TestRunner_l2cap-tester PASS 26.59 seconds
TestRunner_iso-tester PASS 47.41 seconds
TestRunner_bnep-tester PASS 12.15 seconds
TestRunner_mgmt-tester PASS 218.19 seconds
TestRunner_rfcomm-tester PASS 15.49 seconds
TestRunner_sco-tester PASS 18.88 seconds
TestRunner_ioctl-tester PASS 17.38 seconds
TestRunner_mesh-tester PASS 15.88 seconds
TestRunner_smp-tester PASS 13.73 seconds
TestRunner_userchan-tester PASS 10.71 seconds
IncrementalBuild PASS 28.98 seconds
Details
##############################
Test: CheckPatch - FAIL
Desc: Run checkpatch.pl script
Output:
Bluetooth: hci_sync: Fix handling of HCI_QUIRK_STRICT_DUPLICATE_FILTER
WARNING: Unknown link reference 'link:', use 'Link:' or 'Closes:' instead
#90:
link: https://lore.kernel.org/linux-bluetooth/578e6d7afd676129decafba846a933f5@agner.ch/#t
total: 0 errors, 1 warnings, 0 checks, 30 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
/github/workspace/src/src/13369574.patch has style problems, please review.
NOTE: Ignored message types: UNKNOWN_COMMIT_ID
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
Bluetooth: hci_sync: Fix handling of HCI_QUIRK_STRICT_DUPLICATE_FILTER
WARNING: I3 - ignore-body-lines: gitlint will be switching from using Python regex 'match' (match beginning) to 'search' (match anywhere) semantics. Please review your ignore-body-lines.regex option accordingly. To remove this warning, set general.regex-style-search=True. More details: https://jorisroovers.github.io/gitlint/configuration/#regex-style-search
12: B1 Line exceeds max length (90>80): "link: https://lore.kernel.org/linux-bluetooth/578e6d7afd676129decafba846a933f5@agner.ch/#t"
---
Regards,
Linux Bluetooth
Hello: This patch was applied to bluetooth/bluetooth-next.git (master) by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>: On Tue, 29 Aug 2023 13:59:36 -0700 you wrote: > From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> > > When HCI_QUIRK_STRICT_DUPLICATE_FILTER is set LE scanning requires > periodic restarts of the scanning procedure as the controller would > consider device previously found as duplicated despite of RSSI changes, > but in order to set the scan timeout properly set le_scan_restart needs > to be synchronous so it shall not use hci_cmd_sync_queue which defers > the command processing to cmd_sync_work. > > [...] Here is the summary with links: - Bluetooth: hci_sync: Fix handling of HCI_QUIRK_STRICT_DUPLICATE_FILTER https://git.kernel.org/bluetooth/bluetooth-next/c/52bf4fd43f75 You are awesome, thank you!
On 31.08.23 00:20, patchwork-bot+bluetooth@kernel.org wrote: > > This patch was applied to bluetooth/bluetooth-next.git (master) > by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>: > > On Tue, 29 Aug 2023 13:59:36 -0700 you wrote: >> From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> >> >> When HCI_QUIRK_STRICT_DUPLICATE_FILTER is set LE scanning requires >> periodic restarts of the scanning procedure as the controller would >> consider device previously found as duplicated despite of RSSI changes, >> but in order to set the scan timeout properly set le_scan_restart needs >> to be synchronous so it shall not use hci_cmd_sync_queue which defers >> the command processing to cmd_sync_work. >> >> [...] > > Here is the summary with links: > - Bluetooth: hci_sync: Fix handling of HCI_QUIRK_STRICT_DUPLICATE_FILTER > https://git.kernel.org/bluetooth/bluetooth-next/c/52bf4fd43f75 That is (maybe among others?) a fix for a regression from 6.1, so why was this merged into a "for-next" branch instead of a branch that targets the current cycle? Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr If I did something stupid, please tell me, as explained on that page. [1] see https://lore.kernel.org/linux-bluetooth/b0b672069ee6a9e43fed1a07406c6dd3@agner.ch/
Hi, On Mon, Sep 11, 2023 at 6:40 AM Linux regression tracking (Thorsten Leemhuis) <regressions@leemhuis.info> wrote: > > On 31.08.23 00:20, patchwork-bot+bluetooth@kernel.org wrote: > > > > This patch was applied to bluetooth/bluetooth-next.git (master) > > by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>: > > > > On Tue, 29 Aug 2023 13:59:36 -0700 you wrote: > >> From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> > >> > >> When HCI_QUIRK_STRICT_DUPLICATE_FILTER is set LE scanning requires > >> periodic restarts of the scanning procedure as the controller would > >> consider device previously found as duplicated despite of RSSI changes, > >> but in order to set the scan timeout properly set le_scan_restart needs > >> to be synchronous so it shall not use hci_cmd_sync_queue which defers > >> the command processing to cmd_sync_work. > >> > >> [...] > > > > Here is the summary with links: > > - Bluetooth: hci_sync: Fix handling of HCI_QUIRK_STRICT_DUPLICATE_FILTER > > https://git.kernel.org/bluetooth/bluetooth-next/c/52bf4fd43f75 > > That is (maybe among others?) a fix for a regression from 6.1, so why > was this merged into a "for-next" branch instead of a branch that > targets the current cycle? We were late for including it to 6.5, that said the regression was introduced in 6.4, but I could probably have it marked for stable just to make sure it would get backported to affected versions. > Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) > -- > Everything you wanna know about Linux kernel regression tracking: > https://linux-regtracking.leemhuis.info/about/#tldr > If I did something stupid, please tell me, as explained on that page. > > [1] see > https://lore.kernel.org/linux-bluetooth/b0b672069ee6a9e43fed1a07406c6dd3@agner.ch/
On 12.09.23 21:09, Luiz Augusto von Dentz wrote: > On Mon, Sep 11, 2023 at 6:40 AM Linux regression tracking (Thorsten > Leemhuis) <regressions@leemhuis.info> wrote: >> On 31.08.23 00:20, patchwork-bot+bluetooth@kernel.org wrote: >>> This patch was applied to bluetooth/bluetooth-next.git (master) >>> by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>: >>> On Tue, 29 Aug 2023 13:59:36 -0700 you wrote: >>>> From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> >>>> >>>> When HCI_QUIRK_STRICT_DUPLICATE_FILTER is set LE scanning requires >>>> periodic restarts of the scanning procedure as the controller would >>>> consider device previously found as duplicated despite of RSSI changes, >>>> but in order to set the scan timeout properly set le_scan_restart needs >>>> to be synchronous so it shall not use hci_cmd_sync_queue which defers >>>> the command processing to cmd_sync_work. >>>> >>>> [...] >>> >>> Here is the summary with links: >>> - Bluetooth: hci_sync: Fix handling of HCI_QUIRK_STRICT_DUPLICATE_FILTER >>> https://git.kernel.org/bluetooth/bluetooth-next/c/52bf4fd43f75 >> >> That is (maybe among others?) a fix for a regression from 6.1, so why >> was this merged into a "for-next" branch instead of a branch that >> targets the current cycle? > > We were late for including it to 6.5, that said the regression was > introduced in 6.4, 6.4? From the fixes tag it sounded like it was 6.1. Whatever, doesn't make a difference, because: That answer doesn't answer the question afaics, as both 6.1 and 6.4 were released in the past year -- the fix thus should not wait till the next merge window, unless it's high risk or something. See this statement from Linus: https://lore.kernel.org/all/CAHk-=wis_qQy4oDNynNKi5b7Qhosmxtoj1jxo5wmB6SRUwQUBQ@mail.gmail.com/ > but I could probably have it marked for stable just > to make sure it would get backported to affected versions. That would be great, too! Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr If I did something stupid, please tell me, as explained on that page.
Hi Thorsten, On Wed, Sep 13, 2023 at 10:13 PM Thorsten Leemhuis <regressions@leemhuis.info> wrote: > > On 12.09.23 21:09, Luiz Augusto von Dentz wrote: > > On Mon, Sep 11, 2023 at 6:40 AM Linux regression tracking (Thorsten > > Leemhuis) <regressions@leemhuis.info> wrote: > >> On 31.08.23 00:20, patchwork-bot+bluetooth@kernel.org wrote: > >>> This patch was applied to bluetooth/bluetooth-next.git (master) > >>> by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>: > >>> On Tue, 29 Aug 2023 13:59:36 -0700 you wrote: > >>>> From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> > >>>> > >>>> When HCI_QUIRK_STRICT_DUPLICATE_FILTER is set LE scanning requires > >>>> periodic restarts of the scanning procedure as the controller would > >>>> consider device previously found as duplicated despite of RSSI changes, > >>>> but in order to set the scan timeout properly set le_scan_restart needs > >>>> to be synchronous so it shall not use hci_cmd_sync_queue which defers > >>>> the command processing to cmd_sync_work. > >>>> > >>>> [...] > >>> > >>> Here is the summary with links: > >>> - Bluetooth: hci_sync: Fix handling of HCI_QUIRK_STRICT_DUPLICATE_FILTER > >>> https://git.kernel.org/bluetooth/bluetooth-next/c/52bf4fd43f75 > >> > >> That is (maybe among others?) a fix for a regression from 6.1, so why > >> was this merged into a "for-next" branch instead of a branch that > >> targets the current cycle? > > > > We were late for including it to 6.5, that said the regression was > > introduced in 6.4, > > 6.4? From the fixes tag it sounded like it was 6.1. Whatever, doesn't > make a difference, because: It seems I had it confused with HCI_QUIRK_BROKEN_LE_CODED, so you are right about this affecting from 6.1 onwards. > That answer doesn't answer the question afaics, as both 6.1 and 6.4 were > released in the past year -- the fix thus should not wait till the next > merge window, unless it's high risk or something. See this statement > from Linus: > https://lore.kernel.org/all/CAHk-=wis_qQy4oDNynNKi5b7Qhosmxtoj1jxo5wmB6SRUwQUBQ@mail.gmail.com/ Thanks for the feedback, I will try to push fixes to net more often. > > but I could probably have it marked for stable just > > to make sure it would get backported to affected versions. > > That would be great, too! Well now that it has already been merged via -next tree shall we still attempt to mark it as stable? Perhaps we need to check if it was not backported already based on the Fixes tag. > Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) > -- > Everything you wanna know about Linux kernel regression tracking: > https://linux-regtracking.leemhuis.info/about/#tldr > If I did something stupid, please tell me, as explained on that page.
On 14.09.23 19:51, Luiz Augusto von Dentz wrote: > On Wed, Sep 13, 2023 at 10:13 PM Thorsten Leemhuis > <regressions@leemhuis.info> wrote: >> On 12.09.23 21:09, Luiz Augusto von Dentz wrote: >>> On Mon, Sep 11, 2023 at 6:40 AM Linux regression tracking (Thorsten >>> Leemhuis) <regressions@leemhuis.info> wrote: >>>> On 31.08.23 00:20, patchwork-bot+bluetooth@kernel.org wrote: >>>>> This patch was applied to bluetooth/bluetooth-next.git (master) >>>>> by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>: >>>>> On Tue, 29 Aug 2023 13:59:36 -0700 you wrote: >>>>>> From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> >>>>>> >>>>>> When HCI_QUIRK_STRICT_DUPLICATE_FILTER is set LE scanning requires >>>>>> periodic restarts of the scanning procedure as the controller would >>>>>> consider device previously found as duplicated despite of RSSI changes, >>>>>> but in order to set the scan timeout properly set le_scan_restart needs >>>>>> to be synchronous so it shall not use hci_cmd_sync_queue which defers >>>>>> the command processing to cmd_sync_work. >>>>>> [...] >>>>> >>>>> Here is the summary with links: >>>>> - Bluetooth: hci_sync: Fix handling of HCI_QUIRK_STRICT_DUPLICATE_FILTER >>>>> https://git.kernel.org/bluetooth/bluetooth-next/c/52bf4fd43f75 >>>> >>>> That is (maybe among others?) a fix for a regression from 6.1, so why >>>> was this merged into a "for-next" branch instead of a branch that >>>> targets the current cycle? > [...] >> That answer doesn't answer the question afaics, as both 6.1 and 6.4 were >> released in the past year -- the fix thus should not wait till the next >> merge window, unless it's high risk or something. See this statement >> from Linus: >> https://lore.kernel.org/all/CAHk-=wis_qQy4oDNynNKi5b7Qhosmxtoj1jxo5wmB6SRUwQUBQ@mail.gmail.com/ > Thanks for the feedback, I will try to push fixes to net more often. Great, many thx! >>> but I could probably have it marked for stable just >>> to make sure it would get backported to affected versions. >> That would be great, too! > Well now that it has already been merged via -next tree shall we still > attempt to mark it as stable? Perhaps we need to check if it was not > backported already based on the Fixes tag. Changes only get backported once they hit mainline, which hasn't happened yet. And to get them into the net branch (and from there to mainline) a new commit is needed anyway, so you might as well add the stable tag to it. Side note: And don't worry that identical commit is already in -next, git handles that well afaik (but if you rebase bluetooth-next for other reasons anyway you might as well remove it). Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr If I did something stupid, please tell me, as explained on that page.
Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting for once, to make this easily accessible to everyone. @Luiz Augusto von Dentz: did you make any progress to get this into net to make sure this rather sooner then later heads to mainline? Doesn't looks like it from here, but maybe I'm missing something. Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr If I did something stupid, please tell me, as explained on that page. #regzbot poke On 14.09.23 20:08, Thorsten Leemhuis wrote: > On 14.09.23 19:51, Luiz Augusto von Dentz wrote: >> On Wed, Sep 13, 2023 at 10:13 PM Thorsten Leemhuis >> <regressions@leemhuis.info> wrote: >>> On 12.09.23 21:09, Luiz Augusto von Dentz wrote: >>>> On Mon, Sep 11, 2023 at 6:40 AM Linux regression tracking (Thorsten >>>> Leemhuis) <regressions@leemhuis.info> wrote: >>>>> On 31.08.23 00:20, patchwork-bot+bluetooth@kernel.org wrote: >>>>>> This patch was applied to bluetooth/bluetooth-next.git (master) >>>>>> by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>: >>>>>> On Tue, 29 Aug 2023 13:59:36 -0700 you wrote: >>>>>>> From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> >>>>>>> >>>>>>> When HCI_QUIRK_STRICT_DUPLICATE_FILTER is set LE scanning requires >>>>>>> periodic restarts of the scanning procedure as the controller would >>>>>>> consider device previously found as duplicated despite of RSSI changes, >>>>>>> but in order to set the scan timeout properly set le_scan_restart needs >>>>>>> to be synchronous so it shall not use hci_cmd_sync_queue which defers >>>>>>> the command processing to cmd_sync_work. >>>>>>> [...] >>>>>> >>>>>> Here is the summary with links: >>>>>> - Bluetooth: hci_sync: Fix handling of HCI_QUIRK_STRICT_DUPLICATE_FILTER >>>>>> https://git.kernel.org/bluetooth/bluetooth-next/c/52bf4fd43f75 >>>>> >>>>> That is (maybe among others?) a fix for a regression from 6.1, so why >>>>> was this merged into a "for-next" branch instead of a branch that >>>>> targets the current cycle? >> [...] >>> That answer doesn't answer the question afaics, as both 6.1 and 6.4 were >>> released in the past year -- the fix thus should not wait till the next >>> merge window, unless it's high risk or something. See this statement >>> from Linus: >>> https://lore.kernel.org/all/CAHk-=wis_qQy4oDNynNKi5b7Qhosmxtoj1jxo5wmB6SRUwQUBQ@mail.gmail.com/ >> Thanks for the feedback, I will try to push fixes to net more often. > > Great, many thx! > >>>> but I could probably have it marked for stable just >>>> to make sure it would get backported to affected versions. >>> That would be great, too! >> Well now that it has already been merged via -next tree shall we still >> attempt to mark it as stable? Perhaps we need to check if it was not >> backported already based on the Fixes tag. > > Changes only get backported once they hit mainline, which hasn't > happened yet. And to get them into the net branch (and from there to > mainline) a new commit is needed anyway, so you might as well add the > stable tag to it. Side note: And don't worry that identical commit is > already in -next, git handles that well afaik (but if you rebase > bluetooth-next for other reasons anyway you might as well remove it). > > Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) > -- > Everything you wanna know about Linux kernel regression tracking: > https://linux-regtracking.leemhuis.info/about/#tldr > If I did something stupid, please tell me, as explained on that page.
Hi Thorsten, On Wed, Sep 20, 2023 at 7:02 AM Thorsten Leemhuis <regressions@leemhuis.info> wrote: > > Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting > for once, to make this easily accessible to everyone. > > @Luiz Augusto von Dentz: did you make any progress to get this into net > to make sure this rather sooner then later heads to mainline? Doesn't > looks like it from here, but maybe I'm missing something. Just sent the pull-request: https://patchwork.kernel.org/project/bluetooth/patch/20230920181344.571274-1-luiz.dentz@gmail.com/ > Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) > -- > Everything you wanna know about Linux kernel regression tracking: > https://linux-regtracking.leemhuis.info/about/#tldr > If I did something stupid, please tell me, as explained on that page. > > #regzbot poke > > > On 14.09.23 20:08, Thorsten Leemhuis wrote: > > On 14.09.23 19:51, Luiz Augusto von Dentz wrote: > >> On Wed, Sep 13, 2023 at 10:13 PM Thorsten Leemhuis > >> <regressions@leemhuis.info> wrote: > >>> On 12.09.23 21:09, Luiz Augusto von Dentz wrote: > >>>> On Mon, Sep 11, 2023 at 6:40 AM Linux regression tracking (Thorsten > >>>> Leemhuis) <regressions@leemhuis.info> wrote: > >>>>> On 31.08.23 00:20, patchwork-bot+bluetooth@kernel.org wrote: > >>>>>> This patch was applied to bluetooth/bluetooth-next.git (master) > >>>>>> by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>: > >>>>>> On Tue, 29 Aug 2023 13:59:36 -0700 you wrote: > >>>>>>> From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> > >>>>>>> > >>>>>>> When HCI_QUIRK_STRICT_DUPLICATE_FILTER is set LE scanning requires > >>>>>>> periodic restarts of the scanning procedure as the controller would > >>>>>>> consider device previously found as duplicated despite of RSSI changes, > >>>>>>> but in order to set the scan timeout properly set le_scan_restart needs > >>>>>>> to be synchronous so it shall not use hci_cmd_sync_queue which defers > >>>>>>> the command processing to cmd_sync_work. > >>>>>>> [...] > >>>>>> > >>>>>> Here is the summary with links: > >>>>>> - Bluetooth: hci_sync: Fix handling of HCI_QUIRK_STRICT_DUPLICATE_FILTER > >>>>>> https://git.kernel.org/bluetooth/bluetooth-next/c/52bf4fd43f75 > >>>>> > >>>>> That is (maybe among others?) a fix for a regression from 6.1, so why > >>>>> was this merged into a "for-next" branch instead of a branch that > >>>>> targets the current cycle? > >> [...] > >>> That answer doesn't answer the question afaics, as both 6.1 and 6.4 were > >>> released in the past year -- the fix thus should not wait till the next > >>> merge window, unless it's high risk or something. See this statement > >>> from Linus: > >>> https://lore.kernel.org/all/CAHk-=wis_qQy4oDNynNKi5b7Qhosmxtoj1jxo5wmB6SRUwQUBQ@mail.gmail.com/ > >> Thanks for the feedback, I will try to push fixes to net more often. > > > > Great, many thx! > > > >>>> but I could probably have it marked for stable just > >>>> to make sure it would get backported to affected versions. > >>> That would be great, too! > >> Well now that it has already been merged via -next tree shall we still > >> attempt to mark it as stable? Perhaps we need to check if it was not > >> backported already based on the Fixes tag. > > > > Changes only get backported once they hit mainline, which hasn't > > happened yet. And to get them into the net branch (and from there to > > mainline) a new commit is needed anyway, so you might as well add the > > stable tag to it. Side note: And don't worry that identical commit is > > already in -next, git handles that well afaik (but if you rebase > > bluetooth-next for other reasons anyway you might as well remove it). > > > > Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) > > -- > > Everything you wanna know about Linux kernel regression tracking: > > https://linux-regtracking.leemhuis.info/about/#tldr > > If I did something stupid, please tell me, as explained on that page.
diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c index 9b93653c6197..fd7c5d902856 100644 --- a/net/bluetooth/hci_sync.c +++ b/net/bluetooth/hci_sync.c @@ -413,11 +413,6 @@ static int hci_le_scan_restart_sync(struct hci_dev *hdev) LE_SCAN_FILTER_DUP_ENABLE); } -static int le_scan_restart_sync(struct hci_dev *hdev, void *data) -{ - return hci_le_scan_restart_sync(hdev); -} - static void le_scan_restart(struct work_struct *work) { struct hci_dev *hdev = container_of(work, struct hci_dev, @@ -427,15 +422,15 @@ static void le_scan_restart(struct work_struct *work) bt_dev_dbg(hdev, ""); - hci_dev_lock(hdev); - - status = hci_cmd_sync_queue(hdev, le_scan_restart_sync, NULL, NULL); + status = hci_le_scan_restart_sync(hdev); if (status) { bt_dev_err(hdev, "failed to restart LE scan: status %d", status); - goto unlock; + return; } + hci_dev_lock(hdev); + if (!test_bit(HCI_QUIRK_STRICT_DUPLICATE_FILTER, &hdev->quirks) || !hdev->discovery.scan_start) goto unlock;