summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2024-05-30net: txgbe: fix GPIO interrupt blockingJiawen Wu3-0/+29
[ Upstream commit b4a2496c17ed645f8d51061047c9c249b58c74ba ] The register of GPIO interrupt status is masked before MAC IRQ is enabled. This is because of hardware deficiency. So manually clear the interrupt status before using them. Otherwise, GPIO interrupts will never be reported again. There is a workaround for clearing interrupts to set GPIO EOI in txgbe_up_complete(). Fixes: aefd013624a1 ("net: txgbe: use irq_domain for interrupt controller") Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com> Link: https://lore.kernel.org/r/20240301092956.18544-1-jiawenwu@trustnetic.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30net: txgbe: fix to clear interrupt status after handling IRQJiawen Wu1-0/+2
[ Upstream commit 0e71862a20d58b6e8d4c39de1d72c8919c4dccd1 ] GPIO EOI is not set to clear interrupt status after handling the interrupt. It should be done in irq_chip->irq_ack, but this function is not called in handle_nested_irq(). So executing function txgbe_gpio_irq_ack() manually in txgbe_gpio_irq_handler(). Fixes: aefd013624a1 ("net: txgbe: use irq_domain for interrupt controller") Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com> Link: https://lore.kernel.org/r/20240301092956.18544-2-jiawenwu@trustnetic.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30pwm: Fix setting period with #pwm-cells = <1> and of_pwm_single_xlate()Uwe Kleine-König1-1/+1
[ Upstream commit 73dfe970c038d0548beccc5bfb2707e1d543b01f ] For drivers making use of of_pwm_single_xlate() (i.e. those that don't pass a hwpwm index) and also don't pass flags, setting period was wrongly skipped. This affects the pwm-pxa and ti-sn65dsi86 drivers. Reported-by: Karel Balej <balejk@matfyz.cz> Link: https://lore.kernel.org/r/D05IVTPYH35N.2CLDG6LSILRSN@matfyz.cz Fixes: 40ade0c2e794 ("pwm: Let the of_xlate callbacks accept references without period") Tested-by: Karel Balej <balejk@matfyz.cz> Link: https://lore.kernel.org/r/20240329103544.545290-2-u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30net: txgbe: fix to control VLAN stripJiawen Wu7-13/+84
[ Upstream commit 1d3c6414950badaa38002af3b5857e01a21f01e9 ] When VLAN tag strip is changed to enable or disable, the hardware requires the Rx ring to be in a disabled state, otherwise the feature cannot be changed. Fixes: f3b03c655f67 ("net: wangxun: Implement vlan add and kill functions") Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30net: txgbe: use irq_domain for interrupt controllerJiawen Wu9-54/+193
[ Upstream commit aefd013624a10f39b0bfaee8432a235128705380 ] In the current interrupt controller, the MAC interrupt acts as the parent interrupt in the GPIO IRQ chip. But when the number of Rx/Tx ring changes, the PCI IRQ vector needs to be reallocated. Then this interrupt controller would be corrupted. So use irq_domain structure to avoid the above problem. Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com> Signed-off-by: David S. Miller <davem@davemloft.net> Stable-dep-of: 1d3c6414950b ("net: txgbe: fix to control VLAN strip") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30net: txgbe: move interrupt codes to a separate fileJiawen Wu4-127/+144
[ Upstream commit 63aabc3ef1961a5eb3049d02a323b3b7fabb9a23 ] In order to change the interrupt response structure, there will be a lot of code added next. Move these interrupt codes to a new file, to make the codes cleaner. Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com> Signed-off-by: David S. Miller <davem@davemloft.net> Stable-dep-of: 1d3c6414950b ("net: txgbe: fix to control VLAN strip") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30net: wangxun: match VLAN CTAG and STAG featuresJiawen Wu4-0/+50
[ Upstream commit ac71ab7816b675f1c9614015bd87bfccb456c394 ] Hardware requires VLAN CTAG and STAG configuration always matches. And whether VLAN CTAG or STAG changes, the configuration needs to be changed as well. Fixes: 6670f1ece2c8 ("net: txgbe: Add netdev features support") Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com> Reviewed-by: Sai Krishna <saikrishnag@marvell.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30net: wangxun: fix to change Rx featuresJiawen Wu1-1/+3
[ Upstream commit 68067f065ee730c7c67b361c3c81808d25d5a90b ] Fix the issue where some Rx features cannot be changed. When using ethtool -K to turn off rx offload, it returns error and displays "Could not change any device features". And netdev->features is not assigned a new value to actually configure the hardware. Fixes: 6dbedcffcf54 ("net: libwx: Implement xx_set_features ops") Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30idpf: don't skip over ethtool tcp-data-split settingMichal Schmidt1-1/+2
[ Upstream commit 67708158e732bf03d076fba1e3d4453fbf8292a2 ] Disabling tcp-data-split on idpf silently fails: # ethtool -G $NETDEV tcp-data-split off # ethtool -g $NETDEV | grep 'TCP data split' TCP data split: on But it works if you also change 'tx' or 'rx': # ethtool -G $NETDEV tcp-data-split off tx 256 # ethtool -g $NETDEV | grep 'TCP data split' TCP data split: off The bug is in idpf_set_ringparam, where it takes a shortcut out if the TX and RX sizes are not changing. Fix it by checking also if the tcp-data-split setting remains unchanged. Only then can the soft reset be skipped. Fixes: 9b1aa3ef2328 ("idpf: add get/set for Ethtool's header split ringparam") Reported-by: Xu Du <xudu@redhat.com> Closes: https://issues.redhat.com/browse/RHEL-36182 Signed-off-by: Michal Schmidt <mschmidt@redhat.com> Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com> Link: https://lore.kernel.org/r/20240515092414.158079-1-mschmidt@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30RDMA/cma: Fix kmemleak in rdma_core observed during blktests nvme/rdma use siwZhu Yanjun1-1/+3
[ Upstream commit 9c0731832d3b7420cbadba6a7f334363bc8dfb15 ] When running blktests nvme/rdma, the following kmemleak issue will appear. kmemleak: Kernel memory leak detector initialized (mempool available:36041) kmemleak: Automatic memory scanning thread started kmemleak: 2 new suspected memory leaks (see /sys/kernel/debug/kmemleak) kmemleak: 8 new suspected memory leaks (see /sys/kernel/debug/kmemleak) kmemleak: 17 new suspected memory leaks (see /sys/kernel/debug/kmemleak) kmemleak: 4 new suspected memory leaks (see /sys/kernel/debug/kmemleak) unreferenced object 0xffff88855da53400 (size 192): comm "rdma", pid 10630, jiffies 4296575922 hex dump (first 32 bytes): 37 00 00 00 00 00 00 00 c0 ff ff ff 1f 00 00 00 7............... 10 34 a5 5d 85 88 ff ff 10 34 a5 5d 85 88 ff ff .4.].....4.].... backtrace (crc 47f66721): [<ffffffff911251bd>] kmalloc_trace+0x30d/0x3b0 [<ffffffffc2640ff7>] alloc_gid_entry+0x47/0x380 [ib_core] [<ffffffffc2642206>] add_modify_gid+0x166/0x930 [ib_core] [<ffffffffc2643468>] ib_cache_update.part.0+0x6d8/0x910 [ib_core] [<ffffffffc2644e1a>] ib_cache_setup_one+0x24a/0x350 [ib_core] [<ffffffffc263949e>] ib_register_device+0x9e/0x3a0 [ib_core] [<ffffffffc2a3d389>] 0xffffffffc2a3d389 [<ffffffffc2688cd8>] nldev_newlink+0x2b8/0x520 [ib_core] [<ffffffffc2645fe3>] rdma_nl_rcv_msg+0x2c3/0x520 [ib_core] [<ffffffffc264648c>] rdma_nl_rcv_skb.constprop.0.isra.0+0x23c/0x3a0 [ib_core] [<ffffffff9270e7b5>] netlink_unicast+0x445/0x710 [<ffffffff9270f1f1>] netlink_sendmsg+0x761/0xc40 [<ffffffff9249db29>] __sys_sendto+0x3a9/0x420 [<ffffffff9249dc8c>] __x64_sys_sendto+0xdc/0x1b0 [<ffffffff92db0ad3>] do_syscall_64+0x93/0x180 [<ffffffff92e00126>] entry_SYSCALL_64_after_hwframe+0x71/0x79 The root cause: rdma_put_gid_attr is not called when sgid_attr is set to ERR_PTR(-ENODEV). Reported-and-tested-by: Yi Zhang <yi.zhang@redhat.com> Closes: https://lore.kernel.org/all/19bf5745-1b3b-4b8a-81c2-20d945943aaf@linux.dev/T/ Fixes: f8ef1be816bf ("RDMA/cma: Avoid GID lookups on iWARP devices") Reviewed-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Zhu Yanjun <yanjun.zhu@linux.dev> Link: https://lore.kernel.org/r/20240510211247.31345-1-yanjun.zhu@linux.dev Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30RDMA/IPoIB: Fix format truncation compilation errorsLeon Romanovsky1-2/+6
[ Upstream commit 49ca2b2ef3d003402584c68ae7b3055ba72e750a ] Truncate the device name to store IPoIB VLAN name. [leonro@5b4e8fba4ddd kernel]$ make -s -j 20 allmodconfig [leonro@5b4e8fba4ddd kernel]$ make -s -j 20 W=1 drivers/infiniband/ulp/ipoib/ drivers/infiniband/ulp/ipoib/ipoib_vlan.c: In function ‘ipoib_vlan_add’: drivers/infiniband/ulp/ipoib/ipoib_vlan.c:187:52: error: ‘%04x’ directive output may be truncated writing 4 bytes into a region of size between 0 and 15 [-Werror=format-truncation=] 187 | snprintf(intf_name, sizeof(intf_name), "%s.%04x", | ^~~~ drivers/infiniband/ulp/ipoib/ipoib_vlan.c:187:48: note: directive argument in the range [0, 65535] 187 | snprintf(intf_name, sizeof(intf_name), "%s.%04x", | ^~~~~~~~~ drivers/infiniband/ulp/ipoib/ipoib_vlan.c:187:9: note: ‘snprintf’ output between 6 and 21 bytes into a destination of size 16 187 | snprintf(intf_name, sizeof(intf_name), "%s.%04x", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 188 | ppriv->dev->name, pkey); | ~~~~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[6]: *** [scripts/Makefile.build:244: drivers/infiniband/ulp/ipoib/ipoib_vlan.o] Error 1 make[6]: *** Waiting for unfinished jobs.... Fixes: 9baa0b036410 ("IB/ipoib: Add rtnl_link_ops support") Link: https://lore.kernel.org/r/e9d3e1fef69df4c9beaf402cc3ac342bad680791.1715240029.git.leon@kernel.org Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30bnxt_re: avoid shift undefined behavior in bnxt_qplib_alloc_init_hwqMichal Schmidt1-1/+2
[ Upstream commit 78cfd17142ef70599d6409cbd709d94b3da58659 ] Undefined behavior is triggered when bnxt_qplib_alloc_init_hwq is called with hwq_attr->aux_depth != 0 and hwq_attr->aux_stride == 0. In that case, "roundup_pow_of_two(hwq_attr->aux_stride)" gets called. roundup_pow_of_two is documented as undefined for 0. Fix it in the one caller that had this combination. The undefined behavior was detected by UBSAN: UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13 shift exponent 64 is too large for 64-bit type 'long unsigned int' CPU: 24 PID: 1075 Comm: (udev-worker) Not tainted 6.9.0-rc6+ #4 Hardware name: Abacus electric, s.r.o. - servis@abacus.cz Super Server/H12SSW-iN, BIOS 2.7 10/25/2023 Call Trace: <TASK> dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x30 __ubsan_handle_shift_out_of_bounds.cold+0x61/0xec __roundup_pow_of_two+0x25/0x35 [bnxt_re] bnxt_qplib_alloc_init_hwq+0xa1/0x470 [bnxt_re] bnxt_qplib_create_qp+0x19e/0x840 [bnxt_re] bnxt_re_create_qp+0x9b1/0xcd0 [bnxt_re] ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? __kmalloc+0x1b6/0x4f0 ? create_qp.part.0+0x128/0x1c0 [ib_core] ? __pfx_bnxt_re_create_qp+0x10/0x10 [bnxt_re] create_qp.part.0+0x128/0x1c0 [ib_core] ib_create_qp_kernel+0x50/0xd0 [ib_core] create_mad_qp+0x8e/0xe0 [ib_core] ? __pfx_qp_event_handler+0x10/0x10 [ib_core] ib_mad_init_device+0x2be/0x680 [ib_core] add_client_context+0x10d/0x1a0 [ib_core] enable_device_and_get+0xe0/0x1d0 [ib_core] ib_register_device+0x53c/0x630 [ib_core] ? srso_alias_return_thunk+0x5/0xfbef5 bnxt_re_probe+0xbd8/0xe50 [bnxt_re] ? __pfx_bnxt_re_probe+0x10/0x10 [bnxt_re] auxiliary_bus_probe+0x49/0x80 ? driver_sysfs_add+0x57/0xc0 really_probe+0xde/0x340 ? pm_runtime_barrier+0x54/0x90 ? __pfx___driver_attach+0x10/0x10 __driver_probe_device+0x78/0x110 driver_probe_device+0x1f/0xa0 __driver_attach+0xba/0x1c0 bus_for_each_dev+0x8f/0xe0 bus_add_driver+0x146/0x220 driver_register+0x72/0xd0 __auxiliary_driver_register+0x6e/0xd0 ? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re] bnxt_re_mod_init+0x3e/0xff0 [bnxt_re] ? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re] do_one_initcall+0x5b/0x310 do_init_module+0x90/0x250 init_module_from_file+0x86/0xc0 idempotent_init_module+0x121/0x2b0 __x64_sys_finit_module+0x5e/0xb0 do_syscall_64+0x82/0x160 ? srso_alias_return_thunk+0x5/0xfbef5 ? syscall_exit_to_user_mode_prepare+0x149/0x170 ? srso_alias_return_thunk+0x5/0xfbef5 ? syscall_exit_to_user_mode+0x75/0x230 ? srso_alias_return_thunk+0x5/0xfbef5 ? do_syscall_64+0x8e/0x160 ? srso_alias_return_thunk+0x5/0xfbef5 ? __count_memcg_events+0x69/0x100 ? srso_alias_return_thunk+0x5/0xfbef5 ? count_memcg_events.constprop.0+0x1a/0x30 ? srso_alias_return_thunk+0x5/0xfbef5 ? handle_mm_fault+0x1f0/0x300 ? srso_alias_return_thunk+0x5/0xfbef5 ? do_user_addr_fault+0x34e/0x640 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f4e5132821d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e3 db 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffca9c906a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 RAX: ffffffffffffffda RBX: 0000563ec8a8f130 RCX: 00007f4e5132821d RDX: 0000000000000000 RSI: 00007f4e518fa07d RDI: 000000000000003b RBP: 00007ffca9c90760 R08: 00007f4e513f6b20 R09: 00007ffca9c906f0 R10: 0000563ec8a8faa0 R11: 0000000000000246 R12: 00007f4e518fa07d R13: 0000000000020000 R14: 0000563ec8409e90 R15: 0000563ec8a8fa60 </TASK> ---[ end trace ]--- Fixes: 0c4dcd602817 ("RDMA/bnxt_re: Refactor hardware queue memory allocation") Signed-off-by: Michal Schmidt <mschmidt@redhat.com> Link: https://lore.kernel.org/r/20240507103929.30003-1-mschmidt@redhat.com Acked-by: Selvin Xavier <selvin.xavier@broadcom.com> Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30of: module: add buffer overflow check in of_modalias()Sergey Shtylyov1-3/+4
[ Upstream commit cf7385cb26ac4f0ee6c7385960525ad534323252 ] In of_modalias(), if the buffer happens to be too small even for the 1st snprintf() call, the len parameter will become negative and str parameter (if not NULL initially) will point beyond the buffer's end. Add the buffer overflow check after the 1st snprintf() call and fix such check after the strlen() call (accounting for the terminating NUL char). Fixes: bc575064d688 ("of/device: use of_property_for_each_string to parse compatible strings") Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru> Link: https://lore.kernel.org/r/bbfc6be0-c687-62b6-d015-5141b93f313e@omp.ru Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30clk: qcom: apss-ipq-pll: fix PLL rate for IPQ5018Gabor Juhos1-1/+2
[ Upstream commit c55f7ee2ec239b6afd8639c7ac06493876deb0ea ] According to ipq5018.dtsi, the maximum supported rate by the CPU is 1.008 GHz on the IPQ5018 platform, however the current configuration of the PLL results in 1.2 GHz rate. Change the 'L' value in the PLL configuration to limit the rate to 1.008 GHz. The downstream kernel also uses the same value [1]. Also add a comment to indicate the desired frequency. [1] https://git.codelinaro.org/clo/qsdk/oss/kernel/linux-ipq-5.4/-/blob/NHSS.QSDK.12.4/drivers/clk/qcom/apss-ipq5018.c?ref_type=heads#L151 Fixes: 50492f929486 ("clk: qcom: apss-ipq-pll: add support for IPQ5018") Signed-off-by: Gabor Juhos <j4g8y7@gmail.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20240326-fix-ipq5018-apss-pll-rate-v1-1-82ab31c9da7e@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30clk: qcom: Fix SM_GPUCC_8650 dependenciesNathan Chancellor1-0/+1
[ Upstream commit 07fb0a76bb757990b99fc2ab78ad7d1709cc441d ] CONFIG_SM_GCC_8650 depends on ARM64 but it is selected by CONFIG_SM_GPUCC_8650, which can be selected on ARM, resulting in a Kconfig warning. WARNING: unmet direct dependencies detected for SM_GCC_8650 Depends on [n]: COMMON_CLK [=y] && COMMON_CLK_QCOM [=y] && (ARM64 || COMPILE_TEST [=n]) Selected by [y]: - SM_GPUCC_8650 [=y] && COMMON_CLK [=y] && COMMON_CLK_QCOM [=y] Add the same dependencies to CONFIG_SM_GPUCC_8650 to resolve the warning. Fixes: 8676fd4f3874 ("clk: qcom: add the SM8650 GPU Clock Controller driver") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20240318-fix-some-qcom-kconfig-deps-v1-2-ea0773e3df5a@kernel.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30clk: qcom: Fix SC_CAMCC_8280XP dependenciesNathan Chancellor1-0/+1
[ Upstream commit e00f2540a581f8b8c165e5ae8afe52e4ad038550 ] CONFIG_SC_GCC_8280XP depends on ARM64 but it is selected by CONFIG_SC_CAMCC_8280XP, which can be selected on ARM, resulting in a Kconfig warning. WARNING: unmet direct dependencies detected for SC_GCC_8280XP Depends on [n]: COMMON_CLK [=y] && COMMON_CLK_QCOM [=y] && (ARM64 || COMPILE_TEST [=n]) Selected by [y]: - SC_CAMCC_8280XP [=y] && COMMON_CLK [=y] && COMMON_CLK_QCOM [=y] Add the same dependencies to CONFIG_SC_CAMCC_8280XP to resolve the warning. Fixes: ff93872a9c61 ("clk: qcom: camcc-sc8280xp: Add sc8280xp CAMCC") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20240318-fix-some-qcom-kconfig-deps-v1-1-ea0773e3df5a@kernel.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30drivers/virt/acrn: fix PFNMAP PTE checks in acrn_vm_ram_map()David Hildenbrand1-16/+47
[ Upstream commit 3d6586008f7b638f91f3332602592caa8b00b559 ] Patch series "mm: follow_pte() improvements and acrn follow_pte() fixes". Patch #1 fixes a bunch of issues I spotted in the acrn driver. It compiles, that's all I know. I'll appreciate some review and testing from acrn folks. Patch #2+#3 improve follow_pte(), passing a VMA instead of the MM, adding more sanity checks, and improving the documentation. Gave it a quick test on x86-64 using VM_PAT that ends up using follow_pte(). This patch (of 3): We currently miss handling various cases, resulting in a dangerous follow_pte() (previously follow_pfn()) usage. (1) We're not checking PTE write permissions. Maybe we should simply always require pte_write() like we do for pin_user_pages_fast(FOLL_WRITE)? Hard to tell, so let's check for ACRN_MEM_ACCESS_WRITE for now. (2) We're not rejecting refcounted pages. As we are not using MMU notifiers, messing with refcounted pages is dangerous and can result in use-after-free. Let's make sure to reject them. (3) We are only looking at the first PTE of a bigger range. We only lookup a single PTE, but memmap->len may span a larger area. Let's loop over all involved PTEs and make sure the PFN range is actually contiguous. Reject everything else: it couldn't have worked either way, and rather made use access PFNs we shouldn't be accessing. Link: https://lkml.kernel.org/r/20240410155527.474777-1-david@redhat.com Link: https://lkml.kernel.org/r/20240410155527.474777-2-david@redhat.com Fixes: 8a6e85f75a83 ("virt: acrn: obtain pa from VMA with PFNMAP flag") Signed-off-by: David Hildenbrand <david@redhat.com> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Fei Li <fei1.li@intel.com> Cc: Gerald Schaefer <gerald.schaefer@linux.ibm.com> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Yonghua Huang <yonghua.huang@intel.com> Cc: Sean Christopherson <seanjc@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30virt: acrn: stop using follow_pfnChristoph Hellwig1-2/+8
[ Upstream commit 1b265da7ea1e1ae997fa119c2846bb389eb39c6b ] Patch series "remove follow_pfn". This series open codes follow_pfn in the only remaining caller, although the code there remains questionable. It then also moves follow_phys into the only user and simplifies it a bit. This patch (of 3): Switch from follow_pfn to follow_pte so that we can get rid of follow_pfn. Note that this doesn't fix any of the pre-existing raciness and lack of permission checking in the code. Link: https://lkml.kernel.org/r/20240324234542.2038726-1-hch@lst.de Link: https://lkml.kernel.org/r/20240324234542.2038726-2-hch@lst.de Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: David Hildenbrand <david@redhat.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Fei Li <fei1.li@intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ingo Molnar <mingo@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Stable-dep-of: 3d6586008f7b ("drivers/virt/acrn: fix PFNMAP PTE checks in acrn_vm_ram_map()") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30RDMA/mana_ib: boundary check before installing cq callbacksKonstantin Taranov1-0/+2
[ Upstream commit f79edef79b6a2161f4124112f9b0c46891bb0b74 ] Add a boundary check inside mana_ib_install_cq_cb to prevent index overflow. Fixes: 2a31c5a7e0d8 ("RDMA/mana_ib: Introduce mana_ib_install_cq_cb helper function") Signed-off-by: Konstantin Taranov <kotaranov@microsoft.com> Link: https://lore.kernel.org/r/1714137160-5222-5-git-send-email-kotaranov@linux.microsoft.com Reviewed-by: Long Li <longli@microsoft.com> Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30RDMA/mana_ib: Use struct mana_ib_queue for CQsKonstantin Taranov3-58/+24
[ Upstream commit 60a7ac0b8bec5df9764b7460ffee91fc981e8a31 ] Use struct mana_ib_queue and its helpers for CQs Signed-off-by: Konstantin Taranov <kotaranov@microsoft.com> Link: https://lore.kernel.org/r/1711483688-24358-3-git-send-email-kotaranov@linux.microsoft.com Reviewed-by: Long Li <longli@microsoft.com> Signed-off-by: Leon Romanovsky <leon@kernel.org> Stable-dep-of: f79edef79b6a ("RDMA/mana_ib: boundary check before installing cq callbacks") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30RDMA/mana_ib: Introduce helpers to create and destroy mana queuesKonstantin Taranov2-0/+53
[ Upstream commit 46f5be7cd4bceb3a503c544b3dab7b75fe4bb96b ] Intoduce helpers to work with mana ib queues (struct mana_ib_queue). A queue always consists of umem, gdma_region, and id. A queue can become a WQ or a CQ. Signed-off-by: Konstantin Taranov <kotaranov@microsoft.com> Link: https://lore.kernel.org/r/1711483688-24358-2-git-send-email-kotaranov@linux.microsoft.com Reviewed-by: Long Li <longli@microsoft.com> Signed-off-by: Leon Romanovsky <leon@kernel.org> Stable-dep-of: f79edef79b6a ("RDMA/mana_ib: boundary check before installing cq callbacks") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30clk: qcom: mmcc-msm8998: fix venus clock issueMarc Gonzalez1-0/+8
[ Upstream commit e20ae5ae9f0c843aded4f06f3d1cab7384789e92 ] Right now, msm8998 video decoder (venus) is non-functional: $ time mpv --hwdec=v4l2m2m-copy --vd-lavc-software-fallback=no --vo=null --no-audio --untimed --length=30 --quiet demo-480.webm (+) Video --vid=1 (*) (vp9 854x480 29.970fps) Audio --aid=1 --alang=eng (*) (opus 2ch 48000Hz) [ffmpeg/video] vp9_v4l2m2m: output VIDIOC_REQBUFS failed: Connection timed out [ffmpeg/video] vp9_v4l2m2m: no v4l2 output context's buffers [ffmpeg/video] vp9_v4l2m2m: can't configure decoder Could not open codec. Software decoding fallback is disabled. Exiting... (Quit) Bryan O'Donoghue suggested the proper fix: - Set required register offsets in venus GDSC structs. - Set HW_CTRL flag. $ time mpv --hwdec=v4l2m2m-copy --vd-lavc-software-fallback=no --vo=null --no-audio --untimed --length=30 --quiet demo-480.webm (+) Video --vid=1 (*) (vp9 854x480 29.970fps) Audio --aid=1 --alang=eng (*) (opus 2ch 48000Hz) [ffmpeg/video] vp9_v4l2m2m: VIDIOC_G_FMT ioctl [ffmpeg/video] vp9_v4l2m2m: VIDIOC_G_FMT ioctl ... Using hardware decoding (v4l2m2m-copy). VO: [null] 854x480 nv12 Exiting... (End of file) real 0m3.315s user 0m1.277s sys 0m0.453s NOTES: GDSC = Globally Distributed Switch Controller Use same code as mmcc-msm8996 with: s/venus_gdsc/video_top_gdsc/ s/venus_core0_gdsc/video_subcore0_gdsc/ s/venus_core1_gdsc/video_subcore1_gdsc/ https://git.codelinaro.org/clo/la/kernel/msm-4.4/-/blob/caf_migration/kernel.lnx.4.4.r38-rel/include/dt-bindings/clock/msm-clocks-hwio-8996.h https://git.codelinaro.org/clo/la/kernel/msm-4.4/-/blob/caf_migration/kernel.lnx.4.4.r38-rel/include/dt-bindings/clock/msm-clocks-hwio-8998.h 0x1024 = MMSS_VIDEO GDSCR (undocumented) 0x1028 = MMSS_VIDEO_CORE_CBCR 0x1030 = MMSS_VIDEO_AHB_CBCR 0x1034 = MMSS_VIDEO_AXI_CBCR 0x1038 = MMSS_VIDEO_MAXI_CBCR 0x1040 = MMSS_VIDEO_SUBCORE0 GDSCR (undocumented) 0x1044 = MMSS_VIDEO_SUBCORE1 GDSCR (undocumented) 0x1048 = MMSS_VIDEO_SUBCORE0_CBCR 0x104c = MMSS_VIDEO_SUBCORE1_CBCR Fixes: d14b15b5931c2b ("clk: qcom: Add MSM8998 Multimedia Clock Controller (MMCC) driver") Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Marc Gonzalez <mgonzalez@freebox.fr> Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Link: https://lore.kernel.org/r/ff4e2e34-a677-4c39-8c29-83655c5512ae@freebox.fr Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30clk: qcom: dispcc-sm8650: fix DisplayPort clocksDmitry Baryshkov1-16/+4
[ Upstream commit 615a292ee4d51303246278f3fa33cc38700fe00e ] On SM8650 DisplayPort link clocks use frequency tables inherited from the vendor kernel, it is not applicable in the upstream kernel. Drop frequency tables and use clk_byte2_ops for those clocks. This fixes frequency selection in the OPP core (which otherwise attempts to use invalid 810 KHz as DP link rate), also fixing the following message: msm-dp-display af54000.displayport-controller: _opp_config_clk_single: failed to set clock rate: -22 Fixes: 9e939f008338 ("clk: qcom: add the SM8650 Display Clock Controller driver") Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-HDK Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20240424-dispcc-dp-clocks-v2-4-b44038f3fa96@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30clk: qcom: dispcc-sm8550: fix DisplayPort clocksDmitry Baryshkov1-16/+4
[ Upstream commit e90b5139da8465a15c3820b4b67ca9468dce93b4 ] On SM8550 DisplayPort link clocks use frequency tables inherited from the vendor kernel, it is not applicable in the upstream kernel. Drop frequency tables and use clk_byte2_ops for those clocks. This fixes frequency selection in the OPP core (which otherwise attempts to use invalid 810 KHz as DP link rate), also fixing the following message: msm-dp-display ae90000.displayport-controller: _opp_config_clk_single: failed to set clock rate: -22 Fixes: 90114ca11476 ("clk: qcom: add SM8550 DISPCC driver") Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-HDK Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20240424-dispcc-dp-clocks-v2-3-b44038f3fa96@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30clk: qcom: dispcc-sm6350: fix DisplayPort clocksDmitry Baryshkov1-10/+1
[ Upstream commit 1113501cfb46d5c0eb960f0a8a9f6c0f91dc6fb6 ] On SM6350 DisplayPort link clocks use frequency tables inherited from the vendor kernel, it is not applicable in the upstream kernel. Drop frequency tables and use clk_byte2_ops for those clocks. This fixes frequency selection in the OPP core (which otherwise attempts to use invalid 810 KHz as DP link rate), also fixing the following message: msm-dp-display ae90000.displayport-controller: _opp_config_clk_single: failed to set clock rate: -22 Fixes: 837519775f1d ("clk: qcom: Add display clock controller driver for SM6350") Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Tested-by: Luca Weiss <luca.weiss@fairphone.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20240424-dispcc-dp-clocks-v2-2-b44038f3fa96@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30clk: qcom: dispcc-sm8450: fix DisplayPort clocksDmitry Baryshkov1-16/+4
[ Upstream commit e801038a02ce1e8c652a0b668dd233a4ee48aeb7 ] On SM8450 DisplayPort link clocks use frequency tables inherited from the vendor kernel, it is not applicable in the upstream kernel. Drop frequency tables and use clk_byte2_ops for those clocks. This fixes frequency selection in the OPP core (which otherwise attempts to use invalid 810 KHz as DP link rate), also fixing the following message: msm-dp-display ae90000.displayport-controller: _opp_config_clk_single: failed to set clock rate: -22 Fixes: 16fb89f92ec4 ("clk: qcom: Add support for Display Clock Controller on SM8450") Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20240424-dispcc-dp-clocks-v2-1-b44038f3fa96@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30clk: renesas: r9a07g043: Add clock and reset entry for PLICLad Prabhakar1-0/+9
[ Upstream commit 44019387fce230beda35b83da3a2c9fc5787704e ] Add the missing clock and reset entry for PLIC. Also add R9A07G043_NCEPLIC_ACLK to the critical clocks list. Fixes: 95d48d270305ad2c ("clk: renesas: r9a07g043: Add support for RZ/Five SoC") Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20240403200952.633084-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30clk: renesas: r8a779a0: Fix CANFD parent clockGeert Uytterhoeven1-1/+1
[ Upstream commit 3b23118bdbd898dc2f4de8f549d598d492c42ba8 ] According to Figure 52A.1 ("RS-CANFD Module Block Diagram (in classical CAN mode)") in the R-Car V3U Series User’s Manual Rev. 0.5, the parent clock for the CANFD peripheral module clock is the S3D2 clock. Fixes: 9b621b6adff53346 ("clk: renesas: r8a779a0: Add CANFD module clock") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/aef9300f44c9141b1465343f91c5cc7303249b6e.1713279523.git.geert+renesas@glider.be Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30IB/mlx5: Use __iowrite64_copy() for write combining storesJason Gunthorpe1-5/+3
[ Upstream commit ef302283ddfceaba2657923af3f90fd58e6dff06 ] mlx5 has a built in self-test at driver startup to evaluate if the platform supports write combining to generate a 64 byte PCIe TLP or not. This has proven necessary because a lot of common scenarios end up with broken write combining (especially inside virtual machines) and there is other way to learn this information. This self test has been consistently failing on new ARM64 CPU designs (specifically with NVIDIA Grace's implementation of Neoverse V2). The C loop around writeq() generates some pretty terrible ARM64 assembly, but historically this has worked on a lot of existing ARM64 CPUs till now. We see it succeed about 1 time in 10,000 on the worst effected systems. The CPU architects speculate that the load instructions interspersed with the stores makes the WC buffers statistically flush too often and thus the generation of large TLPs becomes infrequent. This makes the boot up test unreliable in that it indicates no write-combining, however userspace would be fine since it uses a ST4 instruction. Further, S390 has similar issues where only the special zpci_memcpy_toio() will actually generate large TLPs, and the open coded loop does not trigger it at all. Fix both ARM64 and S390 by switching to __iowrite64_copy() which now provides architecture specific variants that have a high change of generating a large TLP with write combining. x86 continues to use a similar writeq loop in the generate __iowrite64_copy(). Fixes: 11f552e21755 ("IB/mlx5: Test write combining support") Link: https://lore.kernel.org/r/6-v3-1893cd8b9369+1925-mlx5_arm_wc_jgg@nvidia.com Tested-by: Niklas Schnelle <schnelle@linux.ibm.com> Acked-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30RDMA/rxe: Fix incorrect rxe_put in error pathBob Pearson1-10/+2
[ Upstream commit 8776618dbbd1b6f210b31509507e1aad461d6435 ] In rxe_send() a ref is taken on the qp to keep it alive until the kfree_skb() has a chance to call the skb destructor rxe_skb_tx_dtor() which drops the reference. If the packet has an incorrect protocol the error path just calls kfree_skb() which will call the destructor which will drop the ref. Currently the driver also calls rxe_put() which is incorrect. Additionally since the packets sent to rxe_send() are under the control of the driver and it only ever produces IPV4 or IPV6 packets the simplest fix is to remove all the code in this block. Link: https://lore.kernel.org/r/20240329145513.35381-12-rpearsonhpe@gmail.com Signed-off-by: Bob Pearson <rpearsonhpe@gmail.com> Fixes: 9eb7f8e44d13 ("IB/rxe: Move refcounting earlier in rxe_send()") Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30RDMA/rxe: Allow good work requests to be executedBob Pearson1-1/+5
[ Upstream commit b703374837a8f8422fa3f1edcf65505421a65a6a ] A previous commit incorrectly added an 'if(!err)' before scheduling the requester task in rxe_post_send_kernel(). But if there were send wrs successfully added to the send queue before a bad wr they might never get executed. This commit fixes this by scheduling the requester task if any wqes were successfully posted in rxe_post_send_kernel() in rxe_verbs.c. Link: https://lore.kernel.org/r/20240329145513.35381-5-rpearsonhpe@gmail.com Signed-off-by: Bob Pearson <rpearsonhpe@gmail.com> Fixes: 5bf944f24129 ("RDMA/rxe: Add error messages") Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30RDMA/rxe: Fix seg fault in rxe_comp_queue_pktBob Pearson1-3/+3
[ Upstream commit 2b23b6097303ed0ba5f4bc036a1c07b6027af5c6 ] In rxe_comp_queue_pkt() an incoming response packet skb is enqueued to the resp_pkts queue and then a decision is made whether to run the completer task inline or schedule it. Finally the skb is dereferenced to bump a 'hw' performance counter. This is wrong because if the completer task is already running in a separate thread it may have already processed the skb and freed it which can cause a seg fault. This has been observed infrequently in testing at high scale. This patch fixes this by changing the order of enqueuing the packet until after the counter is accessed. Link: https://lore.kernel.org/r/20240329145513.35381-4-rpearsonhpe@gmail.com Signed-off-by: Bob Pearson <rpearsonhpe@gmail.com> Fixes: 0b1e5b99a48b ("IB/rxe: Add port protocol stats") Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30clk: qcom: clk-alpha-pll: remove invalid Stromer register offsetGabor Juhos1-1/+0
[ Upstream commit 4f2bc4acbb1916b8cd2ce4bb3ba7b1cd7cb705fa ] The offset of the CONFIG_CTL_U register defined for the Stromer PLL is wrong. It is not aligned on a 4 bytes boundary which might causes errors in regmap operations. Maybe the intention behind of using the 0xff value was to indicate that the register is not implemented in the PLL, but this is not verified anywhere in the code. Moreover, this value is not used even in other register offset arrays despite that those PLLs also have unimplemented registers. Additionally, on the Stromer PLLs the current code only touches the CONFIG_CTL_U register if the result of pll_has_64bit_config() is true which condition is not affected by the change. Due to the reasons above, simply remove the CONFIG_CTL_U entry from the Stromer specific array. Fixes: e47a4f55f240 ("clk: qcom: clk-alpha-pll: Add support for Stromer PLLs") Signed-off-by: Gabor Juhos <j4g8y7@gmail.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20240311-alpha-pll-stromer-cleanup-v1-1-f7c0c5607cca@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30clk: rs9: fix wrong default value for clock amplitudeCatalin Popescu1-4/+6
[ Upstream commit 1758c68c81b8b881818fcebaaeb91055362a82f8 ] According to 9FGV0241, 9FGV0441 & 9FGV0841 datasheets, the default value for the clock amplitude is 0.8V, while the driver assumes 0.7V. Additionally, define constants for default values for both clock amplitude and spread spectrum and use them. Fixes: 892e0ddea1aa ("clk: rs9: Add Renesas 9-series PCIe clock generator driver") Signed-off-by: Catalin Popescu <catalin.popescu@leica-geosystems.com> Reviewed-by: Marek Vasut <marex@denx.de> Link: https://lore.kernel.org/r/20240415140348.2887619-1-catalin.popescu@leica-geosystems.com Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30clk: mediatek: mt8365-mm: fix DPI0 parentAlexandre Mergnat1-1/+1
[ Upstream commit 4c0c087772d7e29bc2489ddb068d5167140bfc38 ] To have a working display through DPI, a workaround has been implemented downstream to add "mm_dpi0_dpi0" and "dpi0_sel" to the DPI node. Shortly, that add an extra clock. It seems consistent to have the "dpi0_sel" as parent. Additionnaly, "vpll_dpix" isn't used/managed. Then, set the "mm_dpi0_dpi0" parent clock to "dpi0_sel". The new clock tree is: clk26m lvdspll lvdspll_X (2, 4, 8, 16) dpi0_sel mm_dpi0_dpi0 Fixes: d46adccb7966 ("clk: mediatek: add driver for MT8365 SoC") Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com> Link: https://lore.kernel.org/r/20231023-display-support-v3-12-53388f3ed34b@baylibre.com Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30RDMA/hns: Modify the print level of CQE errorChengchang Tang1-2/+3
[ Upstream commit 349e859952285ab9689779fb46de163f13f18f43 ] Too much print may lead to a panic in kernel. Change ibdev_err() to ibdev_err_ratelimited(), and change the printing level of cqe dump to debug level. Fixes: 7c044adca272 ("RDMA/hns: Simplify the cqe code of poll cq") Signed-off-by: Chengchang Tang <tangchengchang@huawei.com> Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com> Link: https://lore.kernel.org/r/20240412091616.370789-11-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30RDMA/hns: Use complete parentheses in macrosChengchang Tang1-6/+6
[ Upstream commit 4125269bb9b22e1d8cdf4412c81be8074dbc61ca ] Use complete parentheses to ensure that macro expansion does not produce unexpected results. Fixes: a25d13cbe816 ("RDMA/hns: Add the interfaces to support multi hop addressing for the contexts in hip08") Signed-off-by: Chengchang Tang <tangchengchang@huawei.com> Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com> Link: https://lore.kernel.org/r/20240412091616.370789-10-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30RDMA/hns: Fix GMV table pagesizeChengchang Tang1-1/+1
[ Upstream commit ee045493283403969591087bd405fa280103282a ] GMV's BA table only supports 4K pages. Currently, PAGESIZE is used to calculate gmv_bt_num, which will cause an abnormal number of gmv_bt_num in a 64K OS. Fixes: d6d91e46210f ("RDMA/hns: Add support for configuring GMV table") Signed-off-by: Chengchang Tang <tangchengchang@huawei.com> Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com> Link: https://lore.kernel.org/r/20240412091616.370789-8-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30RDMA/hns: Fix UAF for cq async eventChengchang Tang1-11/+13
[ Upstream commit a942ec2745ca864cd8512142100e4027dc306a42 ] The refcount of CQ is not protected by locks. When CQ asynchronous events and CQ destruction are concurrent, CQ may have been released, which will cause UAF. Use the xa_lock() to protect the CQ refcount. Fixes: 9a4435375cd1 ("IB/hns: Add driver files for hns RoCE driver") Signed-off-by: Chengchang Tang <tangchengchang@huawei.com> Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com> Link: https://lore.kernel.org/r/20240412091616.370789-6-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30RDMA/hns: Fix deadlock on SRQ async events.Chengchang Tang2-3/+4
[ Upstream commit b46494b6f9c19f141114a57729e198698f40af37 ] xa_lock for SRQ table may be required in AEQ. Use xa_store_irq()/ xa_erase_irq() to avoid deadlock. Fixes: 81fce6291d99 ("RDMA/hns: Add SRQ asynchronous event support") Signed-off-by: Chengchang Tang <tangchengchang@huawei.com> Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com> Link: https://lore.kernel.org/r/20240412091616.370789-5-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30RDMA/hns: Fix return value in hns_roce_map_mr_sgZhengchao Shao1-8/+7
[ Upstream commit 203b70fda63425a4eb29f03f9074859afe821a39 ] As described in the ib_map_mr_sg function comment, it returns the number of sg elements that were mapped to the memory region. However, hns_roce_map_mr_sg returns the number of pages required for mapping the DMA area. Fix it. Fixes: 9b2cf76c9f05 ("RDMA/hns: Optimize PBL buffer allocation process") Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com> Link: https://lore.kernel.org/r/20240411033851.2884771-1-shaozhengchao@huawei.com Reviewed-by: Junxian Huang <huangjunxian6@hisilicon.com> Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30iommu: Undo pasid attachment only for the devices that have succeededYi Liu1-6/+15
[ Upstream commit b025dea63cded0d82bccd591fa105d39efc6435d ] There is no error handling now in __iommu_set_group_pasid(), it relies on its caller to loop all the devices to undo the pasid attachment. This is not self-contained and has drawbacks. It would result in unnecessary remove_dev_pasid() calls on the devices that have not been attached to the new domain. But the remove_dev_pasid() callback would get the new domain from the group->pasid_array. So for such devices, the iommu driver won't find the attachment under the domain, hence unable to do cleanup. This may not be a real problem today. But it depends on the implementation of the underlying iommu driver. e.g. the intel iommu driver would warn for such devices. Such warnings are unnecessary. To solve the above problem, it is necessary to handle the error within __iommu_set_group_pasid(). It only loops the devices that have attached to the new domain, and undo it. Fixes: 16603704559c ("iommu: Add attach/detach_dev_pasid iommu interfaces") Suggested-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Yi Liu <yi.l.liu@intel.com> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/20240328122958.83332-2-yi.l.liu@intel.com Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30clk: mediatek: pllfh: Don't log error for missing fhctl nodeNícolas F. R. A. Prado1-1/+1
[ Upstream commit bb7b3c8e7180f36de75cdea200ab7127f93f58cc ] Support for fhctl clocks in apmixedsys was introduced at a later point and to this moment only one mt6795 based platform has a fhctl DT node present. Therefore the fhctl support in apmixedsys should be seen as optional and not cause an error when it is missing. Change the message's log level to warning. The warning level is chosen so that it will still alert the fact that fhctl support might be unintentionally missing, but without implying that this is necessarily an issue. Even if the FHCTL DT nodes are added to all current platforms moving forward, since those changes won't be backported, this ensures stable kernel releases won't have live with this error. Fixes: d7964de8a8ea ("clk: mediatek: Add new clock driver to handle FHCTL hardware") Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Link: https://lore.kernel.org/r/20240308-mtk-fhctl-no-node-error-v1-1-51e446eb149a@collabora.com Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30RDMA/mlx5: Adding remote atomic access flag to updatable flagsOr Har-Toov1-1/+2
[ Upstream commit 2ca7e93bc963d9ec2f5c24d117176851454967af ] Currently IB_ACCESS_REMOTE_ATOMIC is blocked from being updated via UMR although in some cases it should be possible. These cases are checked in mlx5r_umr_can_reconfig function. Fixes: ef3642c4f54d ("RDMA/mlx5: Fix error unwinds for rereg_mr") Signed-off-by: Or Har-Toov <ohartoov@nvidia.com> Link: https://lore.kernel.org/r/24dac73e2fa48cb806f33a932d97f3e402a5ea2c.1712140377.git.leon@kernel.org Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30RDMA/mlx5: Change check for cacheable mkeysOr Har-Toov2-10/+23
[ Upstream commit 8c1185fef68cc603b954fece2a434c9f851d6a86 ] umem can be NULL for user application mkeys in some cases. Therefore umem can't be used for checking if the mkey is cacheable and it is changed for checking a flag that indicates it. Also make sure that all mkeys which are not returned to the cache will be destroyed. Fixes: dd1b913fb0d0 ("RDMA/mlx5: Cache all user cacheable mkeys on dereg MR flow") Signed-off-by: Or Har-Toov <ohartoov@nvidia.com> Link: https://lore.kernel.org/r/2690bc5c6896bcb937f89af16a1ff0343a7ab3d0.1712140377.git.leon@kernel.org Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30RDMA/mlx5: Uncacheable mkey has neither rb_key or cache_entOr Har-Toov1-1/+1
[ Upstream commit 0611a8e8b475fc5230b9a24d29c8397aaab20b63 ] As some mkeys can't be modified with UMR due to some UMR limitations, like the size of translation that can be updated, not all user mkeys can be cached. Fixes: dd1b913fb0d0 ("RDMA/mlx5: Cache all user cacheable mkeys on dereg MR flow") Signed-off-by: Or Har-Toov <ohartoov@nvidia.com> Link: https://lore.kernel.org/r/f2742dd934ed73b2d32c66afb8e91b823063880c.1712140377.git.leon@kernel.org Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30clk: samsung: exynosautov9: fix wrong pll clock id valueJaewon Kim1-4/+4
[ Upstream commit 04ee3a0b44e3d18cf6b0c712d14b98624877fd26 ] All PLL id values of CMU_TOP were incorrectly set to FOUT_SHARED0_PLL. It modified to the correct PLL clock id value. Fixes: 6587c62f69dc ("clk: samsung: add top clock support for Exynos Auto v9 SoC") Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com> Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Link: https://lore.kernel.org/r/20240328091000.17660-1-jaewon02.kim@samsung.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30media: cadence: csi2rx: configure DPHY before starting source streamPratyush Yadav1-12/+14
[ Upstream commit fd64dda48f7e3f67ada1e1fe47e784ab350da72e ] When the source device is operating above 1.5 Gbps per lane, it needs to send the Skew Calibration Sequence before sending any HS data. If the DPHY is initialized after the source stream is started, then it might miss the sequence and not be able to receive data properly. Move the start of source subdev to the end of the sequence to make sure everything is ready to receive data before the source starts streaming. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Fixes: 3295cf1241d3 ("media: cadence: Add support for external dphy") Tested-by: Julien Massot <julien.massot@collabora.com> Tested-by: Changhuang Liang <Changhuang.liang@starfivetech.com> Reviewed-by: Julien Massot <julien.massot@collabora.com> Reviewed-by: Changhuang Liang <Changhuang.liang@starfivetech.com> Signed-off-by: Jai Luthra <j-luthra@ti.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30drm/edid: Parse topology block for all DispID structure v1.xVille Syrjälä1-1/+1
[ Upstream commit e0a200ab4b72afd581bd6f82fc1ef510a4fb5478 ] DisplayID spec v1.3 revision history notes do claim that the toplogy block was added in v1.3 so requiring structure v1.2 would seem correct, but there is at least one EDID in edid.tv with a topology block and structure v1.0. And there are also EDIDs with DisplayID structure v1.3 which seems to be totally incorrect as DisplayID spec v1.3 lists structure v1.2 as the only legal value. Unfortunately I couldn't find copies of DisplayID spec v1.0-v1.2 anywhere (even on vesa.org), so I'll have to go on empirical evidence alone. We used to parse the topology block on all v1.x structures until the check for structure v2.0 was added. Let's go back to doing that as the evidence does suggest that there are DisplayIDs in the wild that would miss out on the topology stuff otherwise. Also toss out DISPLAY_ID_STRUCTURE_VER_12 entirely as it doesn't appear we can really use it for anything. I *think* we could technically skip all the structure version checks as the block tags shouldn't conflict between v2.0 and v1.x. But no harm in having a bit of extra sanity checks I guess. So far I'm not aware of any user reported regressions from overly strict check, but I do know that it broke igt/kms_tiled_display's fake DisplayID as that one gets generated with structure v1.0. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> Fixes: c5a486af9df7 ("drm/edid: parse Tiled Display Topology Data Block for DisplayID 2.0") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240410180139.21352-1-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-30drm/rockchip: vop2: Do not divide height twice for YUVDetlev Casanova1-10/+12
[ Upstream commit e80c219f52861e756181d7f88b0d341116daac2b ] For the cbcr format, gt2 and gt4 are computed again after src_h has been divided by vsub. As src_h as already been divided by 2 before, introduce cbcr_src_h and cbcr_src_w to keep a copy of those values to be used for cbcr gt2 and gt4 computation. This fixes yuv planes being unaligned vertically when down scaling to 1080 pixels from 2160. Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com> Fixes: 604be85547ce ("drm/rockchip: Add VOP2 driver") Acked-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240414182706.655270-1-detlev.casanova@collabora.com Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-08-15 00:28:26 +0300