linux-kernel - Re: [PATCH 1/2] remoteproc: imx

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANLsYkxj=1o8Y0V0WedbVirj9seZSArWeCvQvwk+N7wZa2_hPQ@mail.gmail.com>
Date:   Thu, 5 Mar 2020 10:54:22 -0700
From:   Mathieu Poirier <mathieu.poirier@...aro.org>
To:     nikita.shubin@...uefel.me
Cc:     Nikita Shubin <nshubin@...con.com>,
        Ohad Ben-Cohen <ohad@...ery.com>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Fabio Estevam <festevam@...il.com>,
        NXP Linux Team <linux-imx@....com>,
        linux-remoteproc <linux-remoteproc@...r.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] remoteproc: imx_rproc: dummy kick method

On Thu, 5 Mar 2020 at 10:29, <nikita.shubin@...uefel.me> wrote:
>
>
>
> 05.03.2020, 19:17, "Mathieu Poirier" <mathieu.poirier@...aro.org>:
> > On Wed, 4 Mar 2020 at 07:25, Nikita Shubin <NShubin@...con.com> wrote:
> >>  add kick method that does nothing, to avoid errors in rproc_virtio_notify.
> >>
> >>  Signed-off-by: Nikita Shubin <NShubin@...con.com>
> >>  ---
> >>   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.

If I understand correctly, the MCU can boot images that have a virtio
device in its resource table and still do useful work even if the
virtio device/rpmsg bus can't be setup - is this correct?

Thanks,
Mathieu

>
> >
> >>   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