23 Apr, 2020
3 commits
-
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
Signed-off-by: Marcel Holtmann -
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
Signed-off-by: Marcel Holtmann -
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
Signed-off-by: Marcel Holtmann
03 Apr, 2020
2 commits
-
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
[...]
[] (devm_free_irq) from [] (bcm_close+0x97/0x118 [hci_uart])
[] (bcm_close [hci_uart]) from [] (hci_uart_unregister_device+0x33/0x3c [hci_uart])
[] (hci_uart_unregister_device [hci_uart]) from [] (serdev_drv_remove+0x13/0x20)
[] (serdev_drv_remove) from [] (device_release_driver_internal+0x97/0x118)
[] (device_release_driver_internal) from [] (driver_detach+0x2f/0x58)
[] (driver_detach) from [] (bus_remove_driver+0x41/0x94)
[] (bus_remove_driver) from [] (bcm_deinit+0x1b/0x740 [hci_uart])
[] (bcm_deinit [hci_uart]) from [] (hci_uart_exit+0x13/0x30 [hci_uart])
[] (hci_uart_exit [hci_uart]) from [] (sys_delete_module+0x109/0x1d0)
[] (sys_delete_module) from [] (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
Signed-off-by: Marcel Holtmann -
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
Signed-off-by: Marcel Holtmann
16 Jan, 2020
1 commit
-
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
Signed-off-by: Guillaume La Roque
Signed-off-by: Marcel Holtmann
04 Jan, 2020
2 commits
-
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
Signed-off-by: Stefan Wahren
Signed-off-by: Marcel Holtmann -
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
Signed-off-by: Marcel Holtmann
27 Nov, 2019
2 commits
-
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
Signed-off-by: Marcel Holtmann
Signed-off-by: Johan Hedberg -
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
Signed-off-by: Marcel Holtmann
Signed-off-by: Johan Hedberg
21 Nov, 2019
1 commit
-
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
Signed-off-by: Marcel Holtmann
26 Oct, 2019
1 commit
-
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
Signed-off-by: Marcel Holtmann
21 Oct, 2019
1 commit
-
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
Signed-off-by: Marcel Holtmann
05 Sep, 2019
3 commits
-
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
Signed-off-by: Marcel Holtmann -
Detect BCM4345C5 and load a corresponding firmware file.
Signed-off-by: Ondrej Jirman
Signed-off-by: Marcel Holtmann -
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
Signed-off-by: YueHaibing
Signed-off-by: Marcel Holtmann
01 Aug, 2019
1 commit
-
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
Signed-off-by: Marcel Holtmann
Reviewed-by: Yu-Chen, Cho
Tested-by: Yu-Chen, Cho
Signed-off-by: Linus Torvalds
31 May, 2019
1 commit
-
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 usaextracted 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
Reviewed-by: Allison Randal
Reviewed-by: Richard Fontana
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190527070033.113240726@linutronix.de
Signed-off-by: Greg Kroah-Hartman
24 Apr, 2019
1 commit
-
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: # 5.0.x
Signed-off-by: Chen-Yu Tsai
Tested-by: Imre Kaloz
Signed-off-by: Marcel Holtmann
19 Dec, 2018
9 commits
-
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
Signed-off-by: Paweł Chmiel
Signed-off-by: Marcel Holtmann -
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
Signed-off-by: Marcel Holtmann -
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
Tested-by: Ondrej Jirman
Signed-off-by: Chen-Yu Tsai
Signed-off-by: Marcel Holtmann -
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
Signed-off-by: Chen-Yu Tsai
Signed-off-by: Marcel Holtmann -
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
Signed-off-by: Chen-Yu Tsai
Signed-off-by: Marcel Holtmann -
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
Signed-off-by: Chen-Yu Tsai
Signed-off-by: Marcel Holtmann -
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
Signed-off-by: Chen-Yu Tsai
Signed-off-by: Marcel Holtmann -
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
Signed-off-by: Chen-Yu Tsai
Signed-off-by: Marcel Holtmann -
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
Signed-off-by: Chen-Yu Tsai
Signed-off-by: Marcel Holtmann
30 May, 2018
1 commit
-
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
Signed-off-by: Marcel Holtmann
18 May, 2018
3 commits
-
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
Signed-off-by: Marcel Holtmann -
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
Signed-off-by: Marcel Holtmann -
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
Signed-off-by: Marcel Holtmann
02 Apr, 2018
1 commit
-
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
Signed-off-by: Marcel Holtmann
01 Apr, 2018
7 commits
-
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
Signed-off-by: Marcel Holtmann -
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.hcdWhich 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
Signed-off-by: Hans de Goede
Signed-off-by: Marcel Holtmann -
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
Signed-off-by: Marcel Holtmann -
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 Yoga2The reporter of kernel bugzilla 274481 has tested:
BCM2E38: Toshiba EncoreNote 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
Reported-and-tested-by: Christian Herzog
Tested-by: Hans de Goede
Signed-off-by: Hans de Goede
Signed-off-by: Marcel Holtmann -
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
Signed-off-by: Marcel Holtmann -
Add irq_polarity module option for easier troubleshooting of irq-polarity
issues.Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede
Signed-off-by: Marcel 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
Signed-off-by: Johan Hedberg
