[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAA8EJpoFusQbZqUoqA-UZRfretUWOgox_LKfup6viVxXDQiS5g@mail.gmail.com>
Date: Tue, 29 Aug 2023 23:48:53 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Cc: Andy Gross <agross@...nel.org>,
Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konrad.dybcio@...aro.org>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>, Arnd Bergmann <arnd@...db.de>,
Alex Elder <elder@...aro.org>,
Srini Kandagatla <srinivas.kandagatla@...aro.org>,
kernel@...cinc.com, linux-arm-msm@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 00/11] arm64: qcom: add and enable SHM Bridge support
On Tue, 29 Aug 2023 at 22:03, Bartosz Golaszewski
<bartosz.golaszewski@...aro.org> wrote:
>
> On Mon, 28 Aug 2023 at 23:24, Dmitry Baryshkov
> <dmitry.baryshkov@...aro.org> wrote:
> >
> > On Mon, 28 Aug 2023 at 22:29, Bartosz Golaszewski
> > <bartosz.golaszewski@...aro.org> wrote:
> > >
> > > SHM Bridge is a mechanism allowing to map limited areas of kernel's
> > > virtual memory to physical addresses and share those with the
> > > trustzone in order to not expose the entire RAM for SMC calls.
> > >
> > > This series adds support for Qualcomm SHM Bridge in form of a platform
> > > driver and library functions available to users. It enables SHM Bridge
> > > support for three platforms and contains a bunch of cleanups for
> > > qcom-scm.
> >
> > Which users do you expect for this API?
> >
>
> This series adds a single user: the SCM driver. We have another user
> almost ready for upstream in the form of the scminvoke driver and I
> learned today, I can already convert another user upstream right now
> that I will try to get ready for v2.
>
> > Also, could you please describe your design a bit more? Why have you
> > implemented the shm-bridge as a separate driver rather than a part of
> > the SCM driver?
> >
>
> It's self-contained enough to be put into a separate module and not
> all platforms support it so in order to avoid unnecessary ifdeffery in
> the scm driver, I made it separate.
Judging from other reviews, I'm not the only one who questioned this
design. I still suppose that it might be better to move it into the
SCM driver. You can put ifdef's to the header file defining the
interface between SCM and SHM bridge part.
--
With best wishes
Dmitry
Powered by blists - more mailing lists