aboutsummaryrefslogtreecommitdiff
path: root/drivers/bluetooth
AgeCommit message (Collapse)AuthorFilesLines
2019-04-23Bluetooth: hci_h5: fix spelling mistake "sliped" -> "slipped"Colin Ian King1-1/+1
There is a spelling mistake in a BT_DBG debug message. Fix it. Signed-off-by: Colin Ian King <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2019-04-23Bluetooth: mediatek: Fixed incorrect type in assignmentSean Wang1-1/+1
Fixed warning: incorrect type in assignment reported by kbuild test robot. The detailed warning is shown as below. make ARCH=x86_64 allmodconfig make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' All warnings (new ones prefixed by >>): btmtkuart.c:671:18: sparse: warning: incorrect type in assignment (different base types) btmtkuart.c:671:18: sparse: expected unsigned int [usertype] baudrate btmtkuart.c:671:18: sparse: got restricted __le32 [usertype] sparse warnings: (new ones prefixed by >>) btmtkuart.c:671:18: sparse: warning: incorrect type in assignment (different base types) btmtkuart.c:671:18: sparse: expected unsigned int [usertype] baudrate btmtkuart.c:671:18: sparse: got restricted __le32 [usertype] vim +671 drivers/bluetooth/btmtkuart.c 659 660 static int btmtkuart_change_baudrate(struct hci_dev *hdev) 661 { 662 struct btmtkuart_dev *bdev = hci_get_drvdata(hdev); 663 struct btmtk_hci_wmt_params wmt_params; 664 u32 baudrate; 665 u8 param; 666 int err; 667 668 /* Indicate the device to enter the probe state the host is 669 * ready to change a new baudrate. 670 */ > 671 baudrate = cpu_to_le32(bdev->desired_speed); 672 wmt_params.op = MTK_WMT_HIF; Fixes: 22eaf6c9946a ("Bluetooth: mediatek: add support for MediaTek MT7663U and MT7668U UART devices") Reported-by: kernel test robot <[email protected]> Signed-off-by: Sean Wang <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2019-04-23Bluetooth: btmtksdio: fix uninitialized symbol errors in btmtksdio_rx_packetSean Wang1-10/+0
Fixed all the below warnings. They would probably cause the following error handling path would use the uninitialized value and then produce unexpected behavior. drivers/bluetooth/btmtksdio.c:470:2: warning: ‘old_len’ may be used uninitialized in this function [-Wmaybe-uninitialized] print_hex_dump(KERN_ERR, "err sdio rx: ", DUMP_PREFIX_NONE, 4, 1, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ old_data, old_len, true); ~~~~~~~~~~~~~~~~~~~~~~~~ drivers/bluetooth/btmtksdio.c:376:15: note: ‘old_len’ was declared here unsigned int old_len; ^~~~~~~ drivers/bluetooth/btmtksdio.c:470:2: warning: ‘old_data’ may be used uninitialized in this function [-Wmaybe-uninitialized] print_hex_dump(KERN_ERR, "err sdio rx: ", DUMP_PREFIX_NONE, 4, 1, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ old_data, old_len, true); ~~~~~~~~~~~~~~~~~~~~~~~~ drivers/bluetooth/btmtksdio.c:375:17: note: ‘old_data’ was declared here unsigned char *old_data; ^~~~~~~~ v2: Remove old_len and old_data because the error path for sdio_readsb also seems wrong. And change the prefix from "mediatek" to "btmtksdio". Fixes: d74eef2834b5 ("Bluetooth: mediatek: add support for MediaTek MT7663S and MT7668S SDIO devices") Reported-by: Dan Carpenter <[email protected]> Reported-by: Marcel Holtmann <[email protected]> Signed-off-by: Sean Wang <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2019-04-23Bluetooth: btsdio: Use module_sdio_driver helperSean Wang1-14/+1
Macro module_sdio_driver is used for drivers whose init and exit paths only register and unregister to SDIO API. So remove boilerplate code to make code simpler by using module_sdio_driver. Signed-off-by: Sean Wang <[email protected]> Acked-by: Ulf Hansson <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2019-04-23Bluetooth: mediatek: Use module_sdio_driver helperSean Wang1-14/+1
Macro module_sdio_driver is used for drivers whose init and exit paths only register and unregister to SDIO API. So remove boilerplate code to make code simpler by using module_sdio_driver. Suggested-by: Marcel Holtmann <[email protected]> Signed-off-by: Sean Wang <[email protected]> Acked-by: Ulf Hansson <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2019-04-23Bluetooth: btqca: Fix misspelling of 'baudrate'Matthias Kaehlcke1-1/+1
Rename the misspelled struct 'qca_bardrate' to 'qca_baudrate' Signed-off-by: Matthias Kaehlcke <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2019-04-23Bluetooth: hci_qca: Add helper function to get the chip familyMatthias Kaehlcke1-19/+26
Many functions obtain a 'struct qca_serdev' only to read the btsoc_type field. Add a helper function that encapsulates this. This also fixes crashes observed on platforms with ROME controllers that are instantiated through ldisc and not as serdev clients. The crashes are caused by NULL pointer dereferentiations, which stem from the driver's assumption that a QCA HCI device is always associated with a serdev device. Fixes: fa9ad876b8e0 ("Bluetooth: hci_qca: Add support for Qualcomm Bluetooth chip wcn3990") Reported-by: Balakrishna Godavarthi <[email protected]> Signed-off-by: Matthias Kaehlcke <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2019-04-23Bluetooth: mediatek: add support for MediaTek MT7663S and MT7668S SDIO devicesSean Wang3-0/+991
This adds the support of enabling MT7663S and MT7668S SDIO-based Bluetooth function. There are quite many differences between MT766[3,8]S and standard Bluetooth SDIO devices such as Type-A and Type-B devices. For example, MT766[3,8]S have its own SDIO registers layout, definition, SDIO packet format, and the specific flow should be programmed on them to complete the device initialization and low power control and so on. Currently, there are many independent programming sequences from the transport which are exactly the same as the ones in btusb.c about MediaTek support [1] and btmtkuart.c. We can try to split the transport independent Bluetooth setups on the advance, place them into the common files and allow varous transport drivers to reuse them in the future. [1] http://lists.infradead.org/pipermail/linux-mediatek/2019-January/017074.html Signed-off-by: Sean Wang <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2019-04-09Bluetooth: btusb: request wake pin with NOAUTOENBrian Norris1-1/+1
Badly-designed systems might have (for example) active-high wake pins that default to high (e.g., because of external pull ups) until they have an active firmware which starts driving it low. This can cause an interrupt storm in the time between request_irq() and disable_irq(). We don't support shared interrupts here, so let's just pre-configure the interrupt to avoid auto-enabling it. Fixes: fd913ef7ce61 ("Bluetooth: btusb: Add out-of-band wakeup support") Fixes: 5364a0b4f4be ("arm64: dts: rockchip: move QCA6174A wakeup pin into its USB node") Signed-off-by: Brian Norris <[email protected]> Reviewed-by: Matthias Kaehlcke <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2019-03-02Bluetooth: mediatek: add support for MediaTek MT7663U and MT7668U UART devicesSean Wang1-10/+271
This adds the support of enabling MT7663U and MT7668U Bluetooth function running on the top of btmtkuart driver. There are a few differences between MT766[3,8]U and MT7622 where MT766[3,8]U are standalone devices based on UART transport while MT7622 bluetooth is a built-in device on MediaTek SoC communicating with the host through BTIF serial transport. Thus, extra setup sequence is necessary for these standalone devices such as remote regulator and reset control via GPIO, baud rate changing handshake between the host and device and so on. Signed-off-by: Sean Wang <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2019-03-02Bluetooth: hci_qca: Reduce delay after sending baudrate request for WCN3990Matthias Kaehlcke1-8/+18
The current 300ms delay after a baudrate change is extremely long. For WCN3990 it is sufficient to wait 10ms after the baudrate change request has been sent over the wire. Signed-off-by: Matthias Kaehlcke <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2019-02-27Bluetooth: btusb: add QCA6174A compatible propertiesBrian Norris1-0/+2
We may need to specify a GPIO wake pin for this device, so add a compatible property for it. There are at least to USB PID/VID variations of this chip: one with a Lite-On ID and one with an Atheros ID. Signed-off-by: Brian Norris <[email protected]> Reviewed-by: Matthias Kaehlcke <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2019-02-27Bluetooth: hci_qca: Use msleep() instead of open coding itMatthias Kaehlcke1-3/+1
Call msleep() in qca_set_baudrate() instead of reimplementing it. Signed-off-by: Matthias Kaehlcke <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2019-02-27Bluetooth: hci_qca: Add delay after power-off pulseMatthias Kaehlcke1-3/+3
During initialization the power-on pulse is currently sent inmediately after the prior power-off pulse. With this initialization often fails at boot time: [ 15.205224] Bluetooth: hci0: setting up wcn3990 [ 17.341062] Bluetooth: hci0: command 0xfc00 tx timeout [ 22.101453] ERROR: Bluetooth initialization failed [ 25.337740] Bluetooth: hci0: Reading QCA version information failed (-110) After a power-off pulse wait 10ms to give the controller time to power off. Remove the previous short settling delay, it isn't needed anymore. Signed-off-by: Matthias Kaehlcke <[email protected]> Reviewed-by: Balakrishna Godavarthi <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2019-02-27Bluetooth: hci_qca: Move boot delay to qca_send_power_pulse()Matthias Kaehlcke1-3/+3
After sending a power on pulse the driver has a delay of 100ms to allow the host controller to boot. Move the delay into qca_send_power_pulse(), since it is directly related with the power-on pulse. Signed-off-by: Matthias Kaehlcke <[email protected]> Reviewed-by: Balakrishna Godavarthi <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2019-02-27Bluetooth: hci_qca: Pass boolean 'on/off' to qca_send_power_pulse()Matthias Kaehlcke1-4/+5
There are only two types of power pulses 'on' or 'off', pass a boolean instead of the power pulse 'command'. Signed-off-by: Matthias Kaehlcke <[email protected]> Reviewed-by: Balakrishna Godavarthi <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2019-02-26Bluetooth: hci_qca: Set HCI_QUIRK_USE_BDADDR_PROPERTY for wcn3990Matthias Kaehlcke1-0/+1
Set quirk for wcn3990 to read BD_ADDR from a firmware node property. Signed-off-by: Matthias Kaehlcke <[email protected]> Tested-by: Balakrishna Godavarthi <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2019-02-26Bluetooth: btqcomsmd: use HCI_QUIRK_USE_BDADDR_PROPERTYMatthias Kaehlcke1-28/+3
Use the HCI_QUIRK_USE_BDADDR_PROPERTY quirk to let the HCI core handle the reading of 'local-bd-address'. With this there is no need to set HCI_QUIRK_INVALID_BDADDR, the case of a non-existing or invalid fwnode property is handled by the core code. Signed-off-by: Matthias Kaehlcke <[email protected]> Reviewed-by: Balakrishna Godavarthi <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2019-02-26Bluetooth: hci_ldisc: Postpone HCI_UART_PROTO_READY bit set in ↵Kefeng Wang1-2/+1
hci_uart_set_proto() 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: [email protected] Signed-off-by: Kefeng Wang <[email protected]> Reviewed-by: Jeremy Cline <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2019-02-18Bluetooth: mediatek: update the common setup between MT7622 and other devicesSean Wang1-14/+190
Update the setup sequence on MT7622 to apply the same flow with MT7663U and MT7668U USB [1] as much as possible. These additional commands are required to parse the corresponding event to determine what current state the Bluetooth device is on and thus it's necessary to extend mtk_hci_wmt_sync to support the reading status in the same patch. [1] http://lists.infradead.org/pipermail/linux-mediatek/2019-January/017074.html Signed-off-by: Sean Wang <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2019-02-18Bluetooth: mediatek: pass a pointer to mtk_hci_wmt_syncSean Wang1-15/+48
Pass a structure pointer to mtk_hci_wmt_sync rather than several arguments to avoid take up additional stack area and be better to read the code. Signed-off-by: Sean Wang <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2019-02-18Bluetooth: mediatek: fix up an error path to restore bdev->tx_stateSean Wang1-0/+2
Restore bdev->tx_state with clearing bit BTMTKUART_TX_WAIT_VND_EVT when there is an error on waiting for the corresponding event. Fixes: 7237c4c9ec92 ("Bluetooth: mediatek: Add protocol support for MediaTek serial devices") Signed-off-by: Sean Wang <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2019-02-18Bluetooth: mediatek: trivial typo fixSean Wang1-1/+1
add a trivial typo fix from speicfic to specific Fixes: 7237c4c9ec92 ("Bluetooth: mediatek: Add protocol support for MediaTek serial devices") Signed-off-by: Sean Wang <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2019-02-18Bluetooth: hci_ldisc: Initialize hci_dev before open()Jeremy Cline1-7/+14
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: [email protected] Signed-off-by: Jeremy Cline <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2019-02-18Bluetooth: hci_qca: Disable IBS state machine and flush Tx bufferBalakrishna Godavarthi1-2/+15
During hci down we observed IBS sleep commands are queued in the Tx buffer and hci_uart_write_work is sending data to the chip which is not required as the chip is powered off. This patch will disable IBS and flush the Tx buffer before we turn off the chip. Signed-off-by: Balakrishna Godavarthi <[email protected]> Reviewed-by: Matthias Kaehlcke <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2019-02-18Bluetooth: hci_qca: Deassert RTS while baudrate change commandBalakrishna Godavarthi1-14/+15
This patch will help to stop frame reassembly errors while changing the baudrate. This is because host send a change baudrate request command to the chip with 115200 bps, Whereas chip will change their UART clocks to the enable for new baudrate and sends the response for the change request command with newer baudrate, On host side we are still operating in 115200 bps which results of reading garbage data. Here we are pulling RTS line, so that chip we will wait to send data to host until host change its baudrate. Signed-off-by: Balakrishna Godavarthi <[email protected]> Tested-by: Matthias Kaehlcke <[email protected]> Reviewed-by: Matthias Kaehlcke <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2019-02-18Bluetooth: hci_qca: use wait_until_sent() for power pulsesBalakrishna Godavarthi1-23/+15
wcn3990 requires a power pulse to turn ON/OFF along with regulators. Sometimes we are observing the power pulses are sent out with some time delay, due to queuing these commands. This is causing synchronization issues with chip, which intern delay the chip setup or may end up with communication issues. Signed-off-by: Balakrishna Godavarthi <[email protected]> Reviewed-by: Matthias Kaehlcke <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2019-02-18Bluetooth: remove redundant zero check on countColin Ian King1-3/+0
Variable count is never zero inside the loop so the check if count is zero is redundant and can be removed. Fix this. Detected by CoverityScan, CID#1466880 ("Logically dead code") Signed-off-by: Colin Ian King <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2019-01-29Bluetooth: btusb: Add shutdown routine for BTUSB_INTEL_NEW devicesRaghuram Hegde1-0/+19
If BT operations (BREDR inquiry/LE scan) were triggered through the stack, followed by BT turn off through 'hciconfig hci0 down', the controller would still be active and consume power. Also, there is a possibility that a race condition/ synchronization issue might arise on the subsequent BT turn on, as the controller might try to push the events that were queued up before processing the HCI Reset command. btusb_shutdown_intel_new routine shall reset the controller and stop all BT operation. Advantages: 1. Power save on the platform 2. Host and controller will be in Sync. Signed-off-by: Raghuram Hegde <[email protected]> Signed-off-by: Chethan T N <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2019-01-29Bluetooth: btusb: btusb_intel_cmd_timeout: use sleeping functionsRajat Jain1-3/+3
The btusb_intel_cmd_timeout() is called from workqueue contexts, so use the helper functions that can sleep. Signed-off-by: Rajat Jain <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2019-01-28Bluetooth: btrtl: Restore old logic to assume firmware is already loadedKai-Heng Feng1-3/+7
Realtek bluetooth may not work after reboot: [ 12.446130] Bluetooth: hci0: RTL: rtl: unknown IC info, lmp subver a99e, hci rev 826c, hci ver 0008 This is a regression introduced by commit 26503ad25de8 ("Bluetooth: btrtl: split the device initialization into smaller parts"). The new logic errors out early when no matching IC info can be found, in this case it means the firmware is already loaded. So let's assume the firmware is already loaded when we can't find matching IC info, like the old logic did. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=201921 Fixes: 26503ad25de8 ("Bluetooth: btrtl: split the device initialization into smaller parts") Cc: [email protected] # 4.19+ Signed-off-by: Kai-Heng Feng <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2019-01-25Bluetooth: btusb: Use the cmd_timeout method to reset the Intel BT chipRajat Jain1-0/+54
If the platform provides it, use the reset gpio to reset the Intel BT chip, as part of cmd_timeout handling. This has been found helpful on Intel bluetooth controllers where the firmware gets stuck and the only way out is a hard reset pin provided by the platform. Signed-off-by: Rajat Jain <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2019-01-22Bluetooth: btmrvl: Drop unused GPIO includesLinus Walleij1-2/+0
I can't see that these drivers use the old GPIO inlcudes in any way, drop <linux/gpio.h> and <linux/of_gpio.h>. Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2019-01-22Bluetooth: btmrvl: add support for sd8977 chipsetHemantkumar Suthar2-2/+38
This patch adds support for 8977 chipset to mwifiex with SDIO interface. Register offsets and supported feature flags are updated. Firmware image used will be mrvl/sd8977_uapsta.bin. Signed-off-by: Hemantkumar Suthar <[email protected]> Signed-off-by: Rakesh Parmar <[email protected]> Signed-off-by: Cathy Luo <[email protected]> Signed-off-by: Ganapathi Bhat <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2019-01-22Bluetooth: hci_uart: Check if socket buffer is ERR_PTR in h4_recv_buf()Myungho Jung2-0/+8
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: [email protected] Signed-off-by: Myungho Jung <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2019-01-22Bluetooth: btmrvl: lower log level of informational messageStefan Agner1-1/+1
The platform specific wake-up interrupt is optional. Don't print an error message in case it is missing, merely inform the user in this case. Signed-off-by: Stefan Agner <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2019-01-22Bluetooth: btmrvl: improve printk messagesStefan Agner1-3/+4
Use dev_* variants to print messages in drivers. Signed-off-by: Stefan Agner <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2019-01-22Bluetooth: hci_qca: Add helper to set device addressBalakrishna Godavarthi3-2/+30
This patch add qca_set_bdaddr() to set the device address for latest Qualcomm Bluetooth chipset wcn3990 and above. Signed-off-by: Balakrishna Godavarthi <[email protected]> Reviewed-by: Matthias Kaehlcke <[email protected]> Tested-by: Matthias Kaehlcke <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-12-19Bluetooth: hci_bcm: Handle specific unknown packets after firmware loadingJonathan Bakker1-0/+22
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 <[email protected]> Signed-off-by: Paweł Chmiel <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-12-19Bluetooth: btbcm: Add entry for BCM4329B1 UART bluetoothPaweł Chmiel1-0/+1
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 <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-12-19Bluetooth: btusb: Add support for Intel bluetooth device 8087:0029Raghuram Hegde1-35/+37
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 <[email protected]> Signed-off-by: Chethan T N <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-12-19Bluetooth: hci_h5: Turn off RTL8723BS on suspend, reprobe on resumeHans de Goede1-0/+52
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 <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-12-19Bluetooth: hci_h5: Add suspend / resume opsHans de Goede1-0/+29
Add support for vendor specific suspend / resume callbacks. Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-12-19Bluetooth: hci_intel: clean an indentation issue, remove extraneous spacesColin Ian King1-2/+2
Trivial fix to clean up an indentation issue, remove spaces Signed-off-by: Colin Ian King <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-12-19Bluetooth: hci_serdev: Remove setting of HCI_QUIRK_RESET_ON_CLOSE.Balakrishna Godavarthi1-3/+0
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 <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-12-19Bluetooth: Remove unnecessary smp_mb__after_atomic() barriersAndrea Parri2-18/+6
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 <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-12-19Bluetooth: btbcm: Add default address for BCM43430A0Chen-Yu Tsai1-1/+6
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 <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-12-19Bluetooth: hci_bcm: Add compatible string for BCM4330Chen-Yu Tsai1-0/+1
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 <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-12-19Bluetooth: hci_bcm: Add BCM20702A1 variantMaxime Ripard2-0/+7
The BCM20702A1 chip is a single-chip Bluetooth 4.0 controller and transceiver. It is found in the AMPAK AP6210 WiFi+BT package. Signed-off-by: Maxime Ripard <[email protected]> Tested-by: Ondrej Jirman <[email protected]> Signed-off-by: Chen-Yu Tsai <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2018-12-19Bluetooth: hci_bcm: Wait for device to come out of reset after power onChen-Yu Tsai1-0/+3
The datasheets for BCM20702 and BCM43438 both have power up time sequence graphs, however they are slightly different. Both chips also have an internal power-on-reset, which holds the chip in reset for a short time after the regulators are enabled. For the BCM20702, the time period from when the regulators are enabled, until the chip settles and comes out of sleep state, is 6564 ~ 8171 us. For the BCM43438, the graph only shows the time period from when the regulators are enabled until the chip responds by driving the host's CTS line low, assuming the host has already driven its RTS line low. This is shown to be 6.5 sleep cycles, with the sleep clock at 32.768 kHz. This is around 2 ms. Wait a full 10 ms after the regulators are enabled to account for signal rising times. Tested-by: Ondrej Jirman <[email protected]> Signed-off-by: Chen-Yu Tsai <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.