summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-06-23Bluetooth: btusb: fix up firmware download sequenceSean Wang1-1/+15
Data RAM on the device have to be powered on before starting to download the firmware. Fixes: a1c49c434e15 ("Bluetooth: btusb: Add protocol support for MediaTek MT7668U USB devices") Co-developed-by: Mark Chen <Mark-YW.Chen@mediatek.com> Signed-off-by: Mark Chen <Mark-YW.Chen@mediatek.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-06-23Bluetooth: add a mutex lock to avoid UAF in do_enale_setLihong Kou1-0/+5
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: Marcel Holtmann <marcel@holtmann.org>
2020-06-22Bluetooth: Disconnect if E0 is used for Level 4Luiz Augusto von Dentz3-16/+31
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: Marcel Holtmann <marcel@holtmann.org>
2020-06-22Bluetooth: use configured params for ext advAlain Michaud2-4/+11
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: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Reviewed-by: Daniel Winkler <danielwinkler@google.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-06-22Bluetooth: Add hci_dev_lock to get/set device flagsAbhishek Pandit-Subedi1-0/+8
Adding hci_dev_lock since hci_conn_params_(lookup|add) require this lock. Suggested-by: Miao-chen Chou <mcchou@chromium.org> Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-06-18Bluetooth: mgmt: Use command complete on success for set system configMarcel Holtmann1-3/+2
The command status reply is only for failure. When completing set system config command, the reply has to be command complete. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Reviewed-by: Alain Michaud <alainm@chromium.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2020-06-18Bluetooth: Terminate the link if pairing is cancelledManish Mandlik4-11/+42
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: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2020-06-18Bluetooth: Update background scan and report device based on advertisement ↵Miao-chen Chou5-6/+35
monitors 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 <mcchou@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2020-06-18Bluetooth: Notify adv monitor removed eventMiao-chen Chou1-0/+16
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 <mcchou@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2020-06-18Bluetooth: Notify adv monitor added eventMiao-chen Chou1-1/+17
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 <mcchou@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2020-06-18Bluetooth: Add handler of MGMT_OP_REMOVE_ADV_MONITORMiao-chen Chou3-0/+67
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 <mcchou@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2020-06-18Bluetooth: Add handler of MGMT_OP_ADD_ADV_PATTERNS_MONITORMiao-chen Chou3-0/+142
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 <mcchou@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2020-06-18Bluetooth: Add handler of MGMT_OP_READ_ADV_MONITOR_FEATURESMiao-chen Chou5-1/+97
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 <mcchou@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2020-06-18Bluetooth: Add definitions for advertisement monitor featuresMiao-chen Chou1-0/+49
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: Miao-chen Chou <mcchou@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2020-06-18Bluetooth: Add get/set device flags mgmt opAbhishek Pandit-Subedi2-0/+156
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 <abhishekpandit@chromium.org> Reviewed-by: Alain Michaud <alainm@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2020-06-18Bluetooth: Replace wakeable in hci_conn_paramsAbhishek Pandit-Subedi2-2/+3
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 <abhishekpandit@chromium.org> Reviewed-by: Alain Michaud <alainm@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2020-06-18Bluetooth: Replace wakeable list with flagAbhishek Pandit-Subedi3-6/+18
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 <abhishekpandit@chromium.org> Reviewed-by: Alain Michaud <alainm@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2020-06-18Bluetooth: Add bdaddr_list_with_flags for classic whitelistAbhishek Pandit-Subedi4-8/+81
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: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Reviewed-by: Alain Michaud <alainm@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2020-06-18Bluetooth: mgmt: Add commands for runtime configurationMarcel Holtmann3-0/+31
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: Marcel Holtmann <marcel@holtmann.org> Reviewed-by: Alain Michaud <alainm@chromium.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2020-06-12Bluetooth: implement read/set default system parameters mgmtAlain Michaud4-1/+273
This patch implements the read default system parameters and the set default system parameters mgmt commands. Signed-off-by: Alain Michaud <alainm@chromium.org> Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-06-12Bluetooth: centralize default value initialization.Alain Michaud4-21/+40
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 <alainm@chromium.org> Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-06-12Bluetooth: mgmt: read/set system parameter definitionsAlain Michaud1-0/+18
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: Alain Michaud <alainm@chromium.org> Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Reviewed-by: Yu Liu <yudiliu@google.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-06-12Bluetooth: hci_qca: Request Tx clock vote off only when Tx is pendingBalakrishna Godavarthi1-1/+1
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: Marcel Holtmann <marcel@holtmann.org>
2020-06-12Bluetooth: hci_qca: Increase SoC idle timeout to 200msBalakrishna Godavarthi1-1/+1
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: 41d5b25fed0a0 ("Bluetooth: hci_qca: add PM support") Signed-off-by: Balakrishna Godavarthi <bgodavar@codeaurora.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-06-12Bluetooth: hci_qca: Disable SoC debug logging for WCN3991Balakrishna Godavarthi2-0/+29
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: Balakrishna Godavarthi <bgodavar@codeaurora.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-06-12Bluetooth: Use only 8 bits for the HCI CMSG state flagsAlain Michaud2-4/+4
This change implements suggestions from the code review of the SCO CMSG state flag patch. Signed-off-by: Alain Michaud <alainm@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-06-12Bluetooth: Add support for BT_PKT_STATUS CMSG data for SCO connectionsAlain Michaud5-0/+48
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: Alain Michaud <alainm@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-06-12Bluetooth: btmrvl_sdio: Refactor irq wakeupAbhishek Pandit-Subedi1-3/+10
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: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-06-12Bluetooth: btmrvl_sdio: Implement prevent_wakeAbhishek Pandit-Subedi1-0/+9
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 <abhishekpandit@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-06-12Bluetooth: btmrvl_sdio: Set parent dev to hdevAbhishek Pandit-Subedi1-0/+2
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: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-06-10Bluetooth: btusb: Configure Intel debug feature based on available supportChethan T N3-2/+38
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: Marcel Holtmann <marcel@holtmann.org>
2020-06-10Bluetooth: btusb: Add support to read Intel debug featureChethan T N3-0/+53
The command shall read the Intel controller supported debug feature. Based on the supported features additional debug configuration shall be enabled. 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: Marcel Holtmann <marcel@holtmann.org>
2020-06-10Bluetooth: hci_qca: Bug fix during SSR timeoutVenkata Lakshmi Narayana Gubba1-12/+17
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: d841502c79e3 ("Bluetooth: hci_qca: Collect controller memory dump during SSR") Signed-off-by: Venkata Lakshmi Narayana Gubba <gubbaven@codeaurora.org> Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-06-08Bluetooth: Allow suspend even when preparation has failedAbhishek Pandit-Subedi1-7/+10
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: dd522a7429b07e ("Bluetooth: Handle LE devices during suspend") Reported-by: Len Brown <len.brown@intel.com> Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-06-08Bluetooth: hci_qca: Refactor error handling in qca_suspend()Matthias Kaehlcke1-7/+5
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: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-06-08Bluetooth: hci_qca: Skip serdev wait when no transfer is pendingMatthias Kaehlcke1-2/+6
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 <mka@chromium.org> Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-06-08Bluetooth: hci_qca: Only remove TX clock vote after TX is completedMatthias Kaehlcke1-3/+3
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: 41d5b25fed0a0 ("Bluetooth: hci_qca: add PM support") Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-06-08Bluetooth: hci_qca: Simplify determination of serial clock on/off state from ↵Matthias Kaehlcke1-4/+2
votes 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: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-06-03Bluetooth: hci_qca: Fix an error pointer dereferenceDan Carpenter1-9/+9
When a function like devm_clk_get_optional() function returns both error pointers on error and NULL then the NULL return means that the optional feature is deliberately disabled. It is a special sort of success and should not trigger an error message. The surrounding code should be written to check for NULL and not crash. On the other hand, if we encounter an error, then the probe from should clean up and return a failure. In this code, if devm_clk_get_optional() returns an error pointer then the kernel will crash inside the call to: clk_set_rate(qcadev->susclk, SUSCLK_RATE_32KHZ); The error handling must be updated to prevent that. Fixes: 77131dfec6af ("Bluetooth: hci_qca: Replace devm_gpiod_get() with devm_gpiod_get_optional()") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-06-03Bluetooth: Removing noisy dbg messageAlain Michaud1-2/+0
This patch removes a particularly noisy dbg message. The debug message isn't particularly interesting for debuggability so it was simply removed to reduce noise in dbg logs. Signed-off-by: Alain Michaud <alainm@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-06-03Bluetooth: Check scan state before disabling during suspendManish Mandlik1-4/+6
Check current scan state by checking HCI_LE_SCAN flag and send scan disable command only if scan is already enabled. Signed-off-by: Manish Mandlik <mmandlik@google.com> Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Reviewed-by: Alain Michaud <alainm@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-06-01btmrvl: Fix firmware filename for sd8997 chipsetPali Rohár1-2/+2
Firmware for sd8997 chipset is distributed by Marvell package and also as part of the linux-firmware repository in filename sdsd8997_combo_v4.bin. This patch fixes mwifiex driver to load correct firmware file for sd8997. Fixes: f0ef67485f591 ("Bluetooth: btmrvl: add sd8997 chipset support") Signed-off-by: Pali Rohár <pali@kernel.org> Acked-by: Ganapathi Bhat <ganapathi.bhat@nxp.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-06-01btmrvl: Fix firmware filename for sd8977 chipsetPali Rohár1-2/+2
Firmware for sd8977 chipset is distributed by Marvell package and also as part of the linux-firmware repository in filename sdsd8977_combo_v2.bin. This patch fixes mwifiex driver to load correct firmware file for sd8977. Fixes: 8c57983bf7a79 ("Bluetooth: btmrvl: add support for sd8977 chipset") Signed-off-by: Pali Rohár <pali@kernel.org> Acked-by: Ganapathi Bhat <ganapathi.bhat@nxp.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-06-01mwifiex: Fix firmware filename for sd8997 chipsetPali Rohár1-1/+1
Firmware for sd8997 chipset is distributed by Marvell package and also as part of the linux-firmware repository in filename sdsd8997_combo_v4.bin. This patch fixes mwifiex driver to load correct firmware file for sd8997. Fixes: 6d85ef00d9dfe ("mwifiex: add support for 8997 chipset") Signed-off-by: Pali Rohár <pali@kernel.org> Acked-by: Ganapathi Bhat <ganapathi.bhat@nxp.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-06-01mwifiex: Fix firmware filename for sd8977 chipsetPali Rohár1-1/+1
Firmware for sd8977 chipset is distributed by Marvell package and also as part of the linux-firmware repository in filename sdsd8977_combo_v2.bin. This patch fixes mwifiex driver to load correct firmware file for sd8977. Fixes: 1a0f547831dce ("mwifiex: add support for sd8977 chipset") Signed-off-by: Pali Rohár <pali@kernel.org> Acked-by: Ganapathi Bhat <ganapathi.bhat@nxp.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-06-03selftests: net: ip_defrag: ignore EPERMThadeu Lima de Souza Cascardo1-4/+4
When running with conntrack rules, the dropped overlap fragments may cause EPERM to be returned to sendto. Instead of completely failing, just ignore those errors and continue. If this causes packets with overlap fragments to be dropped as expected, that is okay. And if it causes packets that are expected to be received to be dropped, which should not happen, it will be detected as failure. Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-03net_failover: fixed rollback in net_failover_open()Vasily Averin1-1/+2
found by smatch: drivers/net/net_failover.c:65 net_failover_open() error: we previously assumed 'primary_dev' could be null (see line 43) Fixes: cfc80d9a1163 ("net: Introduce net_failover driver") Signed-off-by: Vasily Averin <vvs@virtuozzo.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-03Merge branch 'tipc-revert-two-patches'David S. Miller2-2/+0
Tuong Lien says: ==================== tipc: revert two patches We revert two patches: tipc: Fix potential tipc_node refcnt leak in tipc_rcv tipc: Fix potential tipc_aead refcnt leak in tipc_crypto_rcv which prevented TIPC encryption from working properly and caused kernel panic. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-03Revert "tipc: Fix potential tipc_aead refcnt leak in tipc_crypto_rcv"Tuong Lien1-1/+0
This reverts commit 441870ee4240cf67b5d3ab8e16216a9ff42eb5d6. Like the previous patch in this series, we revert the above commit that causes similar issues with the 'aead' object. Acked-by: Jon Maloy <jmaloy@redhat.com> Signed-off-by: Tuong Lien <tuong.t.lien@dektech.com.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-03Revert "tipc: Fix potential tipc_node refcnt leak in tipc_rcv"Tuong Lien1-1/+0
This reverts commit de058420767df21e2b6b0f3bb36d1616fb962032. There is no actual tipc_node refcnt leak as stated in the above commit. The refcnt is hold carefully for the case of an asynchronous decryption (i.e. -EINPROGRESS/-EBUSY and skb = NULL is returned), so that the node object cannot be freed in the meantime. The counter will be re-balanced when the operation's callback arrives with the decrypted buffer if any. In other cases, e.g. a synchronous crypto the counter will be decreased immediately when it is done. Now with that commit, a kernel panic will occur when there is no node found (i.e. n = NULL) in the 'tipc_rcv()' or a premature release of the node object. This commit solves the issues by reverting the said commit, but keeping one valid case that the 'skb_linearize()' is failed. Acked-by: Jon Maloy <jmaloy@redhat.com> Signed-off-by: Tuong Lien <tuong.t.lien@dektech.com.au> Tested-by: Hoang Le <hoang.h.le@dektech.com.au> Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-30 10:27:37 +0300