aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-06-13selftests/tc-testing: Fix Error: failed to find target LOGVlad Buslov1-0/+1
Add missing netfilter config dependency. Fixes following example error when running tests via tdc.sh for all XT tests: # $ sudo ./tdc.py -d eth2 -e 2029 # Test 2029: Add xt action with log-prefix # exit: 255 # exit: 0 # failed to find target LOG # # bad action parsing # parse_action: bad value (7:xt)! # Illegal "action" # # -----> teardown stage *** Could not execute: "$TC actions flush action xt" # # -----> teardown stage *** Error message: "Error: Cannot flush unknown TC action. # We have an error flushing # " # returncode 1; expected [0] # # -----> teardown stage *** Aborting test run. # # <_io.BufferedReader name=3> *** stdout *** # # <_io.BufferedReader name=5> *** stderr *** # "-----> teardown stage" did not complete successfully # Exception <class '__main__.PluginMgrTestFail'> ('teardown', ' failed to find target LOG\n\nbad action parsing\nparse_action: bad value (7:xt)!\nIllegal "action"\n', '"-----> teardown stage" did not complete successfully') (caught in test_runner, running test 2 2029 Add xt action with log-prefix stage teardown) # --------------- # traceback # File "/images/src/linux/tools/testing/selftests/tc-testing/./tdc.py", line 495, in test_runner # res = run_one_test(pm, args, index, tidx) # File "/images/src/linux/tools/testing/selftests/tc-testing/./tdc.py", line 434, in run_one_test # prepare_env(args, pm, 'teardown', '-----> teardown stage', tidx['teardown'], procout) # File "/images/src/linux/tools/testing/selftests/tc-testing/./tdc.py", line 245, in prepare_env # raise PluginMgrTestFail( # --------------- # accumulated output for this test: # failed to find target LOG # # bad action parsing # parse_action: bad value (7:xt)! # Illegal "action" # # --------------- # # All test results: # # 1..1 # ok 1 2029 - Add xt action with log-prefix # skipped - "-----> teardown stage" did not complete successfully Fixes: 910d504bc187 ("selftests/tc-testings: add selftests for xt action") Signed-off-by: Vlad Buslov <[email protected]> Reviewed-by: Pedro Tammela <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2023-06-13selftests/tc-testing: Fix Error: Specified qdisc kind is unknown.Vlad Buslov1-0/+1
All TEQL tests assume that sch_teql module is loaded. Load module in tdc.sh before running qdisc tests. Fixes following example error when running tests via tdc.sh for all TEQL tests: # $ sudo ./tdc.py -d eth2 -e 84a0 # -- ns/SubPlugin.__init__ # Test 84a0: Create TEQL with default setting # exit: 2 # exit: 0 # Error: Specified qdisc kind is unknown. # # -----> teardown stage *** Could not execute: "$TC qdisc del dev $DUMMY handle 1: root" # # -----> teardown stage *** Error message: "Error: Invalid handle. # " # returncode 2; expected [0] # # -----> teardown stage *** Aborting test run. # # <_io.BufferedReader name=3> *** stdout *** # # <_io.BufferedReader name=5> *** stderr *** # "-----> teardown stage" did not complete successfully # Exception <class '__main__.PluginMgrTestFail'> ('teardown', 'Error: Specified qdisc kind is unknown.\n', '"-----> teardown stage" did not complete successfully') (caught in test_runner, running test 2 84a0 Create TEQL with default setting stage teardown) # --------------- # traceback # File "/images/src/linux/tools/testing/selftests/tc-testing/./tdc.py", line 495, in test_runner # res = run_one_test(pm, args, index, tidx) # File "/images/src/linux/tools/testing/selftests/tc-testing/./tdc.py", line 434, in run_one_test # prepare_env(args, pm, 'teardown', '-----> teardown stage', tidx['teardown'], procout) # File "/images/src/linux/tools/testing/selftests/tc-testing/./tdc.py", line 245, in prepare_env # raise PluginMgrTestFail( # --------------- # accumulated output for this test: # Error: Specified qdisc kind is unknown. # # --------------- # # All test results: # # 1..1 # ok 1 84a0 - Create TEQL with default setting # skipped - "-----> teardown stage" did not complete successfully Fixes: cc62fbe114c9 ("selftests/tc-testing: add selftests for teql qdisc") Signed-off-by: Vlad Buslov <[email protected]> Reviewed-by: Victor Nogueira <[email protected]> Reviewed-by: Pedro Tammela <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2023-06-13net: ethernet: ti: am65-cpsw: Call of_node_put() on error pathDan Carpenter1-1/+1
This code returns directly but it should instead call of_node_put() to drop some reference counts. Fixes: dab2b265dd23 ("net: ethernet: ti: am65-cpsw: Add support for SERDES configuration") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Roger Quadros <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-06-13io_uring/net: save msghdr->msg_control for retriesJens Axboe1-1/+7
If the application sets ->msg_control and we have to later retry this command, or if it got queued with IOSQE_ASYNC to begin with, then we need to retain the original msg_control value. This is due to the net stack overwriting this field with an in-kernel pointer, to copy it in. Hitting that path for the second time will now fail the copy from user, as it's attempting to copy from a non-user address. Cc: [email protected] # 5.10+ Link: https://github.com/axboe/liburing/issues/880 Reported-and-tested-by: Marek Majkowski <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2023-06-13Merge tag 'nios2_fix_v6.4' of ↵Linus Torvalds2-2/+2
git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux Pull NIOS2 dts fix from Dinh Nguyen: - Fix tse_mac "max-frame-size" property * tag 'nios2_fix_v6.4' of git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux: nios2: dts: Fix tse_mac "max-frame-size" property
2023-06-13nios2: dts: Fix tse_mac "max-frame-size" propertyJanne Grunau2-2/+2
The given value of 1518 seems to refer to the layer 2 ethernet frame size without 802.1Q tag. Actual use of the "max-frame-size" including in the consumer of the "altr,tse-1.0" compatible is the MTU. Fixes: 95acd4c7b69c ("nios2: Device tree support") Fixes: 61c610ec61bb ("nios2: Add Max10 device tree") Cc: <[email protected]> Signed-off-by: Janne Grunau <[email protected]> Signed-off-by: Dinh Nguyen <[email protected]>
2023-06-13drm/amd/display: limit DPIA link rate to HBR3Peichen Huang1-0/+5
[Why] DPIA doesn't support UHBR, driver should not enable UHBR for dp tunneling [How] limit DPIA link rate to HBR3 Cc: Mario Limonciello <[email protected]> Cc: Alex Deucher <[email protected]> Cc: [email protected] Acked-by: Stylon Wang <[email protected]> Signed-off-by: Peichen Huang <[email protected]> Reviewed-by: Mustapha Ghaddar <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-06-13drm/amd/display: fix the system hang while disable PSRTom Chung1-4/+6
[Why] When the PSR enabled. If you try to adjust the timing parameters, it may cause system hang. Because the timing mismatch with the DMCUB settings. [How] Disable the PSR before adjusting timing parameters. Cc: Mario Limonciello <[email protected]> Cc: Alex Deucher <[email protected]> Cc: [email protected] Acked-by: Stylon Wang <[email protected]> Signed-off-by: Tom Chung <[email protected]> Reviewed-by: Wayne Lin <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-06-13drm/amd/display: edp do not add non-edid timingsHersen Wu1-1/+7
[Why] most edp support only timings from edid. applying non-edid timings, especially those timings out of edp bandwidth, may damage edp. [How] do not add non-edid timings for edp. Cc: Mario Limonciello <[email protected]> Cc: Alex Deucher <[email protected]> Cc: [email protected] Acked-by: Stylon Wang <[email protected]> Signed-off-by: Hersen Wu <[email protected]> Reviewed-by: Roman Li <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-06-13Revert "drm/amdgpu: remove TOPDOWN flags when allocating VRAM in large bar ↵Arunpravin Paneer Selvam1-1/+1
system" This reverts commit c105518679b6e87232874ffc989ec403bee59664. This patch disables the TOPDOWN flag for APU and few dGPU cards which has the VRAM size equal to the BAR size. When we enable the TOPDOWN flag, we get the free blocks at the highest available memory region and we don't split the lower order blocks. This change is required to keep off the fragmentation related issues particularly in ASIC which has VRAM space <= 500MiB Hence, we are reverting this patch. Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2270 Signed-off-by: Arunpravin Paneer Selvam <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2023-06-13drm/amdgpu: vcn_4_0 set instance 0 init sched score to 1Sonny Jiang1-1/+5
Only vcn0 can process AV1 codecx. In order to use both vcn0 and vcn1 in h264/265 transcode to AV1 cases, set vcn0 sched score to 1 at initialization time. Signed-off-by: Sonny Jiang <[email protected]> Reviewed-by: Leo Liu <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] # 6.1.x
2023-06-13drm/radeon: Disable outputs when releasing fbdev clientThomas Zimmermann1-0/+1
Disable the modesetting pipeline before release the radeon's fbdev client. Fixes the following error: [ 17.217408] WARNING: CPU: 5 PID: 1464 at drivers/gpu/drm/ttm/ttm_bo.c:326 ttm_bo_release+0x27e/0x2d0 [ttm] [ 17.217418] Modules linked in: edac_mce_amd radeon(+) drm_ttm_helper ttm video drm_suballoc_helper drm_display_helper kvm irqbypass drm_kms_helper syscopyarea crc32_pclmul sysfillrect sha512_ssse3 sysimgblt sha512_generic cfbfillrect cfbimgblt wmi_bmof aesni_intel cfbcopyarea crypto_simd cryptd k10temp acpi_cpufreq wmi dm_mod [ 17.217432] CPU: 5 PID: 1464 Comm: systemd-udevd Not tainted 6.4.0-rc4+ #1 [ 17.217436] Hardware name: Micro-Star International Co., Ltd. MS-7A38/B450M PRO-VDH MAX (MS-7A38), BIOS B.G0 07/26/2022 [ 17.217438] RIP: 0010:ttm_bo_release+0x27e/0x2d0 [ttm] [ 17.217444] Code: 48 89 43 38 48 89 43 40 48 8b 5c 24 30 48 8b b5 40 08 00 00 48 8b 6c 24 38 48 83 c4 58 e9 7a 49 f7 e0 48 89 ef e9 6c fe ff ff <0f> 0b 48 83 7b 20 00 0f 84 b7 fd ff ff 0f 0b 0f 1f 00 e9 ad fd ff [ 17.217448] RSP: 0018:ffffc9000095fbb0 EFLAGS: 00010202 [ 17.217451] RAX: 0000000000000001 RBX: ffff8881052c8de0 RCX: 0000000000000000 [ 17.217453] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff8881052c8de0 [ 17.217455] RBP: ffff888104a66e00 R08: ffff8881052c8de0 R09: ffff888104a7cf08 [ 17.217457] R10: ffffc9000095fbe0 R11: ffffc9000095fbe8 R12: ffff8881052c8c78 [ 17.217458] R13: ffff8881052c8c78 R14: dead000000000100 R15: ffff88810528b108 [ 17.217460] FS: 00007f319fcbb8c0(0000) GS:ffff88881a540000(0000) knlGS:0000000000000000 [ 17.217463] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 17.217464] CR2: 000055dc8b0224a0 CR3: 000000010373d000 CR4: 0000000000750ee0 [ 17.217466] PKRU: 55555554 [ 17.217468] Call Trace: [ 17.217470] <TASK> [ 17.217472] ? __warn+0x97/0x160 [ 17.217476] ? ttm_bo_release+0x27e/0x2d0 [ttm] [ 17.217481] ? report_bug+0x1ec/0x200 [ 17.217487] ? handle_bug+0x3c/0x70 [ 17.217490] ? exc_invalid_op+0x1f/0x90 [ 17.217493] ? preempt_count_sub+0xb5/0x100 [ 17.217496] ? asm_exc_invalid_op+0x16/0x20 [ 17.217500] ? ttm_bo_release+0x27e/0x2d0 [ttm] [ 17.217505] ? ttm_resource_move_to_lru_tail+0x1ab/0x1d0 [ttm] [ 17.217511] radeon_bo_unref+0x1a/0x30 [radeon] [ 17.217547] radeon_gem_object_free+0x20/0x30 [radeon] [ 17.217579] radeon_fbdev_fb_destroy+0x57/0x90 [radeon] [ 17.217616] unregister_framebuffer+0x72/0x110 [ 17.217620] drm_client_dev_unregister+0x6d/0xe0 [ 17.217623] drm_dev_unregister+0x2e/0x90 [ 17.217626] drm_put_dev+0x26/0x90 [ 17.217628] pci_device_remove+0x44/0xc0 [ 17.217631] really_probe+0x257/0x340 [ 17.217635] __driver_probe_device+0x73/0x120 [ 17.217638] driver_probe_device+0x2c/0xb0 [ 17.217641] __driver_attach+0xa0/0x150 [ 17.217643] ? __pfx___driver_attach+0x10/0x10 [ 17.217646] bus_for_each_dev+0x67/0xa0 [ 17.217649] bus_add_driver+0x10e/0x210 [ 17.217651] driver_register+0x5c/0x120 [ 17.217653] ? __pfx_radeon_module_init+0x10/0x10 [radeon] [ 17.217681] do_one_initcall+0x44/0x220 [ 17.217684] ? kmalloc_trace+0x37/0xc0 [ 17.217688] do_init_module+0x64/0x240 [ 17.217691] __do_sys_finit_module+0xb2/0x100 [ 17.217694] do_syscall_64+0x3b/0x90 [ 17.217697] entry_SYSCALL_64_after_hwframe+0x72/0xdc [ 17.217700] RIP: 0033:0x7f319feaa5a9 [ 17.217702] Code: 08 89 e8 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 27 08 0d 00 f7 d8 64 89 01 48 [ 17.217706] RSP: 002b:00007ffc6bf3e7f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 17.217709] RAX: ffffffffffffffda RBX: 00005607204f3170 RCX: 00007f319feaa5a9 [ 17.217710] RDX: 0000000000000000 RSI: 00007f31a002eefd RDI: 0000000000000018 [ 17.217712] RBP: 00007f31a002eefd R08: 0000000000000000 R09: 00005607204f1860 [ 17.217714] R10: 0000000000000018 R11: 0000000000000246 R12: 0000000000020000 [ 17.217716] R13: 0000000000000000 R14: 0000560720522450 R15: 0000560720255899 [ 17.217718] </TASK> [ 17.217719] ---[ end trace 0000000000000000 ]--- The buffer object backing the fbdev emulation got pinned twice: by the fb_probe helper radeon_fbdev_create_pinned_object() and the modesetting code when the framebuffer got displayed. It only got unpinned once by the fbdev helper radeon_fbdev_destroy_pinned_object(). Hence TTM's BO- release function complains about the pin counter. Forcing the outputs off also undoes the modesettings pin increment. Tested-by: Borislav Petkov (AMD) <[email protected]> Reported-by: Borislav Petkov <[email protected]> Closes: https://lore.kernel.org/dri-devel/20230603174814.GCZHt83pN+wNjf63sC@fat_crate.local/ Signed-off-by: Thomas Zimmermann <[email protected]> Fixes: e317a69fe891 ("drm/radeon: Implement client-based fbdev emulation") Cc: Alex Deucher <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: "Christian König" <[email protected]> Cc: "Pan, Xinhui" <[email protected]> Cc: [email protected] Signed-off-by: Alex Deucher <[email protected]>
2023-06-13drm/amd/pm: workaround for compute workload type on some skusKenneth Feng1-2/+31
On smu 13.0.0, the compute workload type cannot be set on all the skus due to some other problems. This workaround is to make sure compute workload type can also run on some specific skus. v2: keep the variable consistent Signed-off-by: Kenneth Feng <[email protected]> Acked-by: Lijo Lazar <[email protected]> Reviewed-by: Feifei Xu <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] # 6.1.x
2023-06-13drm/amd: Tighten permissions on VBIOS flashing attributesMario Limonciello1-2/+2
Non-root users shouldn't be able to try to trigger a VBIOS flash or query the flashing status. This should be reserved for users with the appropriate permissions. Cc: [email protected] Fixes: 8424f2ccb3c0 ("drm/amdgpu/psp: Add vbflash sysfs interface support") Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-06-13drm/amd: Make sure image is written to trigger VBIOS image update flowMario Limonciello1-0/+3
The VBIOS image update flow requires userspace to: 1) Write the image to `psp_vbflash` 2) Read `psp_vbflash` 3) Poll `psp_vbflash_status` to check for completion If userspace reads `psp_vbflash` before writing an image, it's possible that it causes problems that can put the dGPU into an invalid state. Explicitly check that an image has been written before letting a read succeed. Cc: [email protected] Fixes: 8424f2ccb3c0 ("drm/amdgpu/psp: Add vbflash sysfs interface support") Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-06-13drm/amdgpu: add missing radeon secondary PCI IDAlex Deucher1-0/+1
0x5b70 is a missing RV370 secondary id. Add it so we don't try and probe it with amdgpu. Cc: [email protected] Reviewed-by: Michel Dänzer <[email protected]> Tested-by: Michel Dänzer <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2023-06-13drm/amdgpu: Implement gfx9 patch functions for resubmissionJiadong Zhu1-0/+80
Patch the packages including CONTEXT_CONTROL and WRITE_DATA for gfx9 during the resubmission scenario. Signed-off-by: Jiadong Zhu <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] # 6.3.x
2023-06-13drm/amdgpu: Modify indirect buffer packages for resubmissionJiadong Zhu4-0/+102
When the preempted IB frame resubmitted to cp, we need to modify the frame data including: 1. set PRE_RESUME 1 in CONTEXT_CONTROL. 2. use meta data(DE and CE) read from CSA in WRITE_DATA. Add functions to save the location the first time IBs emitted and callback to patch the package when resubmission happens. Signed-off-by: Jiadong Zhu <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] # 6.3.x
2023-06-13drm/amdgpu: Program gds backup address as zero if no gds allocatedJiadong Zhu1-5/+8
It is firmware requirement to set gds_backup_addrlo and gds_backup_addrhi of DE meta both zero if no gds partition is allocated for the frame. Signed-off-by: Jiadong Zhu <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] # 6.3.x
2023-06-13drm/nouveau: add nv_encoder pointer check for NULLNatalia Petrova1-1/+2
Pointer nv_encoder could be dereferenced at nouveau_connector.c in case it's equal to NULL by jumping to goto label. This patch adds a NULL-check to avoid it. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 3195c5f9784a ("drm/nouveau: set encoder for lvds") Signed-off-by: Natalia Petrova <[email protected]> Reviewed-by: Lyude Paul <[email protected]> [Fixed patch title] Signed-off-by: Lyude Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-13drm/amdgpu: Reset CP_VMID_PREEMPT after trailing fence signaledJiadong Zhu1-4/+4
When MEC executes unmap_queue for mid command buffer preemption, it will kick the write pointer of the gfx ring, set CP_VMID_PREEMPT to trigger the preemption and wait for CP_VMID_PREEMPT becomes zero after the preemption done. There is a race condition that PFP may excute the resetting command before MEC set CP_VMID_PREEMPT. As a result, hang happens as CP_VMID_PREEMPT is always 0xffff. To avoid this, we send resetting CP_VMID_PREEMPT command after the trailing fence is siganled and update gfx write pointer explicitly. Signed-off-by: Jiadong Zhu <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] # 6.3.x Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2535
2023-06-13drm/nouveau/dp: check for NULL nv_connector->native_modeNatalia Petrova1-2/+2
Add checking for NULL before calling nouveau_connector_detect_depth() in nouveau_connector_get_modes() function because nv_connector->native_mode could be dereferenced there since connector pointer passed to nouveau_connector_detect_depth() and the same value of nv_connector->native_mode is used there. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: d4c2c99bdc83 ("drm/nouveau/dp: remove broken display depth function, use the improved one") Signed-off-by: Natalia Petrova <[email protected]> Reviewed-by: Lyude Paul <[email protected]> Signed-off-by: Lyude Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-13spi: dw: Replace incorrect spi_get_chipselect with setAbe Kohandel1-1/+1
Commit 445164e8c136 ("spi: dw: Replace spi->chip_select references with function calls") replaced direct access to spi.chip_select with spi_*_chipselect calls but incorrectly replaced a set instance with a get instance, replace the incorrect instance. Fixes: 445164e8c136 ("spi: dw: Replace spi->chip_select references with function calls") Signed-off-by: Abe Kohandel <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Acked-by: Serge Semin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2023-06-13drm/bridge: ti-sn65dsi86: Avoid possible buffer overflowSu Hui1-0/+4
Smatch error:buffer overflow 'ti_sn_bridge_refclk_lut' 5 <= 5. Fixes: cea86c5bb442 ("drm/bridge: ti-sn65dsi86: Implement the pwm_chip") Signed-off-by: Su Hui <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-13Merge tag 'devicetree-fixes-for-6.4-3' of ↵Linus Torvalds12-13/+15
git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux Pull devicetree fixes from Rob Herring: - Fix missing of_node_put() in init_overlay_changeset() - Fix schema for qcom,pmic-mpp "qcom,paired" property - Fix 'additionalProperties' in silvaco,i3c-master binding - usage-model.rst: Use documented "arm,primecell" compatible string - Update Damien Le Moal's email address - Fixes in Realtek Bluetooth binding * tag 'devicetree-fixes-for-6.4-3' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: dt-bindings: pinctrl: qcom,pmic-mpp: Fix schema for "qcom,paired" dt-bindings: i3c: silvaco,i3c-master: fix missing schema restriction of: overlay: Fix missing of_node_put() in error case of init_overlay_changeset() docs: zh_CN/devicetree: sync usage-model fix docs: dt: fix documented Primecell compatible string dt-bindings: Change Damien Le Moal's contact email dt-bindings: net: realtek-bluetooth: Fix double RTL8723CS in desc dt-bindings: net: realtek-bluetooth: Fix RTL8821CS binding
2023-06-13dt-bindings: pinctrl: qcom,pmic-mpp: Fix schema for "qcom,paired"Rob Herring1-2/+3
The "qcom,paired" schema is all wrong. First, it's a list rather than an object(dictionary). Second, it is missing a required type. The meta-schema normally catches this, but schemas under "$defs" was not getting checked. A fix for that is pending. Fixes: f9a06b810951 ("dt-bindings: pinctrl: qcom,pmic-mpp: Convert qcom pmic mpp bindings to YAML") Reviewed-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Herring <[email protected]>
2023-06-13regmap: regcache: Don't sync read-only registersTakashi Iwai1-0/+3
regcache_maple_sync() tries to sync all cached values no matter whether it's writable or not. OTOH, regache_sync_val() does care the wrtability and returns -EIO for a read-only register. This results in an error message like: snd_hda_codec_realtek hdaudioC0D0: Unable to sync register 0x2f0009. -5 and the sync loop is aborted incompletely. This patch adds the writable register check to regcache_sync_val() for addressing the bug above. Note that, although we may add the check in the caller side (regcache_maple_sync()), here we put in regcache_sync_val(), so that a similar case like this can be avoided in future. Fixes: f033c26de5a5 ("regmap: Add maple tree based register cache") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2023-06-13ASoC: tegra: Fix Master Volume ControlJon Hunter1-0/+3
Commit 3ed2b549b39f ("ALSA: pcm: fix wait_time calculations") corrected the PCM wait_time calculations and in doing so reduced the calculated wait_time. This exposed an issue with the Tegra Master Volume Control (MVC) device where the reduced wait_time caused the MVC to fail. For now fix this by setting the default wait_time for Tegra to be 500ms. Fixes: 3ed2b549b39f ("ALSA: pcm: fix wait_time calculations") Signed-off-by: Jon Hunter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2023-06-13tty: serial: fsl_lpuart: reduce RX watermark to 0 on LS1028ARobert Hodaszi1-1/+1
LS1028A is using DMA with LPUART. Having RX watermark set to 1, means DMA transactions are started only after receiving the second character. On other platforms with newer LPUART IP, Receiver Idle Empty function initiates the DMA request after the receiver is idling for 4 characters. But this feature is missing on LS1028A, which is causing a 1-character delay in the RX direction on this platform. Set RX watermark to 0 to initiate RX DMA after each character. Link: https://lore.kernel.org/linux-serial/[email protected]/ Fixes: 9ad9df844754 ("tty: serial: fsl_lpuart: Fix the wrong RXWATER setting for rx dma case") Cc: stable <[email protected]> Signed-off-by: Robert Hodaszi <[email protected]> Message-ID: <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-06-13drm/nouveau: don't detect DSM for non-NVIDIA deviceRatchanan Srirattanamet1-0/+3
The call site of nouveau_dsm_pci_probe() uses single set of output variables for all invocations. So, we must not write anything to them unless it's an NVIDIA device. Otherwise, if we are called with another device after the NVIDIA device, we'll clober the result of the NVIDIA device. For example, if the other device doesn't have _PR3 resources, the detection later would miss the presence of power resource support, and the rest of the code will keep using Optimus DSM, breaking power management for that machine. Also, because we're detecting NVIDIA's DSM, it doesn't make sense to run this detection on a non-NVIDIA device anyway. Thus, check at the beginning of the detection code if this is an NVIDIA card, and just return if it isn't. This, together with commit d22915d22ded ("drm/nouveau/devinit/tu102-: wait for GFW_BOOT_PROGRESS == COMPLETED") developed independently and landed earlier, fixes runtime power management of the NVIDIA card in Lenovo Legion 5-15ARH05. Without this patch, the GPU resumption code will "timeout", sometimes hanging userspace. As a bonus, we'll also stop preventing _PR3 usage from the bridge for unrelated devices, which is always nice, I guess. Fixes: ccfc2d5cdb02 ("drm/nouveau: Use generic helper to check _PR3 presence") Signed-off-by: Ratchanan Srirattanamet <[email protected]> Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/79 Reviewed-by: Karol Herbst <[email protected]> Signed-off-by: Karol Herbst <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/DM6PR19MB2780805D4BE1E3F9B3AC96D0BC409@DM6PR19MB2780.namprd19.prod.outlook.com
2023-06-13usb: gadget: udc: core: Prevent soft_connect_store() raceBadhri Jagan Sridharan1-49/+106
usb_udc_connect_control(), soft_connect_store() and usb_gadget_deactivate() can potentially race against each other to invoke usb_gadget_connect()/usb_gadget_disconnect(). To prevent this, guard udc->started, gadget->allow_connect, gadget->deactivate and gadget->connect with connect_lock so that ->pullup() is only invoked when the gadget is bound, started and not deactivated. The routines usb_gadget_connect_locked(), usb_gadget_disconnect_locked(), usb_udc_connect_control_locked(), usb_gadget_udc_start_locked(), usb_gadget_udc_stop_locked() are called with this lock held. An earlier version of this commit was reverted due to the crash reported in https://lore.kernel.org/all/[email protected]/. commit 16737e78d190 ("usb: gadget: udc: core: Offload usb_udc_vbus_handler processing") addresses the crash reported. Cc: [email protected] Fixes: 628ef0d273a6 ("usb: udc: add usb_udc_vbus_handler") Signed-off-by: Badhri Jagan Sridharan <[email protected]> Reviewed-by: Alan Stern <[email protected]> Message-ID: <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-06-13usb: gadget: udc: core: Offload usb_udc_vbus_handler processingBadhri Jagan Sridharan1-2/+27
usb_udc_vbus_handler() can be invoked from interrupt context by irq handlers of the gadget drivers, however, usb_udc_connect_control() has to run in non-atomic context due to the following: a. Some of the gadget driver implementations expect the ->pullup callback to be invoked in non-atomic context. b. usb_gadget_disconnect() acquires udc_lock which is a mutex. Hence offload invocation of usb_udc_connect_control() to workqueue. UDC should not be pulled up unless gadget driver is bound. The new flag "allow_connect" is now set by gadget_bind_driver() and cleared by gadget_unbind_driver(). This prevents work item to pull up the gadget even if queued when the gadget driver is already unbound. Cc: [email protected] Fixes: 1016fc0c096c ("USB: gadget: Fix obscure lockdep violation for udc_mutex") Signed-off-by: Badhri Jagan Sridharan <[email protected]> Reviewed-by: Alan Stern <[email protected]> Message-ID: <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-06-13usb: typec: Fix fast_role_swap_current show functionPavan Holla1-1/+1
The current implementation mistakenly performs a & operation on the output of sysfs_emit. This patch performs the & operation before calling sysfs_emit. Fixes: 662a60102c12 ("usb: typec: Separate USB Power Delivery from USB Type-C") Cc: stable <[email protected]> Reported-by: Benson Leung <[email protected]> Signed-off-by: Pavan Holla <[email protected]> Reviewed-by: Heikki Krogerus <[email protected]> Reviewed-by: Benson Leung <[email protected]> Message-ID: <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-06-13usb: typec: ucsi: Fix command cancellationHeikki Krogerus1-4/+7
The Cancel command was passed to the write callback as the offset instead of as the actual command which caused NULL pointer dereference. Reported-by: Stephan Bolten <[email protected]> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217517 Fixes: 094902bc6a3c ("usb: typec: ucsi: Always cancel the command if PPM reports BUSY condition") Cc: [email protected] Signed-off-by: Heikki Krogerus <[email protected]> Message-ID: <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-06-13USB: dwc3: fix use-after-free on core driver unbindJohan Hovold1-0/+5
Some dwc3 glue drivers are currently accessing the driver data of the child core device directly, which is clearly a bad idea as the child may not have probed yet or may have been unbound from its driver. As a workaround until the glue drivers have been fixed, clear the driver data pointer before allowing the glue parent device to runtime suspend to prevent its driver from accessing data that has been freed during unbind. Fixes: 6dd2565989b4 ("usb: dwc3: add imx8mp dwc3 glue layer driver") Fixes: 6895ea55c385 ("usb: dwc3: qcom: Configure wakeup interrupts during suspend") Cc: [email protected] # 5.12 Cc: Li Jun <[email protected]> Cc: Sandeep Maheswaram <[email protected]> Cc: Krishna Kurapati <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Acked-by: Thinh Nguyen <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Message-ID: <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-06-13USB: dwc3: qcom: fix NULL-deref on suspendJohan Hovold1-1/+10
The Qualcomm dwc3 glue driver is currently accessing the driver data of the child core device during suspend and on wakeup interrupts. This is clearly a bad idea as the child may not have probed yet or could have been unbound from its driver. The first such layering violation was part of the initial version of the driver, but this was later made worse when the hack that accesses the driver data of the grand child xhci device to configure the wakeup interrupts was added. Fixing this properly is not that easily done, so add a sanity check to make sure that the child driver data is non-NULL before dereferencing it for now. Note that this relies on subtleties like the fact that driver core is making sure that the parent is not suspended while the child is probing. Reported-by: Manivannan Sadhasivam <[email protected]> Link: https://lore.kernel.org/all/[email protected]/ Fixes: d9152161b4bf ("usb: dwc3: Add Qualcomm DWC3 glue layer driver") Fixes: 6895ea55c385 ("usb: dwc3: qcom: Configure wakeup interrupts during suspend") Cc: [email protected] # 3.18: a872ab303d5d: "usb: dwc3: qcom: fix use-after-free on runtime-PM wakeup" Cc: Sandeep Maheswaram <[email protected]> Cc: Krishna Kurapati <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Acked-by: Thinh Nguyen <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Message-ID: <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-06-13usb: dwc3: gadget: Reset num TRBs before giving back the requestElson Roy Serrao1-0/+1
Consider a scenario where cable disconnect happens when there is an active usb reqest queued to the UDC. As part of the disconnect we would issue an end transfer with no interrupt-on-completion before giving back this request. Since we are giving back the request without skipping TRBs the num_trbs field of dwc3_request still holds the stale value previously used. Function drivers re-use same request for a given bind-unbind session and hence their dwc3_request context gets preserved across cable disconnect/connect. When such a request gets re-queued after cable connect, we would increase the num_trbs field on top of the previous stale value thus incorrectly representing the number of TRBs used. Fix this by resetting num_trbs field before giving back the request. Fixes: 09fe1f8d7e2f ("usb: dwc3: gadget: track number of TRBs per request") Cc: stable <[email protected]> Signed-off-by: Elson Roy Serrao <[email protected]> Acked-by: Thinh Nguyen <[email protected]> Message-ID: <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-06-13usb: gadget: udc: renesas_usb3: Fix RZ/V2M {modprobe,bind} errorBiju Das1-2/+2
Currently {modprobe, bind} after {rmmod, unbind} results in probe failure. genirq: Flags mismatch irq 22. 00000004 (85070400.usb3drd) vs. 00000004 (85070400.usb3drd) renesas_usb3: probe of 85070000.usb3peri failed with error -16 The reason is, it is trying to register an interrupt handler for the same IRQ twice. The devm_request_irq() was called with the parent device. So the interrupt handler won't be unregistered when the usb3-peri device is unbound. Fix this issue by replacing "parent dev"->"dev" as the irq resource is managed by this driver. Fixes: 9cad72dfc556 ("usb: gadget: Add support for RZ/V2M USB3DRD driver") Cc: stable <[email protected]> Signed-off-by: Biju Das <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Message-ID: <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-06-12clk: clk-loongson2: Zero init clk_init_dataBinbin Zhou1-1/+1
As clk_core_populate_parent_map() checks clk_init_data.num_parents first, and checks clk_init_data.parent_names[] before clk_init_data.parent_data[] and clk_init_data.parent_hws[]. Therefore the clk_init_data structure needs to be explicitly initialised to prevent an unexpected crash if clk_init_data.parent_names[] is a random value. CPU 0 Unable to handle kernel paging request at virtual address 0000000000000dc0, era == 9000000002986290, ra == 900000000298624c Oops[#1]: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.4.0-rc2+ #4582 pc 9000000002986290 ra 900000000298624c tp 9000000100094000 sp 9000000100097a60 a0 9000000104541e00 a1 0000000000000000 a2 0000000000000dc0 a3 0000000000000001 a4 90000001000979f0 a5 90000001800977d7 a6 0000000000000000 a7 900000000362a000 t0 90000000034f3548 t1 6f8c2a9cb5ab5f64 t2 0000000000011340 t3 90000000031cf5b0 t4 0000000000000dc0 t5 0000000000000004 t6 0000000000011300 t7 9000000104541e40 t8 000000000005a4f8 u0 9000000104541e00 s9 9000000104541e00 s0 9000000104bc4700 s1 9000000104541da8 s2 0000000000000001 s3 900000000356f9d8 s4 ffffffffffffffff s5 0000000000000000 s6 0000000000000dc0 s7 90000000030d0a88 s8 0000000000000000 ra: 900000000298624c __clk_register+0x228/0x84c ERA: 9000000002986290 __clk_register+0x26c/0x84c CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) PRMD: 00000004 (PPLV0 +PIE -PWE) EUEN: 00000000 (-FPE -SXE -ASXE -BTE) ECFG: 00071c1c (LIE=2-4,10-12 VS=7) ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0) BADV: 0000000000000dc0 PRID: 0014a000 (Loongson-64bit, ) Modules linked in: Process swapper/0 (pid: 1, threadinfo=(____ptrval____), task=(____ptrval____)) Stack : 90000000031c1810 90000000030d0a88 900000000325bac0 90000000034f3548 90000001002ab410 9000000104541e00 0000000000000dc0 9000000003150098 90000000031c1810 90000000031a0460 900000000362a000 90000001002ab410 900000000362a000 9000000104541da8 9000000104541de8 90000001002ab410 900000000362a000 9000000002986a68 90000000034f3ed8 90000000030d0aa8 9000000104541da8 900000000298d3b8 90000000031c1810 0000000000000000 90000000034f3ed8 90000000030d0aa8 0000000000000dc0 90000000030d0a88 90000001002ab410 900000000298d401 0000000000000000 6f8c2a9cb5ab5f64 90000000034f4000 90000000030d0a88 9000000003a48a58 90000001002ab410 9000000104bd81a8 900000000298d484 9000000100020260 0000000000000000 ... Call Trace: [<9000000002986290>] __clk_register+0x26c/0x84c [<9000000002986a68>] devm_clk_hw_register+0x5c/0xe0 [<900000000298d3b8>] loongson2_clk_register.constprop.0+0xdc/0x10c [<900000000298d484>] loongson2_clk_probe+0x9c/0x4ac [<9000000002a4eba4>] platform_probe+0x68/0xc8 [<9000000002a4bf80>] really_probe+0xbc/0x2f0 [<9000000002a4c23c>] __driver_probe_device+0x88/0x128 [<9000000002a4c318>] driver_probe_device+0x3c/0x11c [<9000000002a4c5dc>] __driver_attach+0x98/0x18c [<9000000002a49ca0>] bus_for_each_dev+0x80/0xe0 [<9000000002a4b0dc>] bus_add_driver+0xfc/0x1ec [<9000000002a4d4a8>] driver_register+0x68/0x134 [<90000000020f0110>] do_one_initcall+0x50/0x188 [<9000000003150f00>] kernel_init_freeable+0x224/0x294 [<90000000030240fc>] kernel_init+0x20/0x110 [<90000000020f1568>] ret_from_kernel_thread+0xc/0xa4 Fixes: acc0ccffec50 ("clk: clk-loongson2: add clock controller driver support") Cc: [email protected] Cc: Yinbo Zhu <[email protected]> Signed-off-by: Binbin Zhou <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Stephen Boyd <[email protected]>
2023-06-12clk: mediatek: mt8365: Fix inverted topclk operationsMarkus Schneider-Pargmann1-3/+3
The given operations are inverted for the wrong registers which makes multiple of the mt8365 hardware units unusable. In my setup at least usb did not work. Fixed by swapping the operations with the inverted ones. Reported-by: Alexandre Mergnat <[email protected]> Fixes: 905b7430d3cc ("clk: mediatek: mt8365: Convert simple_gate to mtk_gate clocks") Signed-off-by: Markus Schneider-Pargmann <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Alexandre Mergnat <[email protected]> Reviewed-by: Alexandre Mergnat <[email protected]> Reviewed-by: Matthias Brugger <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Stephen Boyd <[email protected]>
2023-06-12clk: composite: Fix handling of high clock ratesSebastian Reichel1-1/+4
ULONG_MAX is used by a few drivers to figure out the highest available clock rate via clk_round_rate(clk, ULONG_MAX). Since abs() takes a signed value as input, the current logic effectively calculates with ULONG_MAX = -1, which results in the worst parent clock being chosen instead of the best one. For example on Rockchip RK3588 the eMMC driver tries to figure out the highest available clock rate. There are three parent clocks available resulting in the following rate diffs with the existing logic: GPLL: abs(18446744073709551615 - 1188000000) = 1188000001 CPLL: abs(18446744073709551615 - 1500000000) = 1500000001 XIN24M: abs(18446744073709551615 - 24000000) = 24000001 As a result the clock framework will promote a maximum supported clock rate of 24 MHz, even though 1.5GHz are possible. With the updated logic any casting between signed and unsigned is avoided and the numbers look like this instead: GPLL: 18446744073709551615 - 1188000000 = 18446744072521551615 CPLL: 18446744073709551615 - 1500000000 = 18446744072209551615 XIN24M: 18446744073709551615 - 24000000 = 18446744073685551615 As a result the parent with the highest acceptable rate is chosen instead of the parent clock with the lowest one. Cc: [email protected] Fixes: 49502408007b ("mmc: sdhci-of-dwcmshc: properly determine max clock on Rockchip") Tested-by: Christopher Obbard <[email protected]> Signed-off-by: Sebastian Reichel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Stephen Boyd <[email protected]>
2023-06-12Merge branch 'mptcp-fixes'Jakub Kicinski2-185/+354
Matthieu Baerts says: ==================== selftests: mptcp: skip tests not supported by old kernels (part 3) After a few years of increasing test coverage in the MPTCP selftests, we realised [1] the last version of the selftests is supposed to run on old kernels without issues. Supporting older versions is not that easy for this MPTCP case: these selftests are often validating the internals by checking packets that are exchanged, when some MIB counters are incremented after some actions, how connections are getting opened and closed in some cases, etc. In other words, it is not limited to the socket interface between the userspace and the kernelspace. In addition to that, the current MPTCP selftests run a lot of different sub-tests but the TAP13 protocol used in the selftests don't support sub-tests: one failure in sub-tests implies that the whole selftest is seen as failed at the end because sub-tests are not tracked. It is then important to skip sub-tests not supported by old kernels. To minimise the modifications and reduce the complexity to support old versions, the idea is to look at external signs and skip the whole selftest or just some sub-tests before starting them. This cannot be applied in all cases. Similar to the second part, this third one focuses on marking different sub-tests as skipped if some MPTCP features are not supported. This time, only in "mptcp_join.sh" selftest, the remaining one, is modified. Several techniques are used here to achieve this task: - Before starting some tests: - Check if a file (sysctl knob) is present: that's what patch 12/17 is doing for the userspace PM feature. - Check if a required kernel symbol is present in /proc/kallsyms: patches 9, 10, 14 and 15/17 are using this technique. - Check if it is possible to setup a particular network environment requiring Netfilter or TC: if the preparation step fail, the linked sub-test is marked as skipped. Patch 5/17 is doing that. - Check if a MIB counter is available: patches 7 and 13/17 do that. - Check if the kernel version is newer than a specific one: patch 1/17 adds some helpers in mptcp_lib.sh to ease its use. That's not ideal and it is only used as last resort but as mentioned above, it is important to skip tests if they are not supported not to have the whole selftest always being marked as failed on old kernels. Patches 11 and 17/17 are checking the kernel version. An alternative would be to ignore the results for some sub-tests but that's not ideal too. Note that SELFTESTS_MPTCP_LIB_NO_KVERSION_CHECK env var can be set to 1 not to skip these tests if the running kernel doesn't have a supported version. - After having launched the tests: - Adapt the expectations depending on the presence of a kernel symbol (patch 6/17) or a kernel version (patch 8/17). - Check is a MIB counter is available and skip the verification if not. Patch 4/17 is using this technique. Before skipping tests, SELFTESTS_MPTCP_LIB_EXPECT_ALL_FEATURES env var value is checked: if it is set to 1, the test is marked as "failed" instead of "skipped". MPTCP public CI expects to have all features supported and it sets this env var to 1 to catch regressions in these new checks. Patch 2/17 uses 'iptables-legacy' if available because it might be needed when using an older kernel not supporting iptables-nft. Patch 3/17 adds some helpers used in the other patches mentioned to easily mark sub-tests as skipped. Patch 16/17 uniforms MPTCP Join "listener" tests: it was imported code from userspace_pm.sh but without using the "code style" and ways of using tools and printing messages from MPTCP Join selftest. Link: https://lore.kernel.org/stable/CA+G9fYtDGpgT4dckXD-y-N92nqUxuvue_7AtDdBcHrbOMsDZLg@mail.gmail.com/ [1] Link: https://github.com/multipath-tcp/mptcp_net-next/issues/368 ==================== Link: https://lore.kernel.org/r/20230609-upstream-net-20230610-mptcp-selftests-support-old-kernels-part-3-v1-0-2896fe2ee8a3@tessares.net Signed-off-by: Jakub Kicinski <[email protected]>
2023-06-12selftests: mptcp: join: skip mixed tests if not supportedMatthieu Baerts1-4/+8
Selftests are supposed to run on any kernels, including the old ones not supporting all MPTCP features. One of them is the support of a mix of subflows in v4 and v6 by the in-kernel PM introduced by commit b9d69db87fb7 ("mptcp: let the in-kernel PM use mixed IPv4 and IPv6 addresses"). It looks like there is no external sign we can use to predict the expected behaviour. Instead of accepting different behaviours and thus not really checking for the expected behaviour, we are looking here for a specific kernel version. That's not ideal but it looks better than removing the test because it cannot support older kernel versions. Link: https://github.com/multipath-tcp/mptcp_net-next/issues/368 Fixes: ad3493746ebe ("selftests: mptcp: add test-cases for mixed v4/v6 subflows") Cc: [email protected] Signed-off-by: Matthieu Baerts <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2023-06-12selftests: mptcp: join: uniform listener testsMatthieu Baerts1-16/+14
The alignment was different from the other tests because tabs were used instead of spaces. While at it, also use 'echo' instead of 'printf' to print the result to keep the same style as done in the other sub-tests. And, even if it should be better with, also remove 'stdbuf' and sed's '--unbuffered' option because they are not used in the other subtests and they are not available when using a minimal environment with busybox. Link: https://github.com/multipath-tcp/mptcp_net-next/issues/368 Fixes: 178d023208eb ("selftests: mptcp: listener test for in-kernel PM") Cc: [email protected] Signed-off-by: Matthieu Baerts <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2023-06-12selftests: mptcp: join: skip PM listener tests if not supportedMatthieu Baerts1-0/+5
Selftests are supposed to run on any kernels, including the old ones not supporting all MPTCP features. One of them is the support of PM listener events introduced by commit f8c9dfbd875b ("mptcp: add pm listener events"). It is possible to look for "mptcp_event_pm_listener" in kallsyms to know in advance if the kernel supports this feature. Link: https://github.com/multipath-tcp/mptcp_net-next/issues/368 Fixes: 178d023208eb ("selftests: mptcp: listener test for in-kernel PM") Cc: [email protected] Signed-off-by: Matthieu Baerts <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2023-06-12selftests: mptcp: join: skip MPC backups tests if not supportedMatthieu Baerts1-4/+8
Selftests are supposed to run on any kernels, including the old ones not supporting all MPTCP features. One of them is the support of sending an MP_PRIO signal for the initial subflow, introduced by commit c157bbe776b7 ("mptcp: allow the in kernel PM to set MPC subflow priority"). It is possible to look for "mptcp_subflow_send_ack" in kallsyms because it was needed to introduce the mentioned feature. So we can know in advance if the feature is supported instead of trying and accepting any results. Link: https://github.com/multipath-tcp/mptcp_net-next/issues/368 Fixes: 914f6a59b10f ("selftests: mptcp: add MPC backup tests") Cc: [email protected] Signed-off-by: Matthieu Baerts <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2023-06-12selftests: mptcp: join: skip fail tests if not supportedMatthieu Baerts1-1/+1
Selftests are supposed to run on any kernels, including the old ones not supporting all MPTCP features. One of them is the support of the MP_FAIL / infinite mapping introduced by commit 1e39e5a32ad7 ("mptcp: infinite mapping sending") and the following ones. It is possible to look for one of the infinite mapping counters to know in advance if the this feature is available. Link: https://github.com/multipath-tcp/mptcp_net-next/issues/368 Fixes: b6e074e171bc ("selftests: mptcp: add infinite map testcase") Cc: [email protected] Fixes: 2ba18161d407 ("selftests: mptcp: add MP_FAIL reset testcase") Signed-off-by: Matthieu Baerts <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2023-06-12selftests: mptcp: join: skip userspace PM tests if not supportedMatthieu Baerts1-9/+17
Selftests are supposed to run on any kernels, including the old ones not supporting all MPTCP features. One of them is the support of the userspace PM introduced by commit 4638de5aefe5 ("mptcp: handle local addrs announced by userspace PMs") and the following ones. It is possible to look for the MPTCP pm_type's sysctl knob to know in advance if the userspace PM is available. Link: https://github.com/multipath-tcp/mptcp_net-next/issues/368 Fixes: 5ac1d2d63451 ("selftests: mptcp: Add tests for userspace PM type") Cc: [email protected] Signed-off-by: Matthieu Baerts <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2023-06-12selftests: mptcp: join: skip fullmesh flag tests if not supportedMatthieu Baerts1-4/+8
Selftests are supposed to run on any kernels, including the old ones not supporting all MPTCP features. One of them is the support of the fullmesh flag for the in-kernel PM introduced by commit 2843ff6f36db ("mptcp: remote addresses fullmesh") and commit 1a0d6136c5f0 ("mptcp: local addresses fullmesh"). It looks like there is no easy external sign we can use to predict the expected behaviour. We could add the flag and then check if it has been added but for that, and for each fullmesh test, we would need to setup a new environment, do the checks, clean it and then only start the test from yet another clean environment. To keep it simple and avoid introducing new issues, we look for a specific kernel version. That's not ideal but an acceptable solution for this case. Link: https://github.com/multipath-tcp/mptcp_net-next/issues/368 Fixes: 6a0653b96f5d ("selftests: mptcp: add fullmesh setting tests") Cc: [email protected] Signed-off-by: Matthieu Baerts <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2023-06-12selftests: mptcp: join: skip backup if set flag on ID not supportedMatthieu Baerts1-3/+6
Selftests are supposed to run on any kernels, including the old ones not supporting all MPTCP features. Commit bccefb762439 ("selftests: mptcp: simplify pm_nl_change_endpoint") has simplified the way the backup flag is set on an endpoint. Instead of doing: ./pm_nl_ctl set 10.0.2.1 flags backup Now we do: ./pm_nl_ctl set id 1 flags backup The new way is easier to maintain but it is also incompatible with older kernels not supporting the implicit endpoints putting in place the infrastructure to set flags per ID, hence the second Fixes tag. Link: https://github.com/multipath-tcp/mptcp_net-next/issues/368 Fixes: bccefb762439 ("selftests: mptcp: simplify pm_nl_change_endpoint") Cc: [email protected] Fixes: 4cf86ae84c71 ("mptcp: strict local address ID selection") Signed-off-by: Matthieu Baerts <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.