Hello:
This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <[email protected]>:
On Tue, 29 Aug 2023 13:59:36 -0700 you wrote:
> From: Luiz Augusto von Dentz <[email protected]>
>
> 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!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
On 31.08.23 00:20, [email protected] wrote:
>
> This patch was applied to bluetooth/bluetooth-next.git (master)
> by Luiz Augusto von Dentz <[email protected]>:
>
> On Tue, 29 Aug 2023 13:59:36 -0700 you wrote:
>> From: Luiz Augusto von Dentz <[email protected]>
>>
>> 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/[email protected]/
Hi,
On Mon, Sep 11, 2023 at 6:40 AM Linux regression tracking (Thorsten
Leemhuis) <[email protected]> wrote:
>
> On 31.08.23 00:20, [email protected] wrote:
> >
> > This patch was applied to bluetooth/bluetooth-next.git (master)
> > by Luiz Augusto von Dentz <[email protected]>:
> >
> > On Tue, 29 Aug 2023 13:59:36 -0700 you wrote:
> >> From: Luiz Augusto von Dentz <[email protected]>
> >>
> >> 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/[email protected]/
--
Luiz Augusto von Dentz
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) <[email protected]> wrote:
>> On 31.08.23 00:20, [email protected] wrote:
>>> This patch was applied to bluetooth/bluetooth-next.git (master)
>>> by Luiz Augusto von Dentz <[email protected]>:
>>> On Tue, 29 Aug 2023 13:59:36 -0700 you wrote:
>>>> From: Luiz Augusto von Dentz <[email protected]>
>>>>
>>>> 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
<[email protected]> 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) <[email protected]> wrote:
> >> On 31.08.23 00:20, [email protected] wrote:
> >>> This patch was applied to bluetooth/bluetooth-next.git (master)
> >>> by Luiz Augusto von Dentz <[email protected]>:
> >>> On Tue, 29 Aug 2023 13:59:36 -0700 you wrote:
> >>>> From: Luiz Augusto von Dentz <[email protected]>
> >>>>
> >>>> 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.
--
Luiz Augusto von Dentz
On 14.09.23 19:51, Luiz Augusto von Dentz wrote:
> On Wed, Sep 13, 2023 at 10:13 PM Thorsten Leemhuis
> <[email protected]> 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) <[email protected]> wrote:
>>>> On 31.08.23 00:20, [email protected] wrote:
>>>>> This patch was applied to bluetooth/bluetooth-next.git (master)
>>>>> by Luiz Augusto von Dentz <[email protected]>:
>>>>> On Tue, 29 Aug 2023 13:59:36 -0700 you wrote:
>>>>>> From: Luiz Augusto von Dentz <[email protected]>
>>>>>>
>>>>>> 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
>> <[email protected]> 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) <[email protected]> wrote:
>>>>> On 31.08.23 00:20, [email protected] wrote:
>>>>>> This patch was applied to bluetooth/bluetooth-next.git (master)
>>>>>> by Luiz Augusto von Dentz <[email protected]>:
>>>>>> On Tue, 29 Aug 2023 13:59:36 -0700 you wrote:
>>>>>>> From: Luiz Augusto von Dentz <[email protected]>
>>>>>>>
>>>>>>> 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
<[email protected]> 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/[email protected]/
> 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
> >> <[email protected]> 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) <[email protected]> wrote:
> >>>>> On 31.08.23 00:20, [email protected] wrote:
> >>>>>> This patch was applied to bluetooth/bluetooth-next.git (master)
> >>>>>> by Luiz Augusto von Dentz <[email protected]>:
> >>>>>> On Tue, 29 Aug 2023 13:59:36 -0700 you wrote:
> >>>>>>> From: Luiz Augusto von Dentz <[email protected]>
> >>>>>>>
> >>>>>>> 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.
--
Luiz Augusto von Dentz