linux-kernel - Re: [PATCH v2 07/11] dt-bindings: clock: qcom: document the Kaanapali GPU Clock Controller

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <fbe39eac-7c92-4a08-bafb-31e5c51a0613@kernel.org>
Date: Tue, 16 Dec 2025 09:51:56 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Taniya Das <taniya.das@....qualcomm.com>
Cc: Bjorn Andersson <andersson@...nel.org>,
 Michael Turquette <mturquette@...libre.com>, Stephen Boyd
 <sboyd@...nel.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Neil Armstrong <neil.armstrong@...aro.org>,
 Maxime Coquelin <mcoquelin.stm32@...il.com>,
 Alexandre Torgue <alexandre.torgue@...s.st.com>,
 Vladimir Zapolskiy <vladimir.zapolskiy@...aro.org>,
 Konrad Dybcio <konradybcio@...nel.org>,
 Ajit Pandey <ajit.pandey@....qualcomm.com>,
 Imran Shaik <imran.shaik@....qualcomm.com>,
 Jagadeesh Kona <jagadeesh.kona@....qualcomm.com>,
 linux-arm-msm@...r.kernel.org, linux-clk@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-stm32@...md-mailman.stormreply.com,
 linux-arm-kernel@...ts.infradead.org,
 Jingyi Wang <jingyi.wang@....qualcomm.com>,
 Bryan O'Donoghue <bryan.odonoghue@...aro.org>
Subject: Re: [PATCH v2 07/11] dt-bindings: clock: qcom: document the Kaanapali
 GPU Clock Controller

On 04/12/2025 07:49, Taniya Das wrote:
>>> +  power-domains:
>>> +    description:
>>> +      Power domains required for the clock controller to operate
>>> +    items:
>>> +      - description: GFX power domain
>>> +      - description: GMXC power domain
>>> +      - description: GPUCC(CX) power domain
>>> +
>>> +  '#power-domain-cells':
>>
>> Power domain controllers do not belong to clocks, so this is:
>> 1. Misplaced - wrong folder
>> 2. Probably wrongly named. gxclkctl sounds like clock controller, but
>> this is domain controller?
>>
> 
> The GFXCLKCTL is actually a clock controller which has PLLs, clocks and
> Power domains (GDSC), but the requirement here is to use the GDSC from
> the clock controller to recover the GPU firmware in case of any
> failure/hangs. The rest of the resources of the clock controller are
> being used by the firmware of GPU. The GDSC is a clock controller
> resource and modeled from the clock controller drivers across chipsets.

This should be somewhere explained.

> 
>>> +    const: 1
>>> +
>>> +  reg:
>>> +    maxItems: 1
>>> +
>>> +required:
>>> +  - compatible
>>> +  - reg
>>> +  - power-domains
>>> +  - '#power-domain-cells'
>>> +
>>> +unevaluatedProperties: false
>>> +
>>> +examples:
>>> +  - |
>>> +    #include <dt-bindings/power/qcom,rpmhpd.h>
>>> +    soc {
>>> +        #address-cells = <2>;
>>> +        #size-cells = <2>;
>>> +
>>> +        clock-controller@...8024 {
>>> +            compatible = "qcom,kaanapali-gxclkctl";
>>> +            reg = <0 0x3d68024 0x0 0x8>;
>>
>> Keep consistent hex, so first 0 -> 0x0.
> 
> Sure, will fix this.
> 
>> But the problem is that you defined a device for two registers,
>> basically one domain. I have doubts now whether this is complete and
>> real device.
>>
> 
> As the Linux GPU driver requires only the GDSC, I have mapped the region
> which is required by the clock controller driver. If required, the
> entire region can be mapped as well.

Required is to properly describe the hardware, please read writing
bindings doc.

> 
>>> +            power-domains = <&rpmhpd RPMHPD_GFX>,
>>> +                            <&rpmhpd RPMHPD_GMXC>,
>>> +                            <&gpucc 0>;
>>> +            #power-domain-cells = <1>;
>>
>> And cells 1 makes no sense in such case.
>>
> 
> We would like to leverage the existing common clock driver(GDSC) code to

Fix the driver code if it cannot handle other cells. Your drivers do not
matter for choices made in bindings.

> register the power-domains and also maintain uniformity across chipsets
> and consistency in consumer GDSC phandle usage.

There is no such consistency rule. Don't make up your own rules.

Best regards,
Krzysztof