.../devicetree/bindings/display/msm/gmu.yaml | 12 ++++++++++++ 1 file changed, 12 insertions(+)
dtschema v2024.4, v2024.5 and maybe earlier do not select device nodes for
given binding validation if the schema contains compatible list with
pattern and a const fallback. This leads to binding being a no-op - not
being applied at all. Issue should be fixed in the dtschema but for now
add a work-around do the binding can be used against DTS validation.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
Cc: Akhil P Oommen <quic_akhilpo@quicinc.com>
---
.../devicetree/bindings/display/msm/gmu.yaml | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/msm/gmu.yaml b/Documentation/devicetree/bindings/display/msm/gmu.yaml
index b3837368a260..8d1b515f59ec 100644
--- a/Documentation/devicetree/bindings/display/msm/gmu.yaml
+++ b/Documentation/devicetree/bindings/display/msm/gmu.yaml
@@ -17,6 +17,18 @@ description: |
management and support to improve power efficiency and reduce the load on
the CPU.
+# dtschema does not select nodes based on pattern+const, so add custom select
+# as a work-around:
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,adreno-gmu
+ - qcom,adreno-gmu-wrapper
+ required:
+ - compatible
+
properties:
compatible:
oneOf:
--
2.43.0
On Sun, Jun 23, 2024 at 02:59:30PM +0200, Krzysztof Kozlowski wrote:
> dtschema v2024.4, v2024.5 and maybe earlier do not select device nodes for
That should be just since db9c05a08709 ("validator: Rework selecting
schemas for validation") AKA the 6x speed up in v2024.04.
> given binding validation if the schema contains compatible list with
> pattern and a const fallback. This leads to binding being a no-op - not
> being applied at all. Issue should be fixed in the dtschema but for now
> add a work-around do the binding can be used against DTS validation.
The issue is we only look at the first compatible. I'm testing out a fix
and will apply it tomorrow assuming no issues. With that, I don't think
we should apply this patch.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>
> ---
>
> Cc: Akhil P Oommen <quic_akhilpo@quicinc.com>
> ---
> .../devicetree/bindings/display/msm/gmu.yaml | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/msm/gmu.yaml b/Documentation/devicetree/bindings/display/msm/gmu.yaml
> index b3837368a260..8d1b515f59ec 100644
> --- a/Documentation/devicetree/bindings/display/msm/gmu.yaml
> +++ b/Documentation/devicetree/bindings/display/msm/gmu.yaml
> @@ -17,6 +17,18 @@ description: |
> management and support to improve power efficiency and reduce the load on
> the CPU.
>
> +# dtschema does not select nodes based on pattern+const, so add custom select
> +# as a work-around:
> +select:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - qcom,adreno-gmu
> + - qcom,adreno-gmu-wrapper
> + required:
> + - compatible
> +
> properties:
> compatible:
> oneOf:
> --
> 2.43.0
>
On Tue, Jun 25, 2024 at 04:51:27PM GMT, Rob Herring wrote:
> On Sun, Jun 23, 2024 at 02:59:30PM +0200, Krzysztof Kozlowski wrote:
> > dtschema v2024.4, v2024.5 and maybe earlier do not select device nodes for
>
> That should be just since db9c05a08709 ("validator: Rework selecting
> schemas for validation") AKA the 6x speed up in v2024.04.
>
> > given binding validation if the schema contains compatible list with
> > pattern and a const fallback. This leads to binding being a no-op - not
> > being applied at all. Issue should be fixed in the dtschema but for now
> > add a work-around do the binding can be used against DTS validation.
>
> The issue is we only look at the first compatible. I'm testing out a fix
> and will apply it tomorrow assuming no issues. With that, I don't think
> we should apply this patch.
I think we ended up picking up the next iteration of the patch, but we
can probably land a revert later.
>
> >
> > Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> >
> > ---
> >
> > Cc: Akhil P Oommen <quic_akhilpo@quicinc.com>
> > ---
> > .../devicetree/bindings/display/msm/gmu.yaml | 12 ++++++++++++
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/display/msm/gmu.yaml b/Documentation/devicetree/bindings/display/msm/gmu.yaml
> > index b3837368a260..8d1b515f59ec 100644
> > --- a/Documentation/devicetree/bindings/display/msm/gmu.yaml
> > +++ b/Documentation/devicetree/bindings/display/msm/gmu.yaml
> > @@ -17,6 +17,18 @@ description: |
> > management and support to improve power efficiency and reduce the load on
> > the CPU.
> >
> > +# dtschema does not select nodes based on pattern+const, so add custom select
> > +# as a work-around:
> > +select:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - qcom,adreno-gmu
> > + - qcom,adreno-gmu-wrapper
> > + required:
> > + - compatible
> > +
> > properties:
> > compatible:
> > oneOf:
> > --
> > 2.43.0
> >
--
With best wishes
Dmitry
On 26/06/2024 06:31, Dmitry Baryshkov wrote:
> On Tue, Jun 25, 2024 at 04:51:27PM GMT, Rob Herring wrote:
>> On Sun, Jun 23, 2024 at 02:59:30PM +0200, Krzysztof Kozlowski wrote:
>>> dtschema v2024.4, v2024.5 and maybe earlier do not select device nodes for
>>
>> That should be just since db9c05a08709 ("validator: Rework selecting
>> schemas for validation") AKA the 6x speed up in v2024.04.
>>
>>> given binding validation if the schema contains compatible list with
>>> pattern and a const fallback. This leads to binding being a no-op - not
>>> being applied at all. Issue should be fixed in the dtschema but for now
>>> add a work-around do the binding can be used against DTS validation.
>>
>> The issue is we only look at the first compatible. I'm testing out a fix
>> and will apply it tomorrow assuming no issues. With that, I don't think
>> we should apply this patch.
>
> I think we ended up picking up the next iteration of the patch, but we
> can probably land a revert later.
gpu patch was applied. This is gmu, so can be just ignored/skipped.
Anyway the code here should not have negative effect, so we can revert
it anytime later, e.g. when users upgrade to fixed dtschema.
Best regards,
Krzysztof
© 2016 - 2025 Red Hat, Inc.