Message-ID: <8919a36b-e485-500a-2722-529ffa0d2598@leemhuis.info>
Date:   Wed, 17 Nov 2021 10:42:46 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.2.0
Subject: Re: [PATCHv2] Bluetooth: quirk disabling LE Read Transmit Power
Content-Language: en-BS
To:     Aditya Garg <gargaditya08@live.com>,
        Greg KH <gregkh@linuxfoundation.org>
Cc:     Orlando Chamberlain <redecorating@protonmail.com>,
        Daniel Winkler <danielwinkler@google.com>,
        Johan Hedberg <johan.hedberg@intel.com>,
        "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
        Marcel Holtmann <marcel@holtmann.org>,
        "regressions@lists.linux.dev" <regressions@lists.linux.dev>,
        Sonny Sasaka <sonnysasaka@chromium.org>
References: <20211001083412.3078-1-redecorating@protonmail.com>
 <CABBYNZLjSfcG_KqTEbL6NOSvHhA5-b1t_S=3FQP4=GwW21kuzg@mail.gmail.com>
 <972034A8-4B22-4FEE-9B37-C0A7C7ADD60C@live.com> <YYZr14zwHnd52rQ7@kroah.com>
 <829A2DF8-818E-4AF1-84F9-49B5822F9146@live.com> <YYePw07y2DzEPSBR@kroah.com>
 <70a875d0-7162-d149-dbc1-c2f5e1a8e701@leemhuis.info>
 <20211116090128.17546-1-redecorating@protonmail.com>
 <e75bf933-9b93-89d2-d73f-f85af65093c8@leemhuis.info>
 <3B8E16FA-97BF-40E5-9149-BBC3E2A245FE@live.com> <YZSuWHB6YCtGclLs@kroah.com>
 <52DEDC31-EEB2-4F39-905F-D5E3F2BBD6C0@live.com>
From:   Thorsten Leemhuis <regressions@leemhuis.info>
In-Reply-To: <52DEDC31-EEB2-4F39-905F-D5E3F2BBD6C0@live.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 17.11.21 10:26, Aditya Garg wrote:
>> On 17-Nov-2021, at 12:55 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
>> On Wed, Nov 17, 2021 at 03:28:29AM +0000, Aditya Garg wrote:
>>>> On 16-Nov-2021, at 2:56 PM, Thorsten Leemhuis <regressions@leemhuis.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.
>>
>> Module parameters are for the 1990's, please never add new ones as they
>> modify code, not data, and you want to do something like this on a
>> per-device basis, not on "all devices in the system", right?
>
> Exactly. Since the issue affects only a few Macs and not all devices.
> In fact I have spotted just 2 Macs yet affected with this issue.
When Greg said "per-device basis", he afaics meant: per-device in a
system, as a module parameter would also affect a second bluetooth
controller if there was one (say one connected via USB) -- and that
shouldn't happen.

And FWIW: it's still a regression if something that used to work
suddenly requires a module parameter to get working.

So if this just affects two macs, why can't the fix be realized as a
quirk that is only enabled on those two systems? Or are they impossible
to detect clearly via DMI data or something like that?

Ciao, Thorsten