- 21 Mar, 2022 1 commit
-
-
Wang Yufen authored
In calipso_map_cat_ntoh(), in the for loop, if the return value of netlbl_bitmap_walk() is equal to (net_clen_bits - 1), when netlbl_bitmap_walk() is called next time, out-of-bounds memory accesses of bitmap[byte_offset] occurs. The bug was found during fuzzing. The following is the fuzzing report BUG: KASAN: slab-out-of-bounds in netlbl_bitmap_walk+0x3c/0xd0 Read of size 1 at addr ffffff8107bf6f70 by task err_OH/252 CPU: 7 PID: 252 Comm: err_OH Not tainted 5.17.0-rc7+ #17 Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace+0x21c/0x230 show_stack+0x1c/0x60 dump_stack_lvl+0x64/0x7c print_address_description.constprop.0+0x70/0x2d0 __kasan_report+0x158/0x16c kasan_report+0x74/0x120 __asan_load1+0x80/0xa0 netlbl_bitmap_walk+0x3c/0xd0 calipso_opt_getattr+0x1a8/0x230 calipso_sock_getattr+0x218/0x340 calipso_sock_getattr+0x44/0x60 netlbl_sock_getattr+0x44/0x80 selinux_netlbl_socket_setsockopt+0x138/0x170 selinux_socket_setsockopt+0x4c/0x60 security_socket_setsockopt+0x4c/0x90 __sys_setsockopt+0xbc/0x2b0 __arm64_sys_setsockopt+0x6c/0x84 invoke_syscall+0x64/0x190 el0_svc_common.constprop.0+0x88/0x200 do_el0_svc+0x88/0xa0 el0_svc+0x128/0x1b0 el0t_64_sync_handler+0x9c/0x120 el0t_64_sync+0x16c/0x170 Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wang Yufen <wangyufen@huawei.com> Acked-by: Paul Moore <paul@paul-moore.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 19 Mar, 2022 6 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linuxDavid S. Miller authored
Saeed Mahameed says: ==================== mlx5-updates-2022-03-18 1) XDP multi buffer support This series enables XDP on non-linear legacy RQ in multi buffer mode. When XDP is enabled, fragmentation scheme on non-linear legacy RQ is adjusted to comply to limitations of XDP multi buffer (fragments of the same size). DMA addresses of fragments are stored in struct page for the completion handler to be able to unmap them. XDP_TX is supported. XDP_REDIRECT is not yet supported, the XDP core blocks it for multi buffer packets at the moment. 2) Trivial cleanups ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
git://git.kernel.org/pub/scm/linux/kernel/git/klassert/David S. Miller authored
ipsec-next Steffen Klassert says: ==================== pull request (net-next): ipsec-next 2022-03-19 1) Delete duplicated functions that calls same xfrm_api_check. From Leon Romanovsky. 2) Align userland API of the default policy structure to the internal structures. From Nicolas Dichtel. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Dan Carpenter authored
This code is fine, but it's easier to review if we use snprintf() instead of sprintf(). Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com> Link: https://lore.kernel.org/r/20220318074723.GA6617@kiliSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Yang Yingliang authored
The skb will be checked in kfree_skb(), so remove the outside check. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20220318072728.2659578-1-yangyingliang@huawei.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queueJakub Kicinski authored
Tony Nguyen says: ==================== 40GbE Intel Wired LAN Driver Updates 2022-03-17 This series contains updates to i40e and igb drivers. Tom Rix moves a conversion to little endian to occur only when the value is used for i40e. He also zeros out a structure to resolve possible use of garbage value for igb as reported by clang. * '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue: igb: zero hwtstamp by default i40e: little endian only valid checksums ==================== Link: https://lore.kernel.org/r/20220317160236.3534321-1-anthony.l.nguyen@intel.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Merge tag 'for-net-next-2022-03-18' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next Luiz Augusto von Dentz says: ==================== bluetooth-next pull request for net-next: - Add support for Asus TF103C - Add support for Realtek RTL8852B - Add support for Realtek RTL8723BE - Add WBS support to mt7921s * tag 'for-net-next-2022-03-18' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next: (24 commits) Bluetooth: ath3k: remove superfluous header files Bluetooth: bcm203x: remove superfluous header files Bluetooth: hci_bcm: Add the Asus TF103C to the bcm_broken_irq_dmi_table Bluetooth: mt7921s: Add WBS support Bluetooth: mt7921s: Add .btmtk_get_codec_config_data Bluetooth: mt7921s: Add .get_data_path_id Bluetooth: mt7921s: Set HCI_QUIRK_VALID_LE_STATES Bluetooth: btmtksdio: Fix kernel oops in btmtksdio_interrupt Bluetooth: btmtkuart: fix error handling in mtk_hci_wmt_sync() Bluetooth: call hci_le_conn_failed with hdev lock in hci_le_conn_failed Bluetooth: Send AdvMonitor Dev Found for all matched devices Bluetooth: msft: Clear tracked devices on resume Bluetooth: fix incorrect nonblock bitmask in bt_sock_wait_ready() Bluetooth: Don't assign twice the same value Bluetooth: btrtl: Add support for RTL8852B Bluetooth: hci_uart: add missing NULL check in h5_enqueue Bluetooth: Fix use after free in hci_send_acl Bluetooth: btusb: Use quirk to skip HCI_FLT_CLEAR_ALL on fake CSR controllers Bluetooth: hci_sync: Add a new quirk to skip HCI_FLT_CLEAR_ALL Bluetooth: btmtkuart: fix the conflict between mtk and msft vendor event ... ==================== Link: https://lore.kernel.org/r/20220318224752.1477292-1-luiz.dentz@gmail.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
- 18 Mar, 2022 33 commits
-
-
Colin Ian King authored
Variable index is being assigned a value that is never read, it is being re-assigned later in a following for-loop. The assignment is redundant and can be removed. Cleans up clang scan build warning: drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c:1358:17: warning: Although the value stored to 'index' is used in the enclosing expression, the value is never actually read from 'index' [deadcode.DeadStores] Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Link: https://lore.kernel.org/r/20220318012035.89482-1-colin.i.king@gmail.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Colin Ian King authored
Variable sie is being assigned a value that is never read. The The assignment is redundant and can be removed. Cleans up clang scan build warning: drivers/net/ethernet/atheros/atl1c/atl1c_main.c:1054:22: warning: Although the value stored to 'size' is used in the enclosing expression, the value is never actually read from 'size' [deadcode.DeadStores] Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Link: https://lore.kernel.org/r/20220318005021.82073-1-colin.i.king@gmail.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Yonglong Li authored
In some corner cases, the peer handing an incoming ADD_ADDR option, can receive a retransmitted ADD_ADDR for the same address before the subflow creation completes. We can avoid the above issue by generating and sending the ADD_ADDR echo before starting the MPJ subflow connection. This slightly changes the behaviour of the packetdrill tests as the ADD_ADDR echo packet is sent earlier. Acked-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Yonglong Li <liyonglong@chinatelecom.cn> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Link: https://lore.kernel.org/r/20220317221444.426335-1-mathew.j.martineau@linux.intel.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Kuniyuki Iwashima authored
Let's remove unnecessary brackets around CONFIG_AF_UNIX_OOB. Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.co.jp> Link: https://lore.kernel.org/r/20220317032308.65372-1-kuniyu@amazon.co.jpSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Saeed Mahameed authored
There is no function mlx5e_get_sq(), remove the declaration. Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Moshe Tal <moshet@nvidia.com> Reviewed-by: Maxim Mikityanskiy <maximmi@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
-
Tariq Toukan authored
Starting from commit 4cab346b ("net/mlx5: No command allowed when command interface is not ready"), no calls to mlx5_cmd_trigger_completions() are external to cmd.c anymore. Make it a static function. Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Gal Pressman <gal@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
-
Maxim Mikityanskiy authored
After introducing multi-buffer XDP_TX, the MLX5E_XDP_TX_DS_COUNT define became misleading. It's no longer the DS count of an XDP_TX WQE, this WQE can be longer because of fragments. As this define is only used at one place in mlx5e_open_xdpsq(), it's also not very useful anymore. This commit removes the define and puts the calculation of ds_count for prefilled single-fragment WQEs inline. Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
-
Maxim Mikityanskiy authored
Now that legacy RQ implements XDP in the non-linear mode, stop blocking this configuration. Allow non-linear mode only for programs aware of multi buffer. XDP performance with linear mode RQ hasn't changed. Baseline (MTU 1500, TX MPWQE, legacy RQ, single core): 60-byte packets, XDP_DROP: 11.25 Mpps 60-byte packets, XDP_TX: 9.0 Mpps 60-byte packets, XDP_PASS: 668 kpps Multi buffer (MTU 9000, TX MPWQE, legacy RQ, single core): 60-byte packets, XDP_DROP: 10.1 Mpps 60-byte packets, XDP_TX: 6.6 Mpps 60-byte packets, XDP_PASS: 658 kpps 8900-byte packets, XDP_DROP: 769 kpps (100% of sent packets) 8900-byte packets, XDP_TX: 674 kpps (100% of sent packets) 8900-byte packets, XDP_PASS: 637 kpps Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
-
Maxim Mikityanskiy authored
This commit enables passing multi buffer XDP frames to the TX handlers on XDP_TX. Fragments are DMA synchronized to the device and queued to the xdpi_fifo for a subsequent unmapping. Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
-
Maxim Mikityanskiy authored
The next commit will add more indentation levels to mlx5e_xmit_xdp_buff. To keep indentation minimal, unindent the else-block of the if-statement by doing an early return. Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
-
Maxim Mikityanskiy authored
xmit_xdp_frame is extended to support sending fragmented XDP frames. The next commit will start using this functionality. Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
-
Maxim Mikityanskiy authored
When MPWQE is disabled, mlx5e_open_xdpsq() prefills the common fields of WQEs in the XDP SQ to save time when sending packets. mlx5e_xmit_xdp_frame() runs on the prefilled fields, however, sending multi buffer XDP frames would require changing some of these fields on a per-packet basis. Besides that, mlx5e_xmit_xdp_frame() will be used as a fallback to send multi buffer XDP frames when MPWQE is enabled (MPWQE can only handle linear packets). In order to prepare for XDP multi buffer support, this commit introduces a mode for mlx5e_xmit_xdp_frame() that fills all the fields itself. Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
-
Maxim Mikityanskiy authored
When MPWQE is disabled, mlx5e_open_xdpsq prefills the common fields of WQEs in the XDP SQ to save time when sending packets. One of such fields is eseg->inline_hdr.sz, which can be either 0 or MLX5E_XDP_MIN_INLINE, depending on the inline mode of the SQ. The inline mode can't change during the lifetime of the SQ, so setting this field again in mlx5e_xmit_xdp_frame is redundant. Moreover, the xmit function only sets it to MLX5E_XDP_MIN_INLINE, but not to 0 in the other case. This commit removes the redundant assignment in mlx5e_xmit_xdp_frame. Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
-
Maxim Mikityanskiy authored
The implementations of xmit_xdp_frame get the xdpi parameter of type struct mlx5e_xdp_info for the sole purpose of calling mlx5e_xdpi_fifo_push() on success. This commit moves this call outside of xmit_xdp_frame, shifting this responsibility to the caller. It will allow more fine-grained handling of XDP info for cases when an xdp_frame is fragmented. Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
-
Maxim Mikityanskiy authored
Use page_pool_set_dma_addr() to store the DMA address of a page inside struct page, in order to avoid passing struct mlx5e_dma_info to XDP handlers. Previously, struct mlx5e_dma_info was used to pass both the DMA address and the page, and it worked well for the single-fragment case. When XDP multi buffer is in use, and a fragmented xdp_frame has to be transmitted, the driver needs to know the DMA addresses of fragments, however, the array of fragments in struct skb_shared_info doesn't contain them. In order to pass the DMA addresses, the driver puts them into struct page itself, which is accessible from the array of fragments in struct skb_shared_info. The existing XDP handlers are modified to remove the dependency on struct mlx5e_dma_info. Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
-
Maxim Mikityanskiy authored
This commit adds XDP multi buffer support to the RX path in the non-linear legacy RQ mode. mlx5e_xdp_handle is called from mlx5e_skb_from_cqe_nonlinear. XDP_TX action for fragmented XDP frames is not yet supported and blocked. Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
-
Maxim Mikityanskiy authored
The implementation of XDP in mlx5e assumes that the frame size is equal to the page size. Force this limitation in the non-linear mode for XDP multi buffer. Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
-
Maxim Mikityanskiy authored
XDP multi buffer implementation in the kernel assumes that all fragments have the same size. bpf_xdp_frags_increase_tail uses this assumption to get the size of the last fragment, and __xdp_build_skb_from_frame uses it to calculate truesize as nr_frags * xdpf->frame_sz. The current implementation of mlx5e uses fragments of different size in non-linear legacy RQ. Specifically, the last fragment can be larger than the others. It's an optimization for packets smaller than MTU. This commit adapts mlx5e to the kernel limitations and makes it use fragments of the same size, in order to add support for XDP multi buffer. The change is applied only if XDP is active, otherwise the old optimization still applies. Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
-
Maxim Mikityanskiy authored
mlx5e_skb_from_cqe_nonlinear creates an xdp_buff first, putting the first fragment as the linear part, and the rest of fragments as fragments to struct skb_shared_info in the tailroom. Then it creates an SKB in place, based on the xdp_buff. The XDP program is not called in this commit yet. This commit contains no functional change, except the SKB is built over the whole frag_stride of the first fragment, instead of the minimal size required (headroom, data and skb_shared_info). Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
-
Íñigo Huguet authored
Network drivers can call to netif_get_num_default_rss_queues to get the default number of receive queues to use. Right now, this default number is min(8, num_online_cpus()). Instead, as suggested by Jakub, use the number of physical cores divided by 2 as a way to avoid wasting CPU resources and to avoid using both CPU threads, but still allowing to scale for high-end processors with many cores. As an exception, select 2 queues for processors with 2 cores, because otherwise it won't take any advantage of RSS despite being SMP capable. Tested: Processor Intel Xeon E5-2620 (2 sockets, 6 cores/socket, 2 threads/core). NIC Broadcom NetXtreme II BCM57810 (10GBps). Ran some tests with `perf stat iperf3 -R`, with parallelisms of 1, 8 and 24, getting the following results: - Number of queues: 6 (instead of 8) - Network throughput: not affected - CPU usage: utilized 0.05-0.12 CPUs more than before (having 24 CPUs this is only 0.2-0.5% higher) - Reduced the number of context switches by 7-50%, being more noticeable when using a higher number of parallel threads. Suggested-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Íñigo Huguet <ihuguet@redhat.com> Link: https://lore.kernel.org/r/20220315091832.13873-1-ihuguet@redhat.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Mianhan Liu authored
ath3k.c hasn't use any macro or function declared in linux/device.h. Thus, these files can be removed from ath3k.c safely without affecting the compilation of the ./drivers/bluetooth module Signed-off-by: Mianhan Liu <liumh1@shanghaitech.edu.cn> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Mianhan Liu authored
bcm203x.c hasn't use any macro or function declared in linux/atomic.h. Thus, these files can be removed from bcm203x.c safely without affecting the compilation of the ./drivers/bluetooth module Signed-off-by: Mianhan Liu <liumh1@shanghaitech.edu.cn> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Hans de Goede authored
The DSDT for the Asus TF103C specifies a IOAPIC IRQ for the HCI -> host IRQ but this is not correct. Unlike the previous entries in the table, this time the correct GPIO to use instead is known; and the TF103C is battery powered making runtime-pm support more important. Extend the bcm_broken_irq_dmi_table mechanism to allow specifying the right GPIO instead of just always disabling runtime-pm and add an entry to it for the Asus TF103C. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Yake Yang authored
It is time to add wide band speech (WBS) support. Reviewed-by: Mark Chen <markyawenchen@gmail.com> Co-developed-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Yake Yang <yake.yang@mediatek.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Yake Yang authored
add .btmtk_get_codec_config_data to get codec configuration data. In HFP offload usecase, controllers need to be set codec details before opening SCO. This callback function is used to fetch vendor specific codec config data. This is a preliminary patch to add the WBS support to the MT7921 driver. Reviewed-by: Mark Chen <markyawenchen@gmail.com> Co-developed-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Yake Yang <yake.yang@mediatek.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Yake Yang authored
Add .get_data_path_id to fetch data_path_id for MT7921 to support HFP offload use case. This is a preliminary patch to add the WBS support to the MT7921 driver. Reviewed-by: Mark Chen <markyawenchen@gmail.com> Co-developed-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Yake Yang <yake.yang@mediatek.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Yake Yang authored
The patch set HCI_QUIRK_VALID_LE_STATES to be consistent with the btusb for MT7921 and is required for the likes of experimental LE simultaneous roles. Reviewed-by: Mark Chen <markyawenchen@gmail.com> Co-developed-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Yake Yang <yake.yang@mediatek.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Yake Yang authored
Fix the following kernel oops in btmtksdio_interrrupt [ 14.339134] btmtksdio_interrupt+0x28/0x54 [ 14.339139] process_sdio_pending_irqs+0x68/0x1a0 [ 14.339144] sdio_irq_work+0x40/0x70 [ 14.339154] process_one_work+0x184/0x39c [ 14.339160] worker_thread+0x228/0x3e8 [ 14.339168] kthread+0x148/0x3ac [ 14.339176] ret_from_fork+0x10/0x30 That happened because hdev->power_on is already called before sdio_set_drvdata which btmtksdio_interrupt handler relies on is not properly set up. The details are shown as the below: hci_register_dev would run queue_work(hdev->req_workqueue, &hdev->power_on) as WQ_HIGHPRI workqueue_struct to complete the power-on sequeunce and thus hci_power_on may run before sdio_set_drvdata is done in btmtksdio_probe. The hci_dev_do_open in hci_power_on would initialize the device and enable the interrupt and thus it is possible that btmtksdio_interrupt is being called right before sdio_set_drvdata is filled out. When btmtksdio_interrupt is being called and sdio_set_drvdata is not filled , the kernel oops is going to happen because btmtksdio_interrupt access an uninitialized pointer. Fixes: 9aebfd4a ("Bluetooth: mediatek: add support for MediaTek MT7663S and MT7668S SDIO devices") Reviewed-by: Mark Chen <markyawenchen@gmail.com> Co-developed-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Yake Yang <yake.yang@mediatek.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Dan Carpenter authored
This code has an uninitialized variable warning: drivers/bluetooth/btmtkuart.c:184 mtk_hci_wmt_sync() error: uninitialized symbol 'wc'. But it also has error paths which have memory leaks. Fixes: 8f550f55b155 ("Bluetooth: btmtkuart: rely on BT_MTK module") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Niels Dossche authored
hci_le_conn_failed function's documentation says that the caller must hold hdev->lock. The only callsite that does not hold that lock is hci_le_conn_failed. The other 3 callsites hold the hdev->lock very locally. The solution is to hold the lock during the call to hci_le_conn_failed. Fixes: 3c857757 ("Bluetooth: Add directed advertising support through connect()") Signed-off-by: Niels Dossche <dossche.niels@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Manish Mandlik authored
When an Advertisement Monitor is configured with SamplingPeriod 0xFF, the controller reports only one adv report along with the MSFT Monitor Device event. When an advertiser matches multiple monitors, some controllers send one adv report for each matched monitor; whereas, some controllers send just one adv report for all matched monitors. In such a case, report Adv Monitor Device Found event for each matched monitor. Signed-off-by: Manish Mandlik <mmandlik@google.com> Reviewed-by: Miao-chen Chou <mcchou@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Manish Mandlik authored
Clear already tracked devices on system resume. Once the monitors are reregistered after resume, matched devices in range will be found again. Signed-off-by: Manish Mandlik <mmandlik@google.com> Reviewed-by: Miao-chen Chou <mcchou@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Gavin Li authored
Callers pass msg->msg_flags as flags, which contains MSG_DONTWAIT instead of O_NONBLOCK. Signed-off-by: Gavin Li <gavin@matician.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-