summaryrefslogtreecommitdiff
path: root/drivers/bluetooth/hci_bcm.c
AgeCommit message (Collapse)Author
2023-06-29Bluetooth: hci_bcm: do not mark valid bd_addr as invalidJohan Hovold
A recent commit restored the original (and still documented) semantics for the HCI_QUIRK_USE_BDADDR_PROPERTY quirk so that the device address is considered invalid unless an address is provided by firmware. This specifically means that this flag must only be set for devices with invalid addresses, but the Broadcom driver has so far been setting this flag unconditionally. Fortunately the driver already checks for invalid addresses during setup and sets the HCI_QUIRK_INVALID_BDADDR flag. Use this flag to indicate when the address can be overridden by firmware (long term, this should probably just always be allowed). Fixes: 6945795bc81a ("Bluetooth: fix use-bdaddr-property quirk") Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/lkml/ecef83c8-497f-4011-607b-a63c24764867@samsung.com Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-04-23Bluetooth: hci_bcm: Add Acer Iconia One 7 B1-750 to the bcm_broken_irq_dmi_tableHans de Goede
The DSDT for the Acer Iconia One 7 B1-750 models (which share the same mainboard) specifies a IOAPIC IRQ for the HCI -> host IRQ but this is not correct. Like the Asus TF103C these tablets use pin 17 of the INT33FC:02 GPIO controller for the IRQ and this pin is _not_ configured in direct IRQ mode by the firmware. Add a DMI match for this, re-using the Asus TF103C gpiod_lookup_table, to fix bluetooth not working on these tablets. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2023-04-23Bluetooth: hci_bcm: Add Lenovo Yoga Tablet 2 830 / 1050 to the ↵Hans de Goede
bcm_broken_irq_dmi_table The DSDT for the Lenovo Yoga Tablet 2 830 / 1050 models (which share the same mainboard) specifies a IOAPIC IRQ for the HCI -> host IRQ but this is not correct. Like the Asus TF103C these tablets use pin 17 of the INT33FC:02 GPIO controller for the IRQ and this pin is _not_ configured in direct IRQ mode by the firmware. Add a DMI match for this, re-using the Asus TF103C gpiod_lookup_table, to fix bluetooth not working on these tablets. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2023-04-23Bluetooth: hci_bcm: Limit bcm43430a0 / bcm43430a1 baudrate to 2000000Hans de Goede
The bcm43430a0 and bcm43430a1 BT does not support the 0xfc45 command to set the UART clock to 48 MHz and it also does not work at 4000000 baud without this command as some newer models do. These chips are found on ACPI/x86 devices where the operating baudrate does not come from the firmware but is hardcoded at 4000000, which does not work. Add a max_baudrate value to struct bcm_device_data and set this to 2000000 on all known ACPI hardware-ids for the bcm43430a0 and the bcm43430a1. Note this also adds the BCM2E9F ACPI HID which was missing until now. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2022-12-12Bluetooth: hci_bcm: Add CYW4373A0 supportMarek Vasut
CYW4373A0 is a Wi-Fi + Bluetooth combo device from Cypress. This chip is present e.g. on muRata 2AE module. This chip has additional quirk where the HCI command 0xfc45, used on older chips to switch UART clock from 24 MHz to 48 MHz, to support baudrates over 3 Mbdps, is no longer recognized by this newer chip. This newer chip can configure the 4 Mbdps baudrate without the need to issue HCI command 0xfc45, so add flag to indicate this and do not issue the command on this chip to avoid failure to set 4 Mbdps baud rate. It is not clear whether there is a way to determine which chip does and which chip does not support the HCI command 0xfc45, other than trial and error. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2022-07-21Bluetooth: hci_bcm: Increase host baudrate for CYW55572 in autobaud modeHakan Jansson
Add device specific data for max baudrate in autobaud mode. This allows the host to use a baudrate higher than "init speed" when loading FW in autobaud mode. The device specific max baudrate in autobaud mode for CYW55572 is set to 921600 bps. Devices without device specific max baudrate in autobaud mode will use init speed as before. If no device specific init speed has been specified, it will default to the bcm_proto default 115200 bps. The increased baud rate improves FW load time. The exact load time will depend on the specific system and FW being used. As a rough indication, the FW load time dropped from ~9s @ 115.2kbps to ~1.7s @ 921.6kbps in one test. Signed-off-by: Hakan Jansson <hakan.jansson@infineon.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2022-07-21Bluetooth: hci_bcm: Prevent early baudrate setting in autobaud modeHakan Jansson
Always prevent trying to set device baudrate before calling setup() when using autobaud mode. This was previously happening for devices which had device specific data with member no_early_set_baudrate set to 0. Signed-off-by: Hakan Jansson <hakan.jansson@infineon.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2022-07-21Bluetooth: hci_bcm: Add DT compatible for CYW55572Hakan Jansson
CYW55572 is a Wi-Fi + Bluetooth combo device from Infineon. Signed-off-by: Hakan Jansson <hakan.jansson@infineon.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2022-07-21Bluetooth: hci_bcm: Add BCM4349B1 variantAhmad Fatoum
The BCM4349B1, aka CYW/BCM89359, is a WiFi+BT chip and its Bluetooth portion can be controlled over serial. Two subversions are added for the chip, because ROM firmware reports 002.002.013 (at least for the chips I have here), while depending on patchram firmware revision, either 002.002.013 or 002.002.014 is reported. Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2022-07-21Bluetooth: hci_bcm: Add support for FW loading in autobaud modeHakan Jansson
Use the presence of a DT property, "brcm,requires-autobaud-mode", to enable startup in autobaud mode. If the property is present, the device is started in autobaud mode by asserting RTS (BT_UART_CTS_N) prior to powering on the device. Also prevent the use of unsupported commands for devices started in autobaud mode. Only a limited subset of HCI commands are supported in autobaud mode. Some devices (e.g. CYW5557x) require autobaud mode to enable FW loading. Autobaud mode can also be required on some boards where the controller device is using a non-standard baud rate in normal mode when first powered on. Signed-off-by: Hakan Jansson <hakan.jansson@infineon.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2022-03-18Bluetooth: hci_bcm: Add the Asus TF103C to the bcm_broken_irq_dmi_tableHans de Goede
The DSDT for the Asus TF103C specifies a IOAPIC IRQ for the HCI -> host IRQ but this is not correct. Unlike the previous entries in the table, this time the correct GPIO to use instead is known; and the TF103C is battery powered making runtime-pm support more important. Extend the bcm_broken_irq_dmi_table mechanism to allow specifying the right GPIO instead of just always disabling runtime-pm and add an entry to it for the Asus TF103C. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2022-03-04Bluetooth: hci_bcm: add BCM43430A0 & BCM43430A1Luca Weiss
Add the compatible for BCM43430A0 bluetooth used in lg-lenok and BCM43430A1 used in asus-sparrow. Signed-off-by: Luca Weiss <luca@z3ntu.xyz> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2022-01-06Bluetooth: hci_bcm: Check for error irqJiasheng Jiang
For the possible failure of the platform_get_irq(), the returned irq could be error number and will finally cause the failure of the request_irq(). Consider that platform_get_irq() can now in certain cases return -EPROBE_DEFER, and the consequences of letting request_irq() effectively convert that into -EINVAL, even at probe time rather than later on. So it might be better to check just now. Fixes: 0395ffc1ee05 ("Bluetooth: hci_bcm: Add PM for BCM devices") Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2021-10-25Bluetooth: hci_bcm: Remove duplicated entry in OF tablePaul Cercueil
The entry "brcm,bcm4330-bt" was listed twice in the table. Signed-off-by: Paul Cercueil <paul@crapouillou.net> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2021-08-04Bluetooth: hci_bcm: Fix kernel doc commentsAndy Shevchenko
Kernel doc validator complains about few missed parameter descriptions. Fill the gap by describing them. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2021-03-18Bluetooth: btbcm: Add BCM4330 and BCM4334 compatiblesLinus Walleij
Add the missing brcm,bcm4330-bt and brcm,bcm4334-bt to the match table so device trees can use this compatible as well and not need to use the fallback brcm,bcm4329-bt. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2021-03-08Bluetooth: btbcm: Obtain and handle reset GPIOLinus Walleij
Obtain and drive the optional reset GPIO line if this is not hardwired in the platform. This is needed on the Samsung GT-I9070 mobile phone. The invers of power is used, this should be OK to apply simultaneously as the power signal according to figures 47-51 on pages 159-161 in the BCM4330 datasheet. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-12-18Bluetooth: hci_bcm: Add support for ISO packetsJakub Pawlowski
This enables bcm driver to properly handle ISO packets. Signed-off-by: Jakub Pawlowski <jpawlowski@google.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-04-22Bluetooth: btbcm: Make btbcm_setup_patchram use btbcm_finalizeHans de Goede
On UART attached devices we do: 1. btbcm_initialize() 2. Setup UART baudrate, etc. 3. btbcm_finalize() After our previous changes we can now also use btbcm_finalize() from the btbcm_setup_patchram() function used on USB devices without any functional changes. This completes unifying the USB and UART paths as much as possible. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-04-22Bluetooth: btbcm: Fold Patch loading + applying into btbcm_initialize()Hans de Goede
Instead of having btbcm_initialize() fill a passed in fw_name buffer and then have its callers use that to request the firmware + load it into the HCI, make btbcm_initialize() do this itself the first time it is called (its get called a second time to reset the HCI after the firmware has been loaded). This removes some code duplication and makes it easier for further patches in this series to try more then 1 firmware filename. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-04-22Bluetooth: btbcm: Move setting of USE_BDADDR_PROPERTY quirk to hci_bcm.cHans de Goede
btbcm_finalize() is currently only used by UART attached BCM devices. Move the setting of the USE_BDADDR_PROPERTY quirk, which we only want for UART attached devices to hci_bcm in preparation for using btbcm_finalize() for USB attached devices too. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-04-03Bluetooth: hci_bcm: fix freeing not-requested IRQMichał Mirosław
When BT module can't be initialized, but it has an IRQ, unloading the driver WARNs when trying to free not-yet-requested IRQ. Fix it by noting whether the IRQ was requested. WARNING: CPU: 2 PID: 214 at kernel/irq/devres.c:144 devm_free_irq+0x49/0x4ca [...] WARNING: CPU: 2 PID: 214 at kernel/irq/manage.c:1746 __free_irq+0x8b/0x27c Trying to free already-free IRQ 264 Modules linked in: hci_uart(-) btbcm bluetooth ecdh_generic ecc libaes CPU: 2 PID: 214 Comm: rmmod Tainted: G W 5.6.1mq-00044-ga5f9ea098318-dirty #928 [...] [<b016aefb>] (devm_free_irq) from [<af8ba1ff>] (bcm_close+0x97/0x118 [hci_uart]) [<af8ba1ff>] (bcm_close [hci_uart]) from [<af8b736f>] (hci_uart_unregister_device+0x33/0x3c [hci_uart]) [<af8b736f>] (hci_uart_unregister_device [hci_uart]) from [<b035930b>] (serdev_drv_remove+0x13/0x20) [<b035930b>] (serdev_drv_remove) from [<b037093b>] (device_release_driver_internal+0x97/0x118) [<b037093b>] (device_release_driver_internal) from [<b0370a0b>] (driver_detach+0x2f/0x58) [<b0370a0b>] (driver_detach) from [<b036f855>] (bus_remove_driver+0x41/0x94) [<b036f855>] (bus_remove_driver) from [<af8ba8db>] (bcm_deinit+0x1b/0x740 [hci_uart]) [<af8ba8db>] (bcm_deinit [hci_uart]) from [<af8ba86f>] (hci_uart_exit+0x13/0x30 [hci_uart]) [<af8ba86f>] (hci_uart_exit [hci_uart]) from [<b01900bd>] (sys_delete_module+0x109/0x1d0) [<b01900bd>] (sys_delete_module) from [<b0101001>] (ret_fast_syscall+0x1/0x5a) [...] Cc: stable@vger.kernel.org Fixes: 6cc4396c8829 ("Bluetooth: hci_bcm: Add wake-up capability") Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-04-03Bluetooth: hci_bcm: respect IRQ polarity from DTMichał Mirosław
The IRQ polarity is be configured in bcm_setup_sleep(). Make the configured value match what is in the DeviceTree. Cc: stable@vger.kernel.org Fixes: f25a96c8eb46 ("Bluetooth: hci_bcm: enable IRQ capability from devicetree") Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-01-15Bluetooth: hci_bcm: enable IRQ capability from devicetreeGuillaume La Roque
Add support for getting IRQ directly from DT instead of relying on converting a GPIO to IRQ. This is needed for platforms with GPIO controllers that that do not support gpiod_to_irq(). Reviewed-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Guillaume La Roque <glaroque@baylibre.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-01-04Bluetooth: hci_bcm: Drive RTS only for BCM43438Stefan Wahren
The commit 3347a80965b3 ("Bluetooth: hci_bcm: Fix RTS handling during startup") is causing at least a regression for AP6256 on Orange Pi 3. So do the RTS line handing during startup only on the necessary platform. Fixes: 3347a80965b3 ("Bluetooth: hci_bcm: Fix RTS handling during startup") Reported-by: Ondřej Jirman <megous@megous.com> Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-01-04Bluetooth: hci_bcm: Add device-tree compatible for BCM4329Dmitry Osipenko
Driver supports BCM4329, but there is no device-tree compatible for that chip. Let's add it in order to allow boards to specify Bluetooth in theirs device-trees, in particular this is useful for NVIDIA Tegra20 boards. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-11-27Bluetooth: hci_bcm: Support pcm params in dtsAbhishek Pandit-Subedi
BCM chips may require configuration of PCM to operate correctly and there is a vendor specific HCI command to do this. Add support in the hci_bcm driver to parse this from devicetree and configure the chip. Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2019-11-27Bluetooth: hci_bcm: Disallow set_baudrate for BCM4354Abhishek Pandit-Subedi
Without updating the patchram, the BCM4354 does not support a higher operating speed. The normal bcm_setup follows the correct order (init_speed, patchram and then oper_speed) but the serdev driver will set the operating speed before calling the hu->setup function. Thus, for the BCM4354, don't set the operating speed before patchram. Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2019-11-21Bluetooth: btbcm: Add entry for BCM4335A0 UART bluetoothMohammad Rasim
This patch adds the device ID for the BCM4335A0 module (part of the AMPAK AP6335 WIFI/Bluetooth combo) hciconfig output: ``` hci1: Type: Primary Bus: UART BD Address: 43:35:B0:07:1F:AC ACL MTU: 1021:8 SCO MTU: 64:1 UP RUNNING RX bytes:5079 acl:0 sco:0 events:567 errors:0 TX bytes:69065 acl:0 sco:0 commands:567 errors:0 Features: 0xbf 0xfe 0xcf 0xff 0xdf 0xff 0x7b 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH SNIFF Link mode: SLAVE ACCEPT Name: 'alarm' Class: 0x000000 Service Classes: Unspecified Device Class: Miscellaneous, HCI Version: 4.0 (0x6) Revision: 0x161 LMP Version: 4.0 (0x6) Subversion: 0x4106 Manufacturer: Broadcom Corporation (15) ``` Signed-off-by: Mohammad Rasim <mohammad.rasim96@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-10-26Bluetooth: hci_bcm: Add compatible string for BCM43540Abhishek Pandit-Subedi
The BCM43540 chip is a 802.11 a/b/g/n/ac + Bluetooth 4.1 combo module. This patch adds a compatible string match to the serdev driver for the Bluetooth part of the chip. Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-10-21Bluetooth: hci_bcm: Fix RTS handling during startupStefan Wahren
The RPi 4 uses the hardware handshake lines for CYW43455, but the chip doesn't react to HCI requests during DT probe. The reason is the inproper handling of the RTS line during startup. According to the startup signaling sequence in the CYW43455 datasheet, the hosts RTS line must be driven after BT_REG_ON and BT_HOST_WAKE. Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-09-05bluetooth: hci_bcm: Give more time to come out of resetOndrej Jirman
Some supported devices need more time to come out of reset (eg. BCM4345C5 in AP6256). I don't have/found a datasheet, so the value was arrive at experimentally with the Oprange Pi 3 board. Without increased delay, I got intermittent failures during probe. This is a Bluetooth 5.0 device, so maybe that's why it takes longer to initialize than the others. Signed-off-by: Ondrej Jirman <megous@megous.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-09-05bluetooth: bcm: Add support for loading firmware for BCM4345C5Ondrej Jirman
Detect BCM4345C5 and load a corresponding firmware file. Signed-off-by: Ondrej Jirman <megous@megous.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-09-05Bluetooth: hci_bcm: Fix -Wunused-const-variable warningsYueHaibing
If CONFIG_ACPI is not set, gcc warn this: drivers/bluetooth/hci_bcm.c:831:39: warning: acpi_bcm_int_last_gpios defined but not used [-Wunused-const-variable=] drivers/bluetooth/hci_bcm.c:838:39: warning: acpi_bcm_int_first_gpios defined but not used [-Wunused-const-variable=] move them to #ifdef CONFIG_ACPI block. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-07-31Bluetooth: hci_uart: check for missing tty operationsVladis Dronov
Certain ttys operations (pty_unix98_ops) lack tiocmget() and tiocmset() functions which are called by the certain HCI UART protocols (hci_ath, hci_bcm, hci_intel, hci_mrvl, hci_qca) via hci_uart_set_flow_control() or directly. This leads to an execution at NULL and can be triggered by an unprivileged user. Fix this by adding a helper function and a check for the missing tty operations in the protocols code. This fixes CVE-2019-10207. The Fixes: lines list commits where calls to tiocm[gs]et() or hci_uart_set_flow_control() were added to the HCI UART protocols. Link: https://syzkaller.appspot.com/bug?id=1b42faa2848963564a5b1b7f8c837ea7b55ffa50 Reported-by: syzbot+79337b501d6aa974d0f6@syzkaller.appspotmail.com Cc: stable@vger.kernel.org # v2.6.36+ Fixes: b3190df62861 ("Bluetooth: Support for Atheros AR300x serial chip") Fixes: 118612fb9165 ("Bluetooth: hci_bcm: Add suspend/resume PM functions") Fixes: ff2895592f0f ("Bluetooth: hci_intel: Add Intel baudrate configuration support") Fixes: 162f812f23ba ("Bluetooth: hci_uart: Add Marvell support") Fixes: fa9ad876b8e0 ("Bluetooth: hci_qca: Add support for Qualcomm Bluetooth chip wcn3990") Signed-off-by: Vladis Dronov <vdronov@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Reviewed-by: Yu-Chen, Cho <acho@suse.com> Tested-by: Yu-Chen, Cho <acho@suse.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-30treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 156Thomas Gleixner
Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details you should have received a copy of the gnu general public license along with this program if not write to the free software foundation inc 59 temple place suite 330 boston ma 02111 1307 usa extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 1334 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Richard Fontana <rfontana@redhat.com> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070033.113240726@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-04-23Bluetooth: hci_bcm: Fix empty regulator supplies for Intel MacsChen-Yu Tsai
The code path for Macs goes through bcm_apple_get_resources(), which skips over the code that sets up the regulator supplies. As a result, the call to regulator_bulk_enable() / regulator_bulk_disable() results in a NULL pointer dereference. This was reported on the kernel.org Bugzilla, bug 202963. Unbreak Broadcom Bluetooth support on Intel Macs by checking if the supplies were set up before enabling or disabling them. The same does not need to be done for the clocks, as the common clock framework API checks for NULL pointers. Fixes: 75d11676dccb ("Bluetooth: hci_bcm: Add support for regulator supplies") Cc: <stable@vger.kernel.org> # 5.0.x Signed-off-by: Chen-Yu Tsai <wens@csie.org> Tested-by: Imre Kaloz <kaloz@openwrt.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
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>