From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: rishabhb@codeaurora.org
Cc: Alex Elder <elder@ieee.org>,
linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org,
tsoni@codeaurora.org, psodagud@codeaurora.org,
sidgup@codeaurora.org, linux-remoteproc-owner@vger.kernel.org
Subject: Re: [PATCH v5 1/2] remoteproc: qcom: Add per subsystem SSR notification
Date: Tue, 23 Jun 2020 22:28:01 -0700 [thread overview]
Message-ID: <20200624052801.GB407764@builder.lan> (raw)
In-Reply-To: <cb31dfb50079a1377cf27807a7b2eb3e@codeaurora.org>
On Tue 23 Jun 18:41 PDT 2020, rishabhb@codeaurora.org wrote:
> On 2020-06-23 14:45, Alex Elder wrote:
> > On 6/22/20 8:04 PM, Rishabh Bhatnagar wrote:
> > > Currently there is a single notification chain which is called
> > > whenever any
> > > remoteproc shuts down. This leads to all the listeners being
> > > notified, and
> > > is not an optimal design as kernel drivers might only be interested in
> > > listening to notifications from a particular remoteproc. Create a
> > > global
> > > list of remoteproc notification info data structures. This will hold
> > > the
> > > name and notifier_list information for a particular remoteproc. The
> > > API
> > > to register for notifications will use name argument to retrieve the
> > > notification info data structure and the notifier block will be
> > > added to
> > > that data structure's notification chain. Also move from blocking
> > > notifier
> > > to srcu notifer based implementation to support dynamic notifier head
> > > creation.
> > >
> > > Signed-off-by: Siddharth Gupta <sidgup@codeaurora.org>
> > > Signed-off-by: Rishabh Bhatnagar <rishabhb@codeaurora.org>
> >
> > Sorry, a few more comments, but I think your next one will
> > likely be fine.
> >
> > General:
> > - SSR subsystems are added but never removed. Note that
> > "qcom_common.o" can be built as a module, and if that
> > module were ever removed, memory allocated for these
> > subsystems would be leaked.
> Hi Alex,
> Thank you for reviewing this patchset quickly. This point was
> brought up by Bjorn and it was decided that I will push another patch on
> top in which I'll do the cleanup during module exit.
> > - Will a remoteproc subdev (and in particular, an SSR subdev)
> > ever be removed? What happens to entities that have
> > registered for SSR notifications in that case?
> In practice it should never be removed. If it is clients will
> never get notification about subsystem shutdown/powerup.
Given that clients make direct function calls into qcom_common.ko,
qcom_common.ko would not be possible to rmmod until all clients has been
rmmod'ed. As such there shouldn't be any remaining listeners, or
subdevices, when this happens.
Regards,
Bjorn
next prev parent reply other threads:[~2020-06-24 5:30 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-23 1:04 [PATCH v5 0/2] Extend SSR notifications framework Rishabh Bhatnagar
2020-06-23 1:04 ` [PATCH v5 1/2] remoteproc: qcom: Add per subsystem SSR notification Rishabh Bhatnagar
2020-06-23 21:45 ` Alex Elder
2020-06-24 1:41 ` rishabhb
2020-06-24 5:28 ` Bjorn Andersson [this message]
2020-06-23 1:04 ` [PATCH v5 2/2] remoteproc: qcom: Add notification types to SSR Rishabh Bhatnagar
2020-06-23 21:45 ` Alex Elder
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=20200624052801.GB407764@builder.lan \
--to=bjorn.andersson@linaro.org \
--cc=elder@ieee.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc-owner@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=psodagud@codeaurora.org \
--cc=rishabhb@codeaurora.org \
--cc=sidgup@codeaurora.org \
--cc=tsoni@codeaurora.org \
/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).