linux/drivers/bluetooth, branch v5.0

Bluetooth: hci_bcm: Handle specific unknown packets after firmware loading

2018-12-19T12:43:42Z

The Broadcom controller on aries S5PV210 boards sends out a couple of unknown packets after the firmware is loaded. This will cause logging of errors such as: Bluetooth: hci0: Frame reassembly failed (-84) This is probably also the case with other boards, as there are related Android userspace patches for custom ROMs such as https://review.lineageos.org/#/c/LineageOS/android_system_bt/+/142721/ Since this appears to be intended behaviour, treated them as diagnostic packets. Note that this is another variant of commit 01d5e44ace8a ("Bluetooth: hci_bcm: Handle empty packet after firmware loading") Signed-off-by: Jonathan Bakker Signed-off-by: Paweł Chmiel Signed-off-by: Marcel Holtmann

Bluetooth: btbcm: Add entry for BCM4329B1 UART bluetooth

2018-12-19T12:43:42Z

This patch adds the device ID for the BCM 4329 combo module used in the Samsung Aries based phones (Galaxy S and it's variants). ``` [ 11.508980] Bluetooth: hci0: BCM: chip id 41 [ 11.518975] Bluetooth: hci0: BCM: features 0x04 [ 11.550132] Bluetooth: hci0: BCM4329B1 [ 11.557046] Bluetooth: hci0: BCM4329B1 (002.002.023) build 0000 [ 13.737071] Bluetooth: hci0: BCM4329B1 (002.002.023) build 0744 ``` Output from hciconfig ``` hci0: Type: Primary Bus: UART BD Address: 43:29:B1:55:00:00 ACL MTU: 1021:6 SCO MTU: 64:1 UP RUNNING RX bytes:1675 acl:0 sco:0 events:145 errors:0 TX bytes:20426 acl:0 sco:0 commands:146 errors:0 Features: 0xbf 0xfe 0x8f 0xfe 0x9b 0xff 0x79 0x83 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH SNIFF Link mode: SLAVE ACCEPT Name: 'aries' Class: 0x000000 Service Classes: Unspecified Device Class: Miscellaneous, HCI Version: 2.1 (0x4) Revision: 0x2e8 LMP Version: 2.1 (0x4) Subversion: 0x4217 Manufacturer: Broadcom Corporation (15) ``` Signed-off-by: Paweł Chmiel Signed-off-by: Marcel Holtmann

Bluetooth: btusb: Add support for Intel bluetooth device 8087:0029

2018-12-19T06:38:21Z

Include the new USB product ID for Intel Bluetooth device 22260 family(CcPeak) The /sys/kernel/debug/usb/devices portion for this device is: T: Bus=01 Lev=01 Prnt=01 Port=02 Cnt=02 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=8087 ProdID=0029 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= 64 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 I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms Signed-off-by: Raghuram Hegde Signed-off-by: Chethan T N Signed-off-by: Marcel Holtmann

Bluetooth: hci_h5: Turn off RTL8723BS on suspend, reprobe on resume

2018-12-18T23:49:33Z

On many devices the RTL8723BS device gets reset during suspend/resume, causing it to lose its firmware and all state. Testing has shown it drops back to communicating at 115200 bps and sends sync-request packages, indicating it has been fully reset. This commit fixes this by queueing a reprobe on resume. This mirrors how USB RTL BT devices, which have the same problem, are handled in the btusb driver, there we set the USB_QUIRK_RESET_RESUME for all RTL devices, which also causes a reprobe on resume. The only difference is that here we need to do the reprobe ourselves. Since we are doing a full reprobe on resume now, we can also turn off the device on suspend to save power while suspended. Signed-off-by: Hans de Goede Signed-off-by: Marcel Holtmann

Bluetooth: hci_h5: Add suspend / resume ops

2018-12-18T23:49:30Z

Add support for vendor specific suspend / resume callbacks. Signed-off-by: Hans de Goede Signed-off-by: Marcel Holtmann

Bluetooth: hci_intel: clean an indentation issue, remove extraneous spaces

2018-12-18T23:46:30Z

Trivial fix to clean up an indentation issue, remove spaces Signed-off-by: Colin Ian King Signed-off-by: Marcel Holtmann

Bluetooth: hci_serdev: Remove setting of HCI_QUIRK_RESET_ON_CLOSE.

2018-12-18T23:41:59Z

HCI_QUIRK_RESET_ON_CLOSE quirk is required for BT v1.0 based devices, to send a reset command to the chip during hci device close. Serdev architecture is used for the latest BT chips, which doesn't require to send the reset command during close. If still chips required reset command during close, it would be better enabling it in the vendor probes or in proto setup. Signed-off-by: Balakrishna Godavarthi Signed-off-by: Marcel Holtmann

Bluetooth: Remove unnecessary smp_mb__after_atomic() barriers

2018-12-18T23:37:00Z

The barriers are redundant because atomic_test_and_clear_bit() already provides the required full ordering for the cases in question (that is, when the bit is cleared). Signed-off-by: Andrea Parri Signed-off-by: Marcel Holtmann

Bluetooth: btbcm: Add default address for BCM43430A0

2018-12-18T23:28:39Z

The BCM43430A0 has the default MAC address 43:43:A0:12:1F:AC if none is given. This address was found when enabling Bluetooth on a bunch of boards with the AMPAK AP6210 module, all sharing the same address. It also contains the sequence 4343A0, which is suspicious as that is also the name the chip identifies itself as. Add this to the list of default MAC addresses and leave it to the user to configure a valid one. Signed-off-by: Chen-Yu Tsai Signed-off-by: Marcel Holtmann

Bluetooth: hci_bcm: Add compatible string for BCM4330

2018-12-18T23:28:39Z

The BCM4330 chip is a 802.11 a/b/g/n + Bluetooth 4.0 + HS controller. This patch adds a compatible string match to the serdev driver for the Bluetooth part of the chip. Signed-off-by: Chen-Yu Tsai Signed-off-by: Marcel Holtmann