aboutsummaryrefslogtreecommitdiff
path: root/drivers/remoteproc
AgeCommit message (Collapse)Author
2023-05-24remoteproc: imx_dsp_rproc: Fix kernel test robot sparse warningMathieu Poirier
[ Upstream commit 3c497f624d40171ebead1a6705793100d92ecb85 ] This patch fixes the kernel test robot warning reported here: https://lore.kernel.org/bpf/642f916b.pPIKZ%2Fl%2F%2Fbw8tvIH%25lkp@intel.com/T/ Fixes: 408ec1ff0caa ("remoteproc: imx_dsp_rproc: Add custom memory copy implementation for i.MX DSP Cores") Link: https://lore.kernel.org/r/20230407161429.3973177-1-mathieu.poirier@linaro.org Tested-by: Iuliana Prodan <iuliana.prodan@nxp.com> Reviewed-by: Iuliana Prodan <iuliana.prodan@nxp.com> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-05-24remoteproc: stm32_rproc: Add mutex protection for workqueueArnaud Pouliquen
[ Upstream commit 35bdafda40cc343ad2ba2cce105eba03a70241cc ] The workqueue may execute late even after remoteproc is stopped or stopping, some resources (rpmsg device and endpoint) have been released in rproc_stop_subdevices(), then rproc_vq_interrupt() accessing these resources will cause kernel dump. Call trace: virtqueue_add_inbuf virtqueue_add_inbuf rpmsg_recv_single rpmsg_recv_done vring_interrupt stm32_rproc_mb_vq_work process_one_work worker_thread kthread Suggested-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> Link: https://lore.kernel.org/r/20230331160634.3113031-1-arnaud.pouliquen@foss.st.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-05-24remoteproc: imx_dsp_rproc: Add custom memory copy implementation for i.MX ↵Iuliana Prodan
DSP Cores [ Upstream commit 408ec1ff0caa340c57eecf4cbd14ef0132036a50 ] The IRAM is part of the HiFi DSP. According to hardware specification only 32-bits write are allowed otherwise we get a Kernel panic. Therefore add a custom memory copy and memset functions to deal with the above restriction. Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com> Link: https://lore.kernel.org/r/20230221170356.27923-1-iuliana.prodan@oss.nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-05-17remoteproc: rcar_rproc: Call of_node_put() on iteration errorMathieu Poirier
commit f8bae637d3d5e082b4ced71e28b16eb3ee0683c1 upstream. Function of_phandle_iterator_next() calls of_node_put() on the last device_node it iterated over, but when the loop exits prematurely it has to be called explicitly. Fixes: 285892a74f13 ("remoteproc: Add Renesas rcar driver") Cc: stable@vger.kernel.org Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20230320221826.2728078-4-mathieu.poirier@linaro.org Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-05-17remoteproc: imx_rproc: Call of_node_put() on iteration errorMathieu Poirier
commit 5ef074e805ecfd9a16dbb7b6b88bbfa8abad7054 upstream. Function of_phandle_iterator_next() calls of_node_put() on the last device_node it iterated over, but when the loop exits prematurely it has to be called explicitly. Fixes: b29b4249f8f0 ("remoteproc: imx_rproc: add i.MX specific parse fw hook") Cc: stable@vger.kernel.org Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Reviewed-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20230320221826.2728078-5-mathieu.poirier@linaro.org Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-05-17remoteproc: imx_dsp_rproc: Call of_node_put() on iteration errorMathieu Poirier
commit e0e01de8ee146986872e54e8365f4b4654819412 upstream. Function of_phandle_iterator_next() calls of_node_put() on the last device_node it iterated over, but when the loop exits prematurely it has to be called explicitly. Fixes: ec0e5549f358 ("remoteproc: imx_dsp_rproc: Add remoteproc driver for DSP on i.MX") Cc: stable@vger.kernel.org Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Acked-by: Shengjiu Wang <shengjiu.wang@gmail.com> Link: https://lore.kernel.org/r/20230320221826.2728078-6-mathieu.poirier@linaro.org Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-05-17remoteproc: st: Call of_node_put() on iteration errorMathieu Poirier
commit 8a74918948b40317a5b5bab9739d13dcb5de2784 upstream. Function of_phandle_iterator_next() calls of_node_put() on the last device_node it iterated over, but when the loop exits prematurely it has to be called explicitly. Fixes: 3df52ed7f269 ("remoteproc: st: add reserved memory support") Cc: stable@vger.kernel.org Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> Link: https://lore.kernel.org/r/20230320221826.2728078-3-mathieu.poirier@linaro.org Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-05-17remoteproc: stm32: Call of_node_put() on iteration errorMathieu Poirier
commit ccadca5baf5124a880f2bb50ed1ec265415f025b upstream. Function of_phandle_iterator_next() calls of_node_put() on the last device_node it iterated over, but when the loop exits prematurely it has to be called explicitly. Fixes: 13140de09cc2 ("remoteproc: stm32: add an ST stm32_rproc driver") Cc: stable@vger.kernel.org Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> Link: https://lore.kernel.org/r/20230320221826.2728078-2-mathieu.poirier@linaro.org Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-10remoteproc/mtk_scp: Move clk ops outside send_lockChen-Yu Tsai
commit e46ceea3148163166ef9b7bcac578e72dd30c064 upstream. Clocks are properly reference counted and do not need to be inside the lock range. Right now this triggers a false-positive lockdep warning on MT8192 based Chromebooks, through a combination of mtk-scp that has a cros-ec-rpmsg sub-device, the (actual) cros-ec I2C adapter registration, I2C client (not on cros-ec) probe doing i2c transfers and enabling clocks. This is a false positive because the cros-ec-rpmsg under mtk-scp does not have an I2C adapter, and also each I2C adapter and cros-ec instance have their own mutex. Move the clk operations outside of the send_lock range. Fixes: 63c13d61eafe ("remoteproc/mediatek: add SCP support for mt8183") Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230104083110.736377-1-wenst@chromium.org [Fixed "Fixes:" tag line] Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-10remoteproc: qcom_q6v5_mss: Use a carveout to authenticate modem headersSibi Sankar
[ Upstream commit 57f72170a2b2a362c35bb9407fc844eac5afdec1 ] Any access to the dynamically allocated metadata region by the application processor after assigning it to the remote Q6 will result in a XPU violation. Fix this by replacing the dynamically allocated memory region with a no-map carveout and unmap the modem metadata memory region before passing control to the remote Q6. Reported-and-tested-by: Amit Pundir <amit.pundir@linaro.org> Fixes: 6c5a9dc2481b ("remoteproc: qcom: Make secure world call for mem ownership switch") Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230117085840.32356-7-quic_sibis@quicinc.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10Revert "remoteproc: qcom_q6v5_mss: map/unmap metadata region before/after use"Christoph Hellwig
[ Upstream commit a899d542b687c9b04ccbd9eefabc829ba5fef791 ] This reverts commit fc156629b23a21181e473e60341e3a78af25a1d4. This commit manages to do three API violations at once: - dereference the return value of dma_alloc_attrs with the DMA_ATTR_NO_KERNEL_MAPPING mapping, which is clearly forbidden and will do the wrong thing on various dma mapping implementations. The fact that dma-direct uses a struct page as a cookie is an undocumented implementation detail - include dma-map-ops.h and use pgprot_dmacoherent despite a clear comment documenting that this is not acceptable - use of the VM_DMA_COHERENT for something that is not the dma-mapping code - use of VM_FLUSH_RESET_PERMS for vmap, while it is only supported for vmalloc Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230117085840.32356-6-quic_sibis@quicinc.com Stable-dep-of: 57f72170a2b2 ("remoteproc: qcom_q6v5_mss: Use a carveout to authenticate modem headers") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-01-07remoteproc: imx_rproc: Correct i.MX93 DRAM mappingPeng Fan
commit ee18f2715e85f4ef051851a0c4831ee7ad7d83b3 upstream. According to updated reference mannual, the M33 DRAM view of 0x[C,D]0000000 maps to A55 0xC0000000, so correct it. Fixes: 9222fabf0e39 ("remoteproc: imx_rproc: Support i.MX93") Signed-off-by: Peng Fan <peng.fan@nxp.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20221102111410.38737-1-peng.fan@oss.nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-01-07remoteproc: core: Do pm_relax when in RPROC_OFFLINE stateMaria Yu
commit 11c7f9e3131ad14b27a957496088fa488b153a48 upstream. Make sure that pm_relax() happens even when the remoteproc is stopped before the crash handler work is scheduled. Signed-off-by: Maria Yu <quic_aiquny@quicinc.com> Cc: stable <stable@vger.kernel.org> Fixes: a781e5aa5911 ("remoteproc: core: Prevent system suspend during remoteproc recovery") Link: https://lore.kernel.org/r/20221206015957.2616-2-quic_aiquny@quicinc.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-01-07remoteproc: imx_dsp_rproc: Add mutex protection for workqueueShengjiu Wang
commit 47e6ab07018edebf94ce873cf50a05ec76ff2dde upstream. The workqueue may execute late even after remoteproc is stopped or stopping, some resources (rpmsg device and endpoint) have been released in rproc_stop_subdevices(), then rproc_vq_interrupt() accessing these resources will cause kennel dump. Call trace: virtqueue_add_split+0x1ac/0x560 virtqueue_add_inbuf+0x4c/0x60 rpmsg_recv_done+0x15c/0x294 vring_interrupt+0x6c/0xa4 rproc_vq_interrupt+0x30/0x50 imx_dsp_rproc_vq_work+0x24/0x40 [imx_dsp_rproc] process_one_work+0x1d0/0x354 worker_thread+0x13c/0x470 kthread+0x154/0x160 ret_from_fork+0x10/0x20 Add mutex protection in imx_dsp_rproc_vq_work(), if the state is not running, then just skip calling rproc_vq_interrupt(). Also the flush workqueue operation can't be added in rproc stop for the same reason. The call sequence is rproc_shutdown -> rproc_stop ->rproc_stop_subdevices ->rproc->ops->stop() ->imx_dsp_rproc_stop ->flush_work -> rproc_vq_interrupt The resource needed by rproc_vq_interrupt has been released in rproc_stop_subdevices, so flush_work is not safe to be called in imx_dsp_rproc_stop. Fixes: ec0e5549f358 ("remoteproc: imx_dsp_rproc: Add remoteproc driver for DSP on i.MX") Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/1664524216-19949-1-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-12-31remoteproc: qcom: q6v5: Fix missing clk_disable_unprepare() in ↵Shang XiaoJing
q6v5_wcss_qcs404_power_on() [ Upstream commit 7ff5d60f18bba5cbaf17b2926aa9da44d5beca01 ] q6v5_wcss_qcs404_power_on() have no fail path for readl_poll_timeout(). Add fail path for readl_poll_timeout(). Fixes: 0af65b9b915e ("remoteproc: qcom: wcss: Add non pas wcss Q6 support for QCS404") Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221204082757.18850-1-shangxiaojing@huawei.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31remoteproc: qcom_q6v5_pas: Fix missing of_node_put() in ↵Yuan Can
adsp_alloc_memory_region() [ Upstream commit 38e7d9c19276832ebb0277f415b9214bf7baeb37 ] The pointer node is returned by of_parse_phandle() with refcount incremented. We should use of_node_put() on it when done. Fixes: b9e718e950c3 ("remoteproc: Introduce Qualcomm ADSP PIL") Signed-off-by: Yuan Can <yuancan@huawei.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221203070639.15128-1-yuancan@huawei.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31remoteproc: qcom_q6v5_pas: detach power domains on removeLuca Weiss
[ Upstream commit 34d01df00b84127be04c914fc9f8e8be1fcdf851 ] We need to detach from the power domains also on remove, not just on probe fail so a subsequent probe works as expected. Otherwise the following error appears on re-probe: [ 29.452005] sysfs: cannot create duplicate filename '/devices/genpd:0:3000000.remoteproc' [ 29.477121] CPU: 1 PID: 483 Comm: sh Tainted: G W 6.1.0-rc4-00075-g71a113770bda #78 [ 29.510319] Hardware name: Fairphone 4 (DT) [ 29.538335] Call trace: [ 29.564470] dump_backtrace.part.0+0xe0/0xf0 [ 29.592602] show_stack+0x18/0x30 [ 29.619616] dump_stack_lvl+0x64/0x80 [ 29.646834] dump_stack+0x18/0x34 [ 29.673541] sysfs_warn_dup+0x60/0x7c [ 29.700592] sysfs_create_dir_ns+0xec/0x110 [ 29.728057] kobject_add_internal+0xb8/0x374 [ 29.755530] kobject_add+0x9c/0x104 [ 29.782072] device_add+0xbc/0x8a0 [ 29.808445] device_register+0x20/0x30 [ 29.835175] genpd_dev_pm_attach_by_id+0xa4/0x190 [ 29.862851] genpd_dev_pm_attach_by_name+0x3c/0xb0 [ 29.890472] dev_pm_domain_attach_by_name+0x20/0x30 [ 29.918212] adsp_probe+0x278/0x580 [ 29.944384] platform_probe+0x68/0xc0 [ 29.970603] really_probe+0xbc/0x2dc [ 29.996662] __driver_probe_device+0x78/0xe0 [ 30.023491] device_driver_attach+0x48/0xac [ 30.050215] bind_store+0xb8/0x114 [ 30.075957] drv_attr_store+0x24/0x3c [ 30.101874] sysfs_kf_write+0x44/0x54 [ 30.127751] kernfs_fop_write_iter+0x120/0x1f0 [ 30.154448] vfs_write+0x1ac/0x380 [ 30.179937] ksys_write+0x70/0x104 [ 30.205274] __arm64_sys_write+0x1c/0x2c [ 30.231060] invoke_syscall+0x48/0x114 [ 30.256594] el0_svc_common.constprop.0+0x44/0xec [ 30.283183] do_el0_svc+0x2c/0xd0 [ 30.308320] el0_svc+0x2c/0x84 [ 30.333059] el0t_64_sync_handler+0xf4/0x120 [ 30.359001] el0t_64_sync+0x18c/0x190 [ 30.384385] kobject_add_internal failed for genpd:0:3000000.remoteproc with -EEXIST, don't try to register things with the same name in the same directory. [ 30.406029] remoteproc remoteproc0: releasing 3000000.remoteproc [ 30.416064] qcom_q6v5_pas: probe of 3000000.remoteproc failed with error -17 Fixes: 17ee2fb4e856 ("remoteproc: qcom: pas: Vote for active/proxy power domains") Reviewed-by: Sibi Sankar <quic_sibis@quicinc.com> Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221118090816.100012-2-luca.weiss@fairphone.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31remoteproc: qcom_q6v5_pas: disable wakeup on probe fail or removeLuca Weiss
[ Upstream commit 9a70551996e699fda262e8d54bbd41739d7aad6d ] Leaving wakeup enabled during probe fail (-EPROBE_DEFER) or remove makes the subsequent probe fail. [ 3.749454] remoteproc remoteproc0: releasing 3000000.remoteproc [ 3.752949] qcom_q6v5_pas: probe of 3000000.remoteproc failed with error -17 [ 3.878935] remoteproc remoteproc0: releasing 4080000.remoteproc [ 3.887602] qcom_q6v5_pas: probe of 4080000.remoteproc failed with error -17 [ 4.319552] remoteproc remoteproc0: releasing 8300000.remoteproc [ 4.332716] qcom_q6v5_pas: probe of 8300000.remoteproc failed with error -17 Fix this by disabling wakeup in both cases so the driver can properly probe on the next try. Fixes: a781e5aa5911 ("remoteproc: core: Prevent system suspend during remoteproc recovery") Fixes: dc86c129b4fb ("remoteproc: qcom: pas: Mark devices as wakeup capable") Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org> Reviewed-by: Sibi Sankar <quic_sibis@quicinc.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221118090816.100012-1-luca.weiss@fairphone.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31remoteproc: qcom: q6v5: Fix potential null-ptr-deref in q6v5_wcss_init_mmio()Shang XiaoJing
[ Upstream commit f360e2b275efbb745ba0af8b47d9ef44221be586 ] q6v5_wcss_init_mmio() will call platform_get_resource_byname() that may fail and return NULL. devm_ioremap() will use res->start as input, which may causes null-ptr-deref. Check the ret value of platform_get_resource_byname() to avoid the null-ptr-deref. Fixes: 0af65b9b915e ("remoteproc: qcom: wcss: Add non pas wcss Q6 support for QCS404") Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221125021641.29392-1-shangxiaojing@huawei.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31remoteproc: sysmon: fix memory leak in qcom_add_sysmon_subdev()Gaosheng Cui
[ Upstream commit e01ce676aaef3b13d02343d7e70f9637d93a3367 ] The kfree() should be called when of_irq_get_byname() fails or devm_request_threaded_irq() fails in qcom_add_sysmon_subdev(), otherwise there will be a memory leak, so add kfree() to fix it. Fixes: 027045a6e2b7 ("remoteproc: qcom: Add shutdown-ack irq") Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221129105650.1539187-1-cuigaosheng1@huawei.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31remoteproc: core: Auto select rproc-virtio device idShengjiu Wang
[ Upstream commit 65fcf3872f83d63fb7268e05d4b02640df14126e ] With multiple remoteproc device, there will below error: sysfs: cannot create duplicate filename '/bus/platform/devices/rproc-virtio.0' The rvdev_data.index is duplicate, that cause issue, so need to use the PLATFORM_DEVID_AUTO instead. After fixing device name it becomes something like: /bus/platform/devices/rproc-virtio.2.auto Fixes: 1d7b61c06dc3 ("remoteproc: virtio: Create platform device for the remoteproc_virtio") Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com> Tested-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/1666100644-27010-1-git-send-email-shengjiu.wang@nxp.com [Fixed typographical error in comment block] Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-10-05remoteproc: virtio: Fix warning on bindings by removing the of_match_tableArnaud Pouliquen
The checkpatch tool complains that "virtio,rproc" is not documented. But it is not possible to probe the device "rproc-virtio" by declaring it in the device tree. So documenting it in the bindings does not make sense. This commit solves the checkpatch warning by suppressing the useless of_match_table. Suggested-by: Rob Herring <robh@kernel.org> Fixes: 1d7b61c06dc3 ("remoteproc: virtio: Create platform device for the remoteproc_virtio") Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20221005081317.3411684-1-arnaud.pouliquen@foss.st.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2022-09-28remoteproc: Support attach recovery after rproc crashPeng Fan
Current logic only support main processor to stop/start the remote processor after crash. However to SoC, such as i.MX8QM/QXP, the remote processor could do attach recovery after crash and trigger watchdog to reboot itself. It does not need main processor to load image, or stop/start remote processor. Introduce two functions: rproc_attach_recovery, rproc_boot_recovery for the two cases. Boot recovery is as before, let main processor to help recovery, while attach recovery is to recover itself without help. To attach recovery, we only do detach and attach. Acked-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20220928064756.4059662-3-peng.fan@oss.nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2022-09-28remoteproc: Introduce rproc featuresPeng Fan
remote processor may support: - boot recovery with help from main processor - self recovery without help from main processor - iommu - etc Introduce rproc features could simplify code to avoid adding more bool flags Acked-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20220928064756.4059662-2-peng.fan@oss.nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2022-09-21remoteproc: virtio: Create platform device for the remoteproc_virtioArnaud Pouliquen
Define a platform driver to manage the remoteproc virtio device as a platform devices. The platform device allows to pass rproc_vdev_data platform data to specify properties that are stored in the rproc_vdev structure. Such approach will allow to preserve legacy remoteproc virtio device creation but also to probe the device using device tree mechanism. remoteproc_virtio.c update: - Add rproc_virtio_driver platform driver. The probe ops replaces the rproc_rvdev_add_device function. - All reference to the rvdev->dev has been updated to rvdev-pdev->dev. - rproc_rvdev_release is removed as associated to the rvdev device. - The use of rvdev->kref counter is replaced by get/put_device on the remoteproc virtio platform device. - The vdev device no longer increments rproc device counter. increment/decrement is done in rproc_virtio_probe/rproc_virtio_remove function in charge of the vrings allocation/free. remoteproc_core.c update: Migrate from the rvdev device to the rvdev platform device. From this patch, when a vdev resource is found in the resource table the remoteproc core register a platform device. Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> Link: https://lore.kernel.org/r/20220921135044.917140-5-arnaud.pouliquen@foss.st.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2022-09-21remoteproc: Move rproc_vdev management to remoteproc_virtio.cArnaud Pouliquen
Move functions related to the management of the rproc_vdev structure in the remoteproc_virtio.c. The aim is to decorrelate as possible the virtio management from the core part. Due to the strong correlation between the vrings and the resource table the rproc_alloc/parse/free_vring functions are kept in the remoteproc core. Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> Link: https://lore.kernel.org/r/20220921135044.917140-4-arnaud.pouliquen@foss.st.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2022-09-21remoteproc: core: Introduce rproc_add_rvdev functionArnaud Pouliquen
The rproc structure contains a list of registered rproc_vdev structure. To be able to move the management of the rproc_vdev structure in remoteproc_virtio.c (i.e rproc_rvdev_add_device function), introduce the rproc_add_rvdev and rproc_remove_rvdev functions. Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> Link: https://lore.kernel.org/r/20220921135044.917140-3-arnaud.pouliquen@foss.st.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2022-09-21remoteproc: core: Introduce rproc_rvdev_add_device functionArnaud Pouliquen
In preparation of the migration of the management of rvdev in remoteproc_virtio.c, this patch spins off a new function to manage the remoteproc virtio device creation. The rproc_rvdev_add_device will be moved to remoteproc_virtio.c. The rproc_vdev_data structure is introduced to provide information for the rvdev creation. This structure allows to manage the rvdev and vrings allocation in the rproc_rvdev_add_device function. Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> Link: https://lore.kernel.org/r/20220921135044.917140-2-arnaud.pouliquen@foss.st.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2022-09-19remoteproc: Harden rproc_handle_vdev() against integer overflowDan Carpenter
The struct_size() macro protects against integer overflows but adding "+ rsc->config_len" introduces the risk of integer overflows again. Use size_add() to be safe. Fixes: c87846571587 ("remoteproc: use struct_size() helper") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com> Link: https://lore.kernel.org/r/YyMyoPoGOJUcEpZT@kili Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2022-09-19remoteproc/keystone: Switch to using gpiod APIDmitry Torokhov
This patch switches the driver away from legacy gpio/of_gpio API to gpiod API, and removes use of of_get_named_gpio_flags() which I want to make private to gpiolib. Note that there is a behavior change in the driver: previously the driver did not actually request GPIO, it simply parsed GPIO number out of device tree and poked at it. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/Yxe20ehiOnitDGus@google.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2022-09-19drivers/remoteproc: Fix repeated words in commentswangjianli
Delete the redundant word 'in'. Signed-off-by: wangjianli <wangjianli@cdjrlc.com> Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com> Link: https://lore.kernel.org/r/20220908123237.16911-1-wangjianli@cdjrlc.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2022-08-23remoteproc: imx_dsp_rproc: fix argument 2 of rproc_mem_entry_initShengjiu Wang
There are sparse warning: drivers/remoteproc/imx_dsp_rproc.c:602:49: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void *va @@ got void [noderef] __iomem *[assigned] cpu_addr @@ drivers/remoteproc/imx_dsp_rproc.c:602:49: sparse: expected void *va drivers/remoteproc/imx_dsp_rproc.c:602:49: sparse: got void [noderef] __iomem *[assigned] cpu_addr drivers/remoteproc/imx_dsp_rproc.c:638:49: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void *va @@ got void [noderef] __iomem *[assigned] cpu_addr @@ drivers/remoteproc/imx_dsp_rproc.c:638:49: sparse: expected void *va drivers/remoteproc/imx_dsp_rproc.c:638:49: sparse: got void [noderef] __iomem *[assigned] cpu_addr Fixes: ec0e5549f358 ("remoteproc: imx_dsp_rproc: Add remoteproc driver for DSP on i.MX") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Link: https://lore.kernel.org/r/1660567398-24495-1-git-send-email-shengjiu.wang@nxp.com Acked-by: Mukesh Ojha <quic_mojha@quicinc.com> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2022-08-23remoteproc: imx_rproc: Simplify some error messageChristophe JAILLET
dev_err_probe() already prints the error code in a human readable way, so there is no need to duplicate it as a numerical value at the end of the message. While at it, remove 'ret' that is mostly useless. Fixes: 2df7062002d0 ("remoteproc: imx_proc: enable virtio/mailbox") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/6b9343c2688117a340661d8ee491c2962c54a09a.1659736936.git.christophe.jaillet@wanadoo.fr Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2022-08-16virtio: Revert "virtio: find_vqs() add arg sizes"Michael S. Tsirkin
This reverts commit a10fba0377145fccefea4dc4dd5915b7ed87e546: the proposed API isn't supported on all transports but no effort was made to address this. It might not be hard to fix if we want to: maybe just rename size to size_hint and make sure legacy transports ignore the hint. But it's not sure what the benefit is in any case, so let's drop it. Fixes: a10fba037714 ("virtio: find_vqs() add arg sizes") Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20220816053602.173815-8-mst@redhat.com>
2022-08-12Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhostLinus Torvalds
Pull virtio updates from Michael Tsirkin: - A huge patchset supporting vq resize using the new vq reset capability - Features, fixes, and cleanups all over the place * tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost: (88 commits) vdpa/mlx5: Fix possible uninitialized return value vdpa_sim_blk: add support for discard and write-zeroes vdpa_sim_blk: add support for VIRTIO_BLK_T_FLUSH vdpa_sim_blk: make vdpasim_blk_check_range usable by other requests vdpa_sim_blk: check if sector is 0 for commands other than read or write vdpa_sim: Implement suspend vdpa op vhost-vdpa: uAPI to suspend the device vhost-vdpa: introduce SUSPEND backend feature bit vdpa: Add suspend operation virtio-blk: Avoid use-after-free on suspend/resume virtio_vdpa: support the arg sizes of find_vqs() vhost-vdpa: Call ida_simple_remove() when failed vDPA: fix 'cast to restricted le16' warnings in vdpa.c vDPA: !FEATURES_OK should not block querying device config space vDPA/ifcvf: support userspace to query features and MQ of a management device vDPA/ifcvf: get_config_size should return a value no greater than dev implementation vhost scsi: Allow user to control num virtqueues vhost-scsi: Fix max number of virtqueues vdpa/mlx5: Support different address spaces for control and data vdpa/mlx5: Implement susupend virtqueue callback ...
2022-08-11virtio: find_vqs() add arg sizesXuan Zhuo
find_vqs() adds a new parameter sizes to specify the size of each vq vring. NULL as sizes means that all queues in find_vqs() use the maximum size. A value in the array is 0, which means that the corresponding queue uses the maximum size. In the split scenario, the meaning of size is the largest size, because it may be limited by memory, the virtio core will try a smaller size. And the size is power of 2. Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Acked-by: Jason Wang <jasowang@redhat.com> Message-Id: <20220801063902.129329-34-xuanzhuo@linux.alibaba.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-08-11virtio: record the maximum queue num supported by the device.Xuan Zhuo
virtio-net can display the maximum (supported by hardware) ring size in ethtool -g eth0. When the subsequent patch implements vring reset, it can judge whether the ring size passed by the driver is legal based on this. Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com> Acked-by: Jason Wang <jasowang@redhat.com> Message-Id: <20220801063902.129329-2-xuanzhuo@linux.alibaba.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-08-11remoteproc: rename len of rpoc_vring to numXuan Zhuo
Rename the member len in the structure rpoc_vring to num. And remove 'in bytes' from the comment of it. This is misleading. Because this actually refers to the size of the virtio vring to be created. The unit is not bytes. Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com> Message-Id: <20220624025621.128843-2-xuanzhuo@linux.alibaba.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-08-08remoteproc: qcom_q6v5_pas: Do not fail if regulators are not foundManivannan Sadhasivam
devm_regulator_get_optional() API will return -ENODEV if the regulator was not found. For the optional supplies CX, PX we should not fail in that case but rather continue. So let's catch that error and continue silently if those regulators are not found. The commit 3f52d118f992 ("remoteproc: qcom_q6v5_pas: Deal silently with optional px and cx regulators") was supposed to do the same but it missed the fact that devm_regulator_get_optional() API returns -ENODEV when the regulator was not found. Cc: Abel Vesa <abel.vesa@linaro.org> Fixes: 3f52d118f992 ("remoteproc: qcom_q6v5_pas: Deal silently with optional px and cx regulators") Reported-by: Steev Klimaszewski <steev@kali.org> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Steev Klimaszewski <steev@kali.org> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220801053939.12556-1-manivannan.sadhasivam@linaro.org
2022-07-25drivers/remoteproc: fix repeated words in commentswangjianli
Delete the redundant word 'in'. Signed-off-by: wangjianli <wangjianli@cdjrlc.com> Link: https://lore.kernel.org/r/20220724073418.15793-1-wangjianli@cdjrlc.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2022-07-18remoteproc: Directly use ida_alloc()/free()keliu
Use ida_alloc()/ida_free() instead of deprecated ida_simple_get()/ida_simple_remove() . Signed-off-by: keliu <liuke94@huawei.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220527073832.2474641-1-liuke94@huawei.com
2022-07-18remoteproc: Use unbounded workqueue for recovery workMukesh Ojha
There could be a scenario when there is too much load on a core (n number of tasks which is affined) or in a case when multiple rproc subsystem is going for recovery, they queue their recovery work to one core so even though subsystem are independent their recovery will be delayed if one of the subsystem recovery work is taking more time in completing. If we make this queue unbounded, the recovery work could be picked on any cpu. This patch is trying to address this. Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/1650367554-15510-1-git-send-email-quic_mojha@quicinc.com
2022-07-18remoteproc: using pm_runtime_resume_and_get instead of pm_runtime_get_syncMinghao Chi
Using pm_runtime_resume_and_get is more appropriate for simplifing code Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220411013656.2517150-1-chi.minghao@zte.com.cn
2022-07-18remoteproc: qcom_q6v5_pas: Deal silently with optional px and cx regulatorsAbel Vesa
Use _get_optional as some platforms might not provide the px and cx regulators. This avoids printing the following for each unavailable regulator: [ 4.350229] qcom_q6v5_pas 5c00000.remoteproc: supply cx not found, using dummy regulator [ 4.374224] qcom_q6v5_pas 5c00000.remoteproc: supply px not found, using dummy regulator Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220713152835.3848875-1-abel.vesa@linaro.org
2022-07-18remoteproc: sysmon: Send sysmon state only for running rprocsSiddharth Gupta
When a new remoteproc boots up, send the sysmon state notification of only running remoteprocs. Sending state of remoteprocs booting up in parallel can cause a race between SSR clients of the remoteproc that is booting up and the sysmon notification for the same remoteproc, resulting in an inconsistency between which state the remoteproc that is booting up in parallel. For example - if remoteproc A and B crash one after the other, after remoteproc A boots up, if the remoteproc A tries to get the state of remoteproc B before the sysmon subdevice for B is invoked but after the ssr subdevice of B has been invoked, clients on remoteproc A might get confused when the sysmon notification indicates a different state. Signed-off-by: Siddharth Gupta <sidgup@codeaurora.org> Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/1657022900-2049-8-git-send-email-quic_sibis@quicinc.com
2022-07-18remoteproc: sysmon: Wait for SSCTL service to come upSibi Sankar
The SSCTL service comes up after a finite time when the remote Q6 comes out of reset. Any graceful shutdowns requested during this period will be a NOP and abrupt tearing down of the glink channel might lead to pending transactions on the remote Q6 side and will ultimately lead to a fatal error. Fix this by waiting for the SSCTL service when a graceful shutdown is requested. Fixes: 1fb82ee806d1 ("remoteproc: qcom: Introduce sysmon") Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/1657022900-2049-7-git-send-email-quic_sibis@quicinc.com
2022-07-18remoteproc: qcom: q6v5: Set q6 state to offline on receiving wdog irqSiddharth Gupta
Due to firmware bugs on the Q6 the hardware watchdog irq can be triggered multiple times. As the remoteproc framework schedules work items for the recovery process, if the other threads do not get a chance to run before recovery is completed the proceeding threads will see the state of the remoteproc as running and kill the remoteproc while it is running. This can result in various SMMU and NOC errors. This change sets the state of the remoteproc to offline whenever a watchdog irq is received. Signed-off-by: Siddharth Gupta <sidgup@codeaurora.org> Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/1657022900-2049-6-git-send-email-quic_sibis@quicinc.com
2022-07-18remoteproc: qcom: pas: Check if coredump is enabledSiddharth Gupta
Client drivers need to check if coredump is enabled for the rproc before continuing with coredump generation. This change adds a check in the PAS driver. Fixes: 8ed8485c4f05 ("remoteproc: qcom: Add capability to collect minidumps") Signed-off-by: Siddharth Gupta <sidgup@codeaurora.org> Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/1657022900-2049-5-git-send-email-quic_sibis@quicinc.com
2022-07-18remoteproc: qcom: pas: Mark devices as wakeup capableSiddharth Gupta
device_wakeup_enable() on its own is not capable of setting device as wakeup capable, it needs to be used in conjunction with device_set_wakeup_capable(). The device_init_wakeup() calls both these functions on the device passed. Fixes: a781e5aa5911 ("remoteproc: core: Prevent system suspend during remoteproc recovery") Signed-off-by: Siddharth Gupta <sidgup@codeaurora.org> Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/1657022900-2049-4-git-send-email-quic_sibis@quicinc.com
2022-07-18remoteproc: qcom: pas: Mark va as io memorySiddharth Gupta
The pas driver remaps the entire carveout region using the dev_ioremap_wc() call, which is then used in the adsp_da_to_va() calls made by the rproc framework. This change marks the va returned by this call as an iomem va. Signed-off-by: Siddharth Gupta <sidgup@codeaurora.org> Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/1657022900-2049-3-git-send-email-quic_sibis@quicinc.com
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-26 07:22:10 +0000