linux-kernel - Re: [PATCH v2 1/2] dt-bindings: reserved-memory: rmtfs: Document qcom,assign-to-nav

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 6 Jan 2023 11:55:58 -0600
From:   Bjorn Andersson <andersson@...nel.org>
To:     Konrad Dybcio <konrad.dybcio@...aro.org>
Cc:     linux-arm-msm@...r.kernel.org, agross@...nel.org,
        krzysztof.kozlowski@...aro.org, marijn.suijten@...ainline.org,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/2] dt-bindings: reserved-memory: rmtfs: Document
 qcom,assign-to-nav

On Mon, Jan 02, 2023 at 05:50:33PM +0100, Konrad Dybcio wrote:
> Some SoCs mandate that the RMTFS is also assigned to the NAV VM, while
> others really don't want that. Since it has to be conditional, add a
> bool property to toggle this behavior.
> 
> Signed-off-by: Konrad Dybcio <konrad.dybcio@...aro.org>
> ---
> v1 -> v2:
> - Rewrite the newly added description
> 
>  .../devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml b/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml
> index 2998f1c8f0db..4026788a4e40 100644
> --- a/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml
> +++ b/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml
> @@ -31,6 +31,12 @@ properties:
>      description: >
>        vmid of the remote processor, to set up memory protection
>  
> +  qcom,assign-to-nav:
> +    type: boolean
> +    description:
> +      Whether to also assign the region to a third (NAV) VM, as opposed to
> +      the usual 2.

For better or worse, the binding currently takes the vmid of the first
instance in qcom,vmid. Would it not be cleaner to turn qcom,vmid into an
array and pass the nav vmid as a second element in that array?

Regards,
Bjorn

> +
>  required:
>    - qcom,client-id
>  
> -- 
> 2.39.0
>