- 22 Jul, 2022 21 commits
-
-
Luiz Augusto von Dentz authored
These devices are likely going to be reprogrammed when disconnected so this avoid a whole bunch of commands attempt to remove and the add back to the list. Signed-off-by:
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Tested-by:
Zhengping Jiang <jiangzp@google.com>
-
Luiz Augusto von Dentz authored
When programming a new entry into the resolving list it shall default to network mode since the params may contain the mode programmed when the device was last added to the resolving list. Link: https://bugzilla.kernel.org/show_bug.cgi?id=209745 Fixes: 853b70b5 ("Bluetooth: hci_sync: Set Privacy Mode when updating the resolving list") Signed-off-by:
-
Tamas Koczka authored
Annotate hci_rx_work() with kcov_remote_start() and kcov_remote_stop() calls, so remote KCOV coverage is collected while processing the rx_q queue which is the main incoming Bluetooth packet queue. Coverage is associated with the thread which created the packet skb. The collected extra coverage helps kernel fuzzing efforts in finding vulnerabilities. This change only has effect if the kernel is compiled with CONFIG_KCOV, otherwise kcov_ functions don't do anything. Signed-off-by:
Tamas Koczka <poprdi@google.com> Tested-by:
Aleksandr Nogikh <nogikh@google.com> Reviewed-by:
Dmitry Vyukov <dvyukov@google.com> Signed-off-by:
-
Zhengping Jiang authored
After resuming, remove setting scanning_paused to false, because it is checked and set to false in hci_resume_scan_sync. Also move setting the value to false before updating passive scan, because the value is used when resuming passive scan. Fixes: 3b420553 (Bluetooth: hci_sync: Fix attempting to suspend with unfiltered passive scan) Signed-off-by:
Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by:
-
Sean Wang authored
Commit ce64b3e9 ("Bluetooth: mt7921s: Support wake on bluetooth") adds the wake on bluethooth via a dedicated GPIO. Extend the wake-on-bluetooth to use the SDIO DAT1 pin (in-band wakeup), when supported by the SDIO host driver. Co-developed-by:
Yake Yang <yake.yang@mediatek.com> Signed-off-by:
Sean Wang <sean.wang@mediatek.com> Reviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by:
-
Zhengping Jiang authored
Set the connection data before calling get_conn_info_sync, so it can be verified the connection is still connected, before refreshing cached values. Fixes: 47db6b42 ("Bluetooth: hci_sync: Convert MGMT_OP_GET_CONN_INFO") Signed-off-by:
-
Luiz Augusto von Dentz authored
The scan response and advertising data needs to be tracked on a per instance (adv_info) since when these instaces are removed so are their data, to fix that new flags are introduced which is used to mark when the data changes and then checked to confirm when the data needs to be synced with the controller. Tested-by:
Tedd Ho-Jeong An <tedd.an@intel.com> Signed-off-by:
-
Luiz Augusto von Dentz authored
Both dev_name and short_name are not guaranteed to be NULL terminated so this instead use strnlen and then attempt to determine if the resulting string needs to be truncated or not. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216018Signed-off-by:
-
Xiaohui Zhang authored
Similar to the handling of l2cap_ecred_connect in commit d3715b23 ("Bluetooth: use memset avoid memory leaks"), we thought a patch might be needed here as well. Use memset to initialize structs to prevent memory leaks in l2cap_le_connect Signed-off-by:
Xiaohui Zhang <xiaohuizhang@ruc.edu.cn> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
Dan Carpenter authored
Preserve the error code from hci_register_suspend_notifier(). Don't return success. Fixes: d6bb2a91f95b ("Bluetooth: Unregister suspend with userchannel") Signed-off-by:Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Ahmad Fatoum authored
The BCM4349B1, aka CYW/BCM89359, is a WiFi+BT chip and its Bluetooth portion can be controlled over serial. Two subversions are added for the chip, because ROM firmware reports 002.002.013 (at least for the chips I have here), while depending on patchram firmware revision, either 002.002.013 or 002.002.014 is reported. Signed-off-by:
Ahmad Fatoum <a.fatoum@pengutronix.de> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Ahmad Fatoum authored
The BCM4349B1, aka CYW/BCM89359, is a WiFi+BT chip and its Bluetooth portion can be controlled over serial. Extend the binding with its DT compatible. Acked-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
-
Abhishek Pandit-Subedi authored
When HCI_USERCHANNEL is used, unregister the suspend notifier when binding and register when releasing. The userchannel socket should be left alone after open is completed. Signed-off-by:
-
Abhishek Pandit-Subedi authored
When a userchannel socket is released, we should check whether the hdev is already unregistered before sending out an IndexAdded. Signed-off-by:
-
Schspa Shi authored
The HCI command, event, and data packet processing workqueue is drained to avoid deadlock in commit 76727c02 ("Bluetooth: Call drain_workqueue() before resetting state"). There is another delayed work, which will queue command to this drained workqueue. Which results in the following error report: Bluetooth: hci2: command 0x040f tx timeout WARNING: CPU: 1 PID: 18374 at kernel/workqueue.c:1438 __queue_work+0xdad/0x1140 Workqueue: events hci_cmd_timeout RIP: 0010:__queue_work+0xdad/0x1140 RSP: 0000:ffffc90002cffc60 EFLAGS: 00010093 RAX: 0000000000000000 RBX: ffff8880b9d3ec00 RCX: 0000000000000000 RDX: ffff888024ba0000 RSI: ffffffff814e048d RDI: ffff8880b9d3ec08 RBP: 0000000000000008 R08: 0000000000000000 R09: 00000000b9d39700 R10: ffffffff814f73c6 R11: 0000000000000000 R12: ffff88807cce4c60 R13: 0000000000000000 R14: ffff8880796d8800 R15: ffff8880796d8800 FS: 0000000000000000(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000c0174b4000 CR3: 000000007cae9000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? queue_work_on+0xcb/0x110 ? lockdep_hardirqs_off+0x90/0xd0 queue_work_on+0xee/0x110 process_one_work+0x996/0x1610 ? pwq_dec_nr_in_flight+0x2a0/0x2a0 ? rwlock_bug.part.0+0x90/0x90 ? _raw_spin_lock_irq+0x41/0x50 worker_thread+0x665/0x1080 ? process_one_work+0x1610/0x1610 kthread+0x2e9/0x3a0 ? kthread_complete_and_exit+0x40/0x40 ret_from_fork+0x1f/0x30 </TASK> To fix this, we can add a new HCI_DRAIN_WQ flag, and don't queue the timeout workqueue while command workqueue is draining. Fixes: 76727c02 ("Bluetooth: Call drain_workqueue() before resetting state") Reported-by: syzbot+63bed493aebbf6872647@syzkaller.appspotmail.com Signed-off-by:
Schspa Shi <schspa@gmail.com> Signed-off-by:
-
Jiasheng Jiang authored
As platform_driver_register() could fail, it should be better to deal with the return value in order to maintain the code consisitency. Fixes: 1ab1f239 ("Bluetooth: hci_intel: Add support for platform driver") Signed-off-by:
Jiasheng Jiang <jiasheng@iscas.ac.cn> Signed-off-by:
-
Alain Michaud authored
If a hardware error occurs and the connections are flushed without a disconnection_complete event being signaled, the temporary linkkeys are not flushed. This change ensures that any outstanding flushable linkkeys are flushed when the connection are flushed from the hash table. Additionally, this also makes use of test_and_clear_bit to avoid multiple attempts to delete the link key that's already been flushed. Signed-off-by:
Alain Michaud <alainm@chromium.org> Signed-off-by:
-
Hakan Jansson authored
Use the presence of a DT property, "brcm,requires-autobaud-mode", to enable startup in autobaud mode. If the property is present, the device is started in autobaud mode by asserting RTS (BT_UART_CTS_N) prior to powering on the device. Also prevent the use of unsupported commands for devices started in autobaud mode. Only a limited subset of HCI commands are supported in autobaud mode. Some devices (e.g. CYW5557x) require autobaud mode to enable FW loading. Autobaud mode can also be required on some boards where the controller device is using a non-standard baud rate in normal mode when first powered on. Signed-off-by:
Hakan Jansson <hakan.jansson@infineon.com> Signed-off-by:
-
Hakan Jansson authored
Add property, "brcm,requires-autobaud-mode", to enable autobaud mode selection. Some devices (e.g. CYW5557x) require autobaud mode to enable FW loading. Autobaud mode can also be required on some boards where the controller device is using a non-standard baud rate when first powered on. Signed-off-by:
-
Sai Teja Aluvala authored
This fixes the return value of qca_wakeup(), since .wakeup work inversely with original .prevent_wake. Fixes: 4539ca67 (Bluetooth: Rename driver .prevent_wake to .wakeup) Signed-off-by:
Sai Teja Aluvala <quic_saluvala@quicinc.com> Signed-off-by:
-
Aaron Ma authored
It is 13d3:3568 for MediaTek MT7922 USB Bluetooth chip. T: Bus=03 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3568 Rev=01.00 S: Manufacturer=MediaTek Inc. S: Product=Wireless_Device S: SerialNumber=... C: #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=0a(O) Atr=03(Int.) MxPS= 64 Ivl=125us E: Ad=8a(I) Atr=03(Int.) MxPS= 64 Ivl=125us Signed-off-by:
Aaron Ma <aaron.ma@canonical.com> Signed-off-by:
-
- 21 Jul, 2022 19 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski authored
No conflicts. Signed-off-by:Jakub Kicinski <kuba@kernel.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netLinus Torvalds authored
Pull networking fixes from Paolo Abeni: "Including fixes from can. Still no major regressions, most of the changes are still due to data races fixes, plus the usual bunch of drivers fixes. Previous releases - regressions: - tcp/udp: make early_demux back namespacified. - dsa: fix issues with vlan_filtering_is_global Previous releases - always broken: - ip: fix data-races around ipv4_net_table (round 2, 3 & 4) - amt: fix validation and synchronization bugs - can: fix detection of mcp251863 - eth: iavf: fix handling of dummy receive descriptors - eth: lan966x: fix issues with MAC table - eth: stmmac: dwmac-mediatek: fix clock issue Misc: - dsa: update documentation" * tag 'net-5.19-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (107 commits) mlxsw: spectrum_router: Fix IPv4 nexthop gateway indication net/sched: cls_api: Fix flow action initialization tcp: Fix data-races around sysctl_tcp_max_reordering. tcp: Fix a data-race around sysctl_tcp_abort_on_overflow. tcp: Fix a data-race around sysctl_tcp_rfc1337. tcp: Fix a data-race around sysctl_tcp_stdurg. tcp: Fix a data-race around sysctl_tcp_retrans_collapse. tcp: Fix data-races around sysctl_tcp_slow_start_after_idle. tcp: Fix a data-race around sysctl_tcp_thin_linear_timeouts. tcp: Fix data-races around sysctl_tcp_recovery. tcp: Fix a data-race around sysctl_tcp_early_retrans. tcp: Fix data-races around sysctl knobs related to SYN option. udp: Fix a data-race around sysctl_udp_l3mdev_accept. ip: Fix data-races around sysctl_ip_prot_sock. ipv4: Fix data-races around sysctl_fib_multipath_hash_fields. ipv4: Fix data-races around sysctl_fib_multipath_hash_policy. ipv4: Fix a data-race around sysctl_fib_multipath_use_neigh. can: rcar_canfd: Add missing of_node_put() in rcar_canfd_probe() can: mcp251xfd: fix detection of mcp251863 Documentation: fix udp_wmem_min in ip-sysctl.rst ...
-
Peter Zijlstra authored
Jann reported a race between munmap() and unmap_mapping_range(), where unmap_mapping_range() will no-op once unmap_vmas() has unlinked the VMA; however munmap() will not yet have invalidated the TLBs. Therefore unmap_mapping_range() will complete while there are still (stale) TLB entries for the specified range. Mitigate this by force flushing TLBs for VM_PFNMAP ranges. Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by:
Will Deacon <will@kernel.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Peter Zijlstra authored
Now that architectures are no longer allowed to override tlb_{start,end}_vma() re-arrange code so that there is only one implementation for each of these functions. This much simplifies trying to figure out what they actually do. Signed-off-by: -
Peter Zijlstra authored
The previous patch removed the tlb_flush_end() implementation which used tlb_flush_range(). This means: - csky did double invalidates, a range invalidate per vma and a full invalidate at the end - csky actually has range invalidates and as such the generic tlb_flush implementation is more efficient for it. Signed-off-by:
Guo Ren <guoren@kernel.org> Signed-off-by:
-
Peter Zijlstra authored
Scattered across the archs are 3 basic forms of tlb_{start,end}_vma(). Provide two new MMU_GATHER_knobs to enumerate them and remove the per arch tlb_{start,end}_vma() implementations. - MMU_GATHER_NO_FLUSH_CACHE indicates the arch has flush_cache_range() but does *NOT* want to call it for each VMA. - MMU_GATHER_MERGE_VMAS indicates the arch wants to merge the invalidate across multiple VMAs if possible. With these it is possible to capture the three forms: 1) empty stubs; select MMU_GATHER_NO_FLUSH_CACHE and MMU_GATHER_MERGE_VMAS 2) start: flush_cache_range(), end: empty; select MMU_GATHER_MERGE_VMAS 3) start: flush_cache_range(), end: flush_tlb_range(); default Obviously, if the architecture does not have flush_cache_range() then it also doesn't need to select MMU_GATHER_NO_FLUSH_CACHE. Signed-off-by: -
Khalid Masum authored
Currently the command 'lx-symbols' in gdb exits with the error`Function "do_init_module" not defined in "kernel/module.c"`. This occurs because the file kernel/module.c was moved to kernel/module/main.c. Fix this breakage by changing the path to "kernel/module/main.c" in LoadModuleBreakpoint. Signed-off-by:
Khalid Masum <khalid.masum.92@gmail.com> Acked-by:
Luis Chamberlain <mcgrof@kernel.org> Fixes: cfc1d277 ("module: Move all into module/") Reviewed-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
-
Linus Torvalds authored
Sedat Dilek noticed that I had an extraneous semicolon at the end of a line in the previous patch. It's harmless, but unintentional, and while compilers just treat it as an extra empty statement, for all I know some other tooling might warn about it. So clean it up before other people notice too ;) Fixes: 353f7988 ("watchqueue: make sure to serialize 'wqueue->defunct' properly") Reported-by:
Sedat Dilek <sedat.dilek@gmail.com> Signed-off-by:
-
Łukasz Spintzyk authored
DisplayLink ethernet devices require NTB buffers larger then 32kb in order to run with highest performance. This patch is changing upper limit of the rx and tx buffers. Those buffers are initialized with CDC_NCM_NTB_DEF_SIZE_RX and CDC_NCM_NTB_DEF_SIZE_TX which is 16kb so by default no device is affected by increased limit. Rx and tx buffer is increased under two conditions: - Device need to advertise that it supports higher buffer size in dwNtbMaxInMaxSize and dwNtbMaxOutMaxSize. - cdc_ncm/rx_max and cdc_ncm/tx_max driver parameters must be adjusted with udev rule or ethtool. Summary of testing and performance results: Tests were performed on following devices: - DisplayLink DL-3xxx family device - DisplayLink DL-6xxx family device - ASUS USB-C2500 2.5G USB3 ethernet adapter - Plugable USB3 1G USB3 ethernet adapter - EDIMAX EU-4307 USB-C ethernet adapter - Dell DBQBCBC064 USB-C ethernet adapter Performance measurements were done with: - iperf3 between two linux boxes - http://openspeedtest.com/ instance running on local test machine Insights from tests results: - All except one from third party usb adapters were not affected by increased buffer size to their advertised dwNtbOutMaxSize and dwNtbInMaxSize. Devices were generally reaching 912-940Mbps both download and upload. Only EDIMAX adapter experienced decreased download size from 929Mbps to 827Mbps with iper3, with openspeedtest decrease was from 968Mbps to 886Mbps. - DisplayLink DL-3xxx family devices experienced performance increase with iperf3 download from 300Mbps to 870Mbps and upload from 782Mbps to 844Mbps. With openspeedtest download increased from 556Mbps to 873Mbps and upload from 727Mbps to 973Mbps - DiplayLink DL-6xxx family devices are not affected by increased buffer size. Signed-off-by:
Łukasz Spintzyk <lukasz.spintzyk@synaptics.com> Acked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20220720060518.541-2-lukasz.spintzyk@synaptics.comSigned-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Dominik Czerwik authored
This improves performance and stability of DL-3xxx/DL-5xxx/DL-6xxx device series. Specifically prevents device from temporary network dropouts when playing video from the web and network traffic going through is high. Signed-off-by:
Dominik Czerwik <dominik.czerwik@synaptics.com> Signed-off-by:
-
Jakub Kicinski authored
Alex Elder says: ==================== net: ipa: move configuration data files This series moves the "ipa_data-vX.Y.c" files into a subdirectory. The first patch adds a Makefile variable containing the list of supported IPA versions, and uses it to simplify the way these files are specified. ==================== Link: https://lore.kernel.org/r/20220719150827.295248-1-elder@linaro.orgSigned-off-by:
-
Alex Elder authored
Reduce the clutter in the main IPA source directory by creating a new "data" subdirectory, and locating all of the configuration data files in there. Signed-off-by:
Alex Elder <elder@linaro.org> Signed-off-by:
-
Alex Elder authored
Create a variable in the Makefile listing the IPA versions supported by the driver. Use that to create the list of configuration data object files used (rather than listing them all individually). Add a SPDX license comment. Signed-off-by:
-
Jakub Kicinski authored
Alex Elder says: ==================== net: ipa: small transaction updates Version 2 of this series corrects a misspelling of "outstanding" pointed out by the netdev test bots. (For some reason I don't see that when I run "checkpatch".) I found and fixed a second instance of that word being misspelled as well. This series includes three changes to the transaction code. The first adds a new transaction list that represents a distinct state that has not been maintained. The second moves a field in the transaction information structure, and reorders its initialization a bit. The third skips a function call when it is known not to be necessary. The last two are very small "leftover" patches. ==================== Link: https://lore.kernel.org/r/20220719181020.372697-1-elder@linaro.orgSigned-off-by:
-
Alex Elder authored
Since commit 8797972a ("net: ipa: remove command info pool"), we don't allocate "command info" entries for command channel transactions. Fix a comment that seems to suggest we still do. (Even before that commit, the comment was out of place.) Signed-off-by:
-
Alex Elder authored
When the IPA driver has completed its initialization and setup stages, it emits a brief message to the log. Add a small message that reports when it has been removed. Signed-off-by:
-
Alex Elder authored
In gsi_trans_free(), there's no point in ipa_gsi_trans_release() if a transaction is unused. No used TREs means no IPA layer resources to clean up. So only call ipa_gsi_trans_release() if at least one TRE was used. Signed-off-by:
-
Alex Elder authored
The transaction map is really associated with the transaction pool; move its definition earlier in the gsi_trans_info structure. Rearrange initialization in gsi_channel_trans_init() so it sets the tre_avail value first, then initializes the transaction pool, and finally allocating the transaction map. Update comments. Signed-off-by:
-
Alex Elder authored
We currently put a transaction on the pending list when it has been committed. But until the channel's doorbell rings, these transactions aren't actually "owned" by the hardware yet. Add a new "committed" state (and list), to represent transactions that have been committed but not yet sent to hardware. Define "pending" to mean committed transactions that have been sent to hardware but have not yet completed. Signed-off-by:
-
