Received: by 2002:a05:7412:b10a:b0:f3:1519:9f41 with SMTP id az10csp993533rdb; Fri, 1 Dec 2023 04:31:30 -0800 (PST) X-Google-Smtp-Source: AGHT+IEPolAtrWpCrkn+N0sP5/SaQEJh9M0H8heJaKXkuG4TmPhN4KXRg32JdlEffgwNwHIkQgmL X-Received: by 2002:a05:6a20:231c:b0:18a:181b:146b with SMTP id n28-20020a056a20231c00b0018a181b146bmr20591449pzc.29.1701433890053; Fri, 01 Dec 2023 04:31:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1701433890; cv=none; d=google.com; s=arc-20160816; b=zNTnNUt5OTSbD2BchndYnMYn4wWGk0xnqAlRS4hNj8H53o6V0zXmal8N9rOiBiAgVD yg3gfZIDsKkxdU2LurxbQCX0qp3puVmAhufOubioTogVyofpXrPcdV8VBy6PVLl35fUl M31H9PAL74NyjMTITbvUwnjtSSR7l7hD+eGU4z0VcYbexGfu0HXEyCziSJuLVV9ZEBgc xcSWTeqIBXQ/n1qyf/DrM7vH/2KC5TnJWqBUOuNdWCnRmk6GUDAO3NjhjdvAubjh0XyU Q2jRP26nmaWsYhuC3hIJ4kIONoIwlfNXPFEGMgw0p+/wTNBgCWLQ1w1zwo/8qxgh9Bv3 iUyQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=q7hh6CC3wSteFKObO5YP2ueHTB4l8VhYUaj/87rIPRc=; fh=2OSYmJnZPyncO43zGFdDNcHnWR8Z+qlglMNUkfIM8EM=; b=Pyc88G43kSBxD1BY8xh2FtyJ6/zTVN5WwTPWjZRmqq3FQhWQuJmtqev7q+cCmeiuCL KGOrwdIhyaGiTOtWWRV/Zsmu+0AYyH0PQy8odGSFzHCRpfPcq92Q0kROcmtjgxSBMIpP cE/bkb3l+xQyPHM7kfKF6z7/bDr00LCglhMpT9cZd+M58Qry/AlAiAAqgbEcEbdeUa8z lsxfdcbDIJdpiWNGp0sgDkmFAvrfFo4rnhRfzyAufzdPU77oP7mfvsHL6p8LMcym9d6g LhiURosdbLiflq89raC3O61dbQ9jtAFMnHLTUyr7q1eAPAPjhGaVHZVe3kw+52k9vmlz xxrQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=AX6CDuhe; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from groat.vger.email (groat.vger.email. [2620:137:e000::3:5]) by mx.google.com with ESMTPS id k29-20020a63561d000000b005c24211ca87si3022450pgb.243.2023.12.01.04.31.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Dec 2023 04:31:30 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=AX6CDuhe; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id 6A715825EDA9; Fri, 1 Dec 2023 04:31:19 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1378829AbjLAMbD (ORCPT + 99 others); Fri, 1 Dec 2023 07:31:03 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51426 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1378804AbjLAMbC (ORCPT ); Fri, 1 Dec 2023 07:31:02 -0500 Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1C9371A4 for ; Fri, 1 Dec 2023 04:31:08 -0800 (PST) Received: by mail-qk1-x734.google.com with SMTP id af79cd13be357-77dd07e7d39so118910085a.0 for ; Fri, 01 Dec 2023 04:31:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1701433867; x=1702038667; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=q7hh6CC3wSteFKObO5YP2ueHTB4l8VhYUaj/87rIPRc=; b=AX6CDuheZWCA1sUZCi56gn2vHvY+1vGPfAZ6jyuZSeg3SYyjWjRMsk1psFNPOkxVL7 GWF3hWcy/YHLPbb7ShV4P+pduNh2lMA36MvxXnAnuLlYNCvfv+7lb1p/5yh0y2muC9S+ UzZC4C+6/npD34iqyVXiNBPmq7T/Gyg4yDTK/M7NXHq9O0MvTC9FMkYYTPFAI7M+PCcj EWgiVeOsuHx68/m4KPKrD1j+Gl770X+NEUpMmPwuRhxzeXGFdhvPTDxQ+MbuJuYkFFUf C91rqfnOkYNX/YyMM6wyyJRHxUC2DpqNU+Lq0kfYY03bilE1pLCP3CyI19JIvQsVutTR hRLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701433867; x=1702038667; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=q7hh6CC3wSteFKObO5YP2ueHTB4l8VhYUaj/87rIPRc=; b=ni1O5ld6nhubmTF+JRK0fkeVSE8uMFDPbopWxPPTf6rzVWLhjyT4imWpd5c0SuyWjK YPfgInjz1su8LmZPS21vwMDoDMWGHQQS1T//cMDxpWGWPkb05ZwEwSjNPRl6enVvnJ4U Jh9aDcXQSGn68NI89FjDBHsaOJcxaI13uI+sGXmBbo1OzgyqnkJh5WLV3GlonTeRQuQU xZWnASBEkakREzlIOP/RmJyc5nOtrYPuTIdpxas5/sGGu2KyC1+ylrzI2fc/tXQVwhZE o7h9hYRqLEb92NNF4aesxXQP7RH74iynLVGB9IfM44DMf00pjcHCKEwZ5SjEDV5R0Wkd Ai/w== X-Gm-Message-State: AOJu0Yye06dAXQCS433vHRLnEt90PDySzVj+0+B7sYzgjvkKP+C1ULDK 7yaATTfl3+RkB5TdiczRXsCA X-Received: by 2002:a05:620a:698e:b0:77b:aa20:908 with SMTP id ua14-20020a05620a698e00b0077baa200908mr23876438qkn.37.1701433867158; Fri, 01 Dec 2023 04:31:07 -0800 (PST) Received: from thinkpad ([117.213.102.92]) by smtp.gmail.com with ESMTPSA id qx3-20020a05620a8b8300b0077da68b8801sm1445020qkn.65.2023.12.01.04.30.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Dec 2023 04:31:06 -0800 (PST) Date: Fri, 1 Dec 2023 18:00:54 +0530 From: Manivannan Sadhasivam To: Krzysztof Kozlowski Cc: Krishna Chaitanya Chundru , Andy Gross , Bjorn Andersson , Konrad Dybcio , Vinod Koul , Kishon Vijay Abraham I , Rob Herring , Krzysztof Kozlowski , Conor Dooley , linux-arm-msm@vger.kernel.org, linux-phy@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, quic_vbadigan@quicinc.com, quic_ramkri@quicinc.com, quic_nitegupt@quicinc.com, quic_skananth@quicinc.com, quic_vpernami@quicinc.com, quic_parass@quicinc.com Subject: Re: [PATCH v3 1/3] dt-bindings: phy: qcom,qmp: Add PCIe qcom,refclk-always-on property Message-ID: <20231201123054.GM4009@thinkpad> References: <20231127-refclk_always_on-v3-0-26d969fa8f1d@quicinc.com> <20231127-refclk_always_on-v3-1-26d969fa8f1d@quicinc.com> <78815f1b-7390-40de-8afd-ac71806f4051@linaro.org> <24fae40a-453b-b14c-923f-88758a246aa7@quicinc.com> <20231201060716.GJ4009@thinkpad> <166d307e-7d1b-48b5-90db-9b6df01d87c2@linaro.org> <20231201111033.GL4009@thinkpad> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Fri, 01 Dec 2023 04:31:19 -0800 (PST) On Fri, Dec 01, 2023 at 01:10:48PM +0100, Krzysztof Kozlowski wrote: > On 01/12/2023 12:10, Manivannan Sadhasivam wrote: > > On Fri, Dec 01, 2023 at 09:01:43AM +0100, Krzysztof Kozlowski wrote: > >> On 01/12/2023 07:07, Manivannan Sadhasivam wrote: > >>> On Tue, Nov 28, 2023 at 02:49:18PM +0530, Krishna Chaitanya Chundru wrote: > >>>> > >>>> On 11/28/2023 2:26 PM, Krzysztof Kozlowski wrote: > >>>>> On 27/11/2023 13:13, Krishna chaitanya chundru wrote: > >>>>>> Document qcom,refclk-always-on property which is needed in some platforms > >>>>>> to supply refclk even in PCIe low power states. > >>>>>> > >>>>>> Signed-off-by: Krishna chaitanya chundru > >>>>>> --- > >>>>>> .../devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml | 7 +++++++ > >>>>>> 1 file changed, 7 insertions(+) > >>>>>> > >>>>>> diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml > >>>>>> index 2c3d6553a7ba..c747c9f35795 100644 > >>>>>> --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml > >>>>>> +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml > >>>>>> @@ -93,6 +93,13 @@ properties: > >>>>>> "#phy-cells": > >>>>>> const: 0 > >>>>>> + qcom,refclk-always-on: > >>>>>> + type: boolean > >>>>>> + description: In some platform where PCIe switch is connected, pcie switch due to some design > >>>>> You received a comment to use proper wrapping: 80. Please implement it. > >>>> I will update this. > >>>>>> + limitation fails to propage clkreq signal to the host and due to that host will not send > >>>>>> + refclk, which results in linkdown in L1.2 or L1.1 exit initiated by EP. > >>>>>> + This property if set keeps refclk always on even in Low power states. > >>>>> The property name suggests that's the state of hardware - refclk is > >>>>> always on. Description suggests you want to instruct OS to do something. > >>>>> > >>>>> Again, third time (once from Bjorn, once from Dmitry), rephrase property > >>>>> name and description to describe the hardware issue. I see description > >>>>> improved, but not the property name. Again in the end of description you > >>>> > >>>> Both bjorn and Dmitry gave comments to change the description only, and not > >>>> the property name, > >>>> > >>>> correct if I am wrong. > >>>> > >>>>> say what Linux should do. Bindings do not describe Linux OS. > >>>> > >>>> I will remove the last line in the next patch. > >>>> > >>> > >>> You should name the property as, "qcom,keep-refclk-always-on" > >> > >> Keep the clock by who? By driver? Then not, property should describe > >> physical phenomena or hardware issue being fixed here, not what driver > >> should do. > >> > > > > This property indeed fixes the hardware issue (though in board level) and I see > > a plenty of properties similar to this one instructing the OS to keep some > > resource ON to workaround hardware issues. So they are all wrong? > > What I said before: > "Again, third time (once from Bjorn, once from Dmitry), rephrase > property name and description to describe the hardware issue. I see > description improved, but not the property name. Again in the end of > description you say what Linux should do. Bindings do not describe Linux > OS." > You didn't answer my question: "I see a plenty of properties similar to this one instructing the OS to keep some resource ON to workaround hardware issues. So they are all wrong?" If you say they are wrong, why are they approved in the first place? - Mani > > Best regards, > Krzysztof > -- மணிவண்ணன் சதாசிவம்