linux-kernel - Re: [PATCH v4 1/2] dt-bindings: remoteproc: mediatek: Make l1tcm reg exclusive to mt819x

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] [day] [month] [year] [list]

Date:   Wed, 11 May 2022 15:58:10 -0400
From:   Nícolas F. R. A. Prado 
        <nfraprado@...labora.com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc:     Bjorn Andersson <bjorn.andersson@...aro.org>,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>, kernel@...labora.com,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Mathieu Poirier <mathieu.poirier@...aro.org>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Tinghan Shen <tinghan.shen@...iatek.com>,
        Tzung-Bi Shih <tzungbi@...gle.com>, devicetree@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-mediatek@...ts.infradead.org,
        linux-remoteproc@...r.kernel.org
Subject: Re: [PATCH v4 1/2] dt-bindings: remoteproc: mediatek: Make l1tcm reg
 exclusive to mt819x

On Wed, May 11, 2022 at 11:12:45AM +0200, Krzysztof Kozlowski wrote:
> On 10/05/2022 18:50, Nícolas F. R. A. Prado wrote:
> >>> Also I had to add a description to the global reg-names, since it
> >>> couldn't be neither missing nor empty.
> >>
> >> It is possible:
> >> https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/example-schema.yaml#L91
> >>
> >> Keep constraints and list of names in properties. Then in allOf:if:then
> >> raise minItems or lower maxItems, depending on the variant.
> > 
> > Hi Krzysztof,
> > 
> > that example only shows setting minItems to override the default value, but the
> > issue here is that it's not possible to override minItems/maxItems (after
> > they're already set, even if implicitly) with a different value in the if.
> 
> No, this example shows exactly what you need in first step - make one
> item on the list optional.
> 
> There are several other examples for the entire picture or different
> aproach:
> https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/example-schema.yaml#L91
> 
> https://elixir.bootlin.com/linux/v5.18-rc2/source/Documentation/devicetree/bindings/clock/samsung,exynos7885-clock.yaml#L53
> 
> > 
> > That is:
> > 
> > 	properties:
> > 	  reg-names:
> > 	    items:
> > 	      - const: sram
> > 	      - const: cfg
> > 	      - const: l1tcm
> 
> You did not use the example I gave you. Where is the minItems?
> 
> > 
> > 	if:
> > 	  properties:
> > 	    compatible:
> > 	      enum:
> > 		- mediatek,mt8183-scp
> > 		- mediatek,mt8186-scp
> > 	then:
> > 	  properties:
> > 	    reg-names:
> > 	      minItems: 2
> > 	      maxItems: 2
> > 
> > Generates the error on dtbs_check:
> > 
> > /home/nfraprado/ext/git/linux/arch/arm64/boot/dts/mediatek/mt8183-kukui-kakadu.dtb: scp@...00000: reg-names: ['sram', 'cfg'] is too short
> 
> Missing minItems in first properties.
> 
> > 
> > I believe the tooling is implicitly adding
> > 
> > 	      minItems: 3
> > 	      maxItems: 3
> > 
> > to the common reg-names, and since it's not possible to override them, the
> > override to 2 doesn't work so they are kept at 3, causing the error.
> > 
> > Moving the minItems/maxItems to the common reg-names as a test gives:
> 
> You cannot just. You need it in both places.

OK, now I get it. I sent v5 addressing this.

Thanks,
Nícolas

> 
> > 
> > /home/nfraprado/ext/git/linux/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml: properties:reg-names: {'minItems': 2, 'maxItems': 2, 'items': [{'const': 'sram'}, {'const': 'cfg'}, {'const': 'l1tcm'}]} should not be valid under {'required': ['maxItems']}
> > 	hint: "maxItems" is not needed with an "items" list
> > 
> > That error, plus looking in the items meta-schema, suggests me that maxItems
> > isn't supposed to be set lower then the length of items. So even if the
> > minItems/maxItems override is fixed, there's still this issue. It seems like
> > defining the reg-names list separetely in each if branch is indeed the right way
> > to go.
> 
> 
> 
> Best regards,
> Krzysztof