On 17.11.21 10:26, Aditya Garg wrote:

quoted

On 17-Nov-2021, at 12:55 PM, Greg KH [off-list ref] wrote:
On Wed, Nov 17, 2021 at 03:28:29AM +0000, Aditya Garg wrote:

quoted

quoted

On 16-Nov-2021, at 2:56 PM, Thorsten Leemhuis [off-list ref] wrote:
On 16.11.21 10:02, Orlando Chamberlain wrote:

quoted

quoted

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