- 19 Mar, 2022 5 commits
-
-
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:
-
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 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:
-
- 18 Mar, 2022 35 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:
-
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:
-
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:
-
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:
-
Íñ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:
Íñigo Huguet <ihuguet@redhat.com> Link: https://lore.kernel.org/r/20220315091832.13873-1-ihuguet@redhat.comSigned-off-by:
-
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:
-
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:
-
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:
Yake Yang <yake.yang@mediatek.com> Signed-off-by:
-
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:
-
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:
-
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:
-
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:
-
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: -
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:
-
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:
-
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:
-
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:
-
Christophe JAILLET authored
data.pid is set twice with the same value. Remove one of these redundant calls. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by:
-
Max Chou authored
Add the support for RTL8852B BT controller on USB interface. The necessary firmware file will be submitted to linux-firmware. Signed-off-by:
Max Chou <max.chou@realtek.com> Signed-off-by:
-
Pavel Skripkin authored
Syzbot hit general protection fault in __pm_runtime_resume(). The problem was in missing NULL check. hu->serdev can be NULL and we should not blindly pass &serdev->dev somewhere, since it will cause GPF. Reported-by: syzbot+b9bd12fbed3485a3e51f@syzkaller.appspotmail.com Fixes: d9dd833c ("Bluetooth: hci_h5: Add runtime suspend") Signed-off-by:
Pavel Skripkin <paskripkin@gmail.com> Signed-off-by:
-
Luiz Augusto von Dentz authored
This fixes the following trace caused by receiving HCI_EV_DISCONN_PHY_LINK_COMPLETE which does call hci_conn_del without first checking if conn->type is in fact AMP_LINK and in case it is do properly cleanup upper layers with hci_disconn_cfm: ================================================================== BUG: KASAN: use-after-free in hci_send_acl+0xaba/0xc50 Read of size 8 at addr ffff88800e404818 by task bluetoothd/142 CPU: 0 PID: 142 Comm: bluetoothd Not tainted 5.17.0-rc5-00006-gda4022eeac1a #7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x45/0x59 print_address_description.constprop.0+0x1f/0x150 kasan_report.cold+0x7f/0x11b hci_send_acl+0xaba/0xc50 l2cap_do_send+0x23f/0x3d0 l2cap_chan_send+0xc06/0x2cc0 l2cap_sock_sendmsg+0x201/0x2b0 sock_sendmsg+0xdc/0x110 sock_write_iter+0x20f/0x370 do_iter_readv_writev+0x343/0x690 do_iter_write+0x132/0x640 vfs_writev+0x198/0x570 do_writev+0x202/0x280 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RSP: 002b:00007ffce8a099b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014 Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 14 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10 RDX: 0000000000000001 RSI: 00007ffce8a099e0 RDI: 0000000000000015 RAX: ffffffffffffffda RBX: 00007ffce8a099e0 RCX: 00007f788fc3cf77 R10: 00007ffce8af7080 R11: 0000000000000246 R12: 000055e4ccf75580 RBP: 0000000000000015 R08: 0000000000000002 R09: 0000000000000001 </TASK> R13: 000055e4ccf754a0 R14: 000055e4ccf75cd0 R15: 000055e4ccf4a6b0 Allocated by task 45: kasan_save_stack+0x1e/0x40 __kasan_kmalloc+0x81/0xa0 hci_chan_create+0x9a/0x2f0 l2cap_conn_add.part.0+0x1a/0xdc0 l2cap_connect_cfm+0x236/0x1000 le_conn_complete_evt+0x15a7/0x1db0 hci_le_conn_complete_evt+0x226/0x2c0 hci_le_meta_evt+0x247/0x450 hci_event_packet+0x61b/0xe90 hci_rx_work+0x4d5/0xc50 process_one_work+0x8fb/0x15a0 worker_thread+0x576/0x1240 kthread+0x29d/0x340 ret_from_fork+0x1f/0x30 Freed by task 45: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_set_free_info+0x20/0x30 __kasan_slab_free+0xfb/0x130 kfree+0xac/0x350 hci_conn_cleanup+0x101/0x6a0 hci_conn_del+0x27e/0x6c0 hci_disconn_phylink_complete_evt+0xe0/0x120 hci_event_packet+0x812/0xe90 hci_rx_work+0x4d5/0xc50 process_one_work+0x8fb/0x15a0 worker_thread+0x576/0x1240 kthread+0x29d/0x340 ret_from_fork+0x1f/0x30 The buggy address belongs to the object at ffff88800c0f0500 The buggy address is located 24 bytes inside of which belongs to the cache kmalloc-128 of size 128 The buggy address belongs to the page: 128-byte region [ffff88800c0f0500, ffff88800c0f0580) flags: 0x100000000000200(slab|node=0|zone=1) page:00000000fe45cd86 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xc0f0 raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000 raw: 0100000000000200 ffffea00003a2c80 dead000000000004 ffff8880078418c0 page dumped because: kasan: bad access detected ffff88800c0f0400: 00 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc Memory state around the buggy address: >ffff88800c0f0500: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88800c0f0480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88800c0f0580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ================================================================== ffff88800c0f0600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb Reported-by:Sönke Huster <soenke.huster@eknoes.de> Tested-by:
-
Ismael Ferreras Morezuelas authored
Another subset of the more recent batch of Chinese clones aren't specs-compliant and seem to lock up whenever they receive a HCI_OP_SET_EVENT_FLT with flt_type set to zero/HCI_FLT_CLEAR_ALL, which on Linux (until the recent HCI state-machine refactor) happened right at BR/EDR setup. As there are other less-straightforward ways of reaching those operations, this patch is still relevant. So, while all the previous efforts to wrangle the herd of fake CSRs seem to be paying off (and these also get detected as such) we still need to take care of this quirk; testers seem to agree that these dongles tend to work well enough afterwards. From some cursory USB packet capture on Windows it seems like that driver doesn't appear to use this clear-all functionality at all. This patch was tested on some really popular AliExpress-style dongles, in my case marked as "V5.0". Chip markings: UG8413, the backside of the PCB says "USB Dangel" (sic). Here is the `hciconfig -a` output; for completeness: hci0: Type: Primary Bus: USB BD Address: 00:1A:7D:DA:7X:XX ACL MTU: 679:8 SCO MTU: 48:16 UP RUNNING PSCAN ISCAN Features: 0xbf 0x3e 0x4d 0xfa 0xdb 0x3d 0x7b 0xc7 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH SNIFF Link mode: PERIPHERAL ACCEPT Name: 'CSR8510 A10.' Class: 0x7c0104 Service Classes: Rendering, Capturing, Object Transfer, Audio, Telephony Device Class: Computer, Desktop workstation HCI Version: 4.0 (0x6) Revision: 0x3120 LMP Version: 4.0 (0x6) Subversion: 0x22bb Manufacturer: Cambridge Silicon Radio (10) As well as the `lsusb -vv -d 0a12:0001`: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 224 Wireless bDeviceSubClass 1 Radio Frequency bDeviceProtocol 1 Bluetooth bMaxPacketSize0 64 idVendor 0x0a12 Cambridge Silicon Radio, Ltd idProduct 0x0001 Bluetooth Dongle (HCI mode) bcdDevice 88.91 iManufacturer 0 iProduct 2 BT DONGLE10 iSerial 0 bNumConfigurations 1 Also, changed the benign dmesg print that shows up whenever the generic force-suspend fails from bt_dev_err to bt_dev_warn; it's okay and done on a best-effort basis, not a problem if that does not work. Also, swapped the HCI subver and LMP subver numbers for the Barrot in the comment, which I copied wrong the last time around. Fixes: 81cac64b ("Bluetooth: Deal with USB devices that are faking CSR vendor") Fixes: cde1a8a9 ("Bluetooth: btusb: Fix and detect most of the Chinese Bluetooth controllers") Fixes: d74e0ae7 ("Bluetooth: btusb: Fix detection of some fake CSR controllers with a bcdDevice val of 0x0134") Fixes: 0671c066 ("Bluetooth: btusb: Add workaround for remote-wakeup issues with Barrot 8041a02 fake CSR controllers") Fixes: f4292e2f ("Bluetooth: btusb: Make the CSR clone chip force-suspend workaround more generic") Link: https://bugzilla.kernel.org/show_bug.cgi?id=60824 Link: https://gist.github.com/nevack/6b36b82d715dc025163d9e9124840a07 Cc: stable@vger.kernel.org Cc: Hans de Goede <hdegoede@redhat.com> Tested-by:
Gonzalo Tornaría <tornaria@cmat.edu.uy> Tested-by:
Mateus Lemos <lemonsmateus@gmail.com> Tested-by:
Ismael Ferreras Morezuelas <swyterzone@gmail.com> Signed-off-by:
-
Ismael Ferreras Morezuelas authored
Some controllers have problems with being sent a command to clear all filtering. While the HCI code does not unconditionally send a clear-all anymore at BR/EDR setup (after the state machine refactor), there might be more ways of hitting these codepaths in the future as the kernel develops. Cc: stable@vger.kernel.org Cc: Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Sean Wang authored
There is a conflict between MediaTek wmt event and msft vendor extension logic in the core layer since 145373cb ("Bluetooth: Add framework for Microsoft vendor extension") was introduced because we changed the type of mediatek wmt event to the type of msft vendor event in the driver. But the purpose we reported mediatek event to the core layer is for the diagnostic purpose with that we are able to see the full packet trace via monitoring socket with btmon. Thus, it is harmless we keep the original type of mediatek vendor event here to avoid breaking the msft extension function especially they can be supported by Mediatek future devices. Signed-off-by:
-
Sean Wang authored
add .set_bdaddr support Signed-off-by:
-
Sean Wang authored
Rely on btmtk module to reduce duplicated code Signed-off-by:
-
Takashi Iwai authored
Chicony Electronics BT device with 04f2:b49f seems to be a missing entry for Realtek RTL8723BE. T: Bus=02 Lev=01 Prnt=01 Port=03 Cnt=03 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 2.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04f2 ProdID=b49f Rev= 2.00 S: Manufacturer=Realtek S: Product=Bluetooth Radio S: SerialNumber=00e04c000001 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 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#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms BugLink: https://bugzilla.opensuse.org/show_bug.cgi?id=1196779Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Colin Ian King authored
Variable cur_len is being ininitialized with a value in the start of a for-loop but this is never read, it is being re-assigned a new value on the first statement in the for-loop. The initialization is redundant and can be removed. Cleans up clang scan build warning: net/bluetooth/mgmt.c:7958:14: warning: Although the value stored to 'cur_len' is used in the enclosing expression, the value is never actually read from 'cur_len' [deadcode.DeadStores] Signed-off-by:
-
Krasnov Arseniy Vladimirovich authored
Add test where sender sends two message, each with own data pattern. Reader tries to read first to broken buffer: it has three pages size, but middle page is unmapped. Then, reader tries to read second message to valid buffer. Test checks, that uncopied part of first message was dropped and thus not copied as part of second message. Signed-off-by:
Krasnov Arseniy Vladimirovich <AVKrasnov@sberdevices.ru> Reviewed-by:
Stefano Garzarella <sgarzare@redhat.com> Signed-off-by:
-
Krasnov Arseniy Vladimirovich authored
Test for receive timeout check: connection is established, receiver sets timeout, but sender does nothing. Receiver's 'read()' call must return EAGAIN. Signed-off-by:
-
David S. Miller authored
Merge tag 'wireless-next-2022-03-18' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Kalle Valo says: ==================== wireless-next patches for v5.18 Third set of patches for v5.18. Smaller set this time, support for mt7921u and some work on MBSSID support. Also a workaround for rfkill userspace event. Major changes: mac80211 * MBSSID beacon handling in AP mode rfkill * make new event layout opt-in to workaround buggy user space rtlwifi * support On Networks N150 device id mt76 * mt7915: MBSSID and 6 GHz band support * new driver mt7921u ==================== Signed-off-by:
-
David S. Miller authored
Raju Lakkaraju says: ==================== net: lan743x: PCI11010 / PCI11414 devices This patch series continues with the addition of supported features for the Ethernet function of the PCI11010 / PCI11414 devices to the LAN743x driver. ==================== Signed-off-by: -
Raju Lakkaraju authored
Add support for PTP-IO Event Output (Periodic Output - perout) for PCI11010/PCI11414 chips Signed-off-by:
Raju Lakkaraju <Raju.Lakkaraju@microchip.com> Signed-off-by:
-
Raju Lakkaraju authored
PTP-IOs block provides for time stamping PTP-IO input events. PTP-IOs are numbered from 0 to 11. When a PTP-IO is enabled by the corresponding bit in the PTP-IO Capture Configuration Register, a rising or falling edge, respectively, will capture the 1588 Local Time Counter Signed-off-by:
kernel test robot <lkp@intel.com> Signed-off-by:
-
