Re: [PATCH] Bluetooth: add quirk disabling query LE tx power

From: Orlando Chamberlain <redecorating@protonmail.com>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: danielwinkler@google.com, Johan Hedberg <johan.hedberg@intel.com>,
	linux-bluetooth <linux-bluetooth@vger.kernel.org>,
	regressions@lists.linux.dev, sonnysasaka@chromium.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Bluetooth: add quirk disabling query LE tx power
Date: Fri, 01 Oct 2021 03:37:12 +0000	[thread overview]
Message-ID: <275acce4-9eab-9cba-7145-5a75a69ca530@protonmail.com> (raw)
In-Reply-To: <FA02CDD7-CFEC-4481-9940-BA95D81FD3F3@holtmann.org>

[-- Attachment #1: Type: text/plain, Size: 2926 bytes --]

On 1/10/21 03:58, Marcel Holtmann wrote:
> so I really need the btmon traces from the device init (so unload and reload the module) and we need to see what commands are supported and what commands are failing.
I'll attach the full file I got with btmon -w MacBookPro16,1.btsnoop, but these seem
like the important bits:

< HCI Command: Read Local Supported Commands (0x04|0x0002) plen 0	#43 [hci0] 9.217379

> HCI Event: Command Complete (0x0e) plen 68				#44 [hci0] 9.218033

      Read Local Supported Commands (0x04|0x0002) ncmd 1

        Status: Success (0x00)

        Commands: 223 entries
	## many many lines here ##
	LE Read Transmit Power (Octet 38 - Bit 7)
	LE Read RF Path Compensation (Octet 39 - Bit 0)

	LE Write RF Path Compensation (Octet 39 - Bit 1)

	LE Set Privacy Mode (Octet 39 - Bit 2)

	Read Local Simple Pairing Options (Octet 41 - Bit 

At the end of the trace:

< HCI Command: LE Read Transmit Power (0x08|0x004b) plen 0		#69 [hci0] 9.226953
> HCI Event: Command Complete (0x0e) plen 4				#70 [hci0] 9.227515
      LE Read Transmit Power (0x08|0x004b) ncmd 1
        Status: Unknown HCI Command (0x01)
= Close Index: F8:FF:C2:06:46:63					[hci0] 9.227666

I'm guessing that this means it reports that it supports the command but it doesn't,
so if this is the case, I'd have to change the description of the quirk to clarify that.

> Since you say this is on a MacBook, I assume this is an UART based Broadcom chip. Sometimes Broadcom has been really flaky with their actually implemented commands. However in some cases firmware updates do fix this. So any chance you can boot OS X and check that the latest firmware is loaded.

Bluetooth for this device is indeed through uart:

# lspci -vvvnnd '8086:a328'
00:1e.0 Communication controller [0780]: Intel Corporation Cannon Lake PCH Serial IO UART Host Controller    [8086:a328] (rev 10)

    Subsystem: Intel Corporation Device [8086:7270]

    Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-

    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-

    Latency: 0, Cache Line Size: 256 bytes

    Interrupt: pin A routed to IRQ 20

    IOMMU group: 8

    Region 0: Memory at 4000000000 (64-bit, non-prefetchable) [size=4K]

    Capabilities: [80] Power Management version 3

        Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)

        Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-

    Capabilities: [90] Vendor Specific Information: Len=14 <?>

    Kernel driver in use: intel-lpss

    Kernel modules: intel_lpss_pci

$ cat /sys/bus/pci/devices/0000:00:1e.0/dw-apb-uart.0/serial0/serial0-0/modalias

acpi:BCM2E7C:APPLE-UART-BLTH:

I've just updated macOS to 11.6, which should have updated firmware. The issue is still present.

[-- Attachment #2: MacBookPro161.btsnoop --]
[-- Type: application/octet-stream, Size: 3242 bytes --]