- Apr 15, 2024
-
-
Phil Elwell authored
Get rid of the remaining node.js warnings by updating the actions. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
-
- Apr 08, 2024
-
-
Cavon Lee authored
-
- Mar 15, 2024
-
-
Erik Botö authored
Also create generic overrides in camera-mux-N-port, that can be extended to configure vsync modes for cameras supporting this. Example usages (to be combined with camera_auto_detect=0): dtoverlay=imx477,cam0,sync-source dtoverlay=imx477,sync-sink dtoverlay=camera-mux-2port,cam1-imx477,cam1-sync-sink dtoverlay=camera-mux-4port,cam3-imx477,cam3-sync-sink Signed-off-by: Erik Botö <erik.boto@gmail.com>
-
Erik Botö authored
Allow trigger-mode to be overridden using device tree so that it can be set per camera. Previously the mode could only be changed using a module parameter, which would then affect all cameras. Signed-off-by: Erik Botö <erik.boto@gmail.com>
-
- Mar 13, 2024
-
-
j-schambacher authored
As we have never released a (standard) DACplusADC board with onboard clocks, we can simply use a fixed setup avoiding incompatibilities with Pi5 during driver init. Setting 'hifiberry-dacplusadc,slave' in the overlays disables the failing clock probing mechanism. Removes 'slave' parameter description from README which is still supported but not needed. Signed-off-by: j-schambacher <joerg@hifiberry.com>
-
j-schambacher authored
Same issue as #5919. 'width' needs to be set independent of clocking mode. Signed-off-by: j-schambacher <joerg@hifiberry.com>
-
j-schambacher authored
Adds all available Hifberry cards' UUIDs to the hat_map file. Signed-off-by: j-schambacher <joerg@hifiberry.com>
-
- Mar 12, 2024
-
-
j-schambacher authored
As the easy switching of the I2S module bewteen clock producer/consumer on the PI5 is not possible, two specific DT-overlays are introduced. The DAC+PRO boards with onboard clocks use the -PRO overlay, the boards without oscillators the -STD version. The "hifiberry-dacplus,slave" parameter in the -STD overlay disables the automatic clock detection inside the hifiberry-dacplus driver. The former hifiberry-dacplus overlay is kept for compatibility but will be deprecated. Signed-off-by: j-schambacher <joerg@hifiberry.com>
-
- Mar 11, 2024
-
-
Eng33 authored
Signed-off-by: Eng33 <eng33@waveshare.net>
-
Eng33 authored
Signed-off-by: Eng33 <eng33@waveshare.net>
-
Eng33 authored
Signed-off-by: Eng33 <eng33@waveshare.net>
-
Eng33 authored
Signed-off-by: Eng33 <eng33@waveshare.net>
-
- Mar 05, 2024
-
-
Florian Wesch authored
The code was reducing the number of components by one when we were not blending with alpha. But that only makes sense if the components include alpha. For YUV, we were reducing the number of components for Y from one to zero which resulted in no lbm space being allocated. Fixes: https://github.com/raspberrypi/linux/issues/5912 Signed-off-by: Dom Cobley <popcornmix@gmail.com> Co-authored-by: Dom Cobley <popcornmix@gmail.com>
-
- Feb 29, 2024
-
-
Phil Elwell authored
Allowing an unprivileged user to dump processor registers leaves the door open to the leaking of sensitive data. Disable it. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
-
j-schambacher authored
Dedicated overlay claiming all 4 data lanes of the designware I2S0 module to drive 4x PCM5102. THe devices share BCLK and LRCLK, therefore all outputs will always run at the same samplerate and format. Compatible only with PI5! Signed-off-by: j-schambacher <joerg@hifiberry.com>
-
j-schambacher authored
Defines the settings for the 8 channel version of the standard DAC by overwriting the number of channels in the DAI defs. It can run in 8ch mode only on PI5 using the 4 lane data output of the designware I2S0 module. Signed-off-by: j-schambacher <joerg@hifiberry.com>
-
- Feb 21, 2024
-
-
Andrew Scheller authored
Fixes https://github.com/raspberrypi/Pi-Codec/issues/9
-
- Feb 18, 2024
-
-
Phil Elwell authored
The label 'i2c' is no longer created by the firmware - i2c_arm or i2c1 should be used instead. Replace the last occurrence of &i2c with &i2c1. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
-
Maíra Canal authored
Currently, the V3D driver uses PAGE_SHIFT over the assumption that PAGE_SHIFT = 12, as the PAGE_SIZE = 4KB. But, the RPi 5 is using PAGE_SIZE = 16KB, so the MMU PAGE_SHIFT is different than the system's PAGE_SHIFT. Enable V3D to be used in system's with any PAGE_SIZE by making sure that everything MMU-related uses the MMU page shift. Signed-off-by: Maíra Canal <mcanal@igalia.com>
-
Maíra Canal authored
This implementation of MMU support for larger pages doesn't address the real problem: we are using the system's PAGE_SHIFT (which depends on the PAGE_SIZE) to allocate the VA. This implementation is especially problematic when dealing with a high memory usage, e.g. vkoverhead and RBDOOM-3-BFG, as it can lead to a kernel crash: [ 72.794493] Unable to handle kernel paging request at virtual address ffffc00009b58000 [ 72.802451] Mem abort info: [ 72.805251] ESR = 0x0000000096000047 [ 72.809011] EC = 0x25: DABT (current EL), IL = 32 bits [ 72.814340] SET = 0, FnV = 0 [ 72.817399] EA = 0, S1PTW = 0 [ 72.820544] FSC = 0x07: level 3 translation fault [ 72.825438] Data abort info: [ 72.828320] ISV = 0, ISS = 0x00000047 [ 72.832165] CM = 0, WnR = 1 [ 72.835137] swapper pgtable: 16k pages, 47-bit VAs, pgdp=000000000123c000 [ 72.841950] [ffffc00009b58000] pgd=100000010018c003, p4d=100000010018c003, pud=100000010018c003, pmd=1000000100190003, pte=0000000000000000 [ 72.854530] Internal error: Oops: 0000000096000047 [#1] PREEMPT SMP [ 72.860819] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device algif_hash algif_skcipher af_alg bnep binfmt_misc brcmfmac brcmutil hci_uart cfg80211 btbcm bluetooth aes_ce_blk aes_ce_cipher ghash_ce gf128mul sha2_ce rpivid_hevc(C) pisp_be joydev ecdh_generic sha256_arm64 ecc v4l2_mem2mem sha1_ce videobuf2_dma_contig videobuf2_memops rfkill videobuf2_v4l2 libaes videobuf2_common raspberrypi_hwmon videodev mc pwm_fan rp1_adc raspberrypi_gpiomem nvmem_rmem uio_pdrv_genirq uio i2c_dev fuse dm_mod ip_tables x_tables ipv6 hid_logitech_hidpp hid_logitech_dj vc4 snd_soc_hdmi_codec drm_display_helper cec drm_dma_helper spidev drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops snd_soc_core snd_compress spi_bcm2835 snd_pcm_dmaengine v3d gpu_sched drm_shmem_helper i2c_brcmstb drm snd_pcm snd_timer snd gpio_keys drm_panel_orientation_quirks backlight [ 72.938384] CPU: 1 PID: 1918 Comm: vkoverhead Tainted: G C 6.1.0-rpi8-rpi-2712 #1 Debian 1:6.1.73-1+rpt1 [ 72.949386] Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT) [ 72.955236] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 72.962222] pc : v3d_mmu_insert_ptes+0xc0/0x154 [v3d] [ 72.967298] lr : v3d_mmu_insert_ptes+0x6c/0x154 [v3d] [ 72.972369] sp : ffffc0000a07bbb0 [ 72.975688] x29: ffffc0000a07bbb0 x28: ffffc0000a07bd48 x27: 0000000000000010 [ 72.982849] x26: ffffc0000a07bd48 x25: ffff800101d9ca00 x24: 0000000000000042 [ 72.990009] x23: ffff800101d9ca00 x22: ffff800100d42000 x21: 0000000000100004 [ 72.997169] x20: ffff8001ca4cc000 x19: 0000000000ffffff x18: 0000000000000100 [ 73.004330] x17: 0000000000000000 x16: ffffd0000c6434b0 x15: ffffd0000d16c008 [ 73.011491] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 73.018652] x11: 0000000000000001 x10: 0000000000000000 x9 : ffffcfffde8dc260 [ 73.025813] x8 : ffff800100d42700 x7 : 0000000000003fff x6 : ffff8001ca3a1520 [ 73.032973] x5 : 0000000000100000 x4 : ffffc00009758000 x3 : 0000000000100000 [ 73.040134] x2 : 00000000301ca4cf x1 : 0000000000100001 x0 : 00000000301ca4d0 [ 73.047295] Call trace: [ 73.049741] v3d_mmu_insert_ptes+0xc0/0x154 [v3d] [ 73.054463] v3d_bo_create_finish+0xd0/0xf0 [v3d] [ 73.059185] v3d_create_bo_ioctl+0x50/0x150 [v3d] [ 73.063906] drm_ioctl_kernel+0xd0/0x180 [drm] [ 73.068412] drm_ioctl+0x214/0x430 [drm] [ 73.072383] __arm64_sys_ioctl+0xb4/0xfc [ 73.076318] invoke_syscall+0x50/0x120 [ 73.080077] el0_svc_common.constprop.0+0x4c/0xf4 [ 73.084794] do_el0_svc+0x34/0xd0 [ 73.088114] el0_svc+0x2c/0x84 [ 73.091173] el0t_64_sync_handler+0xf4/0x120 [ 73.095454] el0t_64_sync+0x18c/0x190 [ 73.099124] Code: 2a0103e3 11000421 4b050020 0b020000 (b8237880) [ 73.105237] ---[ end trace 0000000000000000 ]--- Signed-off-by: Maíra Canal <mcanal@igalia.com>
-
- Feb 16, 2024
-
-
Ben Payne authored
Adding 2 new overlays for use with Interlude Audio's Digital and Analog hats adding descriptions for both in README adding changes to Makefile to include both DT's
-
Ben Payne authored
Implementing driver support for Interlude audio's WM8805 based digital hat by leveraging existing drivers
-
- Feb 08, 2024
-
-
Phil Elwell authored
Since [1], the fbdev deferred IO framework is careful to cancel pending updates on close to prevent dirty pages being accessed after they may have been reused. However, this is not necessary in the case that the pagelist is empty, and drivers that don't make use of the pagelist may have wanted updates cancelled for no good reason. Avoid penalising fbdev drivers that don't make use of the pagelist by making the cancelling of deferred IO on close conditional on there being a non-empty pagelist. See: https://github.com/raspberrypi/linux/issues/5398 Signed-off-by: Phil Elwell <phil@raspberrypi.com> [1] 3efc61d9 ("fbdev: Fix invalid page access after closing deferred I/O devices")
-
Phil Elwell authored
There are multiple causes of interrupts, errors being one, and only the receipt of data warrants continued polling. See: https://github.com/raspberrypi/linux/issues/2676 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
-
Dom Cobley authored
-
Dom Cobley authored
This reverts commit 631ee829.
-
Dom Cobley authored
This reverts commit 1dc23c47.
-
- Feb 06, 2024
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20240203035317.354186483@linuxfoundation.org Tested-by: Pavel Machek (CIP) <pavel@denx.de> Tested-by: Salvatore Bonaccorso <carnil@debian.org> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Yann Sionneau <ysionneau@kalrayinc.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Link: https://lore.kernel.org/r/20240203174756.358721205@linuxfoundation.org Tested-by: SeongJae Park <sj@kernel.org> Tested-by: Pavel Machek (CIP) <pavel@denx.de> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Yann Sionneau <ysionneau@kalrayinc.com> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Mateusz Jończyk <mat.jonczyk@o2.pl> Tested-by: Ron Economos <re@w6rz.net> Tested-by: kernelci.org bot <bot@kernelci.org> Tested-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Srinivasan Shanmugam authored
[ Upstream commit 16da3990 ] Return 0 for success scenairos in 'gmc_v6/7/8/9_0_hw_init()' Fixes the below: drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c:920 gmc_v6_0_hw_init() warn: missing error code? 'r' drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c:1104 gmc_v7_0_hw_init() warn: missing error code? 'r' drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c:1224 gmc_v8_0_hw_init() warn: missing error code? 'r' drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c:2347 gmc_v9_0_hw_init() warn: missing error code? 'r' Fixes: fac4ebd7 ("drm/amdgpu: Fix with right return code '-EIO' in 'amdgpu_gmc_vram_checking()'") Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Johan Hovold authored
commit b53cc614 upstream. The PA gain can be set in steps of 1.5 dB from -3 dB to 18 dB, that is, in 15 levels. Fix the dB values for the PA volume control as experiments using wsa8835 show that the first 16 levels all map to the same lowest gain while the last three map to the highest gain. These values specifically need to be correct for the sound server to provide proper volume control. Note that level 0 (-3 dB) does not mute the PA so the mute flag should also not be set. Fixes: cdb09e62 ("ASoC: codecs: wsa883x: add control, dapm widgets and map") Cc: stable@vger.kernel.org # 6.0 Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Link: https://msgid.link/r/20240119112420.7446-2-johan+linaro@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Johan Hovold authored
commit 46188db0 upstream. The LPASS WSA macro codec driver is updating the digital gain settings behind the back of user space on DAPM events if companding has been enabled. As compander control is exported to user space, this can result in the digital gain setting being incremented (or decremented) every time the sound server is started and the codec suspended depending on what the UCM configuration looks like. Soon enough playback will become distorted (or too quiet). This is specifically a problem on the Lenovo ThinkPad X13s as this bypasses the limit for the digital gain setting that has been set by the machine driver. Fix this by simply dropping the compander gain offset hack. If someone cares about modelling the impact of the compander setting this can possibly be done by exporting it as a volume control later. Note that the volume registers still need to be written after enabling clocks in order for any prior updates to take effect. Fixes: 2c4066e5 ("ASoC: codecs: lpass-wsa-macro: add dapm widgets and route") Cc: stable@vger.kernel.org # 5.11 Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Link: https://msgid.link/r/20240119112420.7446-4-johan+linaro@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Zhengchao Shao authored
commit 486058f4 upstream. As suggested by Paolo in link[1], if the memory allocation fails, the mm layer will emit a lot warning comprising the backtrace, so remove the print. [1] https://lore.kernel.org/all/20231118081653.1481260-1-shaozhengchao@huawei.com/ Suggested-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com> Reviewed-by: Hangbin Liu <liuhangbin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Praveen Kaligineedi authored
From: Bailey Forrest <bcf@google.com> Call skb_shinfo() after gve_prep_tso() on DQO TX path. gve_prep_tso() calls skb_cow_head(), which may reallocate shinfo causing a use after free. This bug was unintentionally fixed by 'a6fb8d5a ("gve: Tx path for DQO-QPL")' while adding DQO-QPL format support in 6.6. That patch is not appropriate for stable releases. Fixes: a57e5de4 ("gve: DQO: Add TX path") Signed-off-by: Praveen Kaligineedi <pkaligineedi@google.com> Signed-off-by: Bailey Forrest <bcf@google.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Jeroen de Borst <jeroendb@google.com> Reviewed-by: Kevin DeCabooter <decabooter@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Huacai Chen authored
commit 5056c596 upstream. Machines which have more than 8 nodes fail to boot SMP after commit a2ccf463 ("LoongArch/smp: Call rcutree_report_cpu_starting() earlier"). Because such machines use tlb-based per-cpu base address rather than dmw-based per-cpu base address, resulting per-cpu variables can only be accessed after tlb_init(). But rcutree_report_cpu_starting() is now called before tlb_init() and accesses per-cpu variables indeed. Since the original patch want to avoid the lockdep warning caused by page allocation in tlb_init(), we can move rcutree_report_cpu_starting() to tlb_init() where after tlb exception configuration but before page allocation. Fixes: a2ccf463 ("LoongArch/smp: Call rcutree_report_cpu_starting() earlier") Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Konrad Dybcio authored
commit 6ab502bc upstream. Some devices power the DSI PHY/PLL through a power rail that we model as a GENPD. Enable runtime PM to make it suspendable. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/543352/ Link: https://lore.kernel.org/r/20230620-topic-dsiphy_rpm-v2-2-a11a751f34f0@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Amit Pundir <amit.pundir@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jonathan Gray authored
This reverts commit 85d16c03. duplicated a change made in 6.1.69 20907717 Cc: stable@vger.kernel.org # 6.1 Signed-off-by: Jonathan Gray <jsg@jsg.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Marco Elver authored
commit f6564fce upstream. Alexander Potapenko writes in [1]: "For every memory access in the code instrumented by KMSAN we call kmsan_get_metadata() to obtain the metadata for the memory being accessed. For virtual memory the metadata pointers are stored in the corresponding `struct page`, therefore we need to call virt_to_page() to get them. According to the comment in arch/x86/include/asm/page.h, virt_to_page(kaddr) returns a valid pointer iff virt_addr_valid(kaddr) is true, so KMSAN needs to call virt_addr_valid() as well. To avoid recursion, kmsan_get_metadata() must not call instrumented code, therefore ./arch/x86/include/asm/kmsan.h forks parts of arch/x86/mm/physaddr.c to check whether a virtual address is valid or not. But the introduction of rcu_read_lock() to pfn_valid() added instrumented RCU API calls to virt_to_page_or_null(), which is called by kmsan_get_metadata(), so there is an infinite recursion now. I do not think it is correct to stop that recursion by doing kmsan_enter_runtime()/kmsan_exit_runtime() in kmsan_get_metadata(): that would prevent instrumented functions called from within the runtime from tracking the shadow values, which might introduce false positives." Fix the issue by switching pfn_valid() to the _sched() variant of rcu_read_lock/unlock(), which does not require calling into RCU. Given the critical section in pfn_valid() is very small, this is a reasonable trade-off (with preemptible RCU). KMSAN further needs to be careful to suppress calls into the scheduler, which would be another source of recursion. This can be done by wrapping the call to pfn_valid() into preempt_disable/enable_no_resched(). The downside is that this sacrifices breaking scheduling guarantees; however, a kernel compiled with KMSAN has already given up any performance guarantees due to being heavily instrumented. Note, KMSAN code already disables tracing via Makefile, and since mmzone.h is included, it is not necessary to use the notrace variant, which is generally preferred in all other cases. Link: https://lkml.kernel.org/r/20240115184430.2710652-1-glider@google.com [1] Link: https://lkml.kernel.org/r/20240118110022.2538350-1-elver@google.com Fixes: 5ec8e8ea ("mm/sparsemem: fix race in accessing memory_section->usage") Signed-off-by: Marco Elver <elver@google.com> Reported-by: Alexander Potapenko <glider@google.com> Reported-by: <syzbot+93a9e8a3dea8d6085e12@syzkaller.appspotmail.com> Reviewed-by: Alexander Potapenko <glider@google.com> Tested-by: Alexander Potapenko <glider@google.com> Cc: Charan Teja Kalla <quic_charante@quicinc.com> Cc: Borislav Petkov (AMD) <bp@alien8.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Huang Shijie authored
commit 7b1a09e4 upstream. The init_irq_stacks() has been changed to use the correct node: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/commit/?id=75b5e0bf90bf The init_irq_scs() has the same issue with init_irq_stacks(): cpu_to_node() is not initialized yet, it does not work. This patch uses early_cpu_to_node() to set the init_irq_scs() with the correct node. Signed-off-by: Huang Shijie <shijie@os.amperecomputing.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20231213012046.12014-1-shijie@os.amperecomputing.com Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Benjamin Poirier authored
[ Upstream commit 8cc063ae ] The purpose of the test_LAG_cleanup() function is to check that some hardware addresses are removed from underlying devices after they have been unenslaved. The test function simply checks that those addresses are not present at the end. However, if the addresses were never added to begin with due to some error in device setup, the test function currently passes. This is a false positive since in that situation the test did not actually exercise the intended functionality. Add a check that the expected addresses are indeed present after device setup. This makes the test function more robust. I noticed this problem when running the team/dev_addr_lists.sh test on a system without support for dummy and ipv6: tools/testing/selftests/drivers/net/team# ./dev_addr_lists.sh Error: Unknown device type. Error: Unknown device type. This program is not intended to be run as root. RTNETLINK answers: Operation not supported TEST: team cleanup mode lacp [ OK ] Fixes: bbb774d9 ("net: Add tests for bonding and team address list management") Signed-off-by: Benjamin Poirier <bpoirier@nvidia.com> Link: https://lore.kernel.org/r/20240131140848.360618-3-bpoirier@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
-
Benjamin Poirier authored
[ Upstream commit 7b6fb305 ] Similar to commit dd2d40ac ("selftests: bonding: Add more missing config options"), add more networking-specific config options which are needed for team device tests. For testing, I used the minimal config generated by virtme-ng and I added the options in the config file. Afterwards, the team device test passed. Fixes: bbb774d9 ("net: Add tests for bonding and team address list management") Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Benjamin Poirier <bpoirier@nvidia.com> Link: https://lore.kernel.org/r/20240131140848.360618-2-bpoirier@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
-