Message ID | 1686138469-1464-5-git-send-email-quic_rohiagar@quicinc.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:6358:3046:b0:115:7a1d:dabb with SMTP id p6csp300231rwl; Wed, 7 Jun 2023 05:06:04 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7bRpF9WbAYV3UGLj6TWPAjYn0WG5VHJrtBCSrkh/SiAaCO+pWcR2T00I6xnKi+FbtPxkgB X-Received: by 2002:a17:90b:3b41:b0:250:9e7b:2798 with SMTP id ot1-20020a17090b3b4100b002509e7b2798mr4667219pjb.18.1686139564327; Wed, 07 Jun 2023 05:06:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686139564; cv=none; d=google.com; s=arc-20160816; b=q6yDdGMuFiOlkjQrSMGBlQ4/ZOR3MQcviWBGY1m3+jy0ada5Hk+qCSInN3XNwRh8AD +0da2QIbIZfvasuMJYPXiaqyfCgoyT3Rg+ZLBXIRmJMaRUTV6W3ZHEpAEgES/D9TJ8z1 960Am/Y/WHIt5GbGoQxUpb1ZWaQzarUQVnWx1E0kVrR33WwhJYy7sTEmMCM7sOYBKnfy 808PXC5FckA36RpdPHeQYcOHMgX51qcLNR+/HlPmEXSoZjQJEk0BEEH1ZnrHB4ucRUdx amAfttvpN/8pI6+tsfZjYSihq0Kn4GQlyv85UcNDHrTwvJtymx5Ylq2uVhn7BFxptHFo Hu/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:references:in-reply-to:message-id:date:subject :cc:to:from:dkim-signature; bh=/5pJzyTqpOJmg5KAJrq8HMK+4xf3ymTQkZtUqxiq0yA=; b=baYWGih9j/3RoACCzYkS+I0E5U9ILsp7lDf1ChU8nTpT4ITkmHA69yrQdRMJ6M+hKY 7iYnkf4t3rT1CqSaDheM8Y0el/RHu6tjV6RcMoahXUKkR6fdHoILldkzM7atRU+ZDw2o cL8MKq6ZXdkNRx16tHSpauJ4QRZrqpgW/kCgm4MmPk0xwVZDTM8n5w4YSBjwD/ZQmuz+ 1Hyp8uaxVF+E6W2/VawbZIJuozn25Y9Eduz3IW7nt8kBjar53dPIWtYYfbYy0ouOr8xA ermQxDFDbfd7m6dTaA9MNleLFTdi3U9ukgZ7ViA4LamDUFXxDKr0stDQ9K5kDsaJ65Il xQeg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=LrBQCzwa; 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 rm10-20020a17090b3eca00b0025672fbdad5si977019pjb.178.2023.06.07.05.05.50; Wed, 07 Jun 2023 05:06:04 -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=LrBQCzwa; 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 S240407AbjFGLsH (ORCPT <rfc822;literming00@gmail.com> + 99 others); Wed, 7 Jun 2023 07:48:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41132 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235252AbjFGLsF (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 7 Jun 2023 07:48:05 -0400 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E5A2519D; Wed, 7 Jun 2023 04:48:03 -0700 (PDT) Received: from pps.filterd (m0279871.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 357BUOi0002222; Wed, 7 Jun 2023 11:47:55 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; s=qcppdkim1; bh=/5pJzyTqpOJmg5KAJrq8HMK+4xf3ymTQkZtUqxiq0yA=; b=LrBQCzwaCnBc3r66O+9VmZ63nJxR3KGxnkaXs9EvFCBi22zYjRYR3cEv59sVgYkV08+c MsAtbpSmyaTBr2IaHk6dKpDcjRzeidxR9sa/xMu9nJ5OEXEuceBORzflH9rguXYlqvaJ Dx/d2QKw0rd3l32+up9GTglsWg31sOQ0/kz2lHhKj8GkWItaENahjmQu7InMGioRMm42 UP1CeWT0HF6xZDrnUd98BQMpja/WKfVWdwn15wlzlwAFDqAaZ3nmI+12QpAzsrgjvnO4 g/ICFST8dfa/P1R6bfNBZdEqODPEAuRslth25t5fq2N67Kr6n+aKgOHe3tcSMQmfzP+g WA== Received: from apblrppmta01.qualcomm.com (blr-bdr-fw-01_GlobalNAT_AllZones-Outside.qualcomm.com [103.229.18.19]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3r2a9u9ps4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 07 Jun 2023 11:47:55 +0000 Received: from pps.filterd (APBLRPPMTA01.qualcomm.com [127.0.0.1]) by APBLRPPMTA01.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTP id 357Blqip030939; Wed, 7 Jun 2023 11:47:52 GMT Received: from pps.reinject (localhost [127.0.0.1]) by APBLRPPMTA01.qualcomm.com (PPS) with ESMTP id 3qyxkm28ps-1; Wed, 07 Jun 2023 11:47:52 +0000 Received: from APBLRPPMTA01.qualcomm.com (APBLRPPMTA01.qualcomm.com [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 357BlqZr030931; Wed, 7 Jun 2023 11:47:52 GMT Received: from hu-sgudaval-hyd.qualcomm.com (hu-rohiagar-hyd.qualcomm.com [10.213.106.138]) by APBLRPPMTA01.qualcomm.com (PPS) with ESMTP id 357BlqFi030923; Wed, 07 Jun 2023 11:47:52 +0000 Received: by hu-sgudaval-hyd.qualcomm.com (Postfix, from userid 3970568) id BAC9A5F24; Wed, 7 Jun 2023 17:17:51 +0530 (+0530) From: Rohit Agarwal <quic_rohiagar@quicinc.com> To: agross@kernel.org, andersson@kernel.org, konrad.dybcio@linaro.org, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org, rafael@kernel.org, viresh.kumar@linaro.org, tglx@linutronix.de, maz@kernel.org, mani@kernel.org, robimarko@gmail.com Cc: linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, Rohit Agarwal <quic_rohiagar@quicinc.com> Subject: [PATCH v3 4/5] dt-bindings: cpufreq: cpufreq-qcom-hw: Add SDX75 compatible Date: Wed, 7 Jun 2023 17:17:48 +0530 Message-Id: <1686138469-1464-5-git-send-email-quic_rohiagar@quicinc.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1686138469-1464-1-git-send-email-quic_rohiagar@quicinc.com> References: <1686138469-1464-1-git-send-email-quic_rohiagar@quicinc.com> X-QCInternal: smtphost X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-ORIG-GUID: eYgajBSRQixFgFvGMGi0-rpAAShQcT3U X-Proofpoint-GUID: eYgajBSRQixFgFvGMGi0-rpAAShQcT3U X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.957,Hydra:6.0.573,FMLib:17.11.176.26 definitions=2023-06-07_06,2023-06-07_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 suspectscore=0 impostorscore=0 adultscore=0 clxscore=1015 bulkscore=0 priorityscore=1501 phishscore=0 mlxscore=0 mlxlogscore=870 spamscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2305260000 definitions=main-2306070097 X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,SPF_HELO_NONE, SPF_NONE,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=no 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?1768045479643832667?= X-GMAIL-MSGID: =?utf-8?q?1768045479643832667?= |
Series |
Add devicetree support for SDX75 Modem and IDP
|
|
Commit Message
Rohit Agarwal
June 7, 2023, 11:47 a.m. UTC
Add compatible for EPSS CPUFREQ-HW on SDX75. Signed-off-by: Rohit Agarwal <quic_rohiagar@quicinc.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> --- Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml | 1 + 1 file changed, 1 insertion(+)
Comments
On 07/06/2023 13:47, Rohit Agarwal wrote: > Add compatible for EPSS CPUFREQ-HW on SDX75. > > Signed-off-by: Rohit Agarwal <quic_rohiagar@quicinc.com> > Acked-by: Viresh Kumar <viresh.kumar@linaro.org> > --- This is a friendly reminder during the review process. It looks like you received a tag and forgot to add it. If you do not know the process, here is a short explanation: Please add Acked-by/Reviewed-by/Tested-by tags when posting new versions. However, there's no need to repost patches *only* to add the tags. The upstream maintainer will do that for acks received on the version they apply. https://elixir.bootlin.com/linux/v5.17/source/Documentation/process/submitting-patches.rst#L540 If a tag was not added on purpose, please state why and what changed. Best regards, Krzysztof
On Wed, Jun 07, 2023 at 05:17:48PM +0530, Rohit Agarwal wrote: > Add compatible for EPSS CPUFREQ-HW on SDX75. > > Signed-off-by: Rohit Agarwal <quic_rohiagar@quicinc.com> > Acked-by: Viresh Kumar <viresh.kumar@linaro.org> > --- > Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml > index a6b3bb8..866ed2d 100644 > --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml > +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml > @@ -36,6 +36,7 @@ properties: > - qcom,sa8775p-cpufreq-epss > - qcom,sc7280-cpufreq-epss > - qcom,sc8280xp-cpufreq-epss > + - qcom,sdx75-cpufreq-epss > - qcom,sm6375-cpufreq-epss > - qcom,sm8250-cpufreq-epss > - qcom,sm8350-cpufreq-epss This is a very basic question, not completely related to this patch. Apologies in advance. What is the rationale for adding a new soc string under compatible and using it in the new soc device tree? Is it meant for documentation purpose? i.e one know what all SoCs / boards supported by this device node. I ask this because, we don't add these compatible strings in the driver [1] which means there is not SoC specific handling and there is no module load assist (module alias matching by user space based on device presence). Thanks, Pavan
On 9.06.2023 07:00, Pavan Kondeti wrote: > On Wed, Jun 07, 2023 at 05:17:48PM +0530, Rohit Agarwal wrote: >> Add compatible for EPSS CPUFREQ-HW on SDX75. >> >> Signed-off-by: Rohit Agarwal <quic_rohiagar@quicinc.com> >> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> >> --- >> Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml >> index a6b3bb8..866ed2d 100644 >> --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml >> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml >> @@ -36,6 +36,7 @@ properties: >> - qcom,sa8775p-cpufreq-epss >> - qcom,sc7280-cpufreq-epss >> - qcom,sc8280xp-cpufreq-epss >> + - qcom,sdx75-cpufreq-epss >> - qcom,sm6375-cpufreq-epss >> - qcom,sm8250-cpufreq-epss >> - qcom,sm8350-cpufreq-epss > > This is a very basic question, not completely related to this patch. > Apologies in advance. > > What is the rationale for adding a new soc string under compatible and > using it in the new soc device tree? Is it meant for documentation purpose? > i.e one know what all SoCs / boards supported by this device node. It's two-fold: 1. The device tree describes the hardware, and for lack of better terms (e.g. an SoC-specific version number of the block that is identical to all other implementations of that revision on all SoCs that use it), we tend to associate it with the SoC it's been (first) found on. 2. In case we ever needed to introduce a SoC-specific quirk, we can just add an of_is_compatible-sorta check to the driver and not have to update the device trees. This is very important for keeping backwards compatibility, as it's assumed that not everybody may be running the latest one. This means we have to avoid ABI breaks (unless we have *very* good reasons, like "this would have never worked anyway" or "it was not described properly and worked on this occasion by pure luck") Konrad > > I ask this because, we don't add these compatible strings in the driver > [1] which means there is not SoC specific handling and there is no > module load assist (module alias matching by user space based on device > presence). > > Thanks, > Pavan
On Fri, Jun 09, 2023 at 11:17:08AM +0200, Konrad Dybcio wrote: > > > On 9.06.2023 07:00, Pavan Kondeti wrote: > > On Wed, Jun 07, 2023 at 05:17:48PM +0530, Rohit Agarwal wrote: > >> Add compatible for EPSS CPUFREQ-HW on SDX75. > >> > >> Signed-off-by: Rohit Agarwal <quic_rohiagar@quicinc.com> > >> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> > >> --- > >> Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml | 1 + > >> 1 file changed, 1 insertion(+) > >> > >> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml > >> index a6b3bb8..866ed2d 100644 > >> --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml > >> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml > >> @@ -36,6 +36,7 @@ properties: > >> - qcom,sa8775p-cpufreq-epss > >> - qcom,sc7280-cpufreq-epss > >> - qcom,sc8280xp-cpufreq-epss > >> + - qcom,sdx75-cpufreq-epss > >> - qcom,sm6375-cpufreq-epss > >> - qcom,sm8250-cpufreq-epss > >> - qcom,sm8350-cpufreq-epss > > > > This is a very basic question, not completely related to this patch. > > Apologies in advance. > > > > What is the rationale for adding a new soc string under compatible and > > using it in the new soc device tree? Is it meant for documentation purpose? > > i.e one know what all SoCs / boards supported by this device node. > It's two-fold: > > 1. The device tree describes the hardware, and for lack of better terms (e.g. > an SoC-specific version number of the block that is identical to all other > implementations of that revision on all SoCs that use it), we tend to > associate it with the SoC it's been (first) found on. > > 2. In case we ever needed to introduce a SoC-specific quirk, we can just add > an of_is_compatible-sorta check to the driver and not have to update the > device trees. This is very important for keeping backwards compatibility, > as it's assumed that not everybody may be running the latest one. This > means we have to avoid ABI breaks (unless we have *very* good reasons, like > "this would have never worked anyway" or "it was not described properly > and worked on this occasion by pure luck") > Thanks Konrad for the explanation. The #2 is a clear winner here. It makes complete sense. In devices like USB, we have PID/VID through which quirks can be implemented later. So I guess the same analogy applies here. Like you said in (1), the devices are identified with SoC compatible string. Thanks, Pavan
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml index a6b3bb8..866ed2d 100644 --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml @@ -36,6 +36,7 @@ properties: - qcom,sa8775p-cpufreq-epss - qcom,sc7280-cpufreq-epss - qcom,sc8280xp-cpufreq-epss + - qcom,sdx75-cpufreq-epss - qcom,sm6375-cpufreq-epss - qcom,sm8250-cpufreq-epss - qcom,sm8350-cpufreq-epss