Re: [PATCH v2 10/15] dt-bindings: clock: qcom: Add Kuno Global Clock Controller
Krzysztof Kozlowski <[email protected]>
| Newsgroups | org.kernel.vger.linux-pm,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-clk,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-gpio,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On 17/08/2026 09:54, Hardeep Sharma wrote: > > On 8/17/2026 1:00 PM, Krzysztof Kozlowski wrote: >> On Fri, Aug 14, 2026 at 01:01:41PM +0530, Hardeep Sharma wrote: >>> Document the Global Clock Controller (GCC) binding and associated >>> clock/reset IDs for the Qualcomm Kuno SoC. >>> >>> Signed-off-by: Hardeep Sharma <[email protected]> >> I do not see how you addressed my comments. I should not be needing to >> verify if each one is implemented and then say again the same. >> >> Best regards, >> Krzysztof > > Hi Krzysztof, > > Apologies — my v1 reply just said "done in v2" without detailing each > point. Both your comments are addressed in v2 patch 10: > > 1) Commit-message / binding style consistency: > Reworded to the same form used across the series: > "Document the Global Clock Controller (GCC) binding and associated > clock/reset IDs for the Qualcomm Kuno SoC." > > 2) "Not a power domain provider?": > Correct — Kuno GCC has no GDSCs and takes no corner votes. I removed > the power-domains block from the schema entirely, and dropped the > matching power-domains = <&rpmhpd RPMHPD_CX> and > #include <dt-bindings/power/qcom,rpmhpd.h> from the example. > (binding 56 -> 50 lines) So if it is not a power domain, then why it is now being made a power domain (through qcom,gcc.yaml)? You need to disallow properties which are not correct for your device. Look at other bindings for clock controllers not being power domain providers. Best regards, Krzysztof