linux-kernel - Re: [PATCH 1/4] dt-bindings: reset: aoss: Add AOSS reset binding for SC7180 SoCs

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]

Message-ID: <1566383523.4193.5.camel@pengutronix.de>
Date:   Wed, 21 Aug 2019 12:32:03 +0200
From:   Philipp Zabel <p.zabel@...gutronix.de>
To:     Sibi Sankar <sibis@...eaurora.org>, robh+dt@...nel.org,
        bjorn.andersson@...aro.org
Cc:     agross@...nel.org, mark.rutland@....com,
        linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/4] dt-bindings: reset: aoss: Add AOSS reset binding
 for SC7180 SoCs

On Wed, 2019-08-21 at 15:24 +0530, Sibi Sankar wrote:
> Add SC7180 AOSS reset to the list of possible bindings.
> 
> Signed-off-by: Sibi Sankar <sibis@...eaurora.org>
> ---
>  Documentation/devicetree/bindings/reset/qcom,aoss-reset.txt | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/reset/qcom,aoss-reset.txt b/Documentation/devicetree/bindings/reset/qcom,aoss-reset.txt
> index 510c748656ec5..8f0bbdc6afd91 100644
> --- a/Documentation/devicetree/bindings/reset/qcom,aoss-reset.txt
> +++ b/Documentation/devicetree/bindings/reset/qcom,aoss-reset.txt
> @@ -8,7 +8,8 @@ Required properties:
>  - compatible:
>  	Usage: required
>  	Value type: <string>
> -	Definition: must be:
> +	Definition: must be one of:
> +		    "qcom,sc7180-aoss-cc"
>  		    "qcom,sdm845-aoss-cc"
>  
>  - reg:

Does sc7180 have exactly the same resets (mss, camss, venus, gpu,
dispss, wcss, and lpass) as sdm845? If so, it could be considered
compatible, and the driver changes wouldn't be needed at all:

-	Definition: must be:
+	Definition: must be one of:
+		    "qcom,sc7180-aoss-cc", "qcom,sdm845-aoss-cc"
 	
	    "qcom,sdm845-aoss-cc"

Is there a reason not to do this?

regards
Philipp