linux-kernel - Re: [PATCH 03/24] arm64: dts: qcom: Introduce Glymur base dtsi and CRD dts

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: <a52ff3b6-c5f3-48a8-a8d7-812026b0d87e@oss.qualcomm.com>
Date: Thu, 30 Oct 2025 16:14:43 +0530
From: Taniya Das <taniya.das@....qualcomm.com>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
        Pankaj Patil <pankaj.patil@....qualcomm.com>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konradybcio@...nel.org>, Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley
 <conor+dt@...nel.org>, linux-arm-msm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 03/24] arm64: dts: qcom: Introduce Glymur base dtsi and
 CRD dts



On 10/29/2025 4:06 PM, Dmitry Baryshkov wrote:
> On Wed, Oct 29, 2025 at 03:30:54PM +0530, Taniya Das wrote:
>>
>>
>> On 9/25/2025 3:46 PM, Konrad Dybcio wrote:
>>>> +		tcsrcc: clock-controller@...5044 {
>>>> +			compatible = "qcom,glymur-tcsr";
>>>> +			reg = <0x0 0x1fd5044 0x0 0x48>;
>>> We can map 0x1fd5000 - 0x1fd5094 inclusive, as that seems like a
>>> logical subblock (this would require adjusting the driver)
>>>
>>
>> Konrad, we encountered issues when trying to map regions beyond just the
>> clock reference registers. Normally, we map the entire address range of
>> a clock controller (CC) module in the device tree. However, for TCSRCC
>> where CLKREF_EN registers are located within shared modules like TCSR or
>> TLMM—we don't own the whole address space, and mapping the full range
>> can overlap with other devices.
>> To avoid this, we propose defining the base address as the first
>> register actually used, and the size to only include up to the last
>> register we use. This ensures we only map the relevant subblock,
>> preventing conflicts with other device nodes.
> 
> Then you need to behave slightly differently: map the full range at the
> basic device (TLMM, TCSR, etc.) and then create TCSRCC as a child device
> to that node (and use paren't regmap to access the registers).
> 

Dmitry, I agree that this approach is ideal. However, the current
hardware implementation isn’t consistent across multiple SoCs, which
means the driver design also needs to adapt. Given these differences, we
decided to strictly map only the range of hardware registers that are
actually used for clocks, rather than the entire module.

>>
>> So want to keep the mapping same from the start of clockref clocks.
>>
>>> There's also a laaaarge pool of various TCSR_ registers between
>>> the previous node and this one.. but we can leave that in case we
>>> need to describe it in a specific way some day
>>>> +			#clock-cells = <1>;
>>>> +			#reset-cells = <1>;
>>>> +		};
>>>> +
>>
>> -- 
>> Thanks,
>> Taniya Das
>>
> 

-- 
Thanks,
Taniya Das