diff mbox series

[v7,1/3] dt-bindings: ufs: qcom: Add ICE phandle

Message ID 20230408214041.533749-2-abel.vesa@linaro.org
State Superseded
Headers show
Series Add dedicated Qcom ICE driver | expand

Commit Message

Abel Vesa April 8, 2023, 9:40 p.m. UTC
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@linaro.org>
---

The v6 is here:
https://lore.kernel.org/all/20230407105029.2274111-3-abel.vesa@linaro.org/

Changes since v6:
 * Dropped the minItems for both the qcom,ice and the reg in the
   qcom,ice compatile subschema, like Krzysztof suggested

Changes since v5:
 * dropped the sm8550 specific subschema and replaced it with one that
   mutually excludes the qcom,ice vs both the ICE specific reg range
   and the ICE clock

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

Changes since v3:
 * dropped the "and drop core clock" part from subject line

Changes since v2:
 * dropped all changes except the qcom,ice property


 .../devicetree/bindings/ufs/qcom,ufs.yaml     | 24 +++++++++++++++++++
 1 file changed, 24 insertions(+)

Comments

Krzysztof Kozlowski April 10, 2023, 5:22 p.m. UTC | #1
On 08/04/2023 23:40, 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@linaro.org>

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Best regards,
Krzysztof
Krzysztof Kozlowski May 5, 2023, 6:47 p.m. UTC | #2
On 08/04/2023 23:40, 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@linaro.org>
> ---
> 
> The v6 is here:
> https://lore.kernel.org/all/20230407105029.2274111-3-abel.vesa@linaro.org/
> 
> Changes since v6:
>  * Dropped the minItems for both the qcom,ice and the reg in the
>    qcom,ice compatile subschema, like Krzysztof suggested
> 
> Changes since v5:
>  * dropped the sm8550 specific subschema and replaced it with one that
>    mutually excludes the qcom,ice vs both the ICE specific reg range
>    and the ICE clock
> 
> 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
> 
> Changes since v3:
>  * dropped the "and drop core clock" part from subject line
> 
> Changes since v2:
>  * dropped all changes except the qcom,ice property
> 
> 
>  .../devicetree/bindings/ufs/qcom,ufs.yaml     | 24 +++++++++++++++++++
>  1 file changed, 24 insertions(+)
> 

I see dt_binding_check errors after applying this patch. Are you sure
this was tested?

Best regards,
Krzysztof
Krzysztof Kozlowski May 8, 2023, 6:20 a.m. UTC | #3
On 05/05/2023 20:47, Krzysztof Kozlowski wrote:
> On 08/04/2023 23:40, 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@linaro.org>
>> ---
>>
>> The v6 is here:
>> https://lore.kernel.org/all/20230407105029.2274111-3-abel.vesa@linaro.org/
>>
>> Changes since v6:
>>  * Dropped the minItems for both the qcom,ice and the reg in the
>>    qcom,ice compatile subschema, like Krzysztof suggested
>>
>> Changes since v5:
>>  * dropped the sm8550 specific subschema and replaced it with one that
>>    mutually excludes the qcom,ice vs both the ICE specific reg range
>>    and the ICE clock
>>
>> 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
>>
>> Changes since v3:
>>  * dropped the "and drop core clock" part from subject line
>>
>> Changes since v2:
>>  * dropped all changes except the qcom,ice property
>>
>>
>>  .../devicetree/bindings/ufs/qcom,ufs.yaml     | 24 +++++++++++++++++++
>>  1 file changed, 24 insertions(+)
>>
> 
> I see dt_binding_check errors after applying this patch. Are you sure
> this was tested?

False alarm, it was other patch in my tree.

This one is good.

Best regards,
Krzysztof
Krzysztof Kozlowski June 18, 2023, 8:53 a.m. UTC | #4
On 08/04/2023 23:40, 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@linaro.org>
> ---
> 
> The v6 is here:
> https://lore.kernel.org/all/20230407105029.2274111-3-abel.vesa@linaro.org/
> 
> Changes since v6:
>  * Dropped the minItems for both the qcom,ice and the reg in the
>    qcom,ice compatile subschema, like Krzysztof suggested
> 
> Changes since v5:
>  * dropped the sm8550 specific subschema and replaced it with one that
>    mutually excludes the qcom,ice vs both the ICE specific reg range
>    and the ICE clock
> 
> 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
> 
> Changes since v3:
>  * dropped the "and drop core clock" part from subject line
> 
> Changes since v2:
>  * dropped all changes except the qcom,ice property
> 
> 
>  .../devicetree/bindings/ufs/qcom,ufs.yaml     | 24 +++++++++++++++++++
>  1 file changed, 24 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
> index c5a06c048389..10d426ba1959 100644
> --- a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
> +++ b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
> @@ -70,6 +70,10 @@ properties:
>    power-domains:
>      maxItems: 1
>  
> +  qcom,ice:
> +    $ref: /schemas/types.yaml#/definitions/phandle
> +    description: phandle to the Inline Crypto Engine node
> +
>    reg:
>      minItems: 1
>      maxItems: 2
> @@ -187,6 +191,26 @@ allOf:
>  
>      # TODO: define clock bindings for qcom,msm8994-ufshc
>  
> +  - if:
> +      properties:
> +        qcom,ice:

Un-reviewed. This is broken and was never tested. After applying this
patch, I can see many new warnings in all DTBs (so it is easy to spot
that it was not actually tested).

Your probably meant here:
  if:
    required:


Best regards,
Krzysztof
Martin K. Petersen June 22, 2023, 1:19 a.m. UTC | #5
Abel,

> Un-reviewed. This is broken and was never tested. After applying this
> patch, I can see many new warnings in all DTBs (so it is easy to spot
> that it was not actually tested).
>
> Your probably meant here:
>   if:
>     required:

Please provide a fix for this. I don't want to rebase this late in the
cycle.

Thanks!
Abel Vesa June 22, 2023, 7:02 a.m. UTC | #6
On 23-06-22 08:07:51, Krzysztof Kozlowski wrote:
> On 22/06/2023 03:19, Martin K. Petersen wrote:
> > 
> > Abel,
> > 
> >> Un-reviewed. This is broken and was never tested. After applying this
> >> patch, I can see many new warnings in all DTBs (so it is easy to spot
> >> that it was not actually tested).
> >>
> >> Your probably meant here:
> >>   if:
> >>     required:
> > 
> > Please provide a fix for this. I don't want to rebase this late in the
> > cycle.
> 
> AFAIK, this was not applied. At least as of next 20210621 and I
> commented on this few days ago. Anything changed here?

Check this one:
https://lore.kernel.org/all/yq1a5x1wl4g.fsf@ca-mkp.ca.oracle.com/

I'll send a fix today.

> 
> Best regards,
> Krzysztof
>
Krzysztof Kozlowski June 22, 2023, 9:28 a.m. UTC | #7
On 22/06/2023 09:02, Abel Vesa wrote:
> On 23-06-22 08:07:51, Krzysztof Kozlowski wrote:
>> On 22/06/2023 03:19, Martin K. Petersen wrote:
>>>
>>> Abel,
>>>
>>>> Un-reviewed. This is broken and was never tested. After applying this
>>>> patch, I can see many new warnings in all DTBs (so it is easy to spot
>>>> that it was not actually tested).
>>>>
>>>> Your probably meant here:
>>>>   if:
>>>>     required:
>>>
>>> Please provide a fix for this. I don't want to rebase this late in the
>>> cycle.
>>
>> AFAIK, this was not applied. At least as of next 20210621 and I
>> commented on this few days ago. Anything changed here?
> 
> Check this one:
> https://lore.kernel.org/all/yq1a5x1wl4g.fsf@ca-mkp.ca.oracle.com/
> 

So staging tree is not in next? If it cannot be rebased "that late in
the cycle", this means it should be in the next. :/

Best regards,
Krzysztof
Martin K. Petersen June 23, 2023, 1:06 a.m. UTC | #8
Hi Krzysztof!

> AFAIK, this was not applied. At least as of next 20210621 and I
> commented on this few days ago. Anything changed here?

It's definitely there in 20230621:

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml?h=next-20230621

I merged the series on the 16th prior to you withdrawing your
Reviewed-by: tag. But let's just get the bindings fixed.
diff mbox series

Patch

diff --git a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
index c5a06c048389..10d426ba1959 100644
--- a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
+++ b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
@@ -70,6 +70,10 @@  properties:
   power-domains:
     maxItems: 1
 
+  qcom,ice:
+    $ref: /schemas/types.yaml#/definitions/phandle
+    description: phandle to the Inline Crypto Engine node
+
   reg:
     minItems: 1
     maxItems: 2
@@ -187,6 +191,26 @@  allOf:
 
     # TODO: define clock bindings for qcom,msm8994-ufshc
 
+  - if:
+      properties:
+        qcom,ice:
+          maxItems: 1
+    then:
+      properties:
+        reg:
+          maxItems: 1
+        clocks:
+          minItems: 8
+          maxItems: 8
+    else:
+      properties:
+        reg:
+          minItems: 2
+          maxItems: 2
+        clocks:
+          minItems: 9
+          maxItems: 11
+
 unevaluatedProperties: false
 
 examples: