Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp43501rwb; Wed, 5 Oct 2022 14:26:39 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5R7EZwYx58mqAu2KmuZeSfOBw4baDMxfP1L9Ecc62fHKxWAJ0P1y3BCQ0Uo+p8BH/OJKsY X-Received: by 2002:a17:907:94ce:b0:78c:6795:d545 with SMTP id dn14-20020a17090794ce00b0078c6795d545mr1268299ejc.530.1665005199126; Wed, 05 Oct 2022 14:26:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1665005199; cv=none; d=google.com; s=arc-20160816; b=wyMAJoPia14qJpttd8xxgS17ggN/AbDf8ecBAXaIbRGmEI7NpY56ctJeki89vwQ5sN cEYAMo+C7lLd5e1EVe6ShKGa+aI5EJ9qjt3IbfUX1VDWX4DYMKQzq6rOQ5YqxhxIyCbd aLpPhnatP6LdGlxprFVo1dbkgHeXTfdA/SzAr0DP04hYhmP0pkolTGvWkUZvV7j4LwXi heuhOWe3VFqOofbpvd4hl/dxBXORcbIQRYpLyyZMknlrsa5ZlvI9N9Yi7xRKr9fm2h3b 71/gNxzDv9autMTpDUHhtIxd3VuEwu5OuBpCmlBCq5pya3BgAWFZzH+ZyEt4Mf+65Q/M 0BvQ== 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=i5CppKjYTcL74zoSy5XGrDawTtB6iQImvmz8wUI5z/Q=; b=n0jHK02QeE6iHZgoeTQlJPh0E6g2CDRLK8SmhYgF0JZuI4M1qZvdYrOhPP/sj2eGTB 4l/E5i52XjPUlPc0BBdW7uWl+Byf2Fb8RW23PdRp9k0CSbR+NbFwYkyuIn3QnTfJY7RC TogmqxYWxY+adB3JneVFw6EVYGizWb2Lb0zVYIgGqOyDf4emGbFn7tX3DKC1xoVLvDYw 6j/j/XET0vg2HSPjt0PgA6xGaFkVt8r6g+F+W1ecQMUNkgWD5bDYl95FKUYr2002+oEa j4ApDaFXwJnDyy9mnxg1ur3gK8nNucAB55US9PI7WNUryREqB1EwvqHsSCsIVFV/Ge51 NURQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=ehIULqob; 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 y2-20020a50eb02000000b004551a7e54acsi13311440edp.74.2022.10.05.14.26.13; Wed, 05 Oct 2022 14:26:39 -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=ehIULqob; 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 S231147AbiJEVIK (ORCPT + 99 others); Wed, 5 Oct 2022 17:08:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33170 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230358AbiJEVIH (ORCPT ); Wed, 5 Oct 2022 17:08:07 -0400 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 896F069F56; Wed, 5 Oct 2022 14:08:06 -0700 (PDT) Received: from pps.filterd (m0279864.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 295KUeHI029945; Wed, 5 Oct 2022 21:08:03 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=i5CppKjYTcL74zoSy5XGrDawTtB6iQImvmz8wUI5z/Q=; b=ehIULqob604XAN0nJg4FNIxo0HjYEdHkOwfA6CIxUvC3xSHxqQd9cnNMrwcvQb/KhSU6 QXqOVLEQgJWOEIpQxAU7Al6IcBkj6b5N25SKFAaHbygQRh2Gb4jTvn2H9Hh+EEJA6KLs DUdPdcOb+tvlKZOy2Uz0bBhzQnpHeZYs3RwnZ+egq9P01NXt0PsI7k6+7eORwwXdGx8A Zy7G4py2AXfl7TYe0dAV+0QgddGBoae4wPG96io20ROKbYAGuNyF2JnxXT4zrwlYgMPB AFQ8FkZjC+jblqFQAGxqixGcPr6f1RmQRC+j28yLszWkFijTWPF3Jv6qkfinfwJI7aqr NQ== Received: from nasanppmta04.qualcomm.com (i-global254.qualcomm.com [199.106.103.254]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3k0escva05-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 05 Oct 2022 21:08:03 +0000 Received: from nasanex01a.na.qualcomm.com ([10.52.223.231]) by NASANPPMTA04.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 295L82cQ009133 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 5 Oct 2022 21:08:02 GMT Received: from [10.110.81.239] (10.80.80.8) by nasanex01a.na.qualcomm.com (10.52.223.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.29; Wed, 5 Oct 2022 14:08:01 -0700 Message-ID: <33da6d3b-29fb-7f26-0667-419b317d8e11@quicinc.com> Date: Wed, 5 Oct 2022 14:08:01 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 Subject: Re: [PATCH 1/5] dt-bindings: firmware: scm: Add QDU1000/QRU1000 compatibles Content-Language: en-US To: Krzysztof Kozlowski , Dmitry Baryshkov , Melody Olvera CC: Andy Gross , Bjorn Andersson , Stephen Boyd , Rob Herring , Krzysztof Kozlowski , Ulf Hansson , Bhupesh Sharma , , , , References: <20221001030641.29354-1-quic_molvera@quicinc.com> <20221001030641.29354-2-quic_molvera@quicinc.com> <09f5d364-320e-9ecc-2c2b-68066c61f802@linaro.org> <9664a623-3c58-49e8-1b9a-69335d844448@linaro.org> <095742cb-61cc-af5d-848c-48b2ea5528ea@quicinc.com> <14872934-93f1-baab-7f1a-cfc55ffd0531@linaro.org> From: Trilok Soni In-Reply-To: <14872934-93f1-baab-7f1a-cfc55ffd0531@linaro.org> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01a.na.qualcomm.com (10.52.223.231) To nasanex01a.na.qualcomm.com (10.52.223.231) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-GUID: a2_cbYPcYzhRJCTNqio6GYmp56K963Yy X-Proofpoint-ORIG-GUID: a2_cbYPcYzhRJCTNqio6GYmp56K963Yy X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.528,FMLib:17.11.122.1 definitions=2022-10-05_05,2022-10-05_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 mlxscore=0 lowpriorityscore=0 malwarescore=0 adultscore=0 mlxlogscore=999 phishscore=0 bulkscore=0 clxscore=1011 impostorscore=0 priorityscore=1501 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2209130000 definitions=main-2210050130 X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,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: X-Mailing-List: linux-kernel@vger.kernel.org On 10/5/2022 1:27 AM, Krzysztof Kozlowski wrote: > On 04/10/2022 23:05, Dmitry Baryshkov wrote: >> On Tue, 4 Oct 2022 at 18:52, Melody Olvera wrote: >>> >>> >>> On 10/4/2022 2:36 AM, Dmitry Baryshkov wrote: >>>> On Tue, 4 Oct 2022 at 09:53, Krzysztof Kozlowski >>>> wrote: >>>>> On 04/10/2022 00:14, Dmitry Baryshkov wrote: >>>>>> On Tue, 4 Oct 2022 at 01:02, Melody Olvera wrote: >>>>>>> >>>>>>> On 10/1/2022 4:25 AM, Krzysztof Kozlowski wrote: >>>>>>>> On 01/10/2022 05:06, Melody Olvera wrote: >>>>>>>>> Add compatibles for scm driver for QDU1000 and QRU1000 platforms. >>>>>>>>> >>>>>>>>> Signed-off-by: Melody Olvera >>>>>>>>> --- >>>>>>>>> Documentation/devicetree/bindings/firmware/qcom,scm.yaml | 2 ++ >>>>>>>>> 1 file changed, 2 insertions(+) >>>>>>>>> >>>>>>>>> diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml >>>>>>>>> index c5b76c9f7ad0..b47a5dda3c3e 100644 >>>>>>>>> --- a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml >>>>>>>>> +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml >>>>>>>>> @@ -51,6 +51,8 @@ properties: >>>>>>>>> - qcom,scm-sm8250 >>>>>>>>> - qcom,scm-sm8350 >>>>>>>>> - qcom,scm-sm8450 >>>>>>>>> + - qcom,scm-qdu1000 >>>>>>>>> + - qcom,scm-qru1000 >>>>>> I think after seeing all the patchsets it's time to ask the following >>>>>> question. Do we really need a duplicate compatibility families: >>>>>> qdu1000 vs qru1000? I'd suggest using a single set of compatibile >>>>>> strings in most of the cases. >>>>>> Settle down onto a single name (qdu,qru, qdru, whatever) and define >>>>>> distinct compat strings only when there is an actual difference? >>>>>> >>>>>> E.g .we don't have separate compatible strings for all the sda660, >>>>>> apq8096, etc. unless this is required by the corresponding hardware >>>>>> block not being compatible with corresponding sdm or msm counterpart. >>>>>> >>>>> I am not that fluent in Qualcomm naming, so let me ask - what are the >>>>> differences between QDU and QRU? >>>>> >>>>> For compatible (and/or similar) devices the general recommendation is to >>>>> have specific compatibles followed by fallback. Even if devices are >>>>> very, very, very similar, usually the recommendation still stays. >>>> Well, true. But in some cases we handle this by using a single set of >>>> compatibles. Consider e.g. sa8155 vs sm8150 (sa8155 overrides just few >>>> compats that differ). Or qrb5165 vs sm8250 (there is no separate >>>> qrb5165.dtsi). APQ8096 (#include "msm8996.dtsi"). Etc. >>>> >>>> I'd say this really depends on the actual difference between qru and qdu. >>> >>> To add some clarification, there's pretty little functional difference between the QDU (Distributed Unit) and the QRU (Radio Unit); they're largely the same SoC from the kernel's standpoint. I wasn't sure if it made more sense to separate the compat strings or mash them together (using qdru to specify that it applies to both), so I kept separate compat strings in case there was a separate RU/DU use case down the line and also to avoid some confusion (I guess that didn't work though). It makes the most sense in my mind to just use the qdru compat string for the things that apply to both SoCs (which is most of what's submitted currently) and then we can do qdu/qru specific override strings for more specific drivers. >> >> Unless Krzysztof or Bjorn have other opinion, I'd suggest adding a >> single compat string, It might be qcom,qdru1000-foo or just >> qcom,qdu1000-foo (with having a separate qcom,qru1000-foo where >> applicable). But the final decision is from Rob, Krzysztof and Bjorn. > > If qdru1000 is a real SoC name, then it is fine. But it seems it is > rather a wildcard, which in general is discouraged. Go with qdu1000 and > optionally prepended with qru1000. qdru1000 is not a real SOC, so let's not use that. Prefer to use qdu1000 and qru1000 with whatever approach we decide. ---Trilok Soni