- 12 Oct, 2022 40 commits
-
-
Daniel Golle authored
commit ae3ed15d upstream. Setting ib1 state to MTK_FOE_STATE_UNBIND in __mtk_foe_entry_clear routine as done by commit 0e80707d ("net: ethernet: mtk_eth_soc: fix typo in __mtk_foe_entry_clear") breaks flow offloading, at least on older MTK_NETSYS_V1 SoCs, OpenWrt users have confirmed the bug on MT7622 and MT7621 systems. Felix Fietkau suggested to use MTK_FOE_STATE_INVALID instead which works well on both, MTK_NETSYS_V1 and MTK_NETSYS_V2. Tested on MT7622 (Linksys E8450) and MT7986 (BananaPi BPI-R3). Suggested-by:
Felix Fietkau <nbd@nbd.name> Fixes: 0e80707d ("net: ethernet: mtk_eth_soc: fix typo in __mtk_foe_entry_clear") Fixes: 33fc42de ("net: ethernet: mtk_eth_soc: support creating mac address based offload entries") Signed-off-by:
Daniel Golle <daniel@makrotopia.org> Link: https://lore.kernel.org/r/YzY+1Yg0FBXcnrtc@makrotopia.org Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Kumar Kartikeya Dwivedi authored
commit 8addbfc7 upstream. This has been enabled for unprivileged programs for only one kernel release, hence the expected annoyances due to this move are low. Users using ringbuf can stick to non-dynptr APIs. The actual use cases dynptr is meant to serve may not make sense in unprivileged BPF programs. Hence, gate these helpers behind CAP_BPF and limit use to privileged BPF programs. Fixes: 263ae152 ("bpf: Add bpf_dynptr_from_mem for local dynptrs") Fixes: bc34dee6 ("bpf: Dynptr support for ring buffers") Fixes: 13bbbfbe ("bpf: Add bpf_dynptr_read and bpf_dynptr_write") Fixes: 34d4ef57 ("bpf: Add dynptr data slices") Signed-off-by:
Kumar Kartikeya Dwivedi <memxor@gmail.com> Link: https://lore.kernel.org/r/20220921143550.30247-1-memxor@gmail.com Acked-by:
Andrii Nakryiko <andrii@kernel.org> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Signed-off-by:
-
Krzysztof Kozlowski authored
commit 766279a8 upstream. The use of strncpy() is considered deprecated for NUL-terminated strings[1]. Replace strncpy() with strscpy_pad(), to keep existing pad-behavior of strncpy, similarly to commit 08de420a ("rpmsg: glink: Replace strncpy() with strscpy_pad()"). This fixes W=1 warning: In function ‘qcom_glink_rx_close’, inlined from ‘qcom_glink_work’ at ../drivers/rpmsg/qcom_glink_native.c:1638:4: drivers/rpmsg/qcom_glink_native.c:1549:17: warning: ‘strncpy’ specified bound 32 equals destination size [-Wstringop-truncation] 1549 | strncpy(chinfo.name, channel->name, sizeof(chinfo.name)); [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
Stephen Boyd <sboyd@kernel.org> Signed-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220519073330.7187-1-krzysztof.kozlowski@linaro.org Signed-off-by:
Andrew Chernyakov <acherniakov@astralinux.ru> Signed-off-by:
-
Brian Norris authored
commit e9233917 upstream. This loop intends to retry a max of 10 times, with some implicit termination based on the SD_{R,}OCR_S18A bit. Unfortunately, the termination condition depends on the value reported by the SD card (*rocr), which may or may not correctly reflect what we asked it to do. Needless to say, it's not wise to rely on the card doing what we expect; we should at least terminate the loop regardless. So, check both the input and output values, so we ensure we will terminate regardless of the SD card behavior. Note that SDIO learned a similar retry loop in commit 0797e5f1 ("mmc: core: Fixup signal voltage switch"), but that used the 'ocr' result, and so the current pre-terminating condition looks like: rocr & ocr & R4_18V_PRESENT (i.e., it doesn't have the same bug.) This addresses a number of crash reports seen on ChromeOS that look like the following: ... // lots of repeated: ... <4>[13142.846061] mmc1: Skipping voltage switch <4>[13143.406087] mmc1: Skipping voltage switch <4>[13143.964724] mmc1: Skipping voltage switch <4>[13144.526089] mmc1: Skipping voltage switch <4>[13145.086088] mmc1: Skipping voltage switch <4>[13145.645941] mmc1: Skipping voltage switch <3>[13146.153969] INFO: task halt:30352 blocked for more than 122 seconds. ... Fixes: f2119df6 ("mmc: sd: add support for signal voltage switch procedure") Cc: <stable@vger.kernel.org> Signed-off-by:
Brian Norris <briannorris@chromium.org> Reviewed-by:
Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20220914014010.2076169-1-briannorris@chromium.org Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
ChanWoo Lee authored
commit e4272664 upstream. SD_ROCR_S18A is already defined and is used to check the rocr value, so let's replace with already defined values for readability. Signed-off-by:
ChanWoo Lee <cw9316.lee@samsung.com> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20220706004840.24812-1-cw9316.lee@samsung.com Signed-off-by:
-
Mario Limonciello authored
commit 0ea76c40 upstream. Asus UM325UAZ has GPIO 18 programmed as both an interrupt and a wake source, but confirmed with internal team on this design this pin is floating and shouldn't have been programmed. This causes lots of spurious IRQs on the system and horrendous battery life. Add a quirk to ignore attempts to program this pin on this system. Reported-by:
Pavel Krc <reg.krn@pkrc.net> Link: https://bugzilla.kernel.org/show_bug.cgi?id=216208 Reviewed-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Mario Limonciello <mario.limonciello@amd.com> Reviewed-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Mario Limonciello authored
commit 6b6af7bd upstream. gpiolib-acpi already had support for ignoring a pin for wakeup, but if an OEM configures a floating pin as an interrupt source then stopping it from being a wakeup won't do much good to stop the interrupt storm. Add support for a module parameter and quirk infrastructure to ignore interrupts as well. Signed-off-by:
-
Johan Hovold authored
commit 7bd7ad3c upstream. The 300 bps rate of SIO devices has been mapped to 9600 bps since 2003... Let's fix the regression. Cc: stable@vger.kernel.org Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Tadeusz Struk authored
commit a659daf6 upstream. Syzbot found an issue in usbmon module, where the user space client can corrupt the monitor's internal memory, causing the usbmon module to crash the kernel with segfault, UAF, etc. The reproducer mmaps the /dev/usbmon memory to user space, and overwrites it with arbitrary data, which causes all kinds of issues. Return an -EPERM error from mon_bin_mmap() if the flag VM_WRTIE is set. Also clear VM_MAYWRITE to make it impossible to change it to writable later. Cc: "Dmitry Vyukov" <dvyukov@google.com> Cc: stable <stable@kernel.org> Fixes: 6f23ee1f ("USB: add binary API to usbmon") Suggested-by: PaX Team <pageexec@freemail.hu> # for the VM_MAYRITE portion Link: https://syzkaller.appspot.com/bug?id=2eb1f35d6525fa4a74d75b4244971e5b1411c95a Reported-by: syzbot+23f57c5ae902429285d7@syzkaller.appspotmail.com Signed-off-by:
Tadeusz Struk <tadeusz.struk@linaro.org> Link: https://lore.kernel.org/r/20220919215957.205681-1-tadeusz.struk@linaro.org Signed-off-by:
-
Zhang Qilong authored
[ Upstream commit e2062df7 ] The pm_runtime_enable will increase power disable depth. Thus a pairing decrement is needed on the error handling path to keep it balanced according to context. Fixes: 17f88151 ("i2c: davinci: Add PM Runtime Support") Signed-off-by:
Zhang Qilong <zhangqilong3@huawei.com> Reviewed-by:
Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by:
Wolfram Sang <wsa@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Al Viro authored
[ Upstream commit 06bbaa6d ] passing kmap_local_page() result to __kernel_write() is unsafe - random ->write_iter() might (and 9p one does) get unhappy when passed ITER_KVEC with pointer that came from kmap_local_page(). Fix by providing a variant of __kernel_write() that takes an iov_iter from caller (__kernel_write() becomes a trivial wrapper) and adding dump_emit_page() that parallels dump_emit(), except that instead of __kernel_write() it uses __kernel_write_iter() with ITER_BVEC source. Fixes: 3159ed57 "fs/coredump: use kmap_local_page()" Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Kan Liang authored
[ Upstream commit 24919fde ] For some Alder Lake N machine, the below unchecked MSR access error may be triggered. [ 0.088017] rcu: Hierarchical SRCU implementation. [ 0.088017] unchecked MSR access error: WRMSR to 0x38f (tried to write 0x0001000f0000003f) at rIP: 0xffffffffb5684de8 (native_write_msr+0x8/0x30) [ 0.088017] Call Trace: [ 0.088017] <TASK> [ 0.088017] __intel_pmu_enable_all.constprop.46+0x4a/0xa0 The Alder Lake N only has e-cores. The X86_FEATURE_HYBRID_CPU flag is not set. The perf cannot retrieve the correct CPU type via get_this_hybrid_cpu_type(). The model specific get_hybrid_cpu_type() is hardcode to p-core. The wrong CPU type is given to the PMU of the Alder Lake N. Since Alder Lake N isn't in fact a hybrid CPU, remove ALDERLAKE_N from the rest of {ALDER,RAPTOP}LAKE and create a non-hybrid PMU setup. The differences between Gracemont and the previous Tremont are, - Number of GP counters - Load and store latency Events - PEBS event_constraints - Instruction Latency support - Data source encoding - Memory access latency encoding Fixes: c2a960f7 ("perf/x86: Add new Alder Lake and Raptor Lake support") Reported-by:
Jianfeng Gao <jianfeng.gao@intel.com> Suggested-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by:
Kan Liang <kan.liang@linux.intel.com> Signed-off-by:
-
Dmytro Laktyushkin authored
[ Upstream commit dcc2527d ] [Why & How] Update after new measurment came in Reviewed-by:
Jun Lei <Jun.Lei@amd.com> Acked-by:
Wayne Lin <wayne.lin@amd.com> Signed-off-by:
Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Tested-by:
Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Cruise Hung authored
[ Upstream commit 20c6168b ] [Why] When USB4 DP link training failed and fell back to lower link rate, the time slot calculation uses the verified_link_cap. And the verified_link_cap was not updated to the new one. It caused the wrong VC payload time-slot was allocated. [How] Updated verified_link_cap with the new one from cur_link_settings after the LT completes successfully. Reviewed-by:
Cruise Hung <Cruise.Hung@amd.com> Tested-by:
-
zhikzhai authored
[ Upstream commit 65fbfb02 ] [why] We have minimal pipe split transition method to avoid pipe allocation outage.However, this method will invoke audio setup which cause audio output stuck once pipe reallocate. [how] skip audio setup for pipelines which audio stream has been enabled Reviewed-by:
Charlene Liu <Charlene.Liu@amd.com> Acked-by:
zhikzhai <zhikai.zhai@amd.com> Tested-by:
-
Hugo Hu authored
[ Upstream commit 52bb2149 ] [Why] The desktop plane and full-screen game plane may have different gamut remap coefficients, if switching between desktop and full-screen game without updating the gamut remap will cause incorrect color. [How] Update gamut remap if planes change. Reviewed-by:
Hugo Hu <hugo.hu@amd.com> Tested-by:
-
Michael Strauss authored
[ Upstream commit 29956d0f ] [WHY] LTTPRs can in very rare instsances fail to increment DPCD LTTPR count. This results in aux-i LTTPR requests to be sent to the wrong DPCD address, which causes link training failure. [HOW] Override internal repeater count if fixed_vs flag is set for a given link Reviewed-by:
George Shen <George.Shen@amd.com> Acked-by:
Michael Strauss <michael.strauss@amd.com> Tested-by:
-
Leo Li authored
[ Upstream commit b2615099 ] [Why] DC makes use of layer_index (zpos) when picking the HW plane to enable HW cursor on. However, some compositors will not attach zpos information to each DRM plane. Consequently, in amdgpu, we default layer_index to 0 and do not update it. This causes said DC logic to enable HW cursor on all planes of the same layer_index, which manifests as a double cursor issue if one of the planes is scaled (and hence scaling the cursor as well). [How] Use DRM core helpers to calculate a normalized_zpos value for each drm_plane_state under each crtc, within the atomic state. This helper will first consider existing zpos values, and if identical/unset, fallback to plane ID ordering. The normalized_zpos is then passed to dc_plane_info during atomic check for later use by the cursor logic. Reviewed-by:
Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Acked-by:
Leo Li <sunpeng.li@amd.com> Tested-by:
-
Janis Schoetterl-Glausch authored
[ Upstream commit b3cefd6b ] This silences smatch warnings reported by kbuild bot: arch/s390/kvm/gaccess.c:859 guest_range_to_gpas() error: uninitialized symbol 'prot'. arch/s390/kvm/gaccess.c:1064 access_guest_with_key() error: uninitialized symbol 'prot'. This is because it cannot tell that the value is not used in this case. The trans_exc* only examine prot if code is PGM_PROTECTION. Pass a dummy value for other codes. Reported-by:
kernel test robot <lkp@intel.com> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Janis Schoetterl-Glausch <scgl@linux.ibm.com> Reviewed-by:
Claudio Imbrenda <imbrenda@linux.ibm.com> Link: https://lore.kernel.org/r/20220825192540.1560559-1-scgl@linux.ibm.com Signed-off-by:
Christian Borntraeger <borntraeger@linux.ibm.com> Signed-off-by:
Janosch Frank <frankja@linux.ibm.com> Signed-off-by:
-
Jianglei Nie authored
[ Upstream commit 65e5d27d ] If aq_nic_stop() fails, aq_ndev_close() returns err without calling aq_nic_deinit() to release the relevant memory and resource, which will lead to a memory leak. We can fix it by deleting the if condition judgment and goto statement to call aq_nic_deinit() directly after aq_nic_stop() to fix the memory leak. Signed-off-by:
Jianglei Nie <niejianglei2021@163.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
David Gow authored
[ Upstream commit bd71558d ] Since binutils 2.39, ld will print a warning if any stack section is executable, which is the default for stack sections on files without a .note.GNU-stack section. This was fixed for x86 in commit ffcf9c57 ("x86: link vdso and boot with -z noexecstack --no-warn-rwx-segments"), but remained broken for UML, resulting in several warnings: /usr/bin/ld: warning: arch/x86/um/vdso/vdso.o: missing .note.GNU-stack section implies executable stack /usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker /usr/bin/ld: warning: .tmp_vmlinux.kallsyms1 has a LOAD segment with RWX permissions /usr/bin/ld: warning: .tmp_vmlinux.kallsyms1.o: missing .note.GNU-stack section implies executable stack /usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker /usr/bin/ld: warning: .tmp_vmlinux.kallsyms2 has a LOAD segment with RWX permissions /usr/bin/ld: warning: .tmp_vmlinux.kallsyms2.o: missing .note.GNU-stack section implies executable stack /usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker /usr/bin/ld: warning: vmlinux has a LOAD segment with RWX permissions Link both the VDSO and vmlinux with -z noexecstack, fixing the warnings about .note.GNU-stack sections. In addition, pass --no-warn-rwx-segments to dodge the remaining warnings about LOAD segments with RWX permissions in the kallsyms objects. (Note that this flag is apparently not available on lld, so hide it behind a test for BFD, which is what the x86 patch does.) Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ffcf9c5700e49c0aee42dcba9a12ba21338e8136 Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=ba951afb99912da01a6e8434126b8fac7aa75107 Signed-off-by:
David Gow <davidgow@google.com> Reviewed-by:
Lukas Straub <lukasstraub2@web.de> Tested-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
-
Linus Walleij authored
[ Upstream commit ab637d48 ] This turns the FTGPIO010 irqchip immutable. Tested on the D-Link DIR-685. Cc: Marc Zyngier <maz@kernel.org> Signed-off-by:
Marc Zyngier <maz@kernel.org> Signed-off-by:
-
Lukas Straub authored
[ Upstream commit d27fff34 ] arch.tls_array is statically allocated so checking for NULL doesn't make sense. This causes the compiler warning below. Remove the checks to silence these warnings. ../arch/x86/um/tls_32.c: In function 'get_free_idx': ../arch/x86/um/tls_32.c:68:13: warning: the comparison will always evaluate as 'true' for the address of 'tls_array' will never be NULL [-Waddress] 68 | if (!t->arch.tls_array) | ^ In file included from ../arch/x86/um/asm/processor.h:10, from ../include/linux/rcupdate.h:30, from ../include/linux/rculist.h:11, from ../include/linux/pid.h:5, from ../include/linux/sched.h:14, from ../arch/x86/um/tls_32.c:7: ../arch/x86/um/asm/processor_32.h:22:31: note: 'tls_array' declared here 22 | struct uml_tls_struct tls_array[GDT_ENTRY_TLS_ENTRIES]; | ^~~~~~~~~ ../arch/x86/um/tls_32.c: In function 'get_tls_entry': ../arch/x86/um/tls_32.c:243:13: warning: the comparison will always evaluate as 'true' for the address of 'tls_array' will never be NULL [-Waddress] 243 | if (!t->arch.tls_array) | ^ ../arch/x86/um/asm/processor_32.h:22:31: note: 'tls_array' declared here 22 | struct uml_tls_struct tls_array[GDT_ENTRY_TLS_ENTRIES]; | ^~~~~~~~~ Signed-off-by:
-
Lukas Straub authored
[ Upstream commit 61670b4d ] Like in f4f03f29 "um: Cleanup syscall_handler_t definition/cast, fix warning", remove the cast to to fix the compiler warning. Signed-off-by:
-
Jaroslav Kysela authored
[ Upstream commit 5f80d6bd ] When the user space pcm stream uses the silent stream converter, it is no longer allocated for the silent stream. Clear the appropriate flag in the hdmi_pcm_open() function. The silent stream setup may be applied in hdmi_pcm_close() (and the error path - open fcn) again. If the flag is not cleared, the reuse conditions for the silent stream converter in hdmi_choose_cvt() may improperly share this converter. Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by:
Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20220913070216.3233974-1-perex@perex.cz Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Oleksandr Mazur authored
[ Upstream commit 9124dbcc ] Aldrin2 (98DX8525) is a Marvell Prestera PP, with 100G support. Signed-off-by:
Oleksandr Mazur <oleksandr.mazur@plvision.eu> V2: - retarget to net tree instead of net-next; - fix missed colon in patch subject ('net marvell' vs 'net: mavell'); Signed-off-by:
-
Haimin Zhang authored
[ Upstream commit 94160108 ] There is uninit value bug in dgram_sendmsg function in net/ieee802154/socket.c when the length of valid data pointed by the msg->msg_name isn't verified. We introducing a helper function ieee802154_sockaddr_check_size to check namelen. First we check there is addr_type in ieee802154_addr_sa. Then, we check namelen according to addr_type. Also fixed in raw_bind, dgram_bind, dgram_connect. Signed-off-by:
Haimin Zhang <tcs_kernel@tencent.com> Signed-off-by:
-
Letu Ren authored
[ Upstream commit fbfe9686 ] In __qedf_probe(), if qedf->cdev is NULL which means qed_ops->common->probe() failed, then the program will goto label err1, and scsi_host_put() will free lport->host pointer. Because the memory qedf points to is allocated by libfc_host_alloc(), it will be freed by scsi_host_put(). However, the if statement below label err0 only checks whether qedf is NULL but doesn't check whether the memory has been freed. So a UAF bug can occur. There are two ways to reach the statements below err0. The first one is described as before, "qedf" should be set to NULL. The second one is goto "err0" directly. In the latter scenario qedf hasn't been changed and it has the initial value NULL. As a result the if statement is not reachable in any situation. The KASAN logs are as follows: [ 2.312969] BUG: KASAN: use-after-free in __qedf_probe+0x5dcf/0x6bc0 [ 2.312969] [ 2.312969] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 [ 2.312969] Call Trace: [ 2.312969] dump_stack_lvl+0x59/0x7b [ 2.312969] print_address_description+0x7c/0x3b0 [ 2.312969] ? __qedf_probe+0x5dcf/0x6bc0 [ 2.312969] __kasan_report+0x160/0x1c0 [ 2.312969] ? __qedf_probe+0x5dcf/0x6bc0 [ 2.312969] kasan_report+0x4b/0x70 [ 2.312969] ? kobject_put+0x25d/0x290 [ 2.312969] kasan_check_range+0x2ca/0x310 [ 2.312969] __qedf_probe+0x5dcf/0x6bc0 [ 2.312969] ? selinux_kernfs_init_security+0xdc/0x5f0 [ 2.312969] ? trace_rpm_return_int_rcuidle+0x18/0x120 [ 2.312969] ? rpm_resume+0xa5c/0x16e0 [ 2.312969] ? qedf_get_generic_tlv_data+0x160/0x160 [ 2.312969] local_pci_probe+0x13c/0x1f0 [ 2.312969] pci_device_probe+0x37e/0x6c0 Link: https://lore.kernel.org/r/20211112120641.16073-1-fantasquex@gmail.com Reported-by:
Zheyu Ma <zheyuma97@gmail.com> Acked-by:
Saurav Kashyap <skashyap@marvell.com> Co-developed-by:
Wende Tan <twd2.me@gmail.com> Signed-off-by:
Letu Ren <fantasquex@gmail.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Yifan Zhang authored
[ Upstream commit 0af4ed0c ] there is only one SDMA engine in SDMA 6.0.1, the sdma_hqd_mask has to be zeroed for the 2nd engine, otherwise MES scheduler will consider 2nd engine exists and map/unmap SDMA queues to the non-existent engine. Signed-off-by:
Yifan Zhang <yifan1.zhang@amd.com> Reviewed-by:
Tim Huang <Tim.Huang@amd.com> Signed-off-by:
-
Sergei Antonov authored
[ Upstream commit 02181e68 ] Driver moxart-mmc.c has .compatible = "moxa,moxart-mmc". But moxart .dts/.dtsi and the documentation file moxa,moxart-dma.txt contain compatible = "moxa,moxart-sdhci". Change moxart .dts/.dtsi files and moxa,moxart-dma.txt to match the driver. Replace 'sdhci' with 'mmc' in names too, since SDHCI is a different controller from FTSDC010. Suggested-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Sergei Antonov <saproj@gmail.com> Cc: Jonas Jensen <jonas.jensen@gmail.com> Link: https://lore.kernel.org/r/20220907175341.1477383-1-saproj@gmail.com ' Signed-off-by:
-
Jason A. Donenfeld authored
[ Upstream commit 4d8421f2 ] I get a log line like this every 4 seconds when connected to my AP: [15650.221468] iwlwifi 0000:09:00.0: Got NSS = 4 - trimming to 2 Looking at the code, this seems to be related to a hardware limitation, and there's nothing to be done. In an effort to keep my dmesg manageable, downgrade this error to "debug" rather than "info". Cc: Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by:
Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220905172246.105383-1-Jason@zx2c4.com Signed-off-by:
-
Swati Agarwal authored
[ Upstream commit 8f2b6bc7 ] The driver does not handle the failure case while calling dma_set_mask_and_coherent API. In case of failure, capture the return value of API and then report an error. Addresses-coverity: Unchecked return value (CHECKED_RETURN) Signed-off-by:
Swati Agarwal <swati.agarwal@xilinx.com> Reviewed-by:
Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com> Link: https://lore.kernel.org/r/20220817061125.4720-4-swati.agarwal@xilinx.com Signed-off-by:
Vinod Koul <vkoul@kernel.org> Signed-off-by:
-
Swati Agarwal authored
[ Upstream commit 462bce79 ] Free the allocated resources for missing xlnx,num-fstores property. Signed-off-by:
-
Swati Agarwal authored
[ Upstream commit 91df7751 ] Add missing cleanup in devm_platform_ioremap_resource(). When probe fails remove dma channel resources and disable clocks in accordance with the order of resources allocated . Signed-off-by:
-
Frank Wunderlich authored
[ Upstream commit 388f9f0a ] - extcon is no more needed in 5.19 - so drop it commit 51a9b2c0 ("phy: rockchip-inno-usb2: Handle ID IRQ") - dr_mode was changed from host to otg in rk356x.dtsi commit bc405bb3 ("arm64: dts: rockchip: enable otg/drd operation of usb_host0_xhci in rk356x") change it back on board level as id-pin on r2pro is not connected Signed-off-by:
Frank Wunderlich <frank-w@public-files.de> Link: https://lore.kernel.org/r/20220821121929.244112-1-linux@fw-web.de Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Signed-off-by:
-
Cristian Marussi authored
[ Upstream commit dea796fc ] Currently, when removing the SCMI PM driver not all the resources registered with genpd subsystem are properly de-registered. As a side effect of this after a driver unload/load cycle you get a splat with a few warnings like this: | debugfs: Directory 'BIG_CPU0' with parent 'pm_genpd' already present! | debugfs: Directory 'BIG_CPU1' with parent 'pm_genpd' already present! | debugfs: Directory 'LITTLE_CPU0' with parent 'pm_genpd' already present! | debugfs: Directory 'LITTLE_CPU1' with parent 'pm_genpd' already present! | debugfs: Directory 'LITTLE_CPU2' with parent 'pm_genpd' already present! | debugfs: Directory 'LITTLE_CPU3' with parent 'pm_genpd' already present! | debugfs: Directory 'BIG_SSTOP' with parent 'pm_genpd' already present! | debugfs: Directory 'LITTLE_SSTOP' with parent 'pm_genpd' already present! | debugfs: Directory 'DBGSYS' with parent 'pm_genpd' already present! | debugfs: Directory 'GPUTOP' with parent 'pm_genpd' already present! Add a proper scmi_pm_domain_remove callback to the driver in order to take care of all the needed cleanups not handled by devres framework. Link: https://lore.kernel.org/r/20220817172731.1185305-7-cristian.marussi@arm.com Signed-off-by:
Cristian Marussi <cristian.marussi@arm.com> Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com> Signed-off-by:
-
Cristian Marussi authored
[ Upstream commit 76f89c95 ] Accessing sensor domains descriptors by the index upon the SCMI drivers requests through the SCMI sensor operations interface can potentially lead to out-of-bound violations if the SCMI driver misbehave. Add an internal consistency check before any such domains descriptors accesses. Link: https://lore.kernel.org/r/20220817172731.1185305-4-cristian.marussi@arm.com Signed-off-by:
-
Cristian Marussi authored
[ Upstream commit 1ecb7d27 ] SCMI protocols abstract and expose a number of protocol specific resources like clocks, sensors and so on. Information about such specific domain resources are generally exposed via an `info_get` protocol operation. Improve the sanity check on these operations where needed. Link: https://lore.kernel.org/r/20220817172731.1185305-3-cristian.marussi@arm.com Signed-off-by:
-
Dongliang Mu authored
commit 2e488f13 upstream. In alloc_inode, inode_init_always() could return -ENOMEM if security_inode_alloc() fails, which causes inode->i_private uninitialized. Then nilfs_is_metadata_file_inode() returns true and nilfs_free_inode() wrongly calls nilfs_mdt_destroy(), which frees the uninitialized inode->i_private and leads to crashes(e.g., UAF/GPF). Fix this by moving security_inode_alloc just prior to this_cpu_inc(nr_inodes) Link: https://lkml.kernel.org/r/CAFcO6XOcf1Jj2SeGt=jJV59wmhESeSKpfR0omdFRq+J9nD1vfQ@mail.gmail.com Reported-by:
butt3rflyh4ck <butterflyhuangxx@gmail.com> Reported-by:
Hao Sun <sunhao.th@gmail.com> Reported-by:
Jiacheng Xu <stitch@zju.edu.cn> Reviewed-by:
Christian Brauner (Microsoft) <brauner@kernel.org> Signed-off-by:
Dongliang Mu <mudongliangabcd@gmail.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: stable@vger.kernel.org Signed-off-by:
-
Jalal Mostafa authored
commit 60240bc2 upstream. The flag for need_wakeup is not set for xsks with `XDP_SHARED_UMEM` flag and of different queue ids and/or devices. They should inherit the flag from the first socket buffer pool since no flags can be specified once `XDP_SHARED_UMEM` is specified. Fixes: b5aea28d ("xsk: Add shared umem support between queue ids") Signed-off-by:
Jalal Mostafa <jalal.a.mostapha@gmail.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Acked-by:
Magnus Karlsson <magnus.karlsson@intel.com> Link: https://lore.kernel.org/bpf/20220921135701.10199-1-jalal.a.mostapha@gmail.com Signed-off-by:
-
