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:   Tue, 16 Mar 2021 16:28:25 -0600
From:   Rob Herring <robh@...nel.org>
To:     Bhupesh Sharma <bhupesh.sharma@...aro.org>
Cc:     linux-arm-msm@...r.kernel.org,
        Thara Gopinath <thara.gopinath@...aro.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Andy Gross <agross@...nel.org>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "David S . Miller" <davem@...emloft.net>,
        Stephen Boyd <sboyd@...nel.org>,
        Michael Turquette <mturquette@...libre.com>,
        linux-clk@...r.kernel.org, linux-crypto@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        bhupesh.linux@...il.com
Subject: Re: [PATCH 2/8] dt-bindings: crypto : Add new compatible strings for
 qcom-qce

On Wed, Mar 10, 2021 at 10:54:57AM +0530, Bhupesh Sharma wrote:
> Newer qcom chips support newer versions of the qce IP, so add
> new compatible strings for qcom-qce (in addition to the existing
> "qcom,crypto-v5.1").
> 
> With [1], Thara tried to add the support for new compatible strings,
> but we couldn't conclude on the approach to be used. Since we have
> a number of new qcom arm64 SoCs available now, several of which
> support the same crypto IP version, so it makes more sense to use
> the IP version for the compatible string, rather than using the soc
> name as the compatible string.
> 
> [1]. https://lore.kernel.org/linux-arm-msm/20201119155233.3974286-7-thara.gopinath@linaro.org/
> 
> Cc: Thara Gopinath <thara.gopinath@...aro.org>
> Cc: Bjorn Andersson <bjorn.andersson@...aro.org>
> Cc: Rob Herring <robh+dt@...nel.org>
> Cc: Andy Gross <agross@...nel.org>
> Cc: Herbert Xu <herbert@...dor.apana.org.au>
> Cc: David S. Miller <davem@...emloft.net>
> Cc: Stephen Boyd <sboyd@...nel.org>
> Cc: Michael Turquette <mturquette@...libre.com>
> Cc: linux-clk@...r.kernel.org
> Cc: linux-crypto@...r.kernel.org
> Cc: devicetree@...r.kernel.org
> Cc: linux-kernel@...r.kernel.org
> Cc: bhupesh.linux@...il.com
> Signed-off-by: Bhupesh Sharma <bhupesh.sharma@...aro.org>
> ---
>  Documentation/devicetree/bindings/crypto/qcom-qce.txt | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/crypto/qcom-qce.txt b/Documentation/devicetree/bindings/crypto/qcom-qce.txt
> index 07ee1b12000b..217b37dbd58a 100644
> --- a/Documentation/devicetree/bindings/crypto/qcom-qce.txt
> +++ b/Documentation/devicetree/bindings/crypto/qcom-qce.txt
> @@ -2,7 +2,11 @@ Qualcomm crypto engine driver
>  
>  Required properties:
>  
> -- compatible  : should be "qcom,crypto-v5.1"
> +- compatible  : Supported versions are:
> +		- "qcom,crypto-v5.1", for ipq6018
> +		- "qcom,crypto-v5.4", for sdm845, sm8150

2 SoCs sharing 1 version doesn't convince me on using version numbers. 
Having 4 versions for 5 SoCs further convinces me you should stick with 
SoC specific compatibles as *everyone* else does (including most QCom 
bindings).

> +		- "qcom,crypto-v5.5", for sm8250
> +		- "qcom,crypto-v5.6", for sm8350
>  - reg         : specifies base physical address and size of the registers map
>  - clocks      : phandle to clock-controller plus clock-specifier pair
>  - clock-names : "iface" clocks register interface
> -- 
> 2.29.2
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ