linux-arm-msm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephan Gerhold <stephan@gerhold.net>
To: Stephen Boyd <swboyd@chromium.org>
Cc: Andy Gross <agross@kernel.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Elliot Berman <eberman@codeaurora.org>,
	linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	Brian Masney <masneyb@onstation.org>,
	Jeffrey Hugo <jhugo@codeaurora.org>,
	Douglas Anderson <dianders@chromium.org>
Subject: Re: [PATCH v2] firmware: qcom_scm: Only compile legacy calls on ARM
Date: Mon, 5 Apr 2021 14:50:26 +0200	[thread overview]
Message-ID: <YGsHkoNEaIvCRdpx@gerhold.net> (raw)
In-Reply-To: <161738411853.2260335.5107124874054215375@swboyd.mtv.corp.google.com>

On Fri, Apr 02, 2021 at 10:21:58AM -0700, Stephen Boyd wrote:
> Quoting Stephan Gerhold (2021-04-02 03:18:04)
> > On Thu, Apr 01, 2021 at 11:58:48PM -0700, Stephen Boyd wrote:
> > > [...]
> > >
> > > Maybe it would be better to catch that problem at the source and force
> > > arm64 calling convention to be safe? I'm thinking of this patch, but it
> > > could be even more fine tuned and probably the sc7180 check could be
> > > removed in the process if the rest of this email makes sense.
> > > 
> > > If I understand correctly CONFIG_ARM64=y should never use legacy
> > > convention (and never the 32-bit one either?), so we can figure that out
> > > pretty easily and just force it to use 64-bit if the architecture is
> > > arm64. If only the 64-bit convention is supported on arm64 then we
> > > really don't even need to call into the firmware to figure it out on
> > > arm64. We can do this convention detection stuff on arm32 (CONFIG_ARM)
> > > and always assume 64-bit convention on CONFIG_ARM64. Is that right?
> > > 
> > 
> > No, the detection is also needed on ARM64. On ARM32 there can be either
> > legacy or SMC32, but on ARM64 there can be either SMC32 or SMC64.
> > You cannot use SMC64 on 32-bit, but you can use SMC32 on ARM64 just
> > fine. SMC32 is used on MSM8916 for example.
> > 
> 
> Ah right, the whole secure world running in 32-bit mode thing. Is
> msm8916 the only SoC that's using that? Or are there more? If only
> msm8916 is affected then we could use a combination of CONFIG_ARM64 and
> the compatible string to differentiate and then if more SoCs use 32-bit
> secure world then we could have a new compatible string like qcom,scm-32
> that tells us this fact. Maybe this was all discussed before and I
> missed it. Either way, I'm trying to get rid of this boot call so that
> we don't have to bounce to the firmware an extra time to figure out
> something we can figure out from the kernel arch and scm compatible
> string.

At least MSM8994 also uses SMC32 from what I heard. Overall it's
probably quite hard to get that right now since all boards were tested
with the dynamic detection so far. I suppose you could do the opposite,
add an optional qcom,scm-64 to skip the detection step and force SMC64.

Also note that this could even be firmware-specific, not necessarily
SoC-specific. There are some ancient MSM8916 firmwares that have legacy
instead of SMC32. I could also imagine that there is also some SoC where
there are different firmware versions with SMC32 or SMC64.

Plus, IMO the overhead for this detection is negligible. At least it
ensures that we always use the right calling convention. The PSCI code
probably does much more firmware calls to figure out all supported
features.

Stephan

  reply	other threads:[~2021-04-05 12:50 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-23 22:43 [PATCH v2] firmware: qcom_scm: Only compile legacy calls on ARM Stephen Boyd
2021-04-01  1:26 ` Stephen Boyd
2021-04-01  1:52 ` Bjorn Andersson
2021-04-02  1:12 ` Elliot Berman
2021-04-02  6:58   ` Stephen Boyd
2021-04-02 10:18     ` Stephan Gerhold
2021-04-02 17:21       ` Stephen Boyd
2021-04-05 12:50         ` Stephan Gerhold [this message]
2021-04-08  0:12           ` Stephen Boyd
2021-04-08  7:19             ` Stephan Gerhold
2021-04-08 21:18               ` Stephen Boyd

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=YGsHkoNEaIvCRdpx@gerhold.net \
    --to=stephan@gerhold.net \
    --cc=agross@kernel.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=dianders@chromium.org \
    --cc=eberman@codeaurora.org \
    --cc=jhugo@codeaurora.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masneyb@onstation.org \
    --cc=swboyd@chromium.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).