[05/10] dt-bindings: interconnect: Add sm8350, sc8280xp and generic OSM L3 compatibles
Message ID | 20221028034155.5580-6-quic_bjorande@quicinc.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp596679wru; Thu, 27 Oct 2022 20:45:45 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7AllV353wHEGVeaaBYLwg/PeaG6/KFqSEp3vQb/w7JKjfkGlJUqBwErfsYTxE1ZXf8+okC X-Received: by 2002:a17:906:cc0b:b0:78d:f3b9:ab15 with SMTP id ml11-20020a170906cc0b00b0078df3b9ab15mr44372127ejb.367.1666928745429; Thu, 27 Oct 2022 20:45:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666928745; cv=none; d=google.com; s=arc-20160816; b=oIUqGDbdcrx32QAji0F1BuQdpkTtje/ZA5rgRVECxijlVZEro41eYitj3J+9gQ6H7z 4blOCyNjjCsNA83Znl6MC/fK6l+CD9E/4iephU+uHhB70M0+avILjo8eJS93+IpSUnad IcP6SaoTvAc9loOfm2fekaSnh6dFPiie/AgmCOuJcP9igqNOmMKhQG693c9CZKG7RCCx fNWzx55E8VxOlkWEE1vAQJzax/LSRLDw4PcIqIrwbRBQ48vTjb5m/F8ow60ZOEO98dol FfznG3JEuzgIMQagrX2h3TaZVS0puDZafqBBmSYgUDmNKIs+I75Szk0KH+3vhrHHnMuj VNcA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=im6yITI1531e3Mh3hR1LfHjB0NtsCe0RG1IWCtmk4iY=; b=reMY4Z36STAuVKH8D9F42xUgqjkYAdiyn2F3qZdsL9i/nJoYI7O4zfClcD1MCgr59K R8OP5Mn6dNIaX4sfPs68vIThYrxGoL1OVwbMpnNDHdgRlo1nrMjAUBl3POchOoFgi/m/ qZeuINCAs1MZB5z7+axI4jDN656pUsZhV8HrEjS7d1sQ/DIRXuLferxN6riIozUCQu7k PAOqdY9dJdxUwThhxbP7X7BagSG+zqtEhDm8imLiD1jraP3EWH+ICPhtrZgXU+0VmVbE YJnbUxFcOgk8awvSf6mYiItlV781q+Qkgs/Gn9LHTVE37dSQbSSyVtpdzcxQm7eoTohL 36RA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=iwTont8e; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id qa36-20020a17090786a400b007879808e995si629484ejc.55.2022.10.27.20.45.21; Thu, 27 Oct 2022 20:45:45 -0700 (PDT) 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; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=iwTont8e; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236127AbiJ1Dma (ORCPT <rfc822;chrisfriedt@gmail.com> + 99 others); Thu, 27 Oct 2022 23:42:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56568 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236002AbiJ1DmQ (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 27 Oct 2022 23:42:16 -0400 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ABE9FD0CC0; Thu, 27 Oct 2022 20:42:15 -0700 (PDT) Received: from pps.filterd (m0279872.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 29S2o1OV026286; Fri, 28 Oct 2022 03:42:05 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-type; s=qcppdkim1; bh=im6yITI1531e3Mh3hR1LfHjB0NtsCe0RG1IWCtmk4iY=; b=iwTont8evdsUviVhgp9O75tYPdiyTpn1kZrOae1lXRD7WHicr4U+FYyd38mKB1STUpld 8akzpRmedS5PIS4L+92RDmFWqFbEf0gDpx2Urt4mKKvdDe+rwbIv2kscH9vE3I4k+Yqq /CreEPPkf6n0WiDmezvpZjnS5VtpqnU9vGzf7ADETJlLYwJODA+AhN+pwNLxqxSM9i+G pzItdQ96hHPCLvw8zv4XZxcKKl8bNmn9ajQZ4Dq82et5gWoJEH062dlRl6I0GRWi4BD3 TFJ0mTyy0jaGquq6AHLt7lvQHCqcjrRk3ketyxUMyrV3iQHE0OABNcXCAK9OsZZljipM 1g== Received: from nalasppmta02.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3kfahwbxt2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 28 Oct 2022 03:42:05 +0000 Received: from nalasex01c.na.qualcomm.com (nalasex01c.na.qualcomm.com [10.47.97.35]) by NALASPPMTA02.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 29S3g41c001405 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 28 Oct 2022 03:42:04 GMT Received: from th-lint-050.qualcomm.com (10.80.80.8) by nalasex01c.na.qualcomm.com (10.47.97.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.29; Thu, 27 Oct 2022 20:42:03 -0700 From: Bjorn Andersson <quic_bjorande@quicinc.com> To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>, Georgi Djakov <djakov@kernel.org>, Rob Herring <robh+dt@kernel.org>, Sibi Sankar <quic_sibis@quicinc.com> CC: Bjorn Andersson <andersson@kernel.org>, Konrad Dybcio <konrad.dybcio@somainline.org>, Mike Tipton <quic_mdtipton@quicinc.com>, Johan Hovold <johan+linaro@kernel.org>, <linux-arm-msm@vger.kernel.org>, <linux-pm@vger.kernel.org>, <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org> Subject: [PATCH 05/10] dt-bindings: interconnect: Add sm8350, sc8280xp and generic OSM L3 compatibles Date: Thu, 27 Oct 2022 20:41:50 -0700 Message-ID: <20221028034155.5580-6-quic_bjorande@quicinc.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20221028034155.5580-1-quic_bjorande@quicinc.com> References: <20221028034155.5580-1-quic_bjorande@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01b.na.qualcomm.com (10.46.141.250) To nalasex01c.na.qualcomm.com (10.47.97.35) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-GUID: SR_D6yQBde2Tvf8ljaRrri17d423xc6k X-Proofpoint-ORIG-GUID: SR_D6yQBde2Tvf8ljaRrri17d423xc6k X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-10-27_07,2022-10-27_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 impostorscore=0 phishscore=0 bulkscore=0 suspectscore=0 adultscore=0 lowpriorityscore=0 priorityscore=1501 mlxscore=0 malwarescore=0 spamscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000 definitions=main-2210280022 X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE, SPF_PASS autolearn=ham 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?1747901476196620328?= X-GMAIL-MSGID: =?utf-8?q?1747901476196620328?= |
Series |
interconnect: osm-l3: SC8280XP L3 and DDR scaling
|
|
Commit Message
Bjorn Andersson
Oct. 28, 2022, 3:41 a.m. UTC
Add EPSS L3 compatibles for sm8350 and sc8280xp, but while at it also
introduce generic compatible for both qcom,osm-l3 and qcom,epss-l3.
Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
---
.../bindings/interconnect/qcom,osm-l3.yaml | 22 +++++++++++++------
1 file changed, 15 insertions(+), 7 deletions(-)
Comments
On Thu, 27 Oct 2022 20:41:50 -0700, Bjorn Andersson wrote: > Add EPSS L3 compatibles for sm8350 and sc8280xp, but while at it also > introduce generic compatible for both qcom,osm-l3 and qcom,epss-l3. > > Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> > --- > .../bindings/interconnect/qcom,osm-l3.yaml | 22 +++++++++++++------ > 1 file changed, 15 insertions(+), 7 deletions(-) > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: ./Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml:27:7: [error] duplication of key "items" in mapping (key-duplicates) dtschema/dtc warnings/errors: make[1]: *** Deleting file 'Documentation/devicetree/bindings/interconnect/qcom,osm-l3.example.dts' Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml:27:7: found duplicate key "items" with value "[]" (original value: "[]") make[1]: *** [Documentation/devicetree/bindings/Makefile:26: Documentation/devicetree/bindings/interconnect/qcom,osm-l3.example.dts] Error 1 make[1]: *** Waiting for unfinished jobs.... ./Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml:27:7: found duplicate key "items" with value "[]" (original value: "[]") /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml: ignoring, error parsing file make: *** [Makefile:1492: dt_binding_check] Error 2 doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/patch/ This check can fail if there are any dependencies. The base for a patch series is generally the most recent rc1. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit.
On 27/10/2022 23:41, Bjorn Andersson wrote: > Add EPSS L3 compatibles for sm8350 and sc8280xp, but while at it also > introduce generic compatible for both qcom,osm-l3 and qcom,epss-l3. > > Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> > --- > .../bindings/interconnect/qcom,osm-l3.yaml | 22 +++++++++++++------ > 1 file changed, 15 insertions(+), 7 deletions(-) > > diff --git a/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml b/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml > index bf538c0c5a81..ae0995341a78 100644 > --- a/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml > +++ b/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml > @@ -16,13 +16,21 @@ description: > > properties: > compatible: > - enum: > - - qcom,sc7180-osm-l3 > - - qcom,sc7280-epss-l3 > - - qcom,sc8180x-osm-l3 > - - qcom,sdm845-osm-l3 > - - qcom,sm8150-osm-l3 > - - qcom,sm8250-epss-l3 > + oneOf: > + items: oneOf expects a list, so this should be " - items" > + - enum: > + - qcom,sc7180-osm-l3 > + - qcom,sc8180x-osm-l3 > + - qcom,sdm845-osm-l3 > + - qcom,sm8150-osm-l3 > + - const: qcom,osm-l3 The concept is good, but are you sure all SoCs will be compatible with generic osm-l3? Why not using dedicated compatible of one soc, e.g. the oldest here? We already did like that for BWMON, DMA and few others. > + items: > + - enum: > + - qcom,sc7280-epss-l3 > + - qcom,sc8280xp-epss-l3 > + - qcom,sm8250-epss-l3 > + - qcom,sm8350-epss-l3 > + - const: qcom,epss-l3 > > reg: > maxItems: 1 Best regards, Krzysztof
On Fri, Oct 28, 2022 at 06:12:29PM -0400, Krzysztof Kozlowski wrote: > On 27/10/2022 23:41, Bjorn Andersson wrote: > > Add EPSS L3 compatibles for sm8350 and sc8280xp, but while at it also > > introduce generic compatible for both qcom,osm-l3 and qcom,epss-l3. > > > > Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> > > --- > > .../bindings/interconnect/qcom,osm-l3.yaml | 22 +++++++++++++------ > > 1 file changed, 15 insertions(+), 7 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml b/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml > > index bf538c0c5a81..ae0995341a78 100644 > > --- a/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml > > +++ b/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml > > @@ -16,13 +16,21 @@ description: > > > > properties: > > compatible: > > - enum: > > - - qcom,sc7180-osm-l3 > > - - qcom,sc7280-epss-l3 > > - - qcom,sc8180x-osm-l3 > > - - qcom,sdm845-osm-l3 > > - - qcom,sm8150-osm-l3 > > - - qcom,sm8250-epss-l3 > > + oneOf: > > + items: > > oneOf expects a list, so this should be " - items" > Ahh, thanks. Must have missed running the dt_binding_check on this one. > > + - enum: > > + - qcom,sc7180-osm-l3 > > + - qcom,sc8180x-osm-l3 > > + - qcom,sdm845-osm-l3 > > + - qcom,sm8150-osm-l3 > > + - const: qcom,osm-l3 > > The concept is good, but are you sure all SoCs will be compatible with > generic osm-l3? Per the current implementation yes, worst case if one or more of them isn't the more specific compatible can be used to alter the behavior of that platform. > Why not using dedicated compatible of one soc, e.g. the > oldest here? We already did like that for BWMON, DMA and few others. > Because if we say compatible = "qcom,sc8180x-osm-l3", "qcom,sdm845-osm-l3" and there is a quirk needed for "qcom,sdm845-osm-l3" we're forced to add a "special case" every other *-osm-l3 in the driver. This way we can have a generic implementation for the qcom,osm-l3 and if we realize that we need to quirk something for the oldest platform, we can do so without affecting the others. Regards, Bjorn > > + items: > > + - enum: > > + - qcom,sc7280-epss-l3 > > + - qcom,sc8280xp-epss-l3 > > + - qcom,sm8250-epss-l3 > > + - qcom,sm8350-epss-l3 > > + - const: qcom,epss-l3 > > > > reg: > > maxItems: 1 > > Best regards, > Krzysztof >
On 02/11/2022 23:44, Bjorn Andersson wrote: > On Fri, Oct 28, 2022 at 06:12:29PM -0400, Krzysztof Kozlowski wrote: >> On 27/10/2022 23:41, Bjorn Andersson wrote: >>> Add EPSS L3 compatibles for sm8350 and sc8280xp, but while at it also >>> introduce generic compatible for both qcom,osm-l3 and qcom,epss-l3. >>> >>> Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> >>> --- >>> .../bindings/interconnect/qcom,osm-l3.yaml | 22 +++++++++++++------ >>> 1 file changed, 15 insertions(+), 7 deletions(-) >>> >>> diff --git a/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml b/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml >>> index bf538c0c5a81..ae0995341a78 100644 >>> --- a/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml >>> +++ b/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml >>> @@ -16,13 +16,21 @@ description: >>> >>> properties: >>> compatible: >>> - enum: >>> - - qcom,sc7180-osm-l3 >>> - - qcom,sc7280-epss-l3 >>> - - qcom,sc8180x-osm-l3 >>> - - qcom,sdm845-osm-l3 >>> - - qcom,sm8150-osm-l3 >>> - - qcom,sm8250-epss-l3 >>> + oneOf: >>> + items: >> >> oneOf expects a list, so this should be " - items" >> > > Ahh, thanks. Must have missed running the dt_binding_check on this one. > >>> + - enum: >>> + - qcom,sc7180-osm-l3 >>> + - qcom,sc8180x-osm-l3 >>> + - qcom,sdm845-osm-l3 >>> + - qcom,sm8150-osm-l3 >>> + - const: qcom,osm-l3 >> >> The concept is good, but are you sure all SoCs will be compatible with >> generic osm-l3? > > Per the current implementation yes, worst case if one or more of them isn't the > more specific compatible can be used to alter the behavior of that platform. > >> Why not using dedicated compatible of one soc, e.g. the >> oldest here? We already did like that for BWMON, DMA and few others. >> > > Because if we say compatible = "qcom,sc8180x-osm-l3", "qcom,sdm845-osm-l3" and > there is a quirk needed for "qcom,sdm845-osm-l3" we're forced to add a "special > case" every other *-osm-l3 in the driver. > > This way we can have a generic implementation for the qcom,osm-l3 and if we > realize that we need to quirk something for the oldest platform, we can do so > without affecting the others. True. This also means we do not really know which one is the generic implementation :) Best regards, Krzysztof
On Thu, Nov 03, 2022 at 08:25:17AM -0400, Krzysztof Kozlowski wrote: > On 02/11/2022 23:44, Bjorn Andersson wrote: > > On Fri, Oct 28, 2022 at 06:12:29PM -0400, Krzysztof Kozlowski wrote: > >> On 27/10/2022 23:41, Bjorn Andersson wrote: > >>> Add EPSS L3 compatibles for sm8350 and sc8280xp, but while at it also > >>> introduce generic compatible for both qcom,osm-l3 and qcom,epss-l3. > >>> > >>> Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> > >>> --- > >>> .../bindings/interconnect/qcom,osm-l3.yaml | 22 +++++++++++++------ > >>> 1 file changed, 15 insertions(+), 7 deletions(-) > >>> > >>> diff --git a/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml b/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml > >>> index bf538c0c5a81..ae0995341a78 100644 > >>> --- a/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml > >>> +++ b/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml > >>> @@ -16,13 +16,21 @@ description: > >>> > >>> properties: > >>> compatible: > >>> - enum: > >>> - - qcom,sc7180-osm-l3 > >>> - - qcom,sc7280-epss-l3 > >>> - - qcom,sc8180x-osm-l3 > >>> - - qcom,sdm845-osm-l3 > >>> - - qcom,sm8150-osm-l3 > >>> - - qcom,sm8250-epss-l3 > >>> + oneOf: > >>> + items: > >> > >> oneOf expects a list, so this should be " - items" > >> > > > > Ahh, thanks. Must have missed running the dt_binding_check on this one. > > > >>> + - enum: > >>> + - qcom,sc7180-osm-l3 > >>> + - qcom,sc8180x-osm-l3 > >>> + - qcom,sdm845-osm-l3 > >>> + - qcom,sm8150-osm-l3 > >>> + - const: qcom,osm-l3 > >> > >> The concept is good, but are you sure all SoCs will be compatible with > >> generic osm-l3? > > > > Per the current implementation yes, worst case if one or more of them isn't the > > more specific compatible can be used to alter the behavior of that platform. > > > >> Why not using dedicated compatible of one soc, e.g. the > >> oldest here? We already did like that for BWMON, DMA and few others. > >> > > > > Because if we say compatible = "qcom,sc8180x-osm-l3", "qcom,sdm845-osm-l3" and > > there is a quirk needed for "qcom,sdm845-osm-l3" we're forced to add a "special > > case" every other *-osm-l3 in the driver. > > > > This way we can have a generic implementation for the qcom,osm-l3 and if we > > realize that we need to quirk something for the oldest platform, we can do so > > without affecting the others. > > True. This also means we do not really know which one is the generic > implementation :) > There currently is an implementation without platform specific quirks, I call that the generic implementation and suggest that we refer to that using "qcom,osm-l3". If we instead were to use sdm845 as the generic compatible, and there turns out to be a need for a quirk for this platform, you: 1) no longer have a generic implementation, but 4 platform-specific implementations 2) have 3 platforms claiming to be compatible with the quirked (now specialized) implementation, which they clearly aren't anymore Therefor I favor using generic names for generic compatibles. Regards, Bjorn
On 03/11/2022 11:46, Bjorn Andersson wrote: > On Thu, Nov 03, 2022 at 08:25:17AM -0400, Krzysztof Kozlowski wrote: >> On 02/11/2022 23:44, Bjorn Andersson wrote: >>> On Fri, Oct 28, 2022 at 06:12:29PM -0400, Krzysztof Kozlowski wrote: >>>> On 27/10/2022 23:41, Bjorn Andersson wrote: >>>>> Add EPSS L3 compatibles for sm8350 and sc8280xp, but while at it also >>>>> introduce generic compatible for both qcom,osm-l3 and qcom,epss-l3. >>>>> >>>>> Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> >>>>> --- >>>>> .../bindings/interconnect/qcom,osm-l3.yaml | 22 +++++++++++++------ >>>>> 1 file changed, 15 insertions(+), 7 deletions(-) >>>>> >>>>> diff --git a/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml b/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml >>>>> index bf538c0c5a81..ae0995341a78 100644 >>>>> --- a/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml >>>>> +++ b/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml >>>>> @@ -16,13 +16,21 @@ description: >>>>> >>>>> properties: >>>>> compatible: >>>>> - enum: >>>>> - - qcom,sc7180-osm-l3 >>>>> - - qcom,sc7280-epss-l3 >>>>> - - qcom,sc8180x-osm-l3 >>>>> - - qcom,sdm845-osm-l3 >>>>> - - qcom,sm8150-osm-l3 >>>>> - - qcom,sm8250-epss-l3 >>>>> + oneOf: >>>>> + items: >>>> >>>> oneOf expects a list, so this should be " - items" >>>> >>> >>> Ahh, thanks. Must have missed running the dt_binding_check on this one. >>> >>>>> + - enum: >>>>> + - qcom,sc7180-osm-l3 >>>>> + - qcom,sc8180x-osm-l3 >>>>> + - qcom,sdm845-osm-l3 >>>>> + - qcom,sm8150-osm-l3 >>>>> + - const: qcom,osm-l3 >>>> >>>> The concept is good, but are you sure all SoCs will be compatible with >>>> generic osm-l3? >>> >>> Per the current implementation yes, worst case if one or more of them isn't the >>> more specific compatible can be used to alter the behavior of that platform. >>> >>>> Why not using dedicated compatible of one soc, e.g. the >>>> oldest here? We already did like that for BWMON, DMA and few others. >>>> >>> >>> Because if we say compatible = "qcom,sc8180x-osm-l3", "qcom,sdm845-osm-l3" and >>> there is a quirk needed for "qcom,sdm845-osm-l3" we're forced to add a "special >>> case" every other *-osm-l3 in the driver. >>> >>> This way we can have a generic implementation for the qcom,osm-l3 and if we >>> realize that we need to quirk something for the oldest platform, we can do so >>> without affecting the others. >> >> True. This also means we do not really know which one is the generic >> implementation :) >> > > There currently is an implementation without platform specific quirks, I > call that the generic implementation and suggest that we refer to that > using "qcom,osm-l3".> > If we instead were to use sdm845 as the generic compatible, and there > turns out to be a need for a quirk for this platform, you: > > 1) no longer have a generic implementation, but 4 platform-specific > implementations It's okay because there is no such thing anymore as "generic implementation". If this happened, your generic compatible is not specific enough. It does not represent any specific hardware. Adding generic compatibles just to make driver binding easier, is a bit in contrast with DT which should focus on hardware description. > > 2) have 3 platforms claiming to be compatible with the quirked (now > specialized) implementation, which they clearly aren't anymore Yes, that's the problem and this is why I mentioned that we do not know the generic implementation. If we knew that sdm845 is the generic, we would not expect specific quirks for it. If you cannot make sdm845 generic because of unknown quirk, then you just do not know which one is generic implementation and that compatible is not specific enough... Or it is specific only to current Linux driver. > Therefor I favor using generic names for generic compatibles. They make driver development easier but they hide the real match between hardware and compatible. Best regards, Krzysztof
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml b/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml index bf538c0c5a81..ae0995341a78 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml @@ -16,13 +16,21 @@ description: properties: compatible: - enum: - - qcom,sc7180-osm-l3 - - qcom,sc7280-epss-l3 - - qcom,sc8180x-osm-l3 - - qcom,sdm845-osm-l3 - - qcom,sm8150-osm-l3 - - qcom,sm8250-epss-l3 + oneOf: + items: + - enum: + - qcom,sc7180-osm-l3 + - qcom,sc8180x-osm-l3 + - qcom,sdm845-osm-l3 + - qcom,sm8150-osm-l3 + - const: qcom,osm-l3 + items: + - enum: + - qcom,sc7280-epss-l3 + - qcom,sc8280xp-epss-l3 + - qcom,sm8250-epss-l3 + - qcom,sm8350-epss-l3 + - const: qcom,epss-l3 reg: maxItems: 1