linux-kernel - Re: [PATCHv2] Bluetooth: quirk disabling LE Read Transmit Power

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3B8E16FA-97BF-40E5-9149-BBC3E2A245FE@live.com>
Date:   Wed, 17 Nov 2021 03:28:29 +0000
From:   Aditya Garg <gargaditya08@...e.com>
To:     Thorsten Leemhuis <regressions@...mhuis.info>
CC:     Orlando Chamberlain <redecorating@...tonmail.com>,
        Daniel Winkler <danielwinkler@...gle.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        Johan Hedberg <johan.hedberg@...el.com>,
        "linux-bluetooth@...r.kernel.org" <linux-bluetooth@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Luiz Augusto von Dentz <luiz.dentz@...il.com>,
        Marcel Holtmann <marcel@...tmann.org>,
        "regressions@...ts.linux.dev" <regressions@...ts.linux.dev>,
        Sonny Sasaka <sonnysasaka@...omium.org>
Subject: Re: [PATCHv2] Bluetooth: quirk disabling LE Read Transmit Power



> On 16-Nov-2021, at 2:56 PM, Thorsten Leemhuis <regressions@...mhuis.info> wrote:
> 
> On 16.11.21 10:02, Orlando Chamberlain wrote:
>>> Bluetooth maintainers, what's the status here? The proposed patch is
>>> fixing a regression. It's not a recent one (it afaics was introduced in
>>> v5.11-rc1). Nevertheless it would be good to get this finally resolved.
>>> But this thread seems inactive for more than a week now. Or was progress
>>> made, but is only visible somewhere else?
>> 
>> I think the best solution is getting broadcom to update their firmware,
>> I've just sent them a message through a form on their website, I couldn't
>> seem to get it to tell me "Your message has been sent", so it's possible
>> that it didn't submit (more likely I've sent the same message several times).
>> 
>> If I hear back from them I'll send something here.
> 
> Thx for that. But FWIW: from the point of the regression tracker that's
> not the best solution, as according to your report this is a regression.
> IOW: we deal with something that used to up to a certain kernel version
> and was broken by a change to the kernel. That is something frown upon
> in Linux kernel development, hence changes introducing regression are
> often quickly reverted, if they can't get fixed by follow up change quickly.
> 
> That sentence has two "quickly", as we want to prevent more people
> running into the issue, resulting in a loss of trust. But that's what
> will happen if we wait for a firmware update to get developed, tested,
> published, and rolled out. And even then we can't expect users to have
> the latest firmware installed when they switch to a new kernel.
> 
> Hence the best solution *afaics* might be: fix this in the kernel
> somehow now with a workaround; once the firmware update is out, change
> the kernel again to only apply the workaround if the old firmware is in use.
I have an idea. Can we make LE Read Transmit Power as a module parameter and users can turn it off if it is causing trouble. I have a patch for the same but haven't tested it yet.
> 
> At least that's how it looks to me from the outside. But as mentioned
> earlier already: as a Linux kernel regression tracker I'm getting a lot
> of reports on my table. I can only look briefly into most of them.
> Therefore I unfortunately will get things wrong or miss something
> important. I hope that's not the case here; if you think it is, don't
> hesitate to tell me about it in a public reply. That's in everyone's
> interest, as what I wrote above might be misleading to everyone reading
> this, which is something I'd like to avoid.
> 
> Ciao, Thorsten (carrying his Linux kernel regression tracker hat)