Message-Id: <20230928092040.9420-1-brgl@bgdev.pl>
Date:   Thu, 28 Sep 2023 11:20:29 +0200
From:   Bartosz Golaszewski <brgl@...ev.pl>
To:     Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Maximilian Luz <luzmaximilian@...il.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc:     linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        kernel@...cinc.com,
        Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Subject: [PATCH v2 00/11] arm64: qcom: add and enable SHM Bridge support

From: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>

This is technically the second iteration of the SHM Bridge enablement on
QCom platforms but in practice it's a complete rewrite.

During the internal discussion with QCom the requirement has been established
as an SHM Bridge pool manager with the assumption that there will be multiple
users, each with their own pool. The problem with this is that we don't have
many potential users of SHM pools upstream at the moment which was rightfully
pointed out in the reviews under v1 (which even had some unused symbols etc.).

Moreover: after some investigating, it turns out that there simply isn't any
need for multiple pools as the core SCM only allocates a buffer if given call
requires more than 4 arguments and there are only a handful of SCM calls that
need to pass a physical address to a buffer as argument to the trustzone.

Additionally all but one SCM call allocate buffers passed to the TZ only for
the duration of the call and then free it right aftr it returns. The one
exception is called once and the buffer it uses can remain in memory until
released by the user.

This all makes using multiple pools wasteful as most of that memory will be
reserved but remain unused 99% of the time. What we need is a single pool of
SCM memory that deals out chunks of suitable format (coherent and
page-aligned) that fulfills the requirements of all calls.

As not all architectures support SHM bridge, it makes sense to first unify the
memory operations in SCM calls. All users do some kind of DMA mapping to obtain
buffers, most using dma_alloc_coherent() which impacts performance.

Genalloc pools are very fast so let's use them instead. Create a custom
allocator that also deals with the mapping and use it across all SCM calls.

Then once this is done, let's extend the allocator to use the SHM bridge
functionality if available on the given platform.

While at it: let's create a qcom specific directory in drivers/firmware/ and
move relevant code in there.

I couldn't test all SCM calls but tested with the inline crypto engine on
sm8550 and sa8775p that runs most of new code paths (with and without SHM
bridge). At least qseecom would need some Tested-by.

v1 -> v2:
- too many changes to list, it's a complete rewrite as explained above

Bartosz Golaszewski (11):
  firmware: qcom: move Qualcomm code into its own directory
  firmware: qcom: scm: add a dedicated SCM memory allocator
  firmware: qcom: scm: switch to using the SCM allocator
  firmware: qcom: scm: make qcom_scm_assign_mem() use the SCM allocator
  firmware: qcom: scm: make qcom_scm_ice_set_key() use the SCM allocator
  firmware: qcom: scm: make qcom_scm_pas_init_image() use the SCM
    allocator
  firmware: qcom: scm: make qcom_scm_lmh_dcvsh() use the SCM allocator
  firmware: qcom: scm: make qcom_scm_qseecom_app_get_id() use the SCM
    allocator
  firmware: qcom: qseecom: convert to using the SCM allocator
  firmware: qcom-scm: add support for SHM bridge operations
  firmware: qcom: scm: enable SHM bridge

 MAINTAINERS                                   |   4 +-
 drivers/firmware/Kconfig                      |  48 +---
 drivers/firmware/Makefile                     |   5 +-
 drivers/firmware/qcom/Kconfig                 |  56 ++++
 drivers/firmware/qcom/Makefile                |   9 +
 drivers/firmware/{ => qcom}/qcom_qseecom.c    |   0
 .../{ => qcom}/qcom_qseecom_uefisecapp.c      | 251 ++++++------------
 drivers/firmware/{ => qcom}/qcom_scm-legacy.c |   0
 drivers/firmware/qcom/qcom_scm-mem.c          | 170 ++++++++++++
 drivers/firmware/{ => qcom}/qcom_scm-smc.c    |  21 +-
 drivers/firmware/{ => qcom}/qcom_scm.c        | 149 ++++++-----
 drivers/firmware/{ => qcom}/qcom_scm.h        |   9 +
 include/linux/firmware/qcom/qcom_qseecom.h    |   4 +-
 include/linux/firmware/qcom/qcom_scm.h        |  13 +
 14 files changed, 427 insertions(+), 312 deletions(-)
 create mode 100644 drivers/firmware/qcom/Kconfig
 create mode 100644 drivers/firmware/qcom/Makefile
 rename drivers/firmware/{ => qcom}/qcom_qseecom.c (100%)
 rename drivers/firmware/{ => qcom}/qcom_qseecom_uefisecapp.c (84%)
 rename drivers/firmware/{ => qcom}/qcom_scm-legacy.c (100%)
 create mode 100644 drivers/firmware/qcom/qcom_scm-mem.c
 rename drivers/firmware/{ => qcom}/qcom_scm-smc.c (92%)
 rename drivers/firmware/{ => qcom}/qcom_scm.c (94%)
 rename drivers/firmware/{ => qcom}/qcom_scm.h (95%)

-- 
2.39.2

Powered by blists - more mailing lists