[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABBYNZJ=5VH2+my7Gw1fMCaGgdOQfbWNtBGOc27_XQqCP7jD-A@mail.gmail.com>
Date: Thu, 14 Sep 2023 10:51:27 -0700
From: Luiz Augusto von Dentz <luiz.dentz@...il.com>
To: Thorsten Leemhuis <regressions@...mhuis.info>
Cc: Linux regressions mailing list <regressions@...ts.linux.dev>, patchwork-bot+bluetooth@...nel.org,
linux-bluetooth@...r.kernel.org, netdev <netdev@...r.kernel.org>,
Stefan Agner <stefan@...er.ch>
Subject: Re: [PATCH] Bluetooth: hci_sync: Fix handling of HCI_QUIRK_STRICT_DUPLICATE_FILTER
Hi Thorsten,
On Wed, Sep 13, 2023 at 10:13 PM Thorsten Leemhuis
<regressions@...mhuis.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@...mhuis.info> wrote:
> >> On 31.08.23 00:20, patchwork-bot+bluetooth@...nel.org wrote:
> >>> This patch was applied to bluetooth/bluetooth-next.git (master)
> >>> by Luiz Augusto von Dentz <luiz.von.dentz@...el.com>:
> >>> On Tue, 29 Aug 2023 13:59:36 -0700 you wrote:
> >>>> From: Luiz Augusto von Dentz <luiz.von.dentz@...el.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.
--
Luiz Augusto von Dentz
Powered by blists - more mailing lists