From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Jeremy McNicoll <jmcnicol@redhat.com>
Cc: Ohad Ben-Cohen <ohad@wizery.com>,
Will Newton <will.newton@gmail.com>,
linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-msm@vger.kernel.org, Chris Lew <clew@quicinc.com>
Subject: Re: [PATCH 2/5] rpmsg: smd: Create device for all channels
Date: Fri, 2 Feb 2018 14:57:01 -0800 [thread overview]
Message-ID: <20180202225701.GJ12728@builder> (raw)
In-Reply-To: <20180127010152.GA32527@mini-rhel.redhat.com>
On Fri 26 Jan 17:01 PST 2018, Jeremy McNicoll wrote:
> On Tue, Dec 12, 2017 at 03:58:54PM -0800, Bjorn Andersson wrote:
[..]
> >
> > The result of this patch is that we will actively open the RPM channel
> > even though it's left in a state other than "opening" after the boot
> > loader's closing of the channel.
> >
>
> Its been a while since I looked at this closely but, isn't the result
> of this patch that we now will create a channel / register a platform
> device if the state of the channel is left in any state.
>
Correct, we will create devices for all channels found (on the specific
edge), rather than just the ones that are in opening state. Looking
through a few platforms does however indicate that the two cases where
channels appear but are not in this state are:
1) The rpm_request channel when LK has been communicating with the RPM
before jumping to the kernel.
2) You stop a remote processor, switch firmware to one with less
features and the start it again. Any channels not used by the new
firmware will still be found and we will fail to open them - as
described above. I would be surprised if this would happen in reality.
So with the added handshake mechanism we're supporting #1 and we deal
with #2 - if it ever would happen.
Regards,
Bjorn
next prev parent reply other threads:[~2018-02-02 22:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-12 23:58 [PATCH 0/5] Qualcomm SMD updates Bjorn Andersson
2017-12-12 23:58 ` [PATCH 1/5] rpmsg: smd: Perform handshake during open Bjorn Andersson
2018-01-27 1:32 ` Jeremy McNicoll
2017-12-12 23:58 ` [PATCH 2/5] rpmsg: smd: Create device for all channels Bjorn Andersson
2018-01-27 1:01 ` Jeremy McNicoll
2018-02-02 22:57 ` Bjorn Andersson [this message]
2017-12-12 23:58 ` [PATCH 3/5] rpmsg: smd: Wake up all waiters Bjorn Andersson
2017-12-12 23:58 ` [PATCH 4/5] rpmsg: smd: Fail send on a closed channel Bjorn Andersson
2017-12-12 23:58 ` [PATCH 5/5] rpmsg: smd: Don't hold the tx lock during wait Bjorn Andersson
2018-01-27 1:35 ` [PATCH 0/5] Qualcomm SMD updates Jeremy McNicoll
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=20180202225701.GJ12728@builder \
--to=bjorn.andersson@linaro.org \
--cc=clew@quicinc.com \
--cc=jmcnicol@redhat.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=ohad@wizery.com \
--cc=will.newton@gmail.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).