Message ID | 20230920-rmtfs-mem-guard-pages-v3-1-305b37219b78@quicinc.com |
---|---|
State | Not Applicable, archived |
Headers | show |
Series | soc: qcom: rmtfs: Support dynamic allocation | expand |
Context | Check | Description |
---|---|---|
robh/checkpatch | warning | total: 0 errors, 1 warnings, 17 lines checked |
robh/patch-applied | success | |
robh/dtbs-check | warning | build log |
robh/dt-meta-schema | success |
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@quicinc.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
On 21/09/2023 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). > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > + > + 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. Maybe we should not reference the actual size (4 and 8 kB), but rather page - "the first and last pages in mapping should be left unused ..." etc? Best regards, Krzysztof
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. + qcom,vmid: $ref: /schemas/types.yaml#/definitions/uint32-array description: >
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@quicinc.com> --- .../devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml | 11 +++++++++++ 1 file changed, 11 insertions(+)