05.03.2020, 19:17, "Mathieu Poirier" <mathieu.poirier@xxxxxxxxxx>: > On Wed, 4 Mar 2020 at 07:25, Nikita Shubin <NShubin@xxxxxxxxxx> wrote: >> add kick method that does nothing, to avoid errors in rproc_virtio_notify. >> >> Signed-off-by: Nikita Shubin <NShubin@xxxxxxxxxx> >> --- >> drivers/remoteproc/imx_rproc.c | 6 ++++++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c >> index 3e72b6f38d4b..796b6b86550a 100644 >> --- a/drivers/remoteproc/imx_rproc.c >> +++ b/drivers/remoteproc/imx_rproc.c >> @@ -240,9 +240,15 @@ static void *imx_rproc_da_to_va(struct rproc *rproc, u64 da, int len) >> return va; >> } >> >> +static void imx_rproc_kick(struct rproc *rproc, int vqid) >> +{ >> + >> +} >> + > > If rproc::kick() is empty, how does the MCU know there is packets to > fetch in the virtio queues? Well, of course it doesn't i understand this perfectly - just following documentation citing: | Every remoteproc implementation should at least provide the ->start and ->stop | handlers. If rpmsg/virtio functionality is also desired, then the ->kick handler | should be provided as well. But i as i mentioned in "remoteproc: Fix NULL pointer dereference in rproc_virtio_notify" kick method will be called if "resource_table exists in firmware and has "Virtio device entry" defined" anyway, the imx_rproc is not in control of what exactly it is booting, so such situation can occur. > >> static const struct rproc_ops imx_rproc_ops = { >> .start = imx_rproc_start, >> .stop = imx_rproc_stop, >> + .kick = imx_rproc_kick, >> .da_to_va = imx_rproc_da_to_va, >> }; >> >> -- >> 2.24.1