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]

Date:   Fri, 01 Oct 2021 13:28:03 +0000
From:   Orlando Chamberlain <redecorating@...tonmail.com>
To:     Marcel Holtmann <marcel@...tmann.org>
Cc:     danielwinkler@...gle.com, Johan Hedberg <johan.hedberg@...el.com>,
        linux-bluetooth@...r.kernel.org, linux-kernel@...r.kernel.org,
        regressions@...ts.linux.dev, sonnysasaka@...omium.org
Subject: Re: [PATCHv2] Bluetooth: quirk disabling LE Read Transmit Power

On Fri, 01 Oct 2021 19:35:16 +1000
"Marcel Holtmann" <marcel@...tmann.org> wrote:

> I would really prefer to do that via the ACPI table matching in
> hci_bcm.c and not via some magic chip id check.

Initially I thought we may be able to do this based off BCM2E7C (which
is in the DSDT table which I'll attach), however it seems like many
Macs also have that (i.e. MacBookPro14,1, MacBookAir8,1, MacBook9,1), so
unless all these don't support LE Read Transmit Power, (which would be
hard to determine), I don't know if BCM2E7C can be used to quirk it.

I'll try to see if I can find something else in the ACPI tables that
can be used as a quirk. (I'll see if I can get the table of a similar
model that wasn't affected and compare the BLTH sections)

If ACPI tables other than DSDT could be relevant, I can send them too.
These are the ones that are present:
APIC DMAR DSDT ECDT FACP FACS HPET MCFG SBST SSDT1 SSDT10 SSDT11 SSDT12
SSDT13 SSDT14 SSDT15 SSDT2 SSDT3 SSDT4 SSDT5 SSDT6 SSDT7 SSDT8 SSDT9 VFCT

> We actually don’t know how Broadcom assigns their chip ids.

That's a good point. I've seen 150, 123 and 133 in some recent Macs,
but I also don't know what they refer to or how they are assigned.

View attachment "DSDT.dsl" of type "text/x-dsl" (257600 bytes)