linux-kernel - Re: [PATCH 1/3] dt-bindings: interconnect: qcom,qcs615-rpmh: add clocks property to enable QoS

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: <trcbrxphzbgldya5cau42irrsnu7wn5swffjyvm74z7emfcevg@muojwgpa6ln4>
Date: Fri, 6 Feb 2026 08:51:00 +0200
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Odelu Kukatla <odelu.kukatla@....qualcomm.com>
Cc: Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
        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>,
        Raviteja Laggyshetty <raviteja.laggyshetty@....qualcomm.com>,
        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: qcom,qcs615-rpmh: add
 clocks property to enable QoS

On Fri, Feb 06, 2026 at 10:28:15AM +0530, Odelu Kukatla wrote:
> 
> 
> On 2/5/2026 3:59 PM, Dmitry Baryshkov wrote:
> > On Thu, Feb 05, 2026 at 03:10:31PM +0530, Odelu Kukatla wrote:
> >>
> >>
> >> On 2/5/2026 2:31 PM, Konrad Dybcio wrote:
> >>> On 2/5/26 7:06 AM, Odelu Kukatla wrote:
> >>>>
> >>>>
> >>>> On 2/2/2026 4:33 PM, Konrad Dybcio wrote:
> >>>>> On 2/2/26 8:05 AM, Odelu Kukatla wrote:
> >>>>>> Aggre1-noc interconnect node on QCS615 has QoS registers located
> >>>>>> inside a block whose interface is clock-gated. For that node,
> >>>>>> driver must enable the corresponding clock(s) before accessing
> >>>>>> the registers. Add the 'clocks' property so the driver can obtain
> >>>>>> and enable the required clock(s).
> >>>>>>
> >>>>>> Only interconnects that have clock‑gated QoS register interface
> >>>>>> use this property; it is not applicable to all interconnect nodes.
> >>>>>>
> >>>>>> Signed-off-by: Odelu Kukatla <odelu.kukatla@....qualcomm.com>
> >>>>>> ---
> >>>
> >>> [...]
> >>>
> >>>>>> +  - if:
> >>>>>> +      properties:
> >>>>>> +        compatible:
> >>>>>> +          contains:
> >>>>>> +            enum:
> >>>>>> +              - qcom,qcs615-aggre1-noc
> >>>>>> +    then:
> >>>>>> +      properties:
> >>>>>> +        clocks:
> >>>>>> +          items:
> >>>>>> +            - description: aggre UFS PHY AXI clock
> >>>>>> +            - description: aggre USB2 SEC AXI clock
> >>>>>> +            - description: aggre USB3 PRIM AXI clock
> >>>>>
> >>>>> Should we also include the IPA clock here?
> >>>>>
> >>>>
> >>>> Thanks for the review!
> >>>>
> >>>> For QCS615, the IPA clock is already enabled by the bootloader (xBL) and
> >>>> kept on during the boot‑up stage. Because of this, we do not need to
> >>>> explicitly enable the IPA clock in the interconnect driver when
> >>>> accessing the QoS registers.
> >>>
> >>> Would we need to re-enable it to re-program the hardware if say the
> >>> icc module is loaded after unused clk cleanup or after a cx collapse?
> >>>
> >>
> >> IPA clock is not managed by GCC clock controller driver, so
> >> clk_disable_unused does not disable it.
> > 
> > The clk_disable_unused is not limited to the GCC. The clock is managed
> > by the clk-rpmh, so clk_disable_unused applies to it too. 
> > 
> 
> clk_disable_unused()/clk_disable_unused_subtree() does not disable RPMh
> managed clocks, so it does not apply to IPA clock.

You are describing the current behaviour of one OS. The DTS should be
describing the hardware. Other platforms describe IPA clock used by the
aggre NoC nodes.

> 
> >> As a result, the icc provider
> >> does not need to re enable an IPA clock for QoS access after unused clk
> >> cleanup. And QCS615 does *not* support Cx collapse.
> > 
> > Does lack of CX collapse apply to SM6150?
> > 
> 
> SM6150, QCS615, and Talos are all names referring to the same underlying
> SoC family.

Ack, I was making sure that lack of CX collapse isn't related to IoT vs
mobile case.

-- 
With best wishes
Dmitry