linux-kernel - Re: [PATCH 4/5] arm64: dts: qcom: r0q: enable hardware clocks

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: <39d07bf1-cead-449f-85c8-4651e5296cd8@oss.qualcomm.com>
Date: Wed, 8 Oct 2025 10:48:53 +0200
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Eric Gonçalves <ghatto404@...il.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>
Cc: devicetree@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/5] arm64: dts: qcom: r0q: enable hardware clocks

On 10/6/25 5:49 PM, Eric Gonçalves wrote:
> 
> 
> On October 6, 2025 9:31:42 AM GMT-03:00, Konrad Dybcio <konrad.dybcio@....qualcomm.com> wrote:
>> On 10/5/25 5:50 AM, Eric Gonçalves wrote:
>>>
>>>
>>> On September 25, 2025 10:09:48 AM GMT-03:00, Konrad Dybcio <konrad.dybcio@....qualcomm.com> wrote:
>>>> On 9/20/25 3:46 AM, Eric Gonçalves wrote:
>>>>> Enable the real-time clocks found in R0Q board.
>>>>>
>>>>> Signed-off-by: Eric Gonçalves <ghatto404@...il.com>
>>>>> ---
>>>>>  arch/arm64/boot/dts/qcom/sm8450-samsung-r0q.dts | 15 +++++++++++++++
>>>>>  1 file changed, 15 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm64/boot/dts/qcom/sm8450-samsung-r0q.dts b/arch/arm64/boot/dts/qcom/sm8450-samsung-r0q.dts
>>>>> index c1b0b21c0ec5..c088f1acf6ea 100644
>>>>> --- a/arch/arm64/boot/dts/qcom/sm8450-samsung-r0q.dts
>>>>> +++ b/arch/arm64/boot/dts/qcom/sm8450-samsung-r0q.dts
>>>>> @@ -225,6 +225,21 @@ vol_up_n: vol-up-n-state {
>>>>>  	};
>>>>>  };
>>>>>  
>>>>> +&pmk8350_rtc {
>>>>> +	nvmem-cells = <&rtc_offset>;
>>>>> +	nvmem-cell-names = "offset";
>>>>> +
>>>>> +	status = "okay";
>>>>> +};
>>>>> +
>>>>> +&pmk8350_sdam_2 {
>>>>> +	status = "okay";
>>>>> +
>>>>> +	rtc_offset: rtc-offset@bc {
>>>>
>>>> Is this an offset you took from somewhere downstream?
>>>>
>>>> Generally you *really don't want to* poke at random SDAM cells,
>>>> as they contain a lot of important settings (incl. battery/charging)
>>> From another sm8450 device, I'm sure it's okay.
>>
>> That as an argument alone doesn't sound convincing to me, since vendors
>> also sometimes repurpose unused-by-Qualcomm SDAM cells
>>
>> I actually found a data source internally and this cell you're trying
>> to use is reserved for PBS (see drivers/soc/qcom/qcom-pbs.c), meaning
>> you already fell into this trap..
> Interesting, in this case then why does rtc still work? And
> how can I find the real cell? It's not in downstream DT.

Well if nothing accesses that cell between your last write and your first
read, it will of course work, because SDAM is just a means of storage

As for downstream/Android, it does not use SDAM at all

Konrad