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 for Android: free password hash cracker in your pocket

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

Message-ID: <3e8128f4-3cba-4c13-a846-e5f1638a1e0f@kernel.org>
Date: Wed, 17 Dec 2025 14:54:57 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
 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 17/12/2025 14:21, Konrad Dybcio wrote:
> On 12/17/25 11:09 AM, Krzysztof Kozlowski wrote:
>> On 17/12/2025 10:32, Taniya Das wrote:
>>>>>
>>>>> 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.
>>>>
>>>
>>> As it is still a clock controller from hardware design and in SW I will
>>> be map the entire hardware region and this way this clock controller
>>> will also be aligned to the existing clock controllers and keep the
>>> #power-domain-cells = <1> as other CCs.
>>
>> I don't see how this resolves my comment.
> 
> Spanning the entire 0x6000-long block will remove your worry about this
> description only being 2-register-wide

But that was not the comment here. Taniya replied under comment about
cells. We are not discussing here some other things...

Best regards,
Krzysztof