aboutsummaryrefslogtreecommitdiff
path: root/drivers/bluetooth
AgeCommit message (Collapse)AuthorFilesLines
2017-12-13Bluetooth: hci_ll: Add endianness conversion when setting baudrateDavid Lechner1-1/+3
This adds an endianness conversion when setting the baudrate using a vendor-specific command. Otherwise, bad things might happen on a big- endian system. Suggested-by: Marcel Holtmann <[email protected]> Signed-off-by: David Lechner <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2017-12-13Bluetooth: hci_ll: add constant for vendor-specific commandDavid Lechner1-2/+8
This adds a #define for the vendor-specific HCI command to set the baudrate instead of using the bare 0xff36 multiple times. Signed-off-by: David Lechner <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2017-12-13Bluetooth: serdev: hci_ll: Wait for CTS instead of using msleepDavid Lechner1-2/+6
When a TI Bluetooth chip is reset, it takes about 100ms for the RTS line of the chip to deassert. For my use case with a TI CC2560A chip, this delay was not long enough and caused the local UART to never transmit at all (TI AM1808 SoC UART2). We can wait for the CTS signal using serdev_device_wait_for_cts() instead of trying to guess using msleep(). Also changed the comment to be more informative while we are touching this code. Signed-off-by: David Lechner <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2017-12-13Bluetooth: hci_ll: remove \n from kernel messagesDavid Lechner1-2/+2
The bt_* printk macros include a \n already, so we don't need extra ones here. Signed-off-by: David Lechner <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2017-12-13Bluetooth: btsdio: Do not bind to non-removable BCM43341Hans de Goede1-0/+9
BCM43341 devices soldered onto the PCB (non-removable) always (AFAICT) use an UART connection for bluetooth. But they also advertise btsdio support on their 3th sdio function, this causes 2 problems: 1) A non functioning BT HCI getting registered 2) Since the btsdio driver does not have suspend/resume callbacks, mmc_sdio_pre_suspend will return -ENOSYS, causing mmc_pm_notify() to react as if the SDIO-card is removed and since the slot is marked as non-removable it will never get detected as inserted again. Which results in wifi no longer working after a suspend/resume. This commit fixes both by making btsdio ignore BCM43341 devices when connected to a slot which is marked non-removable. Cc: [email protected] Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2017-12-13Bluetooth: hci_bcm: Add support for BCM2E72Hans de Goede1-0/+1
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 <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2017-12-13Bluetooth: btqcomsmd: Fix skb double free corruptionLoic Poulain1-1/+2
In case of hci send frame failure, skb is still owned by the caller (hci_core) and then should not be freed. This fixes crash on dragonboard-410c when sending SCO packet. skb is freed by both btqcomsmd and hci_core. Fixes: 1511cc750c3d ("Bluetooth: Introduce Qualcomm WCNSS SMD based HCI driver") Signed-off-by: Loic Poulain <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2017-12-13Bluetooth: hci_serdev: Init hci_uart proto_lock to avoid oopsLukas Wunner1-0/+1
John Stultz reports a boot time crash with the HiKey board (which uses hci_serdev) occurring in hci_uart_tx_wakeup(). That function is contained in hci_ldisc.c, but also called from the newer hci_serdev.c. It acquires the proto_lock in struct hci_uart and it turns out that we forgot to init the lock in the serdev code path, thus causing the crash. John bisected the crash to commit 67d2f8781b9f ("Bluetooth: hci_ldisc: Allow sleeping while proto locks are held"), but the issue was present before and the commit merely exposed it. (Perhaps by luck, the crash did not occur with rwlocks.) Init the proto_lock in the serdev code path to avoid the oops. Stack trace for posterity: Unable to handle kernel read from unreadable memory at 406f127000 [000000406f127000] user address but active_mm is swapper Internal error: Oops: 96000005 [#1] PREEMPT SMP Hardware name: HiKey Development Board (DT) Call trace: hci_uart_tx_wakeup+0x38/0x148 hci_uart_send_frame+0x28/0x38 hci_send_frame+0x64/0xc0 hci_cmd_work+0x98/0x110 process_one_work+0x134/0x330 worker_thread+0x130/0x468 kthread+0xf8/0x128 ret_from_fork+0x10/0x18 Link: https://lkml.org/lkml/2017/11/15/908 Reported-and-tested-by: John Stultz <[email protected]> Cc: Ronald Tschalär <[email protected]> Cc: Rob Herring <[email protected]> Cc: Sumit Semwal <[email protected]> Signed-off-by: Lukas Wunner <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2017-12-13Bluetooth: btusb: Fix BT_HCIBTUSB_AUTOSUSPEND Kconfig option nameHans de Goede1-1/+1
Fix: drivers/bluetooth/Kconfig:35:warning: multi-line strings not supported warning. Reported-by: Stephen Rothwell <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2017-12-13Bluetooth: btusb: Add a Kconfig option to enable USB autosuspend by defaultHans de Goede2-0/+17
On many laptops the btusb device is the only USB device not having USB autosuspend enabled, this causes not only the HCI but also the USB controller to stay awake, together using aprox. 0.4W of power. Modern ultrabooks idle around 6W (at 50% screen brightness), 3.5W for Apollo Lake devices. 0.4W is a significant chunk of this (7 / 11%). The btusb driver already contains code to allow enabling USB autosuspend, but currently leaves it up to the user / userspace to enable it. This means that for most people it will not be enabled, leading to an unnecessarily high power consumption. Since enabling it is not entirely without risk of regressions, this commit adds a Kconfig option so that Linux distributions can choose to enable it by default. This commit also adds a module option so that when distros receive bugs they can easily ask the user to disable it again for easy debugging. Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2017-12-13Bluetooth: hci_qca: Avoid setup failure on missing rampatchLoic Poulain1-0/+3
Assuming that the original code idea was to enable in-band sleeping only if the setup_rome method returns succes and run in 'standard' mode otherwise, we should not return setup_rome return value which makes qca_setup fail if no rampatch/nvm file found. This fixes BT issue on the dragonboard-820C p4 which includes the following QCA controller: hci0: Product:0x00000008 hci0: Patch :0x00000111 hci0: ROM :0x00000302 hci0: SOC :0x00000044 Since there is no rampatch for this controller revision, just make it work as is. Signed-off-by: Loic Poulain <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2017-11-28the rest of drivers/*: annotate ->poll() instancesAl Viro2-2/+2
Signed-off-by: Al Viro <[email protected]>
2017-11-04Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller2-0/+2
Files removed in 'net-next' had their license header updated in 'net'. We take the remove from 'net-next'. Signed-off-by: David S. Miller <[email protected]>
2017-11-02License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseGreg Kroah-Hartman2-0/+2
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: Kate Stewart <[email protected]> Reviewed-by: Philippe Ombredanne <[email protected]> Reviewed-by: Thomas Gleixner <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-10-30Bluetooth: hci_ldisc: Fix another race when closing the tty.Ronald Tschalär1-2/+2
The following race condition still existed: P1 P2 cancel_work_sync() hci_uart_tx_wakeup() hci_uart_write_work() hci_uart_dequeue() clear_bit(HCI_UART_PROTO_READY) hci_unregister_dev(hdev) hci_free_dev(hdev) hu->proto->close(hu) kfree(hu) access to hdev and hu Cancelling the work after clearing the HCI_UART_PROTO_READY bit avoids this as any hci_uart_tx_wakeup() issued after the flag is cleared will detect that and not schedule further work. Signed-off-by: Ronald Tschalär <[email protected]> Reviewed-by: Lukas Wunner <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2017-10-30Bluetooth: btusb: Fix isochronous interface assignmentsMarcel Holtmann1-1/+3
The recent MacBook's with multi-function USB interfaces for HID and Bluetooth operation have the isochronous interface on number 3 instead of number 1. Store the interface number and use it. P: Vendor=05ac ProdID=8290 Rev= 1.40 S: Manufacturer=Broadcom Corp. S: Product=Bluetooth USB Host Controller C:* #Ifs= 6 Cfg#= 1 Atr=e0 MxPwr= 0mA A: FirstIf#= 2 IfCount= 4 Cls=ff(vend.) Sub=01 Prot=01 I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=01 Driver=usbhid E: Ad=85(I) Atr=03(Int.) MxPS= 8 Ivl=10ms I:* If#= 1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=usbhid E: Ad=86(I) Atr=03(Int.) MxPS= 8 Ivl=10ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 3 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 3 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 3 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 3 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 3 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=btusb E: Ad=84(I) Atr=02(Bulk) MxPS= 32 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 32 Ivl=0ms I:* If#= 5 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none) Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2017-10-30Bluetooth: btusb: Update firmware filename for Intel 9x60 and laterJaya P G1-7/+47
The format of Intel Bluetooth firmware for bootloader product is ibt-<hw_variant>-<device_revision_id>.sfi and .ddc. But for the SKU's 9x60, there a 3 variants of FW, which cannot be differentiated just with hw_variant and devision_revision_id. So to pick the appropriate FW file for 9x60 SKU's, it will be differentiated using hw_variant, hw_revision and fw_revision rather than hw_variant and device_revision_id only. Format will be like this: ibt-<hw_variant>-<hw_revision>-<fw_revision>.sfi and .ddc Signed-off-by: Jaya P G <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2017-10-30Bluetooth: Use bt_dev_err and bt_dev_info when possibleMarcel Holtmann11-190/+179
In case of using BT_ERR and BT_INFO, convert to bt_dev_err and bt_dev_info when possible. This allows for controller specific reporting. Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2017-10-29Bluetooth: hci_ath: Add ath_vendor_cmd helperLoic Poulain1-17/+32
Introduce ath_vendor_cmd function which can be used to configure 'tags' and patch the firmware. ATH vendor command has the following format: | OPCODE (u8) | INDEX (LE16) | DLEN (U8) | DATA (U8 * DLEN) | BD address configuration tag is at index 0x0001. Signed-off-by: Loic Poulain <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2017-10-29Bluetooth: btusb: Add new NFA344A entry.Bartosz Chronowski1-0/+1
This change allows proper low power mode entry in suspend. /sys/kernel/debug/usb/devices entry: T: Bus=01 Lev=01 Prnt=01 Port=05 Cnt=03 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 2.01 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e09f Rev= 0.01 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by: Bartosz Chronowski <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2017-10-29Bluetooth: hci_ldisc: Allow sleeping while proto locks are held.Ronald Tschalär2-17/+23
Commit dec2c92880cc5435381d50e3045ef018a762a917 ("Bluetooth: hci_ldisc: Use rwlocking to avoid closing proto races") introduced locks in hci_ldisc that are held while calling the proto functions. These locks are rwlock's, and hence do not allow sleeping while they are held. However, the proto functions that hci_bcm registers use mutexes and hence need to be able to sleep. In more detail: hci_uart_tty_receive() and hci_uart_dequeue() both acquire the rwlock, after which they call proto->recv() and proto->dequeue(), respectively. In the case of hci_bcm these point to bcm_recv() and bcm_dequeue(). The latter both acquire the bcm_device_lock, which is a mutex, so doing so results in a call to might_sleep(). But since we're holding a rwlock in hci_ldisc, that results in the following BUG (this for the dequeue case - a similar one for the receive case is omitted for brevity): BUG: sleeping function called from invalid context at kernel/locking/mutex.c in_atomic(): 1, irqs_disabled(): 0, pid: 7303, name: kworker/7:3 INFO: lockdep is turned off. CPU: 7 PID: 7303 Comm: kworker/7:3 Tainted: G W OE 4.13.2+ #17 Hardware name: Apple Inc. MacBookPro13,3/Mac-A5C67F76ED83108C, BIOS MBP133.8 Workqueue: events hci_uart_write_work [hci_uart] Call Trace: dump_stack+0x8e/0xd6 ___might_sleep+0x164/0x250 __might_sleep+0x4a/0x80 __mutex_lock+0x59/0xa00 ? lock_acquire+0xa3/0x1f0 ? lock_acquire+0xa3/0x1f0 ? hci_uart_write_work+0xd3/0x160 [hci_uart] mutex_lock_nested+0x1b/0x20 ? mutex_lock_nested+0x1b/0x20 bcm_dequeue+0x21/0xc0 [hci_uart] hci_uart_write_work+0xe6/0x160 [hci_uart] process_one_work+0x253/0x6a0 worker_thread+0x4d/0x3b0 kthread+0x133/0x150 We can't replace the mutex in hci_bcm, because there are other calls there that might sleep. Therefore this replaces the rwlock's in hci_ldisc with rw_semaphore's (which allow sleeping). This is a safer approach anyway as it reduces the restrictions on the proto callbacks. Also, because acquiring write-lock is very rare compared to acquiring the read-lock, the percpu variant of rw_semaphore is used. Lastly, because hci_uart_tx_wakeup() may be called from an IRQ context, we can't block (sleep) while trying acquire the read lock there, so we use the trylock variant. Signed-off-by: Ronald Tschalär <[email protected]> Reviewed-by: Lukas Wunner <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2017-10-14Bluetooth: mark expected switch fall-throughsGustavo A. R. Silva2-2/+2
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. In this particular case, notice that I replaced the "deliberate fall-through..." comment with a "fall through" comment, which is what GCC is expecting to find. Signed-off-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2017-10-14Revert "Bluetooth: btusb: Add workaround for Broadcom devices without ↵Hans de Goede1-18/+0
product id" Commit 9834e586fa66 ("Bluetooth: btusb: Add workaround for Broadcom devices without product id") was added to deal with the BT part of the BCM4356A2 on GPD pocket laptops having an usb vid:pid of 0000:0000. After another commit to add support for the BCM UART connected BT ACPI-id BCM2E7E used on the GPD win, it turns out that the BT on the GPD pocket is connected via both USB and UART. Adding support for the BCM2E7E ACPI-id causes it to switch to UART mode. The Windows shipped with the device is using it in UART mode and the presence of the BCM2E7E ACPI-id combined with the all 0 USB vid:pid indicates that the BT part was never meant to be used in USB mode. With the recent patches to use serdev device enumeration / instantiation for UART attached ACPI enumerated BT devices, everything work OOTB in UART mode and the workaround for the all 0 USB vid:pid is no longer needed. This reverts commit 9834e586fa ("Bluetooth: btusb: Add workaround for Broadcom devices without product id"). Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2017-10-14Bluetooth: hci_bcm: Add support for BCM2E7EHans de Goede1-0/+1
Tested on a GPD win with a BCM4356 PCI-E wifi/bt combo card. Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2017-10-14Bluetooth: btbcm: Add entry for BCM4356A2 UART bluetoothHans de Goede1-0/+2
This patch adds the device ID for the bluetooth chip used in the Broadcom BCM4356 PCI-E WiFi / UART BT chip. Successfully tested using Firmware version 0273 The upper nibble of the rev field is 2 on this device, so this commit also adds handling of 2 to the switch-case done on the upper nibble. Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2017-10-11Bluetooth: BT_HCIUART now depends on SERIAL_DEV_BUSArnd Bergmann1-1/+1
It is no longer possible to build BT_HCIUART into the kernel when SERIAL_DEV_BUS is a loadable module, even if none of the SERIAL_DEV_BUS based implementations are selected: drivers/bluetooth/hci_ldisc.o: In function `hci_uart_set_flow_control': hci_ldisc.c:(.text+0xb40): undefined reference to `serdev_device_set_flow_control' hci_ldisc.c:(.text+0xb5c): undefined reference to `serdev_device_set_tiocm' This adds a dependency to avoid the broken configuration. Fixes: 7841d554809b ("Bluetooth: hci_uart_set_flow_control: Fix NULL deref when using serdev") Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2017-10-11Bluetooth: hci_bcm: fix build error without CONFIG_PMArnd Bergmann1-0/+4
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 <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2017-10-10Bluetooth: btbcm: Add support for MINIX Z83-4 based devicesIan W MORRISON1-0/+1
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 defines the firmware subversion. Signed-off-by: Ian W MORRISON <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2017-10-10Bluetooth: hci_bcm: Add support for MINIX Z83-4 based devicesIan W MORRISON1-0/+8
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 <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2017-10-10Bluetooth: avoid silent hci_bcm ACPI PM regressionJohan Hovold1-0/+1
The hci_bcm platform-device hack which was used to implement power management for ACPI devices is being replaced by a serial-device-bus implementation. Unfortunately, when the corresponding change to the ACPI code lands (a change that will stop enumerating and registering the serial-device-node child as a platform device) PM will break silently unless serdev TTY-port controller support has been enabled. Specifically, hciattach (btattach) would still succeed, but power management would no longer work. Although this is strictly a runtime dependency, let's make the driver depend on SERIAL_DEV_CTRL_TTYPORT, which is the particular serdev controller implementation used by the ACPI devices currently managed by this driver, to avoid breaking PM without anyone noticing. Note that the driver already has a (build-time) dependency on the serdev bus code. Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2017-10-09Bluetooth: hci_bcm: Correct context of IRQ polarity messageIan W MORRISON1-1/+1
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 <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2017-10-06Bluetooth: Convert timers to use timer_setup()Kees Cook4-21/+23
In preparation for unconditionally passing the struct timer_list pointer to all timer callbacks, switch to using the new timer_setup() and from_timer() to pass the timer pointer explicitly. As already done in hci_qca, add struct hci_uart pointer to priv structure. Signed-off-by: Kees Cook <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2017-10-06Bluetooth: hci_bcm: Add (runtime)pm support to the serdev driverHans de Goede1-50/+68
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 <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2017-10-06Bluetooth: hci_bcm: Make suspend/resume functions platform_dev independentHans de Goede1-4/+4
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 <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2017-10-06Bluetooth: hci_bcm: Make acpi_probe get irq from ACPI resourcesHans de Goede1-2/+9
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 <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2017-10-06Bluetooth: hci_bcm: Rename bcm_platform_probe to bcm_get_resourcesHans de Goede1-2/+2
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 <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2017-10-06Bluetooth: hci_bcm: Store device pointer instead of platform_device pointerHans de Goede1-38/+35
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 <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2017-10-06Bluetooth: hci_bcm: Move platform_get_irq call to bcm_probeHans de Goede1-1/+1
The ACPI subsys is going to move over to instantiating ACPI enumerated HCIs as serdevs, rather then as platform devices. Most of the code in bcm_platform_probe is actually not platform specific and will work with any struct device passed to it, the one platform specific call in bcm_platform_probe is platform_get_irq. This commit moves platform_get_irq call to the platform-driver's bcm_probe function, this is a preparation patch for adding (runtime)pm support to the serdev path. Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2017-10-06Bluetooth: hci_bcm: Move bcm_platform_probe call out of bcm_acpi_probeHans de Goede1-7/+6
Since bcm_acpi_probe calls bcm_platform_probe, bcm_probe always ends up calling bcm_platform_probe. This commit simplifies things by making bcm_probe always call bcm_platform_probe itself. Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2017-10-06Bluetooth: hci_bcm: Fix setting of irq trigger typeHans de Goede1-13/+10
This commit fixes 2 issues with host-wake irq trigger type handling in hci_bcm: 1) bcm_setup_sleep sets sleep_params.host_wake_active based on bcm_device.irq_polarity, but bcm_request_irq was always requesting IRQF_TRIGGER_RISING as trigger type independent of irq_polarity. This was a problem when the irq is described as a GpioInt rather then an Interrupt in the DSDT as for GpioInt-s the value passed to request_irq is honored. This commit fixes this by requesting the correct trigger type depending on bcm_device.irq_polarity. 2) bcm_device.irq_polarity was used to directly store an ACPI polarity value (ACPI_ACTIVE_*). This is undesirable because hci_bcm is also used with device-tree and checking for something like ACPI_ACTIVE_LOW in a non ACPI specific function like bcm_request_irq feels wrong. This commit fixes this by renaming irq_polarity to irq_active_low and changing its type to a bool. Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2017-10-06Bluetooth: hci_uart_set_flow_control: Fix NULL deref when using serdevHans de Goede1-0/+7
Fix a NULL pointer deref (hu->tty) when calling hci_uart_set_flow_control on hci_uart-s using serdev. Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2017-10-06Bluetooth: btmrvl: *_err() and *_info() strings should end with newlinesArvind Yadav1-3/+3
pr_err(), dev_err() and pr_info() messages should terminated with a new-line to avoid other messages being concatenated onto the end. Signed-off-by: Arvind Yadav <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2017-10-06Bluetooth: btqcomsmd: retrieve BD address from DT propertyLoic Poulain1-0/+11
Retrieve BD address from the local-bd-address property. This address must be unique and is usually added in the DT by the bootloader which has access to the provisioned data. Signed-off-by: Loic Poulain <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2017-10-06Bluetooth: btqcomsmd: Add support for BD address setupLoic Poulain1-0/+34
This patch implements the hdev setup function since wcnss-bt does not have persistent memory to store an allocated BD address. The device is therefore marked as unconfigured if no BD address has been previously retrieved. Signed-off-by: Loic Poulain <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]> Cc: [email protected]
2017-08-17Bluetooth: hci_bcm: Handle empty packet after firmware loadingMarcel Holtmann1-0/+11
The Broadcom controller on the Raspberry Pi3 sends an empty packet with packet type 0x00 after launching the firmware. This will cause logging of errors. Bluetooth: hci0: Frame reassembly failed (-84) Since this seems to be an intented behaviour of the controller, handle it gracefully by parsing that empty packet with packet type 0x00 and then just simply report it as diagnostic packet. With that change no errors are logging and the packet itself is actually recorded in the Bluetooth monitor traces. < HCI Command: Broadcom Launch RAM (0x3f|0x004e) plen 4 Address: 0xffffffff > HCI Event: Command Complete (0x0e) plen 4 Broadcom Launch RAM (0x3f|0x004e) ncmd 1 Status: Success (0x00) = Vendor Diagnostic (len 0) < HCI Command: Broadcom Update UART Baud Rate (0x3f|0x0018) plen 6 00 00 00 10 0e 00 ...... > HCI Event: Command Complete (0x0e) plen 4 Broadcom Update UART Baud Rate (0x3f|0x0018) ncmd 1 Status: Success (0x00) < HCI Command: Reset (0x03|0x0003) plen 0 > HCI Event: Command Complete (0x0e) plen 4 Reset (0x03|0x0003) ncmd 1 Status: Success (0x00) Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2017-08-17Bluetooth: hci_bcm: Add serdev supportLoic Poulain2-2/+84
Add basic support for Broadcom serial slave devices. Probe the serial device, retrieve its maximum speed and register a new hci uart device. Tested/compatible with bcm43438 (RPi3). Signed-off-by: Loic Poulain <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2017-08-17Bluetooth: btbcm: Consolidate the controller information commandsMarcel Holtmann1-30/+39
The commands that read the basic vendor information about the Broadcom controller are duplicated for UART and USB devices. Combine them into a single function to reduce the code complexity. Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2017-08-16Bluetooth: hci_bcm: Use operation speed of 4Mbps only for ACPI devicesMarcel Holtmann1-2/+5
Not all Broadcom controller support the 4Mbps operational speed on UART devices. This is because the UART clock setting changes might not be supported. < HCI Command: Broadcom Write UART Clock Setting (0x3f|0x0045) plen 1 01 . > HCI Event: Command Complete (0x0e) plen 4 Broadcom Write UART Clock Setting (0x3f|0x0045) ncmd 1 Status: Unknown HCI Command (0x01) To support any operational speed higher than 3Mbps, support for this command is required. With that respect it is better to not enforce any operational speed by default. Only when its support is known, then allow for higher operational speed. This patch assigns the 4Mbps opertional speed only for devices discovered through ACPI and leave all others at the default 115200. Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2017-08-16Bluetooth: btusb: driver to enable the usb-wakeup featureSukumar Ghorai1-0/+5
BT-Controller connected as platform non-root-hub device and usb-driver initialize such device with wakeup disabled, Ref. usb_new_device(). At present wakeup-capability get enabled by hid-input device from usb function driver(e.g. BT HID device) at runtime. Again some functional driver does not set usb-wakeup capability(e.g LE HID device implement as HID-over-GATT), and can't wakeup the host on USB. Most of the device operation (such as mass storage) initiated from host (except HID) and USB wakeup aligned with host resume procedure. For BT device, usb-wakeup capability need to enable form btusc driver as a generic solution for multiple profile use case and required for USB remote wakeup (in-bus wakeup) while host is suspended. Also usb-wakeup feature need to enable/disable with HCI interface up and down. Signed-off-by: Sukumar Ghorai <[email protected]> Signed-off-by: Amit K Bag <[email protected]> Acked-by: Oliver Neukum <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2017-08-15Bluetooth: btusb: Add workaround for Broadcom devices without product idMarcel Holtmann1-0/+18
The GPD Pocket is shipping with a BCM2045 USB HCI with its vendor and product information set to 0000:0000 and also has its interface class set to 255 (Vendor Specific Class). Luckily it does advertise usable manufacturer and product strings. T: Bus=01 Lev=01 Prnt=01 Port=02 Cnt=02 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0000 ProdID=0000 Rev= 1.12 S: Manufacturer=Broadcom Corp S: Product=BCM2045A0 S: SerialNumber=AC83F30677CB C:* #Ifs= 4 Cfg#= 1 Atr=80 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=84(I) Atr=02(Bulk) MxPS= 32 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 32 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none) Reported-by: Christopher Williamson <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>