On Tue, 29 Aug 2023 at 22:03, Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx> wrote: > > On Mon, 28 Aug 2023 at 23:24, Dmitry Baryshkov > <dmitry.baryshkov@xxxxxxxxxx> wrote: > > > > On Mon, 28 Aug 2023 at 22:29, Bartosz Golaszewski > > <bartosz.golaszewski@xxxxxxxxxx> 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
