kernel/linux.git/drivers/remoteproc, branch v5.15.7

remoteproc: imx_rproc: Fix rsc-table name

2021-11-18T18:17:18+00:00

commit e90547d59d4e29e269e22aa6ce590ed0b41207d2 upstream. Usually the dash '-' is preferred in node name. So far, not dts in upstream kernel, so we just update node name in driver. Cc: Bjorn Andersson Cc: Mathieu Poirier Fixes: 5e4c1243071d ("remoteproc: imx_rproc: support remote cores booted before Linux Kernel") Reviewed-and-tested-by: Peng Fan Signed-off-by: Dong Aisheng Signed-off-by: Peng Fan Cc: stable Link: https://lore.kernel.org/r/20210910090621.3073540-6-peng.fan@oss.nxp.com Signed-off-by: Mathieu Poirier Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman

remoteproc: imx_rproc: Fix ignoring mapping vdev regions

2021-11-18T18:17:18+00:00

commit afe670e23af91d8a74a8d7049f6e0984bbf6ea11 upstream. vdev regions are typically named vdev0buffer, vdev0ring0, vdev0ring1 and etc. Change to strncmp to cover them all. Fixes: 8f2d8961640f ("remoteproc: imx_rproc: ignore mapping vdev regions") Reviewed-and-tested-by: Peng Fan Signed-off-by: Dong Aisheng Signed-off-by: Peng Fan Cc: stable Link: https://lore.kernel.org/r/20210910090621.3073540-5-peng.fan@oss.nxp.com Signed-off-by: Mathieu Poirier Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman

remoteproc: Fix the wrong default value of is_iomem

2021-11-18T18:17:18+00:00

commit 970675f61bf5761d7e5326f6e4df995ecdba5e11 upstream. Currently the is_iomem is a random value in the stack which may be default to true even on those platforms that not use iomem to store firmware. Cc: Bjorn Andersson Cc: Mathieu Poirier Fixes: 40df0a91b2a5 ("remoteproc: add is_iomem to da_to_va") Reviewed-and-tested-by: Peng Fan Signed-off-by: Dong Aisheng Signed-off-by: Peng Fan Cc: stable Link: https://lore.kernel.org/r/20210910090621.3073540-3-peng.fan@oss.nxp.com Signed-off-by: Mathieu Poirier Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman

remoteproc: elf_loader: Fix loading segment when is_iomem true

2021-11-18T18:17:18+00:00

commit 24acbd9dc934f5d9418a736c532d3970a272063e upstream. It seems luckliy work on i.MX platform, but it is wrong. Need use memcpy_toio, not memcpy_fromio. Fixes: 40df0a91b2a5 ("remoteproc: add is_iomem to da_to_va") Tested-by: Dong Aisheng (i.MX8MQ) Reported-by: kernel test robot Reported-by: Dong Aisheng Signed-off-by: Peng Fan Cc: stable Link: https://lore.kernel.org/r/20210910090621.3073540-2-peng.fan@oss.nxp.com Signed-off-by: Mathieu Poirier Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman

remoteproc: Fix a memory leak in an error handling path in 'rproc_handle_vdev()'

2021-11-18T18:17:01+00:00

[ Upstream commit 0374a4ea7269645c46c3eb288526ea072fa19e79 ] If 'copy_dma_range_map() fails, the memory allocated for 'rvdev' will leak. Move the 'copy_dma_range_map()' call after the device registration so that 'rproc_rvdev_release()' can be called to free some resources. Also, branch to the error handling path if 'copy_dma_range_map()' instead of a direct return to avoid some other leaks. Fixes: e0d072782c73 ("dma-mapping: introduce DMA range map, supplanting dma_pfn_offset") Signed-off-by: Christophe JAILLET Reviewed-by: Jim Quinlan Reviewed-by: Mathieu Poirier Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/e6d0dad6620da4fdf847faa903f79b735d35f262.1630755377.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin

remoteproc: imx_rproc: Fix TCM io memory type

2021-11-18T18:16:59+00:00

[ Upstream commit 91bb26637353f35241f5472eedf3202ebe13e2e5 ] is_iomem was introduced in the commit 40df0a91b2a5 ("remoteproc: add is_iomem to da_to_va"), but the driver seemed missed to provide the io type correctly. This patch updates remoteproc driver to indicate the TCM on IMX are io memories. Without the change, remoteproc kick will fail. Cc: Bjorn Andersson Cc: Mathieu Poirier Cc: Peng Fan Reviewed-and-tested-by: Peng Fan Fixes: 79806d32d5aa ("remoteproc: imx_rproc: support i.MX8MN/P") Signed-off-by: Dong Aisheng Signed-off-by: Peng Fan stable Link: https://lore.kernel.org/r/20210910090621.3073540-4-peng.fan@oss.nxp.com Signed-off-by: Mathieu Poirier Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin

remoteproc: q6v5_pas: Add sdm660 ADSP PIL compatible

2021-08-04T17:37:32+00:00

This chipset seems to work fine with the "generic" configuration. Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20210728215212.18217-2-konrad.dybcio@somainline.org [bjorn: Use "-pas" suffix for remoteprocs using TrustZone] Signed-off-by: Bjorn Andersson

remoteproc: use freezable workqueue for crash notifications

2021-07-28T19:57:36+00:00

When a remoteproc has crashed, rproc_report_crash() is called to handle whatever recovery is desired. This can happen at almost any time, often triggered by an interrupt, though it can also be initiated by a write to debugfs file remoteproc/remoteproc*/crash. When a crash is reported, the crash handler worker is scheduled to run (rproc_crash_handler_work()). One thing that worker does is call rproc_trigger_recovery(), which calls rproc_stop(). That calls the ->stop method for any remoteproc subdevices before making the remote processor go offline. The Q6V5 modem remoteproc driver implements an SSR subdevice that notifies registered drivers when the modem changes operational state (prepare, started, stop/crash, unprepared). The IPA driver registers to receive these notifications. With that as context, I'll now describe the problem. There was a situation in which buggy modem firmware led to a modem crash very soon after system (AP) resume had begun. The crash caused a remoteproc SSR crash notification to be sent to the IPA driver. The problem was that, although system resume had begun, it had not yet completed, and the IPA driver was still in a suspended state. This scenario could happen to any driver that registers for these SSR notifications, because they are delivered without knowledge of the (suspend) state of registered recipient drivers. This patch offers a simple fix for this, by having the crash handling worker function run on the system freezable workqueue. This workqueue does not operate if user space is frozen (for suspend). As a result, the SSR subdevice only delivers its crash notification when the system is fully operational (i.e., neither suspended nor in suspend/resume transition). Tested-by: Siddharth Gupta Reviewed-by: Bjorn Andersson Reviewed-by: Mathieu Poirier Signed-off-by: Alex Elder Link: https://lore.kernel.org/r/20210519234418.1196387-2-elder@linaro.org Signed-off-by: Bjorn Andersson

remoteproc: fix an typo in fw_elf_get_class code comments

2021-07-28T19:57:30+00:00

Drop 'and' which looks like unnecessary. Fixes: 73516a33588c ("remoteproc: Add elf helpers to access elf64 and elf32 fields") Signed-off-by: Dong Aisheng Link: https://lore.kernel.org/r/20210706142156.952794-1-aisheng.dong@nxp.com Signed-off-by: Bjorn Andersson

remoteproc: qcom: wcnss: Fix race with iris probe

2021-07-28T19:57:30+00:00

The remoteproc driver is split between the responsibilities of getting the SoC-internal ARM core up and running and the external RF (aka "Iris") part configured. In order to satisfy the regulator framework's need of a struct device * to look up supplies this was implemented as two different drivers, using of_platform_populate() in the remoteproc part to probe the iris part. Unfortunately it's possible that the iris part probe defers on yet not available regulators and an attempt to start the remoteproc will have to be rejected, until this has been resolved. But there's no useful mechanism of knowing when this would be. Instead replace the of_platform_populate() and the iris probe with a function that rolls its own struct device, with the relevant of_node associated that is enough to acquire regulators and clocks specified in the DT node and that may propagate the EPROBE_DEFER back to the wcnss device's probe. Acked-by: Mathieu Poirier Reported-by: Anibal Limon Reported-by: Loic Poulain Tested-by: Anibal Limon Link: https://lore.kernel.org/r/20210312002251.3273013-1-bjorn.andersson@linaro.org Signed-off-by: Bjorn Andersson