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

Message-ID: <27a1ba7c-6e72-4c86-8eed-bff9ab6f0c0c@oss.qualcomm.com>
Date: Thu, 30 Oct 2025 22:40:15 +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/30/2025 4:39 PM, Dmitry Baryshkov wrote:
> On Thu, 30 Oct 2025 at 12:44, Taniya Das <taniya.das@....qualcomm.com> wrote:
>>
>>
>>
>> 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.
> 
> You are writing a driver for the platform, not a generic driver for
> all the platforms.
> 

I will map the logical subblock and will update the offsets in the
TCSRCC driver.

>>
>>>>
>>>> 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
>>
> 
> 

-- 
Thanks,
Taniya Das