> 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. > > thanks, > > greg k-h
