linux-kernel - Re: [PATCH 1/3] dt-bindings: interconnect: add clocks property to enable QoS on qcs8300

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] [day] [month] [year] [list]

Message-ID: <07eeceaa-4f0e-4671-9ce9-8368c76e7d63@oss.qualcomm.com>
Date: Sun, 4 Jan 2026 00:12:39 +0530
From: Odelu Kukatla <odelu.kukatla@....qualcomm.com>
To: Krzysztof Kozlowski <krzk@...nel.org>, Georgi Djakov <djakov@...nel.org>,
        Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konradybcio@...nel.org>
Cc: Raviteja Laggyshetty <raviteja.laggyshetty@....qualcomm.com>,
        Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>,
        Bartosz Golaszewski <bartosz.golaszewski@...aro.org>,
        linux-arm-msm@...r.kernel.org, linux-pm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        Mike Tipton <mike.tipton@....qualcomm.com>
Subject: Re: [PATCH 1/3] dt-bindings: interconnect: add clocks property to
 enable QoS on qcs8300



On 12/23/2025 7:15 PM, Krzysztof Kozlowski wrote:
> On 22/12/2025 18:38, Odelu Kukatla wrote:
>>
>>
>> On 11/29/2025 3:03 PM, Krzysztof Kozlowski wrote:
>>> On 28/11/2025 16:01, Odelu Kukatla wrote:
>>>> Add 'clocks' property to enable QoS configuration. This property
>>>> enables the necessary clocks for QoS configuration.
>>>>
>>>> QoS configuration is essential for ensuring that latency sensitive
>>>> components such as CPUs and multimedia engines receive prioritized
>>>> access to memory and interconnect resources. This helps to manage
>>>> bandwidth and latency across subsystems, improving system responsiveness
>>>> and performance in concurrent workloads.
>>>
>>> I don't see how clocks property help here at all. Are you getting clock
>>> rates in the driver of some other clocks to make QoS decisions?
>>>
>>
>> We don't need to get clock rate/frequency, just need to enable the
>> clock(s) for QoS register access for which we need to get the clock
>> handle in driver.
> 
> Not relevant what your driver does. Still getting clock does not improve
> system responsiveness. If you claim otherwise give me an argument or any
> sort of proof that providing clock has impact on system responsiveness.
> 
> IOW, don't feed us marketing. It's waste of our time.
> 
> 

Hi Krzysztof,
Thanks for the feedback.
You are right that the clocks property itself does not improve system
responsiveness. The QoS registers are inside a block whose interface is
clock-gated, so the driver must enable the required clock before
accessing those registers. The clocks property is only there to let the
driver obtain that clock handle and enable the required clock; without
that, the QoS registers are not accessible. The actual QoS behaviour is
determined entirely by the values written to those registers, not by the
presence of the clocks property in DT.

About the “optional” wording: that was incorrect on my side. I will:
1.update the binding so that the `clocks` property accurately reflects
the hardware and does not allow describing non-existing hardware, and
2.drop the “optional” wording and the performance oriented description
from the commit message, keeping it to a minimal statement that the
clock is needed to access the QoS registers.

I’ll send a v2 with these changes.

Best regards,
Odelu

> 
>>
>>>>
>>>> Both 'reg' and 'clocks' properties are optional. If either is missing,
>>>
>>> No! They are not. How they can be optional in the hardware? How SoC can
>>> have for ONE GIVEN device optional reg, meaning one board with the same
>>> Soc has the IO address space but other board with the same SoC does not
>>> have it.
>>>
>>
>> I agree, I will drop the “optional” wording and rework the schema so
> 
> So why were they optional in the first place? What is this patch describing?
> 
> 
> Best regards,
> Krzysztof