summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2022-08-25scsi: ufs: ufs-mediatek: Fix build error and type mismatchRen Zhijie1-0/+2
commit f54912b228a8df6c0133e31bc75628677bb8c6e5 upstream. If CONFIG_PM_SLEEP is not set. make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-, will fail: drivers/ufs/host/ufs-mediatek.c: In function ‘ufs_mtk_vreg_fix_vcc’: drivers/ufs/host/ufs-mediatek.c:688:46: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 4 has type ‘long unsigned int’ [-Wformat=] snprintf(vcc_name, MAX_VCC_NAME, "vcc-opt%u", res.a1); ~^ ~~~~~~ %lu drivers/ufs/host/ufs-mediatek.c: In function ‘ufs_mtk_system_suspend’: drivers/ufs/host/ufs-mediatek.c:1371:8: error: implicit declaration of function ‘ufshcd_system_suspend’; did you mean ‘ufs_mtk_system_suspend’? [-Werror=implicit-function-declaration] ret = ufshcd_system_suspend(dev); ^~~~~~~~~~~~~~~~~~~~~ ufs_mtk_system_suspend drivers/ufs/host/ufs-mediatek.c: In function ‘ufs_mtk_system_resume’: drivers/ufs/host/ufs-mediatek.c:1386:9: error: implicit declaration of function ‘ufshcd_system_resume’; did you mean ‘ufs_mtk_system_resume’? [-Werror=implicit-function-declaration] return ufshcd_system_resume(dev); ^~~~~~~~~~~~~~~~~~~~ ufs_mtk_system_resume cc1: some warnings being treated as errors The declaration of func "ufshcd_system_suspend()" depends on CONFIG_PM_SLEEP, so the function wrapper ufs_mtk_system_suspend() should wrapped by CONFIG_PM_SLEEP too. Link: https://lore.kernel.org/r/20220619115432.205504-1-renzhijie2@huawei.com Fixes: 3fd23b8dfb54 ("scsi: ufs: ufs-mediatek: Fix the timing of configuring device regulators") Reported-by: Hulk Robot <hulkci@huawei.com> Reviewed-by: Stanley Chu <stanley.chu@mediatek.com> Signed-off-by: Ren Zhijie <renzhijie2@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> [only take the suspend/resume portion of the commit - gregkh] Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-08-25video: fbdev: i740fb: Check the argument of i740_calc_vclk()Zheyu Ma1-2/+7
[ Upstream commit 40bf722f8064f50200b8c4f8946cd625b441dda9 ] Since the user can control the arguments of the ioctl() from the user space, under special arguments that may result in a divide-by-zero bug. If the user provides an improper 'pixclock' value that makes the argumet of i740_calc_vclk() less than 'I740_RFREQ_FIX', it will cause a divide-by-zero bug in: drivers/video/fbdev/i740fb.c:353 p_best = min(15, ilog2(I740_MAX_VCO_FREQ / (freq / I740_RFREQ_FIX))); The following log can reveal it: divide error: 0000 [#1] PREEMPT SMP KASAN PTI RIP: 0010:i740_calc_vclk drivers/video/fbdev/i740fb.c:353 [inline] RIP: 0010:i740fb_decode_var drivers/video/fbdev/i740fb.c:646 [inline] RIP: 0010:i740fb_set_par+0x163f/0x3b70 drivers/video/fbdev/i740fb.c:742 Call Trace: fb_set_var+0x604/0xeb0 drivers/video/fbdev/core/fbmem.c:1034 do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1110 fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1189 Fix this by checking the argument of i740_calc_vclk() first. Signed-off-by: Zheyu Ma <zheyuma97@gmail.com> Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25venus: pm_helpers: Fix warning in OPP during probeStanimir Varbanov1-5/+5
[ Upstream commit 1d95af02f23031c2e1cca7607c514b86ce85bc6e ] Fix the following WARN triggered during Venus driver probe on 5.19.0-rc8-next-20220728: WARNING: CPU: 7 PID: 339 at drivers/opp/core.c:2471 dev_pm_opp_set_config+0x49c/0x610 Modules linked in: qcom_spmi_adc5 rtc_pm8xxx qcom_spmi_adc_tm5 leds_qcom_lpg led_class_multicolor qcom_pon qcom_vadc_common venus_core(+) qcom_spmi_temp_alarm v4l2_mem2mem videobuf2_v4l2 msm(+) videobuf2_common crct10dif_ce spi_geni_qcom snd_soc_sm8250 i2c_qcom_geni gpu_sched snd_soc_qcom_common videodev qcom_q6v5_pas soundwire_qcom drm_dp_aux_bus qcom_stats drm_display_helper qcom_pil_info soundwire_bus snd_soc_lpass_va_macro mc qcom_q6v5 phy_qcom_snps_femto_v2 qcom_rng snd_soc_lpass_macro_common snd_soc_lpass_wsa_macro lpass_gfm_sm8250 slimbus qcom_sysmon qcom_common qcom_glink_smem qmi_helpers qcom_wdt mdt_loader socinfo icc_osm_l3 display_connector drm_kms_helper qnoc_sm8250 drm fuse ip_tables x_tables ipv6 CPU: 7 PID: 339 Comm: systemd-udevd Not tainted 5.19.0-rc8-next-20220728 #4 Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : dev_pm_opp_set_config+0x49c/0x610 lr : dev_pm_opp_set_config+0x58/0x610 sp : ffff8000093c3710 x29: ffff8000093c3710 x28: ffffbca3959d82b8 x27: ffff8000093c3d00 x26: ffffbca3959d8e08 x25: ffff4396cac98118 x24: ffff4396c0e24810 x23: ffff4396c4272c40 x22: ffff4396c0e24810 x21: ffff8000093c3810 x20: ffff4396cac36800 x19: ffff4396cac96800 x18: 0000000000000000 x17: 0000000000000003 x16: ffffbca3f4edf198 x15: 0000001cba64a858 x14: 0000000000000180 x13: 000000000000017e x12: 0000000000000000 x11: 0000000000000002 x10: 0000000000000a60 x9 : ffff8000093c35c0 x8 : ffff4396c4273700 x7 : ffff43983efca6c0 x6 : ffff43983efca640 x5 : 00000000410fd0d0 x4 : ffff4396c4272c40 x3 : ffffbca3f5d1e008 x2 : 0000000000000000 x1 : ffff4396c2421600 x0 : ffff4396cac96860 Call trace: dev_pm_opp_set_config+0x49c/0x610 devm_pm_opp_set_config+0x18/0x70 vcodec_domains_get+0xb8/0x1638 [venus_core] core_get_v4+0x1d8/0x218 [venus_core] venus_probe+0xf4/0x468 [venus_core] platform_probe+0x68/0xd8 really_probe+0xbc/0x2a8 __driver_probe_device+0x78/0xe0 driver_probe_device+0x3c/0xf0 __driver_attach+0x70/0x120 bus_for_each_dev+0x70/0xc0 driver_attach+0x24/0x30 bus_add_driver+0x150/0x200 driver_register+0x64/0x120 __platform_driver_register+0x28/0x38 qcom_venus_driver_init+0x24/0x1000 [venus_core] do_one_initcall+0x54/0x1c8 do_init_module+0x44/0x1d0 load_module+0x16c8/0x1aa0 __do_sys_finit_module+0xbc/0x110 __arm64_sys_finit_module+0x20/0x30 invoke_syscall+0x44/0x108 el0_svc_common.constprop.0+0xcc/0xf0 do_el0_svc+0x2c/0xb8 el0_svc+0x2c/0x88 el0t_64_sync_handler+0xb8/0xc0 el0t_64_sync+0x18c/0x190 qcom-venus: probe of aa00000.video-codec failed with error -16 The fix is re-ordering the code related to OPP core. The OPP core expects all configuration options to be provided before the OPP table is added. Reported-by: Linux Kernel Functional Testing <lkft@linaro.org> Suggested-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25iommu/io-pgtable-arm-v7s: Add a quirk to allow pgtable PA up to 35bitYunfei Wang1-19/+56
[ Upstream commit bfdd231374181254742c5e2faef0bef2d30c0ee4 ] Single memory zone feature will remove ZONE_DMA32 and ZONE_DMA and cause pgtable PA size larger than 32bit. Since Mediatek IOMMU hardware support at most 35bit PA in pgtable, so add a quirk to allow the PA of pgtables support up to bit35. Signed-off-by: Ning Li <ning.li@mediatek.com> Signed-off-by: Yunfei Wang <yf.wang@mediatek.com> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20220630092927.24925-2-yf.wang@mediatek.com Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25vfio: Clear the caps->buf to NULL after freeSchspa Shi1-0/+1
[ Upstream commit 6641085e8d7b3f061911517f79a2a15a0a21b97b ] On buffer resize failure, vfio_info_cap_add() will free the buffer, report zero for the size, and return -ENOMEM. As additional hardening, also clear the buffer pointer to prevent any chance of a double free. Signed-off-by: Schspa Shi <schspa@gmail.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Link: https://lore.kernel.org/r/20220629022948.55608-1-schspa@gmail.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25tty: serial: Fix refcount leak bug in ucc_uart.cLiang He1-0/+2
[ Upstream commit d24d7bb2cd947676f9b71fb944d045e09b8b282f ] In soc_info(), of_find_node_by_type() will return a node pointer with refcount incremented. We should use of_node_put() when it is not used anymore. Acked-by: Timur Tabi <timur@kernel.org> Signed-off-by: Liang He <windhl@126.com> Link: https://lore.kernel.org/r/20220618060850.4058525-1-windhl@126.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25drivers:md:fix a potential use-after-free bugWentao_Liang1-1/+1
[ Upstream commit 104212471b1c1817b311771d817fb692af983173 ] In line 2884, "raid5_release_stripe(sh);" drops the reference to sh and may cause sh to be released. However, sh is subsequently used in lines 2886 "if (sh->batch_head && sh != sh->batch_head)". This may result in an use-after-free bug. It can be fixed by moving "raid5_release_stripe(sh);" to the bottom of the function. Signed-off-by: Wentao_Liang <Wentao_Liang_g@163.com> Signed-off-by: Song Liu <song@kernel.org> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25nvmet-tcp: fix lockdep complaint on nvmet_tcp_wq flush during queue teardownSagi Grimberg1-1/+2
[ Upstream commit 533d2e8b4d5e4c89772a0adce913525fb86cbbee ] We probably need nvmet_tcp_wq to have MEM_RECLAIM as we are sending/receiving for the socket from works on this workqueue. Also this eliminates lockdep complaints: -- [ 6174.010200] workqueue: WQ_MEM_RECLAIM nvmet-wq:nvmet_tcp_release_queue_work [nvmet_tcp] is flushing !WQ_MEM_RECLAIM nvmet_tcp_wq:nvmet_tcp_io_work [nvmet_tcp] [ 6174.010216] WARNING: CPU: 20 PID: 14456 at kernel/workqueue.c:2628 check_flush_dependency+0x110/0x14c Reported-by: Yi Zhang <yi.zhang@redhat.com> Signed-off-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25md/raid5: Make logic blocking check consistent with logic that blocksLogan Gunthorpe1-1/+1
[ Upstream commit 6e3f50d30af847bebce072182bd735e90a294c6a ] The check in raid5_make_request differs very slightly from the logic that causes it to block lower down. This likely does not cause a bug as the check is fuzzy anyway (as reshape may move on between the first check and the subsequent check). However, make it consistent so it can be cleaned up in a subsequent patch. The condition which causes the schedule is: !(mddev->reshape_backwards ? logical_sector < conf->reshape_progress : logical_sector >= conf->reshape_progress) && (mddev->reshape_backwards ? logical_sector < conf->reshape_safe : logical_sector >= conf->reshape_safe) The condition that causes the early bailout is made to match this. Signed-off-by: Logan Gunthorpe <logang@deltatee.com> Signed-off-by: Song Liu <song@kernel.org> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25md: Notify sysfs sync_completed in md_reap_sync_thread()Logan Gunthorpe1-0/+1
[ Upstream commit 9973f0fa7d20269fe6fefe6333997fb5914449c1 ] The mdadm test 07layouts randomly produces a kernel hung task deadlock. The deadlock is caused by the suspend_lo/suspend_hi files being set by the mdadm background process during reshape and not being cleared because the process hangs. (Leaving aside the issue of the fragility of freezing kernel tasks by buggy userspace processes...) When the background mdadm process hangs it, is waiting (without a timeout) on a change to the sync_completed file signalling that the reshape has completed. The process is woken up a couple times when the reshape finishes but it is woken up before MD_RECOVERY_RUNNING is cleared so sync_completed_show() reports 0 instead of "none". To fix this, notify the sysfs file in md_reap_sync_thread() after MD_RECOVERY_RUNNING has been cleared. This wakes up mdadm and causes it to continue and write to suspend_lo/suspend_hi to allow IO to continue. Signed-off-by: Logan Gunthorpe <logang@deltatee.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Song Liu <song@kernel.org> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25phy: samsung: phy-exynos-pcie: sanitize init/power_on callbacksMarek Szyprowski1-16/+9
[ Upstream commit f2812227bb07e2eaee74253f11cea1576945df31 ] The exynos-pcie driver called phy_power_on() before phy_init() for some historical reasons. However the generic PHY framework assumes that the proper sequence is to call phy_init() first, then phy_power_on(). The operations done by both functions should be considered as one action and as such they are called by the exynos-pcie driver (without doing anything between them). The initialization is just a sequence of register writes, which cannot be altered without breaking the hardware operation. To match the generic PHY framework requirement, simply move all register writes to the phy_init()/phy_exit() and drop power_on()/power_off() callbacks. This way the driver will also work with the old (incorrect) PHY initialization call sequence. Link: https://lore.kernel.org/r/20220628220409.26545-1-m.szyprowski@samsung.com Reported-by: Bjorn Helgaas <helgaas@kernel.org> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Chanho Park <chanho61.park@samsung.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-By: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25Revert "RDMA/rxe: Create duplicate mapping tables for FMRs"Li Zhijian5-162/+104
[ Upstream commit 1e75550648da1fa1cd1969e7597355de8fe8caf6 ] Below 2 commits will be reverted: commit 8ff5f5d9d8cf ("RDMA/rxe: Prevent double freeing rxe_map_set()") commit 647bf13ce944 ("RDMA/rxe: Create duplicate mapping tables for FMRs") The community has a few bug reports which pointed this commit at last. Some proposals are raised up in the meantime but all of them have no follow-up operation. The previous commit led the map_set of FMR to be not available any more if the MR is registered again after invalidating. Although the mentioned patch try to fix a potential race in building/accessing the same table for fast memory regions, it broke rtrs etc ULPs. Since the latter could be worse, revert this patch. With previous commit, it's observed that a same MR in rnbd server will trigger below code path: -> rxe_mr_init_fast() |-> alloc map_set() # map_set is uninitialized |...-> rxe_map_mr_sg() # build the map_set |-> rxe_mr_set_page() |...-> rxe_reg_fast_mr() # mr->state change to VALID from FREE that means # we can access host memory(such rxe_mr_copy) |...-> rxe_invalidate_mr() # mr->state change to FREE from VALID |...-> rxe_reg_fast_mr() # mr->state change to VALID from FREE, # but map_set was not built again |...-> rxe_mr_copy() # kernel crash due to access wild addresses # that lookup from the map_set The backtraces are not always identical. [1st]---------- RIP: 0010:lookup_iova+0x66/0xa0 [rdma_rxe] Code: 00 00 00 48 d3 ee 89 32 c3 4c 8b 18 49 8b 3b 48 8b 47 08 48 39 c6 72 38 48 29 c6 45 31 d2 b8 01 00 00 00 48 63 c8 48 c1 e1 04 <48> 8b 4c 0f 08 48 39 f1 77 21 83 c0 01 48 29 ce 3d 00 01 00 00 75 RSP: 0018:ffffb7ff80063bf0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff9b9949d86800 RCX: 0000000000000000 RDX: ffffb7ff80063c00 RSI: 0000000049f6b378 RDI: 002818da00000004 RBP: 0000000000000120 R08: ffffb7ff80063c08 R09: ffffb7ff80063c04 R10: 0000000000000002 R11: ffff9b9916f7eef8 R12: ffff9b99488a0038 R13: ffff9b99488a0038 R14: ffff9b9914fb346a R15: ffff9b990ab27000 FS: 0000000000000000(0000) GS:ffff9b997dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007efc33a98ed0 CR3: 0000000014f32004 CR4: 00000000001706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> rxe_mr_copy.part.0+0x6f/0x140 [rdma_rxe] rxe_responder+0x12ee/0x1b60 [rdma_rxe] ? rxe_icrc_check+0x7e/0x100 [rdma_rxe] ? rxe_rcv+0x1d0/0x780 [rdma_rxe] ? rxe_icrc_hdr.isra.0+0xf6/0x160 [rdma_rxe] rxe_do_task+0x67/0xb0 [rdma_rxe] rxe_xmit_packet+0xc7/0x210 [rdma_rxe] rxe_requester+0x680/0xee0 [rdma_rxe] ? update_load_avg+0x5f/0x690 ? update_load_avg+0x5f/0x690 ? rtrs_clt_recv_done+0x1b/0x30 [rtrs_client] [2nd]---------- RIP: 0010:rxe_mr_copy.part.0+0xa8/0x140 [rdma_rxe] Code: 00 00 49 c1 e7 04 48 8b 00 4c 8d 2c d0 48 8b 44 24 10 4d 03 7d 00 85 ed 7f 10 eb 6c 89 54 24 0c 49 83 c7 10 31 c0 85 ed 7e 5e <49> 8b 3f 8b 14 24 4c 89 f6 48 01 c7 85 d2 74 06 48 89 fe 4c 89 f7 RSP: 0018:ffffae3580063bf8 EFLAGS: 00010202 RAX: 0000000000018978 RBX: ffff9d7ef7a03600 RCX: 0000000000000008 RDX: 000000000000007c RSI: 000000000000007c RDI: ffff9d7ef7a03600 RBP: 0000000000000120 R08: ffffae3580063c08 R09: ffffae3580063c04 R10: ffff9d7efece0038 R11: ffff9d7ec4b1db00 R12: ffff9d7efece0038 R13: ffff9d7ef4098260 R14: ffff9d7f11e23c6a R15: 4c79500065708144 FS: 0000000000000000(0000) GS:ffff9d7f3dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fce47276c60 CR3: 0000000003f66004 CR4: 00000000001706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> rxe_responder+0x12ee/0x1b60 [rdma_rxe] ? rxe_icrc_check+0x7e/0x100 [rdma_rxe] ? rxe_rcv+0x1d0/0x780 [rdma_rxe] ? rxe_icrc_hdr.isra.0+0xf6/0x160 [rdma_rxe] rxe_do_task+0x67/0xb0 [rdma_rxe] rxe_xmit_packet+0xc7/0x210 [rdma_rxe] rxe_requester+0x680/0xee0 [rdma_rxe] ? update_load_avg+0x5f/0x690 ? update_load_avg+0x5f/0x690 ? rtrs_clt_recv_done+0x1b/0x30 [rtrs_client] rxe_do_task+0x67/0xb0 [rdma_rxe] tasklet_action_common.constprop.0+0x92/0xc0 __do_softirq+0xe1/0x2d8 run_ksoftirqd+0x21/0x30 smpboot_thread_fn+0x183/0x220 ? sort_range+0x20/0x20 kthread+0xe2/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 Link: https://lore.kernel.org/r/1658805386-2-1-git-send-email-lizhijian@fujitsu.com Link: https://lore.kernel.org/all/20220210073655.42281-1-guoqing.jiang@linux.dev/T/ Link: https://www.spinics.net/lists/linux-rdma/msg110836.html Link: https://lore.kernel.org/lkml/94a5ea93-b8bb-3a01-9497-e2021f29598a@linux.dev/t/ Tested-by: Md Haris Iqbal <haris.iqbal@ionos.com> Reviewed-by: Bob Pearson <rpearsonhpe@gmail.com> Signed-off-by: Li Zhijian <lizhijian@fujitsu.com> Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25dmaengine: sprd: Cleanup in .remove() after pm_runtime_get_sync() failedUwe Kleine-König1-4/+1
[ Upstream commit 1e42f82cbec7b2cc4873751e7791e6611901c5fc ] It's not allowed to quit remove early without cleaning up completely. Otherwise this results in resource leaks that probably yield graver problems later. Here for example some tasklets might survive the lifetime of the sprd-dma device and access sdev which is freed after .remove() returns. As none of the device freeing requires an active device, just ignore the return value of pm_runtime_get_sync(). Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Baolin Wang <baolin.wang7@gmail.com> Link: https://lore.kernel.org/r/20220721204054.323602-1-u.kleine-koenig@pengutronix.de Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25dmaengine: tegra: Add terminate() for Tegra234Akhil R1-2/+24
[ Upstream commit 36834c67016794b8fa03d7672a5b7f2cc4529298 ] In certain cases where the DMA client bus gets corrupted or if the end device ceases to send/receive data, DMA can wait indefinitely for the data to be received/sent. Attempting to terminate the transfer will put the DMA in pause flush mode and it remains there. The channel is irrecoverable once this pause times out in Tegra194 and earlier chips. Whereas, from Tegra234, it can be recovered by disabling the channel and reprograming it. Hence add a new terminate() function that ignores the outcome of dma_pause() so that terminate_all() can proceed to disable the channel. Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://lore.kernel.org/r/20220720104045.16099-3-akhilrajeev@nvidia.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25RDMA/rxe: Limit the number of calls to each taskletBob Pearson2-4/+18
[ Upstream commit eff6d998ca297cb0b2e53b032a56cf8e04dd8b17 ] Limit the maximum number of calls to each tasklet from rxe_do_task() before yielding the cpu. When the limit is reached reschedule the tasklet and exit the calling loop. This patch prevents one tasklet from consuming 100% of a cpu core and causing a deadlock or soft lockup. Link: https://lore.kernel.org/r/20220630190425.2251-9-rpearsonhpe@gmail.com Signed-off-by: Bob Pearson <rpearsonhpe@gmail.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25ACPI: PPTT: Leave the table mapped for the runtime usageSudeep Holla1-55/+47
[ Upstream commit 0c80f9e165f8f9cca743d7b6cbdb54362da297e0 ] Currently, everytime an information needs to be fetched from the PPTT, the table is mapped via acpi_get_table() and unmapped after the use via acpi_put_table() which is fine. However we do this at runtime especially when the CPU is hotplugged out and plugged in back since we re-populate the cache topology and other information. However, with the support to fetch LLC information from the PPTT in the cpuhotplug path which is executed in the atomic context, it is preferred to avoid mapping and unmapping of the PPTT for every single use as the acpi_get_table() might sleep waiting for a mutex. In order to avoid the same, the table is needs to just mapped once on the boot CPU and is never unmapped allowing it to be used at runtime with out the hassle of mapping and unmapping the table. Reported-by: Guenter Roeck <linux@roeck-us.net> Cc: Rafael J. Wysocki <rafael@kernel.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> -- Hi Rafael, Sorry to bother you again on this PPTT changes. Guenter reported an issue with lockdep enabled in -next that include my cacheinfo/arch_topology changes to utilise LLC from PPTT in the CPU hotplug path. Please ack the change once you are happy so that I can get it merged with other fixes via Greg's tree. Regards, Sudeep Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/20220720-arch_topo_fixes-v3-2-43d696288e84@arm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25mmc: renesas_sdhi: newer SoCs don't need manual tap correctionTakeshi Saito3-3/+9
[ Upstream commit 00e8c11c137b2e4b2bf54dc9881cf32e3441ddb4 ] The newest Gen3 SoCs and Gen4 SoCs do not need manual tap correction with HS400 anymore. So, instead of checking the SDHI version, add a quirk flag and set manual tap correction only for affected SoCs. Signed-off-by: Takeshi Saito <takeshi.saito.xv@renesas.com> [wsa: rebased, renamed the quirk variable, removed stale comment] Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/20220720072901.1266-1-wsa+renesas@sang-engineering.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25dmaengine: dw-axi-dmac: ignore interrupt if no descriptorBen Dooks1-0/+6
[ Upstream commit 820f5ce999d2f99961e88c16d65cd26764df0590 ] If the channel has no descriptor and the interrupt is raised then the kernel will OOPS. Check the result of vchan_next_desc() in the handler axi_chan_block_xfer_complete() to avoid the error happening. Signed-off-by: Ben Dooks <ben.dooks@sifive.com> Link: https://lore.kernel.org/r/20220708170153.269991-4-ben.dooks@sifive.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25dmaengine: dw-axi-dmac: do not print NULL LLI during errorBen Dooks1-0/+5
[ Upstream commit 86cb0defe0e275453bc39e856bb523eb425a6537 ] During debugging we have seen an issue where axi_chan_dump_lli() is passed a NULL LLI pointer which ends up causing an OOPS due to trying to get fields from it. Simply print NULL LLI and exit to avoid this. Signed-off-by: Ben Dooks <ben.dooks@sifive.com> Link: https://lore.kernel.org/r/20220708170153.269991-3-ben.dooks@sifive.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25of: overlay: Move devicetree_corrupt() check upGeert Uytterhoeven1-6/+5
[ Upstream commit e385b0ba6a137f34953e746d70d543660c2de1a0 ] There is no point in doing several preparatory steps in of_overlay_fdt_apply(), only to see of_overlay_apply() return early because of a corrupt device tree. Move the check for a corrupt device tree from of_overlay_apply() to of_overlay_fdt_apply(), to check for this as early as possible. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Frank Rowand <frank.rowand@sony.com> Tested-by: Frank Rowand <frank.rowand@sony.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/c91ce7112eb5167ea46a43d8a980e76b920010ba.1657893306.git.geert+renesas@glider.be Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25PCI/ACPI: Guard ARM64-specific mcfg_quirksHuacai Chen1-0/+3
[ Upstream commit 40a6cc141b4b9580de140bcb3e893445708acc5d ] Guard ARM64-specific quirks with CONFIG_ARM64 to avoid build errors, since mcfg_quirks will be shared by more than one architectures. Link: https://lore.kernel.org/r/20220714124216.1489304-2-chenhuacai@loongson.cn Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25cxl: Fix a memory leak in an error handling pathChristophe JAILLET1-0/+1
[ Upstream commit 3a15b45b5454da862376b5d69a4967f5c6fa1368 ] A bitmap_zalloc() must be balanced by a corresponding bitmap_free() in the error handling path of afu_allocate_irqs(). Acked-by: Andrew Donnellan <ajd@linux.ibm.com> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/ce5869418f5838187946eb6b11a52715a93ece3d.1657566849.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25pinctrl: intel: Check against matching data instead of ACPI companionAndy Shevchenko1-8/+6
[ Upstream commit c551bd81d198bf1dcd4398d5454acdc0309dbe77 ] In some cases we may get a platform device that has ACPI companion which is different to the pin control described in the ACPI tables. This is primarily happens when device is instantiated by board file. In order to allow this device being enumerated, refactor intel_pinctrl_get_soc_data() to check the matching data instead of ACPI companion. Reported-by: Henning Schild <henning.schild@siemens.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Henning Schild <henning.schild@siemens.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25scsi: ufs: ufs-exynos: Change ufs phy control sequenceChanho Park1-7/+10
[ Upstream commit 3d73b200f9893d8f5ba5d105e8b69c8d16744fa2 ] Since commit 1599069a62c6 ("phy: core: Warn when phy_power_on is called before phy_init"), the following warning has been reported: phy_power_on was called before phy_init To address this, we need to remove phy_power_on from exynos_ufs_phy_init() and move it after phy_init. phy_power_off and phy_exit are also necessary in exynos_ufs_remove(). Link: https://lore.kernel.org/r/20220706020255.151177-4-chanho61.park@samsung.com Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Chanho Park <chanho61.park@samsung.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25mmc: tmio: avoid glitches when resettingWolfram Sang4-23/+42
[ Upstream commit 2e586f8a5b0ed4a525014a692923ac96f6647816 ] If we reset because of an error, we need to preserve values for the clock frequency. Otherwise, glitches may be seen on the bus. To achieve that, we introduce a 'preserve' parameter to the reset function and the IP core specific reset callbacks to handle everything accordingly. Reported-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/20220625131722.1397-1-wsa@kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25habanalabs/gaudi: mask constant value before castOded Gabbay1-4/+4
[ Upstream commit e3f49437a2e0221a387ecd192d742ae1434e1e3a ] This fixes a sparse warning of "cast truncates bits from constant value" Signed-off-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25habanalabs/gaudi: fix shift out of boundsOfir Bitton1-7/+9
[ Upstream commit 01622098aeb05a5efbb727199bbc2a4653393255 ] When validating NIC queues, queue offset calculation must be performed only for NIC queues. Signed-off-by: Ofir Bitton <obitton@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25habanalabs/gaudi: invoke device reset from one code blockTal Cohen1-9/+16
[ Upstream commit be572e67dafbf8004d46a2c9d97338c107efb60e ] In order to prepare the driver code for device reset event notification, change the event handler function flow to call device reset from one code block. In addition, the commit fixes an issue that reset was performed w/o checking the 'hard_reset_on_fw_event' state and w/o setting the HL_DRV_RESET_DELAY flag. Signed-off-by: Tal Cohen <talcohen@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25habanalabs: add terminating NULL to attrs arraysDafna Hirschfeld3-0/+5
[ Upstream commit 78d503087be190eab36290644ccec050135e7c70 ] Arrays of struct attribute are expected to be NULL terminated. This is required by API methods such as device_add_groups. This fixes a crash when loading the driver for Goya device. Signed-off-by: Dafna Hirschfeld <dhirschfeld@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25coresight: etm4x: avoid build failure with unrolled loopsNick Desaulniers1-1/+2
[ Upstream commit 4d45bc82df667ad9e9cb8361830e54fc1264e993 ] When the following configs are enabled: * CORESIGHT * CORESIGHT_SOURCE_ETM4X * UBSAN * UBSAN_TRAP Clang fails assemble the kernel with the error: <instantiation>:1:7: error: expected constant expression in '.inst' directive .inst (0xd5200000|((((2) << 19) | ((1) << 16) | (((((((((((0x160 + (i * 4))))) >> 2))) >> 7) & 0x7)) << 12) | ((((((((((0x160 + (i * 4))))) >> 2))) & 0xf)) << 8) | (((((((((((0x160 + (i * 4))))) >> 2))) >> 4) & 0x7)) << 5)))|(.L__reg_num_x8)) ^ drivers/hwtracing/coresight/coresight-etm4x-core.c:702:4: note: while in macro instantiation etm4x_relaxed_read32(csa, TRCCNTVRn(i)); ^ drivers/hwtracing/coresight/coresight-etm4x.h:403:4: note: expanded from macro 'etm4x_relaxed_read32' read_etm4x_sysreg_offset((offset), false))) ^ drivers/hwtracing/coresight/coresight-etm4x.h:383:12: note: expanded from macro 'read_etm4x_sysreg_offset' __val = read_etm4x_sysreg_const_offset((offset)); \ ^ drivers/hwtracing/coresight/coresight-etm4x.h:149:2: note: expanded from macro 'read_etm4x_sysreg_const_offset' READ_ETM4x_REG(ETM4x_OFFSET_TO_REG(offset)) ^ drivers/hwtracing/coresight/coresight-etm4x.h:144:2: note: expanded from macro 'READ_ETM4x_REG' read_sysreg_s(ETM4x_REG_NUM_TO_SYSREG((reg))) ^ arch/arm64/include/asm/sysreg.h:1108:15: note: expanded from macro 'read_sysreg_s' asm volatile(__mrs_s("%0", r) : "=r" (__val)); \ ^ arch/arm64/include/asm/sysreg.h:1074:2: note: expanded from macro '__mrs_s' " mrs_s " v ", " __stringify(r) "\n" \ ^ Consider the definitions of TRCSSCSRn and TRCCNTVRn: drivers/hwtracing/coresight/coresight-etm4x.h:56 #define TRCCNTVRn(n) (0x160 + (n * 4)) drivers/hwtracing/coresight/coresight-etm4x.h:81 #define TRCSSCSRn(n) (0x2A0 + (n * 4)) Where the macro parameter is expanded to i; a loop induction variable from etm4_disable_hw. When any compiler can determine that loops may be unrolled, then the __builtin_constant_p check in read_etm4x_sysreg_offset() defined in drivers/hwtracing/coresight/coresight-etm4x.h may evaluate to true. This can lead to the expression `(0x160 + (i * 4))` being passed to read_etm4x_sysreg_const_offset. Via the trace above, this is passed through READ_ETM4x_REG, read_sysreg_s, and finally to __mrs_s where it is string-ified and used directly in inline asm. Regardless of which compiler or compiler options determine whether a loop can or can't be unrolled, which determines whether __builtin_constant_p evaluates to true when passed an expression using a loop induction variable, it is NEVER safe to allow the preprocessor to construct inline asm like: asm volatile (".inst (0x160 + (i * 4))" : "=r"(__val)); ^ expected constant expression Instead of read_etm4x_sysreg_offset() using __builtin_constant_p(), use __is_constexpr from include/linux/const.h instead to ensure only expressions that are valid integer constant expressions get passed through to read_sysreg_s(). This is not a bug in clang; it's a potentially unsafe use of the macro arguments in read_etm4x_sysreg_offset dependent on __builtin_constant_p. Link: https://github.com/ClangBuiltLinux/linux/issues/1310 Reported-by: Arnd Bergmann <arnd@kernel.org> Reported-by: Tao Zhang <quic_taozha@quicinc.com> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Link: https://lore.kernel.org/r/20220708231520.3958391-1-ndesaulniers@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25gadgetfs: ep_io - wait until IRQ finishesJozef Martiniak1-0/+1
[ Upstream commit 04cb742d4d8f30dc2e83b46ac317eec09191c68e ] after usb_ep_queue() if wait_for_completion_interruptible() is interrupted we need to wait until IRQ gets finished. Otherwise complete() from epio_complete() can corrupt stack. Signed-off-by: Jozef Martiniak <jomajm@gmail.com> Link: https://lore.kernel.org/r/20220708070645.6130-1-jomajm@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25scsi: lpfc: Fix possible memory leak when failing to issue CMF WQEJames Smart1-1/+3
[ Upstream commit 2f67dc7970bce3529edce93a0a14234d88b3fcd5 ] There is no corresponding free routine if lpfc_sli4_issue_wqe fails to issue the CMF WQE in lpfc_issue_cmf_sync_wqe. If ret_val is non-zero, then free the iocbq request structure. Link: https://lore.kernel.org/r/20220701211425.2708-6-jsmart2021@gmail.com Co-developed-by: Justin Tee <justin.tee@broadcom.com> Signed-off-by: Justin Tee <justin.tee@broadcom.com> Signed-off-by: James Smart <jsmart2021@gmail.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25scsi: lpfc: Prevent buffer overflow crashes in debugfs with malformed user inputJames Smart1-10/+10
[ Upstream commit f8191d40aa612981ce897e66cda6a88db8df17bb ] Malformed user input to debugfs results in buffer overflow crashes. Adapt input string lengths to fit within internal buffers, leaving space for NULL terminators. Link: https://lore.kernel.org/r/20220701211425.2708-3-jsmart2021@gmail.com Co-developed-by: Justin Tee <justin.tee@broadcom.com> Signed-off-by: Justin Tee <justin.tee@broadcom.com> Signed-off-by: James Smart <jsmart2021@gmail.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25clk: qcom: clk-alpha-pll: fix clk_trion_pll_configure descriptionVladimir Zapolskiy1-1/+1
[ Upstream commit 94bed9bb05c7850ff5d80b87cc29004901f37956 ] After merging lucid and trion pll functions in commit 0b01489475c6 ("clk: qcom: clk-alpha-pll: same regs and ops for trion and lucid") the function clk_trion_pll_configure() is left with an old description header, which results in a W=2 compile time warning, fix it. Acked-by: Stephen Boyd <sboyd@kernel.org> Reviewed-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220701062711.2757855-1-vladimir.zapolskiy@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25zram: do not lookup algorithm in backends tableSergey Senozhatsky1-6/+5
[ Upstream commit dc89997264de565999a1cb55db3f295d3a8e457b ] Always use crypto_has_comp() so that crypto can lookup module, call usermodhelper to load the modules, wait for usermodhelper to finish and so on. Otherwise crypto will do all of these steps under CPU hot-plug lock and this looks like too much stuff to handle under the CPU hot-plug lock. Besides this can end up in a deadlock when usermodhelper triggers a code path that attempts to lock the CPU hot-plug lock, that zram already holds. An example of such deadlock: - path A. zram grabs CPU hot-plug lock, execs /sbin/modprobe from crypto and waits for modprobe to finish disksize_store zcomp_create __cpuhp_state_add_instance __cpuhp_state_add_instance_cpuslocked zcomp_cpu_up_prepare crypto_alloc_base crypto_alg_mod_lookup call_usermodehelper_exec wait_for_completion_killable do_wait_for_common schedule - path B. async work kthread that brings in scsi device. It wants to register CPUHP states at some point, and it needs the CPU hot-plug lock for that, which is owned by zram. async_run_entry_fn scsi_probe_and_add_lun scsi_mq_alloc_queue blk_mq_init_queue blk_mq_init_allocated_queue blk_mq_realloc_hw_ctxs __cpuhp_state_add_instance __cpuhp_state_add_instance_cpuslocked mutex_lock schedule - path C. modprobe sleeps, waiting for all aync works to finish. load_module do_init_module async_synchronize_full async_synchronize_cookie_domain schedule [senozhatsky@chromium.org: add comment] Link: https://lkml.kernel.org/r/20220624060606.1014474-1-senozhatsky@chromium.org Link: https://lkml.kernel.org/r/20220622023501.517125-1-senozhatsky@chromium.org Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org> Cc: Minchan Kim <minchan@kernel.org> Cc: Nitin Gupta <ngupta@vflare.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25uacce: Handle parent device removal or parent driver module rmmodJean-Philippe Brucker1-46/+87
[ Upstream commit 80fc671bcc0173836e9032b0c698ea74c13b9d7c ] The uacce driver must deal with a possible removal of the parent device or parent driver module rmmod at any time. Although uacce_remove(), called on device removal and on driver unbind, prevents future use of the uacce fops by removing the cdev, fops that were called before that point may still be running. Serialize uacce_fops_open() and uacce_remove() with uacce->mutex. Serialize other fops against uacce_remove() with q->mutex. Since we need to protect uacce_fops_poll() which gets called on the fast path, replace uacce->queues_lock with q->mutex to improve scalability. The other fops are only used during setup. uacce_queue_is_valid(), checked under q->mutex or uacce->mutex, denotes whether uacce_remove() has disabled all queues. If that is the case, don't go any further since the parent device is being removed and uacce->ops should not be called anymore. Reported-by: Yang Shen <shenyang39@huawei.com> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Link: https://lore.kernel.org/r/20220701034843.7502-1-zhangfei.gao@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25clk: qcom: ipq8074: dont disable gcc_sleep_clk_srcRobert Marko1-0/+1
[ Upstream commit 1bf7305e79aab095196131bdc87a97796e0e3fac ] Once the usb sleep clocks are disabled, clock framework is trying to disable the sleep clock source also. However, it seems that it cannot be disabled and trying to do so produces: [ 245.436390] ------------[ cut here ]------------ [ 245.441233] gcc_sleep_clk_src status stuck at 'on' [ 245.441254] WARNING: CPU: 2 PID: 223 at clk_branch_wait+0x130/0x140 [ 245.450435] Modules linked in: xhci_plat_hcd xhci_hcd dwc3 dwc3_qcom leds_gpio [ 245.456601] CPU: 2 PID: 223 Comm: sh Not tainted 5.18.0-rc4 #215 [ 245.463889] Hardware name: Xiaomi AX9000 (DT) [ 245.470050] pstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 245.474307] pc : clk_branch_wait+0x130/0x140 [ 245.481073] lr : clk_branch_wait+0x130/0x140 [ 245.485588] sp : ffffffc009f2bad0 [ 245.489838] x29: ffffffc009f2bad0 x28: ffffff8003e6c800 x27: 0000000000000000 [ 245.493057] x26: 0000000000000000 x25: 0000000000000000 x24: ffffff800226ef20 [ 245.500175] x23: ffffffc0089ff550 x22: 0000000000000000 x21: ffffffc008476ad0 [ 245.507294] x20: 0000000000000000 x19: ffffffc00965ac70 x18: fffffffffffc51a7 [ 245.514413] x17: 68702e3030303837 x16: 3a6d726f6674616c x15: ffffffc089f2b777 [ 245.521531] x14: ffffffc0095c9d18 x13: 0000000000000129 x12: 0000000000000129 [ 245.528649] x11: 00000000ffffffea x10: ffffffc009621d18 x9 : 0000000000000001 [ 245.535767] x8 : 0000000000000001 x7 : 0000000000017fe8 x6 : 0000000000000001 [ 245.542885] x5 : ffffff803fdca6d8 x4 : 0000000000000000 x3 : 0000000000000027 [ 245.550002] x2 : 0000000000000027 x1 : 0000000000000023 x0 : 0000000000000026 [ 245.557122] Call trace: [ 245.564229] clk_branch_wait+0x130/0x140 [ 245.566490] clk_branch2_disable+0x2c/0x40 [ 245.570656] clk_core_disable+0x60/0xb0 [ 245.574561] clk_core_disable+0x68/0xb0 [ 245.578293] clk_disable+0x30/0x50 [ 245.582113] dwc3_qcom_remove+0x60/0xc0 [dwc3_qcom] [ 245.585588] platform_remove+0x28/0x60 [ 245.590361] device_remove+0x4c/0x80 [ 245.594179] device_release_driver_internal+0x1dc/0x230 [ 245.597914] device_driver_detach+0x18/0x30 [ 245.602861] unbind_store+0xec/0x110 [ 245.607027] drv_attr_store+0x24/0x40 [ 245.610847] sysfs_kf_write+0x44/0x60 [ 245.614405] kernfs_fop_write_iter+0x128/0x1c0 [ 245.618052] new_sync_write+0xc0/0x130 [ 245.622391] vfs_write+0x1d4/0x2a0 [ 245.626123] ksys_write+0x58/0xe0 [ 245.629508] __arm64_sys_write+0x1c/0x30 [ 245.632895] invoke_syscall.constprop.0+0x5c/0x110 [ 245.636890] do_el0_svc+0xa0/0x150 [ 245.641488] el0_svc+0x18/0x60 [ 245.644872] el0t_64_sync_handler+0xa4/0x130 [ 245.647914] el0t_64_sync+0x174/0x178 [ 245.652340] ---[ end trace 0000000000000000 ]--- So, add CLK_IS_CRITICAL flag to the clock so that the kernel won't try to disable the sleep clock. Signed-off-by: Robert Marko <robimarko@gmail.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220515210048.483898-10-robimarko@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25vboxguest: Do not use devm for irqPascal Terjan1-3/+6
[ Upstream commit 6169525b76764acb81918aa387ac168fb9a55575 ] When relying on devm it doesn't get freed early enough which causes the following warning when unloading the module: [249348.837181] remove_proc_entry: removing non-empty directory 'irq/20', leaking at least 'vboxguest' [249348.837219] WARNING: CPU: 0 PID: 6708 at fs/proc/generic.c:715 remove_proc_entry+0x119/0x140 [249348.837379] Call Trace: [249348.837385] unregister_irq_proc+0xbd/0xe0 [249348.837392] free_desc+0x23/0x60 [249348.837396] irq_free_descs+0x4a/0x70 [249348.837401] irq_domain_free_irqs+0x160/0x1a0 [249348.837452] mp_unmap_irq+0x5c/0x60 [249348.837458] acpi_unregister_gsi_ioapic+0x29/0x40 [249348.837463] acpi_unregister_gsi+0x17/0x30 [249348.837467] acpi_pci_irq_disable+0xbf/0xe0 [249348.837473] pcibios_disable_device+0x20/0x30 [249348.837478] pci_disable_device+0xef/0x120 [249348.837482] vbg_pci_remove+0x6c/0x70 [vboxguest] Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Pascal Terjan <pterjan@google.com> Link: https://lore.kernel.org/r/20220612133744.4030602-1-pterjan@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25usb: dwc2: gadget: remove D+ pull-up while no vbus with usb-role-switchAmelie Delaunay1-1/+2
[ Upstream commit db638c6500abaffb8f7770b2a69c40d003d54ae1 ] When using usb-role-switch, D+ pull-up is set as soon as DTCL_SFTDISCON is cleared, whatever the vbus valid signal state is. The pull-up should not be set when vbus isn't present (this is determined by the drd controller). This patch ensures that B-Session (so Peripheral role + vbus valid signal) is valid before clearing the DCTL_SFTDISCON bit when role switch is used. Keep original behavior when usb-role-switch isn't used. Acked-by: Minas Harutyunyan <hminas@synopsys.com> Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Link: https://lore.kernel.org/r/20220622160717.314580-1-fabrice.gasnier@foss.st.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25scsi: iscsi: Fix HW conn removal use after freeMike Christie1-2/+0
[ Upstream commit c577ab7ba5f3bf9062db8a58b6e89d4fe370447e ] If qla4xxx doesn't remove the connection before the session, the iSCSI class tries to remove the connection for it. We were doing a iscsi_put_conn() in the iter function which is not needed and will result in a use after free because iscsi_remove_conn() will free the connection. Link: https://lore.kernel.org/r/20220616222738.5722-2-michael.christie@oracle.com Tested-by: Nilesh Javali <njavali@marvell.com> Reviewed-by: Lee Duncan <lduncan@suse.com> Reviewed-by: Nilesh Javali <njavali@marvell.com> Signed-off-by: Mike Christie <michael.christie@oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25usb: renesas: Fix refcount leak bugLiang He1-0/+4
[ Upstream commit 9d6d5303c39b8bc182475b22f45504106a07f086 ] In usbhs_rza1_hardware_init(), of_find_node_by_name() will return a node pointer with refcount incremented. We should use of_node_put() when it is not used anymore. Signed-off-by: Liang He <windhl@126.com> Link: https://lore.kernel.org/r/20220618023205.4056548-1-windhl@126.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25usb: host: ohci-ppc-of: Fix refcount leak bugLiang He1-0/+1
[ Upstream commit 40a959d7042bb7711e404ad2318b30e9f92c6b9b ] In ohci_hcd_ppc_of_probe(), of_find_compatible_node() will return a node pointer with refcount incremented. We should use of_node_put() when it is not used anymore. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Liang He <windhl@126.com> Link: https://lore.kernel.org/r/20220617034637.4003115-1-windhl@126.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25scsi: ufs: ufs-mediatek: Fix the timing of configuring device regulatorsPo-Wen Kao1-5/+53
[ Upstream commit 3fd23b8dfb54d9b74eba6dfdd3225db3ac116785 ] Currently the LPM configurations of device regulators may not work since VCC is not disabled yet while ufs_mtk_vreg_set_lpm() is executed. Fix this by changing the timing of invoking ufs_mtk_vreg_set_lpm(). Link: https://lore.kernel.org/r/20220616053725.5681-5-stanley.chu@mediatek.com Reviewed-by: Stanley Chu <stanley.chu@mediatek.com> Signed-off-by: Po-Wen Kao <powen.kao@mediatek.com> Signed-off-by: Stanley Chu <stanley.chu@mediatek.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25clk: ti: Stop using legacy clkctrl names for omap4 and 5Tony Lindgren3-189/+185
[ Upstream commit 255584b138343d4a28c6d25bd82d04b09460d672 ] With the addition of clock-output-names, we can now unify the internal clock naming for omap4 and 5 to follow the other TI SoCs. We are still using legacy clkctrl names for omap4 and 5 based on the clock manager name which is wrong. Instead, we want to use the clkctrl clock based naming. We must now also drop the legacy TI_CLK_CLKCTRL_COMPAT quirk for the clkctrl clock. This change will allow further devicetree warning cleanup as already done for am3/4 and dra7. Cc: linux-clk@vger.kernel.org Cc: Stephen Boyd <sboyd@kernel.org> Cc: Tero Kristo <kristo@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20220615064306.22254-1-tony@atomide.com Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25drm/meson: Fix overflow implicit truncation warningsSai Prakash Ranjan1-11/+11
[ Upstream commit 98692f52c588225034cbff458622c2c06dfcb544 ] Fix -Woverflow warnings for drm/meson driver which is a result of moving arm64 custom MMIO accessor macros to asm-generic function implementations giving a bonus type-checking now and uncovering these overflow warnings. drivers/gpu/drm/meson/meson_viu.c: In function ‘meson_viu_init’: drivers/gpu/drm/meson/meson_registers.h:1826:48: error: large integer implicitly truncated to unsigned type [-Werror=overflow] #define VIU_OSD_BLEND_REORDER(dest, src) ((src) << (dest * 4)) ^ drivers/gpu/drm/meson/meson_viu.c:472:18: note: in expansion of macro ‘VIU_OSD_BLEND_REORDER’ writel_relaxed(VIU_OSD_BLEND_REORDER(0, 1) | ^~~~~~~~~~~~~~~~~~~~~ Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Sai Prakash Ranjan <quic_saipraka@quicinc.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25irqchip/tegra: Fix overflow implicit truncation warningsSai Prakash Ranjan1-5/+5
[ Upstream commit 443685992bda9bb4f8b17fc02c9f6c60e62b1461 ] Fix -Woverflow warnings for tegra irqchip driver which is a result of moving arm64 custom MMIO accessor macros to asm-generic function implementations giving a bonus type-checking now and uncovering these overflow warnings. drivers/irqchip/irq-tegra.c: In function ‘tegra_ictlr_suspend’: drivers/irqchip/irq-tegra.c:151:18: warning: large integer implicitly truncated to unsigned type [-Woverflow] writel_relaxed(~0ul, ictlr + ICTLR_COP_IER_CLR); ^ Suggested-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Sai Prakash Ranjan <quic_saipraka@quicinc.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Cc: Marc Zyngier <maz@kernel.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25scsi: ufs: core: Add UFSHCD_QUIRK_HIBERN_FASTAUTOYoshihiro Shimoda1-2/+7
[ Upstream commit 2f11bbc2c7f37e3a6151ac548b1c0679cc90ea83 ] Add UFSHCD_QUIRK_HIBERN_FASTAUTO quirk for host controllers which supports auto-hibernate the capability but only FASTAUTO mode. Link: https://lore.kernel.org/r/20220603110524.1997825-4-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25scsi: ufs: core: Add UFSHCD_QUIRK_BROKEN_64BIT_ADDRESSYoshihiro Shimoda1-0/+2
[ Upstream commit 6554400d6f66b9494a0c0f07712ab0a9d307eb01 ] Add UFSHCD_QUIRK_BROKEN_64BIT_ADDRESS for host controllers which do not support 64-bit addressing. Link: https://lore.kernel.org/r/20220603110524.1997825-3-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25PCI: aardvark: Fix reporting Slot capabilities on emulated bridgePali Rohár1-9/+24
[ Upstream commit bcdb6fd4f3e9ac1097698c8d8f56b70853b49873 ] Slot capabilities are currently not reported because emulated bridge does not report the PCI_EXP_FLAGS_SLOT flag. Set PCI_EXP_FLAGS_SLOT to let the kernel know that PCI_EXP_SLT* registers are supported. Move setting of PCI_EXP_SLTCTL register from "dynamic" pcie_conf_read function to static buffer as it is only statically filled the PCI_EXP_SLTSTA_PDS flag and dynamic read callback is not needed for this register. Set Presence State Bit to 1 since there is no support for unplugging the card and there is currently no platform able to detect presence of a card - in such a case the bit needs to be set to 1. Finally correctly set Physical Slot Number to 1 since there is only one port and zero value is reserved for ports within the same silicon as Root Port which is not our case for Aardvark HW. Link: https://lore.kernel.org/r/20220524132827.8837-3-kabel@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-25usb: gadget: uvc: call uvc uvcg_warn on completed status instead of uvcg_infoMichael Grzeschik1-1/+1
[ Upstream commit a725d0f6dfc5d3739d6499f30ec865305ba3544d ] Likewise to the uvcvideo hostside driver, this patch is changing the usb_request message of an non zero completion handler call from dev_info to dev_warn. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Link: https://lore.kernel.org/r/20220529223848.105914-4-m.grzeschik@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2024-10-22 18:38:17 +0300