summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-11-25memory: mtk-smi: Fix a null dereference for the ostdYong Wu
We add the ostd setting for mt8195. It introduces a KE for the previous SoC which doesn't have ostd setting. This is the log: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000080 ... pc : mtk_smi_larb_config_port_gen2_general+0x64/0x130 lr : mtk_smi_larb_resume+0x54/0x98 ... Call trace: mtk_smi_larb_config_port_gen2_general+0x64/0x130 pm_generic_runtime_resume+0x2c/0x48 __genpd_runtime_resume+0x30/0xa8 genpd_runtime_resume+0x94/0x2c8 __rpm_callback+0x44/0x150 rpm_callback+0x6c/0x78 rpm_resume+0x310/0x558 __pm_runtime_resume+0x3c/0x88 In the code: larbostd = larb->larb_gen->ostd[larb->larbid], if "larb->larb_gen->ostd" is null, the "larbostd" is the offset(e.g. 0x80 above), it's also a valid value, then accessing "larbostd[i]" in the "for" loop will cause the KE above. To avoid this issue, initialize "larbostd" to NULL when the SoC doesn't have ostd setting. Fixes: fe6dd2a4017d ("memory: mtk-smi: mt8195: Add initial setting for smi-larb") Signed-off-by: Yong Wu <yong.wu@mediatek.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Link: https://lore.kernel.org/r/20211108082429.15080-1-yong.wu@mediatek.com Link: https://lore.kernel.org/r/20211124085042.9649-3-krzysztof.kozlowski@canonical.com' Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-11-25arm64: dts: exynos: drop samsung,ufs-shareability-reg-offset in ExynosAutov9Chanho Park
samsung,ufs-shareability-reg-offset is not necessary anymore since it was integrated into the second argument of samsung,sysreg. Fixes: 31bbac5263aa ("arm64: dts: exynos: add initial support for exynosautov9 SoC") Signed-off-by: Chanho Park <chanho61.park@samsung.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Link: https://lore.kernel.org/r/20211102064826.15796-1-chanho61.park@samsung.com Link: https://lore.kernel.org/r/20211124085042.9649-2-krzysztof.kozlowski@canonical.com' Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-11-25MAINTAINERS: Update maintainer entry for keystone platformsNishanth Menon
Switch the kernel tree for keystone to the consolidated ti tree and add myself as primary maintainer for keystone platforms to offset Santosh's workload. Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Santosh Shilimkar <ssantosh@kernel.org> Link: https://lore.kernel.org/r/20211123001725.21422-1-nm@ti.com' Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-11-25Merge tag 'asoc-fix-v5.16-rc3' of ↵Takashi Iwai
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v5.16 There's a large but repetitive set of fixes here for issues with the Tegra kcontrols not correctly reporting changes to userspace, a fix for some issues with matching on older x86 platforms introduced during the merge window together with a set of smaller fixes and one new system quirk.
2021-11-25drm/i915: Remove dma_resv_pruneMaarten Lankhorst
The signaled bit is already used for quick testing if a fence is signaled. On top of that, it's a terrible abuse of dma-fence api, and in the common case where the object is already locked by the caller, the trylock will fail. If it were useful, the core dma-api would have exposed the same functionality. The fact that i915 has a dma_resv_utils.c file should be a warning that the functionality either belongs in core, or is not very useful at all. In this case the latter. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> [mlankhorst: Improve commit message] Acked-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211021103605.735002-3-maarten.lankhorst@linux.intel.com Reviewed-by: Matthew Auld <matthew.auld@intel.com> #irc
2021-11-25futex: Wireup futex_waitv syscallAndré Almeida
Wireup futex_waitv syscall for all remaining archs. Signed-off-by: André Almeida <andrealmeid@collabora.com> Acked-by: Max Filippov <jcmvbkbc@gmail.com> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Tested-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc) Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-11-25fuse: release pipe buf after last useMiklos Szeredi
Checking buf->flags should be done before the pipe_buf_release() is called on the pipe buffer, since releasing the buffer might modify the flags. This is exactly what page_cache_pipe_buf_release() does, and which results in the same VM_BUG_ON_PAGE(PageLRU(page)) that the original patch was trying to fix. Reported-by: Justin Forbes <jmforbes@linuxtx.org> Fixes: 712a951025c0 ("fuse: fix page stealing") Cc: <stable@vger.kernel.org> # v2.6.35 Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
2021-11-25Merge drm/drm-next into drm-intel-gt-nextTvrtko Ursulin
Maarten requested a backmerge due his work depending on subtle semantic changes introduced by: 7e2e69ed4678 ("drm/i915: Fix i915_request fence wait semantics") 2cbb8d4d6770 ("drm/i915: use new iterator in i915_gem_object_wait_reservation") Both should probably have been merged to drm-intel-gt-next anyway. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2021-11-25s390/test_unwind: use raw opcode instead of invalid instructionIlie Halip
Building with clang & LLVM_IAS=1 leads to an error: arch/s390/lib/test_unwind.c:179:4: error: invalid register pair " mvcl %%r1,%%r1\n" ^ The test creates an invalid instruction that would trap at runtime, but the LLVM inline assembler tries to validate it at compile time too. Use the raw instruction opcode instead. Reported-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Ilie Halip <ilie.halip@gmail.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Suggested-by: Ulrich Weigand <Ulrich.Weigand@de.ibm.com> Link: https://github.com/ClangBuiltLinux/linux/issues/1421 Link: https://lore.kernel.org/r/20211117174822.3632412-1-ilie.halip@gmail.com Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> [hca@linux.ibm.com: use illegal opcode, and update comment] Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-11-25Merge tag 'usb-serial-5.16-rc3' of ↵Greg Kroah-Hartman
https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus Johan writes: USB-serial fixes for 5.16-rc3 Here's a fix for a pl2303 type-detection issue and some new modem devices ids. All but the last commit have been in linux-next, and with no reported issues. * tag 'usb-serial-5.16-rc3' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial: USB: serial: option: add Fibocom FM101-GL variants USB: serial: pl2303: fix GC type detection USB: serial: option: add Telit LE910S1 0x9200 composition
2021-11-25ASoC: dt-bindings: wlf,wm8962: add missing interrupt propertyDavid Heidelberg
Both, hardware and drivers does support interrupts. Fix warnings as: arch/arm/boot/dts/tegra30-microsoft-surface-rt-efi.dt.yaml: audio-codec@1a: 'interrupt-parent', 'interrupts' do not match any of the regexes: 'pinctrl-[0-9]+' From schema: /home/runner/work/linux/linux/Documentation/devicetree/bindings/sound/wlf,wm8962.yaml Fixes: cd51b942f344 ("ASoC: dt-bindings: wlf,wm8962: Convert to json-schema") Signed-off-by: David Heidelberg <david@ixit.cz> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20211124155101.59694-1-david@ixit.cz Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-25drm/bridge: megachips: Ensure both bridges are probed before registrationMartyn Welch
In the configuration used by the b850v3, the STDP2690 is used to read EDID data whilst it's the STDP4028 which can detect when monitors are connected. This can result in problems at boot with monitors connected when the STDP4028 is probed first, a monitor is detected and an attempt is made to read the EDID data before the STDP2690 has probed: [ 3.795721] Unable to handle kernel NULL pointer dereference at virtual address 00000018 [ 3.803845] pgd = (ptrval) [ 3.806581] [00000018] *pgd=00000000 [ 3.810180] Internal error: Oops: 5 [#1] SMP ARM [ 3.814813] Modules linked in: [ 3.817879] CPU: 0 PID: 64 Comm: kworker/u4:1 Not tainted 5.15.0 #1 [ 3.824161] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) [ 3.830705] Workqueue: events_unbound deferred_probe_work_func [ 3.836565] PC is at stdp2690_get_edid+0x44/0x19c [ 3.841286] LR is at ge_b850v3_lvds_get_modes+0x2c/0x5c [ 3.846526] pc : [<805eae10>] lr : [<805eb138>] psr: 80000013 [ 3.852802] sp : 81c359d0 ip : 7dbb550b fp : 81c35a1c [ 3.858037] r10: 81c73840 r9 : 81c73894 r8 : 816d9800 [ 3.863270] r7 : 00000000 r6 : 81c34000 r5 : 00000000 r4 : 810c35f0 [ 3.869808] r3 : 80e3e294 r2 : 00000080 r1 : 00000cc0 r0 : 81401180 [ 3.876349] Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 3.883499] Control: 10c5387d Table: 1000404a DAC: 00000051 [ 3.889254] Register r0 information: slab kmem_cache start 81401180 pointer offset 0 [ 3.897034] Register r1 information: non-paged memory [ 3.902097] Register r2 information: non-paged memory [ 3.907160] Register r3 information: non-slab/vmalloc memory [ 3.912832] Register r4 information: non-slab/vmalloc memory [ 3.918503] Register r5 information: NULL pointer [ 3.923217] Register r6 information: non-slab/vmalloc memory [ 3.928887] Register r7 information: NULL pointer [ 3.933601] Register r8 information: slab kmalloc-1k start 816d9800 pointer offset 0 size 1024 [ 3.942244] Register r9 information: slab kmalloc-2k start 81c73800 pointer offset 148 size 2048 [ 3.951058] Register r10 information: slab kmalloc-2k start 81c73800 pointer offset 64 size 2048 [ 3.959873] Register r11 information: non-slab/vmalloc memory [ 3.965632] Register r12 information: non-paged memory [ 3.970781] Process kworker/u4:1 (pid: 64, stack limit = 0x(ptrval)) [ 3.977148] Stack: (0x81c359d0 to 0x81c36000) [ 3.981517] 59c0: 80b2b668 80b2b5bc 000002e2 0000034e [ 3.989712] 59e0: 81c35a8c 816d98e8 81c35a14 7dbb550b 805bfcd0 810c35f0 81c73840 824addc0 [ 3.997906] 5a00: 00001000 816d9800 81c73894 81c73840 81c35a34 81c35a20 805eb138 805eadd8 [ 4.006099] 5a20: 810c35f0 00000045 81c35adc 81c35a38 80594188 805eb118 80d7c788 80dd1848 [ 4.014292] 5a40: 00000000 81c35a50 80dca950 811194d3 80dca7c4 80dca944 80dca91c 816d9800 [ 4.022485] 5a60: 81c34000 81c760a8 816d9800 80c58c98 810c35f0 816d98e8 00001000 00001000 [ 4.030678] 5a80: 00000000 00000000 8017712c 81c60000 00000002 00000001 00000000 00000000 [ 4.038870] 5aa0: 816d9900 816d9900 00000000 7dbb550b 805c700c 00000008 826282c8 826282c8 [ 4.047062] 5ac0: 00001000 81e1ce40 00001000 00000002 81c35bf4 81c35ae0 805d9694 80593fc0 [ 4.055255] 5ae0: 8017a970 80179ad8 00000179 00000000 81c35bcc 81c35b00 80177108 8017a950 [ 4.063447] 5b00: 00000000 81c35b10 81c34000 00000000 81004fd8 81010a38 00000000 00000059 [ 4.071639] 5b20: 816d98d4 81fbb718 00000013 826282c8 8017a940 81c35b40 81134448 00000400 [ 4.079831] 5b40: 00000178 00000000 e063b9c1 00000000 c2000049 00000040 00000000 00000008 [ 4.088024] 5b60: 82628300 82628380 00000000 00000000 81c34000 00000000 81fbb700 82628340 [ 4.096216] 5b80: 826283c0 00001000 00000000 00000010 816d9800 826282c0 801766f8 00000000 [ 4.104408] 5ba0: 00000000 81004fd8 00000049 00000000 00000000 00000001 80dcf940 80178de4 [ 4.112601] 5bc0: 81c35c0c 7dbb550b 80178de4 81fbb700 00000010 00000010 810c35f4 81e1ce40 [ 4.120793] 5be0: 81c40908 0000000c 81c35c64 81c35bf8 805a7f18 805d94a0 81c35c3c 816d9800 [ 4.128985] 5c00: 00000010 81c34000 81c35c2c 81c35c18 8012fce0 805be90c 81c35c3c 81c35c28 [ 4.137178] 5c20: 805be90c 80173210 81fbb600 81fbb6b4 81c35c5c 7dbb550b 81c35c64 81fbb700 [ 4.145370] 5c40: 816d9800 00000010 810c35f4 81e1ce40 81c40908 0000000c 81c35c84 81c35c68 [ 4.153565] 5c60: 805a8c78 805a7ed0 816d9800 81fbb700 00000010 00000000 81c35cac 81c35c88 [ 4.161758] 5c80: 805a8dc4 805a8b68 816d9800 00000000 816d9800 00000000 8179f810 810c42d0 [ 4.169950] 5ca0: 81c35ccc 81c35cb0 805e47b0 805a8d18 824aa240 81e1ea80 81c40908 81126b60 [ 4.178144] 5cc0: 81c35d14 81c35cd0 8060db1c 805e46cc 81c35d14 81c35ce0 80dd90f8 810c4d58 [ 4.186338] 5ce0: 80dd90dc 81fe9740 fffffffe 81fe9740 81e1ea80 00000000 810c4d6c 80c4b95c [ 4.194531] 5d00: 80dd9a3c 815c6810 81c35d34 81c35d18 8060dc9c 8060d8fc 8246b440 815c6800 [ 4.202724] 5d20: 815c6810 eefd8e00 81c35d44 81c35d38 8060dd80 8060dbec 81c35d6c 81c35d48 [ 4.210918] 5d40: 805e98a4 8060dd70 00000000 815c6810 810c45b0 81126e90 81126e90 80dd9a3c [ 4.219112] 5d60: 81c35d8c 81c35d70 80619574 805e9808 815c6810 00000000 810c45b0 81126e90 [ 4.227305] 5d80: 81c35db4 81c35d90 806168dc 80619514 80625df0 80623c80 815c6810 810c45b0 [ 4.235498] 5da0: 81c35e6c 815c6810 81c35dec 81c35db8 80616d04 80616800 81c35de4 81c35dc8 [ 4.243691] 5dc0: 808382b0 80b2f444 8116e310 8116e314 81c35e6c 815c6810 00000003 80dd9a3c [ 4.251884] 5de0: 81c35e14 81c35df0 80616ec8 80616c60 00000001 810c45b0 81c35e6c 815c6810 [ 4.260076] 5e00: 00000001 80dd9a3c 81c35e34 81c35e18 80617338 80616e90 00000000 81c35e6c [ 4.268269] 5e20: 80617284 81c34000 81c35e64 81c35e38 80614730 80617290 81c35e64 8171a06c [ 4.276461] 5e40: 81e220b8 7dbb550b 815c6810 81c34000 815c6854 81126e90 81c35e9c 81c35e68 [ 4.284654] 5e60: 8061673c 806146a8 8060f5e0 815c6810 00000001 7dbb550b 00000000 810c5080 [ 4.292847] 5e80: 810c5320 815c6810 81126e90 00000000 81c35eac 81c35ea0 80617554 80616650 [ 4.301040] 5ea0: 81c35ecc 81c35eb0 80615694 80617544 810c5080 810c5080 810c5094 81126e90 [ 4.309233] 5ec0: 81c35efc 81c35ed0 80615c6c 8061560c 80615bc0 810c50c0 817eeb00 81412800 [ 4.317425] 5ee0: 814c3000 00000000 814c300d 81119a60 81c35f3c 81c35f00 80141488 80615bcc [ 4.325618] 5f00: 81c60000 81c34000 81c35f24 81c35f18 80143078 817eeb00 81412800 817eeb18 [ 4.333811] 5f20: 81412818 81003d00 00000088 81412800 81c35f74 81c35f40 80141a48 80141298 [ 4.342005] 5f40: 81c35f74 81c34000 801481ac 817efa40 817efc00 801417d8 817eeb00 00000000 [ 4.350199] 5f60: 815a7e7c 81c34000 81c35fac 81c35f78 80149b1c 801417e4 817efc20 817efc20 [ 4.358391] 5f80: ffffe000 817efa40 801499a8 00000000 00000000 00000000 00000000 00000000 [ 4.366583] 5fa0: 00000000 81c35fb0 80100130 801499b4 00000000 00000000 00000000 00000000 [ 4.374774] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 4.382966] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 [ 4.391155] Backtrace: [ 4.393613] [<805eadcc>] (stdp2690_get_edid) from [<805eb138>] (ge_b850v3_lvds_get_modes+0x2c/0x5c) [ 4.402691] r10:81c73840 r9:81c73894 r8:816d9800 r7:00001000 r6:824addc0 r5:81c73840 [ 4.410534] r4:810c35f0 [ 4.413073] [<805eb10c>] (ge_b850v3_lvds_get_modes) from [<80594188>] (drm_helper_probe_single_connector_modes+0x1d4/0x84c) [ 4.424240] r5:00000045 r4:810c35f0 [ 4.427822] [<80593fb4>] (drm_helper_probe_single_connector_modes) from [<805d9694>] (drm_client_modeset_probe+0x200/0x1384) [ 4.439074] r10:00000002 r9:00001000 r8:81e1ce40 r7:00001000 r6:826282c8 r5:826282c8 [ 4.446917] r4:00000008 [ 4.449455] [<805d9494>] (drm_client_modeset_probe) from [<805a7f18>] (__drm_fb_helper_initial_config_and_unlock+0x54/0x5b4) [ 4.460713] r10:0000000c r9:81c40908 r8:81e1ce40 r7:810c35f4 r6:00000010 r5:00000010 [ 4.468556] r4:81fbb700 [ 4.471095] [<805a7ec4>] (__drm_fb_helper_initial_config_and_unlock) from [<805a8c78>] (drm_fbdev_client_hotplug+0x11c/0x1b0) [ 4.482434] r10:0000000c r9:81c40908 r8:81e1ce40 r7:810c35f4 r6:00000010 r5:816d9800 [ 4.490276] r4:81fbb700 [ 4.492814] [<805a8b5c>] (drm_fbdev_client_hotplug) from [<805a8dc4>] (drm_fbdev_generic_setup+0xb8/0x1a4) [ 4.502494] r7:00000000 r6:00000010 r5:81fbb700 r4:816d9800 [ 4.508160] [<805a8d0c>] (drm_fbdev_generic_setup) from [<805e47b0>] (imx_drm_bind+0xf0/0x130) [ 4.516805] r7:810c42d0 r6:8179f810 r5:00000000 r4:816d9800 [ 4.522474] [<805e46c0>] (imx_drm_bind) from [<8060db1c>] (try_to_bring_up_master+0x22c/0x2f0) [ 4.531116] r7:81126b60 r6:81c40908 r5:81e1ea80 r4:824aa240 [ 4.536783] [<8060d8f0>] (try_to_bring_up_master) from [<8060dc9c>] (__component_add+0xbc/0x184) [ 4.545597] r10:815c6810 r9:80dd9a3c r8:80c4b95c r7:810c4d6c r6:00000000 r5:81e1ea80 [ 4.553440] r4:81fe9740 [ 4.555980] [<8060dbe0>] (__component_add) from [<8060dd80>] (component_add+0x1c/0x20) [ 4.563921] r7:eefd8e00 r6:815c6810 r5:815c6800 r4:8246b440 [ 4.569589] [<8060dd64>] (component_add) from [<805e98a4>] (dw_hdmi_imx_probe+0xa8/0xe8) [ 4.577702] [<805e97fc>] (dw_hdmi_imx_probe) from [<80619574>] (platform_probe+0x6c/0xc8) [ 4.585908] r9:80dd9a3c r8:81126e90 r7:81126e90 r6:810c45b0 r5:815c6810 r4:00000000 [ 4.593662] [<80619508>] (platform_probe) from [<806168dc>] (really_probe+0xe8/0x460) [ 4.601524] r7:81126e90 r6:810c45b0 r5:00000000 r4:815c6810 [ 4.607191] [<806167f4>] (really_probe) from [<80616d04>] (__driver_probe_device+0xb0/0x230) [ 4.615658] r7:815c6810 r6:81c35e6c r5:810c45b0 r4:815c6810 [ 4.621326] [<80616c54>] (__driver_probe_device) from [<80616ec8>] (driver_probe_device+0x44/0xe0) [ 4.630313] r9:80dd9a3c r8:00000003 r7:815c6810 r6:81c35e6c r5:8116e314 r4:8116e310 [ 4.638068] [<80616e84>] (driver_probe_device) from [<80617338>] (__device_attach_driver+0xb4/0x12c) [ 4.647227] r9:80dd9a3c r8:00000001 r7:815c6810 r6:81c35e6c r5:810c45b0 r4:00000001 [ 4.654981] [<80617284>] (__device_attach_driver) from [<80614730>] (bus_for_each_drv+0x94/0xd8) [ 4.663794] r7:81c34000 r6:80617284 r5:81c35e6c r4:00000000 [ 4.669461] [<8061469c>] (bus_for_each_drv) from [<8061673c>] (__device_attach+0xf8/0x190) [ 4.677753] r7:81126e90 r6:815c6854 r5:81c34000 r4:815c6810 [ 4.683419] [<80616644>] (__device_attach) from [<80617554>] (device_initial_probe+0x1c/0x20) [ 4.691971] r8:00000000 r7:81126e90 r6:815c6810 r5:810c5320 r4:810c5080 [ 4.698681] [<80617538>] (device_initial_probe) from [<80615694>] (bus_probe_device+0x94/0x9c) [ 4.707318] [<80615600>] (bus_probe_device) from [<80615c6c>] (deferred_probe_work_func+0xac/0xf0) [ 4.716305] r7:81126e90 r6:810c5094 r5:810c5080 r4:810c5080 [ 4.721973] [<80615bc0>] (deferred_probe_work_func) from [<80141488>] (process_one_work+0x1fc/0x54c) [ 4.731139] r10:81119a60 r9:814c300d r8:00000000 r7:814c3000 r6:81412800 r5:817eeb00 [ 4.738981] r4:810c50c0 r3:80615bc0 [ 4.742563] [<8014128c>] (process_one_work) from [<80141a48>] (worker_thread+0x270/0x570) [ 4.750765] r10:81412800 r9:00000088 r8:81003d00 r7:81412818 r6:817eeb18 r5:81412800 [ 4.758608] r4:817eeb00 [ 4.761147] [<801417d8>] (worker_thread) from [<80149b1c>] (kthread+0x174/0x190) [ 4.768574] r10:81c34000 r9:815a7e7c r8:00000000 r7:817eeb00 r6:801417d8 r5:817efc00 [ 4.776417] r4:817efa40 [ 4.778955] [<801499a8>] (kthread) from [<80100130>] (ret_from_fork+0x14/0x24) [ 4.786201] Exception stack(0x81c35fb0 to 0x81c35ff8) [ 4.791266] 5fa0: 00000000 00000000 00000000 00000000 [ 4.799459] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 4.807651] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 4.814279] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:801499a8 [ 4.822120] r4:817efa40 [ 4.824664] Code: e3a02080 e593001c e3a01d33 e3a05000 (e5979018) Split the registration from the STDP4028 probe routine and only perform registration once both the STDP4028 and STDP2690 have probed. Signed-off-by: Martyn Welch <martyn.welch@collabora.com> CC: Peter Senna Tschudin <peter.senna@gmail.com> CC: Martyn Welch <martyn.welch@collabora.co.uk> CC: Neil Armstrong <narmstrong@baylibre.com> CC: Robert Foss <robert.foss@linaro.org> CC: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> CC: Jonas Karlman <jonas@kwiboo.se> CC: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/43552c3404e8fdf92d8bc5658fac24e9f03c2c57.1637836606.git.martyn.welch@collabora.com
2021-11-25drm/bridge: anx7625: fix an error code in anx7625_register_audio()Dan Carpenter
This code accidentally returns IS_ERR(), which is 1, instead of propagating the negative error code. The caller doesn't check for errors so it doesn't affect run time at all. Fixes: 566fef1226c1 ("drm/bridge: anx7625: add HDMI audio function") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Tzung-Bi Shih <tzungbi@google.com> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211124145219.GD13656@kili
2021-11-25MIPS: boot/compressed/: add __ashldi3 to target for ZSTD compressionPaul Cercueil
Just like before with __bswapdi2(), for MIPS pre-boot when CONFIG_KERNEL_ZSTD=y the decompressor function will use __ashldi3(), so the object file should be added to the target object file. Fixes these build errors: mipsel-linux-ld: arch/mips/boot/compressed/decompress.o: in function `FSE_buildDTable_internal': decompress.c:(.text.FSE_buildDTable_internal+0x48): undefined reference to `__ashldi3' mipsel-linux-ld: arch/mips/boot/compressed/decompress.o: in function `FSE_decompress_wksp_body_default': decompress.c:(.text.FSE_decompress_wksp_body_default+0xa8): undefined reference to `__ashldi3' mipsel-linux-ld: arch/mips/boot/compressed/decompress.o: in function `ZSTD_getFrameHeader_advanced': decompress.c:(.text.ZSTD_getFrameHeader_advanced+0x134): undefined reference to `__ashldi3' Signed-off-by: Paul Cercueil <paul@crapouillou.net> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2021-11-25drm/i915/ttm: Update i915_gem_obj_copy_ttm() to be asynchronousThomas Hellström
Update the copy function i915_gem_obj_copy_ttm() to be asynchronous for future users and update the only current user to sync the objects as needed after this function. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211122214554.371864-7-thomas.hellstrom@linux.intel.com
2021-11-25drm/i915/ttm: Implement asynchronous TTM movesThomas Hellström
Don't wait sync while migrating, but rather make the GPU blit await the dependencies and add a moving fence to the object. This also enables asynchronous VRAM management in that on eviction, rather than waiting for the moving fence to expire before freeing VRAM, it is freed immediately and the fence is stored with the VRAM manager and handed out to newly allocated objects to await before clears and swapins, or for kernel objects before setting up gpu vmas or mapping. To collect dependencies before migrating, add a set of utilities that coalesce these to a single dma_fence. What is still missing for fully asynchronous operation is asynchronous vma unbinding, which is still to be implemented. This commit substantially reduces execution time in the gem_lmem_swapping test. v2: - Make a couple of functions static. v4: - Fix some style issues (Matthew Auld) - Audit and add more checks for ghost objects (Matthew Auld) - Add more documentation for the i915_deps utility (Mattew Auld) - Simplify the i915_deps_sync() function v6: - Re-check for fence signaled before returning -EBUSY (Matthew Auld) - Use dma_resv_iter_is_exclusive() (Matthew Auld) - Await all dma-resv fences before a migration blit (Matthew Auld) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211122214554.371864-6-thomas.hellstrom@linux.intel.com
2021-11-25drm/i915/ttm: Correctly handle waiting for gpu when shrinkingThomas Hellström
With async migration, the shrinker may end up wanting to release the pages of an object while the migration blit is still running, since the GT migration code doesn't set up VMAs and the shrinker is thus oblivious to the fact that the GPU is still using the pages. Add waiting for gpu in the shrinker_release_pages() op and an argument to that function indicating whether the shrinker expects it to not wait for gpu. In the latter case the shrinker_release_pages() op will return -EBUSY if the object is not idle. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211122214554.371864-5-thomas.hellstrom@linux.intel.com
2021-11-25drm/i915/ttm: Drop region reference countingThomas Hellström
There is an interesting refcounting loop: struct intel_memory_region has a struct ttm_resource_manager, ttm_resource_manager->move may hold a reference to i915_request, i915_request may hold a reference to intel_context, intel_context may hold a reference to drm_i915_gem_object, drm_i915_gem_object may hold a reference to intel_memory_region. Break this loop by dropping region reference counting. In addition, Have regions with a manager moving fence make sure that all region objects are released before freeing the region. v6: - Fix a code comment. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211122214554.371864-4-thomas.hellstrom@linux.intel.com
2021-11-25drm/i915/ttm: Move the i915_gem_obj_copy_ttm() functionThomas Hellström
Move the i915_gem_obj_copy_ttm() function to i915_gem_ttm_move.h. This will help keep a number of functions static when introducing async moves. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211122214554.371864-3-thomas.hellstrom@linux.intel.com
2021-11-25drm/i915: Add support for moving fence waitingMaarten Lankhorst
For now, we will only allow async migration when TTM is used, so the paths we care about are related to TTM. The mmap path is handled by having the fence in ttm_bo->moving, when pinning, the binding only becomes available after the moving fence is signaled, and pinning a cpu map will only work after the moving fence signals. This should close all holes where userspace can read a buffer before it's fully migrated. v2: - Fix a couple of SPARSE warnings v3: - Fix a NULL pointer dereference v4: - Ditch the moving fence waiting for i915_vma_pin_iomap() and replace with a verification that the vma is already bound. (Matthew Auld) - Squash with a previous patch introducing moving fence waiting and accessing interfaces (Matthew Auld) - Rename to indicated that we also add support for sync waiting. v5: - Fix check for NULL and unreferencing i915_vma_verify_bind_complete() (Matthew Auld) - Fix compilation failure if !CONFIG_DRM_I915_DEBUG_GEM - Fix include ordering. (Matthew Auld) v7: - Fix yet another compilation failure with clang if !CONFIG_DRM_I915_DEBUG_GEM Co-developed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211122214554.371864-2-thomas.hellstrom@linux.intel.com
2021-11-25ksmbd: fix memleak in get_file_stream_info()Namjae Jeon
Fix memleak in get_file_stream_info() Fixes: 34061d6b76a4 ("ksmbd: validate OutputBufferLength of QUERY_DIR, QUERY_INFO, IOCTL requests") Cc: stable@vger.kernel.org # v5.15 Reported-by: Coverity Scan <scan-admin@coverity.com> Acked-by: Hyunchul Lee <hyc.lee@gmail.com> Signed-off-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com>
2021-11-25ksmbd: contain default data stream even if xattr is emptyNamjae Jeon
If xattr is not supported like exfat or fat, ksmbd server doesn't contain default data stream in FILE_STREAM_INFORMATION response. It will cause ppt or doc file update issue if local filesystem is such as ones. This patch move goto statement to contain it. Fixes: 9f6323311c70 ("ksmbd: add default data stream name in FILE_STREAM_INFORMATION") Cc: stable@vger.kernel.org # v5.15 Acked-by: Hyunchul Lee <hyc.lee@gmail.com> Signed-off-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com>
2021-11-25ksmbd: downgrade addition info error msg to debug in smb2_get_info_sec()Namjae Jeon
While file transfer through windows client, This error flood message happen. This flood message will cause performance degradation and misunderstand server has problem. Fixes: e294f78d3478 ("ksmbd: allow PROTECTED_DACL_SECINFO and UNPROTECTED_DACL_SECINFO addition information in smb2 set info security") Cc: stable@vger.kernel.org # v5.15 Acked-by: Hyunchul Lee <hyc.lee@gmail.com> Signed-off-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com>
2021-11-25docs: filesystem: cifs: ksmbd: Fix small layout issuesSalvatore Bonaccorso
In some senteces there were missing spaces between words. Fix wording in item to show which prints are enabled and add a space beween the cat command and its argument. Cc: Sergey Senozhatsky <senozhatsky@chromium.org> Cc: Steve French <sfrench@samba.org> CC: Hyunchul Lee <hyc.lee@gmail.com> Cc: linux-cifs@vger.kernel.org Acked-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Salvatore Bonaccorso <carnil@debian.org> Signed-off-by: Steve French <stfrench@microsoft.com>
2021-11-25ksmbd: Fix an error handling path in 'smb2_sess_setup()'Christophe JAILLET
All the error handling paths of 'smb2_sess_setup()' end to 'out_err'. All but the new error handling path added by the commit given in the Fixes tag below. Fix this error handling path and branch to 'out_err' as well. Fixes: 0d994cd482ee ("ksmbd: add buffer validation in session setup") Cc: stable@vger.kernel.org # v5.15 Acked-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Steve French <stfrench@microsoft.com>
2021-11-24Merge branch 'net-smc-fixes-2021-11-24'Jakub Kicinski
Karsten Graul says: ==================== net/smc: fixes 2021-11-24 Patch 1 from DaXing fixes a possible loop in smc_listen(). Patch 2 prevents a NULL pointer dereferencing while iterating over the lower network devices. ==================== Link: https://lore.kernel.org/r/20211124123238.471429-1-kgraul@linux.ibm.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-11-24net/smc: Fix loop in smc_listenGuo DaXing
The kernel_listen function in smc_listen will fail when all the available ports are occupied. At this point smc->clcsock->sk->sk_data_ready has been changed to smc_clcsock_data_ready. When we call smc_listen again, now both smc->clcsock->sk->sk_data_ready and smc->clcsk_data_ready point to the smc_clcsock_data_ready function. The smc_clcsock_data_ready() function calls lsmc->clcsk_data_ready which now points to itself resulting in an infinite loop. This patch restores smc->clcsock->sk->sk_data_ready with the old value. Fixes: a60a2b1e0af1 ("net/smc: reduce active tcp_listen workers") Signed-off-by: Guo DaXing <guodaxing@huawei.com> Acked-by: Tony Lu <tonylu@linux.alibaba.com> Signed-off-by: Karsten Graul <kgraul@linux.ibm.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-11-24net/smc: Fix NULL pointer dereferencing in smc_vlan_by_tcpsk()Karsten Graul
Coverity reports a possible NULL dereferencing problem: in smc_vlan_by_tcpsk(): 6. returned_null: netdev_lower_get_next returns NULL (checked 29 out of 30 times). 7. var_assigned: Assigning: ndev = NULL return value from netdev_lower_get_next. 1623 ndev = (struct net_device *)netdev_lower_get_next(ndev, &lower); CID 1468509 (#1 of 1): Dereference null return value (NULL_RETURNS) 8. dereference: Dereferencing a pointer that might be NULL ndev when calling is_vlan_dev. 1624 if (is_vlan_dev(ndev)) { Remove the manual implementation and use netdev_walk_all_lower_dev() to iterate over the lower devices. While on it remove an obsolete function parameter comment. Fixes: cb9d43f67754 ("net/smc: determine vlan_id of stacked net_device") Suggested-by: Julian Wiedmann <jwi@linux.ibm.com> Signed-off-by: Karsten Graul <kgraul@linux.ibm.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-11-24Merge branch 'phylink-resolve-fixes'Jakub Kicinski
Marek Behún says: ==================== phylink resolve fixes With information from me and my nagging, Russell has produced two fixes for phylink, which add code that triggers another phylink_resolve() from phylink_resolve(), if certain conditions are met: interface is being changed or link is down and previous link was up These are needed because sometimes the PCS callbacks may provide stale values if link / speed / ... ==================== Link: https://lore.kernel.org/r/20211123154403.32051-1-kabel@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-11-24net: phylink: Force retrigger in case of latched link-fail indicatorRussell King (Oracle)
On mv88e6xxx 1G/2.5G PCS, the SerDes register 4.2001.2 has the following description: This register bit indicates when link was lost since the last read. For the current link status, read this register back-to-back. Thus to get current link state, we need to read the register twice. But doing that in the link change interrupt handler would lead to potentially ignoring link down events, which we really want to avoid. Thus this needs to be solved in phylink's resolve, by retriggering another resolve in the event when PCS reports link down and previous link was up, and by re-reading PCS state if the previous link was down. The wrong value is read when phylink requests change from sgmii to 2500base-x mode, and link won't come up. This fixes the bug. Fixes: 9525ae83959b ("phylink: add phylink infrastructure") Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-11-24net: phylink: Force link down and retrigger resolve on interface changeRussell King (Oracle)
On PHY state change the phylink_resolve() function can read stale information from the MAC and report incorrect link speed and duplex to the kernel message log. Example with a Marvell 88X3310 PHY connected to a SerDes port on Marvell 88E6393X switch: - PHY driver triggers state change due to PHY interface mode being changed from 10gbase-r to 2500base-x due to copper change in speed from 10Gbps to 2.5Gbps, but the PHY itself either hasn't yet changed its interface to the host, or the interrupt about loss of SerDes link hadn't arrived yet (there can be a delay of several milliseconds for this), so we still think that the 10gbase-r mode is up - phylink_resolve() - phylink_mac_pcs_get_state() - this fills in speed=10g link=up - interface mode is updated to 2500base-x but speed is left at 10Gbps - phylink_major_config() - interface is changed to 2500base-x - phylink_link_up() - mv88e6xxx_mac_link_up() - .port_set_speed_duplex() - speed is set to 10Gbps - reports "Link is Up - 10Gbps/Full" to dmesg Afterwards when the interrupt finally arrives for mv88e6xxx, another resolve is forced in which we get the correct speed from phylink_mac_pcs_get_state(), but since the interface is not being changed anymore, we don't call phylink_major_config() but only phylink_mac_config(), which does not set speed/duplex anymore. To fix this, we need to force the link down and trigger another resolve on PHY interface change event. Fixes: 9525ae83959b ("phylink: add phylink infrastructure") Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-11-24lan743x: fix deadlock in lan743x_phy_link_status_change()Heiner Kallweit
Usage of phy_ethtool_get_link_ksettings() in the link status change handler isn't needed, and in combination with the referenced change it results in a deadlock. Simply remove the call and replace it with direct access to phydev->speed. The duplex argument of lan743x_phy_update_flowcontrol() isn't used and can be removed. Fixes: c10a485c3de5 ("phy: phy_ethtool_ksettings_get: Lock the phy for consistency") Reported-by: Alessandro B Maurici <abmaurici@gmail.com> Tested-by: Alessandro B Maurici <abmaurici@gmail.com> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/40e27f76-0ba3-dcef-ee32-a78b9df38b0f@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-11-24tcp_cubic: fix spurious Hystart ACK train detections for not-cwnd-limited flowsEric Dumazet
While testing BIG TCP patch series, I was expecting that TCP_RR workloads with 80KB requests/answers would send one 80KB TSO packet, then being received as a single GRO packet. It turns out this was not happening, and the root cause was that cubic Hystart ACK train was triggering after a few (2 or 3) rounds of RPC. Hystart was wrongly setting CWND/SSTHRESH to 30, while my RPC needed a budget of ~20 segments. Ideally these TCP_RR flows should not exit slow start. Cubic Hystart should reset itself at each round, instead of assuming every TCP flow is a bulk one. Note that even after this patch, Hystart can still trigger, depending on scheduling artifacts, but at a higher CWND/SSTHRESH threshold, keeping optimal TSO packet sizes. Tested: ip link set dev eth0 gro_ipv6_max_size 131072 gso_ipv6_max_size 131072 nstat -n; netperf -H ... -t TCP_RR -l 5 -- -r 80000,80000 -K cubic; nstat|egrep "Ip6InReceives|Hystart|Ip6OutRequests" Before: 8605 Ip6InReceives 87541 0.0 Ip6OutRequests 129496 0.0 TcpExtTCPHystartTrainDetect 1 0.0 TcpExtTCPHystartTrainCwnd 30 0.0 After: 8760 Ip6InReceives 88514 0.0 Ip6OutRequests 87975 0.0 Fixes: ae27e98a5152 ("[TCP] CUBIC v2.3") Co-developed-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Stephen Hemminger <stephen@networkplumber.org> Cc: Yuchung Cheng <ycheng@google.com> Cc: Soheil Hassas Yeganeh <soheil@google.com> Link: https://lore.kernel.org/r/20211123202535.1843771-1-eric.dumazet@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-11-24MAINTAINERS: Update B53 section to cover SF2 switch driverFlorian Fainelli
Update the B53 Ethernet switch section to contain drivers/net/dsa/bcm_sf2*. Reported-by: Russell King (Oracle) <linux@armlinux.org.uk> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/20211123222422.3745485-1-f.fainelli@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-11-24Merge tag 'ieee802154-for-net-2021-11-24' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/sschmidt/wpan Stefan Schmidt says: ==================== pull-request: ieee802154 for net 2021-11-24 A fix from Alexander which has been brought up various times found by automated checkers. Make sure values are in u32 range. * tag 'ieee802154-for-net-2021-11-24' of git://git.kernel.org/pub/scm/linux/kernel/git/sschmidt/wpan: net: ieee802154: handle iftypes as u32 ==================== Link: https://lore.kernel.org/r/20211124150934.3670248-1-stefan@datenfreihafen.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-11-24vdpa_sim: avoid putting an uninitialized iova_domainLongpeng
The system will crash if we put an uninitialized iova_domain, this could happen when an error occurs before initializing the iova_domain in vdpasim_create(). BUG: kernel NULL pointer dereference, address: 0000000000000000 ... RIP: 0010:__cpuhp_state_remove_instance+0x96/0x1c0 ... Call Trace: <TASK> put_iova_domain+0x29/0x220 vdpasim_free+0xd1/0x120 [vdpa_sim] vdpa_release_dev+0x21/0x40 [vdpa] device_release+0x33/0x90 kobject_release+0x63/0x160 vdpasim_create+0x127/0x2a0 [vdpa_sim] vdpasim_net_dev_add+0x7d/0xfe [vdpa_sim_net] vdpa_nl_cmd_dev_add_set_doit+0xe1/0x1a0 [vdpa] genl_family_rcv_msg_doit+0x112/0x140 genl_rcv_msg+0xdf/0x1d0 ... So we must make sure the iova_domain is already initialized before put it. In addition, we may get the following warning in this case: WARNING: ... drivers/iommu/iova.c:344 iova_cache_put+0x58/0x70 So we must make sure the iova_cache_put() is invoked only if the iova_cache_get() is already invoked. Let's fix it together. Cc: stable@vger.kernel.org Fixes: 4080fc106750 ("vdpa_sim: use iova module to allocate IOVA addresses") Signed-off-by: Longpeng <longpeng2@huawei.com> Acked-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Link: https://lore.kernel.org/r/20211124015215.119-1-longpeng2@huawei.com Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-11-24vhost-vdpa: clean irqs before reseting vdpa deviceWu Zongyong
Vdpa devices should be reset after unseting irqs of virtqueues, or we will get errors when killing qemu process: >> pi_update_irte: failed to update PI IRTE >> irq bypass consumer (token 0000000065102a43) unregistration fails: -22 Signed-off-by: Wu Zongyong <wuzongyong@linux.alibaba.com> Link: https://lore.kernel.org/r/a2cb60cf73be9da5c4e6399242117d8818f975ae.1636946171.git.wuzongyong@linux.alibaba.com Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com>
2021-11-24virtio-blk: modify the value type of num in virtio_queue_rq()Ye Guojin
This was found by coccicheck: ./drivers/block/virtio_blk.c, 334, 14-17, WARNING Unsigned expression compared with zero num < 0 Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Ye Guojin <ye.guojin@zte.com.cn> Link: https://lore.kernel.org/r/20211117063955.160777-1-ye.guojin@zte.com.cn Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Fixes: 02746e26c39e ("virtio-blk: avoid preallocating big SGL for data") Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Max Gurtovoy <mgurtovoy@nvidia.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
2021-11-24vhost/vsock: cleanup removing `len` variableStefano Garzarella
We can increment `total_len` directly and remove `len` since it is no longer used for vhost_add_used(). Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Link: https://lore.kernel.org/r/20211122163525.294024-3-sgarzare@redhat.com Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
2021-11-24vhost/vsock: fix incorrect used length reported to the guestStefano Garzarella
The "used length" reported by calling vhost_add_used() must be the number of bytes written by the device (using "in" buffers). In vhost_vsock_handle_tx_kick() the device only reads the guest buffers (they are all "out" buffers), without writing anything, so we must pass 0 as "used length" to comply virtio spec. Fixes: 433fc58e6bf2 ("VSOCK: Introduce vhost_vsock.ko") Cc: stable@vger.kernel.org Reported-by: Halil Pasic <pasic@linux.ibm.com> Suggested-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Link: https://lore.kernel.org/r/20211122163525.294024-2-sgarzare@redhat.com Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Halil Pasic <pasic@linux.ibm.com>
2021-11-24Revert "virtio_ring: validate used buffer length"Michael S. Tsirkin
This reverts commit 939779f5152d161b34f612af29e7dc1ac4472fcf. Attempts to validate length in the core did not work out: there turn out to exist multiple broken devices, and in particular legacy devices are known to be broken in this respect. We have ideas for handling this better in the next version but for now let's revert to a known good state to make sure drivers work for people. Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-11-24Revert "virtio-net: don't let virtio core to validate used length"Michael S. Tsirkin
This reverts commit 816625c13652cef5b2c49082d652875da6f2ad7a. Attempts to validate length in the core did not work out. We'll drop them, so revert the dependent changes in drivers. Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-11-24Revert "virtio-blk: don't let virtio core to validate used length"Michael S. Tsirkin
This reverts commit a40392edf1b2c7822bc0ce68413106661a9d4232. Attempts to validate length in the core did not work out. We'll drop them, so revert the dependent changes in drivers. Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-11-24Revert "virtio-scsi: don't let virtio core to validate used buffer length"Michael S. Tsirkin
This reverts commit c57911ebfbfe745cb95da2bcf547c5bae000590f. Attempts to validate length in the core did not work out. We'll drop them for now, so revert the dependent changes in drivers. Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-11-24drm/amd/display: update bios scratch when setting backlightAlex Deucher
Update the bios scratch register when updating the backlight level. Some platforms apparently read this scratch register and do additional operations in their hotkey handlers. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1518 Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-11-24drm/amdgpu/pm: fix powerplay OD interfaceAlex Deucher
The overclocking interface currently appends data to a string. Revert back to using sprintf(). Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1774 Fixes: 6db0c87a0a8ee1 ("amdgpu/pm: Replace hwmgr smu usage of sprintf with sysfs_emit") Acked-by: Evan Quan <evan.quan@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2021-11-24drm/amdgpu: Skip ASPM programming on aldebaranLijo Lazar
There is no need for additional programming, keep the default settings. Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-11-24drm/amdgpu: fix byteorder error in amdgpu discoveryYang Wang
fix some byteorder issues about amdgpu discovery. This will result in running errors on the big end system. (e.g:MIPS) Signed-off-by: Yang Wang <KevinYang.Wang@amd.com> Reviewed-by: Guchun Chen <guchun.chen@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-11-24drm/amdgpu: enable Navi retry fault wptr overflowPhilip Yang
If xnack is on, VM retry fault interrupt send to IH ring1, and ring1 will be full quickly. IH cannot receive other interrupts, this causes deadlock if migrating buffer using sdma and waiting for sdma done while handling retry fault. Remove VMC from IH storm client, enable ring1 write pointer overflow, then IH will drop retry fault interrupts and be able to receive other interrupts while driver is handling retry fault. IH ring1 write pointer doesn't writeback to memory by IH, and ring1 write pointer recorded by self-irq is not updated, so always read the latest ring1 write pointer from register. Signed-off-by: Philip Yang <Philip.Yang@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-11-24drm/amdgpu: enable Navi 48-bit IH timestamp counterPhilip Yang
By default this timestamp is 32 bit counter. It gets overflowed in around 10 minutes. Signed-off-by: Philip Yang <Philip.Yang@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
generated by cgit (git 2.34.1) at 2025-09-15 03:07:57 +0000