aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/bluetooth
AgeCommit message (Collapse)Author
2019-04-07Bluetooth: hci_ldisc: Postpone HCI_UART_PROTO_READY bit set in ↵Kefeng Wang
hci_uart_set_proto() commit 56897b217a1d0a91c9920cb418d6b3fe922f590a upstream. task A: task B: hci_uart_set_proto flush_to_ldisc - p->open(hu) -> h5_open //alloc h5 - receive_buf - set_bit HCI_UART_PROTO_READY - tty_port_default_receive_buf - hci_uart_register_dev - tty_ldisc_receive_buf - hci_uart_tty_receive - test_bit HCI_UART_PROTO_READY - h5_recv - clear_bit HCI_UART_PROTO_READY while() { - p->open(hu) -> h5_close //free h5 - h5_rx_3wire_hdr - h5_reset() //use-after-free } It could use ioctl to set hci uart proto, but there is a use-after-free issue when hci_uart_register_dev() fail in hci_uart_set_proto(), see stack above, fix this by setting HCI_UART_PROTO_READY bit only when hci_uart_register_dev() return success. Reported-by: syzbot+899a33dc0fa0dbaf06a6@syzkaller.appspotmail.com Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> Reviewed-by: Jeremy Cline <jcline@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2019-04-07Bluetooth: hci_ldisc: Initialize hci_dev before open()Jeremy Cline
commit 32a7b4cbe93b0a0ef7e63d31ca69ce54736c4412 upstream. The hci_dev struct hdev is referenced in work queues and timers started by open() in some protocols. This creates a race between the initialization function and the work or timer which can result hdev being dereferenced while it is still null. The syzbot report contains a reliable reproducer which causes a null pointer dereference of hdev in hci_uart_write_work() by making the memory allocation for hdev fail. To fix this, ensure hdev is valid from before calling a protocol's open() until after calling a protocol's close(). Reported-by: syzbot+257790c15bcdef6fe00c@syzkaller.appspotmail.com Signed-off-by: Jeremy Cline <jcline@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2019-04-07Bluetooth: hci_uart: Check if socket buffer is ERR_PTR in h4_recv_buf()Myungho Jung
commit 1dc2d785156cbdc80806c32e8d2c7c735d0b4721 upstream. h4_recv_buf() callers store the return value to socket buffer and recursively pass the buffer to h4_recv_buf() without protection. So, ERR_PTR returned from h4_recv_buf() can be dereferenced, if called again before setting the socket buffer to NULL from previous error. Check if skb is ERR_PTR in h4_recv_buf(). Reported-by: syzbot+017a32f149406df32703@syzkaller.appspotmail.com Signed-off-by: Myungho Jung <mhjungk@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2019-03-01Bluetooth: hci_bcm: Handle deferred probing for the clock supplyChen-Yu Tsai
commit 28ac03b9ac3f784c2f048a910c8d0a7a87483b66 upstream. 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> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2018-11-13Bluetooth: btbcm: Add entry for BCM4335C0 UART bluetoothChristian Hewitt
[ Upstream commit a357ea098c9605f60d92a66a9073f56ce25726da ] This patch adds the device ID for the AMPAK AP6335 combo module used in the 1st generation WeTek Hub Android/LibreELEC HTPC box. The WiFI chip identifies itself as BCM4339, while Bluetooth identifies itself as BCM4335 (rev C0): ``` [ 4.864248] Bluetooth: hci0: BCM: chip id 86 [ 4.866388] Bluetooth: hci0: BCM: features 0x2f [ 4.889317] Bluetooth: hci0: BCM4335C0 [ 4.889332] Bluetooth: hci0: BCM4335C0 (003.001.009) build 0000 [ 9.778383] Bluetooth: hci0: BCM4335C0 (003.001.009) build 0268 ``` Output from hciconfig: ``` hci0: Type: Primary Bus: UART BD Address: 43:39:00:00:1F:AC ACL MTU: 1021:8 SCO MTU: 64:1 UP RUNNING RX bytes:7567 acl:234 sco:0 events:386 errors:0 TX bytes:53844 acl:77 sco:0 commands:304 errors:0 Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH SNIFF Link mode: SLAVE ACCEPT Name: 'HUB' Class: 0x0c0000 Service Classes: Rendering, Capturing Device Class: Miscellaneous, HCI Version: 4.0 (0x6) Revision: 0x10c LMP Version: 4.0 (0x6) Subversion: 0x6109 Manufacturer: Broadcom Corporation (15) ``` Signed-off-by: Christian Hewitt <christianshewitt@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-10-18Bluetooth: hci_ldisc: Free rw_semaphore on closeHermes Zhang
[ Upstream commit e6a57d22f787e73635ce0d29eef0abb77928b3e9 ] The percpu_rw_semaphore is not currently freed, and this leads to a crash when the stale rcu callback is invoked. DEBUG_OBJECTS detects this. ODEBUG: free active (active state 1) object type: rcu_head hint: (null) ------------[ cut here ]------------ WARNING: CPU: 1 PID: 2024 at debug_print_object+0xac/0xc8 PC is at debug_print_object+0xac/0xc8 LR is at debug_print_object+0xac/0xc8 Call trace: [<ffffff80082e2c2c>] debug_print_object+0xac/0xc8 [<ffffff80082e40b0>] debug_check_no_obj_freed+0x1e8/0x228 [<ffffff8008191254>] kfree+0x1cc/0x250 [<ffffff80083cc03c>] hci_uart_tty_close+0x54/0x108 [<ffffff800832e118>] tty_ldisc_close.isra.1+0x40/0x58 [<ffffff800832e14c>] tty_ldisc_kill+0x1c/0x40 [<ffffff800832e3dc>] tty_ldisc_release+0x94/0x170 [<ffffff8008325554>] tty_release_struct+0x1c/0x58 [<ffffff8008326400>] tty_release+0x3b0/0x490 [<ffffff80081a3fe8>] __fput+0x88/0x1d0 [<ffffff80081a418c>] ____fput+0xc/0x18 [<ffffff80080c0624>] task_work_run+0x9c/0xc0 [<ffffff80080a9e24>] do_exit+0x24c/0x8a0 [<ffffff80080aa4e0>] do_group_exit+0x38/0xa0 [<ffffff80080aa558>] __wake_up_parent+0x0/0x28 [<ffffff8008082c00>] el0_svc_naked+0x34/0x38 ---[ end trace bfe08cbd89098cdf ]--- Signed-off-by: Hermes Zhang <chenhuiz@axis.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-10-03Bluetooth: Add a new Realtek 8723DE ID 0bda:b009Jian-Hong Pan
[ Upstream commit 45ae68b8cfc25bdbffc11248001c47ab1b76ff6e ] Without this patch we cannot turn on the Bluethooth adapter on HP 14-bs007la. T: Bus=01 Lev=02 Prnt=03 Port=00 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0bda ProdID=b009 Rev= 2.00 S: Manufacturer=Realtek S: Product=802.11n WLAN Adapter S: SerialNumber=00e04c000001 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA 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=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) 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=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-19Bluetooth: h5: Fix missing dependency on BT_HCIUART_SERDEVJohan Hedberg
[ Upstream commit 6c3711ec64fd23a9abc8aaf59a9429569a6282df ] This driver was recently updated to use serdev, so add the appropriate dependency. Without this one can get compiler warnings like this if CONFIG_SERIAL_DEV_BUS is not enabled: CC [M] drivers/bluetooth/hci_h5.o drivers/bluetooth/hci_h5.c:934:36: warning: ‘h5_serdev_driver’ defined but not used [-Wunused-variable] static struct serdev_device_driver h5_serdev_driver = { ^~~~~~~~~~~~~~~~ Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-06-17bluetooth: hci_nokia: Don't include linux/unaligned/le_struct.h directly.David S. Miller
This breaks the build as this header is not meant to be used in this way. ./include/linux/unaligned/access_ok.h:8:28: error: redefinition of ‘get_unaligned_le16’ static __always_inline u16 get_unaligned_le16(const void *p) ^~~~~~~~~~~~~~~~~~ In file included from drivers/bluetooth/hci_nokia.c:32: ./include/linux/unaligned/le_struct.h:7:19: note: previous definition of ‘get_unaligned_le16’ was here static inline u16 get_unaligned_le16(const void *p) Use asm/unaligned.h instead. Signed-off-by: David S. Miller <davem@davemloft.net>
2018-05-30Bluetooth: btusb: Add additional device ID for RTL8822BEArtiom Vaskov
The Asus ROG GL702ZC laptop contains a Realtek RTL8822BE device with an associated BT chip using a USB ID of 13d3:3526. This ID is added to the driver. The /sys/kernel/debug/usb/devices portion for this device is: T: Bus=01 Lev=01 Prnt=01 Port=09 Cnt=04 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3526 Rev= 1.10 S: Manufacturer=Realtek S: Product=Bluetooth Radio S: SerialNumber=00e04c000001 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA 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=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) 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=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by: Artiom Vaskov <velemas@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-05-30Bluetooth: hci_serdev: Fix HCI_UART_INIT_PENDING not workingHans de Goede
Init hci_uart->init_ready so that hci_uart_init_ready() works properly. Signed-off-by: Hans de Goede <hdegoede@redhat.com> 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-30Bluetooth: hci_uart: Restore hci_dev->flush callback on open()Hans de Goede
For reasons explained in detail in commit 3611f4d2a5e0 ("hci_ldisc: fix null pointer deref") the hci_uart_close() functions sets hci_dev->flush to NULL. But the device may be re-opened after a close, this commit restores the hci_dev->flush callback on open(). Note this commit also moves the nearly empty defition of hci_uart_open() a bit down in the file to avoid the need for forward declaring hci_uart_flush(). Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-05-30Bluetooth: btmrvl: Re-use kstrtol_from_user()Andy Shevchenko
Re-use kstrtol_from_user() instead of open coded variant. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-05-30Bluetooth: hci_qca: Fix "Sleep inside atomic section" warningThierry Escande
This patch fixes the following warning during boot: do not call blocking ops when !TASK_RUNNING; state=1 set at [<(ptrval)>] qca_setup+0x194/0x750 [hci_uart] WARNING: CPU: 2 PID: 1878 at kernel/sched/core.c:6135 __might_sleep+0x7c/0x88 In qca_set_baudrate(), the current task state is set to TASK_UNINTERRUPTIBLE before going to sleep for 300ms. It was then restored to TASK_INTERRUPTIBLE. This patch sets the current task state back to TASK_RUNNING instead. Signed-off-by: Thierry Escande <thierry.escande@linaro.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-05-29Bluetooth: btusb: Add Dell Inspiron 5565 to btusb_needs_reset_resume_tableHans de Goede
The Dell Inspiron 5565 uses a QCA Rome chip which needs to be reset (and have its firmware reloaded) for bluetooth to work after suspend/resume. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=15750392 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-05-29Bluetooth: hci_serdev: Removed unnecessary curly bracesVaibhav Murkute
checkpatch.pl shows a warning for these unnecessary curly braces. so just removed those curly braces. Signed-off-by: Vaibhav Murkute <vaibhavmurkute88@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-05-29Bluetooth: btmrvl: support sysfs initiated firmware coredumpArend van Spriel
Since commit 3c47d19ff4dc ("drivers: base: add coredump driver ops") it is possible to initiate a device coredump from user-space. This patch adds support for it in btmrvl_sdio adding the .coredump() driver callback. This makes dump through debugfs obsolete so removing it. Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-05-29Bluetooth: btusb: Apply QCA Rome patches for some ATH3012 modelsTakashi Iwai
In commit f44cb4b19ed4 ("Bluetooth: btusb: Fix quirk for Atheros 1525/QCA6174") we tried to address the non-working Atheros BT devices by changing the quirk from BTUSB_ATH3012 to BTUSB_QCA_ROME. This made such devices working while it turned out to break other existing chips with the very same USB ID, hence it was reverted afterwards. This is another attempt to tackle the issue. The essential point to use BTUSB_QCA_ROME is to apply the btusb_setup_qca() and do RAM- patching. And the previous attempt failed because btusb_setup_qca() returns -ENODEV if the ROM version doesn't match with the expected ones. For some devices that have already the "correct" ROM versions, we may just skip the setup procedure and continue the rest. So, the first fix we'll need is to add a check of the ROM version in the function to skip the setup if the ROM version looks already sane, so that it can be applied for all ath devices. However, the world is a bit more complex than that simple solution. Since BTUSB_ATH3012 quirk checks the bcdDevice and bails out when it's 0x0001 at the beginning of probing, so the device probe always aborts here. In this patch, we add another check of ROM version again, and if the device needs patching, the probe continues. For that, a slight refactoring of btusb_qca_send_vendor_req() was required so that the probe function can pass usb_device pointer directly before allocating hci_dev stuff. Fixes: commit f44cb4b19ed4 ("Bluetooth: btusb: Fix quirk for Atheros 1525/QCA6174") Bugzilla: http://bugzilla.opensuse.org/show_bug.cgi?id=1082504 Tested-by: Ivan Levshin <ivan.levshin@microfocus.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-05-29Bluetooth: btusb: Add a new Realtek 8723DE ID 2ff8:b011Jian-Hong Pan
Without this patch we cannot turn on the Bluethooth adapter on ASUS E406MA. T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=2ff8 ProdID=b011 Rev= 2.00 S: Manufacturer=Realtek S: Product=802.11n WLAN Adapter S: SerialNumber=00e04c000001 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA 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=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) 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=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-05-18Bluetooth: Add a new 13d3:3496 QCA_ROME deviceJoão Paulo Rechi Vita
Without this patch we can't establish a SCO connection with this adapter. This adapter is named "IMC Networks" under lsusb. T: Bus=01 Lev=01 Prnt=01 Port=07 Cnt=02 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3496 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: João Paulo Rechi Vita <jprvita@endlessm.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-05-18Bluetooth: btqca: Add AR3002 rampatch supportLoic Poulain
This patch adds rampatch download compatibility for ROME >= 3.2. Starting with ROME 3.2, the 'download mode' field of the rampatch header indicates if the controller acknowledges (or not) the received rampatch segments. If not, we need to send all the segments without expecting any event from the controller (except for the last segment). Goal is (I assume) to speed-up rampatch download. This fixes BT on Dragonboard-600c P2 which includes the following BT controller: hci0: ROME Patch Version Request hci0: Product:0x00000008 hci0: Patch :0x00000111 hci0: ROM :0x00000302 hci0: SOC :0x00000023 Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-05-18Bluetooth: hci_ldisc: Provide a 'default' switch caseFabio Estevam
When both CONFIG_BT_HCIUART_INTEL and CONFIG_BT_HCIUART_BCM are not selected, sparse complains like this: drivers/bluetooth/hci_ldisc.c:437:9: warning: switch with no cases Fix the sparse warning by proving a default switch case. Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-05-18Bluetooth: btusb: add ID for LiteOn 04ca:301aVic Wei
Contains a QCA6174A chipset, with USB BT. Let's support loading firmware on it. From usb-devices: T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 2.01 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04ca ProdID=301a 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 I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb Signed-off-by: Vic Wei <vwei@codeaurora.org> Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-05-18Bluetooth: btbcm: btbcm_initialize(): Initialize hw_name to "BCM"Hans de Goede
Initialize hw_name to "BCM", this avoids the need for a number of NULL checks on hw_name later. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-05-18Bluetooth: btbcm: Remove duplicate code from btbcm_setup_patchram()Hans de Goede
btbcm_setup_patchram() starts with initializing the controller (and getting the firmware filename) and then after loading the firmware, does a re-init. This almost entirely duplicates the code in btbcm_initialize(), use that function instead. 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: btbcm: Make btbcm_initialize() also work for USB connected devicesHans de Goede
Make btbcm_initialize() also work for USB connected device, btbcm_initialize() and btbcm_setup_patchram() are quite similar, this is a preparation patch for making btbcm_setup_patchram() use btbcm_initialize() to remove the code duplication. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-05-18Bluetooth: btbcm: Factor out common code to determine subversionHans de Goede
We are using the same loop in both the UART and USB bus cases, refactor things a bit to share the loop. This is mostly meant to improve readability. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-05-18Bluetooth: btbcm: Stop using upper nibble of rev to chose between uart/USB pathsHans de Goede
btbcm_setup_patchram() was using the upper nibble of the revision code to determine if we are dealing with an uart or USB connected bcm-bt device, but just as btbcm_initialize() has started accepting 1 and 2 as uart connected devices, I've now encountered an USB connected device (0a5c:216c) which has 0 in the upper nibble. So it seems that the upper nibble is not really a reliable indicator of the bus type. Instead check hdev->bus which does give us a reliable indication. This fixes the patchram code trying to load the patchram by the fallback BCM.hcd filename, now it correctly requests BCM43142A0-0a5c-216c.hcd. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-05-18Bluetooth: hci_qca: Add serdev supportThierry Escande
Add support for Qualcomm serial slave devices. Probe the serial device, retrieve its maximum speed and register a new hci uart device. Signed-off-by: Thierry Escande <thierry.escande@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-05-18Bluetooth: hci_qca: Avoid missing rampatch failure with userspace fw loaderAmit Pundir
AOSP use userspace firmware loader to load firmwares, which will return -EAGAIN in case qca/rampatch_00440302.bin is not found. Since there is no rampatch for dragonboard820c QCA controller revision, just make it work as is. CC: Loic Poulain <loic.poulain@linaro.org> CC: Nicolas Dechesne <nicolas.dechesne@linaro.org> CC: Marcel Holtmann <marcel@holtmann.org> CC: Johan Hedberg <johan.hedberg@gmail.com> CC: Stable <stable@vger.kernel.org> Signed-off-by: Amit Pundir <amit.pundir@linaro.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-05-18Bluetooth: btqcomsmd: Fix rx/tx statsLoic Poulain
HCI RX/TX byte counters were only incremented when sending ACL packets. To reflect the real HCI traffic, we need to increment these counters on HCI events and HCI commands as well. Increment error counter on rpmsg errors. Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-05-18Bluetooth: hci_bcm: Remove irq-active-low DMI quirk for the Thinkpad 8Hans de Goede
Interrupts specified through an "Interrupt" ACPI resource (versus through a "GpioInt" resource) are now always assumed to be active low. When this change was originally made the Thinkpad 8 quirk was kept around because it was uncertain if the Thinkpad 8 uses an "Interrupt" or a "GpioInt" resource. Bug https://bugzilla.kernel.org/show_bug.cgi?id=196701 has a DSDT for the Thinkpad 8 attached and it uses an "Interrupt" resource, so the quirk is not necessary and the quirk, as well as the irq-active-low quirk handling code can be removed. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-05-18Bluetooth: hci_bcm: Add broken-irq dmi blacklist and add Meegopad T08 to itHans de Goede
The Meegopad T08 hdmi-stick (think Intel computestick) has a brcm43430 wifi/bt combo chip. The BCM2E90 ACPI device describing the BT part does contain a valid ActiveLow GpioInt entry, but the GPIO it points to never goes low, so either the IRQ pin is not connected, or the ACPI resource- table points to the wrong GPIO. Eitherway things will not work if we try to use the specified IRQ, this commits adds a DMI based broken-irq blacklist and disables use of the IRQ and thus also runtime-pm for devices on this list. This blacklist starts with the the Meegopad T08, fixing bluetooth not working on this hdmi-stick. Since this is not a battery powered device the loss of runtime-pm is not really an issue. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-04-30Bluetooth: btusb: Add Dell XPS 13 9360 to btusb_needs_reset_resume_tableHans de Goede
The Dell XPS 13 9360 uses a QCA Rome chip which needs to be reset (and have its firmware reloaded) for bluetooth to work after suspend/resume. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1514836 Cc: stable@vger.kernel.org Cc: Garrett LeSage <glesage@redhat.com> Reported-and-tested-by: Garrett LeSage <glesage@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-04-30Bluetooth: btusb: Only check needs_reset_resume DMI table for QCA rome chipsetsHans de Goede
Jeremy Cline correctly points out in rhbz#1514836 that a device where the QCA rome chipset needs the USB_QUIRK_RESET_RESUME quirk, may also ship with a different wifi/bt chipset in some configurations. If that is the case then we are needlessly penalizing those other chipsets with a reset-resume quirk, typically causing 0.4W extra power use because this disables runtime-pm. This commit moves the DMI table check to a btusb_check_needs_reset_resume() helper (so that we can easily also call it for other chipsets) and calls this new helper only for QCA_ROME chipsets for now. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1514836 Cc: stable@vger.kernel.org Cc: Jeremy Cline <jcline@redhat.com> Suggested-by: Jeremy Cline <jcline@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-04-30Revert "Bluetooth: btusb: Fix quirk for Atheros 1525/QCA6174"Hans de Goede
Commit f44cb4b19ed4 ("Bluetooth: btusb: Fix quirk for Atheros 1525/QCA6174") is causing bluetooth to no longer work for several people, see: https://bugzilla.redhat.com/show_bug.cgi?id=1568911 So lets revert it for now and try to find another solution for devices which need the modified quirk. Cc: stable@vger.kernel.org Cc: Takashi Iwai <tiwai@suse.de> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-04-01Bluetooth: Set HCI_QUIRK_SIMULTANEOUS_DISCOVERY for BTUSB_QCA_ROMEVic Wei
QCA Rome controllers can do both LE scan and BR/EDR inquiry at once. Signed-off-by: Vic Wei <vwei@codeaurora.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-04-01Bluetooth: btrsi: remove unused including <linux/version.h>Wei Yongjun
Remove including <linux/version.h> that don't need it. Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-04-01Bluetooth: hci_bcm: Remove DMI quirk for the MINIX Z83-4Ian W MORRISON
As Interrupt resource specified IRQs are now assumed to be always active-low the DMI quirk for the MINIX Z83-4 is no longer required. Signed-off-by: Ian W MORRISON <ianwmorrison@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-04-01Bluetooth: Remove unused btuart_cs driverMarcel Holtmann
With patch 279c936153199 the btuart_cs driver has been deprecated in favor of serial_cs + hci_uart combination. static struct pcmcia_device_id btuart_ids[] = { /* don't use this driver. Use serial_cs + hci_uart instead */ PCMCIA_DEVICE_NULL }; Intead of keeping it around, just remove it since it is not even assigned to any PCMCIA identifiers anymore. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2018-04-01Bluetooth: bpa10x: Use separate h4_recv_buf helperMarcel Holtmann
When adding the alignment and padding support for H:4 packet processing for the Nokia driver, it broke the h4_recv_buf usage within bpa10x driver. To fix this use a separate helper function and placing it into a dedicated h4_recv.h header file. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2018-04-01Bluetooth: hci_ll: Convert to use h4_recv_buf helperMarcel Holtmann
The HCILL or eHCILL protocol from TI is actually an H:4 protocol with a few extra events and thus can also use the h4_recv_buf helper. Instead of open coding the same funtionality add the extra events to the packet description table and use h4_recv_buf. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Tested-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2018-04-01Bluetooth: hci_bcm: Add ACPI HIDs found in Windows .inf files and DSTDsHans de Goede
Now that we need just an ACPI HID in the table, and the driver auto- configures itself otherwise, we can easily add a bunch of known ACPI HIDs. This avoids having to add these 1 by 1 as devices with one are encountered by users. This commit may seem as if it simply adds all IDs between BCM2E00-BCM2EAC, but that is not true, all these IDs were found in actual .inf files and the range is not entirely continuous, the following IDs are not added: BCM2E6A, BCM2E6C, BCM2E8F and BCM2E91 because I did not see these in any .inf files. As for the large amount of IDs this seems to be caused by Broadcom using a separate ID for every bluetooth module using their chips. E.g. BCM2EA6 seems to be specifically for the Raspberry Pi 3. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-04-01Bluetooth: hci_bcm: Do not tie GPIO pin order to a specific ACPI HIDHans de Goede
Since I've been doing a lot of work on Linux Bay Trail / Cherry Trail support, I've gathered a collection of ACPI DSDTs from about 50 such machines. Looking at these DSTDs many have an ACPI device entry describing a bcm bluetooth device (often disabled in the DSDT), quite a few of these ACPI device entries have a resource-table where the order does not match with the order currently associated with the HID of that entry in the bcm_acpi_match table. Looking at the Windows .inf files, there is nothing indicating a specific order there, so I believe that there is no 1:1 mapping between the ACPI HID and the order in which the resources are listed. Therefor this commit replaces the hardcoded mapping based on ACPI HID, with code which actually checks in which order the resources are listed and bases the gpio-mapping on that. This should ensure that we always pick the right mapping and this will make adding new ACPI HIDs to the driver easier. This has been tested on the following devices: -Asus T100CHI BCM2E39 / brcmfmac43241b4-sdio / BCM4324B3-37.4M.hcd -Asus T100TA BCM2E39 / brcmfmac43241b4-sdio / BCM4324B3-37.4M.hcd -Asus T200TA BCM2E65 / brcmfmac43340-sdio / BCM43341B0-37.4M.hcd -Jumper ezPad mini 3 BCM2E74 / brcmfmac43430a0-sdio / BCM4343A0-26M.hcd -Acer Iconia Tab8 w1-8 BCM2E83 / brcmfmac4330-sdio / BCM4330B1-26M.hcd -Chuwi Vi8 plus(CWI519) BCM2EAA / brcmfmac43430-sdio / BCM43430A1-26M.hcd Which together cover all 3 combinations of using an Interrupt resource / GpioInt resource as first resource / GpioInt resource as last resource. Tested-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-04-01Bluetooth: hci_bcm: Remove duplication in gpio-mappings declarationHans de Goede
We declare the same set of const acpi_gpio_params twice with different names, besides the needless duplication this naming leads to a sortof double indirection which also makes it harder to see how the mapping is actually setup. This commit renames the first set to have generic names, which better describe the contents of the mapping and drops the second set. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-04-01Bluetooth: hci_bcm: Add 6 new ACPI HIDsHans de Goede
Add 6 new ACPI HIDs to enable bluetooth on devices using these HIDs, I've tested the following HIDs / devices: BCM2E74: Jumper ezPad mini 3 BCM2E83: Acer Iconia Tab8 w1-810 BCM2E90: Meegopad T08 BCM2EAA: Chuwi Vi8 plus (CWI519) The reporter of Red Hat bugzilla 1554835 has tested: BCM2E84: Lenovo Yoga2 The reporter of kernel bugzilla 274481 has tested: BCM2E38: Toshiba Encore Note the Lenovo Yoga2 and Toshiba Encore also needs the earlier patch to treat all Interrupt ACPI resources as active low. Cc: stable@vger.kernel.org Buglink: https://bugzilla.kernel.org/attachment.cgi?id=274481 Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1554835 Reported-and-tested-by: Robert R. Howell <rhowell@uwyo.edu> Reported-and-tested-by: Christian Herzog <daduke@daduke.org> Tested-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-04-01Bluetooth: hci_bcm: Treat Interrupt ACPI resources as always being active-lowHans de Goede
Older devices with a serdev attached bcm bt hci, use an Interrupt ACPI resource to describe the IRQ (rather then a GpioInt resource). These device seem to all claim the IRQ is active-high and seem to all need a DMI quirk to treat it as active-low. Instead simply always assume that Interrupt resource specified IRQs are always active-low. This fixes the bt device not being able to wake the host from runtime- suspend on the: Asus T100TAM, Asus T200TA, Lenovo Yoga2 and the Toshiba Encore, without the need to add 4 new DMI quirks for these models. This also allows us to remove 2 DMI quirks for the Asus T100TA and Asus T100CHI series. Likely the 2 remaining quirks can also be removed but I could not find a DSDT of these devices to verify this. Cc: stable@vger.kernel.org Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=198953 Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1554835 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-04-01Bluetooth: hci_bcm: Add irq_polarity module optionHans de Goede
Add irq_polarity module option for easier troubleshooting of irq-polarity issues. Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
generated by cgit 1.2.3-korg (git 2.39.0) at 2024-05-25 14:34:35 +0000