Message ID | 20230829205936.766544-1-luiz.dentz@gmail.com (mailing list archive) |
---|---|
State | Accepted |
Commit | 52bf4fd43f759ac4698f041fff2cb27691698265 |
Headers | show |
Series | Bluetooth: hci_sync: Fix handling of HCI_QUIRK_STRICT_DUPLICATE_FILTER | expand |
Context | Check | Description |
---|---|---|
tedd_an/pre-ci_am | success | Success |
tedd_an/CheckPatch | warning | 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. |
tedd_an/GitLint | fail | 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" |
tedd_an/SubjectPrefix | success | Gitlint PASS |
tedd_an/BuildKernel | success | BuildKernel PASS |
tedd_an/CheckAllWarning | success | CheckAllWarning PASS |
tedd_an/CheckSparse | success | CheckSparse PASS |
tedd_an/CheckSmatch | success | CheckSparse PASS |
tedd_an/BuildKernel32 | success | BuildKernel32 PASS |
tedd_an/TestRunnerSetup | success | TestRunnerSetup PASS |
tedd_an/TestRunner_l2cap-tester | success | TestRunner PASS |
tedd_an/TestRunner_iso-tester | success | TestRunner PASS |
tedd_an/TestRunner_bnep-tester | success | TestRunner PASS |
tedd_an/TestRunner_mgmt-tester | success | TestRunner PASS |
tedd_an/TestRunner_rfcomm-tester | success | TestRunner PASS |
tedd_an/TestRunner_sco-tester | success | TestRunner PASS |
tedd_an/TestRunner_ioctl-tester | success | TestRunner PASS |
tedd_an/TestRunner_mesh-tester | success | TestRunner PASS |
tedd_an/TestRunner_smp-tester | success | TestRunner PASS |
tedd_an/TestRunner_userchan-tester | success | TestRunner PASS |
tedd_an/IncrementalBuild | success | Incremental Build PASS |
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;