From: Stephen Boyd <swboyd@chromium.org>
To: Bjorn Andersson <bjorn.andersson@linaro.org>,
Elliot Berman <eberman@codeaurora.org>
Cc: agross@kernel.org, Stephan Gerhold <stephan@gerhold.net>,
saiprakash.ranjan@codeaurora.org, tsoni@codeaurora.org,
sidgup@codeaurora.org, psodagud@codeaurora.org,
Brian Masney <masneyb@onstation.org>,
linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 00/17] Restructure, improve target support for qcom_scm driver
Date: Tue, 07 Jan 2020 22:54:43 -0800 [thread overview]
Message-ID: <5e157cb3.1c69fb81.4f0ae.6172@mx.google.com> (raw)
In-Reply-To: <20200108064253.GB4023550@builder>
Quoting Bjorn Andersson (2020-01-07 22:42:53)
> On Tue 07 Jan 13:04 PST 2020, Elliot Berman wrote:
>
> > This series improves support for 32-bit Qualcomm targets on qcom_scm driver and cleans
> > up the driver for 64-bit implementations.
> >
> > Currently, the qcom_scm driver supports only 64-bit Qualcomm targets and very
> > old 32-bit Qualcomm targets. Newer 32-bit targets use ARM's SMC Calling
> > Convention to communicate with secure world. Older 32-bit targets use a
> > "buffer-based" legacy approach for communicating with secure world (as
> > implemented in qcom_scm-32.c). All arm64 Qualcomm targets use ARM SMCCC.
> > Currently, SMCCC-based communication is enabled only on ARM64 config and
> > buffer-based communication only on ARM config. This patch-series combines SMCCC
> > and legacy conventions and selects the correct convention by querying the secure
> > world [1].
> >
> > We decided to take the opportunity as well to clean up the driver rather than
> > try to patch together qcom_scm-32 and qcom_scm-64.
> >
>
> Series applied.
Without the change-ids presumably? I was going to review the patch
series tomorrow but I guess no more need! ;-)
next prev parent reply other threads:[~2020-01-08 6:54 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-07 21:04 [PATCH v5 00/17] Restructure, improve target support for qcom_scm driver Elliot Berman
2020-01-07 21:04 ` [PATCH v5 01/17] firmware: qcom_scm: Rename macros and structures Elliot Berman
2020-01-07 21:04 ` [PATCH v5 02/17] firmware: qcom_scm: Apply consistent naming scheme to command IDs Elliot Berman
2020-01-07 21:04 ` [PATCH v5 03/17] firmware: qcom_scm: Remove unused qcom_scm_get_version Elliot Berman
2020-01-07 21:04 ` [PATCH v5 04/17] firmware: qcom_scm-64: Make SMC macros less magical Elliot Berman
2020-01-07 21:04 ` [PATCH v5 05/17] firmware: qcom_scm-64: Move svc/cmd/owner into qcom_scm_desc Elliot Berman
2020-01-07 21:04 ` [PATCH v5 06/17] firmware: qcom_scm-64: Add SCM results struct Elliot Berman
2020-01-07 21:04 ` [PATCH v5 07/17] firmware: qcom_scm-64: Move SMC register filling to qcom_scm_call_smccc Elliot Berman
2020-01-07 21:04 ` [PATCH v5 08/17] firmware: qcom_scm-64: Improve SMC convention detection Elliot Berman
2020-01-07 21:04 ` [PATCH v5 09/17] firmware: qcom_scm-32: Use SMC arch wrappers Elliot Berman
2020-01-07 21:04 ` [PATCH v5 10/17] firmware: qcom_scm-32: Add funcnum IDs Elliot Berman
2020-01-07 21:04 ` [PATCH v5 11/17] firmware: qcom_scm-32: Use qcom_scm_desc in non-atomic calls Elliot Berman
2020-01-07 21:04 ` [PATCH v5 12/17] firmware: qcom_scm-32: Move SMCCC register filling to qcom_scm_call Elliot Berman
2020-01-07 21:04 ` [PATCH v5 13/17] firmware: qcom_scm-32: Create common legacy atomic call Elliot Berman
2020-01-07 21:04 ` [PATCH v5 14/17] firmware: qcom_scm-32: Add device argument to atomic calls Elliot Berman
2020-01-07 21:04 ` [PATCH v5 15/17] firmware: qcom_scm: Order functions, definitions by service/command Elliot Berman
2020-01-07 21:04 ` [PATCH v5 16/17] firmware: qcom_scm: Remove thin wrappers Elliot Berman
2020-01-07 21:04 ` [PATCH v5 17/17] firmware: qcom_scm: Dynamically support SMCCC and legacy conventions Elliot Berman
2020-01-08 7:02 ` Stephen Boyd
2020-01-08 6:42 ` [PATCH v5 00/17] Restructure, improve target support for qcom_scm driver Bjorn Andersson
2020-01-08 6:54 ` Stephen Boyd [this message]
2020-01-08 7:21 ` Bjorn Andersson
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=5e157cb3.1c69fb81.4f0ae.6172@mx.google.com \
--to=swboyd@chromium.org \
--cc=agross@kernel.org \
--cc=bjorn.andersson@linaro.org \
--cc=eberman@codeaurora.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masneyb@onstation.org \
--cc=psodagud@codeaurora.org \
--cc=saiprakash.ranjan@codeaurora.org \
--cc=sidgup@codeaurora.org \
--cc=stephan@gerhold.net \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.