summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2022-06-29net: tipc: fix possible refcount leak in tipc_sk_create()Hangyu Hua
Free sk in case tipc_sk_insert() fails. Signed-off-by: Hangyu Hua <hbh25y@gmail.com> Reviewed-by: Tung Nguyen <tung.q.nguyen@dektech.com.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-06-29powerpc/memhotplug: Add add_pages override for PPCAneesh Kumar K.V
With commit ffa0b64e3be5 ("powerpc: Fix virt_addr_valid() for 64-bit Book3E & 32-bit") the kernel now validate the addr against high_memory value. This results in the below BUG_ON with dax pfns. [ 635.798741][T26531] kernel BUG at mm/page_alloc.c:5521! 1:mon> e cpu 0x1: Vector: 700 (Program Check) at [c000000007287630] pc: c00000000055ed48: free_pages.part.0+0x48/0x110 lr: c00000000053ca70: tlb_finish_mmu+0x80/0xd0 sp: c0000000072878d0 msr: 800000000282b033 current = 0xc00000000afabe00 paca = 0xc00000037ffff300 irqmask: 0x03 irq_happened: 0x05 pid = 26531, comm = 50-landscape-sy kernel BUG at :5521! Linux version 5.19.0-rc3-14659-g4ec05be7c2e1 (kvaneesh@ltc-boston8) (gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #625 SMP Thu Jun 23 00:35:43 CDT 2022 1:mon> t [link register ] c00000000053ca70 tlb_finish_mmu+0x80/0xd0 [c0000000072878d0] c00000000053ca54 tlb_finish_mmu+0x64/0xd0 (unreliable) [c000000007287900] c000000000539424 exit_mmap+0xe4/0x2a0 [c0000000072879e0] c00000000019fc1c mmput+0xcc/0x210 [c000000007287a20] c000000000629230 begin_new_exec+0x5e0/0xf40 [c000000007287ae0] c00000000070b3cc load_elf_binary+0x3ac/0x1e00 [c000000007287c10] c000000000627af0 bprm_execve+0x3b0/0xaf0 [c000000007287cd0] c000000000628414 do_execveat_common.isra.0+0x1e4/0x310 [c000000007287d80] c00000000062858c sys_execve+0x4c/0x60 [c000000007287db0] c00000000002c1b0 system_call_exception+0x160/0x2c0 [c000000007287e10] c00000000000c53c system_call_common+0xec/0x250 The fix is to make sure we update high_memory on memory hotplug. This is similar to what x86 does in commit 3072e413e305 ("mm/memory_hotplug: introduce add_pages") Fixes: ffa0b64e3be5 ("powerpc: Fix virt_addr_valid() for 64-bit Book3E & 32-bit") Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220629050925.31447-1-aneesh.kumar@linux.ibm.com
2022-06-29powerpc/bpf: Fix use of user_pt_regs in uapiNaveen N. Rao
Trying to build a .c file that includes <linux/bpf_perf_event.h>: $ cat test_bpf_headers.c #include <linux/bpf_perf_event.h> throws the below error: /usr/include/linux/bpf_perf_event.h:14:28: error: field ‘regs’ has incomplete type 14 | bpf_user_pt_regs_t regs; | ^~~~ This is because we typedef bpf_user_pt_regs_t to 'struct user_pt_regs' in arch/powerpc/include/uaps/asm/bpf_perf_event.h, but 'struct user_pt_regs' is not exposed to userspace. Powerpc has both pt_regs and user_pt_regs structures. However, unlike arm64 and s390, we expose user_pt_regs to userspace as just 'pt_regs'. As such, we should typedef bpf_user_pt_regs_t to 'struct pt_regs' for userspace. Within the kernel though, we want to typedef bpf_user_pt_regs_t to 'struct user_pt_regs'. Remove arch/powerpc/include/uapi/asm/bpf_perf_event.h so that the uapi/asm-generic version of the header is exposed to userspace. Introduce arch/powerpc/include/asm/bpf_perf_event.h so that we can typedef bpf_user_pt_regs_t to 'struct user_pt_regs' for use within the kernel. Note that this was not showing up with the bpf selftest build since tools/include/uapi/asm/bpf_perf_event.h didn't include the powerpc variant. Fixes: a6460b03f945ee ("powerpc/bpf: Fix broken uapi for BPF_PROG_TYPE_PERF_EVENT") Cc: stable@vger.kernel.org # v4.20+ Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> [mpe: Use typical naming for header include guard] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220627191119.142867-1-naveen.n.rao@linux.vnet.ibm.com
2022-06-29drm/i915: Fix a lockdep warning at error captureNirmoy Das
For some platfroms we use stop_machine version of gen8_ggtt_insert_page/gen8_ggtt_insert_entries to avoid a concurrent GGTT access bug but this causes a circular locking dependency warning: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&ggtt->error_mutex); lock(dma_fence_map); lock(&ggtt->error_mutex); lock(cpu_hotplug_lock); Fix this by calling gen8_ggtt_insert_page/gen8_ggtt_insert_entries directly at error capture which is concurrent GGTT access safe because reset path make sure of that. v2: Fix rebase conflict and added a comment. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5595 Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220624110821.29190-1-nirmoy.das@intel.com
2022-06-29fbdev: Disable sysfb device registration when removing conflicting FBsJavier Martinez Canillas
The platform devices registered by sysfb match with firmware-based DRM or fbdev drivers, that are used to have early graphics using a framebuffer provided by the system firmware. DRM or fbdev drivers later are probed and remove conflicting framebuffers, leading to these platform devices for generic drivers to be unregistered. But the current solution has a race, since the sysfb_init() function could be called after a DRM or fbdev driver is probed and request to unregister the devices for drivers with conflicting framebuffes. To prevent this, disable any future sysfb platform device registration by calling sysfb_disable(), if a driver requests to remove the conflicting framebuffers. Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220607182338.344270-4-javierm@redhat.com
2022-06-29firmware: sysfb: Add sysfb_disable() helper functionJavier Martinez Canillas
This can be used by subsystems to unregister a platform device registered by sysfb and also to disable future platform device registration in sysfb. Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220607182338.344270-3-javierm@redhat.com
2022-06-29firmware: sysfb: Make sysfb_create_simplefb() return a pdev pointerJavier Martinez Canillas
This function just returned 0 on success or an errno code on error, but it could be useful for sysfb_init() callers to have a pointer to the device. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220607182338.344270-2-javierm@redhat.com
2022-06-28cxl/mbox: Fix missing variable payload checks in cmd size validationVishal Verma
The conversion of command sizes to unsigned missed a couple of checks against variable size payloads during command validation, which made all variable payload commands unconditionally fail. Add the checks back using the new CXL_VARIABLE_PAYLOAD scheme. Fixes: 26f89535a5bb ("cxl/mbox: Use type __u32 for mailbox payload sizes") Cc: <stable@vger.kernel.org> Cc: Ira Weiny <ira.weiny@intel.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Alison Schofield <alison.schofield@intel.com> Reported-by: Abhi Cs <abhi.cs@intel.com> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Alison Schofield <alison.schofield@intel.com> Signed-off-by: Vishal Verma <vishal.l.verma@intel.com> Link: https://lore.kernel.org/r/20220628220109.633564-1-vishal.l.verma@intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2022-06-28nfc: nfcmrvl: Fix irq_of_parse_and_map() return valueKrzysztof Kozlowski
The irq_of_parse_and_map() returns 0 on failure, not a negative ERRNO. Reported-by: Lv Ruyi <lv.ruyi@zte.com.cn> Fixes: caf6e49bf6d0 ("NFC: nfcmrvl: add spi driver") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20220627124048.296253-1-krzysztof.kozlowski@linaro.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-06-28net: ipv6: unexport __init-annotated seg6_hmac_net_init()YueHaibing
As of commit 5801f064e351 ("net: ipv6: unexport __init-annotated seg6_hmac_init()"), EXPORT_SYMBOL and __init is a bad combination because the .init.text section is freed up after the initialization. Hence, modules cannot use symbols annotated __init. The access to a freed symbol may end up with kernel panic. This remove the EXPORT_SYMBOL to fix modpost warning: WARNING: modpost: vmlinux.o(___ksymtab+seg6_hmac_net_init+0x0): Section mismatch in reference from the variable __ksymtab_seg6_hmac_net_init to the function .init.text:seg6_hmac_net_init() The symbol seg6_hmac_net_init is exported and annotated __init Fix this by removing the __init annotation of seg6_hmac_net_init or drop the export. Fixes: bf355b8d2c30 ("ipv6: sr: add core files for SR HMAC support") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20220628033134.21088-1-yuehaibing@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-06-29Merge tag 'drm-msm-fixes-2022-06-28' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/msm into drm-fixes Fixes for v5.19-rc5 - Fix to increment vsync_cnt before calling drm_crtc_handle_vblank so that userspace sees the value *after* it is incremented if waiting for vblank events - Fix to reset drm_dev to NULL in dp_display_unbind to avoid a crash in probe/bind error paths - Fix to resolve the smatch error of de-referencing before NULL check in dpu_encoder_phys_wb.c - Fix error return to userspace if fence-id allocation fails in submit ioctl Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rob Clark <robdclark@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGvswNKdd02EYKYv5Zjv7f+mcqeWC7hHQ1SBjqYzN_ZHnA@mail.gmail.com
2022-06-28ipv6/sit: fix ipip6_tunnel_get_prl return valuekatrinzhou
When kcalloc fails, ipip6_tunnel_get_prl() should return -ENOMEM. Move the position of label "out" to return correctly. Addresses-Coverity: ("Unused value") Fixes: 300aaeeaab5f ("[IPV6] SIT: Add SIOCGETPRL ioctl to get/dump PRL.") Signed-off-by: katrinzhou <katrinzhou@tencent.com> Reviewed-by: Eric Dumazet<edumazet@google.com> Reviewed-by: David Ahern <dsahern@kernel.org> Link: https://lore.kernel.org/r/20220628035030.1039171-1-zys.zljxml@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-06-28Merge branch 'mptcp-fixes-for-5-19'Jakub Kicinski
Mat Martineau says: ==================== mptcp: Fixes for 5.19 Several categories of fixes from the mptcp tree: Patches 1-3 are fixes related to MP_FAIL and FASTCLOSE, to make sure MIBs are accurate, and to handle MP_FAIL transmission and responses at the correct times. sk_timer conflicts are also resolved. Patches 4 and 6 handle two separate race conditions, one at socket shutdown and one with unaccepted subflows. Patch 5 makes sure read operations are not blocked during fallback to TCP. Patch 7 improves the diag selftest, which were incorrectly failing on slow machines (like the VMs used for CI testing). Patch 8 avoids possible symbol redefinition errors in the userspace mptcp.h file. Patch 9 fixes a selftest build issue with gcc 12. ==================== Link: https://lore.kernel.org/r/20220628010243.166605-1-mathew.j.martineau@linux.intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-06-28selftests: mptcp: Initialize variables to quiet gcc 12 warningsMat Martineau
In a few MPTCP selftest tools, gcc 12 complains that the 'sock' variable might be used uninitialized. This is a false positive because the only code path that could lead to uninitialized access is where getaddrinfo() fails, but the local xgetaddrinfo() wrapper exits if such a failure occurs. Initialize the 'sock' variable anyway to allow the tools to build with gcc 12. Fixes: 048d19d444be ("mptcp: add basic kselftest for mptcp") Acked-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-06-28mptcp: fix conflict with <netinet/in.h>Ossama Othman
Including <linux/mptcp.h> before the C library <netinet/in.h> header causes symbol redefinition errors at compile-time due to duplicate declarations and definitions in the <linux/in.h> header included by <linux/mptcp.h>. Explicitly include <netinet/in.h> before <linux/in.h> in <linux/mptcp.h> when __KERNEL__ is not defined so that the C library compatibility logic in <linux/libc-compat.h> is enabled when including <linux/mptcp.h> in user space code. Fixes: c11c5906bc0a ("mptcp: add MPTCP_SUBFLOW_ADDRS getsockopt support") Signed-off-by: Ossama Othman <ossama.othman@intel.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-06-28selftests: mptcp: more stable diag testsPaolo Abeni
The mentioned test-case still use an hard-coded-len sleep to wait for a relative large number of connection to be established. On very slow VM and with debug build such timeout could be exceeded, causing failures in our CI. Address the issue polling for the expected condition several times, up to an unreasonable high amount of time. On reasonably fast system the self-tests will be faster then before, on very slow one we will still catch the correct condition. Fixes: df62f2ec3df6 ("selftests/mptcp: add diag interface tests") Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-06-28mptcp: fix race on unaccepted mptcp socketsPaolo Abeni
When the listener socket owning the relevant request is closed, it frees the unaccepted subflows and that causes later deletion of the paired MPTCP sockets. The mptcp socket's worker can run in the time interval between such delete operations. When that happens, any access to msk->first will cause an UaF access, as the subflow cleanup did not cleared such field in the mptcp socket. Address the issue explicitly traversing the listener socket accept queue at close time and performing the needed cleanup on the pending msk. Note that the locking is a bit tricky, as we need to acquire the msk socket lock, while still owning the subflow socket one. Fixes: 86e39e04482b ("mptcp: keep track of local endpoint still available for each msk") Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-06-28mptcp: consistent map handling on failurePaolo Abeni
When the MPTCP receive path reach a non fatal fall-back condition, e.g. when the MPC sockets must fall-back to TCP, the existing code is a little self-inconsistent: it reports that new data is available - return true - but sets the MPC flag to the opposite value. As the consequence read operations in some exceptional scenario may block unexpectedly. Address the issue setting the correct MPC read status. Additionally avoid some code duplication in the fatal fall-back scenario. Fixes: 9c81be0dbc89 ("mptcp: add MP_FAIL response support") Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-06-28mptcp: fix shutdown vs fallback racePaolo Abeni
If the MPTCP socket shutdown happens before a fallback to TCP, and all the pending data have been already spooled, we never close the TCP connection. Address the issue explicitly checking for critical condition at fallback time. Fixes: 1e39e5a32ad7 ("mptcp: infinite mapping sending") Fixes: 0348c690ed37 ("mptcp: add the fallback check") Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-06-28mptcp: invoke MP_FAIL response when neededGeliang Tang
mptcp_mp_fail_no_response shouldn't be invoked on each worker run, it should be invoked only when MP_FAIL response timeout occurs. This patch refactors the MP_FAIL response logic. It leverages the fact that only the MPC/first subflow can gracefully fail to avoid unneeded subflows traversal: the failing subflow can be only msk->first. A new 'fail_tout' field is added to the subflow context to record the MP_FAIL response timeout and use such field to reliably share the timeout timer between the MP_FAIL event and the MPTCP socket close timeout. Finally, a new ack is generated to send out MP_FAIL notification as soon as we hit the relevant condition, instead of waiting a possibly unbound time for the next data packet. Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/281 Fixes: d9fb797046c5 ("mptcp: Do not traverse the subflow connection list without lock") Co-developed-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Geliang Tang <geliang.tang@suse.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-06-28mptcp: introduce MAPPING_BAD_CSUMPaolo Abeni
This allow moving a couple of conditional out of the fast path, making the code more easy to follow and will simplify the next patch. Fixes: ae66fb2ba6c3 ("mptcp: Do TCP fallback on early DSS checksum failure") Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-06-28mptcp: fix error mibs accountingPaolo Abeni
The current accounting for MP_FAIL and FASTCLOSE is not very accurate: both can be increased even when the related option is not really sent. Move the accounting into the correct place. Fixes: eb7f33654dc1 ("mptcp: add the mibs for MP_FAIL") Fixes: 1e75629cb964 ("mptcp: add the mibs for MP_FASTCLOSE") Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-06-29gen_compile_commands: handle multiple lines per .mod fileJohn Hubbard
scripts/clang-tools/gen_compile_commands.py incorrectly assumes that each .mod file only contains one line. That assumption was correct when the script was originally created, but commit 9413e7640564 ("kbuild: split the second line of *.mod into *.usyms") changed the .mod file format so that there is one entry per line, and potentially many lines. The problem can be reproduced by using Kbuild to generate compile_commands.json, like this: make CC=clang compile_commands.json In many cases, the problem might be overlooked because many subsystems only have one line anyway. However, in some subsystems (Nouveau, with 762 entries, is a notable example) it results in skipping most of the subsystem. Fix this by fully processing each .mod file. Fixes: 9413e7640564 ("kbuild: split the second line of *.mod into *.usyms") Signed-off-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2022-06-29drm: lcdif: Add support for i.MX8MP LCDIF variantMarek Vasut
Add support for i.MX8MP LCDIF variant. This is called LCDIFv3 and is completely different from the LCDIFv3 found in i.MX23 in that it has a completely scrambled register layout compared to all previous LCDIF variants. The new LCDIFv3 also supports 36bit address space. Add a separate driver which is really a fork of MXSFB driver with the i.MX8MP LCDIF variant handling filled in. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> Tested-by: Martyn Welch <martyn.welch@collabora.com> Signed-off-by: Marek Vasut <marex@denx.de> Cc: Alexander Stein <alexander.stein@ew.tq-group.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Peng Fan <peng.fan@nxp.com> Cc: Robby Cai <robby.cai@nxp.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Stefan Agner <stefan@agner.ch> Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220628174152.167284-2-marex@denx.de
2022-06-29dt-bindings: lcdif: Add compatible for i.MX8MPMarek Vasut
Add compatible string for i.MX8MP LCDIF variant. This is called LCDIFv3 and is completely different from the LCDIFv3 found in i.MX23 in that it has a completely scrambled register layout compared to all previous LCDIF variants. The new LCDIFv3 also supports 36bit address space. However, except for the complete bit reshuffling, this is still LCDIF and it still works like one. Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Marek Vasut <marex@denx.de> Cc: Alexander Stein <alexander.stein@ew.tq-group.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Peng Fan <peng.fan@nxp.com> Cc: Rob Herring <robh+dt@kernel.org> Cc: Robby Cai <robby.cai@nxp.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Stefan Agner <stefan@agner.ch> Cc: devicetree@vger.kernel.org Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220628174152.167284-1-marex@denx.de
2022-06-29drm/bridge: tc358767: Do not cache dsi_lanes twiceMarek Vasut
The DSI lane count can be accessed via the dsi device pointer, make use of that. No functional change. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Andrzej Hajda <andrzej.hajda@intel.com> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Maxime Ripard <maxime@cerno.tech> Cc: Robert Foss <robert.foss@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220624181902.151959-1-marex@denx.de
2022-06-28drm/display/selftests: drop extra word 'for' in comments for MST selftestsJiang Jian
there is an unexpected word 'for' in the comments that need to be dropped file - ./drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c line - 3 * Test cases for for the DRM DP MST helpers changed to: * Test cases for the DRM DP MST helpers Signed-off-by: Jiang Jian <jiangjian@cdjrlc.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220623100632.27056-1-jiangjian@cdjrlc.com
2022-06-28Merge tag 'drm-msm-fixes-2022-06-28' into msm-next-stagingRob Clark
Merge v5.19 fixes to avoid merge conflicts Signed-off-by: Rob Clark <robdclark@chromium.org>
2022-06-28xsk: Clear page contiguity bit when unmapping poolIvan Malov
When a XSK pool gets mapped, xp_check_dma_contiguity() adds bit 0x1 to pages' DMA addresses that go in ascending order and at 4K stride. The problem is that the bit does not get cleared before doing unmap. As a result, a lot of warnings from iommu_dma_unmap_page() are seen in dmesg, which indicates that lookups by iommu_iova_to_phys() fail. Fixes: 2b43470add8c ("xsk: Introduce AF_XDP buffer allocation API") Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Magnus Karlsson <magnus.karlsson@intel.com> Link: https://lore.kernel.org/bpf/20220628091848.534803-1-ivan.malov@oktetlabs.ru
2022-06-28platform/x86: hp-wmi: Ignore Sanitization Mode eventKai-Heng Feng
After system resume the hp-wmi driver may complain: [ 702.620180] hp_wmi: Unknown event_id - 23 - 0x0 According to HP it means 'Sanitization Mode' and it's harmless to just ignore the event. Cc: Jorge Lopez <jorge.lopez2@hp.com> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Link: https://lore.kernel.org/r/20220628123726.250062-1-kai.heng.feng@canonical.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-06-28platform/x86: thinkpad_acpi: do not use PSC mode on Intel platformsMark Pearson
PSC platform profile mode is only supported on Linux for AMD platforms. Some older Intel platforms (e.g T490) are advertising it's capability as Windows uses it - but on Linux we should only be using MMC profile for Intel systems. Add a check to prevent it being enabled incorrectly. Signed-off-by: Mark Pearson <markpearson@lenovo.com> Link: https://lore.kernel.org/r/20220627181449.3537-1-markpearson@lenovo.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-06-28platform/x86: thinkpad-acpi: profile capabilities as integerMark Pearson
Currently the active mode (PSC/MMC) is stored in an enum and queried throughout the driver. Other driver changes will enumerate additional submodes that are relevant to be tracked, so instead track PSC/MMC in a single integer variable. Co-developed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Mark Pearson <markpearson@lenovo.com> Link: https://lore.kernel.org/r/20220603170212.164963-1-markpearson@lenovo.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-06-28platform/x86: panasonic-laptop: filter out duplicate volume up/down/mute ↵Hans de Goede
keypresses On some Panasonic models the volume up/down/mute keypresses get reported both through the Panasonic ACPI HKEY interface as well as through the atkbd device. Filter out the atkbd scan-codes for these to avoid reporting presses twice. Note normally we would leave the filtering of these to userspace by mapping the scan-codes to KEY_UNKNOWN through /lib/udev/hwdb.d/60-keyboard.hwdb. However in this case that would cause regressions since we were filtering the Panasonic ACPI HKEY events before, so filter these in the kernel. Fixes: ed83c9171829 ("platform/x86: panasonic-laptop: Resolve hotkey double trigger bug") Reported-and-tested-by: Stefan Seyfried <seife+kernel@b1-systems.com> Reported-and-tested-by: Kenneth Chan <kenneth.t.chan@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20220624112340.10130-7-hdegoede@redhat.com
2022-06-28platform/x86: panasonic-laptop: don't report duplicate brightness key-pressesHans de Goede
The brightness key-presses might also get reported by the ACPI video bus, check for this and in this case don't report the presses to avoid reporting 2 presses for a single key-press. Fixes: ed83c9171829 ("platform/x86: panasonic-laptop: Resolve hotkey double trigger bug") Reported-and-tested-by: Stefan Seyfried <seife+kernel@b1-systems.com> Reported-and-tested-by: Kenneth Chan <kenneth.t.chan@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20220624112340.10130-6-hdegoede@redhat.com
2022-06-28platform/x86: panasonic-laptop: revert "Resolve hotkey double trigger bug"Hans de Goede
In hindsight blindly throwing away most of the key-press events is not a good idea. So revert commit ed83c9171829 ("platform/x86: panasonic-laptop: Resolve hotkey double trigger bug"). Fixes: ed83c9171829 ("platform/x86: panasonic-laptop: Resolve hotkey double trigger bug") Reported-and-tested-by: Stefan Seyfried <seife+kernel@b1-systems.com> Reported-and-tested-by: Kenneth Chan <kenneth.t.chan@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20220624112340.10130-5-hdegoede@redhat.com
2022-06-28platform/x86: panasonic-laptop: sort includes alphabeticallyHans de Goede
Sort includes alphabetically, small cleanup patch in preparation of further changes. Fixes: ed83c9171829 ("platform/x86: panasonic-laptop: Resolve hotkey double trigger bug") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20220624112340.10130-4-hdegoede@redhat.com
2022-06-28platform/x86: panasonic-laptop: de-obfuscate button codesStefan Seyfried
In the definition of panasonic_keymap[] the key codes are given in decimal, later checks are done with hexadecimal values, which does not help in understanding the code. Additionally use two helper variables to shorten the code and make the logic more obvious. Fixes: ed83c9171829 ("platform/x86: panasonic-laptop: Resolve hotkey double trigger bug") Signed-off-by: Stefan Seyfried <seife+kernel@b1-systems.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20220624112340.10130-3-hdegoede@redhat.com
2022-06-28ACPI: video: Change how we determine if brightness key-presses are handledHans de Goede
Some systems have an ACPI video bus but not ACPI video devices with backlight capability. On these devices brightness key-presses are (logically) not reported through the ACPI video bus. Change how acpi_video_handles_brightness_key_presses() determines if brightness key-presses are handled by the ACPI video driver to avoid vendor specific drivers/platform/x86 drivers filtering out their brightness key-presses even though they are the only ones reporting these presses. Fixes: ed83c9171829 ("platform/x86: panasonic-laptop: Resolve hotkey double trigger bug") Reported-and-tested-by: Stefan Seyfried <seife+kernel@b1-systems.com> Reported-and-tested-by: Kenneth Chan <kenneth.t.chan@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20220624112340.10130-2-hdegoede@redhat.com
2022-06-28tools headers UAPI: Sync linux/kvm.h with the kernel sourcesArnaldo Carvalho de Melo
To pick the changes in: bfbab44568779e16 ("KVM: arm64: Implement PSCI SYSTEM_SUSPEND") 7b33a09d036ffd9a ("KVM: arm64: Add support for userspace to suspend a vCPU") ffbb61d09fc56c85 ("KVM: x86: Accept KVM_[GS]ET_TSC_KHZ as a VM ioctl.") 661a20fab7d156cf ("KVM: x86/xen: Advertise and document KVM_XEN_HVM_CONFIG_EVTCHN_SEND") fde0451be8fb3208 ("KVM: x86/xen: Support per-vCPU event channel upcall via local APIC") 28d1629f751c4a5f ("KVM: x86/xen: Kernel acceleration for XENVER_version") 536395260582be74 ("KVM: x86/xen: handle PV timers oneshot mode") 942c2490c23f2800 ("KVM: x86/xen: Add KVM_XEN_VCPU_ATTR_TYPE_VCPU_ID") 2fd6df2f2b47d430 ("KVM: x86/xen: intercept EVTCHNOP_send from guests") 35025735a79eaa89 ("KVM: x86/xen: Support direct injection of event channel events") That automatically adds support for this new ioctl: $ tools/perf/trace/beauty/kvm_ioctl.sh > before $ cp include/uapi/linux/kvm.h tools/include/uapi/linux/kvm.h $ tools/perf/trace/beauty/kvm_ioctl.sh > after $ diff -u before after --- before 2022-06-28 12:13:07.281150509 -0300 +++ after 2022-06-28 12:13:16.423392896 -0300 @@ -98,6 +98,7 @@ [0xcc] = "GET_SREGS2", [0xcd] = "SET_SREGS2", [0xce] = "GET_STATS_FD", + [0xd0] = "XEN_HVM_EVTCHN_SEND", [0xe0] = "CREATE_DEVICE", [0xe1] = "SET_DEVICE_ATTR", [0xe2] = "GET_DEVICE_ATTR", $ This silences these perf build warning: Warning: Kernel ABI header at 'tools/include/uapi/linux/kvm.h' differs from latest version at 'include/uapi/linux/kvm.h' diff -u tools/include/uapi/linux/kvm.h include/uapi/linux/kvm.h Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Woodhouse <dwmw@amazon.co.uk> Cc: Ian Rogers <irogers@google.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Joao Martins <joao.m.martins@oracle.com> Cc: Marc Zyngier <maz@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Oliver Upton <oupton@google.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Link: http://lore.kernel.org/lkml/Yrs4RE+qfgTaWdAt@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2022-06-28bpf, docs: Better scale maintenance of BPF subsystemAlexei Starovoitov
The BPF subsystem consists of a large number of pieces. There is not a single person that understands it all. Yet reviews are crucially important for the BPF community to provide productive quality feedback to contributors in a timely manner and therefore to ultimately expand the number of active developers in the community. So far, the BPF community had a two-stage review system, that is, a weekly rotation among 7 developers (Alexei, Daniel, Andrii, Martin, Song, Yonghong, John) as a first-level review of all inbound patches accompanied by a BPF CI system which runs the in-tree BPF selftests to check for regressions for every new patch, and then, a final check by Alexei, Daniel, Andrii to apply the patches to either bpf or bpf-next trees. This system worked well for the last ~3.5 years, but clearly reaches its limits these days as it does not scale enough. Especially, as we also need to allow enough room for every developer to contribute patches themselves, integrate with their day to day job, and in particular avoid burnout. We want to better scale both horizontally and vertically going forward. On the horizontal scale, we are adding more developers (KP, Stan, Hao, Jiri) to the overall core reviewer team, thus growing to 11 people in total. The weekly rotation for the horizontal oncall reviewer is shortened to 1/2 week (Mo - Wed and Thur - Fri). Instead of just patches, the coverage however extends also generally to triage and reply to mailing list traffic (e.g. RFCs, questions, etc). On the vertical scale, there is clearly a need for deep expertise areas to assign dedicated maintainer/reviewer teams that are responsible for code reviews and help with design of individual building blocks. To some degree we have been doing this implicitly, but the point is to formalize the teams and commitment. There is an overlap between areas and boundaries are intentionally grey. These additional entries provide a guidance on who has to look at the patches. The patch series which span multiple areas will be looked at by multiple people. The vertical review with areas of deep expertise are bundled at the same time with the horizontal side. This patch cleans up a bit the BPF entries, adds mentioned developers to the horizontal scale and creates new sub-entries with teams for developers committing to the above outlined vertical scale. Also, pw.git tools we use for BPF tree maintenance have been updated with a new pw-schedule script to semi-automate vertical oncall review rotation. Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Martin KaFai Lau <martin.lau@linux.dev> Acked-by: Song Liu <song@kernel.org> Acked-by: Yonghong Song <yhs@fb.com> Acked-by: Mykola Lysenko <mykolal@fb.com> Acked-by: John Fastabend <john.fastabend@gmail.com> Acked-by: Jiri Olsa <jolsa@kernel.org> Acked-by: KP Singh <kpsingh@kernel.org> Acked-by: Stanislav Fomichev <sdf@google.com> Acked-by: Hao Luo <haoluo@google.com> Acked-by: Quentin Monnet <quentin@isovalent.com> Link: https://git.kernel.org/pub/scm/linux/kernel/git/dborkman/pw.git Link: https://lore.kernel.org/bpf/5bdc73e7f5a087299589944fa074563cdf2c2c1a.1656353995.git.daniel@iogearbox.net
2022-06-28Merge tag 'cpufreq-arm-fixes-5.19-rc5' of ↵Rafael J. Wysocki
git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm Pull cpufreq ARM fixes for 5.19-rc5 from Viresh Kumar: - Fix missing of_node_put for qoriq and pmac32 driver (Liang He). - Fix issues around throttle interrupt for qcom driver (Stephen Boyd). - Add MT8186 to cpufreq-dt-platdev blocklist (AngeloGioacchino Del Regno). * tag 'cpufreq-arm-fixes-5.19-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm: cpufreq: Add MT8186 to cpufreq-dt-platdev blocklist cpufreq: pmac32-cpufreq: Fix refcount leak bug cpufreq: qcom-hw: Don't do lmh things without a throttle interrupt drivers: cpufreq: Add missing of_node_put() in qoriq-cpufreq.c
2022-06-28Revert "drm/amdkfd: Free queue after unmap queue success"Philip Yang
This reverts commit ab8529b0cdb271d9b222cbbddb2641f3fca5df8f. This causes KFDTest KFDMemoryTest.MemoryRegister test failed on gfx9. Signed-off-by: Philip Yang <Philip.Yang@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-28drm/amdgpu/display/dc: Fix null pointer exceptionRahul Kumar
We observed hard hang due to NULL derefrence This issue is seen after running system all the time after two or three days struct dc *dc = plane_state->ctx->dc; Randomly in long run we found plane_state or plane_state->ctx is found NULL which causes exception. BUG: kernel NULL pointer dereference, address: 0000000000000000 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present page PGD 1dc7f2067 P4D 1dc7f2067 PUD 222c75067 PMD 0 Oops: 0000 [#1] SMP NOPTI CPU: 5 PID: 29855 Comm: kworker/u16:4 ... ... Workqueue: events_unbound commit_work [drm_kms_helper] RIP: 0010:dcn10_update_pending_status+0x1f/0xee [amdgpu] Code: 41 5f c3 0f 1f 44 00 00 b0 01 c3 0f 1f 44 00 00 41 55 41 54 55 53 48 8b 1f 4c 8b af f8 00 00 00 48 8b 83 88 03 00 00 48 85 db <4c> 8b 20 0f 84 bf 00 00 00 48 89 fd 48 8b bf b8 00 00 00 48 8b 07 RSP: 0018:ffff942941997ab8 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff8d7fd98d2000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff8d7e3e87c708 RDI: ffff8d7f2d8c0690 RBP: ffff8d7f2d8c0000 R08: ffff942941997a34 R09: 00000000ffffffff R10: 0000000000005000 R11: 00000000000000f0 R12: ffff8d7f2d8c0690 R13: ffff8d8035a41680 R14: 00000000000186a0 R15: ffff8d7f2d8c1dd8 FS: 0000000000000000(0000) GS:ffff8d8037340000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000148030000 CR4: 00000000003406e0 Call Trace: dc_commit_state+0x6a2/0x7f0 [amdgpu] amdgpu_dm_atomic_commit_tail+0x460/0x19bb [amdgpu] Tested-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Rahul Kumar <rahul.kumar1@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-28drm/amdgpu: Follow up change to previous drm scheduler change.Andrey Grodzovsky
Align refcount behaviour for amdgpu_job embedded HW fence with classic pointer style HW fences by increasing refcount each time emit is called so amdgpu code doesn't need to make workarounds using amdgpu_job.job_run_counter to keep the HW fence refcount balanced. Also since in the previous patch we resumed setting s_fence->parent to NULL in drm_sched_stop switch to directly checking if job->hw_fence is signaled to short circuit reset if already signed. Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Tested-by: Yiqing Yao <yiqing.yao@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-28drm/sched: Partial revert of 'drm/sched: Keep s_fence->parent pointer'Andrey Grodzovsky
Problem: This patch caused negative refcount as described in [1] because for that case parent fence did not signal by the time of drm_sched_stop and hence kept in pending list the assumption was they will not signal and so fence was put to account for the s_fence->parent refcount but for amdgpu which has embedded HW fence (always same parent fence) drm_sched_fence_release_scheduled was always called and would still drop the count for parent fence once more. For jobs that never signaled this imbalance was masked by refcount bug in amdgpu_fence_driver_clear_job_fences that would not drop refcount on the fences that were removed from fence drive fences array (against prevois insertion into the array in get in amdgpu_fence_emit). Fix: Revert this patch and by setting s_job->s_fence->parent to NULL as before prevent the extra refcount drop in amdgpu when drm_sched_fence_release_scheduled is called on job release. Also - align behaviour in drm_sched_resubmit_jobs_ext with that of drm_sched_main when submitting jobs - take a refcount for the new parent fence pointer and drop refcount for original kref_init for new HW fence creation (or fake new HW fence in amdgpu - see next patch). [1] - https://lore.kernel.org/all/731b7ff1-3cc9-e314-df2a-7c51b76d4db0@amd.com/t/#r00c728fcc069b1276642c325bfa9d82bf8fa21a3 Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Tested-by: Yiqing Yao <yiqing.yao@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-28drm/amdgpu: Prevent race between late signaled fences and GPU reset.Andrey Grodzovsky
Problem: After we start handling timed out jobs we assume there fences won't be signaled but we cannot be sure and sometimes they fire late. We need to prevent concurrent accesses to fence array from amdgpu_fence_driver_clear_job_fences during GPU reset and amdgpu_fence_process from a late EOP interrupt. Fix: Before accessing fence array in GPU disable EOP interrupt and flush all pending interrupt handlers for amdgpu device's interrupt line. v2: Switch from irq_get/put to full enable/disable_irq for amdgpu Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-28drm/amdgpu: Add put fence in amdgpu_fence_driver_clear_job_fencesAndrey Grodzovsky
This function should drop the fence refcount when it extracts the fence from the fence array, just as it's done in amdgpu_fence_process. Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-28drm/amdgpu: Remove useless amdgpu_display_freesync_ioctl() declarationLeslie Shi
Signed-off-by: Leslie Shi <Yuliang.Shi@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-28drm/amdgpu: add mc wptr addr support for mesJack Xiao
MES requires mc wptr address for usermode queues. Export bo gart address for mc wptr address. Signed-off-by: Jack Xiao <Jack.Xiao@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-28drm/amd/display : Log DP link training failure reasonChandan Vurdigere Nataraj
[Why] Existing logs doesn't print DP LT failure reason [How] Update the existing log with DP LT failure reason Signed-off-by: Chandan Vurdigere Nataraj <chandan.vurdigerenataraj@amd.com> Reviewed-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
generated by cgit (git 2.34.1) at 2025-10-01 00:54:45 +0000