Bug 110901

Summary: Macbook8,1 12-inch (Early 2015) Bluetooth not working
Product: Drivers Reporter: Leif Liddy (leif.liddy)
Component: BluetoothAssignee: linux-bluetooth (linux-bluetooth)
Status: RESOLVED CODE_FIX    
Severity: normal CC: adborden, andy.shevchenko, bugzilla, christoph.gysin, Derarnold, j, lkml2819, mika.westerberg, olli.salo
Priority: P1    
Hardware: Intel   
OS: Linux   
Kernel Version: 4.4.0 Subsystem:
Regression: No Bisected commit-id:
Attachments: BtwSerialBus-dev.inf.txt
lshw
Patch adding IDs to UART and bluetooth driver
boot log --with Mika patch
lspci -nk
proc-interrupts
lsmod
interrupts cat < /dev/ttyS0
dmesg --nr_uarts=8 ignore_loglevel....
8250_pci.c
acpi dump
journal-log-8250
proc-interrupts --with /dev/ttyS4 opened
boot-log

Description Leif Liddy 2016-01-16 23:42:35 UTC
Created attachment 200081 [details]
BtwSerialBus-dev.inf.txt

Here's what I've found so far...

There is a BCM2E7C:APPLE-UART-BLTH device listed in the acpi namespace.

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:17/BCM2E7C:00
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:17/BCM2E7C:00
E: ID_VENDOR_FROM_DATABASE=Broadcom
E: MODALIAS=acpi:BCM2E7C:APPLE-UART-BLTH:
E: SUBSYSTEM=acpi
E: USEC_INITIALIZED=7539067

However, there is no listing for BCM2E7C in modules.alias

The windows inf file for this device shows that BCM2E7C corresponds to BCM4350 

%Bus.DeviceDesc%=BluePinole2E7C,    ACPI\BCM2E7C        ; BCM4350 no flash

In the extracted driver files there is no corresponding hcd file for BCM4350. I'm guessing that's what meant by "no flash" --that no firmware needs to loaded onto the device.
Comment 1 Leif Liddy 2016-01-17 21:34:30 UTC
Created attachment 200301 [details]
lshw

I tried adding BCM2E7C to hci.bcm.c
Didn't work, but here's what was shown in the logs. 

hci_bcm BCM2E7C:00: BCM irq: -22
hci_bcm BCM2E7C:00: invalid platform data
hci_bcm: probe of BCM2E7C:00 failed with error -22

I've posted the output of lshw which shows several unclaimed devices like the
Wildcat Point-LP Serial IO UART Controller #0

Does anyone whether this would prevent the kernel from communicating with the bluetooth device?
Comment 2 Leif Liddy 2016-01-17 22:24:42 UTC
I think I may have answered my own question.

lspci shows that that all four of these controllers are part of the same device:
(**all 4 of these controllers are unclaimed by the kernel)

00:15.0 Intel Corporation Wildcat Point-LP Serial IO DMA Controller (rev 03)
00:15.2 Intel Corporation Wildcat Point-LP Serial IO I2C Controller #1 (rev 03)
00:15.4 Intel Corporation Wildcat Point-LP Serial IO GSPI Controller #1 (rev 03)
00:15.5 Intel Corporation Wildcat Point-LP Serial IO UART Controller #0 (rev 03)


sysfs shows that BCM2E7C does fall under the Serial IO UART Controller

./devices/pci0000:00/0000:00:15.5/BCM2E7C:00
./devices/pci0000:00/0000:00:15.5/BCM2E7C:00/power
./devices/pci0000:00/0000:00:15.5/BCM2E7C:00/power/control
./devices/pci0000:00/0000:00:15.5/BCM2E7C:00/power/async
./devices/pci0000:00/0000:00:15.5/BCM2E7C:00/power/runtime_enabled
.....

If anyone has any ideas on how to get this things working let me know....
Comment 3 Andy Shevchenko 2016-01-20 17:04:15 UTC
Windows or Linux compatible hardware is supplying by ACPI tables and ACPI enumerated controllers. Here we have them PCI enumerated.

The drivers/dma/dw/pci.c, drivers/spi/spi-pxa2xx-pci.c, drivers/i2c/busses/i2c-designware-pcidrv.c, and drivers/tty/serial/8250/8250_pci.c have to be updated accordingly, i.e. for first step the IDs must be added.
Comment 5 Mika Westerberg 2016-01-21 14:09:44 UTC
Created attachment 200661 [details]
Patch adding IDs to UART and bluetooth driver

Can you try this patch?
Comment 6 Leif Liddy 2016-01-21 19:06:43 UTC
Created attachment 200831 [details]
boot log --with Mika patch

It doesn't appear that the 8250_pci.c patch had any effect.
Comment 7 Leif Liddy 2016-01-21 19:12:28 UTC
Mika --let me know what information/logs you would find useful.
Comment 8 Andy Shevchenko 2016-01-21 19:28:16 UTC
From log it looks like driver can't get interrupt line.

Anyway, can you provide

% lspci -nk

% cat /proc/interrupts

% lsmod

Have you loaded module? I didn't see ports detected from the log file.
Comment 9 Leif Liddy 2016-01-21 19:34:37 UTC
Created attachment 200871 [details]
lspci -nk
Comment 10 Leif Liddy 2016-01-21 19:36:32 UTC
Created attachment 200881 [details]
proc-interrupts
Comment 11 Leif Liddy 2016-01-21 19:39:10 UTC
Created attachment 200891 [details]
lsmod
Comment 12 Leif Liddy 2016-01-21 19:47:22 UTC
I used the fedora stock config for my kernel config 

CONFIG_SERIAL_8250=y
# CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set
CONFIG_SERIAL_8250_PNP=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_DMA=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_CS=m
CONFIG_SERIAL_8250_NR_UARTS=32
CONFIG_SERIAL_8250_RUNTIME_UARTS=32
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
CONFIG_SERIAL_8250_RSA=y
# CONFIG_SERIAL_8250_FSL is not set
CONFIG_SERIAL_8250_DW=y
CONFIG_SERIAL_8250_RT288X=y
# CONFIG_SERIAL_8250_FINTEK is not set
CONFIG_SERIAL_8250_MID=y
# Non-8250 serial port support

**the 8250_pci is built-in, do you want to the contents of sysfs?
Comment 13 Andy Shevchenko 2016-01-21 19:57:27 UTC
Can you add 'nr_uarts=8 ignore_loglevel' to the command line? And resend /proc/interrupts when all serial ports are opened? You may achieve this by doing something like
% cat < /dev/ttyS0 &
Comment 14 Leif Liddy 2016-01-21 20:16:44 UTC
Created attachment 200901 [details]
interrupts cat < /dev/ttyS0

**booted with: nr_uarts=8 ignore_loglevel

**this is what I see when running the following cmd:

[root@mac ~]# cat < /dev/ttyS0  &
[1] 2130
[root@mac ~]# cat: -: Input/output error

#I grabbed /proc/interrupts in another terminal at this point

*additional information:
[root@mac ~]# setserial -g /dev/ttyS0
/dev/ttyS0, UART: unknown, Port: 0x03f8, IRQ: 4
[root@mac ~]# setserial -g /dev/ttyS1
/dev/ttyS1, UART: unknown, Port: 0x02f8, IRQ: 3
[root@mac ~]# setserial -g /dev/ttyS2
/dev/ttyS2, UART: unknown, Port: 0x03e8, IRQ: 4
[root@mac ~]# setserial -g /dev/ttyS3
/dev/ttyS3, UART: unknown, Port: 0x02e8, IRQ: 3
[root@mac ~]# setserial -g /dev/ttyS4
/dev/ttyS4, UART: unknown, Port: 0x0000, IRQ: 0
[root@mac ~]# setserial -g /dev/ttyS5
/dev/ttyS5, UART: unknown, Port: 0x0000, IRQ: 0
[root@mac ~]# setserial -g /dev/ttyS6
/dev/ttyS6, UART: unknown, Port: 0x0000, IRQ: 0
[root@mac ~]# setserial -g /dev/ttyS7
/dev/ttyS7, UART: unknown, Port: 0x0000, IRQ: 0
Comment 15 Leif Liddy 2016-01-21 20:34:14 UTC
sysfs info:

/sys/bus/pci/drivers/8250_mid
/sys/bus/pci/drivers/8250_mid/bind
/sys/bus/pci/drivers/8250_mid/new_id
/sys/bus/pci/drivers/8250_mid/uevent
/sys/bus/pci/drivers/8250_mid/unbind
/sys/bus/pci/drivers/8250_mid/remove_id

/sys/bus/platform/drivers/serial8250
/sys/bus/platform/drivers/serial8250/bind
/sys/bus/platform/drivers/serial8250/serial8250
/sys/bus/platform/drivers/serial8250/uevent
/sys/bus/platform/drivers/serial8250/unbind

/sys/module/8250
/sys/module/8250/parameters
/sys/module/8250/parameters/nr_uarts
/sys/module/8250/parameters/skip_txen_test
/sys/module/8250/parameters/share_irqs
/sys/module/8250/parameters/probe_rsa
/sys/module/8250/uevent
Comment 16 Leif Liddy 2016-01-21 21:30:25 UTC
Looks like to the DMA controller is working after this line to ./drivers/dma/dw/pci.c

+  { PCI_VDEVICE(INTEL, 0x9ce0) },

lshw output:

     *-generic:0
           description: DMA controller
           product: Wildcat Point-LP Serial IO DMA Controller
           vendor: Intel Corporation
           physical id: 15
           bus info: pci@0000:00:15.0
           version: 03
           width: 32 bits
           clock: 33MHz
           capabilities: pm eisa_dma bus_master cap_list
           configuration: driver=dw_dmac_pci latency=0
           resources: irq:20 memory:c181c000-c181cfff
Comment 17 Leif Liddy 2016-01-21 21:35:53 UTC
Does anyone know how to edit:
drivers/spi/spi-pxa2xx-pci.c
drivers/i2c/busses/i2c-designware-pcidrv.c

To get them working with my hardware?
Comment 18 Andy Shevchenko 2016-01-21 21:39:11 UTC
So, the attachment #200901 [details] doesn't make sense since UART driver is not bound. Something prevents this to happen. Boot kernel with 'nr_uarts=8 ignore_loglevel initcall_debug debug' and attach dmesg output.
Comment 19 Andy Shevchenko 2016-01-21 21:39:55 UTC
WRT comment #17 same way like you did for dw_dmac driver.
Comment 20 Leif Liddy 2016-01-21 21:57:56 UTC
Created attachment 200911 [details]
dmesg --nr_uarts=8 ignore_loglevel....
Comment 21 Leif Liddy 2016-01-21 22:08:38 UTC
in drivers/spi/spi-pxa2xx-pci.c
I'm not sure what to put for the PORT_XXX

static const struct pci_device_id pxa2xx_spi_pci_devices[] = {
        { PCI_VDEVICE(INTEL, 0x2e6a), PORT_CE4100 },
        { PCI_VDEVICE(INTEL, 0x0935), PORT_QUARK_X1000 },
        { PCI_VDEVICE(INTEL, 0x0f0e), PORT_BYT },
        { PCI_VDEVICE(INTEL, 0x228e), PORT_BSW0 },
        { PCI_VDEVICE(INTEL, 0x2290), PORT_BSW1 },
        { PCI_VDEVICE(INTEL, 0x22ac), PORT_BSW2 },
        { },

In drivers/i2c/busses/i2c-designware-pcidrv.c
What do I put for the arch? 

        /* Haswell */
        { PCI_VDEVICE(INTEL, 0x9c61), haswell },
        { PCI_VDEVICE(INTEL, 0x9c62), haswell },
        /* Braswell / Cherrytrail */
        { PCI_VDEVICE(INTEL, 0x22C1), baytrail },
        { PCI_VDEVICE(INTEL, 0x22C2), baytrail },
Comment 22 Leif Liddy 2016-01-21 23:32:09 UTC
Created attachment 200941 [details]
8250_pci.c

I compiled the 8250_pci as a module, shouldn't I see 0x9ce3 or 0x9ce4 listed as an alias?

# modinfo 8250_pci | grep -i 8086
alias:          pci:v00008086d00000936sv*sd*bc*sc*i*
alias:          pci:v00008086d0000228Csv*sd*bc07sc*i*
alias:          pci:v00008086d0000228Asv*sd*bc07sc*i*
alias:          pci:v00008086d00000F0Csv*sd*bc07sc*i*
alias:          pci:v00008086d00000F0Asv*sd*bc07sc*i*
alias:          pci:v00008086d00002E66sv*sd*bc*sc*i*
alias:          pci:v00008086d00001960sv0000E4BFsd*bc*sc*i*
Comment 23 Leif Liddy 2016-01-21 23:51:54 UTC
The DMA controller alias shows up fine...

# modinfo dw_dmac_pci | grep -i 9ce0
alias:          pci:v00008086d00009CE0sv*sd*bc*sc*i*
Comment 24 Leif Liddy 2016-01-22 00:59:01 UTC
figured it out...had to add these lines to 8250_pci.c

        {       PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BDW_UART1,
                PCI_ANY_ID,  PCI_ANY_ID,
                PCI_CLASS_COMMUNICATION_SERIAL << 8, 0xff0000,
                pbn_byt },
        {       PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BDW_UART2,
                PCI_ANY_ID,  PCI_ANY_ID,
                PCI_CLASS_COMMUNICATION_SERIAL << 8, 0xff0000,
                pbn_byt },
lshw output: 

     *-communication:0
             description: Serial controller
             product: Wildcat Point-LP Serial IO UART Controller #0
             vendor: Intel Corporation
             physical id: 15.5
             bus info: pci@0000:00:15.5
             version: 03
             width: 32 bits
             clock: 33MHz
             capabilities: pm 16550 bus_master cap_list
             configuration: driver=serial latency=0
             resources: irq:21 memory:c1819000-c1819fff
Comment 25 Mika Westerberg 2016-01-22 09:07:33 UTC
(In reply to leif from comment #6)
> Created attachment 200831 [details]
> boot log --with Mika patch
> 
> It doesn't appear that the 8250_pci.c patch had any effect.

Are you sure you have the patch applied? It should bind to the PCI UART device and I cannot see it happening from your lspci. Please double check.
Comment 26 Mika Westerberg 2016-01-22 09:26:06 UTC
(In reply to Mika Westerberg from comment #25)
> (In reply to leif from comment #6)
> > Created attachment 200831 [details]
> > boot log --with Mika patch
> > 
> > It doesn't appear that the 8250_pci.c patch had any effect.
> 
> Are you sure you have the patch applied? It should bind to the PCI UART
> device and I cannot see it happening from your lspci. Please double check.

Ah, I can see now that I missed few places in the patch.

BTW, can you attach acpidump from that machine to the bug?
Comment 27 Leif Liddy 2016-01-22 10:45:17 UTC
Created attachment 200961 [details]
acpi dump

acpidump > acpi.dat
Comment 28 Leif Liddy 2016-01-22 15:25:03 UTC
Created attachment 200971 [details]
journal-log-8250

It looks like there might be some issues with the serial driver...
Comment 29 Leif Liddy 2016-01-22 15:51:52 UTC
kernel: 0000:00:15.5: ttyS4 at MMIO 0xc1819000 (irq = 21, base_baud = 2764800) is a 16550A
Comment 30 Leif Liddy 2016-01-22 19:19:26 UTC
I'm having partial success in getting the interface up..
*I've recompiled rawhide bluez 5.37 srpm --and enabled experimental settings --so I could use btattach --which is apparently is the correct tool for the job.

# btattach --bredr /dev/ttyS4 -P bcm
Attaching BR/EDR controller to /dev/ttyS4
Switched line discipline from 0 to 15
Device index 0 attached
**hangs here***

**dmesg log**
[   41.189322]  connection1:0: detected conn error (1020)
[   46.160158] Bluetooth: hci0: BCM: failed to write clock (-110)
[   46.499572]  connection1:0: detected conn error (1020)
[   48.160154] Bluetooth: hci0 command 0x0c03 tx timeout
[   50.079147] audit_printk_skb: 36 callbacks suppressed
[   50.079154] audit: type=1131 audit(1453489901.105:200): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[   51.620184]  connection1:0: detected conn error (1020)
[   56.161007] Bluetooth: hci0: BCM: Reset failed (-110)
[   56.945330]  connection1:0: detected conn error (1020)
[   84.984370] Bluetooth: hci0: BCM: failed to write clock (-4)
[   84.984517] Bluetooth: hci0: BCM: Reset failed (-4)
[   85.220511] Bluetooth: hci0 command tx timeout
[   85.620177]  connection1:0: detected conn error (1020)

[root@mac ~]# hciconfig 
hci0:	Type: BR/EDR  Bus: UART
	BD Address: 00:00:00:00:00:00  ACL MTU: 0:0  SCO MTU: 0:0
	DOWN 
	RX bytes:0 acl:0 sco:0 events:0 errors:0
	TX bytes:14 acl:0 sco:0 commands:3 errors:0
Comment 31 Leif Liddy 2016-01-22 19:40:52 UTC
I can get the interface to stay up with this:

# hciattach /dev/ttyS4 any
Device setup complete

**dmesg**
[   51.442686]  connection1:0: detected conn error (1020)
[   52.887977] serial 0000:00:15.5: found DMA channel "rx" at index 1
[   52.888401] dmaengine: private_candidate: dma0chan0 busy
[   52.888407] dmaengine: private_candidate: dma0chan1 busy
[   52.888599] dma dma0chan2: dwc_alloc_chan_resources: allocated 64 descriptors
[   52.888604] dmaengine: __dma_request_channel: success (dma0chan2)
[   52.888609] serial 0000:00:15.5: found DMA channel "tx" at index 0
[   52.888714] dmaengine: private_candidate: dma0chan0 busy
[   52.888717] dmaengine: private_candidate: dma0chan1 busy
[   52.888720] dmaengine: private_candidate: dma0chan2 busy
[   52.889075] dma dma0chan3: dwc_alloc_chan_resources: allocated 64 descriptors
[   52.889079] dmaengine: __dma_request_channel: success (dma0chan3)
[   56.898018] Bluetooth: hci0 command 0x1001 tx timeout
[   58.898059] Bluetooth: hci0 command 0x1009 tx timeout
[   64.544360]  connection1:0: detected conn error (1020)

[root@mac ~]# hciconfig 
hci0:	Type: BR/EDR  Bus: UART
	BD Address: 00:00:00:00:00:00  ACL MTU: 0:0  SCO MTU: 0:0
	DOWN 
	RX bytes:0 acl:0 sco:0 events:0 errors:0
	TX bytes:12 acl:0 sco:0 commands:3 errors:0
Comment 32 Leif Liddy 2016-01-23 03:30:05 UTC
Here are the bluetooth details from OSX:

Manufacturer: Broadcom
Address: A8-66-7F-20-36-F6
Transport: UART
Chipset: 4350C1
Firmware Version: v64 c5236
Vendor ID: 0x05AC
Product ID: 0x828E
HCI Version: 0x7
HCI Revision: 0x1474
LMP Version: 0x7
LMP Subversion: 0x6140
Device Type (Major): Computer
Device Type (Complete): Mac Portable
Composite Class Of Device: 0x38010C
Device Class (Major): 0x01
Device Class (Minor): 0x03
Service Class: 0x1C0
Comment 33 Andy Shevchenko 2016-01-23 11:56:08 UTC
(In reply to leif from comment #29)
> kernel: 0000:00:15.5: ttyS4 at MMIO 0xc1819000 (irq = 21, base_baud =
> 2764800) is a 16550A

How many such lines do you have in dmesg?  You may decrease or drop nr_uarts parameter from kernel command line.

(In reply to leif from comment #32)
> Here are the bluetooth details from OSX:

So, I didn't get do you have it working now?
Comment 34 Leif Liddy 2016-01-23 15:34:13 UTC
Here's the current status:
**I'm running a kernel with patched versions of 
./drivers/dma/dw/pci.c
./drivers/tty/serial/8250/8250_pci.c

The bluetooth device always gets assigned to /dev/ttyS4
0000:00:15.5: ttyS4 at MMIO 0xc1819000 (irq = 21, base_baud = 2764800) is a 16550A

I can get the hci0 interface to show up by running:

# btattach --bredr /dev/ttyS4 -P bcm
Attaching BR/EDR controller to /dev/ttyS4
Switched line discipline from 0 to 15
Device index 0 attached

hci0:	Type: BR/EDR  Bus: UART
	BD Address: 00:00:00:00:00:00  ACL MTU: 0:0  SCO MTU: 0:0
	DOWN 
	RX bytes:0 acl:0 sco:0 events:0 errors:0
	TX bytes:14 acl:0 sco:0 commands:3 errors:0

But I can't bring up the interface with "hciconfig hci0 up"
[  678.412771] Bluetooth: hci0 command 0xfc45 tx timeout
[  686.409745] Bluetooth: hci0: BCM: failed to write clock (-110)
[  688.409716] Bluetooth: hci0 command 0x0c03 tx timeout
[  696.409694] Bluetooth: hci0: BCM: Reset failed (-110)

I suspect more work needs to be done with with hci_bcm.c or with btbcm.c
I'm still seeing these messages at boot:
[   36.775883] hci_bcm BCM2E7C:00: BCM irq: -22
[   36.779009] hci_bcm BCM2E7C:00: invalid platform data
[   36.822702] hci_bcm: probe of BCM2E7C:00 failed with error -22

I should be seeing something more like this:
hci_bcm BCM2E7C:00: BCM2E7C:00 device registered.


I posted the info from OSX just to give you more insight into the details of the device. Let me know if what information you would find useful.
Comment 35 Leif Liddy 2016-01-23 15:39:37 UTC
Created attachment 201091 [details]
proc-interrupts --with /dev/ttyS4 opened

Booted with nr_uarts=8

I did  cat < /dev/ttyS[0-7] &
Only worked for /dev/ttyS4 
For all other ports, received "Input/output error"
Comment 36 Leif Liddy 2016-01-23 15:41:30 UTC
Created attachment 201101 [details]
boot-log

booted with options:
nr_uarts=8 ignore_loglevel initcall_debug debug
Comment 37 Andy Shevchenko 2016-01-25 09:33:55 UTC
It looks like Bluetooth device has his own methods to be controlled.
BTPU (power up?), BTPD (power down), BTRS (reset), BTLP (low power). Driver doesn't support that (yet?).
Comment 38 Andy Shevchenko 2016-01-27 18:08:36 UTC
Reassign to Bluetooth team since UART driver seems working now.
Comment 39 Andy Shevchenko 2016-01-27 18:09:13 UTC
Oops, now for sure.
Comment 40 Mika Westerberg 2016-01-29 12:42:34 UTC
Leif,

I'm going to send the uart patch upstream. Since you did changes to the patch as well, can I add your Signed-off-by to it?
Comment 41 Leif Liddy 2016-01-29 14:10:12 UTC
Yeah, that's fine. Are you also submitting a patch for hci_bcm.c as well? 
**I've just updated my email address in my profile --please use the new address.
Comment 42 Mika Westerberg 2016-01-29 14:24:08 UTC
Yes, I'll submit them both. And will use your updated email address.
Comment 43 derarnold 2016-04-17 11:15:37 UTC
Hello Guys. 

Quick info: I have tested with 4.6-rc3: No change.

Do you need some logfiles or can I help somehow?

derarnold
Comment 44 derarnold 2016-04-17 15:06:56 UTC
Hello.

I found that on the XPS13 they use the same chip. On the ARCH wiki, they have a link to download ans install the firmware. It seems that you have seperate firmware for the NIC and for bluetooth. Unfortunately this also does not work, but I thought I bring it to your attention.

https://wiki.archlinux.org/index.php/Dell_XPS_13_(2016)

derarnold
Comment 45 Christoph Gysin 2017-09-06 08:39:42 UTC
FYI: Some work has been done on this at:
https://github.com/Dunedan/mbp-2016-linux/issues/29

Commits to use the ACPI methods can be found in:
https://github.com/torvalds/linux/compare/master...l1k:hci_bcm

This fixes the "invalid platform data".

Using btattach still results in the same "command ... tx timeout" though.
Comment 46 Leif Liddy 2017-09-24 22:41:27 UTC
Cool, thanks for the update.

I managed to get bluetooth working on a 4.14-rc1 kernel after applying 

l1k's hci_bcm.c patch
https://github.com/torvalds/linux/compare/master...l1k:hci_bcm

and roadrunner2's hci_bcm.c and hci_ldisc.c patches
https://github.com/l1k/linux/pull/1/files/61c59e8b2a7f129a339608610069a26f4181c82a..7dd4a90a92b97b017d9210899afcfbe985b10509

There's a pull request to include roadrunner's patches in l1k's repo. Work is also being done to port the patches to 4.14 (I just did it manually)
So, this all be cleaned up in the near future. 

You can read more about the current status on the link Christoph posted:
https://github.com/Dunedan/mbp-2016-linux/issues/29
Comment 47 Leif Liddy 2017-09-24 22:43:47 UTC
Should have mentioned that I'm using a Macbook9,1 12-inch (2016) model.
Comment 48 Christoph Gysin 2017-09-25 07:08:58 UTC
I got it to work in a MBP13,1 using those same patches.
Comment 49 Jonas 2024-03-17 21:23:08 UTC
(In reply to Leif Liddy from comment #46)
> Cool, thanks for the update.
> 
> I managed to get bluetooth working on a 4.14-rc1 kernel after applying 
> 
> l1k's hci_bcm.c patch
> https://github.com/torvalds/linux/compare/master...l1k:hci_bcm
> 
> and roadrunner2's hci_bcm.c and hci_ldisc.c patches
> https://github.com/l1k/linux/pull/1/files/
> 61c59e8b2a7f129a339608610069a26f4181c82a..
> 7dd4a90a92b97b017d9210899afcfbe985b10509
> 
> There's a pull request to include roadrunner's patches in l1k's repo. Work
> is also being done to port the patches to 4.14 (I just did it manually)
> So, this all be cleaned up in the near future. 
> 
> You can read more about the current status on the link Christoph posted:
> https://github.com/Dunedan/mbp-2016-linux/issues/29

Are these patches still required or have they eventually been merged into the kernel eventually?