linux-kernel - Re: [PATCHv2] Bluetooth: quirk disabling LE Read Transmit Power

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <332a19f1-30f0-7058-ac18-c21cf78759bb@leemhuis.info>
Date:   Thu, 25 Nov 2021 13:26:43 +0100
From:   Thorsten Leemhuis <regressions@...mhuis.info>
To:     Aditya Garg <gargaditya08@...e.com>,
        Marcel Holtmann <marcel@...tmann.org>
Cc:     Orlando Chamberlain <redecorating@...tonmail.com>,
        Daniel Winkler <danielwinkler@...gle.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        Johan Hedberg <johan.hedberg@...el.com>,
        "linux-bluetooth@...r.kernel.org" <linux-bluetooth@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Luiz Augusto von Dentz <luiz.dentz@...il.com>,
        "regressions@...ts.linux.dev" <regressions@...ts.linux.dev>,
        "sonnysasaka@...omium.org" <sonnysasaka@...omium.org>
Subject: Re: [PATCHv2] Bluetooth: quirk disabling LE Read Transmit Power

Hi, this is your Linux kernel regression tracker speaking again.

On 19.11.21 17:59, Aditya Garg wrote:
>> On 18-Nov-2021, at 12:31 AM, Marcel Holtmann <marcel@...tmann.org> wrote:
>>>> 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?
>>>
>>> I think we should be able to quirk based off the acpi _CID "apple-uart-blth"
>>> or _HID "BCM2E7C". Marcel suggested quirking based of the acpi table here
>>> https://lore.kernel.org/linux-bluetooth/1D2217A9-EA73-4D93-8D0B-5BC2718D4788@holtmann.org/
>>>
>>> This would catch some unaffected Macs, but they don't support the LE Read
>>> Transmit Power command anyway (the affected macs were released after it
>>> was added to the Bluetooth spec, while the unaffected Macs were released
>>> before it was added to the spec, and thus don't support it).
>>>
>>> I'm not sure how to go about applying a quirk based off this, there are
>>> quirks in drivers/bluetooth/hci_bcm.c (no_early_set_baudrate and
>>> drive_rts_on_open), but they don't seem to be based off acpi ids.
>>>
>>> It might be simpler to make it ignore the Unknown Command error, like
>>> in this patch https://lore.kernel.org/linux-bluetooth/CABBYNZLjSfcG_KqTEbL6NOSvHhA5-b1t_S=3FQP4=GwW21kuzg@mail.gmail.com/
>>> however that only applies on bluetooth-next and needed the status it
>>> checks for to be -56, not 0x01.
>>
>> so we abstain from try-and-error sending of commands. The Bluetooth spec
>> has a list of supported commands that a host can query for a reason. This
>> is really broken behavior of the controller and needs to be pointed out as
>> such.
> Well all I can do is provide you any logs or information I can. But we do really wish to get this regression fixed soon.
>>
>> The question is just how we quirk it.

This thread once again looks stalled and smells a lot like "everyone
agrees that his should be fixed, but afaics nobody submitted a fix or
committed to work on one". Please speak up if my impression is wrong, as
this is a regression and thus needs to be fixed, ideally quickly. Part
of my job is to make that happen and thus remind developers and
maintainers about this until we have a fix.

Ciao, Thorsten

#regzbot title bluetooth: "Query LE tx power on startup" broke Bluetooth
on MacBookPro16,1
#regzbot poke