aboutsummaryrefslogtreecommitdiff
path: root/drivers/bluetooth
AgeCommit message (Collapse)AuthorFilesLines
2018-08-03Bluetooth: btusb: Use bt_dev_err for Intel firmware loading errorsMarcel Holtmann1-40/+37
Replace the BT_ERR functions with bt_dev_err to get a consistent error printout that always prefixes the HCI device identifier. Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2018-08-03Bluetooth: btusb: Release RF resource on BT shutdownAmit K Bag1-0/+16
Issue description: Intel 7265 shares the same RF with Wifi and BT. In the shutdown scenario turn off BT, followed by turn WiFi off and on causing error in RF calibration in WiFi Module Solution: before shutdown BT ensure any RF activity to clear by HCI reset command. Reference Logs: ERR kernel: [ 386.193284] iwlwifi 0000:01:00.0: Failed to run INIT calibrations: -5 ERR kernel: [ 386.193298] iwlwifi 0000:01:00.0: Failed to run INIT ucode: -5 ERR kernel: [ 386.193309] iwlwifi 0000:01:00.0: Failed to start RT ucode: -5 Signed-off-by: Amit K Bag <[email protected]> Singed-off-by: Chethan T N <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-07-23bluetooth: hci_qca: Replace GFP_ATOMIC with GFP_KERNELJia-Ju Bai1-2/+2
qca_open() and qca_set_baudrate() are never called in atomic context. They call kzalloc() and bt_skb_alloc() with GFP_ATOMIC, which is not necessary. GFP_ATOMIC can be replaced with GFP_KERNEL. This is found by a static analysis tool named DCNS written by myself. I also manually check the kernel code before reporting it. Signed-off-by: Jia-Ju Bai <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-07-23bluetooth: hci_intel: Replace GFP_ATOMIC with GFP_KERNEL in ↵Jia-Ju Bai1-1/+1
inject_cmd_complete() inject_cmd_complete() is only called by intel_dequeue(), which is never called in atomic context. inject_cmd_complete() calls bt_skb_alloc() with GFP_ATOMIC, which is not necessary. GFP_ATOMIC can be replaced with GFP_KERNEL. This is found by a static analysis tool named DCNS written by myself. I also manually check the kernel code before reporting it. Signed-off-by: Jia-Ju Bai <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-07-23bluetooth: btusb: Replace GFP_ATOMIC with GFP_KERNEL in inject_cmd_complete()Jia-Ju Bai1-1/+1
inject_cmd_complete() is only called by btusb_send_frame_intel(), which is set to hdev->send, and hdev->send() is never called in atomic context. inject_cmd_complete() calls bt_skb_alloc() with GFP_ATOMIC, which is not necessary. GFP_ATOMIC can be replaced with GFP_KERNEL. This is found by a static analysis tool named DCNS written by myself. I also manually check the kernel code before reporting it. Signed-off-by: Jia-Ju Bai <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-07-23bluetooth: btmrvl_sdio: Replace GFP_ATOMIC with GFP_KERNEL in ↵Jia-Ju Bai1-1/+1
btmrvl_sdio_card_to_host() btmrvl_sdio_card_to_host() is never called in atomic context. It calls bt_skb_alloc() with GFP_ATOMIC, which is not necessary. GFP_ATOMIC can be replaced with GFP_KERNEL. This is found by a static analysis tool named DCNS written by myself. I also manually check the kernel code before reporting it. Signed-off-by: Jia-Ju Bai <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-07-23bluetooth: bpa10x: Replace GFP_ATOMIC with GFP_KERNEL in bpa10x_send_frame()Jia-Ju Bai1-3/+3
bpa10x_send_frame() is only set to hdev->send, and hdev->send() is never called in atomic context. bpa10x_send_frame() calls usb_alloc_urb(), kmalloc() and usb_submit_urb() with GFP_ATOMIC, which is not necessary. GFP_ATOMIC can be replaced with GFP_KERNEL. This is found by a static analysis tool named DCNS written by myself. I also manually check the kernel code before reporting it. Signed-off-by: Jia-Ju Bai <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-07-23bluetooth: bluecard_cs: Replace GFP_ATOMIC with GFP_KERNEL in ↵Jia-Ju Bai1-1/+1
bluecard_hci_set_baud_rate() bluecard_hci_set_baud_rate() is never called in atomic context. bluecard_hci_set_baud_rate() is only by bluecard_hci_open(), which is set to hdev->open, and hdev->open() is never called in atomic context. bluecard_hci_set_baud_rate() calls bt_skb_alloc() with GFP_ATOMIC, which is not necessary. GFP_ATOMIC can be replaced with GFP_KERNEL. This is found by a static analysis tool named DCNS written by myself. I also manually check the kernel code before reporting it. Signed-off-by: Jia-Ju Bai <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-07-23bluetooth: bfusb: Replace GFP_ATOMIC with GFP_KERNEL in bfusb_send_frame()Jia-Ju Bai1-1/+1
bfusb_send_frame() is only set to hdev->send, and hdev->send() is never called in atomic context. bfusb_send_frame() calls bt_skb_alloc() with GFP_ATOMIC, which is not necessary. GFP_ATOMIC can be replaced with GFP_KERNEL. This is found by a static analysis tool named DCNS written by myself. I also manually check the kernel code before reporting it. Signed-off-by: Jia-Ju Bai <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-07-06Bluetooth: btusb: use irqsave() in URB's complete callbackSebastian Andrzej Siewior1-8/+12
The USB completion callback does not disable interrupts while acquiring the ->lock. We want to remove the local_irq_disable() invocation from __usb_hcd_giveback_urb() and therefore it is required for the callback handler to disable the interrupts while acquiring the lock. The callback may be invoked either in IRQ or BH context depending on the USB host controller. Use the _irqsave variant of the locking primitives. Cc: Marcel Holtmann <[email protected]> Cc: Johan Hedberg <[email protected]> Cc: [email protected] Signed-off-by: Sebastian Andrzej Siewior <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-07-06Bluetooth: Add a new Realtek 8723DE ID 0bda:b009Jian-Hong Pan1-0/+1
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 <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-06-17bluetooth: hci_nokia: Don't include linux/unaligned/le_struct.h directly.David S. Miller1-1/+1
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 <[email protected]>
2018-05-30Bluetooth: btusb: Add additional device ID for RTL8822BEArtiom Vaskov1-0/+1
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 <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-05-30Bluetooth: hci_serdev: Fix HCI_UART_INIT_PENDING not workingHans de Goede3-1/+3
Init hci_uart->init_ready so that hci_uart_init_ready() works properly. Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-05-30Bluetooth: hci_serdev: Move serdev_device_close/open into common hci_serdev codeHans de Goede4-16/+9
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 <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-05-30Bluetooth: hci_uart: Restore hci_dev->flush callback on open()Hans de Goede2-17/+22
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 <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-05-30Bluetooth: btmrvl: Re-use kstrtol_from_user()Andy Shevchenko1-21/+3
Re-use kstrtol_from_user() instead of open coded variant. Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-05-30Bluetooth: hci_qca: Fix "Sleep inside atomic section" warningThierry Escande1-1/+1
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 <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-05-29Bluetooth: btusb: Add Dell Inspiron 5565 to btusb_needs_reset_resume_tableHans de Goede1-0/+7
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 <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-05-29Bluetooth: hci_serdev: Removed unnecessary curly bracesVaibhav Murkute1-2/+1
checkpatch.pl shows a warning for these unnecessary curly braces. so just removed those curly braces. Signed-off-by: Vaibhav Murkute <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-05-29Bluetooth: btmrvl: support sysfs initiated firmware coredumpArend van Spriel4-42/+8
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 <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-05-29Bluetooth: btusb: Apply QCA Rome patches for some ATH3012 modelsTakashi Iwai1-7/+25
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 <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-05-29Bluetooth: btusb: Add a new Realtek 8723DE ID 2ff8:b011Jian-Hong Pan1-0/+3
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 <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-05-18Bluetooth: Add a new 13d3:3496 QCA_ROME deviceJoão Paulo Rechi Vita1-0/+1
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 <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-05-18Bluetooth: btqca: Add AR3002 rampatch supportLoic Poulain2-56/+59
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 <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-05-18Bluetooth: hci_ldisc: Provide a 'default' switch caseFabio Estevam1-0/+2
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 <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-05-18Bluetooth: btusb: add ID for LiteOn 04ca:301aVic Wei1-0/+1
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 <[email protected]> Signed-off-by: Matthias Kaehlcke <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-05-18Bluetooth: btbcm: btbcm_initialize(): Initialize hw_name to "BCM"Hans de Goede1-5/+4
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 <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-05-18Bluetooth: btbcm: Remove duplicate code from btbcm_setup_patchram()Hans de Goede1-73/+5
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 <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-05-18Bluetooth: btbcm: Allow using btbcm_initialize() for reinitHans de Goede3-26/+14
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 <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-05-18Bluetooth: btbcm: Make btbcm_initialize() also work for USB connected devicesHans de Goede1-29/+43
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 <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-05-18Bluetooth: btbcm: Factor out common code to determine subversionHans de Goede1-22/+18
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 <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-05-18Bluetooth: btbcm: Stop using upper nibble of rev to chose between uart/USB pathsHans de Goede1-9/+6
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 <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-05-18Bluetooth: hci_qca: Add serdev supportThierry Escande2-2/+109
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 <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-05-18Bluetooth: hci_qca: Avoid missing rampatch failure with userspace fw loaderAmit Pundir1-0/+6
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 <[email protected]> CC: Nicolas Dechesne <[email protected]> CC: Marcel Holtmann <[email protected]> CC: Johan Hedberg <[email protected]> CC: Stable <[email protected]> Signed-off-by: Amit Pundir <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-05-18Bluetooth: btqcomsmd: Fix rx/tx statsLoic Poulain1-0/+10
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 <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-05-18Bluetooth: hci_bcm: Remove irq-active-low DMI quirk for the Thinkpad 8Hans de Goede1-20/+0
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 <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-05-18Bluetooth: hci_bcm: Add broken-irq dmi blacklist and add Meegopad T08 to itHans de Goede1-0/+23
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 <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-04-30Bluetooth: btusb: Add Dell XPS 13 9360 to btusb_needs_reset_resume_tableHans de Goede1-0/+7
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: [email protected] Cc: Garrett LeSage <[email protected]> Reported-and-tested-by: Garrett LeSage <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-04-30Bluetooth: btusb: Only check needs_reset_resume DMI table for QCA rome chipsetsHans de Goede1-3/+7
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: [email protected] Cc: Jeremy Cline <[email protected]> Suggested-by: Jeremy Cline <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-04-30Revert "Bluetooth: btusb: Fix quirk for Atheros 1525/QCA6174"Hans de Goede1-1/+1
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: [email protected] Cc: Takashi Iwai <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-04-01Bluetooth: Set HCI_QUIRK_SIMULTANEOUS_DISCOVERY for BTUSB_QCA_ROMEVic Wei1-0/+1
QCA Rome controllers can do both LE scan and BR/EDR inquiry at once. Signed-off-by: Vic Wei <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-04-01Bluetooth: btrsi: remove unused including <linux/version.h>Wei Yongjun1-1/+0
Remove including <linux/version.h> that don't need it. Signed-off-by: Wei Yongjun <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-04-01Bluetooth: hci_bcm: Remove DMI quirk for the MINIX Z83-4Ian W MORRISON1-7/+0
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 <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-04-01Bluetooth: Remove unused btuart_cs driverMarcel Holtmann3-692/+0
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 <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2018-04-01Bluetooth: bpa10x: Use separate h4_recv_buf helperMarcel Holtmann3-3/+162
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 <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2018-04-01Bluetooth: hci_ll: Convert to use h4_recv_buf helperMarcel Holtmann2-145/+70
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 <[email protected]> Tested-by: Tony Lindgren <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2018-04-01Bluetooth: hci_bcm: Add ACPI HIDs found in Windows .inf files and DSTDsHans de Goede1-0/+141
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 <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-04-01Bluetooth: hci_bcm: Do not tie GPIO pin order to a specific ACPI HIDHans de Goede1-36/+55
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 <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-04-01Bluetooth: hci_bcm: Remove duplication in gpio-mappings declarationHans de Goede1-13/+9
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 <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.