> On 17-Nov-2021, at 3:12 PM, Thorsten Leemhuis <regressions@xxxxxxxxxxxxx> wrote: > > On 17.11.21 10:26, Aditya Garg wrote: >>> On 17-Nov-2021, at 12:55 PM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> 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
