[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 4 Apr 2023 12:12:06 +0200
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Abel Vesa <abel.vesa@...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 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?
>
>>
>> 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?
Best regards,
Krzysztof
Powered by blists - more mailing lists