diff mbox series

[v10,13/15] firmware: qcom: scm: clarify the comment in qcom_scm_pas_init_image()

Message ID 20240527-shm-bridge-v10-13-ce7afaa58d3a@linaro.org (mailing list archive)
State New, archived
Headers show
Series firmware: qcom: implement support for and enable SHM bridge | expand

Commit Message

Bartosz Golaszewski May 27, 2024, 12:55 p.m. UTC
From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

The "memory protection" mechanism mentioned in the comment is the SHM
Bridge. This is also the reason why we do not convert this call to using
the TZ memory allocator.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Tested-by: Andrew Halaney <ahalaney@redhat.com> # sc8280xp-lenovo-thinkpad-x13s
Tested-by: Deepti Jaggi <quic_djaggi@quicinc.com> #sa8775p-ride
Reviewed-by: Elliot Berman <quic_eberman@quicinc.com>
---
 drivers/firmware/qcom/qcom_scm.c | 7 +++++++
 1 file changed, 7 insertions(+)

Comments

Elliot Berman June 20, 2024, 10:54 p.m. UTC | #1
On Mon, May 27, 2024 at 02:55:03PM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> 
> The "memory protection" mechanism mentioned in the comment is the SHM
> Bridge. This is also the reason why we do not convert this call to using
> the TZ memory allocator.
> 
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> Tested-by: Andrew Halaney <ahalaney@redhat.com> # sc8280xp-lenovo-thinkpad-x13s
> Tested-by: Deepti Jaggi <quic_djaggi@quicinc.com> #sa8775p-ride
> Reviewed-by: Elliot Berman <quic_eberman@quicinc.com>
> ---
>  drivers/firmware/qcom/qcom_scm.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
> index c82957727650..86e26f17ca19 100644
> --- a/drivers/firmware/qcom/qcom_scm.c
> +++ b/drivers/firmware/qcom/qcom_scm.c
> @@ -583,6 +583,13 @@ int qcom_scm_pas_init_image(u32 peripheral, const void *metadata, size_t size,
>  	 * During the scm call memory protection will be enabled for the meta
>  	 * data blob, so make sure it's physically contiguous, 4K aligned and
>  	 * non-cachable to avoid XPU violations.
> +	 *
> +	 * For PIL calls the hypervisor creates SHM Bridges for the blob
> +	 * buffers on behalf of Linus so we must not do it ourselves hence
                                Linux
> +	 * not using the TZMem allocator here.
> +	 *
> +	 * If we pass a buffer that is already part of an SHM Bridge to this
> +	 * call, it will fail.
>  	 */
>  	mdata_buf = dma_alloc_coherent(__scm->dev, size, &mdata_phys,
>  				       GFP_KERNEL);
> 
> -- 
> 2.43.0
>
Bartosz Golaszewski June 21, 2024, 1:42 p.m. UTC | #2
On Fri, Jun 21, 2024 at 12:54 AM Elliot Berman <quic_eberman@quicinc.com> wrote:
>
> On Mon, May 27, 2024 at 02:55:03PM +0200, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> >
> > The "memory protection" mechanism mentioned in the comment is the SHM
> > Bridge. This is also the reason why we do not convert this call to using
> > the TZ memory allocator.
> >
> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> > Tested-by: Andrew Halaney <ahalaney@redhat.com> # sc8280xp-lenovo-thinkpad-x13s
> > Tested-by: Deepti Jaggi <quic_djaggi@quicinc.com> #sa8775p-ride
> > Reviewed-by: Elliot Berman <quic_eberman@quicinc.com>
> > ---
> >  drivers/firmware/qcom/qcom_scm.c | 7 +++++++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
> > index c82957727650..86e26f17ca19 100644
> > --- a/drivers/firmware/qcom/qcom_scm.c
> > +++ b/drivers/firmware/qcom/qcom_scm.c
> > @@ -583,6 +583,13 @@ int qcom_scm_pas_init_image(u32 peripheral, const void *metadata, size_t size,
> >        * During the scm call memory protection will be enabled for the meta
> >        * data blob, so make sure it's physically contiguous, 4K aligned and
> >        * non-cachable to avoid XPU violations.
> > +      *
> > +      * For PIL calls the hypervisor creates SHM Bridges for the blob
> > +      * buffers on behalf of Linus so we must not do it ourselves hence
>                                 Linux

Can this be fixed when applying? I don't think there's anything else
that warrants a respin.

Bart

> > +      * not using the TZMem allocator here.
> > +      *
> > +      * If we pass a buffer that is already part of an SHM Bridge to this
> > +      * call, it will fail.
> >        */
> >       mdata_buf = dma_alloc_coherent(__scm->dev, size, &mdata_phys,
> >                                      GFP_KERNEL);
> >
> > --
> > 2.43.0
> >
diff mbox series

Patch

diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
index c82957727650..86e26f17ca19 100644
--- a/drivers/firmware/qcom/qcom_scm.c
+++ b/drivers/firmware/qcom/qcom_scm.c
@@ -583,6 +583,13 @@  int qcom_scm_pas_init_image(u32 peripheral, const void *metadata, size_t size,
 	 * During the scm call memory protection will be enabled for the meta
 	 * data blob, so make sure it's physically contiguous, 4K aligned and
 	 * non-cachable to avoid XPU violations.
+	 *
+	 * For PIL calls the hypervisor creates SHM Bridges for the blob
+	 * buffers on behalf of Linus so we must not do it ourselves hence
+	 * not using the TZMem allocator here.
+	 *
+	 * If we pass a buffer that is already part of an SHM Bridge to this
+	 * call, it will fail.
 	 */
 	mdata_buf = dma_alloc_coherent(__scm->dev, size, &mdata_phys,
 				       GFP_KERNEL);