Bluetooth on 2015+ MacBook (Pro)

Commit 27378f4c1b92 ("Bluetooth: Avoid WARN splat due to missing GPIOLIB") amended Kconfig to select GPIOLIB if BT_HCIUART_NOKIA, BT_HCIUART_INTEL or BT_HCIUART_BCM is enabled since all three drivers require it to function.

The diagnosis was correct but the treatment was not. As stated in Documentation/gpio/consumer.txt:

Guidelines for GPIOs consumers
==============================

Drivers that can't work without standard GPIO calls should have Kconfig entries that depend on GPIOLIB.
^^^^^^^^^
Fix it.

Reported-by Andy Shevchenko <[email protected]>

Cc Linus Walleij <[email protected]>

Signed-off-by Lukas Wunner <[email protected]>

Commit 27378f4c1b92 ("Bluetooth: Avoid WARN splat due to missing GPIOLIB") amended Kconfig to select GPIOLIB if BT_HCIUART_NOKIA, BT_HCIUART_INTEL or BT_HCIUART_BCM is enabled since all three drivers require it to function.

The diagnosis was correct but the treatment was not. As stated in Documentation/gpio/consumer.txt:

Guidelines for GPIOs consumers
==============================

Drivers that can't work without standard GPIO calls should have Kconfig entries that depend on GPIOLIB.

                        ^^^^^^^^^

Fix it.

Reported-by Andy Shevchenko <[email protected]>

Cc Linus Walleij <[email protected]>

Signed-off-by Lukas Wunner <[email protected]>

---
drivers/bluetooth/Kconfig | 6 +++---

1 file changed, 3 insertions(+), 3 deletions(-)

Commit 0395ffc1ee05 ("Bluetooth: hci_bcm: Add PM for BCM devices") amended this driver to request a shutdown and device wake GPIO on probe, but mandated that only one of them need to be present:

	/* Make sure at-least one of the GPIO is defined and that
	 * a name is specified for this instance
	 */
	if ((!dev->device_wakeup && !dev->shutdown) || !dev->name) {
		dev_err(&pdev->dev, "invalid platform data\n");
		return -EINVAL;
	}

However the same commit added a call to bcm_gpio_set_power() to the ->probe hook, which unconditionally accesses *both* GPIOs. Luckily, the resulting NULL pointer deref was never reported, suggesting there's no machine where either GPIO is missing.

Commit 8a92056837fd ("Bluetooth: hci_bcm: Add (runtime)pm support to the serdev driver") removed the check whether at least one of the GPIOs is present without specifying a reason.

Because commit 62aaefa7d038 ("Bluetooth: hci_bcm: improve use of gpios API") refactored the driver to use devm_gpiod_get_optional() instead of devm_gpiod_get(), one is now tempted to believe that the driver doesn't require *any* of the two GPIOs.

Which is wrong, the driver still requires both GPIOs to avoid a NULL pointer deref. To this end, establish the status quo ante and request the GPIOs with devm_gpiod_get() again. Bail out of ->probe if either of them is missing.

Oddly enough, whereas bcm_gpio_set_power() accesses the device wake pin unconditionally, bcm_suspend_device() and bcm_resume_device() do check for its presence before accessing it. Those checks are superfluous, so remove them.

Cc Frédéric Danis <[email protected]>

Cc Loic Poulain <[email protected]>

Cc Hans de Goede <[email protected]>

Cc Uwe Kleine-König <[email protected]>

Cc Andy Shevchenko <[email protected]>

Cc Linus Walleij <[email protected]>

Signed-off-by Lukas Wunner <[email protected]>

---
drivers/bluetooth/hci_bcm.c | 24 +++++++++---------------

1 file changed, 9 insertions(+), 15 deletions(-)

drivers/bluetooth/hci_bcm.c +6 -10

index 1fc604a0d870..4294d9df1d4d 100644
@@ -572,11 +572,9 @@ static int bcm_suspend_device(struct device *dev)
 	}
 
 	/* Suspend the device */
-	if (bdev->device_wakeup) {
-		gpiod_set_value(bdev->device_wakeup, false);
-		bt_dev_dbg(bdev, "suspend, delaying 15 ms");
-		mdelay(15);
-	}
+	gpiod_set_value(bdev->device_wakeup, false);
+	bt_dev_dbg(bdev, "suspend, delaying 15 ms");
+	mdelay(15);
 
 	return 0;
 }

@@ -587,11 +585,9 @@ static int bcm_resume_device(struct device *dev)
 
 	bt_dev_dbg(bdev, "");
 
-	if (bdev->device_wakeup) {
-		gpiod_set_value(bdev->device_wakeup, true);
-		bt_dev_dbg(bdev, "resume, delaying 15 ms");
-		mdelay(15);
-	}
+	gpiod_set_value(bdev->device_wakeup, true);
+	bt_dev_dbg(bdev, "resume, delaying 15 ms");
+	mdelay(15);
 
 	/* When this executes, the device has woken up already */
 	if (bdev->is_suspended && bdev->hu) {

Currently runtime PM is only enabled if a valid host wake IRQ was found.

However it is used in ways which seem unrelated to host wake:
E.g., runtime PM is used to force the Bluetooth device on for 5 sec after a complete packet has been received.

Afford this functionality to devices which lack an IRQ by moving the code to enable runtime PM from bcm_request_irq() to bcm_setup().

Cc Frédéric Danis <[email protected]>

Signed-off-by Lukas Wunner <[email protected] > ---

  drivers/bluetooth/hci_bcm.c | 11 +++++------
  1 file changed, 5 insertions(+), 6 deletions(-)

drivers/bluetooth/hci_bcm.c +5 -6

index 4294d9df1d4d..d9ca27d3209a 100644
@@ -221,12 +221,6 @@ static int bcm_request_irq(struct bcm_data *bcm)
 
  	device_init_wakeup(bdev->dev, true);
 
-	pm_runtime_set_autosuspend_delay(bdev->dev,
-					 BCM_AUTOSUSPEND_DELAY);
-	pm_runtime_use_autosuspend(bdev->dev);
-	pm_runtime_set_active(bdev->dev);
-	pm_runtime_enable(bdev->dev);
-
  unlock:
  	mutex_unlock(&bcm_device_lock);
 

@@ -468,6 +462,11 @@ static int bcm_setup(struct hci_uart *hu)
  	if (!bcm_request_irq(bcm))
  		err = bcm_setup_sleep(hu);
 
+	pm_runtime_set_autosuspend_delay(bcm->dev->dev, BCM_AUTOSUSPEND_DELAY);
+	pm_runtime_use_autosuspend(bcm->dev->dev);
+	pm_runtime_set_active(bcm->dev->dev);
+	pm_runtime_enable(bcm->dev->dev);
+
  	return err;
  }
 

Quoted 8 lines · Lukas Wunner

Currently runtime PM is only enabled if a valid host wake IRQ was found.

However it is used in ways which seem unrelated to host wake:
E.g., runtime PM is used to force the Bluetooth device on for 5 sec after a complete packet has been received.

Afford this functionality to devices which lack an IRQ by moving the code to enable runtime PM from bcm_request_irq() to bcm_setup().

Hmm, this seems to not make much sense. If runtime_pm is not enabled (no host wake irq) then the device never runtime suspends, so there is no need to force the device on when we're sending / after a complete packet has been received.

That you give "after a complete packet has been received" as condition example illustrates nicely why I believe this commit is a bad idea, if say a bluetooth keyboard wants to send a keypress HID report after the runtime pm timeout has elapsed, how are we going to receive that report since we're runtime suspended and there is no host wake irq to tell us to wakeup the UART and enable receiving on it again?

I don't see how runtime pm can work without a host-wake IRQ, so IMHO this commit is wrong. Tip when testing this, make sure that you don't have the bluetooth config panel of e.g. gnome3 open as that continuously scans for new devices, so runtime pm never kicks in. I've had a bad configured host IRQ pin on some ASUS laptops using serdev bcm bt and the only way a bt keyboard would work reliable was to keep the config panel open...

Quoted 15 lines · Hans de Goede

Quoted 8 lines · Lukas Wunner

Currently runtime PM is only enabled if a valid host wake IRQ was found.

However it is used in ways which seem unrelated to host wake:
E.g., runtime PM is used to force the Bluetooth device on for 5 sec after a complete packet has been received.

Afford this functionality to devices which lack an IRQ by moving the code to enable runtime PM from bcm_request_irq() to bcm_setup().

Hmm, this seems to not make much sense. If runtime_pm is not enabled (no host wake irq) then the device never runtime suspends, so there is no need to force the device on when we're sending / after a complete packet has been received.

Quoted 6 lines

That you give "after a complete packet has been received" as condition example illustrates nicely why I believe this commit is a bad idea, if say a bluetooth keyboard wants to send a keypress HID report after the runtime pm timeout has elapsed, how are we going to receive that report since we're runtime suspended and there is no host wake irq to tell us to wakeup the UART and enable receiving on it again?

The host UART on MacBooks apparently never runtime suspends, so this couldn't have been observed during testing:

They use either 8250_lpss.c (which has no runtime PM callbacks) or 8250_dw.c (which disables the clock during runtime suspend, but the MacBooks use a fixed rate clock which can't be disabled). Moreover intel_lpss_suspend() excludes the UART from being put into reset.

But the objection is valid so I withdraw this patch.

On MacBooks the host wake pin is ORed with the wake pin of the trackpad and keyboard and goes into the SMC. I think it is only meant to be used to wake the system from sleep and not to provide an interrupt at runtime. In theory we could request the SMC's GPE but we couldn't tell if the interrupt was sent by the trackpad/keyboard or by the Bluetooth controller, or was caused by something else entirely.

So it's probably better not to use runtime PM at all. Let me rework patch [10/10] and remove this hunk:

(quoted diff) +8 -0

+	/* Macs wire the host wake pin to the System Management Controller,
+	 * which handles wakeup independently of the operating system.
+	 */
+	if (x86_apple_machine) {
+		err = 0;
+		goto unlock;
+	}
+

I notice that command 0xfc27 is used to write the sleep_params. Does anyone know the command to read them so that we can check the defaults Apple is using and find out if they can be optimized?

Quoted 7 lines

I don't see how runtime pm can work without a host-wake IRQ, so IMHO this commit is wrong. Tip when testing this, make sure that you don't have the bluetooth config panel of e.g. gnome3 open as that continuously scans for new devices, so runtime pm never kicks in. I've had a bad configured host IRQ pin on some ASUS laptops using serdev bcm bt and the only way a bt keyboard would work reliable was to keep the config panel open...

I don't have one of these MacBooks, I'm submitting patches on behalf of others,

but I'm told that having the gnome panel open leads to choppy audio on these machines. Is that normal?

Quoted 2 lines · Lukas Wunner

I don't have one of these MacBooks, I'm submitting patches on behalf of others,

I didn't realize that, great work on this! It must not be easy to develop a comprehensive patch set like this without direct hw access.

Quoted 14 lines

Quoted 8 lines

Currently runtime PM is only enabled if a valid host wake IRQ was found.

However it is used in ways which seem unrelated to host wake:
E.g., runtime PM is used to force the Bluetooth device on for 5 sec after a complete packet has been received.

Afford this functionality to devices which lack an IRQ by moving the code to enable runtime PM from bcm_request_irq() to bcm_setup().

Hmm, this seems to not make much sense. If runtime_pm is not enabled (no host wake irq) then the device never runtime suspends, so there is no need to force the device on when we're sending / after a complete packet has been received.

Quoted 6 lines

That you give "after a complete packet has been received" as condition example illustrates nicely why I believe this commit is a bad idea, if say a bluetooth keyboard wants to send a keypress HID report after the runtime pm timeout has elapsed, how are we going to receive that report since we're runtime suspended and there is no host wake irq to tell us to wakeup the UART and enable receiving on it again?

The host UART on MacBooks apparently never runtime suspends, so this couldn't have been observed during testing:

They use either 8250_lpss.c (which has no runtime PM callbacks) or 8250_dw.c (which disables the clock during runtime suspend, but the MacBooks use a fixed rate clock which can't be disabled). Moreover intel_lpss_suspend() excludes the UART from being put into reset.

But the objection is valid so I withdraw this patch.

On MacBooks the host wake pin is ORed with the wake pin of the trackpad and keyboard and goes into the SMC. I think it is only meant to be used to wake the system from sleep and not to provide an interrupt at runtime. In theory we could request the SMC's GPE but we couldn't tell if the interrupt was sent by the trackpad/keyboard or by the Bluetooth controller, or was caused by something else entirely.

So it's probably better not to use runtime PM at all. Let me rework patch [10/10] and remove this hunk:

(quoted diff) +8 -0

+	/* Macs wire the host wake pin to the System Management Controller,
+	 * which handles wakeup independently of the operating system.
+	 */
+	if (x86_apple_machine) {
+		err = 0;
+		goto unlock;
+	}
+

I notice that command 0xfc27 is used to write the sleep_params. Does anyone know the command to read them so that we can check the defaults Apple is using and find out if they can be optimized?

Quoted 7 lines

I don't see how runtime pm can work without a host-wake IRQ, so IMHO this commit is wrong. Tip when testing this, make sure that you don't have the bluetooth config panel of e.g. gnome3 open as that continuously scans for new devices, so runtime pm never kicks in. I've had a bad configured host IRQ pin on some ASUS laptops using serdev bcm bt and the only way a bt keyboard would work reliable was to keep the config panel open...

I don't have one of these MacBooks, I'm submitting patches on behalf of others, but I'm told that having the gnome panel open leads to choppy audio on these machines. Is that normal? The Bluetooth controllers are fixed to a baudrate of 3 Mbit on these machines.

Quoted 3 lines

I notice that command 0xfc27 is used to write the sleep_params. Does anyone know the command to read them so that we can check the defaults Apple is using and find out if they can be optimized?

the Read Sleepmode Param is 0xfc28 and requires no parameters. You can check monitor/broadcom.c for a bunch of these commands since btmon will decode them for you if possible. Might want to actually post the btmon log of the init sequence here for reference (just blacklist the module and load it manually after starting btmon).

I thought that I created a Broadcom specific init that reads most of the standard values so we have them for reference in the btmon logs. However it seems I have not done that for Sleepmode Param at the moment.

Quoted 10 lines

Quoted 3 lines

I notice that command 0xfc27 is used to write the sleep_params. Does anyone know the command to read them so that we can check the defaults Apple is using and find out if they can be optimized?

the Read Sleepmode Param is 0xfc28 and requires no parameters. You can check monitor/broadcom.c for a bunch of these commands since btmon will decode them for you if possible. Might want to actually post the btmon log of the init sequence here for reference (just blacklist the module and load it manually after starting btmon).

Quoted 3 lines

I thought that I created a Broadcom specific init that reads most of the standard values so we have them for reference in the btmon logs. However it seems I have not done that for Sleepmode Param at the moment.

Thanks!

I've now been able to dig up v1.6 of the Laird SD40 firmware datasheet.

There's an incongruence between the datasheet and struct bcm_set_sleep_mode (as declared in drivers/bluetooth/btbcm.h and hci_bcm.c) wherein the order of pulsed_host_wake and break_to_host is reversed.

The datasheet is dated Oct 2015, so fairly recent, making it appear more likely that the datasheet is correct and our code is wrong?

do you have a link to the data sheet?

There is already a bcm_gpio_set_power() helper to toggle the power enable pin. Add a corresponding helper to toggle the device wake pin. This will allow us to more easily integrate support for MacBooks which use custom ACPI methods to access both pins.

The only functional change here is an additional 15 ms delay when toggling the device wake pin in bcm_gpio_set_power(). It is unclear why
this delay is observed in bcm_suspend_device() and bcm_resume_device(),
but not in bcm_gpio_set_power() so far.

The host wake IRQ is optional, but if none is found, "BCM irq: -22" is logged which may irritate users. This is really a debug message, so use
dev_dbg() instead of dev_info(). If users are interested in the IRQ, they can always consult /proc/interrupts.

Cc Frédéric Danis <[email protected]>

Signed-off-by Lukas Wunner <[email protected]>

---
 drivers/bluetooth/hci_bcm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/bluetooth/hci_bcm.c +0 -0

index 01d0943b7bbb..632939d413df 100644

drivers/bluetooth/hci_bcm.c +0 -0

 	return 0;
 }

drivers/bluetooth/hci_bcm.c static int bcm_get_resources(struct bcm_device · line 802

Quoted 7 lines · Lukas Wunner

drivers/bluetooth/hci_bcm.c +1 -1

@@ -798,7 +798,7 @@ static int bcm_get_resources(struct bcm_device
 *dev)
 		dev->irq = gpiod_to_irq(gpio);
 	}
 
-	dev_info(dev->dev, "BCM irq: %d\n", dev->irq);
+	dev_dbg(dev->dev, "BCM irq: %d\n", dev->irq);

Perhaps, instead you may add same check

if (dev->irq > 0)
dev_info(...);
else
dev_info(..., "BCM irq not in use\n");

?

Quoted 7 lines · Andy Shevchenko

drivers/bluetooth/hci_bcm.c static int bcm_get_resources(struct bcm_device *dev) · line 801

Quoted 2 lines · Lukas Wunner

drivers/bluetooth/hci_bcm.c +1 -1

-	dev_info(dev->dev, "BCM irq: %d\n", dev->irq);
+	dev_dbg(dev->dev, "BCM irq: %d\n", dev->irq);

Perhaps, instead you may add same check

Quoted 4 lines

if (dev->irq > 0)
dev_info(...);
else
dev_info(..., "BCM irq not in use\n");

gpiod_to_irq() returns different negative errnos depending on the exact
error condition. We wouldn't be able to easily differentiate them if we do it this way.

A significant portion of this driver lacks error handling. As a first step, add error paths to bcm_gpio_set_power(), bcm_open(), bcm_close(),
bcm_suspend_device(), bcm_resume_device(), bcm_resume(), bcm_probe() and
bcm_serdev_probe(). (I've also scrutinized bcm_suspend() but think it's
fine as is.)

Those are all the functions accessing the device wake and shutdown GPIO.
On Apple Macs the pins are accessed through ACPI methods, which may fail
for various reasons, hence proper error handling is necessary. Non- Macs
access the pins directly, which may fail as well but the GPIO core does
not yet pass back errors to consumers.

drivers/bluetooth/hci_bcm.c +6 -0

+
+	if (powered && !IS_ERR(dev->clk) && !dev->clk_enabled) {
+		err = clk_prepare_enable(dev->clk);
+		if (err)
+			return err;
+	}

Review

Quoted 1 line · Lukas Wunner

(quoted diff) +1 -0

+	int err = 0;

Obviously redundant assignment.

drivers/bluetooth/hci_bcm.c static int bcm_open(struct hci_uart *hu) · line 404

Quoted 3 lines

drivers/bluetooth/hci_bcm.c +3 -0

+#ifdef CONFIG_PM
+	bcm->dev->hu = NULL;
+#endif

Hmm... There is no field in !PM case?

Quoted 4 lines · Andy Shevchenko

Review

Quoted 1 line · Lukas Wunner

(quoted diff) +1 -0

+	int err = 0;

Obviously redundant assignment.

No, you need to look at it in the context of patch [10/10], which changes
the following portion of bcm_gpio_set_power():

(quoted diff) +6 -1

-	gpiod_set_value(dev->shutdown, powered);
+	if (x86_apple_machine)
+		err = bcm_apple_set_power(dev, powered);
+	else
+		gpiod_set_value(dev->shutdown, powered);
+	if (err)
+		goto err_clk_disable;

I need to set err = 0 in case the gpiod_set_value() code path is chosen.

Of course I could only declare "int err;" in this patch and change it to
"int err = 0;" in the next patch, but then I would expect an objection along the lines of: You're changing code you've just added in the prior
patch, this is silly.

Long term the gpio API will be changed such that gpiod_set_value() returns a negative errno or 0 (instead of void), as we're already doing for gpiod_get_value(). *Then* I can change this to declare "int err;" and set "err = gpiod_set_value(...)".

Enable Bluetooth on the following Macs which provide custom ACPI methods to toggle the GPIOs for device wake and shutdown instead of accessing the pins directly:

   MacBook8,1     2015  12"
   MacBook9,1     2016  12"
   MacBook10,1    2017  12"
   MacBookPro13,1 2016  13"
   MacBookPro13,2 2016  13" with Touch Bar
   MacBookPro13,3 2016  15" with Touch Bar
   MacBookPro14,1 2017  13"
   MacBookPro14,2 2017  13" with Touch Bar
   MacBookPro14,3 2017  15" with Touch Bar

On the MacBook8,1 Bluetooth is muxed with a second device (a debug port on the SSD) under the control of PCH GPIO 36. Because serdev cannot deal with multiple slaves yet, it is currently necessary to patch the DSDT and remove the SSDC device.

The custom ACPI methods are called:

BTLP (Low Power) takes one argument, toggles device wake GPIO BTPU (Power Up) tells SMC to drive shutdown GPIO high BTPD (Power Down) tells SMC to drive shutdown GPIO low BTRS (Reset) calls BTPD followed by BTPU
BTRB unknown, not present on all MacBooks

Search for the BTLP, BTPU and BTPD methods on ->probe and cache them in struct bcm_device if the machine is a Mac.

Additionally, set the init_speed based on a custom device property provided by Apple in lieu of _CRS resources. The Broadcom UART's speed is fixed on Apple Macs: Any attempt to change it results in Bluetooth status code 0x0c and bcm_set_baudrate() thus always returns -EBUSY. By setting only the init_speed and leaving oper_speed at zero, we can achieve that the host UART's speed is adjusted but the Broadcom UART's speed is left as is.

The host wake pin goes into the SMC which handles it independently of the OS, so there's no IRQ for it.

Thanks to Ronald Tschalär who did extensive debugging and testing of this patch and contributed fixes.

ACPI snippet containing the custom methods and device properties (taken from a MacBook8,1):

   Method (BTLP, 1, Serialized)
   {
       If (LEqual (Arg0, 0x00))
       {
           Store (0x01, GD54) /* set PCH GPIO 54 direction to input */
       }

       If (LEqual (Arg0, 0x01))
       {
           Store (0x00, GD54) /* set PCH GPIO 54 direction to output */
           Store (0x00, GP54) /* set PCH GPIO 54 value to low */
       }

}

   Method (BTPU, 0, Serialized)
   {
       Store (0x01, \_SB.PCI0.LPCB.EC.BTPC)
       Sleep (0x0A)
   }

   Method (BTPD, 0, Serialized)
   {
       Store (0x00, \_SB.PCI0.LPCB.EC.BTPC)
       Sleep (0x0A)
   }

   Method (BTRS, 0, Serialized)
   {
       BTPD ()
       BTPU ()
   }

   Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
   {
       If (LEqual (Arg0, ToUUID ("a0b5b7c6-1318-441c-b0c9-fe695eaf949b")))
       {
           Store (Package (0x08)
               {
                   "baud",
                   Buffer (0x08)
                   { 0xC0, 0xC6, 0x2D, 0x00, 0x00, 0x00, 0x00, 0x00 },

                   "parity",
                   Buffer (0x08)
                   { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 },

                   "dataBits",
                   Buffer (0x08)
                   { 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 },

                   "stopBits",
                   Buffer (0x08)
                   { 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }
               }, Local0)
           DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
           Return (Local0)
       }
       Return (0x00)

}

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=110901

Reported-by Leif Liddy <[email protected]>

Cc Mika Westerberg <[email protected]>

Cc Andy Shevchenko <[email protected]>

Cc Frédéric Danis <[email protected]>

Cc Loic Poulain <[email protected]>

Cc Hans de Goede <[email protected]>

Tested-by Max Shavrick <[email protected]> [MacBook8,1]

Tested-by Leif Liddy <[email protected]> [MacBook9,1]

Tested-by Daniel Roschka <[email protected]> [MacBookPro13,2]

Tested-by Ronald Tschalär <[email protected]> [MacBookPro13,3]

Tested-by Peter Y. Chuang <[email protected]> [MacBookPro14,1]

Signed-off-by Ronald Tschalär <[email protected]>

Signed-off-by Lukas Wunner <[email protected]>

---
Changes since v1:
add DSDT excerpt to the commit message,
drop ternary operators for readability,
return -EIO instead of -EFAULT if ACPI method calls fail, return -EOPNOTSUPP in inline stubs,
use network subsystem comment style. (Marcel, Hans, Andy) Also, to accommodate to mandatory presence of the two GPIOs as per patch [2/10], rename bcm_apple_probe() to bcm_apple_get_resources() and call it from bcm_get_resources() instead of bcm_acpi_probe().

drivers/bluetooth/hci_bcm.c | 76 +++++++++++++++++++++++++++++++++++++++++++--

1 file changed, 74 insertions(+), 2 deletions(-)

drivers/bluetooth/hci_bcm.c +1 -0

index ad6b7c35eb8e..4e0ba38d39d2 100644
@@ -29,6 +29,7 @@
 #include <linux/acpi.h>
 #include <linux/of.h>
 #include <linux/property.h>
+#include <linux/platform_data/x86/apple.h>
 #include <linux/platform_device.h>
 #include <linux/clk.h>
 #include <linux/gpio/consumer.h>

Enable Bluetooth on the following Macs which provide custom ACPI methods
to toggle the GPIOs for device wake and shutdown instead of accessing the pins directly:

drivers/bluetooth/hci_bcm.c +3 -0

+static inline int bcm_apple_get_resources(struct bcm_device *dev)
+{ return -EOPNOTSUPP; }
+static inline int bcm_apple_set_power(struct bcm_device *dev, bool

powered)

(quoted diff) +2 -0

+{ return -EOPNOTSUPP; }
+static inline int bcm_apple_set_low_power(struct bcm_device *dev,

bool enable)
+{ return -EOPNOTSUPP; }