summaryrefslogtreecommitdiff
path: root/drivers/bluetooth/hci_bcm.c
AgeCommit message (Collapse)Author
2018-12-19Bluetooth: hci_bcm: Handle specific unknown packets after firmware loadingJonathan Bakker
The Broadcom controller on aries S5PV210 boards sends out a couple of unknown packets after the firmware is loaded. This will cause logging of errors such as: Bluetooth: hci0: Frame reassembly failed (-84) This is probably also the case with other boards, as there are related Android userspace patches for custom ROMs such as https://review.lineageos.org/#/c/LineageOS/android_system_bt/+/142721/ Since this appears to be intended behaviour, treated them as diagnostic packets. Note that this is another variant of commit 01d5e44ace8a ("Bluetooth: hci_bcm: Handle empty packet after firmware loading") Signed-off-by: Jonathan Bakker <xc-racer2@live.ca> Signed-off-by: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-12-19Bluetooth: hci_bcm: Add compatible string for BCM4330Chen-Yu Tsai
The BCM4330 chip is a 802.11 a/b/g/n + Bluetooth 4.0 + HS controller. This patch adds a compatible string match to the serdev driver for the Bluetooth part of the chip. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-12-19Bluetooth: hci_bcm: Add BCM20702A1 variantMaxime Ripard
The BCM20702A1 chip is a single-chip Bluetooth 4.0 controller and transceiver. It is found in the AMPAK AP6210 WiFi+BT package. Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Tested-by: Ondrej Jirman <megous@megous.com> Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-12-19Bluetooth: hci_bcm: Wait for device to come out of reset after power onChen-Yu Tsai
The datasheets for BCM20702 and BCM43438 both have power up time sequence graphs, however they are slightly different. Both chips also have an internal power-on-reset, which holds the chip in reset for a short time after the regulators are enabled. For the BCM20702, the time period from when the regulators are enabled, until the chip settles and comes out of sleep state, is 6564 ~ 8171 us. For the BCM43438, the graph only shows the time period from when the regulators are enabled until the chip responds by driving the host's CTS line low, assuming the host has already driven its RTS line low. This is shown to be 6.5 sleep cycles, with the sleep clock at 32.768 kHz. This is around 2 ms. Wait a full 10 ms after the regulators are enabled to account for signal rising times. Tested-by: Ondrej Jirman <megous@megous.com> Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-12-19Bluetooth: hci_bcm: Add support for regulator suppliesChen-Yu Tsai
The Broadcom Bluetooth chips have two power inputs, VBAT and VDDIO. The former provides overall power for the chip, while the latter powers the I/O pins and buffers. Model these two as regulator supplies, and let the driver manage them in the same way as it does the clock supply. Tested-by: Ondrej Jirman <megous@megous.com> Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-12-19Bluetooth: hci_bcm: Add support for LPO clockChen-Yu Tsai
The Broadcom Bluetooth controllers support a secondary LPO clock at 32.768 kHz. This external clock provides low power timing, and also a way to detect the frequency of the main reference clock. On many designs without NVRAM and a non-default reference clock, this must be used or the controller will not function correctly. Tested-by: Ondrej Jirman <megous@megous.com> Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-12-19Bluetooth: hci_bcm: Use "txco" and "extclk" to get clock referenceChen-Yu Tsai
Originally the device tree binding only specified one clock reference, with the name "extclk". The driver simply retrieves the clock without bothering to specify a name. Since we added a second clock to the binding, we need to fetch the clocks by name now. First we try the new name "txco", then fall back to the old name "extclk", and finally try retrieving a clock without using any name, to cover any instances where a bad device tree or firmware worked by accident. In the last case, we should take care that we don't get the same clock twice when we add support for the "lpo" clock. Tested-by: Ondrej Jirman <megous@megous.com> Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-12-19Bluetooth: hci_bcm: Simplify clk_get error handlingChen-Yu Tsai
The driver currently checks the clk pointer for an error condition, as returned by clk_get, before every invocation of the clk consumer API. This is redundant if the goal is simply to ignore the errors, thereby making the clk optional. The clk consumer API already checks if the pointer is NULL or not. Simplify the code a bit by assigning NULL to the clk pointer if the error condition is one we want to ignore, which is every error except deferred probing. Tested-by: Ondrej Jirman <megous@megous.com> Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-12-19Bluetooth: hci_bcm: Handle deferred probing for the clock supplyChen-Yu Tsai
On some systems that actually have the bluetooth controller wired up with an extra clock signal, it's possible the bluetooth controller probes before the clock provider. clk_get would return a defer probe error, which was not handled by this driver. Handle this properly, so that these systems can work reliably. Tested-by: Ondrej Jirman <megous@megous.com> Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-05-30Bluetooth: hci_serdev: Move serdev_device_close/open into common hci_serdev codeHans de Goede
Make hci_uart_register_device() and hci_uart_unregister_device() call serdev_device_close()/open() themselves instead of relying on the various hci_uart drivers to do this for them. Besides reducing code complexity, this also ensures correct error checking of serdev_device_open(), which was missing in a few drivers. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-05-18Bluetooth: btbcm: Allow using btbcm_initialize() for reinitHans de Goede
btbcm_finalize() does a re-init of the controller, which is almost the same as the initial init. Modify btbcm_initialize() so that it can be used for this re-init and modify btbcm_finalize() to use it. As an added bonus this also makes the dev_info from btbcm_finalize() use the proper hw_name instead of always printing "BCM". Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-05-18Bluetooth: hci_bcm: Remove irq-active-low DMI quirk for the Thinkpad 8Hans de Goede
Interrupts specified through an "Interrupt" ACPI resource (versus through a "GpioInt" resource) are now always assumed to be active low. When this change was originally made the Thinkpad 8 quirk was kept around because it was uncertain if the Thinkpad 8 uses an "Interrupt" or a "GpioInt" resource. Bug https://bugzilla.kernel.org/show_bug.cgi?id=196701 has a DSDT for the Thinkpad 8 attached and it uses an "Interrupt" resource, so the quirk is not necessary and the quirk, as well as the irq-active-low quirk handling code can be removed. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-05-18Bluetooth: hci_bcm: Add broken-irq dmi blacklist and add Meegopad T08 to itHans de Goede
The Meegopad T08 hdmi-stick (think Intel computestick) has a brcm43430 wifi/bt combo chip. The BCM2E90 ACPI device describing the BT part does contain a valid ActiveLow GpioInt entry, but the GPIO it points to never goes low, so either the IRQ pin is not connected, or the ACPI resource- table points to the wrong GPIO. Eitherway things will not work if we try to use the specified IRQ, this commits adds a DMI based broken-irq blacklist and disables use of the IRQ and thus also runtime-pm for devices on this list. This blacklist starts with the the Meegopad T08, fixing bluetooth not working on this hdmi-stick. Since this is not a battery powered device the loss of runtime-pm is not really an issue. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-04-01Bluetooth: hci_bcm: Remove DMI quirk for the MINIX Z83-4Ian W MORRISON
As Interrupt resource specified IRQs are now assumed to be always active-low the DMI quirk for the MINIX Z83-4 is no longer required. Signed-off-by: Ian W MORRISON <ianwmorrison@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-04-01Bluetooth: hci_bcm: Add ACPI HIDs found in Windows .inf files and DSTDsHans de Goede
Now that we need just an ACPI HID in the table, and the driver auto- configures itself otherwise, we can easily add a bunch of known ACPI HIDs. This avoids having to add these 1 by 1 as devices with one are encountered by users. This commit may seem as if it simply adds all IDs between BCM2E00-BCM2EAC, but that is not true, all these IDs were found in actual .inf files and the range is not entirely continuous, the following IDs are not added: BCM2E6A, BCM2E6C, BCM2E8F and BCM2E91 because I did not see these in any .inf files. As for the large amount of IDs this seems to be caused by Broadcom using a separate ID for every bluetooth module using their chips. E.g. BCM2EA6 seems to be specifically for the Raspberry Pi 3. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-04-01Bluetooth: hci_bcm: Do not tie GPIO pin order to a specific ACPI HIDHans de Goede
Since I've been doing a lot of work on Linux Bay Trail / Cherry Trail support, I've gathered a collection of ACPI DSDTs from about 50 such machines. Looking at these DSTDs many have an ACPI device entry describing a bcm bluetooth device (often disabled in the DSDT), quite a few of these ACPI device entries have a resource-table where the order does not match with the order currently associated with the HID of that entry in the bcm_acpi_match table. Looking at the Windows .inf files, there is nothing indicating a specific order there, so I believe that there is no 1:1 mapping between the ACPI HID and the order in which the resources are listed. Therefor this commit replaces the hardcoded mapping based on ACPI HID, with code which actually checks in which order the resources are listed and bases the gpio-mapping on that. This should ensure that we always pick the right mapping and this will make adding new ACPI HIDs to the driver easier. This has been tested on the following devices: -Asus T100CHI BCM2E39 / brcmfmac43241b4-sdio / BCM4324B3-37.4M.hcd -Asus T100TA BCM2E39 / brcmfmac43241b4-sdio / BCM4324B3-37.4M.hcd -Asus T200TA BCM2E65 / brcmfmac43340-sdio / BCM43341B0-37.4M.hcd -Jumper ezPad mini 3 BCM2E74 / brcmfmac43430a0-sdio / BCM4343A0-26M.hcd -Acer Iconia Tab8 w1-8 BCM2E83 / brcmfmac4330-sdio / BCM4330B1-26M.hcd -Chuwi Vi8 plus(CWI519) BCM2EAA / brcmfmac43430-sdio / BCM43430A1-26M.hcd Which together cover all 3 combinations of using an Interrupt resource / GpioInt resource as first resource / GpioInt resource as last resource. Tested-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-04-01Bluetooth: hci_bcm: Remove duplication in gpio-mappings declarationHans de Goede
We declare the same set of const acpi_gpio_params twice with different names, besides the needless duplication this naming leads to a sortof double indirection which also makes it harder to see how the mapping is actually setup. This commit renames the first set to have generic names, which better describe the contents of the mapping and drops the second set. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-04-01Bluetooth: hci_bcm: Add 6 new ACPI HIDsHans de Goede
Add 6 new ACPI HIDs to enable bluetooth on devices using these HIDs, I've tested the following HIDs / devices: BCM2E74: Jumper ezPad mini 3 BCM2E83: Acer Iconia Tab8 w1-810 BCM2E90: Meegopad T08 BCM2EAA: Chuwi Vi8 plus (CWI519) The reporter of Red Hat bugzilla 1554835 has tested: BCM2E84: Lenovo Yoga2 The reporter of kernel bugzilla 274481 has tested: BCM2E38: Toshiba Encore Note the Lenovo Yoga2 and Toshiba Encore also needs the earlier patch to treat all Interrupt ACPI resources as active low. Cc: stable@vger.kernel.org Buglink: https://bugzilla.kernel.org/attachment.cgi?id=274481 Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1554835 Reported-and-tested-by: Robert R. Howell <rhowell@uwyo.edu> Reported-and-tested-by: Christian Herzog <daduke@daduke.org> Tested-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-04-01Bluetooth: hci_bcm: Treat Interrupt ACPI resources as always being active-lowHans de Goede
Older devices with a serdev attached bcm bt hci, use an Interrupt ACPI resource to describe the IRQ (rather then a GpioInt resource). These device seem to all claim the IRQ is active-high and seem to all need a DMI quirk to treat it as active-low. Instead simply always assume that Interrupt resource specified IRQs are always active-low. This fixes the bt device not being able to wake the host from runtime- suspend on the: Asus T100TAM, Asus T200TA, Lenovo Yoga2 and the Toshiba Encore, without the need to add 4 new DMI quirks for these models. This also allows us to remove 2 DMI quirks for the Asus T100TA and Asus T100CHI series. Likely the 2 remaining quirks can also be removed but I could not find a DSDT of these devices to verify this. Cc: stable@vger.kernel.org Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=198953 Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1554835 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-04-01Bluetooth: hci_bcm: Add irq_polarity module optionHans de Goede
Add irq_polarity module option for easier troubleshooting of irq-polarity issues. Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-04-01Bluetooth: hci_bcm: Use default baud rate if missing shutdown GPIOMarcel Holtmann
In case the shutdown GPIO is not wired up, it is impossible to reset the Bluetooth controller to its original state. This include the initial default baud rate which leads to issues when reloading the module or when something unexpected happens. To avoid any kind of runtime deadlocks, stick with the initial default baud rate. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2018-04-01Bluetooth: hci_bcm: use gpiod cansleep versionLoic Poulain
Some GPIO controller drivers request sleepable context and so can't be accessed from IRQ context. Using gpiod_set/get_value accessors with such controller leads to a kernel warning since they are reserved for atomic context (according to the documentation). Use the postfixed _cansleep version instead, indicating that context is safe for sleeping if necessary. Note that this is the case here since we never toggle the gpio neither from IRQ nor from a spinlocked section. Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-03-15Bluetooth: hci_bcm: Set pulsed_host_wake flag in sleep parametersHans de Goede
The IRQ output of the bcm bt-device is really a level IRQ signal, which signals a logical high as long as the device's buffer contains data. Since the draining in the buffer is done in the tty driver, we cannot (easily) wait in a threaded interrupt handler for the draining, after which the IRQ should go low again. So instead we treat the IRQ as an edge interrupt. This opens the window for a theoretical race where we wakeup, read some data and then autosuspend *before* the IRQ has gone (logical) low, followed by the device just at that moment receiving more data, causing the IRQ to stay high and we never see an edge. Since we call pm_runtime_mark_last_busy() on every received byte, there should be plenty time for the IRQ to go (logical) low before we ever suspend, so this should never happen, but after commit 43fff7683468 ("Bluetooth: hci_bcm: Streamline runtime PM code"), which has been reverted since, this was actually happening causing the device to get stuck in runtime suspend. The bcm bt-device actually has a workaround for this, if we set the pulsed_host_wake flag in the sleep parameters, then the device monitors if the host is draining the buffer and if not then after a timeout the device will pulse the IRQ line, causing us to see an edge, fixing the stuck in suspend condition. This commit sets the pulsed_host_wake flag to fix the (mostly theoretical) race caused by us treating the IRQ as an edge IRQ. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-03-15Revert "Bluetooth: hci_bcm: Streamline runtime PM code"Hans de Goede
This reverts commit 43fff7683468 ("Bluetooth: hci_bcm: Streamline runtime PM code"). The commit msg for this commit states "No functional change intended.", but replacing: pm_runtime_get(); pm_runtime_mark_last_busy(); pm_runtime_put_autosuspend(); with: pm_request_resume(); Does result in a functional change, pm_request_resume() only calls pm_runtime_mark_last_busy() if the device was suspended before the call. This results in the following happening: 1) Device is runtime suspended 2) Device drives host_wake IRQ logically high as it starts receiving data 3) bcm_host_wake() gets called, causes the device to runtime-resume, current time gets marked as last_busy time 4) After 5 seconds the autosuspend timer expires and the dev autosuspends as no one has been calling pm_runtime_mark_last_busy(), the device was resumed during those 5 seconds, so all the pm_request_resume() calls while receiving data and/or bcm_host_wake() calls were nops 5) If 4) happens while the device has (just received) data in its buffer to be read by the host the IRQ line is *already* / still logically high when we autosuspend and since we use an edge triggered IRQ, the IRQ will never trigger, causing the device to get stuck in suspend Therefor this commit has to be reverted, so that we avoid the device getting stuck in suspend. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-02-25Bluetooth: hci_bcm: Make shutdown and device wake GPIO optionalStefan Wahren
According to the devicetree binding the shutdown and device wake GPIOs are optional. Since commit 3e81a4ca51a1 ("Bluetooth: hci_bcm: Mandate presence of shutdown and device wake GPIO") this driver won't probe anymore on Raspberry Pi 3 and Zero W (no device wake GPIO connected). So fix this regression by reverting this commit partially. Fixes: 3e81a4ca51a1 ("Bluetooth: hci_bcm: Mandate presence of shutdown and device wake GPIO") Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-01-22Bluetooth: hci_bcm: For serdev case close serdev on failure to set powerHans de Goede
Commit 8bfa7e1e03ac ("Bluetooth: hci_bcm: Handle errors properly") introduced error checking for the bcm_gpio_set_power() call in bcm_open() but the error-path it introduces unsets dev->hu, which is correct for platform_device instantiated bcm_dev-s but not for serdev instantiated devs. For serdev instantiated devs serdev_device_close() should be called instead (and dev->hu should be left set). Cc: Lukas Wunner <lukas@wunner.de> Fixes: 8bfa7e1e03ac ("Bluetooth: hci_bcm: Handle errors properly") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-01-10Bluetooth: btbcm: Fix sleep mode struct orderingLukas Wunner
According to the documentation for Laird SD40 radio modules (which use the BCM4329 chipset), the order of the Enable_BREAK_To_Host and Pulsed_HOST_WAKE parameters in the sleep mode struct is reversed vis-à-vis our struct declaration. See page 46 of this PDF: http://cdn.lairdtech.com/home/brandworld/files/Application%20Note%20-%2040%20Series%20Bluetooth.pdf The documentation is dated Oct 2015, so fairly recent, making it appear more likely that the documentation is correct and our code is wrong. Amend our code to be in congruence with the documentation. Cc: Sue White <sue.white@lairdtech.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-01-10Bluetooth: hci_bcm: Sleep instead of spinningLukas Wunner
The driver calls mdelay(15) in the ->suspend, ->resume, ->runtime_suspend and ->runtime_resume hook, however spinning for such a long period of time is discouraged as per Documentation/timers/timers-howto.txt. The use of mdelay() seems unnecessary, it is allowed to sleep in the system sleep and runtime PM hooks (with the exception of ->suspend_noirq and ->resume_noirq) and the driver itself also does not rely on a non-sleeping ->runtime_resume as the only place where a synchronous resume is performed, in bcm_dequeue(), is called from a work item in hci_ldisc.c and hci_serdev.c. So replace the mdelay(15) with msleep(15). Note that the delay is inserted after asserting or deasserting the device wake pin, but in bcm_gpio_set_power() that pin is asserted or deasserted *without* observing a delay. It is thus unclear if the delay is necessary at all. It is likewise unclear why it is exactly 15 ms, the commit introducing it, 118612fb9165 ("Bluetooth: hci_bcm: Add suspend/resume PM functions"), does not provide a rationale. Cc: Frédéric Danis <frederic.danis.oss@gmail.com> Suggested-and-reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-01-10Bluetooth: hci_bcm: Silence IRQ printkLukas Wunner
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 <frederic.danis.oss@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-01-10Bluetooth: hci_bcm: Support Apple GPIO handlingLukas Wunner
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) } Link: https://github.com/Dunedan/mbp-2016-linux/issues/29 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=110901 Reported-by: Leif Liddy <leif.liddy@gmail.com> Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Frédéric Danis <frederic.danis.oss@gmail.com> Cc: Loic Poulain <loic.poulain@linaro.org> Cc: Hans de Goede <hdegoede@redhat.com> Tested-by: Max Shavrick <mxms@me.com> [MacBook8,1] Tested-by: Leif Liddy <leif.liddy@gmail.com> [MacBook9,1] Tested-by: Daniel Roschka <danielroschka@phoenitydawn.de> [MacBookPro13,2] Tested-by: Ronald Tschalär <ronald@innovation.ch> [MacBookPro13,3] Tested-by: Peter Y. Chuang <peteryuchuang@gmail.com> [MacBookPro14,1] Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Ronald Tschalär <ronald@innovation.ch> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-01-10Bluetooth: hci_bcm: Handle errors properlyLukas Wunner
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. Cc: Frédéric Danis <frederic.danis.oss@gmail.com> Cc: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-01-10Bluetooth: hci_bcm: Add callbacks to toggle GPIOsLukas Wunner
MacBooks provides custom ACPI methods to toggle the GPIOs for device wake and shutdown instead of accessing the pins directly. Prepare for their support by adding callbacks to toggle the GPIOs, which on non-Macs do nothing more but call gpiod_set_value(). No functional change intended. Suggested-and-reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-01-10Bluetooth: hci_bcm: Document struct bcm_deviceLukas Wunner
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-01-10Bluetooth: hci_bcm: Invalidate IRQ on request failureLukas Wunner
If devm_request_irq() fails, the driver bails out of bcm_request_irq() but continues to ->setup the device (because the IRQ is optional). The driver subsequently calls devm_free_irq(), enable_irq_wake() and disable_irq_wake() on the IRQ even though requesting it failed. Avoid by invalidating the IRQ on request failure. Cc: Frédéric Danis <frederic.danis.oss@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-01-10Bluetooth: hci_bcm: Fix unbalanced pm_runtime_disable()Lukas Wunner
On ->setup, pm_runtime_enable() is only called if a valid IRQ was found, but on ->close(), pm_runtime_disable() is called unconditionally. Disablement of runtime PM is recorded in a counter, so every pm_runtime_disable() needs to be balanced. Fix it. Cc: Frédéric Danis <frederic.danis.oss@gmail.com> Reported-and-reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-01-10Bluetooth: hci_bcm: Fix race on closeLukas Wunner
Upon ->close, the driver powers the Bluetooth controller down, deasserts the device wake pin, updates the runtime PM status to "suspended" and finally frees the IRQ. Because the IRQ is freed last, a runtime resume can take place after the controller was powered down. The impact is not grave, the worst thing that can happen is that the device wake pin is reasserted (should have no effect while the regulator is off) and that setting the runtime PM status to "suspended" does not reflect reality. Still, it's wrong, so free the IRQ first. Cc: Frédéric Danis <frederic.danis.oss@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-01-10Bluetooth: hci_bcm: Clean up unnecessary #ifdefLukas Wunner
pm_runtime_disable() and pm_runtime_set_suspended() are replaced with empty inlines if CONFIG_PM is disabled, so there's no need to #ifdef them. device_init_wakeup() is likewise replaced with an inline, though it's not empty, but it and devm_free_irq() can be made conditional on IS_ENABLED(CONFIG_PM), which is preferable to #ifdef as per section 20 of Documentation/process/coding-style.rst. Cc: Frédéric Danis <frederic.danis.oss@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-01-10Bluetooth: hci_bcm: Validate IRQ before using itRonald Tschalär
The ->close, ->suspend and ->resume hooks assume presence of a valid IRQ if the device is wakeup capable. However it's entirely possible that wakeup was enabled by some other entity besides this driver and in this case the user will get a WARN splat if no valid IRQ was found. Avoid by checking if the IRQ is valid, i.e. > 0. Case in point: On recent MacBook Pros, the Bluetooth device lacks an IRQ (because host wakeup is handled by the SMC, independently of the operating system), but it does possess a _PRW method (which specifies the SMC's GPE as wake event). The ACPI core therefore automatically marks the physical Bluetooth device wakeup capable upon binding it to its ACPI companion: device_set_wakeup_capable+0x96/0xb0 acpi_bind_one+0x28a/0x310 acpi_platform_notify+0x20/0xa0 device_add+0x215/0x690 serdev_device_add+0x57/0xf0 acpi_serdev_add_device+0xc9/0x110 acpi_ns_walk_namespace+0x131/0x280 acpi_walk_namespace+0xf5/0x13d serdev_controller_add+0x6f/0x110 serdev_tty_port_register+0x98/0xf0 tty_port_register_device_attr_serdev+0x3a/0x70 uart_add_one_port+0x268/0x500 serial8250_register_8250_port+0x32e/0x490 dw8250_probe+0x46c/0x720 platform_drv_probe+0x35/0x90 driver_probe_device+0x300/0x450 bus_for_each_drv+0x67/0xb0 __device_attach+0xde/0x160 bus_probe_device+0x9c/0xb0 device_add+0x448/0x690 platform_device_add+0x10e/0x260 mfd_add_device+0x392/0x4c0 mfd_add_devices+0xb1/0x110 intel_lpss_probe+0x2a9/0x610 [intel_lpss] intel_lpss_pci_probe+0x7a/0xa8 [intel_lpss_pci] Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Ronald Tschalär <ronald@innovation.ch> [lukas: fix up ->suspend and ->resume as well, add commit message] Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-01-10Bluetooth: hci_bcm: Mandate presence of shutdown and device wake GPIOLukas Wunner
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 <frederic.danis.oss@gmail.com> Cc: Loic Poulain <loic.poulain@linaro.org> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Cc: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2017-12-26Bluetooth: hci_bcm: Streamline runtime PM codeLukas Wunner
This driver seeks to force the Bluetooth device on for the duration of 5 seconds when the Bluetooth device has woken the host and after a complete packet has been received. It does that by calling: pm_runtime_get(); pm_runtime_mark_last_busy(); pm_runtime_put_autosuspend(); The same can be achieved more succinctly with: pm_request_resume(); That's because after runtime resuming the device, rpm_resume() invokes pm_runtime_mark_last_busy() followed by rpm_idle(), which will cause the device to be suspended after expiration of the autosuspend_delay. No functional change intended. Cc: Frédéric Danis <frederic.danis.oss@gmail.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2017-12-13Bluetooth: hci_bcm: Add support for BCM2E72Hans de Goede
The Asus T100HA laptop uses an ACPI HID of BCM2E72 for the bluetooth part of the SDIO bcm43340 wifi/bt combo chip. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2017-10-14Bluetooth: hci_bcm: Add support for BCM2E7EHans de Goede
Tested on a GPD win with a BCM4356 PCI-E wifi/bt combo card. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2017-10-11Bluetooth: hci_bcm: fix build error without CONFIG_PMArnd Bergmann
This was introduced by the rework adding PM support: drivers/bluetooth/hci_bcm.c: In function 'bcm_device_exists': drivers/bluetooth/hci_bcm.c:156:22: error: 'struct bcm_device' has no member named 'hu' if (device && device->hu && device->hu->serdev) ^~ The pointer is not available otherwise, so I'm enclosing all references in an #ifdef here. Fixes: 8a92056837fd ("Bluetooth: hci_bcm: Add (runtime)pm support to the serdev driver") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2017-10-10Bluetooth: hci_bcm: Add support for MINIX Z83-4 based devicesIan W MORRISON
The MINIX NEO Z83-4 and MINIX NEO Z83-4 Pro devices use an AP6255 chip for wifi and bluetooth. Bluetooth requires an ACPI device id of BCM2EA4 with BCM4345 rev C0 firmware. This patch adds the device id and to use trigger type IRQF_TRIGGER_FALLING as defined by 'GpioInt' in the ACPI DSDT table: Device (BLT0) { Name (_HID, "BCM2EA4") // _HID: Hardware ID Method (_STA, 0, NotSerialized) // _STA: Status { Return (0x0F) } Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings { Name (UBUF, ResourceTemplate () { UartSerialBusV2 (0x0001C200, DataBitsEight, StopBitsOne, 0xFC, LittleEndian, ParityTypeNone, FlowControlHardware, 0x0020, 0x0020, "\\_SB.PCI0.URT1", 0x00, ResourceConsumer, , Exclusive, ) GpioInt (Level, ActiveLow, Exclusive, PullNone, 0x0000, "\\_SB.GPO1", 0x00, ResourceConsumer, , ) { // Pin list 0x0005 } GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly, "\\_SB.GPO1", 0x00, ResourceConsumer, , ) { // Pin list 0x0007 } GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly, "\\_SB.GPO1", 0x00, ResourceConsumer, , ) { // Pin list 0x0004 } }) Return (UBUF) /* \_SB_.PCI0.URT1.BLT0._CRS.UBUF */ } } Signed-off-by: Ian W MORRISON <ianwmorrison@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2017-10-09Bluetooth: hci_bcm: Correct context of IRQ polarity messageIan W MORRISON
As the overwriting of IRQ polarity to active low occurs during the driver probe using 'bt_dev_warn' to display the warning results in '(null)' being displayed for the device. This patch uses 'dev_warn' to correctly display the device in the warning instead. Signed-off-by: Ian W MORRISON <ianwmorrison@gmail.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2017-10-06Bluetooth: hci_bcm: Add (runtime)pm support to the serdev driverHans de Goede
Make the serdev driver use struct bcm_device as its driver data and share all the pm / GPIO / IRQ related code paths with the platform driver. After this commit the 2 drivers are in essence the same and the serdev driver interface can be used for all ACPI enumerated HCI UARTs. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2017-10-06Bluetooth: hci_bcm: Make suspend/resume functions platform_dev independentHans de Goede
Use dev_get_drvdata instead of platform_get_drvdata in the suspend / resume functions. This is a preparation patch for adding (runtime)pm support to the serdev path. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2017-10-06Bluetooth: hci_bcm: Make acpi_probe get irq from ACPI resourcesHans de Goede
The ACPI subsys is going to move over to instantiating ACPI enumerated HCIs as serdevs, rather then as platform devices. So we need to make bcm_acpi_probe() suitable for use on non platform- devices too, which means that we cannot rely on platform_get_irq() getting called. This commit modifies bcm_acpi_probe() to directly get the irq from the ACPI resources, this is a preparation patch for adding (runtime)pm support to the serdev path. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2017-10-06Bluetooth: hci_bcm: Rename bcm_platform_probe to bcm_get_resourcesHans de Goede
After our previous changes, there is nothing platform specific about bcm_platform_probe anymore, rename it to bcm_get_resources. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2017-10-06Bluetooth: hci_bcm: Store device pointer instead of platform_device pointerHans de Goede
The ACPI subsys is going to move over to instantiating ACPI enumerated HCIs as serdevs, rather then as platform devices. This means that the serdev driver paths of hci_bcm.c also need to start supporting (runtime)pm through GPIOs and a host-wake IRQ. The hci_bcm code is already mostly independent of how the HCI gets instantiated, but even though the code only cares about pdev->dev, it was storing pdev itself in struct bcm_device. This commit stores pdev->dev rather then pdev in struct bcm_device, this is a preparation patch for adding (runtime)pm support to the serdev path. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>