linux-kernel - Re: [PATCH v5 2/6] dt-bindings: ufs: qcom: Add ICE phandle

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, 4 Apr 2023 13:41:57 +0300
From:   Abel Vesa <abel.vesa@...aro.org>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc:     Ulf Hansson <ulf.hansson@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Manivannan Sadhasivam <mani@...nel.org>,
        Alim Akhtar <alim.akhtar@...sung.com>,
        Avri Altman <avri.altman@....com>,
        Bart Van Assche <bvanassche@....org>,
        Adrian Hunter <adrian.hunter@...el.com>,
        "James E . J . Bottomley" <jejb@...ux.ibm.com>,
        "Martin K . Petersen" <martin.petersen@...cle.com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "David S . Miller" <davem@...emloft.net>,
        Eric Biggers <ebiggers@...nel.org>, linux-mmc@...r.kernel.org,
        devicetree@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-arm-msm@...r.kernel.org, linux-crypto@...r.kernel.org,
        linux-scsi@...r.kernel.org
Subject: Re: [PATCH v5 2/6] dt-bindings: ufs: qcom: Add ICE phandle

On 23-04-04 12:12:06, Krzysztof Kozlowski wrote:
> On 04/04/2023 10:59, Abel Vesa wrote:
> > On 23-04-04 07:41:55, Krzysztof Kozlowski wrote:
> >> On 03/04/2023 22:05, Abel Vesa wrote:
> >>> Starting with SM8550, the ICE will have its own devicetree node
> >>> so add the qcom,ice property to reference it.
> >>>
> >>> Signed-off-by: Abel Vesa <abel.vesa@...aro.org>
> >>> ---
> >>>
> >>> The v4 is here:
> >>> https://lore.kernel.org/all/20230327134734.3256974-4-abel.vesa@linaro.org/
> >>>
> >>> Changes since v4:
> >>>  * Added check for sm8550 compatible w.r.t. qcom,ice in order to enforce
> >>>    it while making sure none of the other platforms are allowed to use it
> >>
> >> Why?
> > 
> > SM8550 will be the first platform to use the new DT bindings w.r.t ICE.
> 
> This I understand, but why other platforms cannot use it?

The platforms that do not have ICE support yet will be added in the same
subschema along with SM8550 when the ICE DT node will be added in their
dtsi.

> 
> > 
> >>
> >> Also, this does not solve my previous question still.
> > 
> > Well, the clocks are not added for the a few platforms (which include
> > SM8550). Same for 'ice' reg range.. So the only thing left is to
> > enforce the qcom,ice property availability only for SM8550. I believe
> > it solves the mutual exclusiveness of the "ice" reg range along with the
> > clocks versus the qcom,ice property, by enforcing at compatible level.
> 
> Ah, I think I understand. That would work except I don't understand why
> enforcing qcom,qce only for specific, new SoCs. Assuming it is a correct
> hardware representation, we want it for everyone, don't we?

Yes, but they will be added to the subschema (qcom,ice one) when their
their ICE support (ICE DT) will be added. This way, we keep the bindings
check without failures (for now).

> 
> Best regards,
> Krzysztof
>