[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZXGVjY9gYMD6-xFJ@hovoldconsulting.com>
Date: Thu, 7 Dec 2023 10:51:09 +0100
From: Johan Hovold <johan@...nel.org>
To: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
Krishna Chaitanya Chundru <quic_krichai@...cinc.com>,
Andy Gross <agross@...nel.org>,
Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konrad.dybcio@...aro.org>,
Vinod Koul <vkoul@...nel.org>,
Kishon Vijay Abraham I <kishon@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>,
linux-arm-msm@...r.kernel.org, linux-phy@...ts.infradead.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
quic_vbadigan@...cinc.com, quic_ramkri@...cinc.com,
quic_nitegupt@...cinc.com, quic_skananth@...cinc.com,
quic_vpernami@...cinc.com, quic_parass@...cinc.com
Subject: Re: [PATCH v3 1/3] dt-bindings: phy: qcom,qmp: Add PCIe
qcom,refclk-always-on property
On Wed, Dec 06, 2023 at 06:40:09PM +0530, Manivannan Sadhasivam wrote:
> OK. How about, "qcom,broken-refclk"? This reflects the fact that the default
> refclk operation is broken on this platform, so the OS should be prepared for
> it (by keeping it always on).
Shouldn't that be
qcom,broken-clkreq
since its the CLKREQ# signal used to request REFCLK that is broken, not
the REFCLK itself?
Johan
Powered by blists - more mailing lists