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: <78445973-6a5e-4dd8-a661-4e784af49b4e@kernel.org>
Date: Sat, 18 Oct 2025 17:39:43 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Wesley Cheng <wesley.cheng@....qualcomm.com>, krzk+dt@...nel.org,
 conor+dt@...nel.org, konrad.dybcio@....qualcomm.com,
 dmitry.baryshkov@....qualcomm.com, kishon@...nel.org, vkoul@...nel.org,
 gregkh@...uxfoundation.org, robh@...nel.org
Cc: linux-arm-msm@...r.kernel.org, linux-phy@...ts.infradead.org,
 linux-usb@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 02/10] dt-bindings: phy: qcom,qmp-usb: Add Glymur USB
 UNI PHY compatible

On 18/10/2025 02:20, Wesley Cheng wrote:
> 
> 
> On 10/16/2025 9:41 PM, Krzysztof Kozlowski wrote:
>> On 17/10/2025 02:15, Wesley Cheng wrote:
>>>>> Technically its all handling the same clock branch (CXO), we have the
>>>>> TCSR clkref register that allows us to gate the CXO to the USB PHY, as
>>>>
>>>>
>>>> Ah, exactly. Then clkref is not a clock. You need rather proper clock
>>>> hierarchy.
>>>>
>>>>> CXO is shared across several HW blocks, so it allows us to properly
>>>>> powerdown the PHY even though other clients are voting for CXO on.  Then
>>>>> we obviously have to remove our vote to the overall CXO, so that it can
>>>>> potentially be shutdown.
>>>>>
>>>>> Maybe we can rename it to "clkref" for the CXO handle and
>>>>> "clkref_switch" for the TCSRCC handle?
>>>>
>>>> Naming is better, but it is still not correct. This is not independent
>>>> clock signal. It is the same clock.
>>>>
>>>
>>> Hmmm... I guess that's why I kept the same clkref tag, to denote that
>>> its the same clock, but one is a switch/gate for it.  Would you happen
>>> to have any suggestions you might have that makes it clearer for
>>> everyone to understand?
>> To me it looks like:
>>
>> |-----|            |-----------|           |------------------|
>> |clock|------------|TCSRCC gate|-----------|clkref to this dev|
>> |-----|            |-----------|           |------------------|
>>
>> So you need proper clock controller for TCSR (TCSR Clock Controller, in
>> short TCSRCC, what a surprise!) which will take input, add gate and
>> produce clock for this device.
>>
>> Nothing non-standard, all Qualcomm SoCs have it, every other platform
>> has it in some way.
>>
> 
> Hi Krzystof,
> 
> Yes, the design is exactly how you outlined it above.  How about clkref 

Hm? There is no connection between the clock and the device. Do you see
any line going there?

> for the clock and tcsrcc_switch for the clkref switch?  That removes any 
> notation that the gate/switch is an actual clock...

You really did not get the point of this entire discussion.


Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ