Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp2569951rwb; Mon, 7 Nov 2022 15:07:57 -0800 (PST) X-Google-Smtp-Source: AMsMyM6gwqe5eHToT1Lt+IbjUbmiT/ATubpkDBT5THqQnIIpMb5f9/VAOFiJz66knDhNsGgyJ22H X-Received: by 2002:a17:906:2b55:b0:7ae:7ac:db80 with SMTP id b21-20020a1709062b5500b007ae07acdb80mr28908032ejg.187.1667862476863; Mon, 07 Nov 2022 15:07:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1667862476; cv=none; d=google.com; s=arc-20160816; b=Tx2eR4FttvirX8VPUvMyPxWy02TJeFdNS0ZNX8fV/9C5WTTqtYMU4IlcYvvxmE0CoM TLORZTKO/QKSDkDiem7b774FZ+uGySqz1M8ToB1n9liVUKdQZOYh1iMmoIgOHdjVjpW0 0vJGjyQBgJ2A/zi+0Mcm+ZzVMq/wbZeS+v/FD0Kc+00tPcF3KLZsTq045L0tewSILleM 0HPp2NeQ93k94QihzDlwLuuolGvv7IlIU92BOCZdwe92Gn3fG0QJ+LOZuH4vhK+1eqNo ETtHlSWfne8GNrL+hmizU6DNLiomRm7A68uzPN1Xl9t+uWK6xjSC+yUmKyCuktz8brah OUwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=DmVPoVJk6NKOL9HvVxYamgAu6Y3jQwuDHC3VEZfVP4M=; b=M3gSTqzaLsapJXCiZYrmYPTeQz5SY3st56CUETDHcLw2TT4z/9ESpKXyXueJKZmsJy Q7tuTopb+cpwkT87Q2PPH8PcQaTd0EslF/j1XANcl6NazWw6hSGwqHOwnGyxjHfS7pus 9TH6TY+ygFphvomFB9PtQxr4OT/r2mW88K1OEKNQ5HFBcYUNPHZ3iSjWdXLKMyPzlNvk bo3jY2NscdHUl0eSCk+z8go+G4RoZLgaji3X6uIzcNwGB9qxuEkUTmdc3USspJ7G1BOR nIJsUByIbIuexjQKl6ytYf/WxEppmt6lsFTftR1Ci0C2QrDvgx2NValchcrih2B0HeDT B3cA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=ZmOb61x0; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id hd10-20020a170907968a00b007771bc8dbb4si12196876ejc.781.2022.11.07.15.07.34; Mon, 07 Nov 2022 15:07:56 -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; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=ZmOb61x0; 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 S232611AbiKGWqn (ORCPT + 91 others); Mon, 7 Nov 2022 17:46:43 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60884 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230186AbiKGWql (ORCPT ); Mon, 7 Nov 2022 17:46:41 -0500 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9174DCEF; Mon, 7 Nov 2022 14:46:40 -0800 (PST) Received: from pps.filterd (m0279866.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2A7MUKUZ002053; Mon, 7 Nov 2022 22:46:37 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=message-id : date : mime-version : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding; s=qcppdkim1; bh=DmVPoVJk6NKOL9HvVxYamgAu6Y3jQwuDHC3VEZfVP4M=; b=ZmOb61x04nWT9LCCUNPvxvxgk51TZh7amGQc/ut4SPxpExCkG4RvKfrN9/eFW8sQMYLs +cdoXofGg7WIhcY0T9+Bj30HZUz8y5r/ybHo4Ep6q6fC8mDjP1AZcnXKKpi0O5iXkWPW K+s9k4hRTJUPGhXv5hoOXpwbPtSL/3H+xHmP0tud5Hyt4nM0+UF2gRaOZg8uCWPPj9Ko 39rvN3b9H6pBTVktCYbRtec0OVPJZT5sa/2t71UUlURk3+V18w43qBmBmLQwn1/XzeHU TtGGUKFlrKyjFtZhwk8iz4Ifig8Bvz1TVBY9DrCe6xK2aUjUf9vLUA3anD4e8WNaL9Qu DQ== Received: from nasanppmta05.qualcomm.com (i-global254.qualcomm.com [199.106.103.254]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3kq7g4gk2k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 07 Nov 2022 22:46:37 +0000 Received: from nasanex01b.na.qualcomm.com (nasanex01b.na.qualcomm.com [10.46.141.250]) by NASANPPMTA05.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 2A7Mkbqs016401 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 7 Nov 2022 22:46:37 GMT Received: from [10.110.0.244] (10.80.80.8) by nasanex01b.na.qualcomm.com (10.46.141.250) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.29; Mon, 7 Nov 2022 14:46:36 -0800 Message-ID: Date: Mon, 7 Nov 2022 14:46:36 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: [PATCH v3 1/3] dt-bindings: interconnect: Remove required reg field Content-Language: en-US To: Krzysztof Kozlowski , Georgi Djakov , Andy Gross , Bjorn Andersson , Rob Herring , Krzysztof Kozlowski CC: Odelu Kukatla , , , , References: <20221026190520.4004264-1-quic_molvera@quicinc.com> <20221026190520.4004264-2-quic_molvera@quicinc.com> <64d0e5ef-fd36-6f25-2c39-00e8e1346af7@quicinc.com> <1a7fd1fd-4f0d-bec3-ddd5-7c6a99a2ab01@linaro.org> <7d2c43b7-1507-7c30-27f7-3081c6ec77ba@kernel.org> <225f3ff2-62cb-7f11-3eb1-f677360b4359@linaro.org> From: Melody Olvera In-Reply-To: <225f3ff2-62cb-7f11-3eb1-f677360b4359@linaro.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01a.na.qualcomm.com (10.52.223.231) To nasanex01b.na.qualcomm.com (10.46.141.250) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-ORIG-GUID: b0rFN1LLLfOwGg6vKwBRSowRvvdtDHjP X-Proofpoint-GUID: b0rFN1LLLfOwGg6vKwBRSowRvvdtDHjP X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-11-07_11,2022-11-07_02,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 adultscore=0 suspectscore=0 priorityscore=1501 mlxscore=0 mlxlogscore=773 bulkscore=0 spamscore=0 impostorscore=0 lowpriorityscore=0 malwarescore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000 definitions=main-2211070171 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE, 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: X-Mailing-List: linux-kernel@vger.kernel.org On 11/7/2022 10:28 AM, Krzysztof Kozlowski wrote: > On 07/11/2022 15:36, Georgi Djakov wrote: >> Hi, >> >> On 2.11.22 23:11, Krzysztof Kozlowski wrote: >>> On 31/10/2022 19:29, Melody Olvera wrote: >>>> >>>> On 10/27/2022 8:29 AM, Krzysztof Kozlowski wrote: >>>>> On 26/10/2022 15:05, Melody Olvera wrote: >>>>>> Many of the *-virt compatible devices do not have a reg field >>>>>> so remove it as required from the bindings. >>>>> and some virt have it... This should be probably separate binding or if >>>>> the list is small - allOf:if:then. >>>> I attempted this; however I'm still seeing failures in dtb_check. I've added this >>>> to the binding; does this look correct? >>>>  allOf: >>>>    - $ref: qcom,rpmh-common.yaml# >>>> +  - if: >>>> +      properties: >>>> +        compatible: >>>> +          contains: >>>> +            enum: >>>> +              - qcom,qdu1000-clk-virt >>>> +              - qcom,qdu1000-mc-virt >>>> + >>>> +    then: >>>> +      required: >>>> +        - compatible >>> No, because we talk about reg, not compatible. You should not require >>> reg instead for some compatibles... but then the schema is getting >>> complicated. >>> >>> It's difficult to give you recommendation because I do not know what are >>> all these "virt" interconnects. Why some have unit address, why some do not? >> My understanding is that the "reg" property is required for the NoCs that have >> registers for controlling the QoS settings for the ports from Linux side. >> Other NoCs might be controlled by some remote processor and direct access from >> Linux may not be possible, so they do not have unit address and are outside of >> the soc DT node. >> Do we need to strictly define when exactly the "reg" property is required, >> can't we just mark it as optional? > It's preferred to make it strictly required or not allowed, so the > bindings are specific. This also allows to validate for mistakes. It > would be a bit different case if such test for req would make the > bindings complicated. I think it's not the case because we could just > split the bindings into two files: > 1. One for controlled by AP, with reg. > 2. One for controller by remote processors, without reg. > Sounds good. Will drop this change and add a new binding document. Thanks, Melody