Message ID | 20221216215819.1164973-2-marijn.suijten@somainline.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:e747:0:0:0:0:0 with SMTP id c7csp1220007wrn; Fri, 16 Dec 2022 14:03:53 -0800 (PST) X-Google-Smtp-Source: AA0mqf69XaNVwh04sFirf+1ZieVqCsmRc9zgOzlYG34iiFpACJI1WiTH1APkhKYKpmZeGq1nSL6Z X-Received: by 2002:a17:907:2a57:b0:7c1:52a:e903 with SMTP id fe23-20020a1709072a5700b007c1052ae903mr33256881ejc.55.1671228233375; Fri, 16 Dec 2022 14:03:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1671228233; cv=none; d=google.com; s=arc-20160816; b=ak5jBqVGDcGBPde5kMJ4LwZzLWTCo8E8A9t0OtmfBMa9zJaT6gw5pTIvp2F2rVu+My B0AfsdY7eKS+Fie1uHLF/+d1YLdsAERTHvuA/0FcLH/XtaAQSh2Izke3h68dfLhg4k5L sNAutbGNWLj/G+4qLTQ9ZkzMgk6s7WY4fw4jkRHbNuyO5jAPbAnI4XzUfj75BrGd1lI/ sf7t8UIgD6zMpBl5a2UELe7apJ+ZzDk2vT04yxbn35ti34AQTI0ESWXn+cVSMryC6cAv i4VRq8crDbRgcStLvOEuk3CbDUEg1BSTonAkuXtx20w3j04Yz2/g0POzeUEYJ+cxxIxy XlAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=VvMETFselu9YRQcXJmQLigcCDhKc6NFL9+NZHBTXIzk=; b=bwYAD63Y/5r/t4v8dlL/SFjbZYB3mTyjbD4VKTnHvHadMsNbcRDfesivyeLJFkTvtn 4WjZoLjSnB7S+AtzAbGYAoSPaekzjiiuohY3idVPFLFVjhX1LWVWkGYNN2kiIup7nCL+ 0DCQdBOpe695jovJhGwZ0regSiIwkHsJO70LIl+S7i+/OYIFqnAfP+xdb4vL+ag7GLRv +ij1PlItsy72FSzGalKytyyHxnWP5kDIA9edyZFa3aWcNqMdzUbXcKLmeWEzuNMspz0+ LvHIILUaM32LkGKwE18GhB4Ov+hRjUVzx2E5nv1x1lajxXiT713W6AFfajOBmEgAHBQr to7w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x9-20020a1709065ac900b007c0daa7bc20si2766390ejs.880.2022.12.16.14.03.29; Fri, 16 Dec 2022 14:03:53 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229841AbiLPWAL (ORCPT <rfc822;jeantsuru.cumc.mandola@gmail.com> + 99 others); Fri, 16 Dec 2022 17:00:11 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41766 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229510AbiLPWAH (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 16 Dec 2022 17:00:07 -0500 Received: from relay04.th.seeweb.it (relay04.th.seeweb.it [5.144.164.165]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E581317A94; Fri, 16 Dec 2022 14:00:04 -0800 (PST) Received: from localhost.localdomain (94-209-172-39.cable.dynamic.v4.ziggo.nl [94.209.172.39]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by m-r1.th.seeweb.it (Postfix) with ESMTPSA id 6A9892010A; Fri, 16 Dec 2022 23:00:02 +0100 (CET) From: Marijn Suijten <marijn.suijten@somainline.org> To: phone-devel@vger.kernel.org, Will Deacon <will@kernel.org>, Joerg Roedel <joro@8bytes.org>, Bjorn Andersson <andersson@kernel.org> Cc: ~postmarketos/upstreaming@lists.sr.ht, AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>, Konrad Dybcio <konrad.dybcio@somainline.org>, Martin Botka <martin.botka@somainline.org>, Jami Kettunen <jami.kettunen@somainline.org>, Marijn Suijten <marijn.suijten@somainline.org>, Lux Aliaga <they@mint.lgbt>, Robin Murphy <robin.murphy@arm.com>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Andy Gross <agross@kernel.org>, Konrad Dybcio <konrad.dybcio@linaro.org>, Dmitry Baryshkov <dmitry.baryshkov@linaro.org>, Thierry Reding <treding@nvidia.com>, Melody Olvera <quic_molvera@quicinc.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Bhupesh Sharma <bhupesh.sharma@linaro.org>, Douglas Anderson <dianders@chromium.org>, linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org Subject: [PATCH v4 1/4] dt-bindings: arm-smmu: Document smmu-500 binding for SM6125 Date: Fri, 16 Dec 2022 22:58:16 +0100 Message-Id: <20221216215819.1164973-2-marijn.suijten@somainline.org> X-Mailer: git-send-email 2.39.0 In-Reply-To: <20221216215819.1164973-1-marijn.suijten@somainline.org> References: <20221216215819.1164973-1-marijn.suijten@somainline.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1752409815951598408?= X-GMAIL-MSGID: =?utf-8?q?1752409815951598408?= |
Series |
arm64: dts: qcom: sm6125: Enable APPS SMMU
|
|
Commit Message
Marijn Suijten
Dec. 16, 2022, 9:58 p.m. UTC
From: Martin Botka <martin.botka@somainline.org> Document smmu-500 compatibility with the SM6125 SoC. Signed-off-by: Martin Botka <martin.botka@somainline.org> [Marijn: Move compatible to the new, generic, qcom,smmu-500 list] Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> --- Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 1 + 1 file changed, 1 insertion(+)
Comments
On 16/12/2022 22:58, Marijn Suijten wrote: > From: Martin Botka <martin.botka@somainline.org> > > Document smmu-500 compatibility with the SM6125 SoC. > Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Best regards, Krzysztof
On 19/12/2022 10:07, Krzysztof Kozlowski wrote: > On 16/12/2022 22:58, Marijn Suijten wrote: >> From: Martin Botka <martin.botka@somainline.org> >> >> Document smmu-500 compatibility with the SM6125 SoC. >> > > Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Wait, not entirely... no constraints for clocks and regs? Best regards, Krzysztof
On 2022-12-19 10:09:03, Krzysztof Kozlowski wrote: > On 19/12/2022 10:07, Krzysztof Kozlowski wrote: > > On 16/12/2022 22:58, Marijn Suijten wrote: > >> From: Martin Botka <martin.botka@somainline.org> > >> > >> Document smmu-500 compatibility with the SM6125 SoC. > >> > > > > Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > > Wait, not entirely... no constraints for clocks and regs? Quite odd that there is no warning for my DT patch as it clearly requires at least one clock... Irrespective of that downstream doesn't define any (nor power domains). How should we proceed? - Marijn
On 19/12/2022 20:28, Marijn Suijten wrote: > On 2022-12-19 10:09:03, Krzysztof Kozlowski wrote: >> On 19/12/2022 10:07, Krzysztof Kozlowski wrote: >>> On 16/12/2022 22:58, Marijn Suijten wrote: >>>> From: Martin Botka <martin.botka@somainline.org> >>>> >>>> Document smmu-500 compatibility with the SM6125 SoC. >>>> >>> >>> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> >> >> Wait, not entirely... no constraints for clocks and regs? > > Quite odd that there is no warning for my DT patch as it clearly > requires at least one clock... > > Irrespective of that downstream doesn't define any (nor power domains). > How should we proceed? Binding now has constraints for clocks so at least that should be added to your variant. Best regards, Krzysztof
On 2022-12-20 10:52:49, Krzysztof Kozlowski wrote: > On 19/12/2022 20:28, Marijn Suijten wrote: > > On 2022-12-19 10:09:03, Krzysztof Kozlowski wrote: > >> On 19/12/2022 10:07, Krzysztof Kozlowski wrote: > >>> On 16/12/2022 22:58, Marijn Suijten wrote: > >>>> From: Martin Botka <martin.botka@somainline.org> > >>>> > >>>> Document smmu-500 compatibility with the SM6125 SoC. > >>>> > >>> > >>> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > >> > >> Wait, not entirely... no constraints for clocks and regs? > > > > Quite odd that there is no warning for my DT patch as it clearly > > requires at least one clock... Again, any idea why there's no warning for this DT mismatching minItems: 1 for clocks, clock-names and power-domains? > > Irrespective of that downstream doesn't define any (nor power domains). > > How should we proceed? > > Binding now has constraints for clocks so at least that should be added > to your variant. And that should be: clock-names: false clocks: false power-domains: false Because this board does declare have any, at least not when going off of downstream DT? - Marijn
On 22/12/2022 09:23, Marijn Suijten wrote: > On 2022-12-20 10:52:49, Krzysztof Kozlowski wrote: >> On 19/12/2022 20:28, Marijn Suijten wrote: >>> On 2022-12-19 10:09:03, Krzysztof Kozlowski wrote: >>>> On 19/12/2022 10:07, Krzysztof Kozlowski wrote: >>>>> On 16/12/2022 22:58, Marijn Suijten wrote: >>>>>> From: Martin Botka <martin.botka@somainline.org> >>>>>> >>>>>> Document smmu-500 compatibility with the SM6125 SoC. >>>>>> >>>>> >>>>> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> >>>> >>>> Wait, not entirely... no constraints for clocks and regs? >>> >>> Quite odd that there is no warning for my DT patch as it clearly >>> requires at least one clock... > > Again, any idea why there's no warning for this DT mismatching minItems: > 1 for clocks, clock-names and power-domains? I don't know what do you have in DT and what is mismatched. Why there should be a warning? > >>> Irrespective of that downstream doesn't define any (nor power domains). >>> How should we proceed? >> >> Binding now has constraints for clocks so at least that should be added >> to your variant. > > And that should be: > > clock-names: false > clocks: false > power-domains: false > > Because this board does declare have any, at least not when going off of > downstream DT? I'll add it for existing platforms, so you can rebase on top. Best regards, Krzysztof
On 2022-12-22 10:29:40, Krzysztof Kozlowski wrote: > On 22/12/2022 09:23, Marijn Suijten wrote: > > On 2022-12-20 10:52:49, Krzysztof Kozlowski wrote: > >> On 19/12/2022 20:28, Marijn Suijten wrote: > >>> On 2022-12-19 10:09:03, Krzysztof Kozlowski wrote: > >>>> On 19/12/2022 10:07, Krzysztof Kozlowski wrote: > >>>>> On 16/12/2022 22:58, Marijn Suijten wrote: > >>>>>> From: Martin Botka <martin.botka@somainline.org> > >>>>>> > >>>>>> Document smmu-500 compatibility with the SM6125 SoC. > >>>>>> > >>>>> > >>>>> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > >>>> > >>>> Wait, not entirely... no constraints for clocks and regs? > >>> > >>> Quite odd that there is no warning for my DT patch as it clearly > >>> requires at least one clock... > > > > Again, any idea why there's no warning for this DT mismatching minItems: > > 1 for clocks, clock-names and power-domains? > > I don't know what do you have in DT and what is mismatched. Why there > should be a warning? There is: clock-names: minItems: 1 maxItems: 7 clocks: minItems: 1 maxItems: 7 But I did not provide _any_ (see patch 2 of this series). Shouldn't that trigger a warning? > >>> Irrespective of that downstream doesn't define any (nor power domains). > >>> How should we proceed? > >> > >> Binding now has constraints for clocks so at least that should be added > >> to your variant. > > > > And that should be: > > > > clock-names: false > > clocks: false > > power-domains: false > > > > Because this board does declare have any, at least not when going off of > > downstream DT? > > I'll add it for existing platforms, so you can rebase on top. Thanks, will do! - Marijn
On 22/12/2022 11:10, Marijn Suijten wrote: > On 2022-12-22 10:29:40, Krzysztof Kozlowski wrote: >> On 22/12/2022 09:23, Marijn Suijten wrote: >>> On 2022-12-20 10:52:49, Krzysztof Kozlowski wrote: >>>> On 19/12/2022 20:28, Marijn Suijten wrote: >>>>> On 2022-12-19 10:09:03, Krzysztof Kozlowski wrote: >>>>>> On 19/12/2022 10:07, Krzysztof Kozlowski wrote: >>>>>>> On 16/12/2022 22:58, Marijn Suijten wrote: >>>>>>>> From: Martin Botka <martin.botka@somainline.org> >>>>>>>> >>>>>>>> Document smmu-500 compatibility with the SM6125 SoC. >>>>>>>> >>>>>>> >>>>>>> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> >>>>>> >>>>>> Wait, not entirely... no constraints for clocks and regs? >>>>> >>>>> Quite odd that there is no warning for my DT patch as it clearly >>>>> requires at least one clock... >>> >>> Again, any idea why there's no warning for this DT mismatching minItems: >>> 1 for clocks, clock-names and power-domains? >> >> I don't know what do you have in DT and what is mismatched. Why there >> should be a warning? > > There is: > > clock-names: > minItems: 1 > maxItems: 7 > > clocks: > minItems: 1 > maxItems: 7 > > But I did not provide _any_ (see patch 2 of this series). Shouldn't > that trigger a warning? No. Are these required properties? Best regards, Krzysztof
On 2022-12-22 11:36:49, Krzysztof Kozlowski wrote: > [..] > > There is: > > > > clock-names: > > minItems: 1 > > maxItems: 7 > > > > clocks: > > minItems: 1 > > maxItems: 7 > > > > But I did not provide _any_ (see patch 2 of this series). Shouldn't > > that trigger a warning? > > No. Are these required properties? Ah right, this has no effect if the property is not required. Only if the property is set should it adhere to minItems; that is, `clocks;` or `clock-names;` as boolean property isn't allowed, it has to have `clocks = <between 1 and 7 items>`. - Marijn
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml index b28c5c2b0ff2..95b03fd86e18 100644 --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml @@ -43,6 +43,7 @@ properties: - qcom,sdm670-smmu-500 - qcom,sdm845-smmu-500 - qcom,sm6115-smmu-500 + - qcom,sm6125-smmu-500 - qcom,sm6350-smmu-500 - qcom,sm6375-smmu-500 - qcom,sm8150-smmu-500