- 20 Jan, 2022 1 commit
-
-
Manish Mandlik authored
Whenever the controller starts/stops monitoring a bt device, it sends MSFT Monitor Device event. Add handler to read this vendor event. Test performed: - Verified by logs that the MSFT Monitor Device event is received from the controller whenever it starts/stops monitoring a device. Signed-off-by:
Manish Mandlik <mmandlik@google.com> Reviewed-by:
Miao-chen Chou <mcchou@google.com> Signed-off-by:
Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
- 14 Jan, 2022 1 commit
-
-
Soenke Huster authored
This event is just specified for SCO and eSCO link types. On the reception of a HCI_Synchronous_Connection_Complete for a BDADDR of an existing LE connection, LE link type and a status that triggers the second case of the packet processing a NULL pointer dereference happens, as conn->link is NULL. Signed-off-by:
Soenke Huster <soenke.huster@eknoes.de> Signed-off-by:
-
- 11 Jan, 2022 1 commit
-
-
Dan Carpenter authored
Add unlocks to two error paths in hci_inquiry_result_with_rssi_evt(). Fixes: fee64503 ("Bluetooth: hci_event: Use skb_pull_data when processing inquiry results") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
- 10 Jan, 2022 37 commits
-
-
Sean Wang authored
Have "..reg (%d)" to be consistent with the other similar error messages. Signed-off-by:
Sean Wang <sean.wang@mediatek.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
Sean Wang authored
move struct reg_read_cmd to btmtk.h to allow other mtk drivers refer to. Signed-off-by:
-
Mark Chen authored
The driver has to issue the specific command to enable Bluetooth SCO over the I2S/PCM interface on mt7921s, that is supported since the firmware with version 20211222191101 was added, and the patch would not cause any harm even when the old firmware is applied. The SCO profile with the patch was tested by setting up a VOIP application, connected to HFP device, checked telephony function can work normally. Co-developed-by:
Mark Chen <mark-yw.chen@mediatek.com> Signed-off-by:
-
Mark Chen authored
Enable wake on bluetooth on mt7921s that can be supported since the firmware with version 20211129211059 was added, and the patch would not cause any harm even when the old firmware is applied. The patch was tested by setting up an HID or HOGP profile to connect a Bluetooth keyboard and mouse, then putting the system to suspend, then trying to wake up the system by moving the Bluetooth keyboard or mouse, and then checking if the system can wake up and be brought back to the normal state. Co-developed-by:
-
Sean Wang authored
Using "btmtksdio" as the prefix instead of "btsdio" Signed-off-by:
-
Luiz Augusto von Dentz authored
This fixes the following warning: net/bluetooth/hci_sync.c:5143:5: warning: no previous prototype for ‘hci_le_ext_create_conn_sync’ [-Wmissing-prototypes] Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski authored
Merge in fixes directly in prep for the 5.17 merge window. No conflicts. Signed-off-by:Jakub Kicinski <kuba@kernel.org>
-
Benjamin Yim authored
After this parameter is passed in, there is no usage, and deleting it will not bring any impact. Reviewed-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Benjamin Yim <yan2228598786@gmail.com> Link: https://lore.kernel.org/r/20220109130824.2776-1-yan2228598786@gmail.comSigned-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask never fails if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. So, if dma_set_mask_and_coherent() succeeds, 'pci_using_dac' is known to be 1. Simplify code and remove some dead code accordingly. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/3011689e8c77d49d7e44509d5a8241320ec408c5.1641754134.git.christophe.jaillet@wanadoo.frSigned-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask never fails if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. Simplify code and remove some dead code accordingly. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask never fails if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. Simplify code and remove some dead code accordingly. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask never fails if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. Simplify code and remove some dead code accordingly. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask never fails if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. Simplify code and remove some dead code accordingly. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask never fails if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. So, if dma_set_mask_and_coherent() succeeds, 'pci_using_dac' is known to be 1. Simplify code and remove some dead code accordingly. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask never fails if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. So, if dma_set_mask_and_coherent() succeeds, 'highdma' is known to be true. Simplify code and remove some dead code accordingly. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask never fails if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. So, if dma_set_mask_and_coherent() succeeds, 'pci_using_dac' is known to be 1. Simplify code and remove some dead code accordingly. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask never fails if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. Moreover, dma_set_mask_and_coherent() returns 0 or -EIO, so the return code of the function can be used directly. Finally, inline bnx2x_set_coherency_mask() because it is now only a wrapper for a single dma_set_mask_and_coherent() call. Simplify code and remove some dead code accordingly. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask never fails if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. Moreover, dma_set_mask_and_coherent() returns 0 or -EIO, so the return code of the function can be used directly. There is no need to 'rc = -EIO' explicitly. Simplify code and remove some dead code accordingly. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask never fails if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. So if dma_set_mask_and_coherent() succeeds, 'netdev->features' will have NETIF_F_HIGHDMA in all cases. Move the assignment of this feature in be_netdev_init() instead be_probe() which is a much logical place. Simplify code and remove some dead code accordingly. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask never fails if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. So if dma_set_mask_and_coherent() succeeds, 'dma64' is know to be 'true'. Simplify code and remove some dead code accordingly. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask will never fail if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. So, if dma_set_mask_and_coherent() succeeds, 'using_dac' is known to be 'true'. This variable can be removed. Simplify code and remove some dead code accordingly. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask will never fail if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. If dma_set_mask_and_coherent() succeeds, 'ap->pci_using_dac' is known to be 1. So 'pci_using_dac' can be removed from the 'struct ace_private'. Simplify code and remove some dead code accordingly. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask will never fail if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. If dma_set_mask_and_coherent() succeeds, 'dac_enabled' is known to be 1. Simplify code and remove some dead code accordingly. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask will never fail if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. So qlcnic_set_dma_mask(), (in qlcnic_main.c) can be simplified a lot and inlined directly in its only caller. If dma_set_mask_and_coherent() succeeds, 'pci_using_dac' is known to be 1. So it can be removed from all the calling chain. qlcnic_setup_netdev() can finally be simplified as-well. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
-
Jakub Kicinski authored
Kees reports quoted commit introduced the following warning on arm64: drivers/net/ethernet/allwinner/sun4i-emac.c:922:60: error: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'resource_size_t' {aka 'long long unsigned int'} [-Werror=format=] 922 | netdev_info(ndev, "get io resource from device: 0x%x, size = %u\n", | ~^ | | | unsigned int | %llx 923 | regs->start, resource_size(regs)); | ~~~~~~~~~~~ | | | resource_size_t {aka long long unsigned int} .. and another one like that for resource_size(). Switch to %pa and a cast. Reported-by:Kees Cook <keescook@chromium.org> Fixes: 47869e82 ("sun4i-emac.c: add dma support") Link: https://lore.kernel.org/r/20220108034438.2227343-1-kuba@kernel.orgSigned-off-by:
-
Yunsheng Lin authored
As page_pool_refill_alloc_cache() is only called by __page_pool_get_cached(), which assumes non-concurrent access as suggested by the comment in __page_pool_get_cached(), and ptr_ring allows concurrent access between consumer and producer, so remove the spinlock in page_pool_refill_alloc_cache(). Signed-off-by:
Yunsheng Lin <linyunsheng@huawei.com> Acked-by:
Jesper Dangaard Brouer <brouer@redhat.com> Link: https://lore.kernel.org/r/20220107090042.13605-1-linyunsheng@huawei.comSigned-off-by:
-
Taehee Yoo authored
amt_send_membership_update() would return -1 but it's return type is bool. So, it should be used TRUE instead of -1. Fixes: cbc21dc1 ("amt: add data plane of amt interface") Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Taehee Yoo <ap420073@gmail.com> Link: https://lore.kernel.org/r/20220109163702.6331-1-ap420073@gmail.comSigned-off-by:
-
Pavel Skripkin authored
Syzbot reported uninit value in mcs7830_bind(). The problem was in missing validation check for bytes read via usbnet_read_cmd(). usbnet_read_cmd() internally calls usb_control_msg(), that returns number of bytes read. Code should validate that requested number of bytes was actually read. So, this patch adds missing size validation check inside mcs7830_get_reg() to prevent uninit value bugs Reported-and-tested-by: syzbot+003c0a286b9af5412510@syzkaller.appspotmail.com Fixes: 2a36d708 ("USB: driver for mcs7830 (aka DeLOCK) USB ethernet adapter") Signed-off-by:
Pavel Skripkin <paskripkin@gmail.com> Reviewed-by:
Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20220106225716.7425-1-paskripkin@gmail.comSigned-off-by:
-
Jakub Kicinski authored
Menglong Dong says: ==================== net: skb: introduce kfree_skb_with_reason() In this series patch, the interface kfree_skb_with_reason() is introduced(), which is used to collect skb drop reason, and pass it to 'kfree_skb' tracepoint. Therefor, 'drop_monitor' or eBPF is able to monitor abnormal skb with detail reason. In fact, this series patches are out of the intelligence of David and Steve, I'm just a truck man :/ Previous discussion is here: https://lore.kernel.org/netdev/20211118105752.1d46e990@gandalf.local.home/ https://lore.kernel.org/netdev/67b36bd8-2477-88ac-83a0-35a1eeaf40c9@gmail.com/ In the first patch, kfree_skb_with_reason() is introduced and the 'reason' field is added to 'kfree_skb' tracepoint. In the second patch, 'kfree_skb()' in replaced with 'kfree_skb_with_reason()' in tcp_v4_rcv(). In the third patch, 'kfree_skb_with_reason()' is used in __udp4_lib_rcv(). Changes since v3: - fix some code style problems in skb.h Changes since v2: - rename kfree_skb_with_reason() to kfree_skb_reason() - make kfree_skb() static inline, as Jakub suggested Changes since v1: - rename some drop reason, as David suggested - add the third patch ==================== Link: https://lore.kernel.org/r/20220109063628.526990-1-imagedong@tencent.comSigned-off-by:
-
Menglong Dong authored
Replace kfree_skb() with kfree_skb_reason() in __udp4_lib_rcv. New drop reason 'SKB_DROP_REASON_UDP_CSUM' is added for udp csum error. Signed-off-by:
Menglong Dong <imagedong@tencent.com> Signed-off-by:
-
Menglong Dong authored
Replace kfree_skb() with kfree_skb_reason() in tcp_v4_rcv(). Following drop reasons are added: SKB_DROP_REASON_NO_SOCKET SKB_DROP_REASON_PKT_TOO_SMALL SKB_DROP_REASON_TCP_CSUM SKB_DROP_REASON_TCP_FILTER After this patch, 'kfree_skb' event will print message like this: $ TASK-PID CPU# ||||| TIMESTAMP FUNCTION $ | | | ||||| | | <idle>-0 [000] ..s1. 36.113438: kfree_skb: skbaddr=(____ptrval____) protocol=2048 location=(____ptrval____) reason: NO_SOCKET The reason of skb drop is printed too. Signed-off-by: -
Menglong Dong authored
Introduce the interface kfree_skb_reason(), which is able to pass the reason why the skb is dropped to 'kfree_skb' tracepoint. Add the 'reason' field to 'trace_kfree_skb', therefor user can get more detail information about abnormal skb with 'drop_monitor' or eBPF. All drop reasons are defined in the enum 'skb_drop_reason', and they will be print as string in 'kfree_skb' tracepoint in format of 'reason: XXX'. ( Maybe the reasons should be defined in a uapi header file, so that user space can use them? ) Signed-off-by:
-
Jakub Kicinski authored
Build bot reports: drivers/net/ethernet/mellanox/mlx5/core/en_stats.c: In function 'fec_set_block_stats': drivers/net/ethernet/mellanox/mlx5/core/en_stats.c:1235:48: error: 'outl' undeclared (first use in this function); did you mean 'out'? 1235 | if (mlx5_core_access_reg(mdev, in, sz, outl, sz, MLX5_REG_PPCNT, 0, 0)) | ^~~~ | out Reported-by:Leon Romanovsky <leon@kernel.org> Signed-off-by:
-
Jakub Kicinski authored
Michael Chan says: ==================== bnxt_en: Update for net-next This series adds better error and debug logging for firmware messages. We now also use the firmware provided timeout value for long running commands instead of capping it to 40 seconds. ==================== Link: https://lore.kernel.org/r/1641772485-10421-1-git-send-email-michael.chan@broadcom.comSigned-off-by:
-
Edwin Peer authored
While it has always been possible to infer that an HWRM command was abandoned due to an unhealthy firmware status by the shortened timeout reported, this change improves the log messaging to account for this case explicitly. In the interests of further clarity, the firmware status is now also reported in these new messages. v2: Remove inline keyword for hwrm_wait_must_abort() in .c file. Reviewed-by:
Andy Gospodarek <gospo@broadcom.com> Signed-off-by:
Edwin Peer <edwin.peer@broadcom.com> Signed-off-by:
Michael Chan <michael.chan@broadcom.com> Signed-off-by:
-
Edwin Peer authored
Some older devices cannot accommodate the 40 seconds timeout cap for long running commands (such as NVRAM commands) due to hardware limitations. Allow these devices to request more time for these long running commands, but print a warning, since the longer timeout may cause the hung task watchdog to trigger. In the case of a firmware update operation, this is preferable to failing outright. v2: Use bp->hwrm_cmd_max_timeout directly without the constants. Fixes: 881d8353 ("bnxt_en: Add an upper bound for all firmware command timeouts.") Signed-off-by:
-
Edwin Peer authored
The current driver design relies on the PF netdev being open in order to intercept the following HWRM commands from a VF: - HWRM_FUNC_VF_CFG - HWRM_CFA_L2_FILTER_ALLOC - HWRM_PORT_PHY_QCFG (only if FW_CAP_LINK_ADMIN is not supported) If the PF is closed, then VFs are subjected to rather inscrutable error messages in response to any configuration requests involving the above command types. Recent firmware distinguishes this problem case from other errors by returning HWRM_ERR_CODE_PF_UNAVAILABLE. In most cases, the appropriate course of action is still to fail, but this can now be accomplished with the aid of more user informative log messages. For L2 filter allocations that are already asynchronous, an automatic retry seems more appropriate. v2: Delete extra newline. Signed-off-by:
-
