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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> wrote: >>>>> On 31.08.23 00:20, patchwork-bot+bluetooth@xxxxxxxxxx wrote: >>>>>> This patch was applied to bluetooth/bluetooth-next.git (master) >>>>>> by Luiz Augusto von Dentz <luiz.von.dentz@xxxxxxxxx>: >>>>>> On Tue, 29 Aug 2023 13:59:36 -0700 you wrote: >>>>>>> From: Luiz Augusto von Dentz <luiz.von.dentz@xxxxxxxxx> >>>>>>> >>>>>>> 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@xxxxxxxxxxxxxx/ >> 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.
