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

[Aditya Garg]

> On 25-Nov-2021, at 5:56 PM, Thorsten Leemhuis <regressions@xxxxxxxxxxxxx> wrote:
> 
> 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@xxxxxxxxxxxx> 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@xxxxxxxxxxxx/
>>>> 
>>>> 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@xxxxxxxxxxxxxx/
>>>> 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.
On the basis of DMI data, I have made this patch to disable read transmit power on 16,1. I have tested this on my 16,1 successfully. Still consider this as a draft as more models have to be added. I am sending this to get the approval of the maintainers whether this quirk is acceptable or not. If yes, I shall send the final patch.