linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sjur BRENDELAND <sjur.brandeland@stericsson.com>
To: "Guzman Lugo, Fernando" <fernando.lugo@ti.com>
Cc: Ohad Ben-Cohen <ohad@wizery.com>, LKML <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH 2/3] remoteproc: recover a remoteproc when it has crashed
Date: Wed, 22 Aug 2012 13:57:32 +0200	[thread overview]
Message-ID: <81C3A93C17462B4BBD7E272753C1057923B95AC7F0@EXDCVYMBSTM005.EQ1STM.local> (raw)
In-Reply-To: <CACY--9EWSRWu9sxq62rmOwNR0tzzr-1HEwH4gnWd4z0xtrAKpw@mail.gmail.com>

Hi Fernando,

> > I think you drop the driver module's ref count during recovery, because
> > rproc_shutdown calls module_put(). Maybe you should move driver
> > ref count handling to rproc_add and rproc_type_release, instead of
> > rproc_boot() and rproc_shutdown()?
> 
> How could you remove the remoteproc modules then?
...
> At this point we have a circular dependency, omap_remoteproc depends on
> remoteproc and vice-versa. Making impossible to remove the remoteproc
> modules. So, I don't think it is a good idea to move module_get/put
> calls.

Yes, I see - you're right. What I proposed won't work.

> However, if you still have concerns about that or a valid testcase where
> that would have an unexpected behaviour we can think in a way to fix it.
> Probably just calling module_get/put inside  rproc_trigger_recover is
> the easiest way. Please let me know what you think.

My concern was unloading of pdev or driver modules durng async firmware
loading. However it turns out that my issue was that I was using
rproc_put() instead of rproc_del() when unloading my driver module.
So after fixing my driver your patch works fine even when unloading the
driver during firmware loading.

> > >+int rproc_trigger_recover(struct rproc *rproc)
> > >+{
> > >+      struct rproc_vdev *rvdev, *rvtmp;
> > >+
> > >+      dev_err(&rproc->dev, "recovering %s\n", rproc->name);
> > >+
> > >+      /* clean up remote vdev entries */
> > >+      list_for_each_entry_safe(rvdev, rvtmp, &rproc->rvdevs, node)
> > >+              rproc_remove_virtio_dev(rvdev);
> > ...
> > Is this safe? Are you guaranteed that rproc->power
> > is counted down to zero at this point.
...
> > I think you should wait for the rproc->power count to go to zero
> > before initiating the firmware_loading. You could e.g.
> > move firmware_loading to rproc_shutdown(), or add a
> > completion.
> 
> Yes, that sounds good and it will work when we supports
> rproc_boot/shutdown > calls from anywhere and not only from
> rpmsg module(find_vqs). Also, I think with that wait_for_completion
> inside rproc_trigger_recover will make more clear how the recovery
> is performed (actually the need for ref counter to
> become 0 in order to work).
> 
> I will try that and send a new patch to get more comments.


Ok, looking forward to your next patch then.

Regards,
Sjur

  reply	other threads:[~2012-08-22 11:57 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-20 13:07 [PATCH 2/3] remoteproc: recover a remoteproc when it has crashed Sjur Brændeland
2012-08-20 20:45 ` Guzman Lugo, Fernando
2012-08-22 11:57   ` Sjur BRENDELAND [this message]
  -- strict thread matches above, loose matches on Subject: below --
2012-08-08 23:07 [PATCH 0/3] remoteproc: introduce rproc recovery Fernando Guzman Lugo
2012-08-08 23:07 ` [PATCH 2/3] remoteproc: recover a remoteproc when it has crashed Fernando Guzman Lugo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=81C3A93C17462B4BBD7E272753C1057923B95AC7F0@EXDCVYMBSTM005.EQ1STM.local \
    --to=sjur.brandeland@stericsson.com \
    --cc=fernando.lugo@ti.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ohad@wizery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).