[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0349897d-8802-b4c9-c867-20d139baf952@linaro.org>
Date: Thu, 21 Sep 2023 09:06:38 +0200
From: Konrad Dybcio <konrad.dybcio@...aro.org>
To: Bjorn Andersson <quic_bjorande@...cinc.com>,
Andy Gross <agross@...nel.org>,
Bjorn Andersson <andersson@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>
Cc: linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 1/3] dt-bindings: reserved-memory: rmtfs: Allow guard
pages
On 9/21/23 04:37, Bjorn Andersson wrote:
> On some Qualcomm platforms the firwmare, or hardware, does not
> gracefully handle memory protection of the rmtfs memory region when
> placed adjacent to other protected region. Some DeviceTree authors have
> worked around this issue by explicitly reserving the space around the
> region, but this prevents such author to use rely on the OS to place the
> region, through the use of "size" (instead of a fixed location).
>
> Introduce a flag to indicate that guard pages need be carved at the
> beginning and end of the memory region. The user shall account for the
> two 4k blocks in the defined size.
>
> Signed-off-by: Bjorn Andersson <quic_bjorande@...cinc.com>
> ---
> .../devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml b/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml
> index bab982f00485..2d7be508c5a0 100644
> --- a/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml
> +++ b/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml
> @@ -26,6 +26,17 @@ properties:
> description: >
> identifier of the client to use this region for buffers
>
> + qcom,use-guard-pages:
> + type: boolean
> + description: >
> + Indicates that the firmware, or hardware, does not gracefully handle
> + memory protection of this region when placed adjacent to other protected
> + memory regions, and that padding around the used portion of the memory
> + region is necessary.
> +
> + When this is set, the first and last 4kB should be left unused, and the
> + effective size of the region will thereby shrink with 8kB.
kiB
Konrad
Powered by blists - more mailing lists