- 24 Jun, 2020 1 commit
-
-
Abhishek Pandit-Subedi authored
QCA_ROME sometimes gets into a state where it is unresponsive to commands. Since it doesn't have support for a reset gpio, reset the usb port when this occurs instead. Signed-off-by:
Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
- 23 Jun, 2020 3 commits
-
-
Sean Wang authored
Data RAM on the device have to be powered on before starting to download the firmware. Fixes: 9aebfd4a ("Bluetooth: mediatek: add support for MediaTek MT7663S and MT7668S SDIO devices") Co-developed-by:
Mark Chen <Mark-YW.Chen@mediatek.com> Signed-off-by:
Sean Wang <sean.wang@mediatek.com> Signed-off-by:
-
Sean Wang authored
Data RAM on the device have to be powered on before starting to download the firmware. Fixes: a1c49c43 ("Bluetooth: btusb: Add protocol support for MediaTek MT7668U USB devices") Co-developed-by:
-
Lihong Kou authored
In the case we set or free the global value listen_chan in different threads, we can encounter the UAF problems because the method is not protected by any lock, add one to avoid this bug. BUG: KASAN: use-after-free in l2cap_chan_close+0x48/0x990 net/bluetooth/l2cap_core.c:730 Read of size 8 at addr ffff888096950000 by task kworker/1:102/2868 CPU: 1 PID: 2868 Comm: kworker/1:102 Not tainted 5.5.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: events do_enable_set Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1fb/0x318 lib/dump_stack.c:118 print_address_description+0x74/0x5c0 mm/kasan/report.c:374 __kasan_report+0x149/0x1c0 mm/kasan/report.c:506 kasan_report+0x26/0x50 mm/kasan/common.c:641 __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:135 l2cap_chan_close+0x48/0x990 net/bluetooth/l2cap_core.c:730 do_enable_set+0x660/0x900 net/bluetooth/6lowpan.c:1074 process_one_work+0x7f5/0x10f0 kernel/workqueue.c:2264 worker_thread+0xbbc/0x1630 kernel/workqueue.c:2410 kthread+0x332/0x350 kernel/kthread.c:255 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 Allocated by task 2870: save_stack mm/kasan/common.c:72 [inline] set_track mm/kasan/common.c:80 [inline] __kasan_kmalloc+0x118/0x1c0 mm/kasan/common.c:515 kasan_kmalloc+0x9/0x10 mm/kasan/common.c:529 kmem_cache_alloc_trace+0x221/0x2f0 mm/slab.c:3551 kmalloc include/linux/slab.h:555 [inline] kzalloc include/linux/slab.h:669 [inline] l2cap_chan_create+0x50/0x320 net/bluetooth/l2cap_core.c:446 chan_create net/bluetooth/6lowpan.c:640 [inline] bt_6lowpan_listen net/bluetooth/6lowpan.c:959 [inline] do_enable_set+0x6a4/0x900 net/bluetooth/6lowpan.c:1078 process_one_work+0x7f5/0x10f0 kernel/workqueue.c:2264 worker_thread+0xbbc/0x1630 kernel/workqueue.c:2410 kthread+0x332/0x350 kernel/kthread.c:255 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 Freed by task 2870: save_stack mm/kasan/common.c:72 [inline] set_track mm/kasan/common.c:80 [inline] kasan_set_free_info mm/kasan/common.c:337 [inline] __kasan_slab_free+0x12e/0x1e0 mm/kasan/common.c:476 kasan_slab_free+0xe/0x10 mm/kasan/common.c:485 __cache_free mm/slab.c:3426 [inline] kfree+0x10d/0x220 mm/slab.c:3757 l2cap_chan_destroy net/bluetooth/l2cap_core.c:484 [inline] kref_put include/linux/kref.h:65 [inline] l2cap_chan_put+0x170/0x190 net/bluetooth/l2cap_core.c:498 do_enable_set+0x66c/0x900 net/bluetooth/6lowpan.c:1075 process_one_work+0x7f5/0x10f0 kernel/workqueue.c:2264 worker_thread+0xbbc/0x1630 kernel/workqueue.c:2410 kthread+0x332/0x350 kernel/kthread.c:255 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 The buggy address belongs to the object at ffff888096950000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 0 bytes inside of 2048-byte region [ffff888096950000, ffff888096950800) The buggy address belongs to the page: page:ffffea00025a5400 refcount:1 mapcount:0 mapping:ffff8880aa400e00 index:0x0 flags: 0xfffe0000000200(slab) raw: 00fffe0000000200 ffffea00027d1548 ffffea0002397808 ffff8880aa400e00 raw: 0000000000000000 ffff888096950000 0000000100000001 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88809694ff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff88809694ff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff888096950000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888096950080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888096950100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== Reported-by: syzbot+96414aa0033c363d8458@syzkaller.appspotmail.com Signed-off-by:Lihong Kou <koulihong@huawei.com> Signed-off-by:
-
- 22 Jun, 2020 3 commits
-
-
Luiz Augusto von Dentz authored
E0 is not allowed with Level 4: BLUETOOTH CORE SPECIFICATION Version 5.2 | Vol 3, Part C page 1319: '128-bit equivalent strength for link and encryption keys required using FIPS approved algorithms (E0 not allowed, SAFER+ not allowed, and P-192 not allowed; encryption key not shortened' SC enabled: > HCI Event: Read Remote Extended Features (0x23) plen 13 Status: Success (0x00) Handle: 256 Page: 1/2 Features: 0x0b 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Secure Simple Pairing (Host Support) LE Supported (Host) Secure Connections (Host Support) > HCI Event: Encryption Change (0x08) plen 4 Status: Success (0x00) Handle: 256 Encryption: Enabled with AES-CCM (0x02) SC disabled: > HCI Event: Read Remote Extended Features (0x23) plen 13 Status: Success (0x00) Handle: 256 Page: 1/2 Features: 0x03 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Secure Simple Pairing (Host Support) LE Supported (Host) > HCI Event: Encryption Change (0x08) plen 4 Status: Success (0x00) Handle: 256 Encryption: Enabled with E0 (0x01) [May 8 20:23] Bluetooth: hci0: Invalid security: expect AES but E0 was used < HCI Command: Disconnect (0x01|0x0006) plen 3 Handle: 256 Reason: Authentication Failure (0x05) Signed-off-by:Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by:
-
Alain Michaud authored
When the extended advertisement feature is enabled, a hardcoded min and max interval of 0x8000 is used. This patch fixes this issue by using the configured min/max value. This was validated by setting min/max in main.conf and making sure the right setting is applied: < HCI Command: LE Set Extended Advertising Parameters (0x08|0x0036) plen 25 #93 [hci0] 10.953011 … Min advertising interval: 181.250 msec (0x0122) Max advertising interval: 181.250 msec (0x0122) … Signed-off-by:
Alain Michaud <alainm@chromium.org> Reviewed-by:
Daniel Winkler <danielwinkler@google.com> Signed-off-by:
-
Abhishek Pandit-Subedi authored
Adding hci_dev_lock since hci_conn_params_(lookup|add) require this lock. Suggested-by:
Miao-chen Chou <mcchou@chromium.org> Signed-off-by:
-
- 18 Jun, 2020 14 commits
-
-
Marcel Holtmann authored
The command status reply is only for failure. When completing set system config command, the reply has to be command complete. Signed-off-by:
Johan Hedberg <johan.hedberg@intel.com>
-
Manish Mandlik authored
If user decides to cancel the ongoing pairing process (e.g. by clicking the cancel button on pairing/passkey window), abort any ongoing pairing and then terminate the link if it was created because of the pair device action. Signed-off-by:
Manish Mandlik <mmandlik@google.com> Signed-off-by:
-
Miao-chen Chou authored
This calls hci_update_background_scan() when there is any update on the advertisement monitors. If there is at least one advertisement monitor, the filtering policy of scan parameters should be 0x00. This also reports device found mgmt events if there is at least one monitor. The following cases were tested with btmgmt advmon-* commands. (1) add a ADV monitor and observe that the passive scanning is triggered. (2) remove the last ADV monitor and observe that the passive scanning is terminated. (3) with a LE peripheral paired, repeat (1) and observe the passive scanning continues. (4) with a LE peripheral paired, repeat (2) and observe the passive scanning continues. (5) with a ADV monitor, suspend/resume the host and observe the passive scanning continues. Signed-off-by:
-
Miao-chen Chou authored
This notifies management sockets on MGMT_EV_ADV_MONITOR_REMOVED event. The following test was performed. - Start two btmgmt consoles, issue a btmgmt advmon-remove command on one console and observe a MGMT_EV_ADV_MONITOR_REMOVED event on the other. Signed-off-by:
-
Miao-chen Chou authored
This notifies management sockets on MGMT_EV_ADV_MONITOR_ADDED event. The following test was performed. - Start two btmgmt consoles, issue a btmgmt advmon-add command on one console and observe a MGMT_EV_ADV_MONITOR_ADDED event on the other Signed-off-by:
-
Miao-chen Chou authored
This adds the request handler of MGMT_OP_REMOVE_ADV_MONITOR command. Note that the controller-based monitoring is not yet in place. This removes the internal monitor(s) without sending HCI traffic, so the request returns immediately. The following test was performed. - Issue btmgmt advmon-remove with valid and invalid handles. Signed-off-by:
-
Miao-chen Chou authored
This adds the request handler of MGMT_OP_ADD_ADV_PATTERNS_MONITOR command. Note that the controller-based monitoring is not yet in place. This tracks the content of the monitor without sending HCI traffic, so the request returns immediately. The following manual test was performed. - Issue btmgmt advmon-add with valid and invalid inputs. - Issue btmgmt advmon-add more the allowed number of monitors. Signed-off-by:
-
Miao-chen Chou authored
This adds the request handler of MGMT_OP_READ_ADV_MONITOR_FEATURES command. Since the controller-based monitoring is not yet in place, this report only the supported features but not the enabled features. The following test was performed. - Issuing btmgmt advmon-features. Signed-off-by:
-
Miao-chen Chou authored
This adds support for Advertisement Monitor API. Here are the commands and events added. - Read Advertisement Monitor Feature command - Add Advertisement Pattern Monitor command - Remove Advertisement Monitor command - Advertisement Monitor Added event - Advertisement Monitor Removed event Signed-off-by:
-
Abhishek Pandit-Subedi authored
Add the get device flags and set device flags mgmt ops and the device flags changed event. Their behavior is described in detail in mgmt-api.txt in bluez. Sample btmon trace when a HID device is added (trimmed to 75 chars): @ MGMT Command: Unknown (0x0050) plen 11 {0x0001} [hci0] 18:06:14.98 90 c5 13 cd f3 cd 02 01 00 00 00 ........... @ MGMT Event: Unknown (0x002a) plen 15 {0x0004} [hci0] 18:06:14.98 90 c5 13 cd f3 cd 02 01 00 00 00 01 00 00 00 ............... @ MGMT Event: Unknown (0x002a) plen 15 {0x0003} [hci0] 18:06:14.98 90 c5 13 cd f3 cd 02 01 00 00 00 01 00 00 00 ............... @ MGMT Event: Unknown (0x002a) plen 15 {0x0002} [hci0] 18:06:14.98 90 c5 13 cd f3 cd 02 01 00 00 00 01 00 00 00 ............... @ MGMT Event: Command Compl.. (0x0001) plen 10 {0x0001} [hci0] 18:06:14.98 Unknown (0x0050) plen 7 Status: Success (0x00) 90 c5 13 cd f3 cd 02 ....... @ MGMT Command: Add Device (0x0033) plen 8 {0x0001} [hci0] 18:06:14.98 LE Address: CD:F3:CD:13:C5:90 (Static) Action: Auto-connect remote device (0x02) @ MGMT Event: Device Added (0x001a) plen 8 {0x0004} [hci0] 18:06:14.98 LE Address: CD:F3:CD:13:C5:90 (Static) Action: Auto-connect remote device (0x02) @ MGMT Event: Device Added (0x001a) plen 8 {0x0003} [hci0] 18:06:14.98 LE Address: CD:F3:CD:13:C5:90 (Static) Action: Auto-connect remote device (0x02) @ MGMT Event: Device Added (0x001a) plen 8 {0x0002} [hci0] 18:06:14.98 LE Address: CD:F3:CD:13:C5:90 (Static) Action: Auto-connect remote device (0x02) @ MGMT Event: Unknown (0x002a) plen 15 {0x0004} [hci0] 18:06:14.98 90 c5 13 cd f3 cd 02 01 00 00 00 01 00 00 00 ............... @ MGMT Event: Unknown (0x002a) plen 15 {0x0003} [hci0] 18:06:14.98 90 c5 13 cd f3 cd 02 01 00 00 00 01 00 00 00 ............... @ MGMT Event: Unknown (0x002a) plen 15 {0x0002} [hci0] 18:06:14.98 90 c5 13 cd f3 cd 02 01 00 00 00 01 00 00 00 ............... @ MGMT Event: Unknown (0x002a) plen 15 {0x0001} [hci0] 18:06:14.98 90 c5 13 cd f3 cd 02 01 00 00 00 01 00 00 00 ............... Signed-off-by: -
Abhishek Pandit-Subedi authored
Replace the wakeable boolean with flags in hci_conn_params and all users of this boolean. This will be used by the get/set device flags mgmt op. Signed-off-by:
-
Abhishek Pandit-Subedi authored
Since the classic device list now supports flags, convert the wakeable list into a flag on the existing device list. Signed-off-by:
-
Abhishek Pandit-Subedi authored
In order to more easily add device flags to classic devices, create a new type of bdaddr_list that supports setting flags. Signed-off-by:
-
Marcel Holtmann authored
This adds the required read/set commands for runtime configuration. Even while currently no parameters are specified, the commands are made available. Signed-off-by:
-
- 12 Jun, 2020 11 commits
-
-
Alain Michaud authored
This patch implements the read default system parameters and the set default system parameters mgmt commands. Signed-off-by:
-
Alain Michaud authored
This patch centralized the initialization of default parameters. This is required to allow clients to more easily customize the default system parameters. Signed-off-by:
-
Alain Michaud authored
This patch submits the corresponding kernel definitions to mgmt.h. This is submitted before the implementation to avoid any conflicts in values allocations. Signed-off-by:
Yu Liu <yudiliu@google.com> Signed-off-by:
-
Balakrishna Godavarthi authored
Tx pending flag is set to true when HOST IBS state is AWAKE or AWAKEING. If IBS state is ASLEEP, then Tx clock is already voted off. To optimize further directly calling serial_clock_vote() instead of qca_wq_serial_tx_clock_vote_off(), at this point of qca_suspend() already data is sent out. No need to wake up hci to send data. Signed-off-by:
Balakrishna Godavarthi <bgodavar@codeaurora.org> Signed-off-by:
-
Balakrishna Godavarthi authored
In some version of WCN399x, SoC idle timeout is configured as 80ms instead of 20ms or 40ms. To honor all the SoC's supported in the driver increasing SoC idle timeout to 200ms. Fixes: 41d5b25f ("Bluetooth: hci_qca: add PM support") Signed-off-by:
-
Balakrishna Godavarthi authored
By default, WCN3991 sent debug packets to HOST via ACL packet with header 0xDC2E. This logging is not required on commercial devices. With this patch SoC logging is disabled post fw download. Signed-off-by:
-
Alain Michaud authored
This change implements suggestions from the code review of the SCO CMSG state flag patch. Signed-off-by:
-
Alain Michaud authored
This change adds support for reporting the BT_PKT_STATUS to the socket CMSG data to allow the implementation of a packet loss correction on erroneous data received on the SCO socket. The patch was partially developed by Marcel Holtmann and validated by Hsin-yu Chao. Signed-off-by:
-
Abhishek Pandit-Subedi authored
Use device_init_wakeup to allow the Bluetooth dev to wake the system from suspend. Currently, the device can wake the system but no power/wakeup entry is created in sysfs to allow userspace to disable wakeup. Signed-off-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
-
Abhishek Pandit-Subedi authored
Use the parent device's power/wakeup to control whether we support remote wake. If remote wakeup is disabled, Bluetooth will not enable scanning for incoming connections. Signed-off-by:
-
Abhishek Pandit-Subedi authored
Set the correct parent dev when registering hdev. This allows userspace tools to find the parent device (for example, to set the power/wakeup property). Before this change, the path was /sys/devices/virtual/bluetooth/hci0 and after this change, it looks more like: /sys/bus/mmc/devices/mmc1:0001/mmc1:0001:2/bluetooth/hci0 Signed-off-by:
-
- 10 Jun, 2020 3 commits
-
-
Chethan T N authored
This patch shall enable the Intel telemetry exception format based on the supported features Signed-off-by:
Chethan T N <chethan.tumkur.narayan@intel.com> Signed-off-by:
Ps AyappadasX <AyappadasX.Ps@intel.com> Signed-off-by:
Kiran K <kiran.k@intel.com> Signed-off-by:
-
Chethan T N authored
The command shall read the Intel controller supported debug feature. Based on the supported features additional debug configuration shall be enabled. Signed-off-by:
-
Venkata Lakshmi Narayana Gubba authored
Due to race conditions between qca_hw_error and qca_controller_memdump during SSR timeout,the same pointer is freed twice. This results in a double free. Now a lock is acquired before checking the stauts of SSR state. Fixes: d841502c ("Bluetooth: hci_qca: Collect controller memory dump during SSR") Signed-off-by:
Venkata Lakshmi Narayana Gubba <gubbaven@codeaurora.org> Reviewed-by:
-
- 08 Jun, 2020 5 commits
-
-
Abhishek Pandit-Subedi authored
It is preferable to allow suspend even when Bluetooth has problems preparing for sleep. When Bluetooth fails to finish preparing for suspend, log the error and allow the suspend notifier to continue instead. To also make it clearer why suspend failed, change bt_dev_dbg to bt_dev_err when handling the suspend timeout. Fixes: dd522a74 ("Bluetooth: Handle LE devices during suspend") Reported-by:
Len Brown <len.brown@intel.com> Signed-off-by:
-
Matthias Kaehlcke authored
If waiting for IBS sleep times out jump to the error handler, this is easier to read than multiple 'if' branches and a fall through to the error handler. Signed-off-by:
Matthias Kaehlcke <mka@chromium.org> Reviewed-by:
-
Matthias Kaehlcke authored
qca_suspend() calls serdev_device_wait_until_sent() regardless of whether a transfer is pending. While it does no active harm since the function should return immediately it makes the code more confusing. Add a flag to track whether a transfer is pending and only call serdev_device_wait_until_sent() is needed. Signed-off-by:
-
Matthias Kaehlcke authored
qca_suspend() removes the vote for the UART TX clock after writing an IBS sleep request to the serial buffer. This is not a good idea since there is no guarantee that the request has been sent at this point. Instead remove the vote after successfully entering IBS sleep. This also fixes the issue of the vote being removed in case of an aborted suspend due to a failure of entering IBS sleep. Fixes: 41d5b25f ("Bluetooth: hci_qca: add PM support") Signed-off-by:
-
Matthias Kaehlcke authored
The serial clocks should be on when there is a vote for at least one of the clocks (RX or TX), and off when there is no 'on' vote. The current logic to determine the combined state is a bit redundant in the code paths for different types of votes, use a single statement in the common path instead. Signed-off-by:
-
