lkml.org 
[lkml]   [2021]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCHv2] Bluetooth: quirk disabling LE Read Transmit Power
Date


> On 17-Nov-2021, at 3:12 PM, Thorsten Leemhuis <regressions@leemhuis.info> wrote:
>
> 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?

<RESENDING AS PLAIN TEXT>

A part of the output of dmidecode is below :-

Handle 0x0005, DMI type 1, 27 bytes
System Information
Manufacturer: Apple Inc.
Product Name: MacBookPro16,1
Version: 1.0
Serial Number: <Removed for Privacy>
UUID: <Removed for Privacy>
Wake-up Type: Power Switch
SKU Number:
Family: MacBook Pro

Handle 0x0006, DMI type 2, 17 bytes
Base Board Information
Manufacturer: Apple Inc.
Product Name: Mac-E1008331FDC96864
Version: MacBookPro16,1
Serial Number: <Removed for Privacy>
Asset Tag:
Features:
Board is a hosting board
Location In Chassis:
Chassis Handle: 0x0007
Type: Motherboard
Contained Object Handles: 0

The product name, MacBookPro16,1 in my case, is unique for each model. If possible a quirk to disable LE Read Transmit Power can be made on this basis.

>
> Ciao, Thorsten

\
 
 \ /
  Last update: 2021-11-17 11:00    [W:0.255 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site