linux-kernel - Re: [PATCH 1/3] dt-bindings: crypto: qcom,prng: Add SM8450

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: <2c208796-5ad6-c362-dabc-1228b978ca1d@linaro.org>
Date:   Sat, 19 Aug 2023 09:45:09 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Om Prakash Singh <quic_omprsing@...cinc.com>,
        konrad.dybcio@...aro.org
Cc:     agross@...nel.org, andersson@...nel.org, conor+dt@...nel.org,
        davem@...emloft.net, devicetree@...r.kernel.org,
        herbert@...dor.apana.org.au, krzysztof.kozlowski+dt@...aro.org,
        linux-arm-msm@...r.kernel.org, linux-crypto@...r.kernel.org,
        linux-kernel@...r.kernel.org, marijn.suijten@...ainline.org,
        robh+dt@...nel.org, vkoul@...nel.org
Subject: Re: [PATCH 1/3] dt-bindings: crypto: qcom,prng: Add SM8450

On 18/08/2023 18:17, Om Prakash Singh wrote:
> Instead of having SoC name "qcom,sm8450-prng-ee" we could use "qcom,rng-ee" as
> new IP core is not longer pseudo random number generator. so "prng" can be
> changed to "rng". Clock configuration is not needed on sm8550 as well. So it is
> better to use generic compatible string.

I am not sure if I understand your point. You mean drop "p" in "prng" or
drop specific compatible? The first depends in the block - if it is
still pseudo. The second - why? That's contradictory to what is in the
guidelines and what we have been pushing for very long time. Going
against guidelines would require proper justification (and not some
usual justification "I don't need it", because we talked about this many
many times). One should not bring downstream poor practices to upstream,
but the other way. You should fix downstream code.

Best regards,
Krzysztof